Thinking Machines 发布 Inkling-Small 开放权重模型
7月15日的预告已转为可下载权重，部署门槛下降，但性能与许可边界仍需逐项核对。
本文要点
- Inkling-Small 从 preview 变成带完整权重、专属模型卡和下载入口的正式版本。
- 参数口径从 12B 激活扩展为 276B 总参数、12B 激活参数。
- BF16 与 NVFP4 两种公开仓库让自托管路径从承诺变成可执行选项。
阅读辅助
先看数字、证据和来源，再读正文。
本期 news peg 是 Inkling-Small 从7月15日预告状态转为正式开放完整权重。
2026-07-15 · Thinking Machines 发布 Inkling，并把 12B 激活参数的 Inkling-Small 定位为预告版本。
预告模型正式变成可下载权重
Inkling-Small 这次值得记录的状态变化很明确：Thinking Machines 在 7 月 15 日只预告了一个每 token 激活 120 亿参数的轻量版本；到 7 月 30 日，公司发布 Small 专属公告和模型卡，并把 BF16、NVFP4 完整权重放到可公开下载的 Hugging Face 仓库。
已经可以核实的规格包括 2760 亿总参数、120 亿激活参数、最长 100 万 tokens上下文，以及文本、图像、音频三类输入。模型生成的是文本输出。官方还开放了 Tinker 微调入口与 Playground，这使“预告模型”正式变成可下载、可部署、可微调的产品。
仍需谨慎的是性能口径。Thinking Machines 所说的“可比 Inkling”，落在 Terminal-Bench 2.1、HLE text-only、IFBench 以及部分视觉和音频评测上。官方也写明，完整 Inkling 在知识覆盖与事实性上仍有优势；目前没有证据支持两者在所有任务上等同。
对开发者而言，最大的变化是权重状态与部署可行性。Small 的激活规模明显低于 Inkling，但 BF16 仍要求至少 600 GB 聚合显存，NVFP4 也要求至少 180 GB。它更接近可由团队自托管的多模态基础模型，还没有变成普通消费级显卡可以轻松运行的小模型。
从预告到正式权重，新增的不只是一条下载链接
7 月 15 日的 Inkling 公告把 Small 称为 preview。当时公开的核心信息只有它采用相似训练方案、每 token 激活 12B，并以更低成本和延迟追求强表现。完整 Inkling 的权重已经发布，Small 的可下载状态尚未成立。
7 月 30 日公告改用 Today, we are releasing Inkling-Small，并明确写出 We are releasing the full weights。这两个状态动词构成本期 news peg：预告版本完成正式发布，第三方首次获得由官方确认的完整权重、独立模型卡和部署说明。
Hugging Face 仓库也给出可机器核验的证据。BF16 仓库公开、非 gated，包含 32 个模型权重分片和单独的 MTP 权重；NVFP4 仓库同样公开、非 gated，包含 9 个模型分片与量化配置。按仓库文件体量统计，两组 safetensors 分别约为 532 GB与 171 GB。
仓库文件的上传时间早于正式公告，这在模型发布中并不罕见。新闻日期仍应以公司公告、Small 专属模型卡和官方发布帖为准；文件时间只能证明发布前已完成上传准备，不能把 7 月 27 日或 28 日写成对外正式发布日期。
参数缩小了，部署门槛仍然属于集群级
Inkling-Small 是 42 层 decoder-only 稀疏 MoE。每个 token 会路由到 256 个专家中的 6 个，另有 2 个共享专家始终激活。276B total / 12B active 因而描述的是两个不同维度：总权重决定存储与加载压力，激活参数更接近单 token 前向计算量。
| 口径 | Inkling-Small | Inkling | 应如何理解 |
|---|---|---|---|
| 总参数 | 276B | 975B | Small 约为 Inkling 的 28.3%；官方将其近似表述为四分之一规模 |
| 每 token 激活参数 | 12B | 41B | Small 约为 Inkling 的 29.3%，但不能直接等同于端到端成本比例 |
| BF16 聚合显存要求 | 至少 600 GB | 约 2 TB | 都需要多卡或集群；Small 可用 4×B300 或 8×H200 |
| NVFP4 聚合显存要求 | 至少 180 GB | 约 600 GB | Small 可用 1×B300 的 W4A4，或 2×H200 的 W4A16 |
| 最长上下文 | 100 万 tokens | 100 万 tokens | 上限相同，跑满时的 KV cache 与吞吐仍取决于部署配置 |
“约四分之一规模”是官方近似说法，不是严格分数。若按总参数计算，276 除以 975 约为 28.3%；按激活参数计算，12 除以 41 约为 29.3%。中文可以忠实保留“约四分之一”，同时应给出原始参数，避免读者误以为精确等于 25%。
这也不能翻译成“显存、延迟和价格均降为四分之一”。权重精度、专家并行、张量并行、batch、上下文长度、KV cache、推理框架与硬件代际都会改变实际结果。官方给出的最低显存配置证明部署规模确实显著下降，也证明它依然不是单张常见数据中心卡或消费卡即可完整承载的模型。
Hugging Face 发布说明提供了更具体的工程路径，包括 Transformers、SGLang、vLLM、TokenSpeed 与 Unsloth。其预配置 Inference Endpoint 使用 8 张 RTX PRO 6000 部署 NVFP4，报告单用户约 140 TPS。这个数字绑定特定硬件、配置和并发状态，不能写成 Inkling-Small 的通用吞吐。
多模态能力的准确范围
模型卡把 Inkling-Small 定义为 general-purpose multimodal model：接受 UTF-8 文本、像素图像和 16kHz WAV 音频，生成 UTF-8 文本。图像通过分层 patch encoder 编码，音频转为离散表示，随后与文本投影到共享隐藏空间，由同一个 decoder 联合处理。
输入规格也有推荐边界。官方建议图像每个边长位于 40px 至 4096px，音频最好短于 2 分钟。这些是最佳表现建议，不是所有超出范围的输入都会失败；同样，支持音频和图像理解也不代表模型可以直接输出音频波形或生成图像。
Thinking Machines 表示，Small 在多数多模态评测上接近 Inkling，并增强了用 Python 处理视觉任务的能力。官方模型卡列出的部分结果为：MMMU Pro Standard 10 得分 74.0%，Inkling 为 73.5%；Audio MC 为 54.9%，Inkling 为 56.6%；MMAU 为 77.0%，Inkling 为 77.2%。
这些数字说明 Small 没有因规模下降而在列出的多模态评测上全面失速，却仍属于厂商发布时的评测矩阵。图表理解、音频推理、真实噪声、不同语言和超长多轮交互的效果，需要第三方在固定 prompt、思考预算与预处理条件下复现。
“性能可比”必须附上任务和基准
公告把性能比较限定在三组核心维度：Terminal-Bench 2.1 的 agentic tool use、无工具的 HLE text-only 推理，以及 IFBench 指令遵循。模型卡中，Small 分别为 64.7%、31.6%和 82.2%；完整 Inkling 分别为 63.8%、29.7%和 79.8%。
| 官方评测 | Inkling-Small | Inkling | 可以得出的结论 |
|---|---|---|---|
| Terminal-Bench 2.1 | 64.7% | 63.8% | 在官方所用 best harness 下，Small 略高 |
| HLE text-only，无工具 | 31.6% | 29.7% | 在该文本推理口径下，Small 略高 |
| IFBench | 82.2% | 79.8% | 在该指令遵循评测下，Small 更高 |
| SimpleQA Verified | 20.6% | 43.9% | 完整 Inkling 的事实性结果明显更高 |
| AA Omniscience Index | -9.0 | 2.1 | 官方知识覆盖指标同样显示大模型优势 |
这张表解释了为何“性能可比”不能扩成“所有任务等同”。Thinking Machines 自己给出了反向证据：Small 在推理和 agentic coding benchmark 上可匹配或超过 Inkling，Inkling 仍在知识覆盖和事实性上占优。不同任务的结论方向并不相同。
Small 的训练路径也与单纯缩小模型不同。公司称，它在大模型之后开始训练，因此调整了预训练数据配比和训练方案；较早的 preview checkpoint 部分使用 Inkling 作为教师做 on-policy distillation，随后继续进行了两周 agentic coding 强化学习。这能解释部分专项评测为何可能超过更大的教师模型，但尚不能证明泛化质量同步提升。
评测的另一项变量是可调思考强度。官方用从 minimal 到 xhigh 的 effort sweep 比较输出 TFLOPs、生成 token 和样本成本。若第三方只报最高 effort 的分数，却忽略输出长度、调用价格和任务超时，结论会偏向“多算换高分”，无法反映真实部署的性价比。
Apache 2.0 标注之外，还有 Model AUP
Small 专属模型卡和两组 Hugging Face 仓库都把许可证标为 Apache 2.0。模型卡还明确称开放权重用于研究、微调，以及由下游开发者集成进第三方产品。这些信息支持商业团队把它纳入技术评估。
与此同时，Thinking Machines 的 Model Acceptable Use Policy 写明：访问、下载或使用模型权重、参数、相关材料及修改版本，即同意受该政策约束，除非双方另有书面约定。AUP 限制违法用途、武器、恶意代码、未经授权监控、自动化高影响决策等场景，并要求在特定情况下向终端用户披露 AI 交互和已知重大限制。
因此，“Apache 2.0”不能被简写成“没有额外使用条件”。准确表述是：仓库许可证标注为 Apache 2.0，官方同时声明 Model AUP 适用于模型材料。企业若要再分发权重、提供托管 API 或嵌入高风险行业，还需结合 AUP、出口管制、当地法律和产品责任进行审查。
这种并行结构也值得后续跟踪。若社区衍生权重修改了模型、量化格式或安全策略，哪些义务随权重传播，哪些义务由服务条款触发，需要由法律文本和具体部署关系判断。技术团队不应只读取仓库顶部的 license tag 就完成合规结论。
Inkling-Small 的实际价值来自“可复核性”终于落地。预告阶段只能讨论厂商给出的方向；完整权重、模型卡和两种精度仓库同时公开后，第三方才可以测量真实显存、吞吐、长上下文稳定性、多模态预处理和微调效果。发布状态的变化比又多一组 benchmark 更有意义。
12B 激活参数会降低每 token 计算压力，但 276B 总权重仍把它放在专业基础设施范围。它填补的是完整 Inkling 与更小开源模型之间的部署层级：大型团队可以用两张 H200 或单张 B300 尝试量化版，普通开发者仍更可能通过托管推理或进一步量化使用。
性能叙事应保留任务分化。Small 在官方列出的推理、编码和指令遵循评测上表现亮眼，知识覆盖与事实性却落后于完整 Inkling。对 agentic coding 或领域微调团队，这种交换可能合理；对依赖广泛事实知识的通用问答产品，较小激活规模未必能抵消质量差距。
许可同样会影响生态扩散。Apache 2.0 的熟悉度有利于工程采用，Model AUP 又给使用和分发增加了行为边界。真正决定企业是否愿意投入适配的，不仅是模型能否下载，还包括这些条件能否被合规团队稳定解释，以及衍生权重和托管服务如何继承义务。
当前最稳妥的判断是：Thinking Machines 把一款原生文本、图像、音频模型推到了更可部署的开放权重层级，但“更可部署”仍是相对完整 Inkling 而言。第三方复现、真实负载成本和许可实践，将决定它能否从一次高规格发布变成持续使用的基础模型。
复核时应盯住的三组分母
性能分母首先要统一。Terminal-Bench 2.1 使用哪个 harness，HLE 是否带工具，IFBench 使用什么思考强度，都会影响比较。官方模型卡把部分设置写进指标名，第三方报告也应保留这些限定，不能只摘最高分。
部署分母包括权重精度、GPU、并行方式、上下文长度、batch 和并发。BF16 的 600 GB与 NVFP4 的 180 GB是聚合显存建议，不是完整服务的硬件总成本。长上下文还会放大 KV cache，生产服务也需要预留故障恢复和并发空间。
许可分母则是使用方式。下载后内部研究、对外托管 API、再分发修改权重、嵌入终端产品，承担的合规责任不同。后续若出现社区量化或微调版本，发布者应明确基础许可证、AUP 适用主张、修改内容与安全测试，避免只留下模糊的“开源模型”标签。
最终，Inkling-Small 是否建立稳定生态，可用几项公开指标观察：主流推理框架是否持续兼容；第三方量化是否披露质量损失；独立 benchmark 是否复现任务分化；Tinker 微调是否允许可验证的导出与复现；企业部署案例是否公开真实吞吐、成本与合规处理方式。