Baseten 在 GLM-5.2 上发现一个反直觉现象：对更多层进行量化，最终基准测试质量反而持平，吞吐量却提升了 20%。原因是不同层的量化误差方向相反，error(层A) + error(层B) 反而小于误差单独作用。这打破了「量化必有损」的直觉，意味着在特定模型上可安全选用更激进的精度方案，在不妥协质量的前提下挤出额外吞吐。

大模型推理时，每个 token 的 Key 和 Value 向量会被缓存起来避免重复计算，但 KV 缓存会随上下文线性膨胀——70B 模型在 128K 上下文时，KV 缓存占 50-60 GB，比模型本身还大。缓存感知路由的核心就是根据每个推理节点上 KV 缓存的实时分布，把新请求调度到能复用已有缓存的 GPU 上，从而跳过计算。阿里云已在 vLLM 框架中落地「精准模式」和「估算模式」两套路由策略，分别适用于多轮对话和长文档查询场景。

文章指出现有视频模型面临「二次注意力瓶颈」，自回归方案在长视频中质量漂移累积，扩散方案则受限于并行去噪的连贯性。字节 Seed 提出的 Mixture of Contexts（MoC）稀疏注意力机制，将长视频生成重构为信息检索任务，计算量削减 85% 且保持人物场景一致性。而香港大学的 VideoSSM 则走另一条路——用状态空间模型（SSM）替代注意力，实现一小时超长视频的连贯生成。两条路线都在挑战「长视频必须更贵」的假设。

文章提到 GLM-5.2 被用于优化运行 GLM-5.2 自身的内核，这指向一个正在形成的趋势：推理不再只是训练后的最后一步，而是与模型架构协同设计的系统工程。持久化 KV 缓存让持续学习成为可能——模型在部署中不断从用户交互中压缩新知识回权重，形成「后训练-部署-评估-再训练」的闭环。NVIDIA Rubin 平台的 ASIC 化设计（近存计算、确定性调度）进一步将推理算力利用率从 20-30% 拉升至 80% 以上，为这种闭环提供硬件基础。

竞态条件（Race Condition）在并发系统中由执行顺序不确定导致结果不一致。文章提到生产推理中出现了「非确定性故障」和「模型崩溃陷入 Token 重复」——这些现象很可能是由 KV 缓存更新、GPU 内核调度或请求路由中的竞态引发的。值得追问的是：在推理框架（如 vLLM、TensorRT-LLM）中，哪些共享资源（KV 缓存池、批处理队列、内存分配器）最容易产生竞态？当前社区是否有成熟的确定性调试或形式化验证工具来捕获这类极难复现的 Bug？