Nanbeige4.2-3B vLLM支持即将落地：BOSS直聘的Looped 3B智能体模型告别仅限Fork时代

Nanbeige4.2-3B —— BOSS Zhipin旗下Nanbeige实验室于2026年7月下旬发布的紧凑型智能体模型 —— 即将首次能够在原生vLLM安装上提供服务。2026年9月9日提交的一个拉取请求通过transformers后端将该架构添加到了vLLM的模型注册表中。如果该请求成功合并，vllm serve Nanbeige/Nanbeige4.2-3B将成为一条原生命令，而不再是依赖厂商分支的例行流程。这对自托管用户来说是一个实质性的变化：自该模型发布以来的六周里，其模型卡片列出的每一个推理引擎 —— vLLM、SGLang、llama.cpp、Ollama —— 指向的都是Nanbeige维护的分支，而非未经修改的安装。

模型本身并不是新闻；自7月最后一周起它就可以下载了。新闻在于，仅靠fork的时代正在结束，而且就在本周结束。SGLang于9月5日将Nanbeige4.2的原生实现合并到其主分支，vLLM的拉取请求则在四天后提出。两者都是上游的、开箱即用的支持，针对的是一个此前每个引擎都视为特例的架构。下面，所有内容都标注清楚：这些拉取请求实际做了什么，哪些已经过验证、哪些仍然开放，供应商的基准测试声明，以及将它们置于背景中的独立数据。

确切地说，这周发生了什么变化？

该 vLLM 拉取请求是 vllm-project/vllm #56071，题为"[Model] Add support for Nanbeige4.2 (transformers backend)"，由一位 Nanbeige 工程师于 9 月 9 日提出，截至撰写本文时仍处于开放状态。它刻意保持精简——仅涉及两个文件。第一个文件在 vLLM 的模型注册表中添加了一行，将 Hugging Face 架构名称 NanbeigeForCausalLM 映射到 TransformersForCausalLM——这是 vLLM 的通用回退方案，通过 transformers 后端运行模型。第二个文件添加了一个 NanbeigeModelArchConfigConvertor，其唯一职责是告知 vLLM 需要预留多少层：它返回配置中的 num_hidden_layers 乘以 num_loops 的结果，因为 Nanbeige 的循环 transformer 会重复其层栈，vLLM 必须据此调整其 KV-cache 和注意力实例的规模。

对于任何关注此事的人来说，审查线程中有两个细节值得注意。首先，注册表映射是让模型自动通过 transformers 后端运行的机制——一位 vLLM 维护者指出，一旦该映射存在，显式的 `--model-impl transformers` 标志就变得多余，而合并前剩余的工作只是一个文档条目和一个 CI 测试注册表映射。其次，审查者指出，最近合并的一个 vLLM 变更（PR #54941）可能已经使层数转换器变得不必要，因为它直接检测注意力模块，而不是从层数推断它们。简而言之：这个修复在落地之前可能会变得更简单，而不是更复杂。

vLLM 路径之所以重要，更多在于它不是什么。这并非首次尝试将 Nanbeige4.2 原生集成到 vLLM 中。PR #49433 由同一位工程师于 7 月底提交，作为随模型发布当日即推出的原生实现，最终于 9 月 9 日被关闭——恰与 transformers 后端 PR 出现在同一天——原因是维护者认为，定制模型实现所需的工作量超出了该架构本身所值的程度，并转而指向 transformers 后端。读者需要记住的要点是：上游 vLLM 支持正通过兼容路线到来，而非手工调优的原生实现，这一区别对性能有着实际影响，下文将详细讨论。

需要所有这些特殊处理的模型

要理解为什么Nanbeige4.2-3B打破了每个运行时的假设，了解这个模型是什么会很有帮助。它是一个大约40亿参数的模型，其中非嵌入参数为30亿，以Apache-2.0许可证发布，支持英文和中文，目标明确地针对智能体工作负载：代码智能体、办公自动化、工具使用、终端操作。技术报告（arXiv 2607.22083，日期为2026年7月24日）描述了从零开始在28万亿个token上进行预训练，然后采用围绕真实世界环境交互构建的SFT加三阶段强化学习方案。上下文窗口长达262,144个token。所有这些都是可以核实的。

不平凡之处在于架构。Nanbeige4.2-3B 使用了一种“Looped Transformer”（循环Transformer）：同一组 22 层 Transformer 层堆叠被运行两次，因此一个 3B 参数的模型每 token 的计算量大约是一个常规 3B 模型的两倍，同时不增加任何权重。这正是该实验室以小参数量支撑起超出其体量的基准测试成绩的方式——模型实质上对自身的表征进行了第二次遍历，而配置将该复用表示为 num_loops=2，作用于 22 个隐藏层（即 44 个有效注意力阶段）。代价是，每个推理引擎都必须被告知如何处理一个被使用两次的层堆叠：如何为 KV 缓存和 CUDA 图索引注意力，如何确定缓存大小，如何流式传输权重。一个围绕单次前向传播 Transformer 构建的标准引擎完全不知道该如何处理它，这正是自定义建模代码随仓库一起提供、并且需要在 Hugging Face Transformers 中设置 trust_remote_code=True 的原因。

