마지막 수정
Nanbeige4.2-3B, M4 Mac mini 16GB에서 실행 전 확인한 것
Nanbeige4.2-3B의 에이전트 벤치마크와 8.34GB 공식 가중치, Ollama·llama.cpp 호환 문제를 대조해 M4 Mac mini 16GB에서 시험할 기준을 정리했습니다.
결론 먼저
Nanbeige4.2-3B는 M4 Mac mini 16GB에서 시험할 만한 작은 에이전트 모델입니다. 다만 공식 BF16 가중치는 약 8.34GB이고 표준 llama.cpp·Ollama 호환이 아직 매끄럽지 않아, 검증되지 않은 양자화 파일보다 공식 실행 경로와 작은 context부터 확인해야 합니다.
- 실험 환경
- 2026년 7월 22일 Nanbeige 공식 Hugging Face 모델 카드·배포 파일·설정 파일과 같은 날 공개된 LocalLLaMA 초기 사용자 보고를 대조했습니다. 아직 Daejin Lab 장비에서 모델을 내려받거나 실행하지 않았습니다.
- 누구에게 유용한가
- 16GB Apple Silicon Mac에서 작은 로컬 코딩·도구 호출 모델을 찾는 사람, 제작사 벤치마크와 실제 실행 가능성을 나눠 판단하려는 사람
확인한 자료와 한계
- Nanbeige4.2-3B 공식 Hugging Face 모델 카드와 배포 파일
- Nanbeige4.2-3B 공식 설정·실행 안내
- Reddit LocalLLaMA·LocalLLM 공개 당일 사용자 보고
제작사가 공개한 벤치마크를 독립 재현하지 않았습니다. M4 Mac mini 16GB의 로딩 성공 여부, 메모리, tokens/sec, 한국어 품질과 도구 호출 정확도는 후속 실험 전까지 미확인입니다.
이 글에서 다루는 핵심 3가지
3B 모델이 Gemma 4 12B보다 에이전트 작업을 잘한다는 표보다 먼저 본 것은 파일 크기와 실행 경로였습니다. M4 Mac mini 16GB에서 실제로 쓸 수 있는지는 벤치마크 순위만으로 판단할 수 없기 때문입니다.
공식 BF16 가중치는 약 8.34GB입니다. 모델 고유 구조 때문에 일반 llama.cpp에서 곧바로 열리지 않았다는 보고도 나왔습니다. Ollama 안내 역시 평소 쓰는 설치본이 아니라 별도 빌드와 실험 기능을 전제로 합니다.
아직 Daejin Lab 장비에서 모델을 실행하지 않았습니다. 이 글에서는 Nanbeige4.2-3B가 무엇을 잘한다고 주장하는지, 16GB Mac에서 어디부터 막힐 수 있는지, 직접 시험할 때 무엇을 기록해야 하는지를 구분해 정리했습니다.
10초 요약
- Nanbeige4.2-3B는 2026년 7월 21일 공개된 Apache 2.0 모델입니다.
- 전체 파라미터는 약 4B, 임베딩을 제외하면 3B입니다. 같은 층을 다시 통과시키는 Looped Transformer 구조를 사용합니다.
- 제작사 표에서는 Qwen3.5-9B와 Gemma4-12B보다 여러 에이전트·코딩 평가 점수가 높습니다.
- 이 수치는 같은 날 공개된 독립 재현 결과가 아니라 제작사 평가입니다. 일부 항목은 자체 실행 환경과 rubric을 사용했습니다.
- 공식 BF16 safetensors 두 파일의 합계는 8,339,601,408바이트, 약 8.34GB입니다.
- 공식 모델은
modeling_nanbeige.py라는 사용자 정의 코드를 포함하며 Transformers 예제도trust_remote_code=True를 사용합니다. - 공개 당일에는 표준 llama.cpp의
unknown model architecture: nanbeige오류와 MCP 도구 인식 실패가 보고됐습니다. - M4 Mac mini 16GB에서는 공식 실행 경로를 먼저 검토하고, context 4K와 단일 요청부터 시작하는 편이 안전합니다.
이번에 확인한 자료
| 구분 | 확인한 내용 |
|---|---|
| 공식 모델 카드 | 구조, 파라미터, 지원 작업, 제작사 벤치마크, 권장 실행 설정 |
| 공식 배포 파일 | BF16 가중치 크기, 사용자 정의 모델 코드, 설정 파일 |
| Ollama 안내 | 공식 모델 구조를 넣은 별도 빌드, GGUF·MLX 실행 방법 |
| 초기 사용자 보고 | llama.cpp 로드 오류, MCP 인식 문제, 긴 thinking 출력 |
| 아직 확인하지 못한 것 | M4 16GB 로딩, 메모리, 속도, 한국어, 실제 도구 호출 성공률 |
공식 자료와 사용자 후기는 같은 증거가 아닙니다. 제작사 표는 모델의 목표를 보는 자료이고, 초기 후기는 실패 지점을 찾는 단서입니다. 실제 사용 가능 여부는 같은 장비와 같은 입력으로 다시 확인해야 합니다.
Nanbeige4.2-3B는 어떤 모델인가
Nanbeige4.2-3B는 에이전트와 도구 사용에 초점을 맞춘 작은 언어 모델입니다. 공식 설명 기준 전체 파라미터는 4B이고, 임베딩을 빼면 3B입니다.
눈에 띄는 부분은 Looped Transformer입니다. 한 번 아래층부터 위층까지 계산한 hidden state를 같은 층 묶음에 다시 통과시킵니다. 파라미터를 그대로 두고 계산 깊이를 늘리는 방식입니다. 작은 파일로 더 복잡한 추론을 노린 대신, 일반적인 3B 모델과 속도가 같을 것이라고 미리 가정해서는 안 됩니다.
모델 카드에는 두 가지 thinking 설정도 나옵니다.
| 설정 | 용도 |
|---|---|
enable_thinking |
현재 응답에서 reasoning 생성 여부 |
preserve_thinking |
이전 응답의 reasoning을 다음 대화에 유지할지 여부 |
일반 대화에서는 preserve_thinking=false, 여러 단계의 도구·사무·코딩 작업에서는 true를 권장합니다. 도구 호출은 XML 형식을 우선 권장하고 JSON도 호환용으로 지원한다고 적혀 있습니다.
3B가 12B보다 높다는 숫자는 어떻게 봐야 하나
공식 모델 카드에서 눈에 띄는 수치를 일부 옮기면 아래와 같습니다.
| 평가 | Nanbeige4.2-3B | Qwen3.5-9B | Gemma4-12B |
|---|---|---|---|
| GDPval rubrics | 74.3 | 61.9 | 68.5 |
| MCP-Atlas | 57.8 | 47.4 | 30.5 |
| SWE-Bench Verified | 63.6 | 53.1 | 44.2 |
| SWE-Bench Pro | 46.9 | 33.8 | 21.9 |
| Terminal-Bench 2.0 | 44.1 | 29.2 | 21.1 |
이 표만 보면 3B 모델이 9B와 12B를 넉넉히 앞섭니다. 그대로 일반화하기에는 확인할 조건이 있습니다.
먼저 모델 카드가 밝힌 것처럼 GDPval과 일부 office·협업 평가는 제작사 자체 scaffold를 사용했습니다. SWE-Bench 계열도 OpenHands, SWE-agent, Terminus 2처럼 평가별 실행기가 다릅니다. 모델의 순수한 답변 품질과 에이전트 실행기의 성능이 함께 반영된 숫자입니다.
또 Nanbeige4.2-3B는 thinking mode와 preserve_thinking=true로 평가됐습니다. 작은 모델이라도 reasoning 토큰을 길게 쓰면 완료 시간과 메모리 부담이 늘 수 있습니다. 공개 당일 사용자 반응에서도 답은 괜찮지만 thinking이 길다는 관찰이 나왔습니다.
그래서 첫 실험에서는 점수를 재현하려 하기보다 아래 질문부터 확인하는 편이 낫습니다.
작은 코드 수정 한 건을 끝까지 완료하는가?
도구 호출 형식을 20회 연속 지키는가?
같은 도구를 이유 없이 반복 호출하는가?
thinking을 제한하면 정답률이 얼마나 떨어지는가?
한국어 조건을 여러 단계 뒤에도 유지하는가?공식 파일은 3B라는 이름보다 크다
3B만 보고 2~3GB 파일을 예상하면 실제 배포본에서 당황할 수 있습니다.
공식 Hugging Face 저장소의 BF16 가중치는 두 파일로 나뉩니다.
| 파일 | 크기 |
|---|---|
model-00001-of-00002.safetensors |
약 4.97GB |
model-00002-of-00002.safetensors |
약 3.37GB |
| 합계 | 약 8.34GB |
전체 파라미터가 약 4B이므로 BF16 가중치가 8GB를 넘는 것은 이상하지 않습니다. 여기에 runtime, activation, KV cache, 프롬프트와 운영체제 메모리가 더 필요합니다.
M4 Mac mini 16GB에서 파일을 메모리에 올릴 가능성은 있어 보입니다. 하지만 로드 가능과 도구를 붙여 여러 번 실행 가능은 다른 문제입니다. context를 크게 잡거나 다른 앱을 함께 켜면 메모리 압박과 swap이 생길 수 있습니다.
처음부터 모델 카드의 최대 출력 65,536 또는 131,072토큰을 목표로 잡지 않는 이유입니다. 실제 실험은 4K context에서 시작하고, 메모리와 첫 토큰 지연을 확인한 뒤 8K로 올리는 편이 맞습니다.
표준 llama.cpp와 Ollama에서 바로 열리지 않을 수 있다
공식 config.json의 모델 타입은 nanbeige, architecture는 NanbeigeForCausalLM입니다. 저장소에는 약 122KB의 modeling_nanbeige.py도 포함돼 있습니다.
Transformers 예제는 아래 옵션을 사용합니다.
trust_remote_code=True이 옵션은 모델 저장소의 Python 코드를 로컬에서 실행한다는 뜻입니다. 공식 계정이라도 다운로드한 코드와 commit hash를 확인하고, 격리된 환경에서 먼저 실행해야 합니다. 개인정보가 들어 있는 작업 폴더나 비밀키가 로드된 셸에서 곧바로 시험할 이유는 없습니다.
Ollama 실행 안내도 평소 설치하는 정식 바이너리만으로 끝나지 않습니다. 공식 모델 카드에는 Nanbeige용 renderer와 parser가 포함된 소스 빌드, llama.cpp payload 복사, MLX safetensors import의 --experimental 옵션이 나옵니다.
커뮤니티에서는 같은 날 다음 문제가 보고됐습니다.
llama_model_load: error loading model: unknown model architecture: 'nanbeige'
Ollama에서는 응답하지만 연결된 MCP 도구를 보지 못함
reasoning이 길어 간단한 작업도 완료 시간이 늘어남초기 사용자 한두 명의 경험을 전체 모델 평가로 볼 수는 없습니다. 그래도 현재 단계에서 “Ollama에 모델 이름만 넣으면 로컬 에이전트가 바로 된다”고 쓰기 어려운 근거는 됩니다.
새 양자화 파일을 바로 받지 않은 이유
공개 하루 만에 GGUF와 MLX 2·3·4·5·6·8비트 변환본이 여러 계정에서 생겼습니다. 확인 시점에는 다운로드 기록이 거의 없거나 0인 저장소가 많았습니다.
새로운 양자화 파일도 출처와 변환 과정을 확인하면 사용할 수 있습니다. 지금은 아래 항목을 판단할 기록이 부족합니다.
원본 commit과 tensor가 일치하는가?
변환 스크립트와 옵션이 공개됐는가?
chat template과 tool parser가 유지됐는가?
다른 사용자가 같은 파일을 로드했는가?
파일 hash와 라이선스가 명확한가?이번 모델은 사용자 정의 구조와 도구 형식이 핵심입니다. 가중치만 작게 바뀌어도 runtime과 parser가 맞지 않으면 모델이 열리지 않거나 도구 호출이 망가질 수 있습니다. 다운로드 수만 믿을 일도 아니지만, 공개 직후 검증 기록이 전혀 없는 파일을 주력 환경에 넣는 것도 피하는 편이 낫습니다.
M4 Mac mini 16GB에서 시험한다면
첫 테스트에서는 점수 재현보다 안전한 로딩과 실패 기록을 우선합니다. 짧은 작업부터 반복해야 어느 단계에서 무너지는지 알 수 있습니다.
| 순서 | 확인 항목 | 통과 기준 |
|---|---|---|
| 1 | 공식 저장소·코드 검토 | 실행 코드, commit, hash 기록 |
| 2 | 격리 환경 로드 | 개인 폴더·키 접근 없이 시작 |
| 3 | context 4K 단일 응답 | OOM·과도한 swap 없이 완료 |
| 4 | 한국어 요약 5회 | 핵심 조건과 근거 문장 유지 |
| 5 | 구조화 도구 호출 20회 | XML·JSON 형식 오류와 반복 호출 기록 |
| 6 | 작은 저장소 수정 | 필요한 파일만 변경하고 테스트 완료 |
| 7 | 10회 연속 대화 | 앞선 조건 유지와 메모리 증가 확인 |
측정 항목은 아래처럼 고정해서 남겨야 합니다.
runtime와 commit
모델 파일과 hash
context·thinking 설정
첫 토큰까지 걸린 시간
출력 tokens/sec
최대 unified memory와 swap
작업 완료 시간
형식 오류·재시도·반복 도구 호출 횟수
사람이 고친 항목 수작은 모델의 장점은 한 번의 정답보다 반복 작업에서 드러날 수 있습니다. 반대로 매 토큰을 두 번 계산하고 thinking을 길게 쓴다면 예상보다 느릴 수도 있습니다. 파일 크기와 전체 완료 시간을 함께 봐야 합니다.
Gemma 4 12B·Bonsai 27B와 무엇을 비교할까
Nanbeige4.2-3B는 기존 Daejin Lab 실험과 비교하기 좋은 위치에 있습니다.
| 모델 | 비교할 이유 |
|---|---|
| Gemma 4 12B | 더 큰 일반 모델보다 도구·코딩 작업을 잘한다는 제작사 주장 확인 |
| Bonsai 27B | 작은 파일과 실제 에이전트 안정성이 같은 문제인지 비교 |
| Nanbeige4.2-3B | 작은 파라미터와 반복 계산이 완료 비용에 주는 영향 확인 |
Gemma 4 12B를 M4 Mac mini 16GB에서 먼저 돌려본 기록에서는 모델이 열리는 것과 반복 작업에 쓸 수 있는 것을 나눠 봤습니다. M4 Mac mini 16GB에서 Bonsai 27B를 비교한 기록에서는 낮은 비트 모델도 runtime과 도구 호출 조건에 따라 결과가 달라지는 것을 확인했습니다.
Nanbeige 테스트도 같은 기준으로 맞춰야 숫자보다 실제 차이를 볼 수 있습니다.
지금 결론
Nanbeige4.2-3B는 M4 Mac mini 16GB에서 시험할 이유가 충분한 모델입니다. 4B 전체 파라미터, Apache 2.0, 도구 사용 중심 학습, 공개 당일의 높은 관심은 모두 좋은 출발점입니다.
아직 “3B가 12B를 이겼다”고 결론 내릴 단계는 아닙니다. 벤치마크에는 제작사 자체 실행 환경이 포함됐고, 공식 가중치는 약 8.34GB이며, 표준 llama.cpp·Ollama 호환도 정리 중입니다. thinking 토큰과 실행 시간을 포함한 완료 비용도 직접 재야 합니다.
다음 판단은 숫자가 아니라 실행 기록으로 해야 합니다. M4 16GB에서 로드 로그, 메모리, 속도와 도구 호출 실패를 같은 조건으로 남긴 뒤 이 글을 업데이트하겠습니다.
같이 읽을 글
- Gemma 4 12B를 M4 Mac mini 16GB에서 먼저 돌려본 기록
- M4 Mac mini 16GB에서 Bonsai 27B 실험: oMLX·LM Studio·llama.cpp 비교
- 로컬 LLM 실험을 시작하기 전에 정한 기준
- 외부 AI 에이전트 repo를 설치하기 전에 보는 안전 체크리스트
참고 자료
- Nanbeige/Nanbeige4.2-3B 공식 모델 카드
- LocalLLaMA: Nanbeige4.2-3B 공개 토론
- LocalLLM: Nanbeige 팀의 모델 소개
- LocalLLaMA: 공개 벤치마크와 초기 실행 의견
기준일은 2026년 7월 22일입니다. 모델 파일, runtime 지원과 커뮤니티 양자화 상태는 빠르게 바뀔 수 있습니다. 실제 설치 전에는 공식 모델 카드와 사용하려는 runtime의 최신 지원 상태를 다시 확인해야 합니다.