Audio8 的纯 CPU 运行时让语音克隆在约 1 GiB 内存中运行

以下是 Audio8 TTS ONNX Runtime 发布中最重要的数字：在一台 16 GB Apple M2 MacBook Air 上，使用五个 ONNX Runtime 线程，推理服务在加载后稳定在约 1004 MiB 内存，合成期间峰值在 1.1 至 1.2 GiB 之间。这意味着语音克隆和语音生成可以在笔记本电脑 CPU 上完成，无需 GPU。模型文件在线约 572 MiB，如果加上可选的语音注册编码器，则约为 968 MiB。

该运行时是 Audio8-TTS-Preview-0.6B-ONNX-INT4 的纯 CPU 配套版本，后者是 Audio8 以 Apache 2.0 协议发布的开权重模型。该模型的卖点是 11 种语言、从短参考样本进行零样本语音克隆，以及内置 44.1 kHz 编解码器，面向需要速度和隐私的边缘语音应用。这个 ONNX 移植版让这一卖点在 GPU 盒子之外变得切实可行：权重下载后，推理既不需要 PyTorch，也不需要 Transformers 或 Hugging Face Hub。

该运行时实际需要多少资源

精度按角色分配。慢速和快速自回归权重（模型中生成编解码器码的部分）采用仅权重的 INT4。激活值、隐藏状态和 KV 缓存保持 FP16，编解码器编码器和解码器也是如此。只有最终的波形输出是 FP32。

常规合成只加载三个会话：慢速 AR、快速 AR 和编解码器解码器。内置编解码器是流水线保持如此轻量的部分原因：无需额外挂接单独的声码器。合成分两个阶段运行：自回归模型输出编解码器码，编解码器解码器将其转换为音频。CLI 会将这些码写入 .wav 输出旁边的 .npy 文件。

语音注册遵循相同的逻辑。语音档案是从参考录音中提取的一组编解码器码：时长 0.5 至 30 秒，不超过 50 MiB，可被 libsndfile 读取，并由服务转换为单声道 44.1 kHz。录音必须与其精确转写文本配对。编码器仅在此步骤加载，将内存推至约 1.55 GiB，然后卸载，使合成会话恢复。README 对弱点直言不讳：嘈杂、过长或转写错误的参考录音会降低稳定性和说话人相似度。

为部署而生，而非演示

依赖预算才是这里真正值得注意的消息。要求是 Python 3.11 或更高版本、用于一次性下载的 Hugging Face Hub CLI，以及固定的目录结构。Audio8 已在 macOS arm64 上使用 CPUExecutionProvider 对当前版本进行了测试。从那里开始，它是一个运行在 127.0.0.1:8024 上的 HTTP 服务，有三种接入方式：网页、位于 /api/tts 的 JSON API，以及以 WAV 响应的 OpenAI 兼容端点 /v1/audio/speech。已针对该 API 形状编写的代码可以改为指向本地模型。流式传输通过 /api/tts/stream 运行，该端点返回以换行分隔的 JSON，包含 base64 编码的 16 位 44.1 kHz PCM，/api/tts/cancel 可停止活动流。CLI 脚本覆盖脚本化使用场景，日志写入 service.log。

该服务将合成和注册请求串行化，这是一种刻意的取舍：以并发为代价来限制内存使用。README 将其定位为本地使用和低并发 CPU 部署。线程数、模型目录、语音目录、主机和端口都是带有合理默认值的环境变量，一个停止脚本可关闭托管的后台服务。

小模型时刻

Audio8 发布之际，小型语音模型正在不断缩小与大型模型的差距。Voxtral Realtime 是研究人员推出的开源流式语音识别模型，声称其转写能力与 OpenAI 的 Whisper 相当，延迟仅为 480 毫秒。0.6B TTS 预览版低于大多数开源 TTS 模型聚集的 1B 门槛，并且无需微调即可从短样本克隆声音。开权重运动也在公开场合提出同样的论点：41 位签署方最近在一封信中为开放模型辩护。Audio8 的贡献在性质上有所不同：它是生成式的，创造语音而非转写语音，而且本地运行时作为一等公民交付，而非事后补充。

注意事项都写在数据里。加载后约 1 GiB 的工作集适合 16 GB 笔记本电脑，而不是手机。串行化请求队列在设计上限制了吞吐量，而且正如 README 所指出的，测量结果会因操作系统和 ONNX Runtime 分配器行为而有所不同。但这一方向很难反驳：不久前还需要 GPU 盒子才能运行的自回归加编解码器流水线，现在在 CPU 线程上渲染还绰绰有余。本地语音克隆现在是一个工程选择，而非基础设施决策。