目录
-
[三、备选一：科大讯飞 ------ 中文语音天花板](#三、备选一：科大讯飞 —— 中文语音天花板)
-
[四、备选二：阿里云 CosyVoice / 通义 ------ 延迟极致](#四、备选二：阿里云 CosyVoice / 通义 —— 延迟极致)
-
[五、备选三：腾讯云 / 百度曦灵 ------ 生态绑定](#五、备选三：腾讯云 / 百度曦灵 —— 生态绑定)
-
[六、海外实时语音 API 对比](#六、海外实时语音 API 对比)
-
[八、成本粗算（以 1 万分钟/月对话为例）](#八、成本粗算（以 1 万分钟/月对话为例）)
-
[九、官方入口：路线 A（分别接入 ASR + LLM + TTS）](#九、官方入口：路线 A（分别接入 ASR + LLM + TTS）)
-
[十、官方入口：路线 B（一站式实时语音对话 StartVoiceChat）](#十、官方入口：路线 B（一站式实时语音对话 StartVoiceChat）)
-
[三、备选一：科大讯飞 ------ 中文语音天花板](#三、备选一：科大讯飞 —— 中文语音天花板)
-
[四、备选二：阿里云 CosyVoice / 通义 ------ 延迟极致](#四、备选二：阿里云 CosyVoice / 通义 —— 延迟极致)
-
[五、备选三：腾讯云 / 百度曦灵 ------ 生态绑定](#五、备选三：腾讯云 / 百度曦灵 —— 生态绑定)
-
[六、海外实时语音 API 对比](#六、海外实时语音 API 对比)
-
[八、成本粗算（以 1 万分钟/月对话为例）](#八、成本粗算（以 1 万分钟/月对话为例）)
你们已经把数字人形象这一层做好了，要补的是"听---理解---说"的语音链路。这里有个关键判断：别再买整套数字人 API（那会把你自研的形象替换掉），而是单独接入语音对话组件------ASR（语音识别）+ LLM（大脑）+ TTS（语音合成），把 TTS 输出的音频流喂给你现有的数字人做口型驱动即可。
下面按国内中文场景给出明确选型。
🎯 默认推荐：火山引擎（字节豆包语音）
如果你的场景是中文实时对话、追求"延迟低 + 音质自然 + 接入简单"的平衡，火山引擎 TTS 是国内开发者综合首选。
• 首包延迟 300--400ms（WebSocket 流式合成），音质主观评分 9/10
• 定价约 1.3 元/千字，新用户有试用额度
• 完整 SDK（Python / Java / Go / Node.js），文档清晰
• 同生态下可以一起用豆包大模型做对话大脑，端到端延迟可控
配套链路建议：
• ASR：火山引擎同款"豆包语音识别"，或者接讯飞听见 / 百度 ASR
• LLM：豆包 1.5 Pro 已支持端到端语音对话，月活过亿；也可以用 DeepSeek、Qwen 等低成本方案
• TTS：火山引擎豆包语音
💡 这条链路的优势是"一家搞定、延迟最低、中文自然度够用"。
备选一：科大讯飞 ------ 中文语音天花板
如果你的数字人用在教育、客服、政务、金融等"语音品质就是产品"的场景，讯飞是更稳的选择：
• 中文 MOS 评分 4.5+/5.0，接近真人发音
• 支持 20+ 方言 + 8 种外语实时切换，语音识别准确率 98%+
• 讯飞智作提供数字人实时驱动 API，语音与口型驱动深度打通，支持情绪音色匹配微表情
⚠️ 代价：讯飞 API 生态偏封闭，需要企业资质审核，价格不透明，中小开发者接入体验不如火山顺滑。
备选二：阿里云 CosyVoice / 通义 ------ 延迟极致
如果你对延迟极度敏感（比如实时客服、语音助手）：
• CosyVoice 2 首包延迟可低至 ~80ms，端到端对话延迟约 1.2 秒，接近真人电话的 0.8 秒
• 开源 Apache 2.0，3 秒零样本音色克隆
• 阿里云百炼平台有托管 API，也可自部署
2026 年 1 月阿里开源的 Qwen3-TTS 更是做到 97ms 端到端延迟 + 3 秒音色克隆，Apache 2.0 商用免费。
适合"用量大 + 要自部署 + 控制成本"的团队。
备选三：腾讯云 / 百度曦灵 ------ 生态绑定
• 腾讯智影：如果你们数字人要走微信生态、视频号，腾讯智影的数字人 API 是原生的；个人免费版仅开放录播，完整实时对话需企业套餐
• 百度曦灵：文心大模型底座，情感自然度国内领先，主要面向企业客户，价格偏高、门槛高
如果你想"一步到位"用海外实时语音 API
海外方案在中文场景未必比国内厂商更合适，但技术上值得了解：
API 架构 延迟 价格/分钟 适合场景
OpenAI Realtime 半双工 ~450ms ~$0.06 多语言、生态成熟
Gemini Live 半双工 ~400ms ~$0.01 多模态、成本低
ElevenLabs Conversational 半双工 ~350ms ~$0.05 音质天花板
Seeduplex 全双工 ~200ms $0.008 真·同时听说，支持中英
⚠️ 海外方案的硬伤：国内访问延迟高、需代理、合规风险、中文口型效果弱于国产平台。除非你做出海业务，否则中文数字人对话优先选国内厂商。
我的建议路径
按你"已自研数字人形象"的前提，我建议这样落地：
- 先用火山引擎跑通 MVP：豆包 ASR + 豆包 LLM + 豆包 TTS，三家一套，端到端时延最优，成本最低
- TTS 环节做 A/B 测试：火山 vs 讯飞，让最终用户盲测音质------中文自然度讯飞略胜，但火山差不了太多
- 如果做实时打断：必须上全双工方案。目前国内厂商的全双工实时对话 API 仍在早期，海外可选 Seeduplex（~200ms，支持中英）
- 口型驱动对接：把 TTS 返回的音频流（或时间戳标记）喂给你现有数字人渲染层，唇形同步用你们自己的引擎处理，或者接阿里云 RTC 的实时会话 SDK
📌 关键提醒：选型时务必自己做端到端时延测试------用户停止说话 → 数字人开始发声的总延迟。超过 800ms 用户就能明显感觉到"慢"，理想值在 400ms 以内。实验室数据往往比生产环境乐观 30%--50%。
成本粗算（以 1 万分钟/月对话为例）
• 火山引擎全链路：TTS 约 1.3 元/千字 × 假设 150 万字 ≈ 2000 元 + ASR/LLM 费用，月成本预计在 3000--5000 元
• 全自部署开源方案（Qwen3-TTS + CosyVoice + DeepSeek）：单卡 4090 硬件折旧+电费约 520 元/月，用量越大越划算
• OpenAI Realtime：约 $3000/月（≈2 万人民币），贵 5-10 倍
如果你们是中小项目验证阶段，火山引擎按量付费是最稳的起点；如果月调用量超过 5 万分钟，自部署开源 TTS 会更省。
你这个数字人主要用在什么场景？是直播带货、政务大屏、教育陪练还是客服？不同场景对"低延迟"和"高音质"的权重不一样，我可以帮你把链路再收窄到具体配置。
给你最直接的官方入口，按"自己分别接 ASR + LLM + TTS"和"一站式实时语音对话"两条路给：
🛠 路线 A：分别接入三个 API（MVP 推荐）
这是上一轮说的"三家一套"的具体地址：
-
火山方舟控制台（统一管理 API Key）
-
豆包 LLM 接入文档（火山方舟）
https://www.volcengine.com/docs/82379/1159164
• API Base URL：https://ark.cn-beijing.volces.com/api/v3（兼容 OpenAI 格式）
• 模型列表与价格：https://www.volcengine.com/product/doubao
- 豆包 ASR + TTS 接入文档（语音模型接入总文档）
https://www.volcengine.com/docs/82379/2516286
• 流式 TTS 双向 WebSocket 地址：wss://openspeech.bytedance.com/api/v3/plan/tts/bidirection
• 流式 TTS 单向 WebSocket 地址：wss://openspeech.bytedance.com/api/v3/plan/tts/unidirectional/stream
• ASR 资源 ID：volc.seedasr.sauc.duration
• TTS 资源 ID：seed-tts-2.0
-
豆包语音总文档（含 SDK、音色列表、双向流式细节）
-
TTS 单向流式接口详细参数
💡 跑通 MVP 的最小动作：方舟控制台拿 API Key → 开通语音技术产品 → 用上面的 WebSocket 地址分别接 ASR 和 TTS → LLM 走方舟的 /api/v3 接口。
🎯 路线 B：一站式实时语音对话（StartVoiceChat）
如果你不想自己拼装三个服务、希望火山帮你把 ASR+LLM+TTS 串成实时语音对话管道，直接用实时音视频的 StartVoiceChat 接口：
接口文档：https://volcengine.com/docs/56651/1404673
请求地址：
POST https://rtc.volcengineapi.com?Action=StartVoiceChat\&Version=2024-12-01
请求体里的 Config 可以同时配置 ASRConfig、TTSConfig、LLMConfig，且官方文档的示例就是火山自家三家服务（Provider: volcano / volcano_bidirection / Mode: ArkV3）。
配套的 AI 音视频互动方案接入指南：https://volcengine.com/docs/6348/2137641
端到端实时语音大模型接入：https://www.volcengine.com/docs/6348/1902994
⚠️ 这条路的 StartVoiceChat 走的是 RTC 房间机制，适合"真人用户进房与 AI 对话"的场景。如果你是自己模拟的数字人形象、需要拿到音频流自己去驱动口型渲染，路线 A 更灵活------你能拿到 TTS 返回的 PCM 音频流，直接喂给自研数字人。
给你的具体建议
你既然"自己模拟了数字人形象"，意味着你需要拿到 TTS 合成的音频流去驱动口型。这种情况下：
- 走路线 A，用双向流式 TTS WebSocket 地址 wss://openspeech.bytedance.com/api/v3/plan/tts/bidirection，流式接收 PCM 音频
- 把 ASR 识别到的文本传给豆包 LLM（ark.cn-beijing.volces.com/api/v3/chat/completions）
- LLM 输出的文本流式送进 TTS
- TTS 回传的音频流喂给你的数字人口型驱动层
这样整条链路都在火山生态内，延迟最优。
要不要我顺着路线 A 给你一份最小可跑通的 Python 伪代码骨架？把 ASR → LLM → TTS 三个 WebSocket/HTTP 调用串起来，你直接替换 API Key 就能调试。
完全可以，而且提示词（System Prompt）是 StartVoiceChat 原生支持的，知识库 RAG 则需要走"代理注入"或"方舟知识库接入点"间接实现。下面分开说清楚。
一、提示词：直接写在 LLMConfig 里（零成本）
StartVoiceChat 的 LLMConfig 提供了三个字段来控制大模型的人设和行为，这就是你的"提示词入口"：
"LLMConfig": {
"Mode": "ArkV3",
"EndPointId": "epid****212",
"MaxTokens": 1024,
"Temperature": 0.1,
"TopP": 0.3,
"SystemMessages": [
"## 人设\n你是一个全能的超级助手，具备强大的知识库、情感理解能力和解决问题的能力。你的目标是高效、专业、友好地帮助用户完成各类任务；\n\n## 约束\n始终主动、礼貌、有条理；\n回答准确但不冗长；\n不清楚的任务会主动澄清，不假设、不误导。"
],
"UserPrompts": [
{ "Role": "user", "Content": "你好" },
{ "Role": "assistant", "Content": "有什么可以帮到你的?" }
],
"HistoryLength": 3
}
三个核心字段的含义 ：
• SystemMessages（String\[\]）：系统提示词，定义角色、行为准则、输出格式。这是你注入人设、业务规则、回答约束的主入口
• UserPrompts（Object\[\]）：用户提示词，注入示例对话来增强回复质量（推荐用这个，具有自动逐出机制，比旧的 UserMessages 更稳定）
• HistoryLength：历史问题轮数，默认 3
💡 如果你还需要让数字人做动作/表情，可以在 System Prompt 里约定括号指令格式（如 (action:wave)），配合 IgnoreBracketText 功能，这些指令不会被 TTS 朗读，但会通过字幕下发到客户端驱动你的数字人 。
⚠️ 重要前提：以上配置只在你使用 LLMConfig（如 Mode: ArkV3） 时生效。如果你改用 S2SConfig 启用了纯端到端语音模型（OutputMode=0），那 LLMConfig 的相关配置将完全无效 ------端到端模型不走独立的 LLM 文本环节。
二、知识库 RAG：StartVoiceChat 没有"一键绑定"字段，但有三条可行路径
官方文档里 LLMConfig 并没有一个 KnowledgeBaseId 这样的字段让你直接绑定火山方舟知识库。要接动态知识库，本质思路是：先把知识检索出来，再作为上下文喂给大模型。有三种落地方式：
路径 1：方舟知识库 + 自定义 LLM 代理（推荐，最灵活）
这是生产环境最稳的方案：
- 在火山方舟创建知识库：使用知识库 API 创建库、导入文档、创建实验版本
- 创建一个自定义推理接入点（Endpoint），在高级配置里启用"上下文增强"→ 勾选"启用知识库检索"→ 选择你的知识库 → 设置相关性阈值（如 0.65）和返回片段数量（如 3）
- StartVoiceChat 的 LLMConfig.Mode 设为 CustomLLM，把 Url 指向你自己的 Agent 服务
- 你的 Agent 服务收到用户问题后，调用方舟的 search_knowledge 或 service_chat 接口做语义检索 ，把召回的文本片段拼进 System Prompt，再转发给方舟 Endpoint 拿到最终回答
CustomLLM 模式还支持通过 Custom 字段和 ExtraHeader 透传业务参数（如 user_id、biz_id）到你的 Agent 服务 ，方便做多租户隔离。
路径 2：直接用方舟"上下文增强"接入点（最快，但灵活性低）
火山方舟控制台支持给推理接入点绑定知识库作为上下文增强：
• 火山方舟控制台 → 在线推理 → 推理接入点 → 编辑 → 高级配置 → 上下文增强 → 启用知识库检索 → 选择知识库
• 绑定后，该接入点所有 API 调用都会自动携带知识库检索结果作为 System Prompt 的一部分
• 把这个 Endpoint ID 填到 StartVoiceChat 的 LLMConfig.EndPointId 即可
这种方式配置最简单，但缺点是你无法在运行时动态调整检索策略、无法做多路召回融合、无法做业务路由。
路径 3：第三方 LLM / Agent 模式（完全自建 RAG）
如果你已经有自己的 RAG 管线（比如用 LangChain、LlamaIndex 搭的，或者用 Qwen3-Embedding + 向量数据库自研的），直接把 LLMConfig.Mode 设为 CustomLLM，Url 指向你的 RAG 服务 HTTPS 地址即可 。你的服务需要兼容火山定义的第三方大模型接口协议。
三、给你的具体建议
考虑到你"自己模拟了数字人形象"这个前提，我建议这样组合：
🎯 推荐架构：StartVoiceChat + LLMConfig.Mode=CustomLLM → 你的 Agent 代理服务 → 方舟知识库检索 + 方舟豆包 LLM
理由：
- 数字人驱动需要字幕/指令下发：CustomLLM 模式下你可以完全控制返回的文本格式，方便下发 (action:xxx) 类指令驱动数字人表情口型
- 知识库可动态更新：你的 Agent 层可以热插拔不同的知识库（售前知识库/售后知识库/产品FAQ），不必改 StartVoiceChat 配置
- 业务数据透传：CustomLLM 支持 Custom 和 ExtraHeader 字段 ，可以把用户 ID、会话 ID 等带到你的 RAG 服务做个性化检索
- 未来扩展：函数调用（Tool Calling）也通过 CustomLLM 模式支持，你的 Agent 可以声明工具让模型调用
最小可跑通的配置骨架：
{
"Config": {
"LLMConfig": {
"Mode": "CustomLLM",
"Url": "https://your-agent-service.com/v1/chat-stream",
"Custom": "{"user_id": "u_123", "kb_id": "product_faq"}",
"ExtraHeader": {
"X-Service-Token": "your_token"
}
}
}
}
你的 Agent 服务内部逻辑：
- 收到用户 query + Custom 里的 kb_id
- 调用方舟 search_knowledge 接口检索对应知识库
- 把检索结果 + System Prompt 拼装，调用方舟 chat/completions 接口
- 流式返回 LLM 回复给火山 RTC
⚠️ 几个容易踩的坑
坑 1：TopUserPrompts / UserPrompts 会占用 HistoryLength 的空间 ，如果你注入大量知识文本到 UserPrompts，会挤压真实对话历史的轮数，导致模型"忘记"前面的对话。知识库内容应该走 SystemMessages 或通过 CustomLLM 代理注入，而不是塞进 UserPrompts。
坑 2：纯端到端语音模式（S2SConfig + OutputMode=0）下 LLMConfig 配置无效 ，如果你选了端到端模型就不能用上面这套提示词 + RAG 方案，必须回到 Mode: ArkV3 的文本 LLM 模式。
坑 3：知识库检索会增加端到端延迟。每次对话多一次向量检索（通常 +50~200ms），如果你的场景对延迟极度敏感，可以考虑预检索或缓存策略。
你的数字人场景里，知识库的内容量级大概是什么规模？是几百条 FAQ 还是几十万文档？这决定了是用方舟托管知识库就够了，还是需要自己搭向量库做精细化召回。