技术复盘最容易写成一串顺利：某个内核完成、某个模型跑通、某种精度提升。真正改变实现的，常常是被推翻的假设：补零没有保护输出尾块，独立分配没有实现共享，统计量只对同一个 query 有效。

这篇复盘讨论验证方法，也保留没有完成的实验和仍待解释的现象。

复盘同时记录已知证据、开放问题与下一项实验。

把问题分成三类，下一步才会具体

第一类是能独立证明的代数与格式。例如零点修正的常数项、E4M3 的合法编码、Softmax 的块合并关系。这些适合标准库小程序与枚举测试，输入应该故意包括容易失败的边界。

第二类是系统协议。例如共享块的回收、集合调用的参与者、设备完成事件。这类问题需要真实并发或至少明确的状态机。一个顺序数组模拟可以检查结果合同，不能证明没有数据竞争或死锁。

第三类是性能与质量。例如 tile 选择、KV 量化后的长上下文误差、chunked prefill 的延迟。它们需要固定硬件、模型、流量与统计口径。没有这些条件，就先不要把一个局部例子写成生产结论。

本月发布也可以变成检查线索

2026 年 10 月 20 日的 SGLang-TorchTPU 发布说明介绍了后端插件与形状 bucket。它适合引出编译缓存键和 padding 的问题，不需要照抄发布中的模型名单与性能结果。

10 月 15 日 Rust 1.99.1修复编译优化引出的链接依赖，也提醒我们保留工具链版本。一个小修订可能与某个特定目标关系很大，单看“代码没改”无法保证环境行为相同。

留一份真正能继续的清单

下次实验应写成可执行的问题：用哪个输入重现，期望结果是什么，什么结果会让方案停止。不要写“继续提升吞吐”这样无法失败的目标；可以写“同一模型、同一并发下，比较两个 chunk 预算的 TTFT 和 ITL 分布，同时检查输出与内存峰值”。

给失败结果留下一份可定位的记录

失败记录不必很长。保留触发输入、预期行为、实际行为和当前怀疑的边界，就能帮助下一次继续。若只写“今天修了一个量化问题”，后来很难判断新发现是不是同一个问题；若能指出“两个非零零点时展开式漏了长度因子”，对应反例就可以长期保留。

系统问题还需要时序。共享块在取消前后有多少所有者、设备任务何时完成、块何时回到空闲池，都比一次最终 checksum 更有解释力。日志也应有边界，避免每个 token 都输出大量无关细节，反而淹没关键的状态转换。

复盘时可以明确区分已经解释的失败和暂时消失的失败。加了延时以后不再复现，不等于证明了同步正确；换了一组输入以后误差变小，也不等于修好了尺度。临时缓解可以记录，但不能替代根因判断。下一次实验应尽量让原来的失败条件重新出现。

这样留下的开放问题不会削弱文章。它给读者一个清楚的接口：哪些结论可以复用，哪些需要在自己的环境重新验证。技术工作常常就是沿着这些小接口继续推进，复盘也应为这种继续留下空间。

本文没有把这些后续实验说成已完成。复盘的作用，是把暂时不知道的地方摆到桌面上，让下一个人能够接着验证。被推翻的假设如果留下了反例，就已经产生了可重复利用的价值。