AI 快讯Nanbeige 33B开源:专教小Agent
模型上新

Nanbeige 33B开源:专教小Agent

2026-10-25T20:03:22.458Z
Nanbeige 33B开源:专教小Agent

Nanbeige4.3-33B 以 Apache 2.0 协议开放权重,提供 512K 上下文,并被定位为后续 3B Agent 的教师模型。其终端任务成绩突出,但软件工程基准并未全面领先。

Nanbeige 33B开源:专教小Agent

截至 2026 年 10 月 25 日,Nanbeige LLM Lab 近日发布了 Nanbeige4.3-33B,开放 Apache 2.0 权重,并在官方模型卡中标注支持 512K token 上下文窗口。这次发布最值得关注的不是又多了一个 30B 级开源模型,而是团队明确把它定位成后续小型 Agent——包括计划推出的 3B 模型——的教师模型。

**Agent 教师模型是用于生成推理轨迹、工具调用过程和训练反馈,再将能力蒸馏给更小模型的大模型。**它不一定是线上部署最便宜的选择,但可以充当“高级教练”:先完成复杂任务并留下过程数据,再让 3B、7B 等更小模型学习如何规划、调用工具、处理失败和继续执行。

这一路线比单纯追求聊天跑分更贴近 2026 年的 Agent 竞争。真正能否落地,取决于模型在几十轮乃至数百轮工具调用中能不能保持状态,而不只是单轮回答一道数学题。

Nanbeige4.3-33B、512K上下文与小型Agent蒸馏关系示意图

先看结论:它在终端任务上亮眼,但不是全面碾压

**Nanbeige4.3-33B 的官方成绩呈现出明显的能力偏向:终端 Agent 任务强,软件工程任务并未全面领先。**根据发布团队公布的结果,在相同基准所采用的评测框架和推理设置下,它在 Terminal-Bench 2.1 上取得 80.9 分,对照模型 Qwen3.8-27B 为 73.0 分;但在 SWE-Bench Pro 上,Nanbeige4.3-33B 得分 60.3,低于后者的 61.7。

| 模型 | 参数规模 | 开放方式 | 上下文窗口 | Terminal-Bench 2.1 | SWE-Bench Pro | 主要定位 | |---|---:|---|---:|---:|---:|---| | Nanbeige4.3-33B | 33B | Apache 2.0 权重 | 512K | 80.9 | 60.3 | Agent 教师模型、终端与工具调用 | | Qwen3.8-27B | 27B | 以对应版本官方条款为准 | 未在本次材料中统一披露 | 73.0 | 61.7 | 对照模型、通用 Agent 与编码 |

**Terminal-Bench 2.1 是衡量模型能否在真实终端环境中操作命令、文件和软件工具的 Agent 基准。**Nanbeige4.3-33B 在该基准上领先 7.9 分,按 73.0 的基线计算相对增幅约为 10.8%,说明它至少在发布方采用的终端任务配置中展现出了竞争力。

**SWE-Bench Pro 是面向真实代码仓库的软件工程修复基准,考验模型定位问题、理解跨文件依赖并提交有效补丁的能力。**Nanbeige4.3-33B 在这项测试中落后 1.4 分,说明终端操作能力和仓库级修复能力不能直接画等号:会熟练使用 shell、搜索文件和运行测试,并不意味着一定更擅长理解大型项目中的隐性约束。

**这两组结果都来自发布团队,目前不能视为独立复现结论。**模型卡成绩适合判断训练方向,却不适合直接充当采购或部署排行榜;在第三方使用相同容器、任务超时、采样参数和 token 预算复测之前,80.9 更准确的含义是“值得测试”,而不是“已经确定领先”。

512K 上下文很大,但不能简单等同于能读懂整个仓库

**上下文窗口是模型在一次推理过程中能够接收和处理的最大 token 总量。**Nanbeige4.3-33B 标注的 512K 上下文,理论上可以容纳大型代码仓库的关键文件、长时间 Agent 历史、工具返回结果和多轮推理记录,容量约为常见 128K 上下文模型的 4 倍。