那段自定义代码也正是该模型最粗糙之处的所在。一份独立报告（arXiv 2608.13987，八月中旬）记录了五个缺陷，导致发布的检查点无法在 Hugging Face Transformers 中开箱即用地加载——其中包括一个被静默归零的旋转位置嵌入缓冲区，以及对已移除缓存 API 的调用——社区文章也描述了种种变通方法，例如设置 use_cache=False 后模型才能运行。这些问题都是可以修复的，修补后的检查点和测试工具现在已在流传，但关键在于这种模式：这是一个精巧的架构，却从第一天起就在部署摩擦方面付出了不寻常的代价。

数字、供应商和独立

{{1}}直接取自技术报告的头条基准测试结论是：Nanbeige4.2-3B 在智能体评测中优于更大的开源模型——Qwen3.5-9B 和 Gemma4-12B。{{/1}} {{2}}最核心的数据是 SWE-Bench Verified 得分 63.6，而 Qwen3.5-9B 为 53.1，Gemma4-12B 为 44.2。{{/2}} {{3}}报告还列出 GPQA-Diamond 得分 87.4、HMMT-Feb-2026 得分 82.8、Terminal-Bench 2.0 得分 44.1 以及 SWE-Bench Pro 得分 46.9。{{/3}} {{4}}这些结果均未在厂商选定的测试框架上被独立复现，因此应将其视为实验室对其模型的自我说明——模型卡也正是以这一说明将该模型总结为位居 Artificial Analysis 小型模型排行榜榜首。{{/4}}

迄今为止，最接近独立验证的结果完全来自另一个层面。在8月下旬发布的一项于iPhone 17 Pro上运行的Artificial Analysis × Liquid AI设备端基准测试中，Nanbeige4.2-3B的4-bit量化版本在33款可运行的8GB以下模型中，以16K上下文取得并列最高的平均分（63分，与LFM2.5-2.6B持平，并领先数款9B级模型）；在64K上下文下则拿下65分，仅次于Ling 3.0 Tiny的66分。其分项测试表现令人瞩目：在MATH-500上全场最佳（96%），函数调用表现强劲（BFCL为76%），但在AA-Omniscience上非幻觉率仅为33%，较为薄弱——而对实际使用具有决定性意义的是：速度慢。它每秒约生成14个token，回答一个1,024 token的提示词需耗时21.4秒、占用4.0 GB内存；在60秒回答时限下，其平均分从63分骤降至18分。换言之：能击败9B模型的质量是真实存在的，而产生这种质量的循环架构所带来的代价也同样真实。

上游支持实际上能给你带来什么

将这两个上游事件放在一起看，对自托管用户来说，实际情况就直截了当了。如果你运行 SGLang，Nanbeige4.2-3B 已经可以从合并后的主分支支持的标准安装中直接提供服务——无需 fork，模型的工具调用和推理解析器已接入 SGLang 自带的同一套 qwen3 检测器。如果你运行 vLLM，标准支持只差一次合并：注册表行将模型路由到 transformers 后端，架构转换器正确设置缓存大小，并复用 qwen3 的推理和工具调用解析器——这正是与 OpenAI 兼容的工具调用接口的工作方式。

需要坦诚说明的是，vLLM的路线是一条兼容路径，而非经过调优的路径。通过TransformersForCausalLM运行NanbeigeForCausalLM，意味着vLLM在其服务层内执行模型自身的Hugging Face代码，而不是采用带有自定义内核和CUDA图处理的原生实现——这正是SGLang选择原生构建的差异所在。对于一个单token成本已被循环翻倍的3B模型而言，transformers后端路线不太可能成为最快的服务路径；而且底层自定义代码已有五处bug的历史，意味着该路径会继承其中残留的各种怪癖。对于智能体工作负载，工具调用的正确性和长上下文行为通常比原始每秒token数更重要，因此这或许是可以接受的权衡；但对于延迟敏感的聊天场景，在将生产路径押注于它之前，值得先做基准测试。另外还有两个引擎仍然仅支持分支版本：llama.cpp和Ollama仍指向Nanbeige分支，LM Studio中捆绑的llama.cpp服务器尚不支持该架构。

接下来看什么

有三件事都会改变局面。首先，vLLM 的 PR 需要合并并随一个版本发布——持续关注该讨论串和 vLLM 的发布说明；审阅者已指出，合并前还差一个文档条目和一个 CI 检查点映射。其次，看看层数转换器能否顺利通过审阅，因为维护者认为 PR #54941 可能已经让它变得多余——这正说明这个变通方案中有多少是围着循环架构搭的脚手架。第三，关注托管提供商的问题：Hugging Face 卡片目前没有显示任何推理提供商在服务该模型，我们这边也不托管，所以现在它只能自托管。一旦有提供商把它列入目录，路由那一侧就变成常规操作——用一个大模型目录共享的 API，把提供商标价原样透传、不加价，就能以极低的摩擦对自托管的 Nanbeige4.2-3B 和它所声称击败的托管模型做 A/B 测试。在那之前，值得记下的里程碑是刚刚发生的这一点：发布六周时，所有主流运行时最初都只是耸耸肩、分叉了事，如今其中两个已经能用一次未作改动的安装来服务 Nanbeige4.2-3B。