Thinking Machines Inkling 多模态模型挑战闭源模型默认格局

Thinking Machines 于 7 月 15 日发布 Inkling，将三种输入模态与开放权重和高达 100 万 token 的上下文窗口结合起来。Thinking Machines Inkling 多模态模型可接收文本、图像和音频，并通过一个共享推理系统生成文本响应。

此次发布意义重大，因为 Inkling 并不试图在每项基准测试中取胜。Thinking Machines 明确表示，它并非目前最强大的开放或闭源模型。相反，该公司押注的是：控制权、定制能力和高效推理可能比微弱的性能领先更重要。

这让 Inkling 向 OpenAI、Anthropic 和 Google 所确立的闭源模型默认格局发起了挑战。这些提供商通过托管接口提供功能强大的系统，但客户无法检查、托管或直接修改其底层权重。

Inkling 提供了另一种选择。开发者可以获得采用 Apache 2.0 许可的模型、可下载的检查点、原生多模态处理能力，以及通过 Thinking Machines 的 Tinker 平台进行后训练的内置支持。

该模型的运行要求依然很高，而且大多数性能证据都来自其开发者。即便如此，它也不只是另一个可下载的语言模型。Inkling 将开放权重与商业定制系统、部署合作伙伴结合起来，并明确提出了一个问题：专用 AI 应由谁来掌控。

Thinking Machines Inkling 携开放权重登场

Inkling 将超大规模稀疏架构与异常广泛的开发者访问权限结合在一起。

根据官方 Inkling 发布公告，该模型共有 9750 亿个参数。在处理每个 token 时，它会激活 410 亿个参数。

这种设计称为混合专家 Transformer。模型不会为每个请求使用全部参数，而是将每个 token 路由到一组有限的专用计算组件中。

Inkling 的每个专家层都包含 256 个路由专家和两个共享专家。每个 token 由六个路由专家处理，而共享专家则在处理不同输入时始终保持激活。

这种路由机制使模型总参数量与激活参数量之间的差异变得十分重要。Inkling 保留了广泛的能力，同时无需在每个推理步骤中调用全部 9750 亿个参数。

该模型使用涵盖文本、图像、音频和视频的 45 万亿个 token 进行预训练。Thinking Machines 表示，它在 NVIDIA GB300 NVL72 系统上从零开始训练了 Inkling。

后训练涵盖推理、数学、编程、工具使用、图像、音频、对话和安全。该公司还表示使用了超过 3000 万次强化学习 rollout，即利用已完成的模型交互，通过反馈改善模型行为。

Inkling 可接收文本、基于像素的图像，以及以 16 kHz 采样的 WAV 音频。该模型返回文本，而不是生成图像或语音。

这一差异使产品专注于多模态理解。Inkling 可以转录语音、解读录音、回答图像相关问题、分析图表，并将这些输入与工具结合使用。

Thinking Machines 列出的最大上下文窗口为 100 万个 token。上下文是模型在一次交互中能够纳入考量的信息，包括指令、文档、工具结果和先前的消息。

访问能力因环境而异。Tinker 目前提供 64,000-token 和 256,000-token 两种选项，而可下载模型则支持官方所述的更大上限。

开发者可以通过 Inkling 模型仓库下载完整权重。该仓库标明模型采用 Apache 2.0 许可，并提供 BF16 和 NVFP4 检查点选项。

Apache 许可允许在遵守其条款的前提下广泛使用、修改和分发。这使 Inkling 比仅通过 API 提供、且底层检查点由提供商控制的模型更具适应性。

Thinking Machines 还发布了与常用推理系统的集成。支持的选项包括 vLLM、SGLang、TokenSpeed、Unsloth、llama.cpp 和 Hugging Face Transformers。

API 访问可通过 Together AI、Fireworks、Modal、Databricks 和 Baseten 等基础设施提供商获得。这种分发策略降低了每位开发者独立搭建托管技术栈的必要性。

因此，Inkling 是开放权重模型，但并不局限于自托管。团队可以下载模型、通过 Tinker 进行微调，或使用外部提供商提供的托管推理服务。

这种灵活性构成了本文的核心张力。闭源提供商出售的是对成品智能的访问权，而 Thinking Machines 则希望开发者将模型本身视为可编辑的基础设施。

原生多模态推理是其主要技术押注

