Поддержка vLLM для Nanbeige4.2-3B уже на подходе: зацикленная агентная модель 3B от BOSS Zhipin выходит из эпохи «только форки»

Nanbeige4.2-3B — компактная агентная модель, выпущенная лабораторией Nanbeige из BOSS Zhipin в конце июля 2026 года, — впервые станет доступна для обслуживания в стандартной установке vLLM. Pull request, открытый 9 сентября 2026 года, добавляет архитектуру в реестр моделей vLLM через бэкенд transformers. Если он будет принят, vllm serve Nanbeige/Nanbeige4.2-3B станет стандартной командой, а не ритуалом с форком от вендора. Это реальное изменение в том, что может сделать самостоятельный хостинг: в течение шести недель с момента выпуска модели каждый движок, перечисленный в её карточке — vLLM, SGLang, llama.cpp, Ollama — указывал на форк, поддерживаемый Nanbeige, а не на немодифицированную установку.

Сама модель — не новость: она доступна для скачивания с последней недели июля. Новость в том, что эпоха форков заканчивается, причём на этой неделе. SGLang влил нативную реализацию Nanbeige4.2 в свою основную ветку 5 сентября, а pull request в vLLM открыли четырьмя днями позже. И то и другое — поддержка в апстриме, доступная при стандартной установке, для архитектуры, которую каждый движок раньше рассматривал как особый случай. Ниже всё разложено по полочкам: что на самом деле делают эти pull request'ы, что подтверждено, а что остаётся открытым, заявления вендора о бенчмарках и независимые цифры, которые помещают их в контекст.

Что именно изменилось на этой неделе

Запрос на включение в vLLM — это vllm-project/vllm #56071, «[Model] Add support for Nanbeige4.2 (transformers backend)», открытый 9 сентября инженером Nanbeige и всё ещё открытый на момент написания. Он намеренно небольшой — два файла. Первый добавляет строку в реестр моделей vLLM, сопоставляющую имя архитектуры Hugging Face NanbeigeForCausalLM с TransformersForCausalLM — универсальным запасным вариантом vLLM, который запускает модель через бэкенд transformers. Второй добавляет NanbeigeModelArchConfigConvertor, единственная задача которого — сообщить vLLM, сколько слоёв закладывать в бюджет: он возвращает num_hidden_layers из конфига, умноженное на num_loops, потому что циклический трансформер Nanbeige повторяет свой стек слоёв, и vLLM должен соответствующим образом рассчитать размер KV-кэша и экземпляров внимания.

