Inkling 2 Small 权重已开放下载：394 GB、Apache 2.0，以及一张节点级别的账单

Inkling 2 Small 仓库中的第一次权重提交标记为 2026 年 11 月 12 日 19:53 UTC——比本文撰写时间早九个小时。在此之前，这个模型只是一张价目表和一张基准测试表：Thinking Machines Lab 于 11 月 5 日发布它时采用了闭源权重、一个 Tinker 端点，并明确表示打算“下周”根据 Apache 2.0 发布检查点。因此，这个模型本身才诞生八天。新变化在于你现在可以下载它，而这次下载可不是一个小文件。

两个仓库已公开。主检查点为 393.5 GB，分布在 36 个文件中，其中 24 个是 safetensors 分片。MXFP8 变体为 622.8 GB。两者在模型卡元数据中均声明为 Apache 2.0。这就是目前公告的全部内容——模型卡、仓库，以及附加在发布帖末尾的一段更新。以下所有内容均来自这些一手资料，以及随附的两份推理服务指南；而且有必要直说仍然缺失的东西：作为开放这些权重所声明前提的外部安全测试，尚未公布。

下载内容里究竟有什么

先从规模说起，因为这是首先决定这个模型到底能否为你所用的因素。混合精度布局几乎正好解释了这个数字，这是一个好迹象，说明公布的数据彼此一致，而不是营销文案。

• 检查点拆分 — 根据 SGLang 指南，第 0 到 39 层使用 NVFP4 专家，第 40 到 47 层使用 MXFP8 专家。

预测大小——在该 40/48 和 8/48 的拆分下，平均每个参数 5.33 比特，则 594B 参数对应 396 GB。

• 测量大小 — 主仓库为 393.5 GB，包括分词器和配置文件。

• MXFP8 仓库——622.8 GB，而 safetensors 索引统计出 612.4B 个存储参数，相比之下主仓库为 383.1B，因为将专家权重打包为 4 位只会减少被计数的元素数量，而不会减少模型本身。

底层架构是一个 48 层的仅解码器 Transformer，并带有稀疏混合专家前馈块：384 个路由专家，每个 token 激活 8 个，隐藏宽度为 4,608，48 个注意力头分布在 8 个键值头上，每个头 128 维，词表包含 201,024 个 token。注意力采用混合式而非统一式——48 层中有 40 层使用 1,024 token 的滑动窗口，只有 8 层是全局的，长上下文预算正来源于此。视觉塔是一个独立的 23 层 Transformer，隐藏宽度为 1,024，有 16 个头，读取 20×20 像素的 patch，并进行 2×2 合并，因此每个图像 token 覆盖 40×40 像素的区域；卡片要求图像边长在 40 到 4,096 像素之间。

此外还加装了一个用于投机解码的多 token 预测头——五层、块大小为 8、马尔可夫秩为 256，目标层为第 5、11、17、23、29、35、41 层以及最后一个块。这些恰好就是八个全局注意力层，而这一细节说明草稿头是围绕混合栈设计的，而不是事后才加上去的。Thinking Machines 将由此得到的解码器称为“DSpark”。

有一项日常整理事项，适用于任何法律审查要求提供书面材料的人：许可证已在模型卡元数据中声明为 Apache 2.0，并且模型卡链接到标准许可证文本，但仓库树中没有 LICENSE、LICENSE.md、LICENSE.txt 或 NOTICE 文件。这四个文件均返回空结果。该声明真实且明确；大多数法律团队期望找到的产物并不在那里。

硬件清单，以及供应商与指南不一致之处

模型卡给出的是显存下限，服务部署方案给出的是拓扑结构。这两个数字并不相同，而它们之间的差距正是本页最实用的内容。

• 以 NVFP4 为主 — 至少 500 GB 聚合显存；该卡的示例为 2× B300 或 4× H200。

• MXFP8 变体——至少 800 GB；示例为 4× B300 或 8× H200。

