南北阁发布 33B 开放编程模型

Nanbeige4.3-33B 把重点放在了能调用工具、连续执行任务的编程 Agent 上：33B 稠密参数、512K 上下文，采用 Apache 2.0 许可，还提供可继续训练的 Base 版本。它在官方自测的 20 项评测中领先 17 项，但部分竞品成绩与对应模型卡冲突。

对前端和全栈开发者，这条消息值得关注的地方有两个：开源编程 Agent 多了一个候选；长上下文、自测高分和实际部署成本之间，仍然有不少距离。

它想解决的是连续干活，而不只是生成代码

Nanbeige LLM Lab 来自 BOSS Zhipin。按实验室的定位，Nanbeige4.3-33B 既面向 agentic coding，也面向办公协作类的 cowork 任务。前者强调模型围绕目标调用工具、处理反馈、继续修改，后者覆盖自动化和工作任务执行。

这也是聊天模板里三个控制项的意义。enable_thinking 控制是否启用推理，默认开启；preserve_thinking 保留之前轮次的推理内容，官方推荐在多轮工具调用和代码 Agent 中使用；传入 tools 可以启用工具调用，并推荐 XML 调用格式。

保留此前推理，是为了让多轮执行有更连续的上下文。但原文没有给出开启前后的对照数据，不能据此断言任务成功率一定提高。

模型本身采用标准 LlamaForCausalLM 架构，没有 MoE 专家路由，每生成一个 token 都会运行全部 33B 参数。它有 52 层，隐藏维度 7,168，采用 56 个查询头、8 个键值头的分组查询注意力，单头维度 128；FFN 中间维度为 22,016，词表包含 166,912 个 token。RoPE theta 为 120,000,000，最大位置数为 524,288。

这些配置说明了它的结构，不能单独证明编程能力。实验室的路线是先做强「教师模型」，再把 Agent 能力蒸馏到更小的模型，计划从 Nanbeige4.3-3B 开始。小模型的实际效果，原文尚未提供。

领先 17 项，为什么还不能直接排第一

官方比较对象是 Qwen3.8-27B、Muse-Glimmer-30B 和 Gemma4-31B。原文称，各模型都使用最高推理强度，共享超参数和评测框架。这样的设置有比较价值，但这些成绩全部来自 Nanbeige 自报，不能当成独立验证。

最突出的结果是 Terminal-Bench 2.1：Nanbeige 得到 80.9，Qwen3.8-27B 为 73.0；DeepSWE 的差距更大，为 65.5 对 42.5。不过，Terminal-Bench 4.0 上它只有 23.8，Gemma4-31B 为 0.0。不同版本的任务难度和评测条件需要分别理解，不能把这些分数当成同一把尺子。

办公协作方面，它在 Automation Bench 得到 54.2，对照成绩为 38.3；JobBench 为 44.8 对 34.5。YC-bench 的模拟收益达到 $1,025,437，对照为 $641,290。这里的收益属于模拟评测，不能推算成团队采用后的收入。

推理成绩包括 AIME 2026 的 95.2 和 AA-LCR 的 84.0。它也有明确落后项：SWE-Bench Pro 为 60.3，低于 Qwen3.8-27B 的 61.7；GDPval 为 84.8，对方为 86.4；GPQA Diamond 为 89.5，低于表中 Gemma4-31B 的 91.3。

问题出在部分对照数据上。Meta 模型卡列出的 SWE-Bench Pro 成绩，Muse-Glimmer-30B 是 51.2、Gemma4-31B 是 36.9，Nanbeige 的表格却把这两个数反了过来。Google 公布的 Gemma4-31B GPQA Diamond 是 84.3，Nanbeige 表中则为 91.3。Muse-Glimmer-30B 的 Terminal-Bench 2.1 也有 51.7 与 61.8 的差异。

评测框架可以解释部分差距，疑似交换数据则需要进一步核实。「领先 17 项」可以作为试用理由，暂时不足以支持确定排名。

512K 能装下很多内容，显存也要跟上

模型卡提供 Transformers、SGLang 和 vLLM 部署方案，服务端示例采用 4 路张量并行，并使用 Qwen3 推理解析器和工具调用解析器。解析器名称是服务配置的一部分，不代表模型采用 Qwen3 架构。

推荐参数分为两类：Agent 任务使用 temperature 1.0、top_p 0.95，最大新增 token 为 65,536；推理和聊天使用 temperature 0.6，最大新增 token 为 262,144。输出上限和上下文窗口不是同一个概念，配置时需要分别看待。

按照原文基于配置的计算，BF16 权重约占 66 GB。KV cache，也就是推理过程中保存历史 token 键值的缓存，每个 token 约需 208 KiB；完整 524,288-token 序列对应的缓存约为 112 GB。这些是配置推算，原文没有提供实测峰值显存、吞吐和延迟。

512K 是容量上限，不是低成本运行的承诺。

文章发布时仅列出 1 个社区量化版本，也没有 Hugging Face Inference Provider 托管。对个人开发者，下载权重之后能否顺畅使用，仍取决于硬件和服务配置。

我的判断

这个模型值得进入自部署编程 Agent 的候选名单。Apache 2.0、文本输入、工具调用控制和长上下文，都是清楚的产品取舍。Nanbeige4.3-33B-Base 还在自报的 8 项任务中全部超过 Gemma4-31B-Base，包括 MMLU-Pro 的 66.9 对 59.3、GPQA 的 62.0 对 41.5，但这只能支持继续训练方向的评估，不能替代最终 Agent 测试。

我更在意两个缺口：竞品表格存在冲突，部署部分缺少实测成本。与继续使用团队已有的托管模型相比，自部署是否划算，原文没有对照数据。与更小的量化模型相比，它多消耗的显存能换来多少任务完成率，也没说清。

因此，官方榜单适合筛选候选，真实仓库任务才适合决定是否切换。

能拿来做什么

• 给现有 AI 编程流程增加一个候选，用同一批前端或 Node 仓库任务比较修改正确性、测试结果、执行时间和资源消耗。
• 做多轮工具调用时，按官方建议评估 preserve_thinking，同时检查 XML 工具调用格式能否被现有 Agent 框架正确解析。
• 部署前分别估算权重和 KV cache，先按实际任务长度配置上下文与输出上限，再决定是否需要完整 512K。
• 有定制训练需求时评估 Base 版本；需要小模型时，等待 Nanbeige4.3-3B 的实际结果，不把教师模型成绩直接套过去。