Nanbeige4.2-3B vLLM 지원 도입: BOSS Zhipin의 루프형 3B 에이전트 모델, 포크 전용 시대를 벗어나다

Nanbeige4.2-3B — BOSS Zhipin의 Nanbeige Lab이 2026년 7월 말에 출시한 컴팩트 에이전틱 모델 — 이 처음으로 순정 vLLM 설치에서 서비스 가능하게 될 예정입니다. 2026년 9월 9일에 열린 풀 리퀘스트는 transformers 백엔드를 통해 vLLM의 모델 레지스트리에 이 아키텍처를 추가합니다. 병합되면, vllm serve Nanbeige/Nanbeige4.2-3B는 벤더 포크를 사용해야 하는 절차 대신 기본 명령어가 됩니다. 이는 자체 호스팅 사용자가 할 수 있는 일에 실질적인 변화를 의미합니다. 모델이 출시된 이후 6주 동안, 모델 카드에 나열된 모든 서빙 엔진(vLLM, SGLang, llama.cpp, Ollama)은 수정되지 않은 설치가 아닌 Nanbeige가 유지 관리하는 포크를 가리켰습니다.

모델 자체는 뉴스가 아닙니다. 7월 마지막 주부터 다운로드할 수 있었습니다. 뉴스는 포크 전용 시대가 끝나고 있다는 점이며, 그 끝이 이번 주라는 것입니다. SGLang은 9월 5일 메인 브랜치에 Nanbeige4.2의 네이티브 구현을 병합했고, vLLM 풀 리퀘스트는 4일 후에 열렸습니다. 둘 다 모든 엔진이 이전에 특수 사례로 취급했던 아키텍처에 대한 업스트림 표준 설치 지원입니다. 아래에서는 모든 것이 명확히 구분되어 있습니다: 풀 리퀘스트가 실제로 수행하는 작업, 검증된 것과 아직 열려 있는 것, 벤더의 벤치마크 주장, 그리고 이를 맥락에 맞게 보여주는 독립적인 수치입니다.

이번 주에 정확히 무엇이 바뀌었나요?

vLLM 풀 리퀘스트는 vllm-project/vllm #56071, "[Model] Add support for Nanbeige4.2 (transformers backend)"로, 9월 9일에 Nanbeige 엔지니어가 열었으며 작성 시점 기준으로 아직 열려 있습니다. 이 PR은 의도적으로 아주 작습니다 — 파일 두 개뿐입니다. 첫 번째 파일은 vLLM의 모델 레지스트리에 Hugging Face 아키텍처 이름인 NanbeigeForCausalLM을 TransformersForCausalLM에 매핑하는 줄을 추가합니다. TransformersForCausalLM은 transformers 백엔드를 통해 모델을 실행하는 vLLM의 일반 대체(fallback) 모델입니다. 두 번째 파일은 NanbeigeModelArchConfigConvertor를 추가하는데, 그 유일한 역할은 vLLM에 몇 개의 레이어를 배정할지 알려주는 것입니다: config의 num_hidden_layers에 num_loops를 곱한 값을 반환합니다. Nanbeige의 루프형 트랜스포머가 레이어 스택을 반복하기 때문에, vLLM은 이에 맞춰 KV-cache와 attention 인스턴스의 크기를 조정해야 하기 때문입니다.

