实时AI推理为何贵56倍？持续推理与常驻内核的破局之道

实时AI模型的成本困境

一家构建推理引擎的团队（dotwave.ai）最近发布了两篇技术笔记，直指一个被行业长期忽视的问题：当下服务实时AI模型的成本，可能比它本应的高出多达 56 倍。他们以 NVIDIA 的全双工语音模型 Nemotron VoiceChat 11B 为测试对象，拆解了问题的根源与解法。

核心论点很尖锐——同样的模型权重、同样的精度、同样的输出，成本差距完全来自"模型如何运行"，而非"用什么硬件"或"换什么模型"。

reddit source

请求式推理 vs 持续推理

理解这个问题，要先区分两种截然不同的推理范式。

传统的"请求式推理"

今天绝大多数 AI 推理都以"请求"为单位组织：输入到达 → 模型运行 → 响应结束 → 资源释放。如果服务器繁忙，它可以稍等片刻把多个请求打成一批（batching），或者重排队列，代价不过是响应慢一点点。这套逻辑是 vLLM、SGLang、TensorRT-LLM、Triton 等主流推理服务框架的设计基石。

日益增多的"持续推理"

但有一类模型的工作方式完全不同。它们与 GPU 之外的某个实体（一段对话、一路视频流、一个机器人）并行保持活跃，持续接收输入，并在整个会话期间维持自身状态。团队称之为"持续推理"（continuous inference）。

全双工语音是最清晰的例子。模型一边听一边说，所以你可以随时打断它。音频在整个通话中持续到达，对话记忆要一直存活到挂断为止，而且每 80 毫秒就必须交付下一帧输出。这个截止时间不管服务器准备好与否都会到来——如果帧迟到了，你就会听到卡顿。更棘手的是，它在沉默时也得运行：停顿的长短正是模型判断"你只是在犹豫"还是"你说完了"的依据。

这与传统语音 agent（语音转文字 → LLM → 文字转语音）截然不同。后者的 LLM 在每轮对话之间是空闲的，而持续推理没有任何空档可以跳过。

全双工（Full-Duplex）语音与传统半双工的根本区别在于通信方向的同时性。半双工系统（如对讲机）同一时刻只能单向传输，传统语音Agent正是这种模式——说话方"说完"后才轮到另一方；而全双工系统允许两端同时收发，就像普通电话通话。对AI而言，全双工意味着模型必须在持续输出语音的同时，实时处理传入的音频流，并随时准备响应打断。这要求模型维护一个跨越整个对话时长的动态状态（KV Cache），而非每次生成完整响应后清空上下文。NVIDIA Nemotron VoiceChat 11B正是为这种范式专门设计的模型，其11B参数规模也意味着即便是单路会话，显存占用也相当可观，进一步放大了调度效率低下带来的成本损耗。

为什么它如此昂贵

既有推理框架围绕"请求"构建，几条关键假设在持续推理场景下集体失效：

批次等不起。每一个时间刻度（tick），服务器都必须用手头现有的资源运行所有到期的任务，没有缓冲余地。
过载同时砸向所有人。被打包在一起的会话共享同一个计算步骤，一个慢步骤会让整组会话全部迟到。
内存无法中途释放或换出。因为 80 毫秒后它又会被用到。
常规指标会掩盖故障。每秒 token 数和平均延迟看起来可能一切正常，而某个来电者其实一直在听卡顿。

团队给出了一组触目惊心的数据：在 NVIDIA 的参考技术栈中，每 160 毫秒的音频会被拆解成数千个微小的 GPU 操作，由 CPU 在它们之间来回协调，结果 GPU 约有 75% 的时间处于空闲等待。单会话勉强能跑，一旦加到两个会话，就有 8–15% 的音频节拍迟到。

换句话说，每一路实时对话都要独占一整块 H100，而这块昂贵的 GPU 大部分时间都在干等。

解法：把工作钉在 GPU 上

团队强调，修复之道不在于更快的 GPU 或更换模型，而在于运行方式的重构。核心是三条原则：

让工作常驻 GPU

他们的引擎把整个模型作为一个常驻的 GPU 程序运行。每个节拍，CPU 只负责投入新音频、取走输出，除此之外没有任何数据在 CPU 与 GPU 之间来回搬运——这直接消灭了参考栈中 75% 的空闲等待。

这里的核心优化对应GPU计算中的"kernel fusion"与"persistent kernel"技术。在传统推理流程中，每个GPU操作（矩阵乘法、激活函数、注意力计算等）会被独立启动为一个CUDA kernel，CPU需要在每次启动之间进行调度与数据搬运，由此产生大量的launch overhead和PCIe带宽消耗。而"常驻GPU程序"的思路是将整个前向传播编译为一个持续运行的kernel，GPU线程在两次音频节拍之间不退出、不重新初始化，只是在等待下一批输入数据——这将CPU与GPU之间的交互从每步数千次压缩为每个节拍仅一次边界同步。这一设计思路与CUDA Graph的理念相近，但针对时序严格的流式场景做了更激进的静态化处理。

让所有活跃会话同步推进

同一刻度上到期的所有会话被作为一个批次一起运行，于是模型权重只需为整组读取一次，而不是每个会话各读一次。这是摊薄成本的关键杠杆。

把一切提前决定好

由于每个节拍重复的工作完全相同，可以用编译器在第一通电话之前就固定好调度和内存布局。运行时不再需要调度器或内存分配器来临时决策，也就不再引入额外延迟。

这里描述的本质是"Ahead-of-Time（AOT）编译"在推理调度层面的应用。主流推理框架通常采用动态调度：在每个请求到来时，运行时系统根据当前显存、批次大小、序列长度等动态决定内存分配与算子调度顺序，这带来了灵活性，但也引入了不可预测的延迟抖动。而当工作负载的结构完全固定（每80ms一帧、固定批次大小、固定上下文长度上限），调度器就能在第一通电话之前把所有决策"烧录"进一张静态执行图：内存地址在编译期固定，算子顺序确定，GPU线程的分配不再依赖运行时协商。这消除了调度开销，也是p99延迟能稳定在147.5ms以内、84,000次测量零次超时的底层原因——确定性系统天然比动态系统更容易满足硬实时约束。

实测数据：从 1 到 56

在单块 NVIDIA H100 SXM 80GB 上，团队测得：

56 个并发会话（测试中的最高容量），而参考技术栈只能支撑 1 个；
每 160 毫秒节拍的 p99 延迟为 147.4–147.5 毫秒；
跨三轮、共 84,000 次会话节拍测量中，零次错过截止时间。

一通对话的成本等于 GPU 时间除以共享该 GPU 的对话数量。从 1 提升到 56，意味着每通对话的 GPU 占用减少约 98%。

团队也坦诚说明了测量边界：这是服务器端数据，排除了网络与音频播放环节，使用相同的录制输入、约两分钟的上下文。

对实时AI落地的启示

这篇笔记抛出了一个值得每个做实时模型的团队自问的问题：你今天每块 GPU 能跑多少路会话？又如何验证每一路都没有迟到？

随着全双工语音、具身智能、实时视频理解等"持续推理"场景快速增长，围绕请求式范式构建的推理栈正在暴露结构性短板。这个案例揭示出一个更普遍的趋势——推理优化的下一个战场，可能不在模型压缩或更强的芯片，而在调度范式本身的重新设计。当硬件利用率存在 56 倍的提升空间时，软件层的架构创新才是真正的成本杠杆。

注：以上数据与结论均来自 dotwave.ai 发布的技术笔记，为单一来源，尚待第三方独立复现验证。