Две детали из ветки обсуждения важны для тех, кто следит за этим. Во-первых, сопоставление реестра — это то, что заставляет модель автоматически работать через бэкенд transformers; мейнтейнер vLLM отметил, что как только сопоставление существует, явный флаг `--model-impl transformers` становится избыточным, а оставшаяся работа перед слиянием — это запись в документации и тест реестра сопоставлений в CI. Во-вторых, рецензенты отметили, что недавно объединённое изменение vLLM (PR #54941) может уже сделать конвертер количества слоёв ненужным, определяя модули внимания напрямую, а не выводя их из количества слоёв. Проще говоря: исправление может стать проще до того, как оно будет принято, а не сложнее.

Путь vLLM важен больше из-за того, чем он не является. Это не первая попытка нативной интеграции Nanbeige4.2 в vLLM. PR #49433, открытый тем же инженером в конце июля как нативная реализация «с первого дня», был закрыт 9 сентября — в тот же день, когда появился PR на основе бэкенда transformers, — после того как мейнтейнеры заявили, что индивидуальная реализация модели требует больше работы, чем оправдывает архитектура, и указали на бэкенд transformers как альтернативу. Вывод для читателей: поддержка vLLM в апстриме приходит по пути совместимости, а не через нативную реализацию, настроенную вручную, и это различие имеет реальные последствия для производительности, которые обсуждаются ниже.

Модель, которой требовалась вся эта особая обработка

Чтобы понять, почему Nanbeige4.2-3B нарушил все допущения сред выполнения, полезно знать, что это за модель. Это модель примерно с 4 миллиардами параметров, из которых 3 миллиарда не относятся к эмбеддингам. Она выпущена под лицензией Apache-2.0, поддерживает английский и китайский языки и нацелена непосредственно на агентные нагрузки: агенты для кода, офисная автоматизация, использование инструментов, работа с терминалом. Технический отчет (arXiv 2607.22083, от 24 июля 2026 года) описывает предварительное обучение с нуля на 28 триллионах токенов, за которым следует методика SFT и трехэтапного RL, построенная на взаимодействии с реальной средой. Контекстное окно достигает 262 144 токенов. Все это проверяемо.

Необычной является архитектура. Nanbeige4.2-3B использует «Looped Transformer» («зацикленный трансформер»): один и тот же стек из 22 слоёв трансформера запускается дважды, поэтому модель с 3B параметров выполняет примерно вдвое больше вычислений на токен, чем обычная модель с 3B параметров, не добавляя при этом весов. Именно так лаборатория примиряет малое число параметров с заявленными в бенчмарках результатами, дотягивающимися выше её весовой категории: модель фактически получает второй проход по собственным представлениям, а конфигурация выражает это повторное использование как num_loops = 2 поверх 22 скрытых слоёв (44 эффективных этапа внимания). Расплата в том, что каждому инференс-движку приходится объяснять, как работать со стеком слоёв, используемым дважды: как индексировать внимание для KV-кэша и CUDA-графов, как задавать размер кэша, как потоково подавать веса. Стандартный движок, построенный вокруг трансформеров с одним прямым проходом, понятия не имеет, что с этим делать, — именно поэтому собственный код модели поставляется в составе репозитория и требует trust_remote_code=True в Hugging Face Transformers.

Именно в этом пользовательском коде живут и самые грубые грани модели. Независимый отчёт (arXiv 2608.13987, середина августа) зафиксировал пять ошибок, которые мешали опубликованному чекпойнту загружаться из коробки в Hugging Face Transformers, — среди них молча обнуляемый буфер rotary-position-embedding и вызовы удалённых API кэша, — а в статьях сообщества описывались обходные пути вроде use_cache=False, пока модель вообще не начинала работать. Эти проблемы были устранимы, и пропатченные чекпойнты с обвязками уже распространяются, но важна закономерность: это продуманная архитектура, которая с первого дня платит необычный налог трением при развёртывании.

Числа, поставщик и независимый

Главное заявление о производительности, взятое прямо из технического отчёта, состоит в том, что Nanbeige4.2-3B превосходит более крупные открытые модели — Qwen3.5-9B и Gemma4-12B — в агентных оценках. Флагманский показатель — SWE-Bench Verified: 63,6 против 53,1 у Qwen3.5-9B и 44,2 у Gemma4-12B. В отчёте также указаны GPQA-Diamond — 87,4, HMMT-Feb-2026 — 82,8, Terminal-Bench 2.0 — 44,1 и SWE-Bench Pro — 46,9. Ни один из этих результатов не был независимо воспроизведён на выбранном вендором стенде, и их следует читать как собственную оценку лаборатории своей модели — ту же оценку, которую карточка модели резюмирует как первое место в рейтинге малых моделей Artificial Analysis.

Самое близкое к независимой проверке на данный момент исходит совсем с другой стороны. В ходе бенчмарка на устройстве Artificial Analysis × Liquid AI, запущенного на iPhone 17 Pro и опубликованного в конце августа, 4-битная сборка Nanbeige4.2-3B разделила первое место по среднему баллу среди 33 работающих моделей объёмом менее 8 ГБ при контексте 16K (63 — вровень с LFM2.5-2.6B и впереди нескольких моделей класса 9B), а при контексте 64K набрала 65 — второй результат после 66 у Ling 3.0 Tiny. Её профиль по отдельным тестам был поразительным: лучший результат в категории на MATH-500 (96%) и сильный результат в вызове функций (76% на BFCL), но слабая доля ответов без галлюцинаций — 33% на AA-Omniscience — и, что решающе для реального использования, медленность. Она генерировала примерно 14 токенов в секунду и отвечала на промпт из 1 024 токенов за 21,4 секунды, используя 4,0 ГБ; при ограничении времени ответа 60 секундами её средний балл рухнул с 63 до 18. Иными словами: качество, превосходящее модели класса 9B, реально, и реальна также цена петлевой архитектуры, которая его обеспечивает.

Что на самом деле дает поддержка апстрима

Сложите два апстрим-события вместе — и практическая картина для самохостера становится очевидной. Если вы используете SGLang, Nanbeige4.2-3B уже обслуживается из стандартной установки на основе поддержки, слитой в основную ветку, — без форка, а парсеры вызовов инструментов и рассуждений модели подключены к тем же детекторам qwen3, которые SGLang уже поставляет. Если вы используете vLLM, стандартная поддержка — в одном мерже: строка реестра направляет модель в бэкенд transformers, конвертер архитектуры правильно определяет размер кэша, а парсеры рассуждений и вызовов инструментов qwen3 переиспользуются — именно так работает совместимая с OpenAI поверхность вызова инструментов.

Честное предупреждение: путь vLLM — это путь совместимости, а не оптимизации. Запуск NanbeigeForCausalLM через TransformersForCausalLM означает, что vLLM выполняет собственный код модели Hugging Face в своём serving-слое, а не нативную реализацию с кастомными ядрами и обработкой CUDA-graph, — именно это различие SGLang выбрал реализовать нативно. Для модели 3B, затраты на каждый токен которой уже удваиваются из-за цикла, маршрут на базе transformers вряд ли окажется самым быстрым из возможных путей обслуживания, а история из пяти багов нижележащего пользовательского кода означает, что этот путь наследует все оставшиеся в нём странности. Для агентных рабочих нагрузок, где корректность вызовов инструментов и поведение с длинным контекстом обычно важнее сырых токенов в секунду, это может быть приемлемым компромиссом; для чувствительного к задержкам чата стоит провести бенчмаркинг, прежде чем доверять ему продакшн-путь. И два движка всё ещё доступны только через форки: llama.cpp и Ollama продолжают указывать на ветки Nanbeige, а встроенный сервер llama.cpp в LM Studio пока не поддерживает эту архитектуру.

Что посмотреть дальше

Есть три вещи, каждая из которых изменила бы картину. Во-первых, PR в vLLM должен быть смёржен и войти в релиз — следите за тредом и примечаниями к релизам vLLM; ревьюеры уже отметили, что до готовности к мержу остаются запись в документации и маппинг CI-чекпоинтов. Во-вторых, посмотрим, переживёт ли ревью конвертер количества слоёв, поскольку мейнтейнеры полагают, что PR #54941 мог сделать его избыточным, — признак того, насколько это обходное решение — лишь леса вокруг зацикленной архитектуры. В-третьих, следите за вопросом о хостинг-провайдере: на карточке Hugging Face сейчас не указан ни один инференс-провайдер, обслуживающий эту модель, и мы её тоже не хостим, так что на сегодняшний день это история про самостоятельный хостинг. Когда провайдер добавит её в каталог, маршрутизационная часть превратится в рутину: один API поверх большого каталога моделей, где цены провайдера по прайс-листу передаются без наценки, — это самый простой способ провести A/B-тест самостоятельно размещённой Nanbeige4.2-3B против хостинговых моделей, которые она, как утверждается, превосходит. А пока что веха, которую стоит отметить, — та, что только что произошла: через шесть недель после запуска, который каждый крупный рантайм встретил пожатием плеч и форком, два из них теперь обслуживают Nanbeige4.2-3B из немодифицированной установки.