저는 Nanbeige-4.2-3B를 테스트해 보았습니다. 서류상으로는 이 모델이 Qwen3.5-9B와 Gemma4-12B를 압도할 것이라고 벤치마크에서 약속하고 있습니다. 제 목표는 간단하고 직관적인 코딩 작업을 위해 Qwen3.6-35B(또는 이를 미세 조정(finetunes)한 버전)을 대체할 수 있는 매우 가볍고 빠른 모델을 확보하는 것이었습니다. 과거에 Qwen3.5-9B를 다운그레이드해보기도 했지만, 고려될 만큼 충분하지 않았습니다. 현재 이 모델은 llamacpp master에서 작동 오류가 있습니다. 이 PR이 이를 수정했습니다: https://github.com/ggml-org/llama.cpp/pull/26324 문제를 수정한 후, 제가 직접 사용해 보았는데 솔직히 말해서 감명받지 못했습니다. 우선, 이 모델은 루프형(looped) 모델입니다. 모든 레이어를 두 번씩 순회합니다. 이는 이론적인 기준치로 볼 때, 6B 모델의 속도와 컨텍스트 크기를 가진다는 것을 의미합니다. Q6 양자화(quant)에서 가중치를 실행할 수 있고 Q4와의 크기 차이를 거의 느끼지 못하는 것은 좋습니다. 하지만 컨텍스트가 워낙 방대하기 때문에 매우 나쁜 KV 캐시 양자화를 사용해서 보상해야 합니다. 128k의 kvarn3 t2048 컨텍스트는 매우 빠듯하며, 극심한 성능 저하 없이 사용할 수 있는 한계에 가깝습니다. 이 컨텍스트를 처리하는 데 5.2GB가 소요됩니다. 이 크기의 모델치고는 엄청난 양입니다. 256k kvarn5는 가중치와 데스크톱 환경을 고려하면 16GB VRAM에 들어가지 않습니다. 이 모델은 Laguna-S-2.1이 사용하는 것과 동일한 '꼼수'를 사용하여 좋은 벤치마크 결과를 얻습니다. 즉, [최대] 사고 수준(thinking level)에서 벤치마크될 때, 생각하고 또 생각하며 멈추지 않습니다. 이는 단순히 느리다는 점(작업당 벽 시간) 외에도, 간단한 작업에서도 컨텍스트 예산을 매우 빠르게 소모한다는 것을 의미합니다. 저는 이 모델에게 견고한 AGENTS.md와 스킬을 가진 프로젝트에서 두 가지 매우 단순하고 복잡하지 않은 브라운필드 유지보수 작업을 시켰습니다. 하지만 둘 다 실패했습니다. 과연 Qwen3.5 9B보다 나은가? 말하기 어렵습니다. 저 역시 그 모델에 대해 좋지 않은 경험만 했고, 가장 간단한 작업에서 지속적으로 실패하는 모델들을 구별하기가 어렵기 때문입니다. 주목할 점은 Nanbeige가 (128k 기준) 메모리 크기와 속도가 완전히 동일하다는 것입니다.

작업당 소요 시간 (time-per-task) 측면에서, 전문가(experts)가 호스트 메모리(host memory)로 스필(spilled)된 Qwen3.6-35B-A3B가 훨씬 더 빠르며 실제로 정확한 출력을 생성합니다. 작은 모델을 원하시나요? 좋은 모델이 아닙니다 (디스크 용량은 작지만, VRAM 사용량은 엄청납니다). 빠른 모델을 원하시나요? 그것도 아닙니다. 특히 초당 토큰 수 (tok/s) 대신 작업당 소요 시간 (time-per-task)을 측정할 때 더욱 그렇습니다. 아주 쉬운 작업에 대해 정밀하고 신뢰할 수 있는 모델을 원하시나요? 그것 또한 아닙니다. /u/crusaderky 제출 [link] [comments]