LFM2.5-Audio-1.5B 部署深度研究：WebGPU / born / GGUF / Ollama 四路拆解

调研日期：2026-07-25 ｜ 方法：5 路并行深度调研 + born 仓库本地源码审计 + 关键信源亲验（HF 文件树 / llama.cpp PR / Liquid 官方文档）
结论先行：GGUF 全链路已可用但依赖官方定制 fork；WebGPU 官方 ONNX 五图方案开箱可跑；Ollama 语音路线死路；born 移植需新写 6 类算子，属"贡献级"工程。

0. 模型架构底盘（一切部署问题的根源）

LFM2.5-Audio-1.5B 不是"一个模型"，而是四件套流水线：

麦克风 → [mel 前端] → FastConformer 音频编码器 (115M, 源自 canary-180m-flash)
       → LFM2.5 骨干 (1.2B, hybrid short-conv + GQA attention, 32k ctx)
       → RQ/depth-transformer (8 codebooks, 2049×8 音频词表)
       → 自研 audio detokenizer (Mimi 兼容, LFM-based) → 24kHz 波形

• 双生成模式：interleaved（文本/音频 token 交错，实时对话用）与 sequential（ASR/TTS 用）
• License：LFM Open License v1.0；编码器代码源自 NVIDIA NeMo (Apache 2.0)
• 部署难点全在"四件套"上：任何运行时想跑通 speech-to-speech，必须同时承载 4 个异构子网络 + 交错采样循环。只支持"标准 LLM"的运行时（Ollama、MLC、born 现状）都只能吃下中间的 LM 骨干。

来源：HF 模型卡

1. WebGPU 部署需要什么格式？→ ONNX 多图拆分（官方已备好）

1.1 直接答案

格式 = ONNX（5 个独立计算图 + 外置权重）+ onnxruntime-web (WebGPU EP)。不是 GGUF，不是 safetensors。

官方仓库 LiquidAI/LFM2.5-Audio-1.5B-ONNX（亲验文件树）：

外加 embed_tokens.bin/json（文本嵌入直查表）、mel_config.json（mel 前端配置）、tokenizer.json。量化档位：fp32 / fp16 / q4 / q8。

1.2 关键约束

• 浏览器只能用 q4 或 fp16——官方明言 q8 为 server-only（CPU/GPU），WebGPU EP 不支持（Liquid ONNX 部署文档）
• q4 全链路权重合计约 1.7 GB，浏览器 4GB WASM/VRAM 上限之内；首次加载后用 Cache API/IndexedDB 缓存
• 需 Chrome/Edge 113+，WebGPU 开启

1.3 现成方案（不必自己造）

• 官方浏览器 demo：Liquid4All/cookbook → examples/audio-webgpu-demo，Vite + ONNX Runtime Web，三模式（ASR / TTS / Interleaved 对话），npm install && npm run dev 即起，HF Spaces 有已部署实例
• 导出工具：Liquid4All/onnx-export（LiquidONNX），lfm2-audio-export 一条命令出全套精度
• transformers.js 已支持 LFM2 文本架构（device:"webgpu", dtype:"q4"），但 audio 版不走 transformers.js pipeline——官方 demo 用原生 onnxruntime-web 手工编排 5 图数据流

1.4 可行性评级：需胶水代码，但胶水官方写好了

自己要做的只是改 UI/业务层。唯一遗憾：demo 的 Interleaved 模式是"整段生成后播放"，真流式（逐帧出声）列在官方 Further Improvements，要自己在 JS 侧实现逐帧 detokenize + AudioWorklet 播放。

2. 用 born 怎么部署？需要写新算子么？→ 要，至少 6 类（本地源码审计结论）

2.1 born 是什么（勘误）

born-ml/born 不是 Rust Burn 的 fork，是纯 Go、零 CGO 的独立 ML 框架（v0.9.18，Apache 2.0），卖点"单二进制训练+部署"。注意：其"WebGPU 后端"是native wgpu（Dawn/Vulkan）桌面路径，非浏览器；WASM 仅有 CI 构建检查，浏览器推理未成熟。

