和 AI 进行语音对话时，你可能还没说完，它就需要开始理解；你突然打断它的回答，语音输出又必须及时停止，同时保留此前的对话状态。对用户来说，这只是一次交流是否顺畅的问题；对技术系统来说，背后涉及音频流处理、模型推理、会话状态管理等多个环节。任何一个环节出现延迟，都可能影响最终的交互体验。

随着 AI 从单轮问答走向持续感知、理解与回应，实时性不再只是模型生成得有多快，而是整个系统能否持续、及时地响应变化中的需求。从语音处理、算力调度到数据更新与多模态推理，不同基础设施环节之间的协同，正在成为实时 AI 落地的重要工程问题。

10 月 24 日，iRTE2026 实时智能大会「Real-Time AI Infra 技术专场」中，模思智能 AI Infra 负责人高扬、声网基础资源中心负责人郝保平、OceanBase 技术专家汤庆、面壁智能多模态 Infra 负责人及 OpenBMB 开源技术负责人蔡天驰，以及 SGLang-Omni Maintainer 张若屹，分别围绕实时语音、AI 算力云、端侧数据引擎、流式全双工与多模态推理加速，分享了各自的工程实践。圆桌环节则围绕 Agent 辅助开发、实时推理框架、算力供给与未来交互场景展开讨论。

本场论坛由模思智能、声网和 RTE 开发者社区联合出品。

高扬｜流式多说话人识别与实时 TTS 的全链路工程优化

实时语音识别首先要回答三个问题：声音何时发生、谁在说、说了什么。多人同时发言时，系统不仅需要转写文字，还要区分说话人、标注时间，并随着音频到来持续输出结果。

模思智能 AI Infra 负责人高扬以 MOSS-Transcribe-Diarize 的工程实践为例，介绍了从整段处理转向流式处理的挑战——传统的离线识别可以等录音结束后再处理；但系统若要边听边出字，就不能只把音频切成小段并反复计算。系统需要保留历史状态、增量处理新到达的音频，同时维护已经识别的文字与说话人信息。

流式处理也改变了推理服务的资源管理方式：系统需要持续保留会话状态、占用显存；虽然每一步的计算量较小，固定调度开销却更为突出。服务端既要合批处理多路会话，也要按延迟目标控制容量，避免新请求影响正在进行的交互。

在语音生成环节，系统还需要应对另一类瓶颈：一条 TTS 请求可能经过参考音频编码、语言模型、帧内解码和声码器，不同阶段的计算特征和节奏并不一致。针对不同阶段的计算负载，高扬介绍了进程拆分、异步执行、算子融合与资源分配调整等优化方法，以减少 GPU 等待和频繁启动小算子带来的开销。

郝保平｜日呼百万级对话式智能体背后：声网 AI 算力云的架构与实践

声网基础资源中心负责人郝保平介绍了支撑日呼百万级对话式智能体的 AI 算力云实践。即使模型推理足够快，资源部署位置、实例启动速度和故障恢复能力，仍会影响通话体验。他将这套基础设施分为算力中心网络、资源调度、模型服务平台和自动化稳定性体系。

郝保平首先讨论了算力部署与访问距离之间的关系：将 Agent 与模型部署在相近的算力中心，可以减少中间链路；靠近用户的边缘节点也有助于缩短访问距离。但边缘容量有限，一旦局部需求升高，服务可能需要跨区域调度，新增的网络路径又会带来延迟。郝保平介绍，声网通过全球加速网络改善跨区域算力访问。在其展示的对比条件下，跨区域传输的 P90 延迟低于公网直连；这一指标只对应网络传输链路，不能直接等同于整条 AI 对话的端到端延迟。

算力部署之外，系统还要应对呼叫业务的潮汐流量。需求集中到来时，如果接到呼叫才启动 Agent 和模型，就难以满足实时响应。系统需要根据业务预测提前准备实例，再通过 Agent、模型与资源三个层级的调度，决定在哪里运行、选择哪个模型，以及何时扩缩容。

除了提前准备容量，系统还需要为故障做好预案。郝保平介绍了异常检测、灰度验证、故障诊断和恢复预案等机制，让服务在流量突增或部分资源失效时尽可能保持可用。

汤庆｜seekdb：Agent 的端侧数据引擎

