技术复盘最容易写成一串顺利某个内核完成、某个模型跑通、某种精度提升。真正改变实现的常常是被推翻的假设补零没有保护输出尾块独立分配没有实现共享统计量只对同一个 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 都输出大量无关细节反而淹没关键的状态转换。复盘时可以明确区分已经解释的失败和暂时消失的失败。加了延时以后不再复现不等于证明了同步正确换了一组输入以后误差变小也不等于修好了尺度。临时缓解可以记录但不能替代根因判断。下一次实验应尽量让原来的失败条件重新出现。这样留下的开放问题不会削弱文章。它给读者一个清楚的接口哪些结论可以复用哪些需要在自己的环境重新验证。技术工作常常就是沿着这些小接口继续推进复盘也应为这种继续留下空间。本文没有把这些后续实验说成已完成。复盘的作用是把暂时不知道的地方摆到桌面上让下一个人能够接着验证。被推翻的假设如果留下了反例就已经产生了可重复利用的价值。
