VoxCPM2 开源多语种语音生成模型

VoxCPM2 想让开源语音合成同时做到三件事：读懂多语言文本、按描述创造声音、保留参考音频里的说话特征。它提供了 Python 调用、兼容 OpenAI 的服务接口和本地 C++ 推理路径，值得程序员关注的，是从试音到接入应用的这条链路。

但项目展示的能力与生产可用之间仍有距离。48kHz 输出不等于听感必然更好，生成速度快也不等于首段声音来得快。读这份项目说明，最有用的是把功能、部署条件和证据边界分开看。

不把语音切成离散 token，解决了什么问题

VoxCPM 的核心路线是 tokenizer-free TTS，也就是不先把语音压成一串离散编号，再预测这些编号，而是在连续的语音表示上生成声音。这里的 tokenizer-free 指语音生成路径，不能理解成整个系统完全不用文本分词。

项目采用扩散自回归架构，以 MiniCPM-4 为骨干，在 AudioVAE V2 的潜在空间中工作，流程是 LocEnc → TSLM → RALM → LocDiT。可以把潜在空间理解成音频的一种内部压缩表示：模型先在这层表示上生成，再还原成可播放的声音。

作者希望借此保留更细的韵律、情绪和音色变化。不过，这份说明没有给出隔离变量的对照实验，无法仅凭架构名称确认它比离散 token 路线好多少。

VoxCPM2 的规模是 2B 参数，训练数据超过 200 万小时，支持 30 种语言，输入文本时不需要语言标签。项目还列出了四川话、粤语、吴语、东北话、河南话、陕西话、山东话、天津话、闽南话，但没有在提供的内容里展示逐项效果。

音频规格上，AudioVAE V2 使用非对称编解码设计，接受 16kHz 参考音频，直接输出 48kHz 音频，内置超分辨率，不需要外置上采样器。这能减少处理环节，但不能理解成低采样率录音里已经丢失的细节都会被准确找回。

设计声音和克隆声音，需要的输入不同

VoxCPM2 把声音生成拆成了三种工作方式，选择依据是你手里有什么素材。

Voice Design 不需要参考音频。把性别、年龄、语气、情绪、语速等描述放在文本开头的括号里，模型据此创造声音。Controllable Cloning 则输入一段参考音频，用它提供音色，再通过文字调整情绪、速度和表达方式。

Ultimate Cloning 需要参考音频及其准确转写，采用音频续写方式保留更多说话特征。作者称这种方式与 VoxCPM1.5 一致，并建议把同一段录音同时传给 reference_wav_path 和 prompt_wav_path，提高相似度。

下面这段原始示例展示了第三种方式需要怎样组织输入：

wav = model.generate(
    text="This is an ultimate cloning demonstration using VoxCPM2.",
    prompt_wav_path="path/to/voice.wav",
    prompt_text="The transcript of the reference audio.",
    reference_wav_path="path/to/voice.wav", # 可选，用于提高相似度
)
sf.write("hifi_clone.wav", wav, model.tts_model.sample_rate)

要看的是 prompt_text：它填写参考录音的准确内容，目标台词仍然放在 text 中。两者混淆，就偏离了这个接口的使用前提。

普通生成示例使用 cfg_value=2.0、inference_timesteps=10、seed=42，加载模型时设置 load_denoiser=False。这些是示例配置，原文没有证明它们适合所有语言和声音。

声音可控，不代表一次生成就能稳定命中要求。

作者明确承认，Voice Design 和 Controllable Voice Cloning 的结果可能波动，需要生成 1～3 次才能得到想要的声音或风格。做配音工具时，这会影响交互设计：试听、重试和保存结果，应当是正常流程的一部分。

接进应用之前，先分清三条运行路线

基础安装命令是 pip install voxcpm，环境要求为 Python ≥ 3.10 且 <3.13、PyTorch ≥ 2.5.0、CUDA ≥ 12.0。国内开发者也可以先通过 pip install modelscope，再用 snapshot_download 下载 OpenBMB/VoxCPM2 到本地目录。

Web Demo 使用 python app.py --port 8808。运行设备可通过 --device 指定为 auto、cpu、mps、cuda 或 cuda:N；Apple Silicon 上，auto 会在 MPS 可用时选用它。这条路线适合先确认音质与功能。