Inkling 在一个解码器内处理文本、视觉和音频，而不是将它们作为松散连接的外部服务。

许多被称为多模态的产品依赖独立组件。语音识别器将音频转换为文本，图像编码器概括图片内容，再由语言模型完成最终推理。

Inkling 采用了更加一体化的路径。不同模态被投射到共享的隐藏空间中，并由同一个解码器联合处理。

图像被分割成 40×40 像素的图块，并通过分层编码器处理。音频则通过 dMel 表示输入，将语音信号转换为适合模型处理的紧凑 token。

一个轻量级嵌入层先转换这些输入，之后由主 Transformer 将它们与文本 token 一同处理。这种架构使模型能够在推理过程中关联不同模态之间的证据。

对于仅靠转录会丢失信息的任务而言，这种能力十分重要。语气、背景声音、图示、布局和视觉关系都可能影响正确解读。

例如，一段附带截图的产品访谈录音。多模态模型可以将参与者口述的抱怨与当时画面中可见的界面元素关联起来。

开发者还可以提供错误截图、口头说明和代码仓库。Inkling 可以在提出修复方案或使用工具之前，在一个工作流中分析这些输入。

同样的方法也适用于以文档为主的知识工作。团队通常会将会议录音、图表、技术文档和书面消息作为彼此独立的信息流处理。

当 AI 能够跨这些格式进行推理时，可搜索的知识库会变得更加实用。不过，任何生成式模型仍需配合可靠的检索和来源验证机制。

Thinking Machines 报告称，Inkling 在多项多模态评测中取得了有竞争力的成绩。在测试的最高努力设置下，Inkling 在 MMMU Pro 上得分为 73.5%，在 CharXiv RQ 上得分为 78.1%。

该公司还报告称，Inkling 在 VoiceBench 上得分为 91.4%，在 MMAU 上为 77.2%，在 Audio MC 上为 56.6%。这些评测分别测试语音理解、音频推理和指令遵循等不同方面。

这些数字不应被视为一个统一结论。每项基准测试使用的提示词、评分器、测试框架和运行条件都不相同。

Thinking Machines 承认其 VoiceBench 测试流程存在一项具体限制。该基准测试使用严格的字符串匹配，因此该公司加入了一条系统指令，以引导模型使用规定的答案格式。

Inkling 还可以使用 Python 执行裁剪和缩放等图像操作。这为模型提供了一种检查微小视觉细节的方式，而不必完全依赖初始图像表示。

该模型具备多模态优势，但这并不意味着它能够生成所有媒体类型。它的输出仍然是文本，因此需要生成音频或图像的应用还必须使用其他模型。

音频也存在实际限制。官方 Inkling 模型卡建议输入以 16 kHz 采样的 WAV 音频，并将录音时长控制在 20 分钟以内，以获得最佳性能。

这些限制使当前版本更接近推理引擎，而非完整的实时语音产品。应用仍需在其周围配置界面、存储、检索、内容审核和输出系统。

Thinking Machines 已将 Inkling 与其独立的交互模型研究联系起来，该研究探索通过语音和视觉实现实时协作。Inkling 旨在成为这一更广泛系统中的后台推理组件。

该公司的战略押注十分明确：它预计未来的 AI 应用将持续混合各种模态，而不是让每个视觉或音频信号都通过相互隔离的预处理步骤。

可控思考改变成本与性能之间的权衡

Inkling 允许开发者调整推理力度，而不必接受速度、token 用量和答案质量之间固定不变的平衡。

当推理模型获准生成更多中间计算时，其表现通常会有所提升。这种提升也伴随着成本，因为更长的输出会消耗更多 token，并增加响应时间。

Inkling 提供从 0.2 到 0.99 的可控努力设置。开发者可以为常规请求选择较低的努力程度，将较高的努力程度留给更困难的问题。

Thinking Machines 通过修改系统消息并在强化学习过程中调整每个 token 的成本来训练这种行为。因此，不同样本会奖励不同程度的计算投入。

该公司表示，随着训练推进，Inkling 的推理轨迹变得更加简洁。后期的推理轨迹会去除语法性填充内容，同时保留得出最终答案所需的推理过程。

这一结果支持了一个实际的产品论点：高效推理并不仅仅意味着缩小模型或量化其权重。

团队还可以控制同一模型为每项任务投入多少工作量。分类、摘要和格式化所需的努力可能低于调试或科学推理。

