如果你在做实时语音对话产品，这条值得停下来看。今天的全模态对话模型（omni-modal LM）允许用户一边流式说话、一边听模型生成的语音、还能随时插话打断，但跑在底下的推理服务系统却基本没为这种交互方式改过——它们还是按文本大模型那套"尽量把吞吐量拉满"的逻辑在调度，缓存淘汰也还是简单的 LRU（最近最少使用）。问题在于，语音交互的节奏和文本生成根本不是一回事。 具体哪里错位？原文点出两个。一是模型经常会生成远超用户实际听到的 token：语音是按播放进度一点点被听到的，用户一旦打断（论文里叫 barge-in），后面那些已经算出来但还没播放的内容就全白做了，算力直接浪费。二是 LRU 这种通用淘汰策略会把下一轮对话马上要用的 KV 状态（注意力机制缓存的键值对，多轮对话里复用它能省掉重算）提前清掉，等下一轮真要用时又得重新加载，延迟卡在关键路径上。 LiveServe 的思路是把"交互语义"接进服务流水线。它把三类此前调度器看不见的信号显式暴露出来：播放进度（用户听到哪儿了）、说话活动（用户此刻在不在说话）、以及打断事件。有了这些信号，调度和缓存就能按交互的真实状态来决策，而不是盲跑。 调度器这一侧做两件事。一是优先处理两类会话：刚开始、需要尽快出第一段音频的会话（首包延迟最影响体感），以及音频快播完、马上要"断流"（near-underrun）的会话——避免用户听着听着卡住。二是限制超出"播放前沿"（playback frontier，即用户当前听到的位置）太远的生成，不再提前算一大堆可能被打断作废的内容。 KV 管理器这一侧也换了两套机制。淘汰不再用 LRU，而是按"下次使用时机"（next-use-aware）来决定留谁踢谁，把多轮对话里马上还要复用的状态保住。同时它会趁用户说话的间隙，预加载下一轮大概率要用到的 KV，把重新加载的延迟藏到用户说话这段时间里，等模型要回应时缓存已经就位。原文也提到，这套做法把大部分 KV 重载工作移出了下一轮的关键路径。 效果上，团队在 vLLM-Omni 这个全模态服务平台上、对两个 Omni-LM 和混合负载做了评测。P90 音频首包时延（TTFP，衡量从请求到第一段音频的尾部延迟）平均降到原来的 1/1.55，最好的情况快了 2.21 倍；完成请求的吞吐量平均提升 1.15 倍，最高 1.56 倍。值得注意的是它没有在延迟和吞吐之间二选一——两个指标同时改善，这在 serving 优化里不算常见。 诚实地说，这是一篇系统侧的优化工作，收益区间也明确写了"平均"和"最高"两档，真实部署里大概率落在平均值附近、看负载特征而定；它针对的是实时语音这一特定场景，文本为主的服务未必用得上。但对正在被首包延迟和打断浪费困扰的实时语音 serving 团队，把交互事件接进调度这个方向，是个具体、可借鉴的切口。