**512K 的实际价值主要体现在减少上下文裁剪,而不是取消检索系统。**一个持续执行数百轮的 Agent 会不断积累命令输出、报错日志、网页内容和中间计划,较小窗口往往需要频繁总结历史;窗口扩大后,系统可以保留更多原始证据,降低总结过程中丢失文件名、参数和异常栈细节的概率。

**长上下文容量不代表长上下文质量。**模型即使能够接收 512K token,也可能在信息位于中段时出现召回下降,或者被重复日志和无关文件干扰;真正有意义的验证应包括不同信息位置上的检索准确率、跨文件推理成功率,以及上下文从 32K 扩展到 512K 后的任务收益曲线。

**512K 推理的成本也不应被参数表掩盖。**33B 参数仅按 BF16 权重粗略计算就约需 66GB 显存,INT8 权重约为 33GB,4-bit 权重约为 16.5GB;这些数字还没有计入 KV Cache、激活值和推理框架开销。实际跑满 512K 上下文时,KV Cache 往往会成为主要显存压力,具体占用还取决于模型层数、注意力头结构、缓存精度和推理引擎实现。

**开发者不应该默认把 512K 全部塞满。**更现实的部署方式仍是代码索引、语义检索、日志压缩和上下文缓存组合使用,只把当前任务最相关的文件和历史轨迹交给模型;超长窗口更像安全余量,而不是鼓励把整个文件系统无差别复制进提示词。

preserve_thinking=true 是理解成绩的关键

**preserve_thinking=true 是在多轮交互中保留模型先前推理内容,使后续轮次能够继续利用既有思考轨迹的配置。**Nanbeige4.3-33B 模型卡建议在多轮工具使用场景启用这一设置,但不建议把它机械地用于普通聊天。

**保留历史推理可能显著改变 Agent 的行为方式。**例如,模型在第一轮判断“测试失败来自依赖版本”,第二轮查询包信息,第三轮修改配置;如果先前思考被删除,它可能重新排查一次并重复调用工具,而保留推理则有机会让模型沿着原计划继续执行。

**保留推理也会增加 token 消耗和上下文污染风险。**早期判断一旦出错,后续步骤可能持续围绕错误假设展开;随着轨迹变长,历史推理还会占用上下文,并影响首 token 延迟、总体生成时间和推理费用。对于重复性强的客服问答或普通对话,保留全部思考未必比保留结构化摘要更有效。

**Agent 基准必须在相同思考保留策略下比较才有意义。**如果一个模型保留完整历史推理,另一个模型每轮只看到工具结果,两者即使拿到同样的任务成功率,实际 token 成本和系统能力也完全不同。比起只看最终得分,开发者更应该同步记录以下指标:

  • 每个成功任务的输入与输出 token 总量;
  • 平均工具调用次数和无效调用比例;
  • 从任务开始到完成的端到端耗时;
  • 首次生成正确补丁的成功率;
  • 上下文压缩或截断后的成绩变化;
  • 开启与关闭 preserve_thinking 时的任务成功率差异;
  • 单任务 GPU 时间与峰值显存占用。

**任务成功率除以总生成 token,可能比单一跑分更接近部署价值。**如果 80.9 分需要多生成数倍推理内容,它可能适合作为离线教师模型,却未必适合高并发在线 Agent;反过来,如果它能用更少的步骤完成任务,33B 的较高单步成本也可能被更短的执行链抵消。

Apache 2.0 让“教师模型”定位更有实际意义

**Apache 2.0 是允许使用、修改、分发和商业应用的宽松开源许可证,并包含明确的专利授权条款。**对于计划构建企业内部 Agent、生成合成训练数据或继续微调模型的团队,这比限制商业用途或对衍生模型施加额外条件的许可证更容易纳入产品流程。

**开放权重的价值在教师模型场景中会被进一步放大。**企业可以在私有代码和内部工具环境中部署 Nanbeige4.3-33B,让它生成任务拆解、工具调用和错误恢复轨迹,再用这些轨迹训练更小的专用模型,而不必把源代码、工单和日志发送到外部服务。