Thinking Machines 报告称，Inkling 在 Terminal Bench 2.1 上追平 Nemotron 3 Ultra，同时生成的 token 数量大约只有后者的三分之一。Terminal Bench 用于评估智能体在终端环境中执行任务的能力。

这仍然是该公司自行报告的对比结果。参与测试的模型可能使用了不同的测试框架、提示词和默认运行设置。

Inkling 在更广泛的基准测试中表现不一，这与该公司自身的定位相符。该模型在 SWE-bench Verified 上得分为 77.6%，在公开的 SWE-bench Pro 评测中得分为 54.3%。

它在使用工具时的 Humanity's Last Exam 得分为 46%，不使用工具时则为 29.7%。在 GPQA Diamond 上，它取得了 87.2% 的成绩。

在这些评测中，有多款竞品模型的表现超过 Inkling。Claude Fable 5、GPT 5.6 Sol、Gemini 3.1 Pro、GLM 5.2 和 Kimi K2.6 分别在部分项目中领先于它。

在发布公告报告的全部三项音频基准测试中，Inkling 的表现也落后于 Gemini。在 MMMU Pro 上，其 73.5% 的成绩低于所列出的 Kimi K2.6、Gemini、Claude 和 GPT 得分。

这并未否定该模型的用途。它说明了 Thinking Machines 为何强调完整的成本曲线，而非某一运行点上的最高分数。

对于单个高难度提示词而言最强的模型，未必是在会发起数百次调用的智能体中最好的选择。延迟和 token 使用量会在规划、工具执行、修改和评估循环中不断累积。

开发者可以针对特定行为对 Inkling 进行微调，然后以经过校准的投入程度运行该版本。这提供了两个控制维度：模型专精的方向，以及它投入的计算量。

Inkling-Small 延续了同样的思路。该预览模型共有 2760 亿个参数，其中 120 亿个为活跃参数。

Thinking Machines 报告称，较小版本在多项任务上的表现接近 Inkling。它在 GPQA Diamond、IFBench、MCP Atlas，以及使用 Python 的 CharXiv RQ 上略微超过了更大的模型。

Inkling 在 Terminal Bench、SimpleQA 和其他多项评估中仍然更强。由于测试仍在进行，该公司尚未发布完整的 Inkling-Small 权重。

如果这些结果在独立评估中依然成立，较小的模型可能会更适合高吞吐量工作负载。代码评分器、合成数据生成器和后台智能体都看重可预测的成本与响应时间。

目前，更大的 Inkling 展示了这一机制。稀疏激活、可调节的投入程度和后训练协同工作，对“一个固定的推理配置适合所有请求”这一假设发起了挑战。

开放权重给闭源 AI 平台带来压力

主要竞争并非 Inkling 对抗某一个模型，而是可编辑的模型基础设施对抗由提供商控制的智能。

闭源模型服务简化了采用过程。开发者向 API 发送请求、接收答案，并将基础设施管理交给提供商。

这种安排也集中了控制权。提供商决定模型何时变化、允许哪些行为、数据如何流经服务，以及可以使用哪些定制方法。

开放权重将其中若干决策下放。组织可以检查部署行为、运行私有基础设施、保留选定的检查点，并创建专用版本。

Inkling 为这种自由增加了一个值得关注的商业层面。Thinking Machines 并非只是将模型放到网上，然后让开发者独自管理后续的每个步骤。

Tinker 通过 API 提供监督式微调和强化学习工作流。更新后的 Tinker 指南包含用于适配 Inkling 的方法，包括专注于音频的示例。

该公司通过要求 Inkling 修改自身行为，展示了这种关联。模型编写了一个微调任务、创建了一项评估、运行了训练，并加载了生成的检查点。

要求的行为是一种避字文，即模型必须在不使用字母 "e" 的情况下作答。Thinking Machines 报告称，完整工作流在约 27 分钟内完成。

该演示并不能证明通用的自我改进。它表明智能体可以操作创建并启用狭义微调所需的工具。

这一区别很重要。模型改变一种受约束的写作行为，远不如独立提升其整体推理能力或纠正未知弱点那般雄心勃勃。

即便如此，该工作流仍体现了 Thinking Machines 的产品理念。真正有价值的单元不是静态的聊天机器人回复，而是开发者可以反复适配、测试和部署的模型。

