Nanbeige4.2-3B: тесты показали провал модели с громкими бенчмарками
Новая 3B-модель Nanbeige4.2 на бумаге обгоняет Qwen3.5-9B и Gemma4-12B, но в реальных задачах проваливается: «петлевая» архитектура удваивает размер в памяти до 6B, контекст пожирает 5+ ГБ VRAM, а «думающий» режим сжигает токены на пустом месте. Провалила два простых кодинговых задания, хотя tool calling работает идеально.
Пост показывает реальную пропасть между бенчмарками и продакшеном — критичная информация для тех, кто выбирает модели для бизнеса или разработки, а не для демо.
Что произошло
На Reddit появился подробный разбор новой китайской модели Nanbeige4.2-3B от разработчика, искавшего лёгкую замену Qwen3.6-35B для простых задач кодинга.
Технические проблемы: - Модель использует looped architecture — все слои проходятся дважды, фактически это 6B-модель по скорости и контексту - Контекст 128k с квантизацией kvarn3 занимает 5.2 ГБ VRAM — огромно для такого размера - В llamacpp модель изначально сломана, требует фикса через PR
Качество работы: Модель показывает сильные бенчмарки благодаря трюку: на максимальном уровне «размышлений» она бесконечно думает вслух, сжигая контекст и время. В реальных задачах провалила два простых brownfield maintenance задания в проекте с подробной документацией.
Единственный плюс: безупречный tool calling после фикса.
По скорости и точности уступает даже Qwen3.6-35B с экспертами в оперативной памяти. Автор резюмирует: ни маленькая (в VRAM огромная), ни быстрая (wall time ужасное), ни надёжная.
Автор: Артём Ковалёв · Источник: reddit.com
Разработчикам. Модель сломана в llamacpp из коробки, требует патча. Looped архитектура удваивает проходы по слоям — нужно учитывать при оценке памяти и контекста. Tool calling работает стабильно, но для простого кодинга модель непригодна — проваливает базовые задачи.
Бизнесу. Громкие бенчмарки не равны реальной пользе: модель оптимизирована под тесты, а не под продакшн. Для задач, где важна скорость ответа и точность (чат-боты, кодинг-ассистенты), это не вариант — даже старые модели работают лучше.
Инвесторам. Яркий пример манипуляции метриками: сильные бенчмарки достигаются через «думающий» режим, непригодный для реальных продуктов. Рынок малых моделей переполнен маркетингом — критично проверять на реальных задачах, а не на синтетике.
- Создать сервис независимого тестирования LLM на реальных задачах, а не синтетических бенчмарках — платная аналитика для разработчиков
- Разработать инструмент для автоматической оценки wall time и VRAM-нагрузки моделей в разных режимах (thinking levels, KV cache)
- Консалтинг по выбору моделей для стартапов: многие переплачивают за хайп или страдают от недооценки реальных требований
- Фокус на оптимизации tool calling слоя — это единственное, что в модели работает идеально, можно выделить в отдельный продукт
- Бенчмарки LLM всё чаще становятся маркетинговым фокусом — реальная производительность расходится с заявленной
- Looped архитектуры выглядят компактно на диске, но пожирают память в рантайме — скрытая ловушка для малых GPU
- Thinking режимы полезны для сложных задач, но превращаются в токен-пожиратель на простых — нужен адаптивный выбор
- Китайские модели часто требуют кастомных фиксов в llamacpp/vLLM — риск для продакшена без собственной инфраструктуры
Это классический случай «хороша на бумаге, провал в деле». Nanbeige4.2 оптимизирована под синтетические тесты с бесконечным «размышлением», которое в продакшене превращается в токеноед и тормоз. Looped архитектура выглядит компактной (3B), но работает как 6B — удвоенные проходы по слоям пожирают VRAM и контекст.
Что реально интересно: tool calling работает безупречно даже в сломанной модели. Это показывает, что индустрия научилась делать надёжные функциональные вызовы, но с общим интеллектом всё ещё проблемы. Если ищете лёгкую модель для простых задач — берите проверенные Qwen или Phi, а не гонитесь за красивыми цифрами в таблицах.
Комментарии