Nanbeige4.3-33B 解读：512K 上下文的开权重 Agent 模型，编程与办公表现如何？

Nanbeige 发布了 Nanbeige4.3-33B，把重点放在需要多轮推理、调用工具和交付成果的 Agent 工作上。它在官方对比中的终端操作、代码任务与办公自动化表现值得关注，但这并不意味着它在所有项目上领先，也不代表普通消费级显卡就能轻松跑满 512K 上下文。

本文依据截至 2026 年 10 月 26 日可查的官方模型卡与配置文件整理。下文分数均为发布方报告，并非 TboxIO 独立实测；部署内存估算也不等于实机测试结果。

它是什么：先做强教师模型，再蒸馏小模型

Nanbeige4.3-33B 是 Nanbeige4.3 系列的旗舰教师模型，目标是在约 30B 参数档位提供较强的编程与专业办公 Agent 能力，再为后续小模型蒸馏提供基础。官方提到了 Nanbeige4.3-3B 的后续计划；这不能理解为 3B 版本已经随本次一起发布，也不能把 33B 的分数套到未来小模型身上。

与只回答问题的聊天模型相比，这一定位更强调连续工作：理解任务、处理代码仓库、运行工具、读取反馈，再修正方案。对于希望自托管代码助手或办公助手的团队，它提供了一个可以评估的开权重候选。

项目	官方信息与解读
模型	Nanbeige4.3-33B
规模与结构	约 33B 参数，配置为 LlamaForCausalLM 稠密架构
上下文上限	524,288 tokens，即 512K
权重精度	BF16
许可证	Apache 2.0
主要方向	Agent 编程、工具调用、专业办公协作
官方运行示例	Transformers、SGLang、vLLM
思考模式	默认启用，可通过模板参数关闭

这里的 33B 与 MoE 模型的“总参数 / 每 token 激活参数”不是同一种成本描述。它是稠密模型，不能按少量激活专家模型的推理负担来估计。512K 也只是上下文容量上限，不保证在所有长度、任务和硬件上都维持同样的质量与速度。

官方跑分：编程与办公较强，但并非全胜

官方将它与 Qwen3.8-27B、Muse-Glimmer-30B 和 Gemma4-31B 放在同一张表中比较，说明各模型使用最高思考强度，并在每项基准内使用相同的推理超参数和测试框架。以下保留部分代表项目的原始分数，便于直接核对。

基准	Nanbeige4.3-33B	Qwen3.8-27B	Muse-Glimmer-30B	Gemma4-31B
Terminal-Bench 2.1	80.9	73.0	61.8	47.2
Terminal-Bench 4.0	23.8	6.3	1.6	0.0
DeepSWE	65.5	42.5	4.4	2.7
SWE-Bench Pro	60.3	61.7	36.9	51.2
SWE-Atlas-QnA	50.8	41.9	17.7	3.3
NL2Repo	53.0	48.3	27.4	33.8
SkillsBench	61.1	56.4	39.7	28.9
Automation Bench	54.2	38.3	15.2	9.7
JobBench	44.8	34.5	16.6	9.0
GDPval	84.8	86.4	75.8	71.4
Claw-Eval pass^3	78.3	75.2	57.3	44.2
Toolathlon-Verified	70.4	68.5	47.2	27.8
GPQA Diamond	89.5	89.2	83.5	91.3
AIME 2026	95.2	94.5	94.7	89.2
AA-LCR	84.0	82.0	83.3	72.0

这组结果说明它有成为 Agent 候选的理由，同时也给出了选择边界：

• 终端与复杂代码任务突出：相对 Qwen3.8-27B，Terminal-Bench 2.1 高 7.9 分，DeepSWE 高 23.0 分。不过，Terminal-Bench 4.0 的 23.8 也提醒我们：更困难的任务仍有大量失败空间。
• 办公任务值得关注：Automation Bench 高 15.9 分，JobBench 高 10.3 分；这反映的是指定评测工作流表现，不能直接等同于企业真实流程的自动化成功率。
• Qwen 仍有领先项目：SWE-Bench Pro 中 Nanbeige 为 60.3，低于 Qwen 的 61.7；GDPval 为 84.8，也低于 Qwen 的 86.4。
• 通用推理不是全面压倒：GPQA Diamond 的 89.5 略高于 Qwen 的 89.2，但低于 Gemma4-31B 的 91.3。0.3 分的小差距不宜放大成稳定能力优势。

这些都是同表的分数差，不是相对于上一代 Nanbeige 的提升比例。当前引用的模型卡没有提供完整的上一代同条件对照，因此本文不编造“提升多少倍”的结论。与本站前几篇 DeepSeek、MiniMax、Kimi 或 Raon 文章比较时，也应先对齐基准版本、Agent 框架和推理预算。

读跑分，必须一起看测试条件

Agent 测试的结果不仅取决于模型，也受工具、执行环境、上下文策略和重试预算影响。官方脚注中有几项会直接影响解读：

