语音交互必须 ASR + TTS 配套部署

💡 核心观点

语音交互 ≠ 只做 ASR。一个完整的语音对话系统必须同时考虑：

• ASR（听）：语音 → 文字
• TTS（说）：文字 → 语音

两者必须配套选型、配套部署，不能只看一个。

一、为什么必须配套考虑？

1.1 语音交互的完整链路

用户说话 → [ASR 识别] → 文字 → [LLM 对话] → 回复文字 → [TTS 合成] → 语音播放
              ↑                                              ↑
           延迟敏感点 1                                   延迟敏感点 2

整个链路的延迟 = ASR 延迟 + LLM 延迟 + TTS 延迟。如果 ASR 用了本地部署但 TTS 还在走云端（或反过来），那"数据不出域"就破了——音频数据仍然会经过外部服务。

1.2 三种部署场景

⚠️ 混合部署的陷阱：如果 ASR 本地但 TTS 走云端，回复文字会送到云端合成语音——对话内容仍然出域了。反之亦然。

二、ASR 本地部署方案

2.1 可选模型

2.2 推荐选型

三、TTS 本地部署方案

3.1 可选模型

3.2 推荐选型

四、ASR + TTS 配套部署方案

4.1 方案 A：最低配（纯 CPU 服务器）

ASR：Qwen3-ASR-0.6B    → ~1.2 GB
TTS：F5-TTS            → ~1 GB
─────────────────────────────────
总模型大小：~2.2 GB
总内存需求：~4 GB
硬件要求：CPU 即可（8 核推荐）

适用：低并发场景（同时 1~2 人使用），有"数据不出域"合规要求。

4.2 方案 B：推荐配（加一块 GPU）

ASR：Qwen3-ASR-1.7B    → ~3.4 GB
TTS：CosyVoice 3-1.5B  → ~3 GB
─────────────────────────────────
总模型大小：~6.4 GB
显存需求：~8 GB（T4 16GB 足够）
硬件要求：NVIDIA T4 / P4 / A10

适用：中等并发，追求最佳效果。

4.3 方案 C：全云端（当前方案）

ASR：阿里云 paraformer-realtime-v2（DashScope API）
TTS：火山引擎 Seed-TTS 2.0
─────────────────────────────────
模型大小：零（云端）
硬件要求：零（云端）

适用：无合规要求，追求零运维。

五、成本对比与决策矩阵

5.1 成本平衡点

5.2 决策流程

是否有"数据不出域"合规要求？
  ├── 是 → 本地部署（方案 A 或 B，视有无 GPU）
  └── 否 → 月 API 费是否 > 500 元？
              ├── 是 → 考虑本地部署节省成本
              └── 否 → 继续全云端，零运维最省心

六、对本项目的意义

6.1 当前状态

6.2 升级路径

6.3 关键结论

1. 当前全云端方案是最优选择——API 费低、零运维、效果最好
2. 一旦出现"数据不出域"需求，必须 ASR + TTS 一起转本地——不能只转一个
3. 纯 CPU 也能跑——Qwen3-ASR-0.6B + F5-TTS 总模型仅 ~2.2 GB，4 GB 内存即可
4. Qwen3-ASR + Qwen3-TTS 是最佳配套——同属阿里 Qwen 体系，同日开源（2026-01-29），Apache 2.0
5. F5-TTS 是纯 CPU 场景的 TTS 首选——非自回归架构，RTF 0.15，CPU 上比其他 AR 模型快得多

七、参考资源

ASR 相关笔记

• ASR前沿进展（2025-2026）
• Paraformer实时语音识别模型
• FunASR开源语音识别框架

TTS 相关笔记

• TTS前沿进展（2024-2026）
• CosyVoice开源语音合成模型详解
• Edge-TTS微软免费语音合成服务

项目内语音交互笔记

• Ping语音聊天机制
• 语音AI聊天开发经验