AWS发布方案：将AI智能体每句话实时送入Kokoro TTS以降低语音延迟
AWS机器学习博客介绍一套开源示例：把Kokoro-82M语音合成模型部署在SageMaker AI实时端点上，智能体每生成一句就送入合成，并比较SSE与二进制流两种音频回传方式。作者称在隔离测试中将首音频字节时间缩短 52.4%。
AI解读：这套方案针对的具体延迟是：语音智能体要先等完整回答生成完才开始合成。博客举例说，一句话的回答可能 600 毫秒生成，但完整回答要 5 秒，集成层等全部完成后才开始合成音频。
按作者的说明，改动点是把智能体产出的每个完整句子立即送入托管在SageMaker AI上的Kokoro-82M端点，让合成从第一句开始，而非等整段响应结束。方案并非并发合成：每个双向处理循环仍是串行的，收益来自更早启动。
Kokoro-82M有 8200 万参数，作者称其小到可在单块中端GPU实例上低成本运行；示例部署在ml.g5.xlarge上，容器暴露普通流式与双向WebSocket两条路径。
作者给出的量化结果分两层：隔离TTS传输时，只发送四句文本的第一句，五次试验的首音频字节均值从 329.3 毫秒降到 156.7 毫秒，相对改善 52.4%；端到端接真实语言模型时，双向模式的首次出音频比批量模式快 2.4 倍（本地容器）和 3.5 倍（部署在AgentCore运行时）。这些是博客自测数据，未提供跨厂商或生产流量下的独立验证。
适用对象是需要给已有文本流式智能体加语音的开发者。若前端已有SSE文本管道，作者建议先用base64编码音频放进SSE事件，代价是负载增大约 33% 并需缓冲重组帧；若新建语音链路或延迟优先，可改用同一双向会话多路复用原始二进制音频和JSON控制帧。
方案附带明确限制：示例容器固定了较旧版本的PyTorch，存在已知安全公告PYSEC-2026-2286（作者称torch 2.10.0已修复），非验证性用途前需审查并升级；清理步骤也不自动删除缓存模型权重的S3桶和存放镜像的ECR仓库。
AWS机器学习博客发布一篇技术方案，演示如何为AI语音智能体减少“等待完整回答再合成语音”造成的停顿。作者Joseph Cottingham提出的做法是：智能体每产出一个完整句子，就立即把该句送入部署在Amazon SageMaker AI实时端点上的Kokoro-82M文本转语音模型，让音频在第一句生成后就开始合成。
博客称该模型仅有 8200 万参数，可运行在单块中端GPU实例上；示例部署在ml.g5.xlarge，容器提供POST /invocations与WebSocket /invocations-bidirectional-stream两条路径。方案要求SageMaker AI端点容器带有com.amazonaws.sagemaker.capabilities.bidirectional-streaming=true的Docker标签，以及SageMaker、AgentCore、IAM、ECR等相关权限。
作者报告的两组延迟数据
博客给出两层测量。第一层隔离TTS传输本身：把同一段 267 字符、四句话的文本分别作为一条消息发送和只发送第一句，各做五次试验，作者称首音频字节均值从 329.3 毫秒降到 156.7 毫秒，相对改善 52.4%。第二层接上真实语言模型，用同一提示词比较双向模式与批量模式；作者称双向模式的首次出音频在本地容器快 2.4 倍、在部署的AgentCore运行时快 3.5 倍。
作者解释部署环境差距扩大，是因为双向模式在生成与合成重叠期间吸收了额外网络跳转，而批量模式串行等待，网络开销直接加在等待上。这些数字来自博客自测，未提供生产流量或第三方复现结果。
音频回传的两种选择及代价
博客把“音频如何回到浏览器”单列为需要决策的一环。对已有SSE文本管道的团队，作者建议把音频base64编码后放进SSE的JSON事件；他测量 24 段音频后称，base64使负载增大约 33%，例如原始PCM 2,396,400 字节变为 3,195,200 字节。
作者还提醒SSE事件以空行分隔，音频以MP3帧分隔，两者未必对齐：一次测量中四个逻辑MP3帧被拆成六个传输块，其中两个在帧中途结束，消费端需要缓冲到分隔符出现再处理。另一条路径是在承载文本输入的双向会话上直接多路复用原始二进制音频与JSON控制帧，以“整块能否解析为JSON对象”区分控制帧与音频，省去编码和重组的开销。
作者给出选择建议：已有SSE管道就先用base64方案；新建语音链路或延迟优先时再考虑统一二进制与JSON的传输。
示例中容易踩的两个坑与安全限制
博客专门记录了双向传输的一个常见故障：SageMaker AI把客户端消息都作为二进制WebSocket帧送达，若容器用receive_text() 读取，会因缺少text字段抛出KeyError('text')，而端点状态仍显示InService，容易被误判为部署问题。作者建议显式同时接受文本和二进制帧，并用二进制帧做测试。
另一个要求是会话保持：容器发完一段音频和synthesis_complete控制帧后，应继续在同一会话上等待下一条消息，仅在客户端发送 {"type": "close"} 时关闭；否则每句都重连，会抵消大部分延迟收益。
安全方面，作者说明示例容器固定了较旧版PyTorch，存在已知公告PYSEC-2026-2286，torch 2.10.0中已修复，非概念验证用途前需审查并升级。清理资源时，agent-infra destroy和speech-infra destroy不会清空缓存权重的S3桶，也不会删除存放镜像的ECR仓库，作者提醒二者会继续产生少量存储费用。