• SGLang，每 GPU 拓扑 — GB200、GB300 和 B300 为 TP 4 / EP 4；B200 为 TP 4 / EP 4，建议采用 TP 8 以预留 KV 空间；H200 搭配 NVFP4 为 TP 8 / EP 8；MI350X 和 MI355X 为 TP 8 / EP 8；Vera Rubin 为 TP 4 / EP 4；TPU7x 在四芯片主机上为 8 / 8。

• 在 B200 或 GB200 上使用 MXFP8 — TP 8 / EP 8，每块 GPU 约 151 GB 权重。

所有这一切背后的约束是——专家并行必须等于张量并行，因为 NVFP4 专家激活缩放因子覆盖每个专家的完整输入宽度，且无法按张量并行进行分片。

因此，该卡的 4× H200 示例满足了 500 GB 下限，但并不是手册所验证的拓扑；H200 被列为 8 路。存储和内存下限只能说明它是否放得下，却不能说明它是否能运行；而对于这个检查点，在大多数人拥有的硬件上，第二个数字是第一个数字的两倍。如果你正在做资源规划，请按配方来规划，而不是按下限。

AMD 这条路径已经存在两天了，但尚未合并

让这篇文章浮出水面的雷达捕捉到的是 AMD 支持相关的拉取请求，而不是权重发布；而单就这个 PR 本身，诚实的定位是：它属于引擎层面的工作——那种算不上新闻的事情。它在这里之所以重要，只是因为它和检查点是在同一周落地的，而且它是第二家拥有容器镜像的芯片厂商。

该拉取请求为 MI350X 和 MI355X 添加 gfx950 支持，叠加在基础 Inkling 2 Small 移植之上。变更内容：ROCm 内核位于单独的 *_hip.py 模块中，仅在 HIP 下可达；CUDA 和 NPU 路径未受影响；统一 KV 池和全图预填充成为启动默认项；MegaMoE 被拒绝而非尝试执行；除非环境标志允许，否则 quick-reduce 量化会被忽略。除非第二个环境变量覆盖，否则要求 gfx950——这意味着 MI300 级显卡在启动时会被拒绝，并且 PR 作者表示 gfx942“尚未运行过”。

PR 中的测量结果由作者自行提供且未经评审：在单块 MI350X 上通过 426 项单元测试；在 balanced effort 下，GSM8K-200 上为 98.0%，而在 DSpark 且接受长度为 4.04 时为 97.5%；在输入 2,048、输出 512 时，每个输出 token 的耗时在 balanced 下为 5.15 ms，而使用 DSpark 时为 2.10 ms。换算到八块加速器上的单流，约为每秒 194 和 476 个输出 token。启用 AITer 后，准确率数字变为 97.5% 和 96.5%。

该 PR 的状态为草稿。CI 尚未在其上运行——base job 因缺少标签而受阻，且针对待审查提交没有记录到任何 AMD 运行——所有列出的代码所有者仍在等待审查。请将 MI350X 支持视为本周可以从源码构建的东西，而不是可以购买的东西。

提供它意味着用的是开发镜像，而不是正式发布版

两大主流技术栈都宣称提供首日支持，但两者都尚未正式发布。SGLang 明确表示，目前还没有任何发布版本包含这项支持，并指向 dev-inkling-2-small 构建，为 Hopper 和 Blackwell、Vera Rubin、MI35x 和 TPU7x 提供单独镜像。vLLM 则要求使用 nightly 或更新版本，或者使用 vllm/vllm-openai:inkling-2-small 镜像。对于这种规模且如此新的模型来说，这很正常，但它改变了“supported”的含义：你跟踪的是一个分支，而一次 rebase 就可能破坏你的部署。

真正会带来麻烦的操作细节：

上下文 — vLLM 的 TP 4 方案在单个托盘上的上限为 262,144 个 token；完整的 1,048,576 token 窗口需要跨两个节点使用 TP 8。在 TP 4 下，单个 1M token 请求需要 64.47 GiB 的 KV 缓存，这超过了单个托盘的剩余容量。

