Liquid AI 开源 74M 参数 LiquidCodec 编码快 13 倍，却解不开 CPU 实时语音死结

2026 年 11 月 12 日，Liquid AI 开源了支撑 LFM3-Audio-2B 与 LFM3-Omni-2B 的流式语音分光器 LiquidCodec（模型卡参数量 73.6M），正式替换掉上一代 LFM2-Audio-1.5B 借用的 Kyutai Mimi（96.2M 参数）。在 Apple M4 Max 单核 CPU（FP32）自测中，它的编码速度达到 361 倍实时（RTF 0.0028，比 Mimi 快约 13 倍），解码达 87 倍实时（RTF 0.0115，快约 2.9 倍），并在 8 个多语种测试集上拿下了最佳 ViSQOL 重建音质与下游 TTS 自然度（UTMOSv2）。账面数字很亮眼，但把配置源码与社区实测拼在一起看，这颗编解码器的真实工程意义，在于它为迁就语言模型预测能力所做的底层交换，以及戳破了编解码器极速等于端侧语音极速的错觉。

在原生语音大模型里，编解码器既要把声音压得足够轻，又得让产出的离散 token 容易被语言模型猜中。为了兼顾这两头，LiquidCodec 在 24 kHz 采样率、12.5 Hz 帧率（每帧 80 ms 切成 12 个码本 token，即每秒 150 个 token）下，彻底放弃了 Mimi 等主流方案采用的残差矢量量化（RVQ），改用分组有限标量量化（GFSQ），并在解码端直接预测频谱系数，砍掉了极其吃算力的学习型转置卷积上采样。

为什么宁可牺牲音色还原，也要换掉 Kyutai Mimi

RVQ 的宿命是每一层码本都在修补上一层的残差，码本之间必须串行依赖；而 GFSQ 各组相互独立，允许 MaskGIT 风格的 Transformer 一次性并行预测全部 12 个码本。这种对语言模型胃口的迁就，在受控 TTS 实验中立竿见影——当 Liquid AI 固定 101,000 小时 6 语种数据、1.7B 模型底座（LFM3-1.7B 与 Qwen3-1.7B 均成立）以及 3 个生成随机种子，仅更换底层编解码器时，LiquidCodec 在 LibriSpeech test-clean 上的合成词错误率（WER）直接压到了 3.15%，几乎是 12 码本截断版 Mimi（6.27%）的一半，也优于 NVIDIA NanoCodec（3.32%）和 HKUST Audio 的 X-Codec 2（4.19%）。

语音分光器的第一性原理，正在从声学无损还原转向迁就大模型的预测智商。

这种高可预测性并非没有代价。官方宣传稿隐去了实际比特率，但翻看仓库源码的默认配置，其 FSQ 级别设为 [8, 7, 6, 6]，意味着每个码本 token 有 2,016 种可能值；按每秒 150 个 token 与固定 11-bit 打包推算，LiquidCodec 的真实有效载荷比特率约为 1.65 kbps，比原生 8 码本 Mimi 的 1.1 kbps 宽裕了整整一半。此外，Liquid AI 在测试中为了对齐 12 码本，将原生 8 码本的 Mimi 设为 12 码本截断测试，且自身速度测试用 FP32、音质重建测试用 BF16，基准设定的微调也放大了领先身位。

即便给足了码率，GFSQ 为迎合大模型并行预测，依然在纯声学细节上交了买路钱。在衡量宽带语音感知质量的 PESQ（WB）指标上，NVIDIA 的 NanoCodec（62M 参数，1.78 kbps）在 8 个测试集中的 7 个击败了 LiquidCodec；在决定零样本声音克隆成败的说话人相似度（SECS）上，LiquidCodec（0.785）也明显落后于 NanoCodec（0.836）。

单核 87 倍解码的真相与端侧落地的三个门槛

很多端侧开发者看到 M4 Max 单核 CPU 361 倍编码、87 倍解码的数字，第一反应是纯靠笔记本或手机 CPU 就能跑通实时语音对话了。这是整份技术报告最容易引人踩坑的盲区——官方测出的只是编解码器自身的纯吞吐量，而在真实的流式语音链路里，算力黑洞从来都是前面那颗 20 亿参数的语言模型骨干。

社区独立评测项目 5uck1ess/tts-bench 在 2026 年 10 月底对集成了 LiquidCodec 的 LFM3-Audio 流式 TTS 路径做了重测。走标准 Hugging Face Transformers 管线时，RTX 3090 和 RTX 5090 的热启动首音频延迟（TTFA）分别为 42 ms 和 55 ms（持续生成 1.8 至 2.2 倍实时）；但一旦切回纯 CPU，热启动首包延迟直接飙升到 450 至 550 ms（冷启动约 1.6 秒），持续生成速度暴跌至 0.3 至 0.4 倍实时——连基本的不断音播放都维持不了。同时要注意，官方宣称的 50 ms 首 token 时间（TTFT）属于 LFM3 增量预填充指标，80 ms 也只是单帧切片时长，都不是端到端的出声延迟。

想在本地设备真正跑顺这套模型，开发者必须跨过标准 Transformers 管线，依赖两套硬核的端侧优化：一是官方在两阶段训练（264,000 小时 107 语种预训练 + 55,000 小时全频段对抗微调消除金属音）之外，专门做的仅解码器量化感知训练（QAT），把随 LFM3 GGUF 分发的 Q4_0 解码器体积压缩了 3.5 倍，而 LibriSpeech ViSQOL 仅从 4.319 微降至 4.292（WER 从 3.15% 微升至 3.18%）；二是像 FluidInference 发布的 Apple Core ML 转换版那样，采用 int8 语言模型加 FP16 编解码器的异构加速，在 M5 Pro 上才能跑出 37 ms 的中位首音频延迟和 4.3 至 4.5 倍实时的持续生成速度。

• 风险.正在评估是否将语音底座切向 LiquidCodec 的团队，眼下还要盯紧三处工程与合规暗礁。第一，官方明确声明完全没有对音乐、歌唱和环境背景音做评估，这颗纯语音特化的分光器放在号称全模态的 LFM3-Omni 里，遇到复杂声学背景或哼唱交互极易露怯；第二，独立仓库 LiquidAI/Liquid-Codec 目前只放出了推理代码与 BF16 权重，缺失基准测试运行脚本与评估清单，其 Q4_0 量化表现尚待第三方复现；第三，模型卡虽笼统标为 other 许可，但背后绑定的 LFM Open License v1.0 设有 1000 万美元年营收的免费商用红线，超额企业必须另签商业授权，绝非像 Kyutai Mimi（CC-BY 4.0）那样可以无条件免责集成。