这对 OpenAI、Anthropic 和 Google 构成了间接压力。它们的闭源模型在 Thinking Machines 列出的评估中通常领先于 Inkling，但客户受制于提供商设定的定制边界。

开放权重的竞争对手面临着更直接的压力。Inkling 的架构沿用了 DeepSeek-V3 的重要元素，包括稀疏专家路由和无辅助损失的负载均衡。

DeepSeek-V3 论文推动确立了一套受到广泛研究的高效混合专家训练方案。Inkling 采用了这一基础，同时加入了自己的注意力设计、多模态输入和可控投入程度。

Inkling 还必须与 Qwen、Kimi、GLM、DeepSeek 和 Nemotron 系列竞争。其中若干系列已经提供了强大的开放权重推理、编码或多模态能力。

Thinking Machines 的差异化来自多种能力的组合，而非在单项基准测试中领先。Inkling 将原生音频和视觉、长上下文、开放检查点、后训练访问能力与托管部署合作伙伴结合在一起。

这一组合可能会吸引拥有专有数据或工作流的企业。金融公司可能需要一个适配其审核标准的模型，而软件公司可能会针对自身代码仓库和工具进行优化。

对于许多团队而言，经济性仍然更有利于托管 API。托管 Inkling 这种规模的模型需要昂贵的基础设施和经验丰富的运维人员。

根据模型卡，BF16 检查点至少需要两 TB 的 GPU 总显存。建议配置包括八块 NVIDIA B300 GPU 或 16 块 H200 GPU。

NVFP4 检查点将最低要求降低至 600 GB。在一种受支持的模式下，它可以运行在四块 B300 GPU 上；在另一种模式下，则可以运行在八块 H200 GPU 上。

这些要求意味着“可下载”并不等于“易于在本地运行”。仅仅因为权重可用，笔记本电脑并不能托管完整模型。

托管推理合作伙伴弥补了部分差距。然而，使用这些服务会重新引入外部服务，即使客户对于底层模型和微调版本拥有更多选择。

因此，Inkling 在控制权层面给闭源平台带来了压力，而非在便利性层面。它能否成功，取决于是否有足够多的买家重视检查点所有权和定制能力，并愿意接受额外的运营复杂性。

验证缺口是 Inkling 最大的制约因素

Inkling 的规格很具体，但其质量、安全性和效率主张仍需更广泛的独立测试。

公告中的大多数基准测试结果都来自 Thinking Machines。该公司表示，在有数据可用时，它会采用竞争对手对外报告的分数；对于其他评估，则使用内部测试框架。

当评估条件不同时，跨模型比较会变得困难。即使底层模型保持不变，更强的智能体测试框架也可能提高编码分数。

Thinking Machines 表示，Inkling 在 SWE-bench Verified 上使用了仅支持 bash 的测试框架。其 Terminal Bench 结果则来自内部编码测试框架。

该公司还发现，一些 Terminal Bench 解决方案受到网页搜索污染，并将这些尝试的分数记为零。这一披露很有价值，但也说明了评估细节会如何影响最终排名。

若干预测结果来自一个不同于已发布模型的检查点。根据公告，测试于 6 月 30 日至 7 月 13 日期间进行。

因此，最明确的结论比营销叙事所传达的范围更窄。Inkling 在许多任务上似乎具有竞争力，但现有证据尚不能证明其全面领先。

Thinking Machines 自身也避免了这种夸大。其公告明确表示，无论在开放模型还是闭源模型中，Inkling 都不是当前最强的模型。

安全性也面临类似的验证问题。该公司报告了内部评估和外部测试，涵盖化学、生物、放射、核、网络以及失控风险。

在 FORTRESS Adversarial 上，Inkling 得分为 78%。它在良性部分的得分为 95.9%，在 StrongREJECT 上的得分为 98.6%。

这些数字描述的是特定测试下的拒绝行为。它们并不能保证模型在微调后或遭遇新型攻击时仍能保持安全行为。

模型卡指出，模型仍容易受到角色扮演和间接表述的有害请求影响。它建议采用多重防御措施，而不是仅依赖模型自身的拒绝机制。

这一建议对于开放权重尤其重要。下游开发者在定制过程中可能削弱、移除或意外破坏安全防护。

