SGLang
定义与本文中的身份
SGLang 在来源文章中不是作为通用框架综述展开，而是被当作一个“把底层推理做成逐字确定”的代表性例子提出。
文中明确提到，SGLang 基于 Thinking Machines 的工作，支持 batch-invariant kernel。它要解决的问题，是让同一个输入在不同批次条件下仍然走相同的累加顺序，从而使输出在字面上保持一致，不再因为 batch size 变化而发生逐字抖动。
这使它成为对抗系统层不确定性的一种底层技术路径：不是在业务层做校验和兜底，而是试图直接从推理内核层面减少“同样输入、不同并发条件下结果不同”的现象。
它解决的具体问题
文章前文指出，LLM 即使把 temperature 设为 0，也仍然可能不确定。根因不只在采样，而在服务系统和硬件调度层：
- 生产环境中的 batch size 会随负载波动；
- matmul、attention 等底层 kernel 的结果会依赖这一批一共多少请求；
- 浮点累加不满足结合律，累加顺序变化会让最后几位不同；
- 最终这种数值扰动可能传导成 token 级差异。
在这个背景下，SGLang 所代表的 batch-invariant kernel 路线，核心就是让“当前这一批有多少请求”不再影响同一输入的计算路径和累加顺序，进而追求 逐字级复现。
换句话说，SGLang 瞄准的是“同一输入永远给出同样字面输出”这一层的确定性，而不是业务语义层的纠错、审计或责任归因。
关键信息
支持 batch-invariant kernel
这是文中点名 SGLang 的核心原因。所谓 batch-invariant，可以理解为：无论请求处在怎样的动态批处理中，同一输入都尽量保持同样的数值计算顺序，不让 batch 变化影响输出。
文中的表述非常直接：有了这类 kernel，同一个输入“永远走同样的累加顺序，进去出来字字一致”。
追求的是逐字级复现
SGLang 在本文里对应的不是“结果大致稳定”，而是更严格的目标：逐字一致。
这意味着它关注的是 token 级别的可复现，而不是“语义差不多”或“最终结论一致”。文章正是借这个例子来区分：底层逐字确定性是一类能力，但它不等于确定性笼子里真正要交付的正确性与可审计性。
会带来明显性能代价
文中给出具体数字：
- SGLang 官方数据称，开启 batch-invariant 后，推理减速 25% 到 45%；
- 主流后端的平均损失在 三成出头。
这不是轻微开销，而是显著的吞吐与延迟代价。文章把它形容为一种“固定税”：为了逐字确定性，每个请求都要承担额外成本。
官方定位主要是调试与复现
文中还强调，SGLang 官方对白纸黑字写明：这项能力“主要用于调试和复现”。
这个定位非常关键。它说明即便在框架提供方看来，batch-invariant 也不是所有线上业务默认都该打开的通用最佳实践，而更像用于排查问题、比对行为、稳定复现实验条件的特殊模式。
为什么文中认为它不一定适合 ToB 查询
文章的立场不是否认 SGLang 的技术价值，而是指出它在多数 ToB AI 确定性笼子 摘要 所讨论的企业查询场景中，往往是“用错地方的锤子”。
原因主要有四层。
1. ToB 查询要的首先不是逐字一致，而是结果正确
文中反复区分三件事：
- 可复现；
- 正确；
- 可审计。
而 SGLang 这条路主要强化的是第一件事：可复现，尤其是逐字级可复现。
但企业客户真正关心的是“同样的问题能不能得到同样且正确、还能让我拿去汇报的结果”。如果答案本身错了，那么底层越稳定，只是“稳定地错”。
因此，SGLang 在文中被当作一个典型反例：它能强化底层一致性，但并不能替代业务上的口径校验、规则核验、越权检查与结果复核。
2. 确定性笼子已经在语义层中和了这类抖动
文章主张的主路径不是修改模型内核，而是搭建确定性笼子：
- 意图层和执行层分家；
- 执行前规则校验；
- 结果出来再交叉验算；
- 出现异常时可回退到保守但正确的默认行为。
在这种架构里，LLM 输出中的细微逐字波动，很多时候会在语义层和校验层被中和掉。也就是说，模型这次多吐一个 token 还是少吐一个 token，并不一定影响最终可交付结果。
既然业务链路已经把这种抖动“包住”了，再额外为底层逐字一致支付高额性能成本，性价比就未必成立。
3. 它会破坏动态批处理优化
文中提到更新的批评认为，这条路线并不适合真实的 LLM 服务系统，因为它会连带干掉一些支撑动态批处理效率的重要优化，例如：
- split-K；
- shape-aware tiling。
文章没有展开这些优化的实现细节，但意思很明确：为了保证 batch-invariant，你不仅要付出直接的推理减速，还可能牺牲服务系统依赖的吞吐优化能力。这对线上 ToB 查询系统尤其敏感，因为它们通常同时受正确性、响应速度和成本三重约束。
4. 大多数 ToB 场景并不要求逐字一致
文中直接给出判断：对绝大多数 ToB 查询场景，例如财务、报表、合规等，关键要求是“结果对”，而不是“措辞或 token 序列逐字一致”。
如果系统最终交付的是经过规则检查、口径校验和交叉验算的结果，那么底层生成文本是否每次都一字不差，通常不是采购与上线的决定性指标。
因此，作者认为在这些场景里，第一种解法——也就是 确定性笼子——往往已经足够；而把确定性继续往推理底层推到底，则容易走偏。
更适合它的场景边界
文章并没有说 batch-invariant 毫无用处，反而给出了一个更适合它的主场：RL 训练。
文中的理由是，在 on-policy 场景里，采样和训练必须依赖同一套数值行为，否则：
- 梯度可能对不上；
- reward 可能崩掉。
在这种情况下，逐字可复现或更严格的数值一致性，不是“锦上添花”，而是训练流程是否成立的前提。
所以，SGLang 在文中并非被全盘否定，而是被放回更合适的边界中理解：它对某些调试、复现、训练一致性场景很重要，但不应被直接套用为多数 ToB 查询系统的首选解法。