语音AI基础设施：构建实时语音代理

更新于2025年12月11日

2025年12月更新： Deepgram语音转文字延迟150毫秒，ElevenLabs文字转语音延迟75毫秒——但由于技术栈延迟叠加，大多数代理响应时间仍需800毫秒至2秒。人类对话需要300-500毫秒的响应窗口。管道延迟：语音转文字（100-500毫秒）+ 大语言模型（350毫秒-1秒以上）+ 文字转语音（75-200毫秒）。对于生产级语音代理而言，每一毫秒都至关重要。

Deepgram在150毫秒内完成语音转文字，ElevenLabs在75毫秒内合成语音。然而，大多数语音AI代理的响应时间仍需800毫秒到2秒——因为延迟在整个技术栈中不断累积。¹ 组件能力与端到端性能之间的差距揭示了语音AI的核心基础设施挑战：如何将语音识别、语言模型和语音合成编排成符合人类对话节奏的管道。

人类对话在300-500毫秒的响应窗口内进行。² 超过500毫秒的延迟会让人感觉不自然。超过1.2秒，用户就会挂断或打断。构建能达到这些阈值的语音代理，需要理解技术栈的每一层、选择合适的组件，并构建每毫秒都至关重要的系统架构。

语音AI技术栈

每个语音代理都依赖四个协同工作的组件：³

语音转文字（STT/ASR）： 将口语音频转录为文本的"耳朵"。根据流式配置不同，延迟范围从100-500毫秒不等。

大语言模型（LLM）： 处理转录文本并生成响应的"大脑"。优化后的模型延迟从350毫秒起，前沿模型则超过1秒。

文字转语音（TTS）： 将响应文本合成为音频的"声音"。现代流式TTS可实现75-200毫秒的首音频时间。

编排层： 管理组件间实时数据流的"指挥"，处理轮流对话、打断和会话状态。

延迟方程

语音AI延迟在整个管道中累积：⁴

总延迟 = STT + LLM + TTS + 网络 + 处理
      = 200ms + 500ms + 150ms + 50ms + 100ms
      = 1000ms（典型值）

要实现500毫秒以下的响应，要么压缩每个组件的延迟，要么通过流式处理实现管道并行化——在LLM生成完成之前开始语音合成，在用户说完之前处理部分转录内容。

语音转文字基础设施

ASR层将音频流转换为语言模型可处理的文本。服务商选择需要在延迟、准确性和成本之间取得平衡。

服务商对比

Deepgram Nova-3：⁵ - 首Token时间：约150毫秒（美国），250-350毫秒（全球） - 词错误率：18.3% - 流式优化，实时因子0.2-0.3倍 - 定价：$0.0043/分钟（按量付费） - 最适合：优先考虑速度的低延迟语音代理

AssemblyAI Universal-2：⁶ - 延迟：300-600毫秒 - 词错误率：14.5%（流式模型中准确率最高） - 在医疗和销售领域表现出色 - 定价：$0.00025/秒 - 最适合：准确性优先于原始速度的应用

Whisper（自托管）：⁷ - 延迟：1-5秒（批处理），380-520毫秒（WhisperX优化版） - 离线转录准确率最高 - 生产级流式处理需要大量工程投入 - 最适合：批处理、混合架构

Groq加速的Whisper： - 延迟：LPU硬件上低于300毫秒 - 结合Whisper的准确性和流式延迟 - 仅通过GroqCloud提供有限访问 - 最适合：注重质量的实时应用

ASR基础设施模式

流式架构： 音频到达后立即开始转录，而非等待完整的语句。在用户说完之前，部分结果就已经传递给下游组件。

# 流式ASR模式
async def transcribe_stream(audio_stream):
    async for chunk in audio_stream:
        partial = await asr_client.transcribe_chunk(chunk)
        if partial.is_final:
            yield partial.text
        else:
            # 发送中间结果用于预测
            yield partial.interim_text

语音活动检测（VAD）： 检测用户何时开始和停止说话。糟糕的VAD会导致过早截断（打断用户）或过度延迟（等待已经发生的静音）。

端点检测： 确定用户何时完成其轮次。激进的端点检测可减少延迟，但有打断说话者的风险。保守的端点检测确保完整性，但会增加延迟。

自托管ASR的GPU需求

自托管Whisper部署需要GPU加速：⁸

生产级语音转文字通常运行在A100或RTX 6000 Ada上，而非H100——这类工作负载更受益于内存带宽而非原始计算能力。

大语言模型层

LLM处理转录的语音并生成响应文本。模型选择对延迟和对话质量都有显著影响。

模型延迟概况

超快速（低于350毫秒）：⁹ - Gemini Flash 1.5：约300毫秒首Token时间 - Groq托管的Llama：LPU上约200毫秒 - 最适合：最大响应速度、简单查询

快速（350-700毫秒）： - GPT-4o-mini：约400毫秒 - Claude 3.5 Haiku：约350毫秒 - 最适合：速度与能力的平衡

标准（700毫秒-1秒以上）： - GPT-4o：约700毫秒 - Claude 3.5 Sonnet：约800毫秒 - 最适合：复杂推理、质量优先的应用

