多轮记忆、混合精度与安全上线：推理服务如何追上Agentic负载

Agentic 工作负载正在改变推理服务的底层假设。过去整个行业优化的都是"单次请求"场景，但当 LLM 变成持续对话、反复调用工具的智能体时，服务系统的瓶颈从计算密集型转向了内存与调度。本文梳理近期在 arXiv、vLLM、Hugging Face、Modal 等平台上涌现的一批进展，它们共同指向同一个方向：让推理服务从"把一次请求跑完"进化到"让一段会话跑得便宜"。配图：Multi-Turn Memory, Mixed Precision, and Safer Rollouts — Serving Catches Up to Agentic Workloads

多轮会话：KV 缓存的双向流转

多轮 Agentic 工作负载最直接的痛点是 TTFT（首 token 延迟）被反复重算的 prefill 拖垮。传统的 KV 缓存只从 prefill 节点流向 decode 节点，每次对话新一回合都要重新 prefill 整段历史。vLLM 的最新工作打破了这条单向通道——让 decode 节点把已经算好的 KV 块"还回"给 prefill 节点，这样下一轮对话的公共前缀就不需要再算一遍。

据 vLLM 博客披露，这套双向 KV 传输在 Qwen3-32B 上把 24k token 场景的 TTFT 从 778ms 压到 460ms（约 1.6 倍），在 GLM-5-FP8 的 20k token 场景下更是从 2334ms 降到 702ms（约 3.3 倍）。关键在于它不需要额外硬件，配合一个感知 KV 缓存的 router 和基于 EFA 的点对点张量传输即可实现。对于任何部署长会话智能体的团队来说，这是直接的延迟与成本收益。

KV 缓存与 prefill/decode 两阶段：Transformer 推理时，每个 token 的注意力计算依赖此前所有 token 的 Key（K）和 Value（V）向量，这些中间结果即 KV 缓存。推理被拆成两个阶段：prefill 一次性并行处理整段输入提示词，生成首个 token 并填充 KV 缓存，是计算密集型；decode 逐 token 自回归生成，每步都要读取全部 KV 缓存，是内存带宽密集型。多轮对话中，历史对话已算过的 KV 在传统架构里只驻留在 decode 节点，下一回合新增前缀仍需在 prefill 节点重算。TTFT（Time To First Token，首 token 延迟）主要由 prefill 时长决定，因而成为长会话最敏感的用户体验指标。把已算好的 KV 块从 decode 回传 prefill 复用，本质上就是消除这种重复计算。

EFA 点对点传输：EFA（Elastic Fabric Adapter）是 AWS 面向高性能计算与分布式训练推出的网络接口，支持绕过内核的 RDMA 式点对点通信和 GPUDirect，让 KV 块能在节点间以接近显存带宽的速度搬运，而不必经由 CPU 或共享存储。这正是双向 KV 流转不依赖额外专用硬件的工程前提——复用集群既有的高速互连，把跨节点 KV 迁移的代价压到可接受范围。

调度层：会话亲和性与队列拥塞的权衡

如果说 vLLM 从服务引擎内部解决问题，arXiv 上的 Vesta 则从调度理论切入。它指出了一个被忽视的结构性问题：把"会话级 KV 缓存归属"和"请求级执行放置"解耦——也就是说，不是每个请求都必须路由到持有其缓存的那个节点，而是用排队论在缓存局部性和队列拥塞之间做权衡。

论文报告在共置部署下吞吐提升 14%、平均 TTFT 下降 57.8%，在分离式部署下 P99 TTFT 最多降低 29%。这一结果与 vLLM 的双向 KV 传输形成互补：一个从引擎侧减少重复计算，一个从调度侧减少排队等待，两者殊途同归，都指向"会话优先"的服务架构。

会话亲和性与排队论：会话亲和性（session affinity）指把同一会话的后续请求路由到持有其 KV 缓存的同一节点，以命中缓存、省去重算。但严格绑定会带来副作用：若目标节点正忙，请求只能排队等待，导致尾延迟恶化；而宽松路由虽能分散负载，却可能次次缓存落空。Vesta 用排队论把这变成一个可优化问题——将“缓存在哪”（会话归属）与“请求在哪执行”（执行放置）解耦，允许请求被送到空闲节点执行，同时通过缓存迁移或预取维持命中率，在缓存局部性与队列拥塞之间取平衡。这一视角的价值在于：它把调度从启发式规则变成可量化的代价权衡，也解释了为何共置部署（缓存与计算同节点）与分离式部署（prefill/decode 分离）需要不同的调度策略。

混合精度：不再靠字节宽度猜配置

KV 缓存的量化策略一直是推理优化中最容易拍脑袋的部分。《The Price of Precision》这篇论文提出一个校准成本模型：先判断在给定 batch size 和上下文长度下，真正的瓶颈是计算、权重加载还是 KV 缓存访问，再用动态规划选择混合精度配置，而不是单纯依据字节宽度。对于需要按模型逐个调节 KV 内存上限的团队，这比"一刀切 bit 数"要实用得多。

