今日场景今天推理系统这条线的主题是缓存和排队。Fairway、Penelope 和一篇讲 agent 服务在流量高峰后恢复不了的论文，问的是同一类问题：前缀缓存被大量复用之后，该先跑谁、删哪一段、什么时候少收新会话。AttentionIndex 把稀疏注意力里挑 token 的那一步当成一次近邻检索来加速，OctEx 用 GPU 显存换掉向量检索里一轮等一轮的查询。Scute 让一张 GPU 混跑多种微调适配器。工程侧有 Qdrant 的低位量化存储、SageMaker 的前缀感知路由、NVIDIA 的训练自动恢复，以及 Google 排查 XLA 编译器错误的经验。 — 评分 212 篇，入选 10 篇，分数 3.75 – 4.40
前缀缓存下的 prefill 排队，可以同时做到中位延迟低、长尾也短：队列短时优先跑命中多的便宜请求，一个请求等得越久（和它自己的 prefill 时长相比）就排得越靠前，同时限制便宜请求最多能插到最老请求前面多少计算量。这就是 Fairway 的做法。agent 和 RAG 的请求常共用一段前缀，同一队列里各请求剩下的计算量能差上百倍，先跑谁就决定了每个请求等多久才出第一个 token。在流量尖峰里，Fairway 的中位首 token 延迟是 0.82 秒，p99 接近先来先服务；偏向命中的排法 p99 则到了 11 到 50 秒。
DeepSeek-V4、GLM-5.3 这类学习式稀疏注意力里，每个 query 只对 k 个键做注意力，但挑出这 k 个键的小打分网络仍要给前缀里的每个键打一遍分。上下文到 100 万 token 时，这一步占了 prefill 时间的一半以上。AttentionIndex 大幅压低了这一步的开销：它在 prefill 过程中把键按相似程度分成一组组，query 先给每组的代表打分，只把最有希望的几组成员交给原来的打分网络细选。在这个长度上，它的 prefill 吞吐是逐个打分的 1.3 到 1.8 倍，也比速度相近的分块方法 HiSA 漏选得少。
一阵十分钟的流量高峰，就能让 prefill 和 decode 分离部署的 agent 推理服务一直恢复不了。高峰过去、流量回到原来扛得住的水平以后，在 SGLang 上之后一小时的有效吞吐仍下降约 88%。agent 每次调用都要把越来越长的对话重新发给模型，靠前缀缓存省掉重算。背后是一个循环。缓存不够导致重算，调用变慢，会话结束得更晚，同时在线的上下文变多，缓存就更不够。作者据此做了 Basin，它预估每个会话整个过程中最长会用到多少上下文，按这个量从一个随负载调整的总额度里预留，额度不够就先不收新会话。它的有效吞吐是 Continuum 的 1.20 到 1.70 倍。这类故障在利用率和队列长度上几乎看不出征兆。
GPU 上做高召回的向量检索，最快的 CAGRA 这类图索引要沿着图一轮轮走，每轮都得等上一轮的距离算完，召回要求越高，轮数越多。OctEx 换了个思路：把 GPU 显存花在提前算好的近邻列表上。它把数据随机投影成几百份低维副本，每份把向量归到规则网格的格子里，并为每个格子存好离格子中心最近的那些向量。查询时一次读出自己所在格子的列表，再读这些候选各自预存的近邻，轮数固定，不再等一条长链。在四张 H100 上的十亿向量数据集上，它在高召回下比 CAGRA 快 1.46 到 2.05 倍。用显存换掉查询时的串行等待，是这篇的核心取舍。
KV cache 放不下时，vLLM 和 SGLang 都从缓存序列的末尾开始删，为的是保住开头那段能被很多请求共用的前缀。但 agent 每一轮都会把很长的历史重新发回来，而越靠后的 token 重算越贵，因为它要和前面所有 token 算注意力。Penelope 反过来做：共享前缀照样保留，剩下的历史从靠前的部分开始删，留住靠后的部分。请求回来时，只重算缺掉的那一段。在 SGLang 上用真实 agent 请求记录测，只用 GPU 缓存时平均首 token 延迟最多降 60%，再加上 CPU 内存做第二层缓存时最多降 76%。该删哪一段，要看重算它要花多少，而不只看它被多少请求共用。
vLLM 和 SGLang 能把许多 LoRA 适配器的请求拼成一批，但 DoRA、VeRA、OFT 这类其他微调方法的适配器直接被拒，没法和它们混在一批里跑，转成 LoRA 又要多占显存、可能掉精度。多租户平台常给每个客户叠一个自己的小适配器，这个限制很碍事。Scute 在 LoRA 的计算里留出几个可填的位置：基础权重那条路上，输入先乘一个变换矩阵，输出再按列缩放、加一个偏移；低秩那一项的中间和输出也各乘一个向量。不用的位置就是乘 1 或加 0。比如 OFT 先旋转输入再走原来的层，它的旋转矩阵就填进输入变换。这样五种方法能在一个批次里精确混跑，decode 时间只比同样数量的 LoRA 多 5% 到 17%。与其把各种适配器都转成 LoRA，不如让 LoRA 的批处理核函数认识它们。
Qdrant向量库里最贵的往往是存向量本身：冷数据占磁盘，热数据占内存。Qdrant 1.20 新加了两种低位存储类型 turbo8 和 turbo16。它们不是把 float32 直接截成低精度，而是先把向量旋转一下再量化，尽量保住检索需要的信息。在官方测试的一组向量上，turbo8 只占 float32 四分之一的空间，召回还略高一点，服务端延迟比 float32 多出不到 10%。延迟涨得少，是因为查询向量只做旋转、不做量化。先旋转再量化，能在省空间的同时基本不丢召回。
编译器里的一个错误可能不报任何错，只是悄悄让数值算偏，几周后让一次昂贵的训练发散，或者让线上推理质量变差。Google 介绍了他们怎样在大规模上排查 TPU 上 XLA 编译器的这类问题。一方面，用随机生成的程序和真实生产里的计算图做模糊测试，并让一群 AI agent 自动写压力测试、复现失败、起草修复。另一方面，定位时把出错的大计算图层层二分，一直缩小到融合核函数里出错的那一个算子。这套流程上线后已经推动修复了超过 142 个编译器缺陷，另有 103 个发现还在核实。编译器正确性要靠持续的生产级测试，只跑回归用例远远不够。
NVIDIA分布式训练规模越大，某个训练进程卡住、某个节点失联、某台机器拖慢全局这类中断就越频繁。每次都要有人看日志、找出坏节点、从 checkpoint 重启，期间 GPU 在空转。NVIDIA 开源的 NVIDIA Recovery 把这件事自动化：从应用日志、GPU 指标和调度器信号里发现异常，判断是哪台机器的问题，把它隔离，再按策略重启或停掉任务。新部署默认只给建议、不动手，方便运维先确认信号可靠。在一个每天约 200 个任务的训练集群上跑了三个月，平均 69 秒发现异常，94 秒采取恢复动作。先只给建议、再放开自动处理，让这类系统上线的风险小得多。
Amazon很多 LLM 应用的提示都以一大段固定内容开头，比如几千 token 的客服规则，后面才是用户的一句话。单台机器上的前缀缓存能省掉这段重算，但多台机器时请求被随机分出去，每台都很少重复见到同一个开头，缓存基本用不上。Amazon SageMaker 新加的前缀感知路由会把开头相同的请求固定发到同一台机器。那台机器满载时，请求转给空闲的机器；扩缩容时，也只挪动一小部分流量。在官方测试里，缓存命中率从约 25% 升到 80% 以上，中位首 token 延迟最多降 77%。多实例部署时，前缀缓存省不省得下来，取决于路由。