优化策略

流式生成： 在LLM Token到达时立即开始TTS合成，而非等待完整响应。现代编排管道将Token直接流式传输到语音合成。

推测执行： 基于部分转录预测可能的响应。在用户说完之前开始生成响应，如果预测与最终意图不匹配则丢弃。

模型路由： 将简单查询路由到快速模型，复杂查询路由到能力更强的模型。分类器在个位数毫秒内确定查询复杂度。

# 模型路由模式
def route_query(transcript, context):
    complexity = classify_complexity(transcript)
    if complexity == "simple":
        return "gemini-flash"
    elif complexity == "moderate":
        return "gpt-4o-mini"
    else:
        return "gpt-4o"

提示词优化： 更短的提示词减少处理时间。在支持提示词缓存的服务商处缓存系统提示词（Anthropic在缓存前缀上可实现90%的成本降低）。

文字转语音基础设施

TTS将LLM生成的文本转换为自然流畅的语音。这一层已从瓶颈（历史上需要2-3秒）转变为优势（现代服务商可达75-150毫秒）。

服务商对比

ElevenLabs Flash v2.5：¹⁰ - 首音频时间：75毫秒 - 语音质量：业界领先的自然度 - 情感范围：出色的表现力 - 定价：$0.050/1,000字符 - 最适合：质量优先的应用

Cartesia Sonic：¹¹ - 首音频时间：40-95毫秒 - 专为实时对话构建 - 高负载下延迟稳定 - 定价：$0.038/1,000字符 - 最适合：延迟优先的应用

Deepgram Aura-2：¹² - 首音频时间：低于150毫秒 - 企业级可靠性 - 大规模部署成本效益高 - 定价：$0.030/1,000字符 - 最适合：高流量企业部署

PlayHT： - 延迟：约300毫秒 - 丰富的语音库 - 语音克隆功能 - 价格较低 - 最适合：预算敏感的应用

TTS基础设施模式

流式合成： 在LLM文本到达时逐步生成音频。在完整句子合成完成之前就向用户发送音频块。

音频缓冲： 维护小型缓冲区以平滑播放，尽管合成时间不稳定。缓冲太多会影响延迟，缓冲太少会导致音频卡顿。

语音缓存： 将常用短语（问候语、常见回复）缓存为预合成音频。对缓存内容完全消除TTS延迟。

编排平台

编排层连接ASR、LLM和TTS组件，同时处理电话通信、轮流对话和会话管理。平台选择决定了开发速度和生产可靠性。

平台对比

Vapi：¹³ - 定位：一站式语音代理平台 - 电话通信：原生SIP/PSTN集成 - 定制化：模块化组件选择 - 定价：$0.05/分钟 + 组件费用 - 最适合：快速部署、电话应用场景

LiveKit：¹⁴ - 定位：开源实时基础设施 - 架构：原生WebRTC，带代理框架 - 定制化：完全控制，可自托管 - 定价：免费层（100并发，5,000分钟/月），付费从$50/月起 - 最适合：定制应用、需要完全控制的团队

Retell AI：¹⁵ - 定位：自然对话流程 - 差异化：优化的轮流对话和打断处理 - 合规性：HIPAA和SOC 2 Type II - 定价：$0.07+/分钟 - 最适合：对话质量优先、企业合规需求

Pipecat： - 定位：开源代理框架 - 集成：支持主流云服务商 - 定制化：高度灵活的管道构建 - 最适合：想要框架但不想被平台锁定的开发者

选择标准

架构模式

级联管道（ASR → LLM → TTS）

传统架构通过离散阶段处理音频：¹⁶

音频 → ASR → 文本 → LLM → 响应文本 → TTS → 音频

优势： - 组件模块化（易于更换服务商） - 成熟的工具和调试手段 - 可预测的成本结构（约$0.15/分钟，与对话长度无关） - 透明的中间表示（文本可检查）

挑战： - 延迟在各阶段累积 - 文本表示中的信息丢失（语调、情感） - 流式协调复杂

语音到语音（S2S）

端到端模型直接从音频处理到音频：¹⁷

音频 → 多模态模型 → 音频

示例： - GPT-4o语音模式 - Moshi（Kyutai Labs） - Ultravox

优势： - 保留语调信息 - 潜在更低延迟（单一模型） - 自然处理重叠语音

挑战： - 更高成本（较长对话约$0.30-1.50/分钟） - 定制化受限（无法更换组件） - 调试不透明（无中间文本）

混合方法

生产系统越来越多地结合多种架构：

级联 + S2S回退： 标准交互使用级联，复杂的重叠对话切换到S2S。

并行处理： 同时运行ASR和意图预测。在ASR完成的同时基于预测意图开始生成响应。

推测性TTS： 预先生成可能的响应音频。如果预测匹配立即播放缓存音频；否则回退到合成。

语音AI基础设施扩展

并发容量规划

语音AI的扩展方式与基于文本的AI不同。每个并发通话都需要整个管道的专用处理资源。¹⁸

每GPU容量（自托管）：

托管服务容量： 云服务商自动处理扩展

[内容因翻译需要截断]