Nanbeige4.3-33B：20 场赢 17 场、512K 上下文，却未经过任何独立测试

2026年10月24日 02:49 UTC，一个名为 Nanbeige/Nanbeige4.3-33B的 Hugging Face 仓库在其同名基础检查点发布四分钟后公开上线。没有出现任何发布帖。没有博客文章，没有厂商公告，也没有新闻稿——模型卡是这次 331 亿参数开放权重发布的全部第一方记录，其核心宣称是它在 20 项基准中的 18 项上击败 Qwen3.8-27B。这一说法并非虚假。但它目前也尚不可核验，而此后的报道大多只是重复了那张表格，却没有阅读表格下方的脚注。

所以这些数字同时说明了两件事。Nanbeige4.3-33B 在它自己表格的 20 行中领先 17 行，并在其中 18 行上击败Qwen3.8-27B。这是两个不同的计数，而且都准确：它没有领先的三行是 SWE-Bench Pro，Qwen3.8-27B 以 61.7 比 60.3 获胜；GDPval，Qwen3.8-27B 以 86.4 比 84.8 获胜；以及 GPQA Diamond，Gemma4-31B 的 91.3 击败了两者。输给 Qwen3.8-27B 两行、输给 Gemma4-31B 一行，就得到对 Qwen 模型 20 行中的 18 行、对全场 20 行中的 17 行。大多数报道只挑一个数字而省略另一个，这是件小事，却能说明其余内容被读得有多仔细。

该仓库确立了哪些内容，以及哪些内容没有确立

从打开文件后可以核实的内容入手，而不是引用文字描述，因为两者之间的差距才是这里的关键所在。

• 已确认：权重确实存在。十四个 safetensors 分片总计 66,259,989,086 字节，采用 bfloat16，位于一个创建于 2026 年 10 月 24 日 02:49:18Z、最后更新于 10 月 25 日 11:11Z 的仓库中。另有一个独立的基础检查点，Nanbeige4.3-33B-Base，创建于三分钟前的 02:46:52Z。

• 已确认：许可证为 Apache 2.0，已在仓库元数据和卡片前言中声明。八个非权重文件中没有 LICENSE 文件，这属于文书层面的缺口，而非法律层面的缺口——Hub 和大多数扫描器读取的正是元数据字段。

• 已确认：该架构是标准的 Llama 堆栈，并非混合专家架构，也不是该系列小模型所采用的循环 Transformer 设计。更多配置信息见下文。

• 已确认：不存在供应商托管的端点。Hub 中该仓库的推理提供程序映射为空，而卡片提供了 vLLM、SGLang 和 Transformers，其理念就是：自备 GPU。

• 未确认：关于其训练方式的任何信息。没有预训练 token 数量，没有数据配比，没有算力数据，没有后训练方案，也没有局限性或安全性章节。该模型卡的引用部分仅有四行。

• 未确认：任何已公布的数字是否可复现。仓库中没有评估工具——没有脚本、没有任务配置、没有日志——并且截至10月26日，尚无第三方公布该模型的评分、竞技场评级或指数排名。

• 未获证实：此次发布是悄悄进行的。事实并非如此。它由实验室在未事先公布的情况下推出，这一描述更狭窄也更准确：该模型卡是一份完整的发布文档，附有二十行的基准测试表，聚合网站一天之内就将其收录。缺失的是一篇第一方文章，说明 Nanbeige 认为自己构建了什么。

这一区别对任何正在决定该如何对待这次发布的人来说都很重要。一家什么都不说的实验室，在意图、支持或下一个检查点方面什么也没告诉你。一家发布了模型卡却没有发帖的实验室，则已经向你透露了大量关于该模型的信息，同时把策略留在了不言之中——而在这个例子中，只要你留心，就会发现策略就明明白白写在模型卡的第二段。

这张卡把它称作老师，而这重新诠释了整个发布。

Nanbeige4.3-33B 被描述为 Nanbeige4.3 系列的“旗舰教师模型”，它被首先构建出来，以便实验室将智能体行为蒸馏到更小的模型中，“例如用于 Nanbeige4.3-3B”。模型卡将“在约 30B 参数级别的开放模型中具备最先进的智能体性能”列为目标，随后立即将 33B 描述为蒸馏流程的基础，而非最终产品。

如果照字面理解，这次发布就是一个恰好可交付的训练产物。它是你用来为 3B 学生模型生成轨迹的模型，而它的基准测试套件之所以大量侧重长时程智能体任务——Terminal-Bench、DeepSWE、JobBench、Toolathlon——是因为这些正是有人想要迁移的行为。Nanbeige4.3-3B 尚未发布。当它发布时，它将成为大多数人实际运行的模型，而这个 33B 模型将成为解释其分数的那一个。

