Nanbeige4.3-33B 분석: 512K 문맥을 지원하는 오픈 웨이트 모델의 코딩·업무 에이전트 성능

Nanbeige4.3-33B는 여러 턴에 걸쳐 추론하고 도구를 호출하며 결과물을 완성하는 에이전트 작업에 초점을 맞췄습니다. 공식 비교에서 터미널 작업, 코딩, 업무 자동화 성적이 눈에 띄지만, 모든 항목에서 앞서거나 일반 소비자 GPU에서 512K 문맥을 손쉽게 쓸 수 있다는 뜻은 아닙니다.

이 글은 2026년 10월 26일 확인 가능한 공식 모델 카드와 설정 파일을 바탕으로 합니다. 아래 점수는 개발사 보고치이며 TboxIO의 독립 실측이 아닙니다. 메모리 계산도 하드웨어 실험이 아닌 이론적 추정입니다.

강한 교사 모델을 먼저 만들고 소형 모델로 증류

Nanbeige4.3-33B는 시리즈의 플래그십 교사 모델입니다. 약 30B급에서 코딩과 전문 업무 협업 능력을 높인 다음, 이를 더 작은 모델로 증류하는 전략입니다. 공식 문서는 향후 Nanbeige4.3-3B를 언급하지만, 이번에 함께 출시됐다는 뜻도, 33B 점수가 그대로 이전된다는 뜻도 아닙니다.

단순한 질의응답보다 작업 이해, 저장소 처리, 도구 실행, 피드백 확인, 해결책 수정에 무게를 둡니다. 자체 호스팅 코딩 및 업무 도우미를 검토하는 팀에 평가 후보가 될 수 있습니다.

항목	공식 정보 및 해석
모델	Nanbeige4.3-33B
규모·구조	약 33B 파라미터, LlamaForCausalLM 밀집형 구조
최대 문맥	524,288 tokens, 512K
공개 가중치	BF16
라이선스	Apache 2.0
주요 용도	에이전트 코딩, 도구 사용, 전문 업무 협업
공식 실행 예시	Transformers, SGLang, vLLM
추론 모드	기본 활성화, 채팅 템플릿으로 설정 가능

밀집형 33B의 비용은 토큰마다 일부 전문가만 활성화하는 MoE 모델과 다르게 봐야 합니다. 512K는 용량 상한이며 모든 길이, 작업, 하드웨어에서 품질과 속도가 같다는 보장은 아닙니다.

공식 점수: 강한 에이전트 성능에도 예외는 있다

개발사는 Qwen3.8-27B, Muse-Glimmer-30B, Gemma4-31B와 비교했습니다. 모든 모델을 최고 추론 강도로 평가했고, 각 벤치마크 안에서 같은 추론 하이퍼파라미터와 하네스를 사용했다고 설명합니다. 다음은 주요 항목의 원점수입니다.

벤치마크	Nanbeige4.3-33B	Qwen3.8-27B	Muse-Glimmer-30B	Gemma4-31B
Terminal-Bench 2.1	80.9	73.0	61.8	47.2
Terminal-Bench 4.0	23.8	6.3	1.6	0.0
DeepSWE	65.5	42.5	4.4	2.7
SWE-Bench Pro	60.3	61.7	36.9	51.2
SWE-Atlas-QnA	50.8	41.9	17.7	3.3
NL2Repo	53.0	48.3	27.4	33.8
SkillsBench	61.1	56.4	39.7	28.9
Automation Bench	54.2	38.3	15.2	9.7
JobBench	44.8	34.5	16.6	9.0
GDPval	84.8	86.4	75.8	71.4
Claw-Eval pass^3	78.3	75.2	57.3	44.2
Toolathlon-Verified	70.4	68.5	47.2	27.8
GPQA Diamond	89.5	89.2	83.5	91.3
AIME 2026	95.2	94.5	94.7	89.2
AA-LCR	84.0	82.0	83.3	72.0

• 터미널·코딩 작업이 돋보입니다. Qwen보다 Terminal-Bench 2.1에서 7.9점, DeepSWE에서 23.0점 높습니다. 반면 Terminal-Bench 4.0의 23.8은 어려운 작업에 여전히 실패 여지가 큼을 보여줍니다.
• 업무 자동화도 주목할 만합니다. Automation Bench는 15.9점, JobBench는 10.3점 높습니다. 지정된 평가 흐름에서의 결과이지 기업 실제 업무의 자동화 성공률은 아닙니다.
• Qwen이 앞서는 항목도 있습니다. SWE-Bench Pro는 60.3 대 61.7, GDPval은 84.8 대 86.4로 Nanbeige가 낮습니다.
• 일반 추론도 전면 우위는 아닙니다. GPQA Diamond 89.5는 Qwen의 89.2보다 조금 높지만 Gemma4-31B의 91.3보다 낮습니다. 0.3점 차이를 안정적인 종합 우위로 확대하면 안 됩니다.

이는 같은 표 안의 점수 차이지 이전 세대 Nanbeige 대비 향상률이 아닙니다. 인용한 카드에는 이전 세대와의 완전한 동일 조건 비교가 없습니다. 앞선 DeepSeek, MiniMax, Kimi, Raon 기사와 비교할 때도 벤치마크 버전, 에이전트 하네스, 추론 예산을 먼저 맞춰야 합니다.

평가 조건을 함께 읽어야 하는 이유

에이전트 결과에는 모델 외에도 도구, 실행 환경, 문맥 관리, 재시도 예산이 영향을 줍니다. 공식 각주의 핵심은 다음과 같습니다.