面向服务端，Nano-vLLM-VoxCPM 提供并发请求、异步 API 和 FastAPI HTTP 服务。作者报告，在 NVIDIA RTX 4090 上，标准 PyTorch 实现的实时因子 RTF 约为 0.3，加速后最低约为 0.13。RTF 是生成耗时与音频时长之比，越小越快；它不能单独说明首段音频延迟或高并发下的响应时间。

另一条服务路线是 vLLM-Omni，提供 PagedAttention、连续批处理、多 GPU 部署，以及兼容 OpenAI 的 /v1/audio/speech 接口。原文安装示例固定 vllm==0.19.0，而 vllm-omni 从最新 main 分支安装，也注明它仍在快速演进。

它的调用形态可以直接从原始示例看出来：

vllm serve openbmb/VoxCPM2 --omni --port 8000

curl http://localhost:8000/v1/audio/speech \
  -H "Content-Type: application/json" \
  -d '{"model":"openbmb/VoxCPM2","input":"Hello from VoxCPM2 on vLLM-Omni!","voice":"default"}' \
  --output out.wav

启动命令里的 --omni 用于开启多模态服务。对 Node 或全栈项目，这条 HTTP 路径更容易接入现有后端，但示例只展示了基础请求，没有说明完整的声音控制参数如何映射到该接口。

本地运行则有无需 Python 的 llama.cpp-omni，支持 CPU、Metal、CUDA、Vulkan。它需要一份 BaseLM 权重和一份 Acoustic 权重，BaseLM 可选 F16 或 Q8_0。作者称 Q8_0 下载量约减半、质量损失很小，但没有在这里给出听感对照。

Apple M4 Pro / Metal 上，Q8_0 的 RTF 约为 1.76，生成耗时长于音频时长。能在 Mac 上运行，与能够实时对话，是两个需要分别验收的目标。

我的判断

我认为它最值得关注的地方，是把声音设计、克隆、流式输出和多种部署入口放进了同一套项目里。对于想保留模型部署控制权的团队，这比只有一个试听 Demo 更有用。代码和权重采用 Apache-2.0，也降低了商业接入的许可门槛。

但「达到领先或可比水平」仍需看具体证据。原文提到了 Seed-TTS-eval、CV3-eval、MiniMax 多语言测试，却没有提供展开后的成绩表。内部测试采用 30 种语言 × 500 条样本，由 Gemini 3.1 Flash Lite API 做 ASR 转写评估，也没有在输入材料中列出结果。

WER/CER 衡量转写错误，SIM 关注说话人相似度，它们不能替代自然度、情绪表现和长文本稳定性的试听。48kHz 更是输出规格，不能单独支撑「录音棚级」听感。

与托管 TTS API 相比，自部署需要团队承担环境、容量和故障处理；与其他开源 TTS 路线相比，这份材料不足以作出全面优劣判断。作者提出用 5～10 分钟音频进行 SFT 或 LoRA 适配，也应视为可尝试的起点，不能当成效果保证。

此外，Apache-2.0 许可并不代替对参考声音使用权限的确认。项目明确禁止冒充、欺诈和虚假信息用途，并建议标注 AI 生成内容。

能拿来做什么

• 做配音或朗读功能时，先用真实业务文本测试中文、英文混排、数字和长句，分别记录可懂度、停顿与重试次数，再决定是否接入。
• 在 Node 后端对接 /v1/audio/speech，先跑通文本到音频的闭环；需要边生成边播放时，再单独验证服务端分块与前端播放。Python 的 generate_streaming 示例把分块最终拼成文件，没有展示浏览器实时播放链路。
• 做字幕配音时，可以试用 pip install "voxcpm[timestamps]" 和 --timestamps --timestamp-level word --timestamp-language en。中文可选 --timestamp-level char --timestamp-language zh，但字符时间戳由词级对齐推导，只是尽力估计，需要人工校对。
• 确有固定说话人适配需求时，再比较参考音频克隆与 SFT、LoRA 的收益；5～10 分钟素材是否够用，应由自己的试听集验证。