有一个值得指出的副作用：教师模型被优化的是在宽裕的 token 预算下生成优质轨迹，而不是在推理时保持低成本。卡片推荐的设置也印证了这一点——智能体任务的最大新 token 数为 65,536，推理和聊天为 262,144，且默认开启思考。一个会被提示生成 25 万个 token 的模型，不是你会不加预算就放在聊天框后面的模型。

配置文件所描述的 33B

阅读 config.json 就会发现，其结构很常规，而营销宣传则不然。五十二层，隐藏大小为 7,168，56 个查询头对应 8 个键值头——7:1 的分组查询比例——头维度为 128，FFN 宽度为 22,016，词表包含 166,912 个 token。RoPE 基数为 120,000,000，且未应用任何缩放，而 max_position_embeddings 被设为 524,288。文件中标注的 transformers 版本为 4.51.1。

参数量可由这些数字推算出来。注意力投影每层有 1.174 亿个参数，三层 MLP 有 4.734 亿个，因此每个块有 5.909 亿个，52 个块合计 307 亿。两个非绑定嵌入矩阵的尺寸为 166,912 × 7,168，共增加 24 亿。总计为 331 亿，这正是名称所承诺的规模，也正是 66.3 GB 的 bfloat16 所对应的重量。

相对于它不惜用整张表格去攻击的那个模型，差异比分数所显示的更为鲜明。

• 规模 — Nanbeige4.3-33B 为 33.1B 稠密模型，而 Qwen3.8-27B 为 27.78B 稠密模型。两者均为稠密模型；均非混合专家模型。

• 模态——仅文本，英文和中文，Nanbeige4.3-33B 对比 Qwen3.8-27B 的原生文本、图像和视频输入。如果你的流水线读取截图，那么基准测试还没开始，比较就已经结束了。

• 注意力 — Nanbeige4.3-33B 在 52 层中采用统一的全注意力，而 Qwen3.8-27B 采用混合堆栈：以 3:1 的比例运行 48 个门控 DeltaNet 线性层和 16 个全注意力层。这就是为什么 Qwen 模型在长上下文下成本低，而这个模型并非如此。

• 上下文——Nanbeige4.3-33B 原生支持 524,288 个 token，而 Qwen3.8-27B 原生支持 262,144 个，并可通过 YaRN 扩展至约 100 万个。

• 许可证 — 两者均为 Apache 2.0，这消除了通常偏好其中一个的理由。

注意力上的差异并非无关紧要的注解。它正是下一节存在的全部理由。

512K 只是配置文件中的一个数值，并不是可用的工作上下文

关于这次发布的每一篇摘要，开篇都在讲那五十万 token 的上下文窗口。几乎没有一篇去算过这笔账，而这笔账并不好看。

在 52 层、8 个 128 维的键值头以及 bfloat16 存储下，缓存中每个 token 的开销为 2 × 52 × 8 × 128 × 2 字节——212,992 字节，即 208 KiB。由此可直接得出三个后果。

• 在完整的 524,288 个 token 下，仅 KV 缓存就达 111.7 GB，约 104 GiB。这比 66.3 GB 的权重还多，而且它无法放入当今在售的任何单块加速器中。

• 在 131,072 个 token 时——也就是标称窗口的四分之一——缓存为 27.9 GB，约合 26 GiB。加上权重后，在激活之前就已经达到 92 GB，这就是为什么该显卡自己的示例采用四路张量并行。

• 在 32,768 个 token 时，缓存为 6.98 GB，约 6.5 GiB。这是实际中真正重要的数字，也是社区 GGUF 仓库的 llama.cpp 示例实际设置的上下文长度。

这些都不足以让512K的说法变得不诚实。这个窗口是原生支持的——没有YaRN，没有缩放因子，RoPE基数高达1.2亿——在一台内存足够的四GPU节点上，你确实可以把它跑起来。但这确实意味着，标题里的那个数字是一个你在自己拥有的硬件上达不到的上限，也意味着任何把“512K上下文”当作购买理由来引用的人，并没有把缓存的代价算进去。相比之下，在Qwen3.8-27B的设计中，四分之三的层持有的是恒定大小的循环状态，而不是不断增长的缓存，因此每个长上下文token的成本差距是结构性的，而非调优层面的问题。