Agent 在执行任务时，不仅需要检索已有信息，还要及时获取新数据、管理试验性修改，并在多轮交互中延续任务进度。OceanBase 技术专家汤庆围绕这些需求，介绍了 seekdb 在混合检索、索引更新与数据分支管理方面的技术能力，以及 PowerContext 支持跨会话任务接续的实现思路。

在证据检索环节，Agent 往往需要结合语义相似度、关键词、业务范围和来源信息，而不只是依靠单一的向量相似度。seekdb 将结构化数据、JSON、全文检索与向量检索等能力整合在同一数据内核中，使这些条件能够结合使用。

对于持续写入的数据，索引更新还存在时间差。汤庆特别提醒，即使事务已经提交、数据能够通过主键读取，在异步索引维护机制下，新数据也可能暂时无法出现在近似向量检索结果中。因此，在依赖最新证据作出判断前，应用需要确认索引可见性，必要时触发刷新，避免遗漏刚写入的信息。

当 Agent 需要比较不同的修改方案时，还要避免试验性操作直接影响正式数据。通过 seekdb 的数据分支机制，Agent 可以在独立分支中尝试修改、检查差异，再根据验证结果和用户授权决定是否合并。但数据分支只能隔离数据库内部的变化，外部工具调用产生的副作用仍需应用另行控制。

蔡天驰｜端侧实时推理与流式全双工：让全模态模型跑在 Mac 上

过去常见的语音交互更像对讲机：用户说完，模型才开始回答；回答过程中，模型未必还能持续感知外界。全双工交互则更接近打电话，输入与输出可以同时进行，用户能够随时打断，模型也要持续判断此刻该听还是该说。

面壁智能多模态 Infra 负责人、OpenBMB 开源技术负责人蔡天驰以 MiniCPM-o 4.5 的 Omni-Flow 架构介绍了这一变化。模型以连续的时间窗处理画面与声音输入，在每个时间窗内更新交互状态，并按需生成语音输出。

蔡天驰团队采用约 1 秒的时间窗，在响应速度与生成质量之间进行权衡。窗口过短，留给计算和生成的时间更加紧张；窗口过长，则可能影响交互的实时性。在连续输入的情况下，系统还需要保持足够的处理速度，避免未处理的数据不断积压。

在全双工交互中，推理引擎需要持续维护会话状态、处理用户打断，并协调不同模块的时序。蔡天驰指出，让单个 session 实现全双工，与让多个 session 并发运行且保持效率，是两项不同的工程挑战。

现场问答中，蔡天驰也谈到了实际部署的硬件条件：目前 MiniCPM-o 4.5 的全双工运行仍需要配置较好的 Mac 或具备一定算力的 PC。他在分享后半段提到的手机 MoE 推理优化属于另一项工作，不能据此认为 MiniCPM-o 4.5 已经在普通手机上实现全双工部署。

张若屹｜新时代该如何利用 Agent 协助多模态推理加速

当一条语音生成链路包含编码器、语言模型、帧内解码和声码器时，瓶颈不一定出在算力最密集的地方。有时，GPU 并未持续执行计算，而是在等待 CPU 下发后续执行命令。

SGLang-Omni Maintainer 张若屹以 MOSS-TTS 的优化过程说明了这一点。在特定配置下，优化前的 MOSS-TTS-Local 生成一秒 48 kHz 立体声音频时，可能触发约 6250 次 CUDA kernel launch。大量短小操作的启动开销，使得单纯增加批量未必能解决问题。团队先通过 runtime profiling 定位瓶颈，再采用合批、CUDA Graph 和针对特定算子的 Triton 实现减少开销。

张若屹提出，进行性能优化前要回答三个问题：瓶颈究竟在哪里？是否牺牲了音频质量来换取速度？测得的收益是否超过测试噪声？如果语音生成速度变快，却出现发音错误或音色变化，优化也可能失去意义。因此，团队不仅检查词错率等质量指标，对部分 MOSS 优化还要求输出的 PCM 采样逐位一致。

在性能优化过程中，Agent 可以辅助收集 profiling 数据、运行测试和生成优化候选，开发者则需要判断哪些假设值得验证、性能提升是否可靠，并对最终的代码提交负责。在一次 A/B 测试中，如果性能提升只有 1% 或 2%，且仍处于基线的正常波动范围，就不能认定优化有效。即使测试结果显示了明确的提升，也需要确认指标的测量范围。

圆桌｜模型跑得更快，基础设施还要解决什么？