• 投机解码——SGLang 使用内置的 DSpark 头每步验证 8 个 token；vLLM 的对应方案通过概率性起草设置 7 个投机 token。该方案警告，如果在温度 1.0 下进行贪心起草，接受率会下降 15% 至 25%。

• 解析器 — 推理使用 inkling，工具调用使用 inkling2，未设置时 SGLang 会自动选择这两者。vLLM 的工具调用解析器需显式启用，并且该配方说明工具调用尚未经过端到端基准测试，仅做过单元测试。

• 预填充/解码分离 — 仅在四 GPU 的 GB300 托盘上以 1P1D 形式验证过，使用 NVFP4，未启用 MegaMoE，静态内存占比被强制降至 0.86，因为自动值 0.963 会导致内存耗尽。该拆分无法适配 MXFP8 检查点。

• 编码器分离——尚未包含在镜像中，而且如果无法访问到健康的编码器，语言服务器就会停止。

• 显存余量——在 TP 4 下的 192 GB B200 或 GB200 部件上，KV 容量大约只有 GB300 托盘所能提供容量的三分之一，而真正限制长上下文并发的是这一点，而不是卡上标称的窗口大小。

模型卡本身还有一条社区报告，来自上传后的最初几小时，标题为“Hopper 卡目前与 vllm 镜像不兼容”。没有看到维护者回复，我也无法复现它，因此请把它当作一个警示而不是结论，并在提交 Hopper 节点前先检查。SGLang 那边确实以 8 路列出了 H200，所以 Hopper 路径并未关闭——只是它不是 vLLM 的方案所描述的那条路径。

自托管的成本是什么，以及为什么答案很少是价格

下载 394 GB 的理由在于控制权，而非单位经济效益，而且算一算很快就能看清这一点。

在 Tinker 上，模型标价为每百万输入 token 0.30 美元、每百万缓存输入 token 0.03 美元、每百万输出 token 1.00 美元，上下文为 256K。Artificial Analysis 测得每秒输出 84 个 token，首个答案 token 耗时 67.71 秒，每项 index 任务成本 1.18 美元、每项任务耗时 29.6 分钟；整个测试套件共输出 1.54 亿个 token，而同行的中位数为 8980 万。这个 token 数量就是线索：这是一个在回答前会长时间思考的模型；按标价输出计算，单条流满负荷运行一小时约产生 30.2 万个 token，也就是约 30 美分的输出成本。要胜过每小时 1 美元的节点，你需要让大约四条流保持忙碌；要胜过每小时 20 美元的节点，则需要六十六条。很少有评估工作负载——智能体工作负载就更少——能对一个首 token 时间为 67 秒的模型保持这样的并发量。

拥有权重而非租用所换来的是：按你自己的方式获得完整的 1M 窗口，而不是使用 Tinker 的 256K 服务层级；生产环境前没有 beta 等候名单；在你自己的技术栈上进行微调；数据永不离开你的网络；以及不按 token 计量的评估扫描。你放弃的是：一个可用的发布构建、必须购买而非租用的八路拓扑，以及你现在需要维护的服务栈。

这就是这个决定真实的样貌，也正是路由层适合发挥作用的地方，而不必被要求假装自己托管了它并不托管的东西。Inkling 2 Small 不在 OrcaRouter 目录中——我们本周查看了实时模型列表，在 215 个模型里没有 inkling 条目——因此这个模型的 API 路径仍然是 Thinking Machines 自家的 Tinker 平台，并且根据发布更新，还有几家第三方推理提供商。而一个密钥背后接入 200 多个模型确实给你留了一条退路：你可以在单个节点上运行自托管实验，同时把生产环境留在我们确实路由的模型上；如果实验失败，还能自动故障转移；而对于我们确实路由的模型，提供商的标价会原样透传。当第二、第三个托管方接手这些检查点时，故障转移这一环就不再只是理论——而厂商锁定，这个最初让人下载 394 GB 的主要理由，也会变得更弱。