**Apache 2.0 并不意味着所有合规问题自动消失。**许可证主要约束模型权重和相关软件的使用方式,部署方仍需核查训练数据说明、第三方组件、商标使用、生成内容风险及自身行业监管要求;如果要利用教师输出训练商业模型,还应建立数据过滤、版权审查和敏感信息清洗流程。

**这次开放策略比“只发布一个在线接口”更符合教师模型的产品逻辑。**教师模型需要被反复采样、调整温度、接入自定义沙箱,并针对企业任务生成大量轨迹,权重可下载意味着开发者能够控制推理环境,也能测试量化、并行和不同上下文管理方案。

为什么先做 33B,再教 3B

**大模型教小模型的核心目标是把昂贵能力转化为低成本执行能力。**33B 模型可以承担数据生成、轨迹筛选和失败分析,未来的 3B 模型则负责更高频、更低延迟的实际调用,这与“云端教师加边缘学生”的路线类似。

**Agent 蒸馏不只是复制最终答案。**对工具型任务而言,真正有价值的数据通常包括何时搜索、调用哪个工具、参数如何填写、看到错误后如何修正,以及什么时候停止;如果只让 3B 模型学习最终补丁,它很难掌握中间决策,更容易在环境变化后失效。

**Nanbeige 团队此前已经在 3B 规模上强调推理、代码和长链工具使用。**Nanbeige4.3-33B 的出现表明团队正在反向补齐更强的上游教师,以提高后续小模型训练数据的质量,而不是只依赖外部闭源模型生成轨迹。

**教师是否优秀最终要由学生成绩证明。**如果后续 3B 模型能在相同任务上接近 33B 的成功率,同时把显存、延迟和每任务 token 数降到适合单卡或边缘部署的水平,那么这次发布的战略意义会超过当前跑分;如果学生模型提升有限,33B 就更像一个独立的 Agent 模型,而不是有效的能力生产线。

它适合谁,又不适合谁

**Nanbeige4.3-33B 最适合拥有自有评测集和推理基础设施的 Agent 团队。**代码维护、终端自动化、安全沙箱操作、内部知识检索和合成轨迹生产,都是它值得尝试的方向,尤其适合需要把数据保留在私有环境中的组织。

**普通聊天应用没有必要因为 512K 和 Agent 跑分立刻迁移。**模型卡已经对 preserve_thinking 的使用场景作出区分,而 33B 模型的部署成本也明显高于 3B 或 7B 模型;对于短问答、内容改写和简单信息抽取,小模型通常更便宜,也更容易获得稳定延迟。

**软件工程 Agent 也不应只依据 Terminal-Bench 2.1 做决定。**Nanbeige4.3-33B 在 SWE-Bench Pro 上并未超过对照模型,说明涉及真实仓库修改时仍需进行针对性测试,包括私有语言栈、构建系统、测试套件和代码审查规则。

**最合理的试用方式是先做受控 A/B 测试。**团队可以选择 50 至 200 个内部真实任务,在相同容器、超时限制、工具权限和 token 预算下,对比 Nanbeige4.3-33B 与现有模型,并同时测试开启和关闭 preserve_thinking 的差异。

我们的判断:亮点不是 512K,而是开放的 Agent 训练闭环

**Nanbeige4.3-33B 真正有竞争力的卖点是“Apache 2.0 权重、长上下文、教师模型”三者同时出现。**512K 单独看已经不再稀缺,33B 参数规模也不是最大,但允许企业把模型放进私有工具环境、生成多轮轨迹并训练更小 Agent,这套组合具有明确的工程价值。

**80.9 的 Terminal-Bench 2.1 成绩值得关注,但现阶段仍应保守解读。**发布方成绩尚未经过独立复现,而且 preserve_thinking=true 会影响上下文长度、token 用量和多轮行为;如果没有同步公布任务级 token、延迟及失败类型,单一分数还不足以证明总体部署效率。

**Nanbeige4.3-33B 更像一台 Agent 数据生产设备,而不是面向所有用户的万能聊天模型。**它是否能在开源模型中建立位置,将取决于三件事:第三方能否复现终端成绩、512K 下的有效召回能否经受压力测试,以及计划中的 3B 学生模型能否真正继承教师的长程工具能力。

参考来源

相关推荐

查看全部