2.2 born 现有家底（clone 后逐目录审计）

2.3 必须新写的算子/模块清单

1. Causal depthwise Conv1D（门控短卷积） —— LFM2 骨干 16 层中 10 层是 gated short-conv（kernel=63），头号缺口，CPU+WebGPU 双后端都要写（其余 6 层 GQA 可复用 born 现有 nn.GQA）
2. STFT/iSTFT + mel filterbank —— born 全无 FFT 设施，音频前端与 vocoder 输出都卡在这，得从零写或引纯 Go FFT
3. FastConformer 编码器：depthwise separable Conv1D + 下采样（Conv2D 可复用）+ 相对位置注意力
4. RQ/depth-transformer 交错生成器：8 codebook 逐深度采样 + audio top-k，generate 包需全新 InterleavedGenerator
5. Mimi 兼容 detokenizer：SEANet 式解码器，核心是 ConvTranspose1d（转置卷积）+ 流式卷积状态管理
6. GGUF/权重装载：LFM2 架构 tensor 命名映射 + 四件套多文件装载（born 的 llama loader 是单文件单架构）

2.4 工程量与务实建议

参照物：llama.cpp 那边官方塞了 53 个 commit、+4122 行 C++（PR #18641）才跑通，还不含 ggml 已有的 conv/FFT 基建。移植到 born ≈ 同量级 Go 代码 + 补 FFT 库 + WGSL shader。

判词：作为给 born 社区的开源贡献（它连 lfm2 文本架构都还没有）是好题目；作为"部署手段"不划算。若目标只是"Go 程序里用上它"：

• 最快：Go exec 官方预编译 runner（见 §3），stdin/stdout 或 HTTP 对接
• 次快：Go 调 ONNX Runtime（onnxruntime_go 需 CGO，与 born 零 CGO 哲学冲突，但与 born 无关时无妨）

3. GGUF 支持如何？→ 官方一等公民，但活在 llama.cpp 的"定制 fork"里

3.1 官方 GGUF 仓库

LiquidAI/LFM2.5-Audio-1.5B-GGUF：4 组件 × 3 量化档 = 12 个 GGUF —— LM 主干 + mmproj（音频编码器）+ vocoder（detokenizer）+ tokenizer，并附各平台预编译二进制 runner。这是"llama.cpp compatible GGUFs"宣称的实体。

3.2 llama.cpp 主线状态（亲验 PR）

• PR #18641：[Do Not Merge] model : LFM2.5-Audio-1.5B，Draft，53 commits，+4122 行，作者 tdakhran（Liquid 工程师）
• 该 PR 提供完整功能实现（新二进制 llama-liquid-audio-cli / llama-liquid-audio-server，vocoder GGUF 经 -mv 加载），策略是拆小块逐步合入主线：#18607 n_embd_out、#18601 llama_memory_hybrid_iswa、#18645 mtmd_audio_streaming_istft（流式音频输出基建）、#19687 audio tokenizer；llama-server 语音输出 API 交由 ngxson，TBD
• 音频输入（ASR） 走 mtmd 机制较近主线；音频输出/speech-to-speech 目前只在定制 build 可用

3.3 判词

GGUF 路线是 今天本地跑通 s2s 全链路的最短路径（下载预编译 runner 即可，全程无 Python），但你锁定在 Liquid 维护的 fork 上；等拆分 PR 全部合入，才谈得上"标准 llama.cpp 支持"。社区实测帖（r/LocalLLaMA）暂缺，成熟度自证有限。

4. Ollama 可用么？→ 语音：不可用。文本：勉强。

替代排序：① 官方预编译 llama-liquid-audio-server（最接近 Ollama 体验的本地 HTTP 服务）→ ② LM Studio（仅文本+外接 TTS）→ ③ LEAP SDK（官方移动/边缘音频路径，Mac/Android/iOS Voice Assistant 样例在 cookbook）。

5. 流式 voice-to-voice：机理与各路线保真度

