Thinking Machines

定义与本文中的位置

Thinking Machines 在原文里被作为相关技术工作的来源提到，重点不在机构背景，而在其被引用的那条底层确定性思路。

文中的具体语境是：SGLang 基于 Thinking Machines 的工作做了 batch-invariant kernel，用来让计算结果不再依赖同一批里有多少请求。

也就是说，Thinking Machines 在本文承担的是一个“技术参照物”的角色：它代表一种试图从推理内核层面减少系统级非确定性的路线。

相关技术主张：batch-invariant kernel

原文给出的核心点很具体：

• 传统推理服务中，底层 matmul、attention 等 kernel 的结果会受 batch size 影响。
• batch size 一变，浮点累加顺序就可能变化。
• 浮点累加不满足结合律，因此顺序变化会让最后几位出现差异。
• 这些细小差异会继续传播，最终导致同一输入在不同负载下输出不完全一致。

Thinking Machines 被提及，正是因为其相关工作指向一种解决办法：让 kernel 变成 batch-invariant，即不再依赖这一批里有多少请求。

原文对这种思路的描述是：同一个输入永远走同样的累加顺序，于是进去出来可以做到逐字一致。

这使它天然对应到一个目标：内核层复现。

在本文中的作用：用来对照工程取舍

本文并没有把 Thinking Machines 这条路线当成主线方案来展开，而是把它放在“别把确定性推到底”的部分，作为与 确定性笼子 的对照。

这种对照关系非常明确：

• Thinking Machines 相关方向：从底层 kernel 入手，尽量消除 batch 波动带来的非确定性。
• 确定性笼子：不在内核层死磕逐字一致，而是在系统上层把 LLM 包进确定性的工程链路。

文章要表达的不是前者“没用”，而是ToB AI 的主问题不在这里。

在作者看来，企业客户真正要的不是单纯“每次字字一样”，而是：

• 结果正确；
• 结果可复现；
• 结果出了问题能回溯依据并让人签字背书。

所以 Thinking Machines 代表的底层确定性路线，在文中主要被用来说明一个工程判断：底层复现能力与 ToB 交付价值，并不是一回事。

为什么不是 ToB 的主解法

原文对这条路线给出的限制条件和边界比较清楚。

1. 它解决的是“逐字一致”，但 ToB 更在意“结果正确”

文中反复强调：确定性 不等于 正确性。

就算一个模型在底层完全可复现，也可能只是“一字不差地错一百次”。

因此，Thinking Machines 所代表的底层确定性方案，最多是在“可复现”这一维度上加强了系统，却不能自动解决业务口径、规则合规、结果核验这些 ToB 真正关键的问题。

2. 它有明确性能代价

原文不是泛泛而谈，而是给了具体数字，并通过 SGLang 引出这类方案的成本：

• 开启 batch-invariant 后，推理减速 25% 到 45%；
• 主流后端平均减速 三成出头；
• 官方还明确写了其用途“主要用于调试和复现”。

这说明这类思路不是没有价值，而是价值和代价都很明确。

如果业务已经通过 确定性笼子 在语义层、校验层、结果核验层中和了逐字抖动，那么再去为“用不上的逐字一致”支付三成左右的速度税，文章认为是不值的。

3. 它会牺牲动态批处理优化

原文还引用了更新的批评：这类确定性方案不适合真实的 LLM 服务系统，因为它把确定性变成每个请求都得交的固定税，并且会破坏一些高性能优化。

文中点名的优化包括：

• split-K
• shape-aware tiling

这些优化本来就是动态批处理有效的重要基础。

因此，Thinking Machines 这一路线在本文里被视为一种“更狠但更重”的底层办法，而不是大多数 ToB 查询系统应优先采用的路线。

适用场景边界

原文没有全盘否定底层确定性，而是给了一个明确主场：RL 训练，尤其是 on-policy 场景。

在这种情况下：

• 采样和训练必须使用同一套数值行为；
• 否则梯度对不上；
• reward 也可能崩掉。

所以在那里，逐字级、路径级的严格复现是“救命”的。

这构成了 Thinking Machines 相关思路的重要边界：

• 适合：对数值路径一致性要求极高的训练、调试、复现工作；
• 不适合作为主解法：大多数 ToB 查询、财务、报表、合规类交付系统。

文中对后者的判断很直接：这类业务通常只要求结果对、口径稳、依据可查，并不要求生成过程逐字一致。

与上层治理思路的关系

把 Thinking Machines 放回全文结构里看，它的重要性在于帮助作者划清两种路线：

第一种路线，是从底层去“压掉不确定性”； 第二种路线，是在上层把不确定性“关进笼子并读出来”。

后者也就是 确定性笼子，包括四道工程关卡：

• 意图层和执行层分家；
• 执行前规则校验；
• 结果出来后再做确定性核验；
• 任一环异常时可回退到保守但正确的默认行为。

在这套框架下，LLM 的逐字抖动并不是直接暴露给客户的最终结果，而是先经过语义抽象、规则校验和交叉验算。

因此，Thinking Machines 所代表的内核层方案，在文中更多是一个比较基准：它让人看到“从底层修”是可能的，但也让人看清“对 ToB 来说，未必该从这里修”。

与“不确定性是信号”的关系

文章还有一个更深的判断，也构成了对底层绝对确定性的保留态度。

文中援引 Stochastic CHAOS 一类观点：LLM 本质上是条件分布 (p(y|x))，而不是固定函数 (f(x))。

如果把这种分布硬压成单点输出，虽然系统看起来更“确定”，但也可能把模型真实的不确定性隐藏起来。

这对 ToB 反而危险，因为：

• 同一问题多次运行的答案分散程度，本身就是风险信号；
• 如果多次结果对不齐，说明模型没把握；
• 这时更合理的做法是报警、挂起或转人工。

因此，本文并不主张把 Thinking Machines 这类底层确定性思路无限上纲成唯一目标。

文章给出的态度是：确定性应当服务于交付，而不是把所有不确定性都抽干。

本文结论中的定位

综合全文，Thinking Machines 在本文中的定位可以概括为：

1. 它代表了一条真实存在的底层确定性技术路线。
2. 这条路线与 batch-invariant 紧密相关，核心目标是减少 batch 变化导致的非确定性。
3. 它适合被拿来讨论内核层复现、调试与特定训练场景。