配置里还有一点，而且是那种会搭进去一个下午的细节：use_cache被设为false在以下两个文件中都config.json和generation_config.json如果用模型卡上的 Transformers 代码片段加载模型，然后直接调用 generate 而不覆盖这个设置，那么每一步都会重新计算前缀。vLLM 和 SGLang 这两条路径自行管理缓存，不受影响。如果你第一次跑基准测试时感觉慢得莫名其妙，先检查这一点，再去怪权重。

按照脚注要求的方式阅读基准表

这张表格的文档记录比大多数供应商表格都更完善，而警示说明恰恰就藏在这些文档里。二十行数据之下附有十二条脚注，它们对可比性的说明比分数本身还要多。

• Terminal-Bench 2.1 使用 Terminus 2 运行。Terminal-Bench 4.0 和 DeepSWE 使用 mini-swe-agent v2.4.6 运行。

• NL2Repo 使用 Claude Code 测试框架运行；JobBench 则使用 Claude Code 加搜索工具运行。

• SWE-Atlas-QnA 的回答由 GPT-6 Sol 作为评判模型、以中等推理强度，依据 1,304 条针对具体任务的评分标准进行评分。评分标准评判模型是流程中的第二个模型，并非被测模型本身。

• Toolathlon-Verified 不对单个请求设置 max_tokens 限制。Claw-Eval 仅在 General 子集（157 个单轮任务）上评分。YC-bench 在每次调用前仅保留最近十轮对话作为历史记录。GDPval 使用修订后的评分标准。

• Nanbeige4.3-33B 本身是在 preserve_thinking=true 的条件下评估的，该设置会跨轮次保留先前的助手推理内容。模型卡针对多轮工具使用推荐的正是这一设置，而对普通聊天推荐的则恰恰相反。

综合来看，这些记录描述了一套测试套件，旨在以充裕的预算衡量长时程智能体行为。这是一个站得住脚的衡量对象——这正是模型的用途所在——但它也是运行框架选择对分数影响最大的情形。表中最大的差距是 DeepSWE 的 65.5 对 Qwen3.8-27B 的 42.5，在一个由智能体脚手架驱动的基准上形成了 23 分的差距。最小的差距出现在脚手架影响最小的几行：AIME 2026 为 95.2 对 94.5，Tau3-Bench 为 48.8 对 48.5，EnterpriseOps-Gym 为 41.0 对 40.2。

这一现象与两种解释相符。要么该模型在智能体编程方面确实远优于同类模型，要么智能体相关的行正是那些实验室通过针对自家模型调优自家脚手架而获益最大的行。仓库中没有任何内容能区分这两种解释；在有人重新运行该测试套件之前，诚实的立场是两者都仍然成立。模型仅以一分或更小优势获胜的那些行——Tau3-Bench、EnterpriseOps-Gym、AIME、Claw-Eval 以 78.3 对 75.2——最不可能在独立评测框架下依然成立。

截至10月26日，根本不存在任何外部数字。没有 Artificial Analysis 指数条目，没有竞技场评分，也没有任何人复现。模型卡自己给出的 AA-LCR 数值 84.0，是 Nanbeige 在运行 Artificial Analysis 的基准测试，而不是 Artificial Analysis 在运行 Nanbeige。

迄今为止唯一一次实际测试，以及它说明了什么

只有一个人公布了实际运行权重得出的任何结果，而这一结果之所以值得报告，恰恰是因为它很单薄。一位日本开发者在配备 80 GB 显存的 Colab A100 上加载了完整的 bfloat16 checkpoint，使用的是普通 Transformers，并启用了自动 dtype 和 device mapping，测得约 63 GB 的 VRAM 占用。第一次回复限制为 1,024 个新 token，耗时大约十一秒。没有给出 tokens-per-second 数字；给人的印象是，bfloat16 下的 33B dense model 很慢，而这正是算术所预测的。

随后是三个提示。9.11 与 9.8 的比较结果正确，并给出了清晰的小数解释。一个关于动漫角色的问题主观上回答得还行，但名字出现了错乱。一个关于日本首相的问题给出了错误答案，声称知识截止日期为 2024 年 6 月，并虚构了一个名字。英文思维链在结束的 think 标签之前泄露了。

三个随意提示算不上评估，也不应被当作评估来解读。它们只是一个数据点，与厂商表格所呈现的形态相符：一个为英语智能体任务大力调优、世界知识落后两年、在第二语言上表现平平的模型。模型卡声称支持英语和中文；但也没有人发布过中文测试。

量化版本在何处不再是同一个模型

大多数人运行它时不会用 66 GB 的 bfloat16。他们会在单卡上运行 4-bit 量化，而发布后一天内出现的量化报告表明，这次性能下降比通常幅度更大。