1. Nanbeige 的评测启用了 preserve_thinking=true，即保留历史轮次的思考内容。实际接入时若默认清掉这些信息，多轮 Agent 的行为可能不同。
2. Terminal-Bench 2.1 使用 Terminus 2；Terminal-Bench 4 与 DeepSWE 使用 mini-swe-agent v2.4.6。不同版本的 Terminal-Bench 分数不应直接拼成一张跨文章排行榜。
3. SWE-Atlas-QnA 使用 mini-swe-agent v2.4.6，并用 GPT-6 Sol、medium reasoning effort，依据 1,304 条任务专属评分规则评判；NL2Repo 使用 Claude Code，JobBench 则使用带搜索工具的 Claude Code 框架。
4. Automation Bench v1.0.6 包含 600 个公开任务。Claw-Eval 仅评测 General 子集的 157 个单轮用户交互任务，而且指标是 pass^3，应保留这一标记。
5. GDPval 使用修订后的评分规则，表中的 84.8 不能改写成 Elo 分数。Toolathlon-Verified 未限制单次请求的 max_tokens，因此成本比较还要看实际 token 消耗。

官方另外报告 YC-bench 为 1,025,437 美元，但这是基准中的美元计价结果，不是模型收费、真实营收或使用者的收益承诺。我们不把它与百分比类分数混算。

思考与工具调用：两个开关各管一件事

模型模板提供 enable_thinking 和 preserve_thinking，二者容易被混淆。

enable_thinking 控制当前回复是否生成推理内容，默认开启，设为 False 可切换非思考模式。preserve_thinking 控制多轮对话中是否保留此前助手的思考；官方对普通聊天与问答建议 False，对多轮工具调用、办公和代码 Agent 建议 True。

官方还建议工具调用优先使用 tool_call_format="xml"，同时提供 json 兼容格式。接入现有 Agent 时，需要确认模板、工具调用解析器、思考内容的保存方式相互一致，不能只把模型名称替换掉就认为结果等同于官方评测。

场景	Temperature	Top_p	官方建议 Max New Tokens
Agent 与工具任务	1.0	0.95	65,536
推理与聊天	0.6	0.95	262,144

Max New Tokens 是输出预算，512K 是上下文上限，两者并不等同。输入、历史思考、工具返回内容和新输出需要共同满足服务端上下文约束；较高输出上限也不意味着每个请求都会生成那么长。

本地部署：BF16 权重约 66GB，长上下文还要另算

官方仓库文件页显示约 66.3GB，提供 BF16 Safetensors 权重。按 33B 参数、每参数 2 字节粗算，权重本身约需 66GB 十进制存储；这还没有计入 KV cache、运行时缓冲和框架开销。仓库大小不等于完整运行时显存需求。

从官方配置看，模型有 52 层、8 个 KV heads、head_dim 为 128。若使用朴素的 BF16 KV cache，单条序列填满 524,288 tokens，按 K 与 V 两份缓存估算约需 104GiB KV cache。这是根据配置做的理论估算，不是官方硬件实测；缓存精度、并行切分、卸载和运行时策略会改变实际占用。

因此，不宜把“支持 512K”解读为“普通单卡就能轻松使用 512K”。量化可能降低权重开销，但仍需核验转换质量、框架兼容性与长上下文表现。本文没有进行量化版本或 Mac 的速度测试，也没有依据可以承诺某张消费显卡的每秒输出速度。

官方 SGLang 和 vLLM 示例均采用 4 路张量并行，使用 qwen3 reasoning parser 与 qwen3_coder tool-call parser。这是示例配置，不是所有部署的最低卡数要求。实际选型应先根据目标输入长度、并发量、首 token 延迟和输出速度做容量测试，再决定 GPU 配置。

适合谁，什么时候值得尝试？

如果你的重点是可自托管的代码 Agent、带工具的办公流程，或者想研究教师模型与后续小模型蒸馏，这次发布值得加入候选列表。Apache 2.0 许可证为使用和改造提供了较清晰的许可基础，具体分发仍应遵守对应许可证要求。

如果你主要需要日常聊天、极低延迟或小显存单机体验，33B 稠密模型的资源成本需要认真衡量。模型卡没有给出可直接用于商业预算的官方 API 单价或统一吞吐测试；开权重也不等于推理免费，托管 GPU、存储和维护都需要成本。

建议用你自己的代码仓库和办公任务做小规模验证，同时记录完成率、工具调用错误、token 消耗、延迟与人工修正次数。涉及实际文件或业务系统的 Agent，可先在隔离测试环境中评估其工具行为。

TboxIO 的判断：Nanbeige4.3-33B 的看点是把较强的编程与办公 Agent 表现放进可自托管的 33B 模型中。官方结果支持“值得评估”，尚不足以支持“所有任务最强”或“部署一定更省钱”。

参考来源

• Nanbeige 官方模型卡：定位、评测表、脚注与运行指南
• 官方 config.json：架构、层数、KV heads 与上下文配置
• 官方仓库文件列表：BF16 权重与文件大小