五场主题分享之后，模思智能联合创始人兼 CDO 费朝烨主持圆桌，与模思智能 AI Infra 负责人高扬、声网基础资源中心负责人郝保平、面壁智能多模态 Infra 负责人及 OpenBMB 开源技术负责人蔡天驰、SGLang-Omni Maintainer 张若屹共同讨论了 Agent 辅助开发、开源推理框架适配、算力供需，以及推理提速可能带来的交互体验变化。

随着 Agent 能力不断提升，身处技术一线的人是否感受到了被这股浪潮推着前进？

高扬分享了几个月前的一次开发经历：他在训练框架中遇到一项数据加载模块的开发任务。这类工作逻辑相对确定，但实现繁琐，对性能和接口设计也有较高要求。按照传统流程，需要编写设计文档、讨论方案，再逐步实现。而 Agent 在一夜之间完成了他估计相当于团队约一个月工作量的任务。

但高扬并没有直接采用结果，而是逐一检查输入输出和边界条件，确认无误后才认为代码可用。他也提醒，即使代码由 AI 编写，核心开发者仍必须理解重要功能的实现，否则随着代码和功能不断增加，可能逐渐失去对框架的掌控。

全双工交互跑通之后，还有哪些工程难题？

蔡天驰将持续感知与人的日常体验作类比：人清醒时会不断接收周围环境的信息，而不是等到有人提问才看一眼。对于 AI，持续交互也意味着推理系统需要长时间保持稳定。云端部署要应对网络波动，端侧部署则需要控制发热和功耗。

张若屹认为，现阶段的全双工交互在很大程度上仍依赖工程设计。部分全模态模型的能力尚不能与更大规模的语言模型相比，因此需要通过上下文管理、话轮控制等方式维持交互。例如，当上下文过长时，系统可能需要舍弃较早的信息，以保持当前对话的连贯性。他设想，随着模型能力增强，未来部分工程规则或许能够逐步交给模型完成。

新模型要真正可用，开源社区需要如何参与？

高扬介绍，模型团队通常会在正式发布前联系推理框架维护者，说明新模型的特性与适配需求，并提供参考实现，帮助社区开展后续开发。

蔡天驰坦言，全双工架构对推理引擎的要求较为复杂，因此团队需要与社区保持密切交流。他们不仅讨论技术方案，还会提供机器和算力，与开发者共同调试。

张若屹则谈到了模型开放后的真实反馈。开发者在不同场景中使用模型，往往会遇到原团队未曾预料的问题。他打了一个有趣的比方：即使一家酒吧准备了各种酒，仍然可能有客人走进来，要求点一碗炒饭。开源社区的价值之一，正是不断发现并推动解决这些意料之外的问题。

算力供给如何跟上真实业务的需求？

郝保平指出，业务希望算力尽可能靠近用户，但算力中心未必能够按照需求自由选址，各地区可获得的资源规模也有所不同。

呼叫中心是一个典型场景。大量呼叫可能集中在特定时段，如果等请求到来后才启动算力资源，就可能无法满足实时交互的延迟要求；但提前准备资源，又需要预测需求出现的时间和规模。郝保平认为，除了跨区域网络，还需要结合流量预测、资源预热与实时弹性调度，应对地域和时间上的供需错位。

张若屹补充，目前多模态推理框架仍主要关注单卡效率。未来随着模型规模与服务复杂度增加，也可能逐步引入多卡、多实例以及计算阶段分离部署等方案，借鉴大语言模型规模化服务的经验。

如果推理速度提升十倍，哪些体验会真正改变？

圆桌最后，主持人费朝烨提出了一个假设：如果推理速度突然提升十倍，会发生什么？

高扬首先想到两种选择：利用更低的延迟加快现有应用和工作流，或者在相近的时间预算内运行更大的模型，探索模型能力进一步提升的可能。

郝保平从算力供给的角度出发。如果单位算力能够承载更多智能服务，一方面可以缓解资源供需压力，另一方面也可能降低用户使用服务的成本。

蔡天驰则将智能与电力作了类比。当电力变得充裕、便宜，人们创造的不只是更多电视机，还有空气炸锅、吹风机等各种新的电器。他设想，当 AI 的使用成本足够低，或许也会出现许多此前难以实现的设备与产品形态，甚至让一支普通的话筒也能够运行 AI。

张若屹将目光投向更复杂的科研与生产任务。他设想，随着推理成本持续下降，高能力模型能够使用更长的推理过程，或许有机会参与更前沿的数学、计算机科学及其他科研工作。

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么