Thinking Machines发布Inkling 2 Small：594B MoE模型支持视觉与可变推理开销

摘要：Thinking Machines Lab 发布第二代模型 Inkling 2 Small。该模型采用 594B 总参数、17B 激活参数的混合专家架构，支持图像输入与按请求调整推理开销，并在 Artificial Analysis Intelligence Index 获得 31 分，覆盖智能体编码、视觉、知识工作和推理任务。模型目前通过 Tinker 提供闭权重推理、微调与采样，官方计划在外部安全测试及红队评估完成后，以 Apache 2.0 许可证开放完整权重及检查点。

---

核心发布

Thinking Machines Lab 推出 Inkling 2 Small，定位为支持视觉输入、智能体编码与可变推理开销的通用 MoE 模型。其规模从上一代 Inkling Small 的 276B 总参数、12B 激活参数增至 594B 总参数、17B 激活参数。

官方称，新模型在 Artificial Analysis Intelligence Index 上取得 31 分，能力提升覆盖智能体编码、视觉理解、知识工作和推理。模型当前已接入 Tinker Playground，并开放微调与采样；完整权重计划在外部安全测试及红队评估完成后，以 Apache 2.0 许可证发布，检查点也将随之开放下载。

MoE架构如何理解

Inkling 2 Small 的核心是稀疏混合专家架构。594B 是全部专家及共享组件的参数规模，而 17B 表示单次典型前向计算中实际参与计算的参数量。两者并不矛盾：MoE 通过路由器为每个 Token 选择少量专家，将模型容量与单 Token 计算量部分解耦。

粗略而言，若路由较均衡，参数激活比例约为：

[ 17B / 594B \approx 2.9% ]

这一比例远低于稠密模型全部参数参与计算的方式。工程上的收益不是简单的“推理成本固定为 17B 模型”，而是模型拥有 594B 的参数容量，同时把每 Token 的专家计算控制在约 17B 规模。不过，实际成本还取决于专家并行方式、路由负载均衡、激活批次、KV Cache、视觉编码器及通信拓扑。

MoE 的关键难点是路由与部署。若热门专家在同一个请求或同一批请求中同时被选中，局部算力会成为瓶颈，即使平均激活参数量保持不变。所谓“variable effort”则允许系统按任务难度分配不同计算量，但原文未给出推理档位、路由阈值、延迟和吞吐数据，尚不能判断其调度粒度与实际成本曲线。

训练与强化学习

官方将能力提升归因于全流程训练改进，包括更高效的预训练和一次大规模的统一强化学习运行。统一 RL 训练可能减少多个训练阶段之间的策略漂移，并让编码、视觉和通用推理能力共享一套后训练流程；但统一并不天然等同于更高效或更稳定。

对 MoE 模型而言，RL rollout 的成本尤其取决于奖励验证、采样长度和专家分布。活跃专家在 rollout 过程中若负载不均，训练集群利用率会明显下降。原文没有披露训练算力、奖励构成、采样预算、上下文长度或 RL 超参数，因此“large, unified RL run”目前更像训练路线描述，而非可复现的技术细节。

基准成绩应如何解读

Artificial Analysis Intelligence Index 得分 31 表明 Inkling 2 Small 进入了更激烈的综合模型竞争区间，但该指数属于聚合指标，无法单独证明某个能力域已经领先。开发者仍需查看组成指标、提示模板、工具权限、推理预算以及是否采用 variable effort。

尤其值得注意的是“远超上一代”必须结合计算预算解释。如果旧模型使用较低推理投入，而新模型允许增加测试时计算，那么提升可能同时来自模型训练和额外采样预算。要判断架构与训练收益是否真实，应保持提示、工具、上下文、并发度、输出长度和推理预算一致，再比较准确率、延迟、吞吐与总 token 成本。

部署权衡与工程门槛

尽管 17B 激活参数低于 594B 总参数，Inkling 2 Small 仍不是消费级单卡模型。仅权重以常见半精度格式计算，594B 参数就约需 594GB 空间；若采用 BF16，连同 KV Cache、视觉编码器、运行时与通信缓冲区，实际需求更高。若使用 FP8，理论权重体积可降至约 594GB，仍需多卡高内存系统；INT4 虽能进一步降低存储，却会引入量化误差、MoE路由偏差以及不同专家的精度敏感度差异。

如果权重按 100B 参数以下的小模型直接加载到单卡，通常需要离线分片或按专家放置。真实部署还要考虑专家亲和性、跨节点 All-to-All 通信、动态批处理以及路由热点。理论上的 17B 激活量更接近中等规模稠密模型的单 Token 计算负担，但 594B 权重必须常驻多卡集群，存储、并行启动和故障恢复仍是显著门槛。

开发者如何落地

目前最现实的路径是使用 Tinker 完成 API 推理、微调和采样。对于计划本地部署的团队，建议按以下顺序验证：

1. 先确认推理档位：记录 variable effort 如何映射到 token 上限、采样次数和延迟，避免不同请求的成本不可控。
2. 建立强基线：在固定预算下与上一代 Inkling Small及同规模开源 MoE 比较编码、视觉和工具调用成功率。
3. 核算端到端成本：除权重显存，还要计入多卡互联、专家通信、KV Cache、图像预处理及长上下文占用。
4. 等待权重后再评估微调：完整检查点开放后，重点验证不同专家的采样数据配比、路由稳定性和量化后质量损失。
5. 独立进行安全测试：开源只是分发方式变化，不代表模型风险自然消失；仍应单独评估越狱、图像提示注入、工具调用越权和多模态输入污染。

后续观察

Inkling 2 Small 的关键增量不只是一个更大的 MoE，而是视觉输入、智能体编码和可变推理预算被整合到同一模型。真正决定其开发者价值的是三项尚未公开的数据：不同 effort 档位的实际延迟与 token 消耗、完整权重在多节点上的吞吐，以及微调后的任务增益是否超过额外训练成本。Apache 2.0 开放计划若按期完成，将使其进入可审计、可二次开发的模型竞争层；在此之前，Tinker API 是验证产品价值的主要渠道。

---

消息来源：Reddit r/LocalLLaMA (2026-11-06)

—— 完 ——

主题标签： #Inkling 2 Small 关注 #Thinking Machines Lab 关注 #MoE架构 关注 #多模态模型 关注 #智能体编码 关注