이 사안을 추적하는 사람이라면 리뷰 스레드의 두 가지 세부 사항이 중요합니다. 첫째, 레지스트리 매핑 덕분에 모델이 자동으로 transformers 백엔드를 통해 실행됩니다. vLLM 유지관리자는 매핑이 존재하면 명시적인 --model-impl transformers 플래그가 불필요해지며, 병합 전 남은 작업은 문서 항목과 레지스트리 매핑에 대한 CI 테스트뿐이라고 언급했습니다. 둘째, 리뷰어들은 최근 병합된 vLLM 변경(PR #54941)이 레이어 수에서 어텐션 모듈을 추론하는 대신 직접 감지함으로써 레이어 수 변환기를 이미 불필요하게 만들 수 있다고 지적했습니다. 쉽게 말하면, 이 수정은 적용되기 전에 더 복잡해지기보다 오히려 더 단순해질 수 있습니다.

vLLM 경로가 더 중요한 이유는 그것이 아닌 것 때문입니다. 이것은 Nanbeige4.2를 vLLM에 네이티브로 넣으려는 첫 번째 시도가 아닙니다. 같은 엔지니어가 7월 말에 출시 당일 네이티브 구현으로 연 PR #49433은 9월 9일에 종료되었는데, 이는 transformers 백엔드 PR이 나타난 바로 그날이었습니다. 메인테이너들은 맞춤형 모델 구현이 아키텍처가 정당화하는 것보다 더 많은 작업이라고 주장하며 transformers 백엔드를 대신 가리켰습니다. 독자를 위한 요점: 업스트림 vLLM 지원은 수작업으로 조정된 네이티브 구현이 아니라 호환성 경로를 통해 도착하고 있으며, 그 차이는 아래에서 논의되는 실제 성능 결과를 가져옵니다.

이 모든 특별한 처리가 필요했던 모델

Nanbeige4.2-3B가 모든 런타임의 가정을 깨뜨린 이유를 이해하려면, 이 모델이 무엇인지 아는 것이 도움이 된다. 이것은 약 40억 개의 파라미터를 가진 모델로, 비임베딩 파라미터는 30억 개이며, Apache-2.0 라이선스로 영어와 중국어로 출시되었다. 코드 에이전트, 사무 자동화, 도구 사용, 터미널 운영과 같은 에이전트형 워크로드를 정확히 겨냥한다. 기술 보고서(arXiv 2607.22083, 2026년 7월 24일자)는 28조 개의 토큰으로 처음부터 사전학습을 수행한 후, 실제 환경 상호작용을 중심으로 구축된 SFT 및 3단계 RL 레시피를 설명한다. 컨텍스트 윈도우는 262,144개 토큰까지 지원한다. 이 모든 것은 확인 가능하다.

평범하지 않은 부분은 아키텍처입니다. Nanbeige4.2-3B는 "Looped Transformer"를 사용합니다. 동일한 22개 트랜스포머 레이어 스택을 두 번 실행하므로, 3B 파라미터 모델이 가중치를 추가하지 않으면서도 기존 3B 모델의 토큰당 연산량의 약 2배를 수행합니다. 이것이 이 연구실이 적은 파라미터 수로 자사 규모 이상의 벤치마크 성능을 주장할 수 있는 방식입니다. 모델은 사실상 자신의 표현(representation)에 대해 두 번째 패스를 수행하며, 설정(config)은 이러한 재사용을 22개 히든 레이어에 대한 num_loops 2(44개의 유효 어텐션 스테이지)로 표현합니다. 그 대가로, 모든 추론 엔진은 두 번 사용되는 레이어 스택을 처리하는 방법을 지정받아야 합니다. KV 캐시와 CUDA 그래프에 대한 어텐션 인덱싱 방법, 캐시 크기 조정 방법, 가중치 스트리밍 방법 등이 그것입니다. 단일 순방향 패스 트랜스포머를 기반으로 하는 기본(스톡) 엔진은 이를 어떻게 처리해야 할지 전혀 알지 못하며, 이것이 사용자 정의 모델링 코드가 리포지토리 안에 포함되어 제공되고 Hugging Face Transformers에서 trust_remote_code=True가 필요한 이유입니다.

그 사용자 정의 코드는 모델의 가장 거친 부분이 존재하는 곳이기도 하다. 독립적인 보고서(arXiv 2608.13987, 8월 중순)는 공개된 체크포인트가 Hugging Face Transformers에서 바로 로드되지 못하게 만든 다섯 가지 버그를 문서화했다. 그중에는 조용히 0으로 설정된 회전 위치 임베딩 버퍼와 제거된 캐시 API 호출이 포함되어 있으며, 커뮤니티 게시물에서는 모델이 전혀 실행되기 전에 use_cache=False와 같은 해결 방법을 설명했다. 그것들은 수정 가능했고, 패치된 체크포인트와 하네스가 현재 유포되고 있지만, 중요한 것은 패턴이다: 이것은 배포 마찰이라는 특이한 비용을 첫날부터 지불해 온 영리한 아키텍처다.

숫자, 공급업체 및 독립

주요 벤치마크 주장은 기술 보고서에서 직접 가져온 것으로, {{1}}Nanbeige4.2-3B가 더 큰 오픈 모델인 Qwen3.5-9B 및 Gemma4-12B를 능가한다는 것입니다{{/1}} — {{2}}에이전트 평가 전반에서 말이죠.{{/2}} {{3}}대표 수치는 SWE-Bench Verified 63.6으로{{/3}}, {{4}}Qwen3.5-9B의 53.1{{/4}}, {{5}}Gemma4-12B의 44.2를 상회합니다.{{/5}} {{6}}보고서에는 GPQA-Diamond 87.4{{/6}}, {{7}}HMMT-Feb-2026 82.8{{/7}}, {{8}}Terminal-Bench 2.0 44.1{{/8}}, {{9}}SWE-Bench Pro 46.9도 기재되어 있습니다.{{/9}} {{10}}이 중 어느 것도 공급업체가 선택한 하네스에서 독립적으로 재현된 바 없으며{{/10}}, {{11}}이는 연구소 자체의 모델 설명으로 읽어야 합니다{{/11}} — {{12}}모델 카드가 요약하는 내용과 동일한 설명으로{{/12}}, {{13}}Artificial Analysis의 소형 모델 리더보드 정상에 있다는 것입니다.{{/13}}

지금까지 독립적인 확인에 가장 가까운 것은 전혀 다른 측면에서 나옵니다. 8월 말에 발표된 iPhone 17 Pro에서 실행된 Artificial Analysis × Liquid AI 온디바이스 벤치마크에서 Nanbeige4.2-3B의 4비트 빌드는 16K 컨텍스트에서 작동하는 33개의 8GB 미만 모델 중 최고 평균 점수에 공동 1위를 기록했습니다(63점, LFM2.5-2.6B와 동률이고 여러 9B급 모델보다 앞섰습니다). 그리고 64K 컨텍스트에서는 65점을 기록하여 Ling 3.0 Tiny의 66점에 이어 2위였습니다. 테스트별 프로필은 놀라웠습니다. MATH-500에서 최고 수준(96%)이고 함수 호출(BFCL에서 76%)에서 강력했지만, AA-Omniscience에서는 33%의 약한 비환각률을 기록했으며 — 결정적으로 실제 사용에서는 느렸습니다. 약 초당 14토큰을 생성했고 1,024토큰 프롬프트에 응답하는 데 21.4초와 4.0GB가 소요되었습니다. 60초 응답 제한 하에서는 평균 점수가 63에서 18로 급락했습니다. 즉, 9B 모델을 능가하는 품질은 실재하며, 그 품질을 만들어내는 루프 구조의 비용도 실재합니다.

업스트림 지원이 실제로 가져다주는 것

두 가지 업스트림 이벤트를 함께 놓고 보면, 자체 호스팅 사용자에게 실제 그림은 간단합니다. SGLang을 실행한다면 Nanbeige4.2-3B는 이미 병합된 메인 브랜치 지원 덕분에 기본 설치에서 바로 서빙할 수 있습니다. 포크 없이도 모델의 도구 호출 및 추론 파서가 SGLang이 이미 제공하는 동일한 qwen3 감지기에 연결됩니다. vLLM을 실행한다면 기본 지원은 머지 하나 차이입니다. 레지스트리 라인이 모델을 transformers 백엔드로 라우팅하고, 아키텍처 변환기가 캐시 크기를 올바르게 설정하며, qwen3 추론 및 도구 호출 파서가 재사용되는데, 이것이 OpenAI 호환 도구 호출 표면이 작동하는 방식입니다.

솔직히 말하자면, vLLM의 경로는 튜닝된 경로가 아니라 호환성 경로입니다. NanbeigeForCausalLM을 TransformersForCausalLM을 통해 실행한다는 것은 vLLM이 자체 커널과 CUDA 그래프 처리를 갖춘 네이티브 구현 대신 모델의 자체 Hugging Face 코드를 서빙 레이어 내부에서 실행한다는 뜻입니다. 이 차이는 바로 SGLang이 네이티브로 구축하기로 선택한 부분입니다. 루프 때문에 이미 토큰당 비용이 두 배로 늘어난 3B 모델의 경우 transformers 백엔드 경로는 가장 빠른 서빙 경로일 가능성이 낮습니다. 게다가 기본 커스텀 코드의 다섯 가지 버그 이력은 그 경로가 여전히 남아 있는 특이한 동작들을 물려받는다는 것을 의미합니다. 도구 호출의 정확성과 긴 컨텍스트 동작이 보통 초당 원시 토큰 수보다 더 중요한 에이전트 워크로드의 경우, 이는 수용 가능한 절충안일 수 있습니다. 지연 시간에 민감한 채팅의 경우에는 프로덕션 경로로 선택하기 전에 벤치마킹을 해볼 가치가 있습니다. 그리고 두 엔진은 여전히 포크 전용입니다. llama.cpp와 Ollama는 계속 Nanbeige 브랜치를 가리키고 있으며, LM Studio에 번들된 llama.cpp 서버는 아직 해당 아키텍처를 지원하지 않습니다.

다음에 볼 콘텐츠

세 가지가 각각 그림을 바꿀 수 있습니다. 첫째, vLLM PR이 병합되어 릴리스에 포함되어야 합니다. 스레드와 vLLM 릴리스 노트를 주시하세요. 리뷰어들은 이미 병합 준비가 완료되려면 문서 항목과 CI 체크포인트 매핑이 남아 있다고 지적했습니다. 둘째, 레이어 수 변환기가 리뷰를 통과하는지 지켜보세요. 유지관리자들은 PR #54941로 인해 그것이 더 이상 필요 없게 되었을 수 있다고 믿고 있기 때문입니다. 이는 이 해결책이 루프형 아키텍처를 둘러싼 임시 구조가 얼마나 많은지를 보여주는 신호입니다. 셋째, 호스팅 제공업체 문제를 주시하세요. 현재 Hugging Face 카드에는 이 모델을 서비스하는 추론 제공자가 표시되어 있지 않으며, 우리도 호스팅하지 않으므로 현재로서는 자체 호스팅 스토리입니다. 제공자가 이 모델을 등록하면 라우팅 측면은 일상적인 문제가 됩니다. 대규모 모델 카탈로그 전반에 걸친 하나의 API에 제공업체 목록 가격을 마크업 없이 그대로 전달하는 방식이, 자체 호스팅된 Nanbeige4.2-3B를 자사가 이겼다고 주장하는 호스팅 모델들과 A/B 비교하는 가장 마찰이 적은 방법입니다. 그때까지 주목할 마일스톤은 방금 발생한 사건입니다. 모든 주요 런타임이 어깨를 으쓱하며 포크로 대응했던 출시 6주 후, 그중 두 곳이 이제 수정되지 않은 설치본에서 Nanbeige4.2-3B를 서비스하고 있습니다.