5.1 机理（源码级证实）

• 块级交错：interleaved 生成按"n 个文本 token → n 个音频帧"循环交错；音频每步 8 个 codebook 一步全出（depthformer/RQ 深度方向一次采样 8 头），不是逐 codebook 8 步
• 帧率：Mimi 兼容 12.5 Hz，每帧 = 80ms 波形；detokenizer 是因果 LFM 小骨干 + iSTFT，可逐帧解码——这是低首包延迟的结构基础
• 延迟基线：LFM2-Audio 官方宣称端到端 <100ms（4s 音频输入→首声，硬件未注明）；LFM2.5 版 detokenizer 经 INT4 QAT 后移动端 CPU 提速 8×。对比：Moshi 全双工 ~200ms 实测、Qwen2.5-Omni 首包 ~640ms+
• 骨干结构（arXiv 2511.23404）：1.2B 级 16 层 = 10 层 gated causal depthwise short-conv (kernel=63) + 6 层 GQA——conv 层无 KV cache、状态仅 63 步滑窗，CPU/边缘缓存极友好，这正是它敢做实时对话的底气

5.2 各路线保真度

• Python 参考实现（liquid-audio 包）：generate_interleaved 逐 token/帧 yield → 黄金标准
• GGUF/定制 llama.cpp：需 -mm（mmproj）+-mv（vocoder）+ speaker 全套挂齐；#18645 专做流式 iSTFT 输出 → 保真度高；若只挂主干不挂 vocoder，退化为 ASR/文本
• WebGPU/ONNX demo：当前"整段生成再播放"，真流式要自己做 KV cache 续跑 + conv 状态保持 + 逐帧 detokenize + AudioWorklet 播放 → 保真度中
• Ollama：无音频输出，无从谈起
• born：全部从零，流式取决于你自己写的交错生成循环

6. 拍板：部署决策树

你的目标是什么？
├─ 本地机器最快跑通 s2s 对话 → 官方 GGUF + 预编译 llama-liquid-audio runner（§3）
├─ 浏览器/前端产品，零安装   → ONNX q4 五图 + onnxruntime-web，clone cookbook demo 改（§1）
├─ 想要 Ollama 一条命令      → 死心；退而 llama-liquid-audio-server，或只拉文本版 lfm2.5-1.2b（§4）
├─ 手机/嵌入式               → LEAP SDK（官方 edge 路径）
└─ 用 born / 纯 Go           → 需新写 Conv1D/FFT/ConvTranspose/交错采样器等 6 类模块，
                               定位为开源贡献而非部署捷径；急用请 exec 官方 runner（§2）

三句话总结：

1. WebGPU 要 ONNX 不要 GGUF——官方五图 q4 方案连 demo 都写好了，浏览器只吃 q4/fp16。
2. GGUF 是全链路最短路径，但"llama.cpp 兼容"暂时 = "Liquid 定制 fork 兼容"，主线合入按 #18645 等拆分 PR 进度走。
3. Ollama 与 born 在语音上是同一种"不行"——运行时只认标准 LLM，四件套里另外三件无处安放；born 想跑须补齐音频算子矩阵，等价于把 4122 行 C++ 的活儿用 Go 再干一遍。

附：信源清单

• HF 模型卡 / GGUF / ONNX 仓库：LiquidAI/LFM2.5-Audio-1.5B{,-GGUF,-ONNX}（文件树亲验）
• llama.cpp PR：#18641（Draft 主实现）、#18601 / #18607 / #18645 / #19687（拆分合入）
• Liquid 官方文档：docs.liquid.ai（ONNX 部署页、audio-webgpu-demo 页）
• Liquid4All/cookbook（浏览器/桌面/移动全家桶样例）、Liquid4All/onnx-export（LiquidONNX）
• born-ml/born v0.9.18 源码本地审计（tensor/nn/models/loader/internal/backend/webgpu 逐目录）
• Ollama library 与 ollama/ollama issues（音频模态支持现状）

#LLM #Voice2Voice #智柴