我之前在 NAS 上跑过几个 TTS 服务，最后发现最烦的不是模型效果，是环境。一个项目要 PyTorch，另一个要特定版本的 CUDA，再来一个依赖 transformers 5.x，Docker 镜像越叠越厚。所以看到 MOSS-TTS 放出 llama.cpp 后端的时候，我第一反应是：终于有人想通了。
MOSS-TTS 是 OpenMOSS 和 MOSI.AI 开源的一套语音合成模型族，Apache 2.0 协议。它不是单一个模型，而是把语音任务拆成了五条线：高保真克隆的 MOSS-TTS、多人对话的 MOSS-TTSD、凭空设计音色的 VoiceGenerator、生成音效的 SoundEffect，还有实时对话的 Realtime。最近又加了 Nano 版和 Local-Transformer 版，覆盖从轻量 CPU 到 8B 显卡的场景。
最吸引我的是它支持 PyTorch-free 推理。三月份发布的 llama.cpp 后端用 GGUF 做骨干网络，ONNX Runtime 跑音频 tokenizer，理论上可以在没有 PyTorch 和 CUDA 的环境下直接跑。对于想塞到 NAS 或轻量容器里的人来说，这意味着镜像可以小很多，冷启动也快一些。
官方给了四套预设配置。普通起点用 default.yaml，TensorRT 追求吞吐用 trt.yaml，8GB 显卡选 trt-8gb.yaml 分阶段加载，纯 CPU 就用 cpu-only.yaml。8B 的旗舰模型按官方数据能在 8GB GPU 上跑起来，Nano 版只有约 0.1B 参数，4 核 CPU 就能流式输出。31 种语言里包含中文，粤语也有，这点对中文用户比较友好。
我按文档搭了一遍 llama.cpp 后端。安装比想象中简单，pip install 对应 extras 之后，准备 GGUF 权重和 ONNX tokenizer 即可。KV cache 可以选 q8_0 或 q4_0 量化，配合 Flash Attention 还能再压一压显存。实测环节我主要试了 Local-Transformer 1.7B，在 16GB 内存的 Mac 上走 CPU-only 配置，生成一段 20 秒的中文语音大概几十秒，音色克隆的稳定性比想象中好，长句子的韵律也没有明显断裂。
不过有几个地方需要留意。一是不同后端支持的模型架构不一样：SGLang-Omni 目前是唯一支持 MossTTSLocal 的推理后端，vLLM-Omni 覆盖得更全但不支持 Local。二是 llama.cpp 后端虽然省依赖，但首次准备权重和 tokenizer 还是要花点时间。三是 8B 模型即便能塞进 8GB 显存，也别指望它跟云端 API 比延迟，本地跑更适合离线批量生成或者对隐私要求高的场景。
Realtime 版的数据看起来也不错，首包延迟 180ms，端到端首句 377ms。这个数据是在 L20 GPU 上测的，消费级显卡理论上会慢一些，但用来做本地语音助手已经能看到曙光了。MLX 后端五月也接上了，Mac 用户又多了一条路。
MOSS-TTS 让我觉得有意思的地方，不是它某一项指标刷榜，而是它把”本地可跑”当成了设计目标之一。llama.cpp、GGUF、ONNX、MLX、SGLang、vLLM 这些后端全都有，等于把选择权交给了用户。我会把它留在本地部署候选名单里，下次给 NAS 加语音通知服务的时候再仔细测一遍。