数据源与状态仍在导航菜单中
aws.amazon.com·2026/10/23·Joseph Cottingham
为解决语音代理等待完整回复才合成造成的数秒静默,AWS 将 Kokoro-82M(82M 参数)托管在 Amazon SageMaker AI 实时端点,容器暴露 POST /invocations 和 WebSocket 双向流,客户端用 IncrementalSentenceChunker 按句切分,每句即发合成,音频以二进制与 JSON 控制帧复用,避免 SSE base64 约 33% 的膨胀和 MP3 帧错位。部署须处理 SageMaker 实际下发的二进制帧、保持会话开启至显式 close,并通过 speech-infra/agent-infra CLI 创建端点与 Bedrock AgentCore 上的 Strands 代理;容器中旧 PyTorch 需先升级。文中实测仅发首句使首音频延迟下降 52.4%,端到端 run_bidi 比 run_batch 快 2.4 到 3.5 倍。双向区分规则须按整块 JSON 解析判断控制帧而非音频,清理 destroy 不删 S3 权重缓存和 ECR 镜像,需手动删除。
为什么重要 低时延语音 agent 的可落地模板:单 GPU 实例跑 82M TTS,双向 WebSocket 复用二进制/JSON,附实测加速比与真实命令。适合 构建低延迟语音 agent、跑 SageMaker/Bedrock AgentCore 推理的工程团队

注释 · 同一段 267 字符、四句文本分别作为完整一消息和仅第一句发送,各测 5 次。出自 Testing and validation
注释 · 同一 prompt、同一 live Bedrock 模型和 Kokoro 端点,唯一变量是合成开始时间;本地为 2.4 倍。出自 Testing and validation
$ uv run speech-infra deploy kokoro-82m
$ uv run agent-infra deploy --bedrock-model-id <your-bedrock-model-id>
$ uv run agent-infra demo --endpoint-url <your-endpoint-url> --prompt "<your prompt>"
$ uv run agent-infra destroy --bedrock-model-id <your-bedrock-model-id>
$ uv run speech-infra destroy kokoro-82m
语音 agents 常常等待 agent 的完整响应后才开始语音合成,增加了用户直接感受到的延迟。本文展示如何在 agent 生成每个句子时,就把该句子流式传输到 Amazon SageMaker AI 上的 Kokoro-82M text-to-speech 模型,以及如何通过 Server-Sent Events 或统一二进制传输把音频返回浏览器。
Voice agents often wait for an agent's full response before starting speech synthesis, adding latency users feel directly.
This post shows how to stream each sentence to a Kokoro-82M text-to-speech model on Amazon SageMaker AI as the agent produces it, and how to get that audio back to a browser over Server-Sent Events or a unified binary transport.
EVIDENCE / METHODS
参数清单
隔离测试使用 267 字符、四句文本,各方式做 5 次试验
注释 · 端到端对比固定同一 live Bedrock 模型与 Kokoro 端点,仅让合成起点成为变量。出自 Testing 与 Step 4