Liquid推出7400万参数流式音频编解码器

Liquid AI 发布的 LiquidCodec，解决的是语音模型中一道容易被忽略的工序：把声音变成模型能预测的 token，再把 token 还原成声音。它约有 7400 万参数，主打容易预测、解码快，已经用于 LFM3-Audio-2B 和 LFM3-Omni-2B。

原文最有价值的地方，是把编解码速度、声音重建和下游语音生成放在一起比较。不过，漂亮的成绩来自 Liquid AI 自测，硬件、评价指标和授权条件都需要拆开看。

为什么语音模型需要另一种编解码器

这里的 codec 不是给播放器换一种文件格式，而是给语言模型提供声音的离散表示。LiquidCodec 接收 24 kHz 音频，以 12.5 Hz 的帧率处理，每个 80 ms 帧生成 12 个离散 token，对应 12 条 token 流。

语言模型预测这些 token，解码器再把它们变回波形。因此，音频压得好只是一个目标，token 是否容易预测、还原声音是否足够快，同样影响语音产品的体验。

LiquidCodec 的模型卡标注参数量为 73.6M，替代了 Liquid AI 在 LFM2-Audio-1.5B 中使用的 Mimi，后者为 96.2M 参数。不过，参数更少不能单独证明推理更快，还得看具体计算路径。

它的编码器和解码器采用 LFM3 架构模块，两部分结构对称。编码器完全因果，也就是处理当前声音时不需要等待未来输入，适合流式接收。原文只确认了编码器的因果性，没有披露解码器是否完全因果。

12 组 token 能并行预测，才是结构上的重点

LiquidCodec 的流程仍是编码、量化、解码，变化集中在后两步。

量化采用分组有限标量量化（GFSQ），替代残差向量量化（RVQ）。RVQ 的各级码本依次补偿前一级没有表达好的信息；GFSQ 的分组相互独立，因此 MaskGIT-style transformers 可以并行预测全部 12 个码本。对生成模型来说，这提供了减少串行预测依赖的条件，但不代表任意接入方式都会自动获得相同加速。

解码器直接预测频谱系数，避开波形解码器中常见的可学习转置卷积上采样。它缩短的是声音还原环节的计算路径。

训练也分了层次。第一阶段使用覆盖 107 种语言的 264,000 小时语音，只使用波形和频谱损失，不使用对抗损失。第二阶段用 55,000 小时全频带语音微调，采样率为 24 kHz 或更高，并引入对抗判别器。Liquid AI 称，这一步消除了第一阶段残留的金属音。

最后还有仅针对解码器的量化感知训练（QAT），服务于边缘推理。这里关于金属音改善的描述属于团队报告，原文没有提供独立听测结果。

跑得快有数据，但音质没有全面领先

速度测试使用 Apple M4 Max MacBook Pro，限定单 CPU 线程、FP32。实时因子（RTF）等于处理耗时除以音频时长，越低越好。

编解码器	编码 RTF	解码 RTF
LiquidCodec	0.0028	0.0115
Mimi	0.0361	0.0329
NanoCodec	0.2145	0.2543
X-Codec 2	0.7359	0.0379

LiquidCodec 的编码约为实时速度的 361 倍，解码约为 87 倍。相对 Mimi，编码 RTF 约低 13 倍，解码约低 2.9 倍。这些数字描述的是 codec 的吞吐能力，不能直接当成语音助手从用户开口到开始回答的延迟。

质量测试覆盖 8 个集合：LibriSpeech test-clean、Seed-TTS 英语和普通话，以及 FLEURS 的德语、法语、普通话、日语、韩语。重建测试中，LiquidCodec 在全部集合上取得最高 ViSQOL 和最低 mel distance，分别衡量感知质量和频谱差异。

LibriSpeech 上，它的 ViSQOL 为 4.319，NanoCodec、X-Codec 2、Mimi 分别为 4.219、4.119、4.031；mel distance 分别为 0.120、0.122、0.123、0.160。

更有说服力的是下游 TTS 对照：团队固定 101,000 小时、6 种语言的数据，以及架构、算力和批次顺序，只更换 codec token。LiquidCodec 在全部 8 个集合上取得最高 UTMOSv2，但 WER/CER 只在 4 个集合上最佳。LibriSpeech WER 为 3.15%，Mimi 为 6.27%；换用 Qwen3-1.7B 和 LFM3-1.7B 骨干网络，结果仍保持。

它也有短板。NanoCodec 在 7 个集合的 PESQ（WB）上更高，LibriSpeech 说话人相似度 SECS 为 0.836，超过 LiquidCodec 的 0.785。保留音色和追求其他感知指标，可能导向不同选择。

我的判断

我更认可这次评估把 codec 放回 TTS 系统比较。只看重建音质，无法判断 token 对生成模型是否友好；固定训练条件再比较下游效果，证据比单独展示音频样例更强。

但这些仍是厂商自测。原文有对照数据，却没有独立复现，也没有端到端交互延迟、实际内存占用或浏览器性能数据。单线程 M4 Max 成绩不能直接套到普通服务器和手机上。

比较条件也不完全齐整：NanoCodec 为 62M 参数、22.05 kHz、1.78 kbps；X-Codec 2 为 0.8B 参数、16 kHz、50 tokens/s；LiquidCodec 的码率未披露。Mimi 的速度和质量比较使用 12 个码本，表中另列的 1.1 kbps 配置不能直接视作同一条件。

授权同样需要核实。LiquidCodec 在 Hugging Face 标为 other，博客指向 LFM License；Mimi 是 CC-BY 4.0，NanoCodec 是 NVIDIA Open Model License，X-Codec 2 是 CC-BY-NC 4.0。权重可下载，不足以判断项目是否符合你的使用条件。

能拿来做什么

• 做语音生成选型时，可以把 LiquidCodec 纳入对照，分别检查内容识别错误、听感和说话人相似度。原文已经说明，这几个目标不会总由同一个 codec 获胜。
• 做服务端原型时，可以从 Hugging Face Transformers 的 trust_remote_code=True 加载路径入手，使用 encode() 获取音频码、decode() 还原波形。模型卡示例采用 CUDA 和 bfloat16；原生 LiquidCodecStreamingCache 支持逐块解码，但原文没有提供 Node 或浏览器直接运行的方案。
• 做边缘部署验证时，可以测试 llama.cpp 的 Q4_0、Q4_K_M、Q8_0 GGUF 构建，相关仓库随 LFM3-Audio-2B 和 LFM3-Omni-2B 提供。Q4_0 配合仅解码器 QAT，使解码器占用缩小 3.5 倍，LibriSpeech ViSQOL 从 4.319 降至 4.292；这个缩减比例针对解码器，不能扩展为整套语音模型。