社区 GGUF 仓库公布了相对于 bfloat16 模型的 KL 散度和 top-1 一致率，这些指标是在标准文本测试集上测得的，而且其自带的 README 警告称，该模型“对量化异常敏感”。

• Q8_0，35.2 GB — KL 0.0032，top-1 一致率 98.0%。

• 重要性矩阵 Q5_K_M，24.7 GB — KL 0.0213，94.7% top-1。

• 重要性矩阵 Q4_K_M，21.2 GB — KL 0.0380，92.6% top-1。

• 普通 llama.cpp Q4_K_M，20.1 GB —— KL 0.0693，top-1 准确率 89.9%。与上一行相同的位宽，漂移却几乎翻倍。

• 重要性矩阵 IQ3_S，17.1 GB — KL 0.1019，87.5% top-1。README 指出，低于 4-bit 的文件会损失明显更多的精度。

一次 8 位 MLX 转换报告称，在 KL 为 0.015 时 top-1 达到 98.6%；并将其与 4 位 AWQ 路径进行对比：该路径在 KL 为 0.181 时 top-1 为 92.1%——相比相同标称宽度下的重要性矩阵 GGUF，下降幅度要大得多。

实际解读是：如果你在单张 40 或 48 GB 显卡上以 4-bit 评估这个模型，而它未能完成你的智能体任务，那么你评估的模型与已发布模型大约每十个 token 有九个一致。对普通文本来说，这看不出来。对工具调用来说，一个格式错误的参数就会结束整个回合，7% 的差异率就是另一款产品。如果你感兴趣的原因是那些智能体能力宣称，那么诚实的最低要求是带重要性矩阵的 Q5，或者在租用硬件上用 bfloat16 跑评估。

尝试它需要付出什么代价，以及如何在不押注于它的情况下尝试它

Nanbeige 没有公布任何价格，因为根本无从定价：该模型只是权重，而非一项服务，并且 Hub 上没有为其列出任何推理提供商。这样一来就只剩三条路线——用四块 80 GB 显卡运行 bfloat16，用一块 48 GB 显卡以 Q5 量化运行，或者等待某家提供商将其上线。

作为对比，它声称要超越的模型可按需使用。Qwen3.8-27B 在 OrcaRouter 上运行，每百万输入 token 收费 0.33 美元，每百万输出 token 收费 2.40 美元，上下文窗口为 262K，p50 首 token 时间约为 2.95 秒。一个 65,536 token 的智能体提示词加上 8,000 token 的输出，成本约为四美分。这正是自托管的 33B 模型必须超越的数字，而且它必须在承担 GPU 闲置时间、量化风险以及没有回退路径的情况下超越它。

我们不托管 Nanbeige4.3-33B，本文任何内容都不应被解读为我们这样做的声明。我们能做的是让反方向的比较变得成本低廉：Orca Connect 可将你自己的 GPU 置于与托管目录相同的密钥之后，这样，在你做决定期间，一个自托管的 Nanbeige 端点与 Qwen3.8-27B 可以共处同一个端点、同一条路由规则之后。将一部分流量导向新检查点，保留托管模型作为回退，再让请求日志——评分、延迟、每次调用成本——来解决厂商表格无法解决的争论。0% 加价在这里有特定意义：供应商标价原样传递，因此当厂商降价时，你上周搭建的比较仍然可靠。

谁应该对此采取行动，谁应该等待

如果你正在构建蒸馏流水线，这是本月最值得关注的开放检查点。一个拥有宽松许可证、有文档记录的采样设置，以及一套经过挑选、恰好用于衡量你想迁移的行为的基准测试套件的 33B 稠密教师模型，是一项有用的资产；而实验室表示会先构建教师模型，这一事实也释放出该系列走向何方的信号。下载它，运行你自己的评估，并把模型卡中的测试框架说明与你的结果放在一起。

如果你本周就需要把模型投入生产，那就再等等。目前没有独立评分，没有托管端点，只有一份包含三个提示词的实测报告，以及一个量化表现：在大多数人负担得起的位宽下，它的退化速度比通常更快。这些都不足以否定它——只是还不能算作证据。

如果你需要视觉能力，胜负早已分明：Qwen3.8-27B 能读取图像和视频，而这个模型只能读取两种语言的文本。

值得关注的点很具体。Nanbeige4.3-3B，也就是蒸馏目标，它会告诉你这位老师是否值得打造。Terminal-Bench 4.0 的首次独立运行，也就是差距最大、对脚手架最敏感的那一行。以及是否有服务商把 33B 列出来——因为一旦有人这么做，512K 上下文就不再是一个配置值，而变成了一项账单条目，而本文中的这笔算术也就成了某人的发票。