把语音助手拆成四个零件，每个都能换，这就是 speech-to-speech 做的事。

这个项目来自 HuggingFace，是一套用纯开源模型搭建的语音对话流水线。 它把语音活动检测、语音识别、大语言模型和语音合成串成一条四级流水线，每个组件独立运行在自己的线程里，通过队列传递数据。对外暴露的是 OpenAI Realtime 兼容的 WebSocket 接口，任何支持这个协议的客户端都能直接连上来用。

项目目前处于 v0.2.11，还在快速迭代中，过去两周内有多次提交。但它已经不是实验室玩具了——HuggingFace 自家的 Reachy Mini 机器人产品线已经把这个流水线作为对话后端，跑在数千台硬件上。这种"自己的模型自己用"的路线，比先开源再找场景要踏实得多。

上手简单得不像话。装一个包，设一个环境变量，跑一条命令，语音助手就起来了。

pip install speech-to-speech
export OPENAI_API_KEY=...
speech-to-speech

这三行背后发生了什么？一个 WebSocket 服务器在 ws://localhost:8765/v1/realtime 上启动，默认使用 NVIDIA 的 Parakeet TDT 做语音识别，你指定的 OpenAI 模型做对话理解，阿里的 Qwen3-TTS 做语音合成。每个环节都可以通过命令行参数替换，比如想把 LLM 跑在本地的 llama.cpp 上：

llama-server -hf ggml-org/gemma-4-E4B-it-GGUF \
  -np 2 -c 65536 -fa on --swa-full

speech-to-speech \
  --model_name "ggml-org/gemma-4-E4B-it-GGUF" \
  --responses_api_base_url "http://127.0.0.1:8080/v1" \
  --responses_api_api_key ""

这条流水线的核心设计哲学是全模块化。 VAD 环节使用 Silero VAD v5 做语音边界检测，STT 有 6 种引擎可选、LLM 提供 4 种接入方式、TTS 支持 5 种实现，你可以按硬件和场景任意组合。比如 macOS 用户走 MLX 加速路径（Apple Silicon 优先是这个项目的明确设计取向），Linux 用户走 GGML/CUDA，Windows 用户……好吧，README 里没怎么提 Windows，这算一个槽点。

组件替换不只是"支持多种"，每个后端的选择都有明确的场景理由。Parakeet TDT 作为默认 STT 是因为它在低延迟场景下表现稳定；Qwen3-TTS 作为默认 TTS 是因为它支持多语言且能流式输出；Silero VAD v5 处理语音边界检测是因为它轻量且准确。没有一个是随便选的。

和同类方案相比，speech-to-speech 的差异点在于"管道化"而非"框架化"。 LiveKit Agents（github.com/livekit/agents）是一套更完整的实时多模态 Agent 框架，偏向 WebRTC 传输和复杂的会话管理，适合需要生产级可观测性的团队；Pipecat（github.com/pipecat-ai/pipecat）是 Python 生态中更成熟的语音 AI 管道框架，有更丰富的客户端 SDK 和调试工具。speech-to-speech 的优势在于零配置起步和 HuggingFace 模型生态的直接整合——你不需要理解 WebRTC 信令流程，不需要写任何管道编排代码。代价是灵活性受限于它预设的四级级联架构，如果你想做的不止于 VAD-STT-LLM-TTS 这个固定模式，就得自己改源码了。

今日同在榜上的微软 VibeVoice 则走了另一条路：聚焦于模型本身（ASR 和 TTS 的权重），不提供管道编排。两个项目其实可以组合使用——用 VibeVoice 的模型替换 speech-to-speech 流水线中的 STT 或 TTS 环节。

安装和运行虽然简单，实际部署时会碰到几个坑。 第一个是 CUDA 版本匹配问题。Qwen3-TTS 的 GGML 后端默认 CUDA 12.8，如果你的机器是 CUDA 13.x 或 12.4 甚至纯 CPU，必须先装正确的 qwentts-cpp-python wheel，再装 speech-to-speech，顺序反了会报错。第二个是依赖冲突：DeepFilterNet（用于 VAD 音频增强）需要 numpy<2，而 Pocket TTS 需要 numpy>=2，两者不能共存。第三个是 TCP socket 模式功能受限：不支持中断处理、实时转录事件和工具调用事件——如果你需要完整的 Realtime API 能力，必须用 WebSocket 模式。

管道本身对 STT 和 TTS 后端的语言覆盖有要求，比如默认的 Parakeet TDT 只覆盖 25 种欧洲语言。想用中文，得换 Whisper 或 Paraformer 做 STT，同时确保 LLM 和 TTS 也都支持中文输出。

这个项目适合谁？ 如果你想在树莓派或 MacBook 上跑一个完全不依赖云端的语音助手，或者你在做一个需要可定制语音前端的硬件产品，speech-to-speech 是目前门槛最低的选择之一。它的四级流水线架构很适合作为原型验证工具——先用默认配置把整个链路跑通，再逐一替换每个环节做 A/B 测试。不适合的场景也很明确：如果你需要多人同时对话的会议室场景（VAD 部分不够）、需要精细控制音频路由的复杂呼叫中心、或者你的团队对 Python 和模型部署不熟，那这套工具的学习成本可能比看起来高。

最后说一个细节，这个项目对中断处理（barge-in）下了很大功夫。 语音助手的体验好不好，很大程度上取决于用户能不能随时打断它。speech-to-speech 的 VAD 模块支持推测性轮次——在用户说到一半时就开始处理，如果判断用户还要继续说就重新打开窗口。配合实时转录功能，用户可以在对方还在说话时就看到自己语音的文字反馈。这种交互细节上的打磨，比支持多少种 TTS 后端更能体现项目成熟度。

项目地址：https://github.com/huggingface/speech-to-speech

竞品参考：

- LiveKit Agents：https://github.com/livekit/agents
- Pipecat：https://github.com/pipecat-ai/pipecat
- Microsoft VibeVoice：https://github.com/microsoft/VibeVoice