既然已经开放，它现在位于哪里

权重发布时，分数并未改变；真正改变的是，它如今登上了此前被排除在外的一个排行榜。在 Artificial Analysis 的开放权重排名中，Inkling 2 Small 以 31 的 Intelligence Index 在 28 个模型中位列第四，而对比组的中位数为 24。

• Kimi K3.1 Pro — 46。

• DeepSeek V4.1 Flash 1017 以最大努力 — 33。

• GLM-5.3 以最大努力 — 32。

• Inkling 2 Small — 31。

• MiMo-V2.6-Pro 和 Ling 3.1 Flash 1019 —— 各 30 个。

• Mistral Large 4 在高强度模式下 — 26。

• Qwen3.8 27B 在 xhigh 下 — 20。

那份清单中值得关注的并不是最上面一列。Inkling 2 Small 以上的每个模型都来自中国实验室，而非中国实验室最好的开放权重模型是 Mistral Large 4，得分为 26。开放这些权重将这一特定差距从二十分缩小到十五分，并改变了非中国那一列的榜首。它没有触及前沿：最好的开放模型领先十五分，而闭源模型还要更靠外。

厂商自己的评测表更长，也更显美化，其中每个数字都是 Thinking Machines 用自己的测试框架在高投入档位下跑出来的——未经复现，因此只是上限，而非预期值。对智能体工作至关重要的几项是：SWE-bench Pro v2 Hard 86.3%，DeepSWE v1.1 72.1%，Vibe Code Bench v1.1 81.6%，BrowseComp 90.2% 和 DeepSearchQA 90.9%（两者均启用压缩），MCP Atlas 全量 85.4%、公开集 85.0%，HLE 纯文本 44.1%，FrontierCode v2.0 25.4%。反向说明问题的一项是 Terminal Bench Science 仅 5.7%，绝对值偏低，这与长时程、长思考的画像相符，而非广泛能力主张。厂商在 Intelligence Index 上印的是 30.6，而实时榜单显示 31——这是快照差异，并非争议。

什么会改变这一评估？

三件事，按重要程度排序。

原本应当为此次发布把关的安全流程尚未公布。Thinking Machines 7 月关于通往安全开放权重路径的文章称，有四家外部组织对第一代 Inkling 进行了部署前测试，而 11 月 5 日的发布文章将此次发布与“外部安全测试和红队测试”联系在一起。11 月 12 日宣布权重的更新只有一句话和一个链接——指向 Hugging Face 仓库——没有评估结果，没有红队测试发现，也没有对早先条件的修订。这并不意味着测试没有发生。它意味着读者无法核查，而一个采购政策要求提供证据的组织在这里找不到证据。

发布级支持会改变哪些用户能够采用它。目前的选择是：SGLang 的开发分支、vLLM 的 nightly 版本，或者基于尚未合并的草稿从源码构建 AMD 路径。一旦支持进入带标签的发布版本，该模型就会成为一项部署决策，而不再是一个工程项目，八路拓扑也不再是研究性配置。

在默认设置下进行独立复现，才能看出 31 在实际使用中到底值多少。值得关注的是智能体（agentic）那几行——SWE-bench Pro 的 86.3 和 DeepSWE 的 72.1，对于一个仅有 17B 激活参数的模型来说是很有力的宣称，而且这些成绩是在最大努力档位下取得的。第三方在默认努力档位下运行，分数总会更低。问题在于低多少，而 Thinking Machines 之外还没有人给出答案。

在至少其中一件事落地之前，对 Inkling 2 Small 的正确描述异常精确：一个你今天就能下载的 Apache 2.0 检查点，却没有任何已发布的服务栈支持它；其最强的主张来自打造它的实验室；其许可证闸门在没有本应先行的文书工作的情况下就打开了。这是一次真实的发布，也是一个真实的缺口，而缺口才是值得关注的部分。