1. Nanbeige는 preserve_thinking=true 로 평가했습니다. 이전 턴의 추론을 지우는 통합 방식에서는 다중 턴 동작이 달라질 수 있습니다.
2. Terminal-Bench 2.1은 Terminus 2, Terminal-Bench 4와 DeepSWE는 mini-swe-agent v2.4.6을 사용합니다. 서로 다른 버전 점수를 하나의 순위표에 섞지 않아야 합니다.
3. SWE-Atlas-QnA는 mini-swe-agent v2.4.6을 사용하며 GPT-6 Sol이 medium reasoning effort로 1,304개 작업별 루브릭을 적용해 판정합니다. NL2Repo는 Claude Code, JobBench는 검색 도구가 있는 Claude Code 하네스입니다.
4. Automation Bench v1.0.6은 공개 작업 600개를 포함합니다. Claw-Eval은 단일 턴 상호작용 157개인 General 하위 집합만 평가하며, 지표는 pass^3입니다. 이 범위를 생략하면 안 됩니다.
5. GDPval은 수정된 루브릭 점수이므로 84.8은 Elo가 아닙니다. Toolathlon-Verified는 개별 요청의 max_tokens를 제한하지 않아 실제 토큰 소모를 함께 봐야 비용을 비교할 수 있습니다.

YC-bench는 1,025,437달러로 보고됐지만, 이는 벤치마크 안의 달러 표시 결과입니다. API 가격, 실제 매출, 사용자의 수익 보장이 아닙니다. 백분율형 점수와 섞어서 평균할 수도 없습니다.

추론과 도구 호출: 서로 다른 두 설정

enable_thinking은 현재 응답에서 추론을 생성할지 결정합니다. 기본 활성화이며 False로 비추론 모드를 쓸 수 있습니다. preserve_thinking은 이전 어시스턴트 추론을 보존할지 결정합니다. 개발사는 일반 대화·질의응답에는 False, 다중 턴 도구 사용·업무·코딩 에이전트에는 True를 권장합니다.

도구 형식은 tool_call_format="xml"을 우선 권장하고 json도 호환용으로 지원합니다. 채팅 템플릿, 도구 파서, 이전 추론 저장 방식이 일치해야 합니다. 모델 이름만 바꾼다고 공식 평가 설정을 재현하는 것은 아닙니다.

시나리오	Temperature	Top_p	권장 Max New Tokens
에이전트·도구 작업	1.0	0.95	65,536
추론·대화	0.6	0.95	262,144

Max New Tokens는 출력 예산이고 512K는 문맥 한도입니다. 입력, 보존 추론, 도구 결과, 새 출력이 서버의 문맥 제한을 함께 만족해야 합니다. 큰 출력 상한이 매번 그 길이만큼 생성한다는 뜻은 아닙니다.

배포: BF16 가중치 약 66GB에 캐시가 추가된다

공식 파일 목록은 약 66.3GB이며 BF16 Safetensors 가중치를 제공합니다. 33B 파라미터에 각각 2바이트를 적용하면 가중치만 십진 단위 약 66GB입니다. KV 캐시, 실행 버퍼, 프레임워크 오버헤드는 별도로 필요합니다. 저장소 크기는 전체 실행 시 VRAM 요구량과 같지 않습니다.

공식 설정은 52개 층, KV 헤드 8개, head_dim 128입니다. 단순한 BF16 KV 캐시로 단일 시퀀스 524,288토큰을 채운다면 K와 V를 합쳐 약 104GiB 가 필요하다고 계산할 수 있습니다. 공식 하드웨어 실측이 아니라 설정에서 도출한 이론치입니다. 캐시 정밀도, 병렬 분할, 오프로딩, 런타임 전략에 따라 실제 사용량은 달라집니다.

512K 지원이 일반 GPU 한 장에서 전체 문맥을 쉽게 돌린다는 뜻은 아닙니다. 양자화는 가중치 메모리를 줄일 수 있지만 변환 품질, 런타임 호환성, 장문 성능을 검증해야 합니다. 이 글에서는 양자화판, Mac, 소비자 GPU의 토큰 생성 속도를 실측하지 않았습니다.

공식 SGLang·vLLM 예시는 4-way tensor parallelism, qwen3 reasoning parser, qwen3_coder tool-call parser를 사용합니다. 이는 예시이며 모든 배포의 최소 GPU 수는 아닙니다. 입력 길이, 동시 요청 수, 첫 토큰 지연, 출력 속도를 기준으로 용량을 측정해야 합니다.

누가 평가할 만한가

자체 호스팅 코딩 에이전트, 도구 기반 업무 흐름, 교사·학생 증류 연구를 하는 팀이라면 후보에 넣을 이유가 있습니다. Apache 2.0은 명확한 사용 기반을 제공하며 배포 시에는 해당 조건을 따라야 합니다.

일상 대화, 낮은 지연, 작은 VRAM이 우선이라면 밀집형 33B의 비용을 따져야 합니다. 모델 카드에는 상용 예산에 바로 쓸 공식 API 단가나 통일된 처리량 시험이 없습니다. 오픈 웨이트라도 GPU, 저장소, 운영 비용은 남습니다.

실제 저장소와 업무 과제로 소규모 평가를 하고 완료율, 도구 오류, 토큰 소모, 지연, 사람의 수정 횟수를 기록하는 것이 좋습니다. 파일 수정이나 업무 시스템 작업 도구는 먼저 격리된 환경에서 시험할 수 있습니다.

TboxIO의 판단: 자체 호스팅 가능한 33B 안에 강한 코딩·업무 에이전트 능력을 담았다는 점이 매력입니다. 공식 결과는 평가 후보라는 근거이며 모든 작업 최강 또는 항상 더 저렴하다는 근거는 아닙니다.

출처

• 공식 모델 카드: 포지셔닝, 점수, 각주, 실행 안내
• 공식 config.json: 구조, 층수, KV 헤드, 문맥
• 공식 파일 목록: BF16 가중치 및 크기