本文要点
- 从只提供模型定制平台，变成同时提供自研开放权重底座。
- 从单一文本模型选择，变成文本、图像和音频共用一个可微调底座。
- 从只看最大推理能力，变成可调思考力度下的质量与 token 成本曲线。
阅读辅助
先看数字、证据和来源，再读正文。
Inkling 是 975B 总参数、41B 激活的原生多模态稀疏模型。
2026-07-14 · Hugging Face API 显示 Inkling BF16 与 NVFP4 仓库在正式公告前建立。
结论先行
Thinking Machines Lab 7 月 15 日把自研模型、全量权重、Tinker 微调入口和多模态能力同时交付。Inkling 是一个 975B 总参数、41B 激活参数的 Mixture-of-Experts 模型，支持文本、图像和音频输入，权重以 Apache-2.0 许可发布；这组可下载、可微调的交付形态，比接近万亿参数本身更能界定它的位置。
确定事实可以分成四组。第一，模型支持最高 1M tokens 上下文，但 Tinker 发布当日实际提供的是 64K 与 256K 两档，二者不是同一个可用性口径。第二，官方称预训练使用 45T tokens，覆盖文本、图像、音频和视频；后训练阶段把异步强化学习扩展到 30M+ rollouts。第三，Hugging Face 的 BF16 仓库列出 108 个主模型 safetensors 权重分片，另有 NVFP4 检查点。第四，同日出现的 Inkling-Small 只是 preview：它有 276B 总参数、12B 激活参数，完整权重仍在测试，尚未发布。
不确定性同样明确。Thinking Machines Lab 自己写道，Inkling “is not the strongest overall model available today, open or closed”，即它不是当前开放或闭源模型中的最强总体模型。公开表格虽然覆盖推理、编码、Agent、多模态和安全，但 Inkling 的多数结果仍是发布方报告；SWE-Bench Verified 使用 bash-only harness，Terminal-Bench 2.1 使用内部编码 harness，部分对手成绩也取自自报。它们适合说明定位，不能替代独立、同配置复现。
对开发者而言，Inkling 打开了三个入口：可以直接下载权重审计与部署，可以在 Tinker 上做后训练，也可以通过 SGLang、vLLM、TokenSpeed、llama.cpp 与 Transformers 等生态接入。代价是工程门槛不会因为 Apache-2.0 自动消失。975B 是完整权重规模，41B 只是每个 token 的激活口径；存储、加载、跨卡通信、长上下文 KV cache 和多模态预处理，仍会决定它是否真的适合自建。
这次到底发布了什么
Inkling 是 Thinking Machines Lab 从头训练的第一款开放权重模型。官方把它定义为一个广谱、多模态、可定制的基础模型，而不是只针对某个榜单优化的专用模型。架构上，它是 66 层 decoder-only Transformer，每层的稀疏前馈部分包含 256 个 routed experts 和 2 个 shared experts；每个 token 选择 6 个 routed experts，共享专家始终参与。注意这里的专家数量是架构细节，不能和“每个 token 激活 41B 参数”简单等同计算。
注意力部分也不是纯粹沿用常见配方。官方称模型按 5:1 比例交错使用滑动窗口与全局注意力层，配置 8 个 KV heads，位置编码选择相对位置嵌入而不是 RoPE。图像以 40×40 像素 patch 进入轻量嵌入层，音频则使用 dMel 表示，之后与文本 token 一起进入共享 decoder。模型卡把输入范围写为文本、图像和音频，输出为文本；发布公告虽说预训练数据包含视频，但这不等于当前模型卡承诺直接接受视频输入。
“开放全量权重”也有可核查的落点。Hugging Face API 的 BF16 仓库文件名从 model-00001-of-00108.safetensors 排到 model-00108-of-00108.safetensors，因此 108 个权重分片是仓库级事实，而不是根据参数量推算。发布方同时提供 NVFP4 检查点，面向 NVIDIA Blackwell 系统的高效推理；NVFP4 仓库分片数不同，不能把 BF16 的 108 个机械套到所有格式。Apache-2.0 许可降低了再分发、改造和产品集成的法律摩擦，但开放权重仍不等于开放全部训练数据、数据配比、训练代码和逐步日志。
参数、上下文与可用性不能混写
| 项目 | Inkling 公布口径 | 7 月 15 日实际状态 | 解读边界 |
|---|---|---|---|
| 模型规模 | 975B 总参数 | BF16 与 NVFP4 权重可下载 | 总参数不是单 token 计算量 |
| 稀疏激活 | 41B 激活参数 | MoE 每 token 选择部分专家 | 不代表只需加载 41B 权重 |
| 上下文能力 | 最高 1M tokens | 模型层面的支持上限 | 不是 Tinker 当日默认档位 |
| Tinker 上下文 | 64K、256K | 两档已列入支持模型表 | 256K 使用独立 PEFT 模型标识 |
| 预训练规模 | 45T tokens | 官方披露的总量 | 各模态比例与去重细节未公开 |
| RL 规模 | 30M+ rollouts | 官方称经历两个长连续训练阶段 | rollout 数量不等于独立任务数 |
| 权重许可 | Apache-2.0 | 模型卡和 HF 标签一致 | 仍需遵守可接受使用政策 |
| 促销 | 50% discount | 仅称“for a limited time” | 公告没有给出截止日期 |
这张表里最容易被误读的是上下文。Inkling 的模型公告和模型卡都写“up to 1M tokens”，这是能力上限。Tinker 的可用性段落则明确写发布当日提供 64K 和 256K 选项，模型表也分别列出两个配置。因此，准确表述是“模型最高支持 1M，Tinker 当日开放 64K 与 256K”，而不是“Tinker 已开放 1M”。自部署能否跑到上限，还取决于推理框架支持、KV cache、并行策略和硬件容量。
第二个容易被误读的是 MoE 的成本。41B 激活参数意味着每个 token 不会计算全部 975B 参数，但完整专家权重仍需被存储并在设备或节点之间组织。对部署团队来说，激活规模更接近单步计算口径，总参数规模更接近权重存储和系统编排压力。两者共同决定成本，不能只取较小的数字宣传“等同 41B 模型”，也不能只取较大的数字断言“每个 token 都计算近 1T 参数”。
第三个边界是价格。官方原文为“a 50% discount for a limited time”。忠实中文只能是“限时 五折优惠”或“限时优惠 50%”，不能写成“永久半价”。公告没有给出结束日期，因此也不能自行补一个截止日。Tinker 模型文档是动态页面，实际采购与训练前仍需重新核对价格、缓存折扣、上下文档位和优惠是否还在。
训练规模说明了什么
官方披露 Inkling 在文本、图像、音频和视频上预训练 45T tokens。这个数字说明训练覆盖面很大，但公开材料没有给出各模态配比，也没有给出足以让外部完整重建数据管线的明细。模型卡只概括数据来自公开来源、第三方获取以及合成或增强数据，并经过清洗、去重和过滤。因此，45T 能证明官方声称的训练规模，不能直接证明某一模态的数据质量，也不能解释某个 benchmark 的因果来源。
后训练部分更有辨识度。Thinking Machines Lab 称先用包括 Kimi K2.5 在内的开放权重模型生成合成数据，完成占较小算力比例的初始 SFT，主要算力随后投入合成环境和人工创建环境上的大规模 RL。异步 RL 被扩展到 30M+ rollouts，并在两个长期连续训练阶段保持稳定。官方展示的 held-out reasoning aggregate 从 SFT 初始化的 0.264 提升到发布检查点的 0.356，但这个 aggregate 是内部组合指标，不是外部标准榜单。
可控 thinking effort 来自后训练时对系统消息和每 token 成本的调整。发布方用 0.2 到 0.99 的 effort 扫描展示质量与生成 token 数的关系，并称在 Terminal-Bench 2.1 上，Inkling 用约三分之一 token 达到 Nemotron 3 Ultra 的同等分数。这里的正确读法是发布方展示了一条“质量—生成量”曲线，而不是证明所有任务都固定节省三分之二成本。任务类型、harness、最大轨迹、采样温度和失败重试都会改变实际账单。
评测亮点与证据等级
Inkling 的发布表覆盖很广。官方给出的代表性结果包括 SWE-Bench Verified 77.6%、SWE-Bench Pro Public 54.3%、Terminal-Bench 2.1 63.8%、HLE with tools 46.0%、MMMU Pro 73.5%、VoiceBench 91.4%。这些数字显示它不是只会文本推理的模型，但不能脱离脚注横向排序。
| 评测 | Inkling 官方结果 | 发布方披露的方法边界 | 当前可得出的结论 |
|---|---|---|---|
| SWE-Bench Verified | 77.6% | Inkling 使用 bash-only harness | 说明官方编码评测较强，待同 harness 复现 |
| Terminal-Bench 2.1 | 63.8% | Inkling 使用内部 coding harness | 不能与不同 harness 结果直接等号比较 |
| HLE with tools | 46.0% | 全表按 effort 0.99、temperature 1.0 | 反映高 effort 配置，不代表默认成本 |
| MMMU Pro | 73.5% | 对照分数部分取自 Artificial Analysis | 可用于定位，仍需核对版本和运行配置 |
| VoiceBench | 91.4% | 加系统消息适配硬编码答案格式 | 结果对输出格式敏感 |
| ForecastBench | 61.1、63.7 | 使用不同于发布版的检查点 | 不能当作发布权重的精确成绩 |
发布材料并非完全没有外部口径。团队表示，对 HLE、GPQA Diamond、GDPVal、Tau 3 Banking、AA Omniscience、MMMU Pro 等项目，在适用时采用 Artificial Analysis 报告的对照成绩；安全测试也包含外部测试者。不过，Inkling 自身的整张发布表仍由发布方整理，多个编码和多模态项目明确使用内部 harness、特别系统提示或内部运行。更准确的信源标签是“官方发布、评测主要待独立复现”，而不是“已有全面第三方验证”。
官方主动承认 Inkling 不是最强总体模型，这一点比单项排名更重要。发布表中，闭源模型在多项推理、编码和视觉任务上领先；部分开放权重模型也在特定项目超过 Inkling。Thinking Machines Lab 的卖点不是“全面第一”，而是多模态输入、可控 thinking effort、可下载权重和 Tinker 微调可以落在同一个底座上。评估它是否有价值，应看定制后的任务收益和部署成本，而不是从一张综合图外推“最强”。
Inkling-Small 是同日预览，不是同等发布
Inkling-Small 与 Inkling 在 7 月 15 日同一篇公告中出现，但发布状态不同。Small 是一个 276B 总参数、12B 激活参数的 MoE，使用相似预训练配方和同一套可扩展后训练栈。官方 preview 表称它在 HLE with tools、GPQA Diamond、IFBench、MCP-Atlas、CharXiv RQ with Python、MMAU 和 StrongREJECT 等若干项目接近或超过大模型，同时在 Terminal-Bench、SimpleQA 和部分音频任务明显落后。
不能把这些预览成绩写成已经可下载的正式产品。原文明确表示团队“currently finishing the testing of Inkling-Small”，并将在工作完成后发布 full weights。也就是说，当日真正完成全量权重发布的是 Inkling；Inkling-Small 只是同日 preview。276B/12B 提供了一个更低延迟、低成本方向，但它的最终权重、正式配置和第三方部署表现仍未落地。
Small 的存在也暴露了一个值得跟踪的方向：更大的总参数不一定在所有任务上更好。官方把 Small 的部分成绩归因于更好的预训练数据和配方，而两者共享后训练栈。如果正式版复现 preview，Thinking Machines Lab 的产品线可能不是单纯用参数规模分档，而是用不同“总参数—激活参数—数据配方—effort”组合覆盖编码、评分、合成数据和多模态任务。
Inkling 把开放权重竞争从参数纪录推进到产品组合：“可下载底座”和“托管后训练服务”首次在 Thinking Machines Lab 的同一产品面会合。Apache-2.0 权重让企业保留自部署、审计和迁移的选择；Tinker 则承接不想自建大规模训练基础设施的团队。开放权重降低供应商锁定，托管微调又把复杂度重新带回发布方平台，这是一种比单纯 API 更灵活、也更有商业闭环的组合。
近 1T 总参数本身更像能力和工程压力的共同标签。MoE 把每 token 激活规模压到 41B，但不会让完整权重凭空消失。对于大多数团队，下载权重只是第一步；能否以合理成本加载 108 个 BF16 主分片、处理跨节点通信、支持长上下文并维持多模态吞吐，才决定“开放”是否转化为可用。NVFP4 和多家推理框架的同步接入，说明发布方知道部署生态是成败关键。
早报判断是，Inkling 当前最有竞争力的定位应落在“可定制的开放多模态底座”。发布方主动否认总体最强，反而让评估标准更清楚：一看独立复现后是否仍有稳定的广谱能力；二看 Tinker 微调能否用较少数据获得领域增益；三看 BF16 与 NVFP4 的质量和成本差距；四看 64K、256K 与 1M 之间的产品鸿沟何时缩小。
这套定位也有明显反面。开放权重不等于可低成本部署，Apache-2.0 不等于数据透明，内部 harness 高分不等于生产可靠。尤其是编码 Agent 任务，工具定义、系统提示、轨迹上限和网页搜索污染处理都会改变分数。只有外部团队拿相同权重、公开 harness 和固定配置跑出接近结果，Inkling 的性能叙事才会从“官方可信披露”升级为“可复现事实”。
Inkling-Small 可能比大模型更能检验这条路线。如果 276B/12B 正式版能保持 preview 中的部分优势，并显著降低时延和部署门槛，它会说明 Thinking Machines Lab 的核心资产是数据与后训练栈，而不是单一超大检查点。反之，如果 Small 延期、成绩回落或权重生态迟迟不齐，产品线就会更依赖大模型和 Tinker 的托管能力。
开发者与企业应如何评估
研究团队首先要建立可复现基线。下载的权重版本、提交哈希、精度格式、推理框架、系统提示、effort、温度、最大 token、工具 schema 和超时都应记录。Inkling 的发布材料已经证明这些变量会影响结果：编码评测使用特定 harness，VoiceBench 对答案格式敏感，预测评测甚至使用了不同于正式发布的检查点。缺少实验记录，复现失败无法判断来自模型、框架还是配置。
部署团队需要分别测 BF16 和 NVFP4。BF16 仓库的 108 个主分片体现了完整检查点的工程体量；NVFP4 面向 Blackwell 的高效推理，但“更省资源”不能自动推导为“质量无损”。至少应测试首 token 延迟、持续吞吐、并发、长上下文内存、跨卡通信、多模态预处理、工具调用稳定性和关键任务准确率。对没有相应硬件的团队，第三方 API 或 Tinker 可能比自建更现实。
微调团队则要区分模型上下文和训练服务上下文。模型宣称最高 1M，不代表 Tinker 当天可以用 1M 样本训练；实际选项是 64K 和 256K。训练数据管线、样本打包和评测集都应按所选档位设计。若业务依赖超长代码库、长音频或大量图像，必须先确认输入预处理和有效上下文是否达到需求，而不是只读模型卡上限。
企业采购还要把限时价格当作促销变量。原文没有给 50% 优惠的截止日期，预算模型至少要计算优惠期和恢复价两种情景。更重要的是比较完整任务成本：训练数据整理、微调调用、评测、检查点导出、推理、人工复核和失败重跑都应计入。一个模型在发布期五折，不代表其长期总拥有成本低于更小模型。
接下来看什么
第一，等待独立复现。最有价值的不是再做一张综合雷达图，而是固定版本、公开 harness、公开提示词和硬件配置，复现 SWE-Bench Verified、Terminal-Bench 2.1、MMMU Pro、VoiceBench 以及长上下文检索。特别要确认网页搜索污染的处理是否一致。
第二，观察部署曲线。BF16、NVFP4 以及不同推理框架之间的吞吐和质量差异，会决定 975B/41B 的 MoE 是否能超出少数大型算力团队。若社区很快提供稳定量化、张量并行配方和可复现容器，Apache-2.0 权重的扩散速度会更快。
第三，观察上下文产品化。1M 是模型支持上限，64K 与 256K 是 Tinker 当日选项。何时开放更长训练与采样配置，长上下文在图像、音频和工具轨迹中是否仍稳定，都会直接影响它作为交互模型后台的价值。
第四，观察 Inkling-Small 的正式发布。Small 当前只是同日 preview，不能与已经开放权重的 Inkling 并列写成“两个模型正式开源”。它何时完成测试、以何种许可和精度发布、是否保持 276B 总参数、12B 激活参数以及预览成绩，是判断这家公司能否形成模型家族的关键。
最后，观察促销之后的真实价格。发布公告只承诺限时 50% discount，没有给截止日。优惠结束后的 Tinker 训练、采样与长上下文价格，叠加自部署硬件成本后，才能回答 Inkling 是一个有竞争力的开放基础设施选择，还是一个技术上开放、经济上仍高度集中于大客户的模型。