同方向的还有 MultiAlloc，它把固定的量化预算拆成"逐层精度提升"和"逐 token 保留"两部分，用轻量离线 profiling 替代均匀压缩。在等内存预算下，它在 Mistral、Llama、QwQ 上均优于单粒度基线。而 E8 Lattice Key Quantization 则走了一条更激进的路线：用 E8 格上的向量量化替代标量量化，利用跨维度相关性，实现 2-bit keys / 2-bit values 配置（此前 keys 至少需要 3-bit），约 6 倍压缩的同时 decode 吞吐与标量基线持平。

KV 量化的粒度与预算：把 KV 缓存从 FP16 压到更低比特，能显著减少显存占用、提升 batch size，但会引入精度损失。量化粒度决定压缩效率与误差分布：标量量化对每个数值独立取整，实现简单但忽略维度间相关性；向量量化把若干维度作为一个整体映射到码本，能利用相关性获得更高压缩比。E8 格（E8 lattice）是八维空间中最优的球堆积结构之一，用它做向量量化可在极低比特下保持较低重构误差，这正是 2-bit keys 得以实现的数学基础。而混合精度策略的核心问题是“预算怎么分”——是给所有层、所有 token 统一压缩，还是对敏感层和重要 token 保留更高精度。MultiAlloc 的分层预算与逐 token 保留、以及《The Price of Precision》的成本模型，都是在回答这个问题。

上线安全：先镜像流量，再切换生产

一旦选定了更快的服务路径，团队面临的另一个问题是如何安全地验证它。Modal 的 Endpoint Candidates 功能给出了一个内建方案：让备用部署（新 checkpoint 或不同模型）镜像采样一部分生产流量，在提升为正式端点前测量质量、延迟、吞吐和成本。

其工程实现值得一提——Modal 扩展了基于 Pingora 的代理，让每个镜像候选者从自己有限的、去重的缓冲区读取数据，并设置进程级内存预算，从而保证慢候选者不会给生产流量带来额外延迟。对于那些想对量化调整、模型升级或引擎配置变更做 A/B 测试，却又不愿自建流量镜像基础设施的团队，这是一条低风险路径。

硬件与稀疏化：Agentic 吞吐的下一阶段

evidence 显示，vLLM 对 DeepSeek^广告-V4.1-Flash 的三项优化——SWA 有界重放（只重算最后 128 个 token）、MegaAttention 与 Mega-Gate 内核、以及算子融合与 CUDA graphs——在 150 TPS 约束下实现了 5.3 倍吞吐，低并发下加速 1.9 倍，100K 吞吐时 TTFT 降低约 70%。这意味着每 token 成本出现了量级上的变化。

硬件层面，vLLM 对 NVIDIA Vera Rubin NVL72 的 day-0 支持报告了相对 GB200 NVL72 每 GPU 7.8 倍吞吐（AgentX）和相对 GB300 的 3.7 倍 VLM 吞吐（MLPerf v6.1），配有面向 MoE 路由调优的"locality domains"。这更像是面向未来硬件的预览，而非今天就能落地的方案，但对硬件规划有参考价值。

在模型侧，LiquidAI 的 LFM2.5-24B-A2B 用稀疏 MoE 实现了 24B 参数中每 token 仅激活 2B，并把上下文从 32K 扩展到 131K。它在 Apple M5 Max 上跑出 184 tok/s，在单张 NVIDIA B300 上聚合吞吐高达 21K tok/s，为"在单 GPU 或设备端跑低成本智能体"给出了直接数据点。

稀疏 MoE 与激活参数量：混合专家模型（MoE）把前馈层拆成多个专家，每个 token 只被路由到其中少数几个，因此“总参数量”与“每 token 激活参数量”是两个不同概念。LFM2.5-24B-A2B 的命名正是说明这一点：24B 总参数、每 token 仅激活 2B，推理计算量接近一个 2B 稠密模型，却能享受更大参数带来的容量。这使得它在单张 B300 或 Apple M5 Max 这类设备上也能跑出高吞吐，为设备端或单 GPU 部署低成本智能体提供数据点。MoE 的代价是显存仍需容纳全部专家权重，且路由本身带来额外通信与调度开销——这也是 NVIDIA 在 Vera Rubin NVL72 上强调“locality domains”的原因：让路由尽量落在局部高速互联范围内，避免专家跨节点搬运成为瓶颈。

贯穿本周的主线

这一轮进展的共同逻辑是：服务系统正在为"会话"而非"请求"重新设计。vLLM 的双向 KV 传输和 Vesta 调度器从引擎和调度两侧攻击同一个问题——多轮会话反复支付 prefill 成本、或在朴素排队中卡住；而 Modal 的 Endpoint Candidates 和 DeepSeek-V4.1-Flash 的内核工作则指向后半段：一旦你选定了更快的服务路径，需要一个安全的方式在真实流量上验证它，再全面切换。

对推理基础设施团队而言，这意味着评估框架也应该更新：不再只看单请求的 TTFT 和吞吐，而是看会话级的成本、缓存命中率和 P99 尾延迟。