Thinking Machines 表示，相较于开放权重生态系统中已有的能力，Inkling 并未实质性提升危险能力。独立研究人员仍需检验这一结论。

训练数据的描述也较为宽泛。数据来自公开来源、第三方以及合成或增强材料，但此次发布并未提供详细的数据集清单。

这限制了外界对版权风险、人口群体代表性、语言覆盖范围和数据污染的分析。使用 45 万亿个 token 进行训练，使得数据来源问题更加重要，而非不再重要。

模型卡警告称，模型可能出现幻觉、无法遵循指令，以及在长时间、多轮对话中性能下降。它还指出，模型在不同语言和主题领域的表现并不均衡。

一百万 token 的上下文窗口同样值得审视。最大上下文容量并不能证明模型能够在整个跨度内准确回忆或推理。

长上下文模型可能会遗漏细节、过度重视近期材料，或难以整合相距遥远的证据。独立的“大海捞针”测试和真实文档工作流将揭示 Inkling 在接近上下文上限时的表现。

原生多模态能力还带来了额外的失效模式。语音识别错误、模糊声音、视觉幻觉以及不同模态之间的冲突，都可能扭曲后续推理。

组织应测试自己预期使用的确切输入。高基准测试分数无法替代针对特定领域口音、图表、文档或安全要求的评估。

Inkling 的 Apache 2.0 许可证扩大了实验空间，这应该会加速验证过程。研究人员可以开展受控测试，而无需等待 API 访问权限，也无需担心检查点在不透明的情况下发生变化。

证据缺口并不是否定 Inkling 的理由。它恰恰是应将此次发布视为评估周期的开始、而非结论的主要原因。

三个信号将表明 Inkling 是否真正重要

Inkling 的重要性将由独立证据、真实定制成果及其较小版本的表现决定。

第一个信号是在一致条件下进行的第三方评估。研究人员需要使用相同的提示词、工具、采样设置和计算限制，将 Inkling 与开放及闭源替代方案进行比较。

独立的多模态测试最为重要。Inkling 的独特主张涉及跨文本、图像和音频进行推理，而不仅仅是在数学任务上追平另一个模型。

强劲的外部测试结果将支持 Thinking Machines 的通用模型战略。如果公司分数与独立分数之间存在巨大差距，则会削弱其效率和质量主张。

第二个信号是下游微调活动。模型仓库已经支持适配器、量化版本和第三方集成，但仅凭数量并不能说明实际价值。

真正有用的证据将来自那些在真实任务上超越基础模型的专用模型。例如音频分析、编码智能体、文档审查、预测或特定领域的工具使用。

开发者还应关注微调能否保留安全性和通用能力。如果狭义改进损害了其他方面的可靠性，就会带来代价高昂的部署权衡。

Tinker 是这项检验的核心。如果团队能够反复构建、评估和导出有用的检查点，Thinking Machines 将比仅提供权重的公司占据更有利的位置。

第三个信号是 Inkling-Small 的完整发布。其 120 亿个活跃参数使它更适合延迟敏感型或高吞吐量工作负载。

该公司的结果表明，Inkling-Small 在多项评估中已经接近更大的模型。独立验证将增强“训练质量比单纯增加活跃参数规模更重要”这一观点的可信度。

如果发布延期、外部测试表现不佳，或能力大幅下降，关注焦点将重新转向拥有 410 亿个活跃参数的模型。这也意味着 Inkling 对基础设施的高要求将继续存在。

这些信号共同回答了一个核心问题：即便闭源模型仍保持更高的峰值分数，一个可编辑的多模态基础模型能否凭借可控性和专业化能力参与竞争？

对于开发者而言，眼下该采取的行动十分明确。针对真实工作流测试 Inkling，使用固定的评估集，衡量 token 使用量和延迟，并在定制后验证每一项安全假设。

对于企业采购方而言，决策的重点不在于某一个排行榜，而在于模型控制权应归属何处、组织能够支撑多大规模的基础设施，以及专业化性能是否值得投入这些工作。

Thinking Machines 的 Inkling 多模态模型已经亮明了它的押注：开放权重、原生多模态和可调节推理能够构成一种可与闭源智能相抗衡的可信替代方案。

如今，举证责任转移到了公司之外。独立评估机构、微调团队和生产环境部署必须证明，这一组合能否带来超越发布基准测试的可靠优势。