LFM2.5 QAD：4-bit 量化感知蒸馏恢复 97% BF16 质量 · 干货攻略
- 链接:https://x.com/maximelabonne/status/2090498250168058081
- 分类:x-tips
- 来源:X @maximelabonne
- 作者:Jay
- 更新:2026-08-22
- 仓库:LiquidAI/LFM2.5-2.6B-GGUF
这是什么
LFM2.5 QAD（Quantization-Aware Distillation）是 Liquid AI 发布的一种训练时量化蒸馏技术，原理是让一个高精度 teacher 模型直接蒸馏到一个量化后的 student 模型，而非先训练好再事后量化（PTQ，Post-Training Quantization）。
4 个 LFM2.5 尺寸均发布 QAD Q4_0 量化版本：
| 模型 | QAD Q4_0 恢复率 | 相对 PTQ Q4_0 提升 |
|---|---|---|
| LFM2.5-230M | 97.1% BF16 | 回收 70.6% 的质量差距 |
| LFM2.5-350M | 96.5% BF16 | 回收 73.4% 的质量差距 |
| LFM2.5-1.2B-Instruct | 97.4% BF16 | 回收 65.5% 的质量差距 |
| LFM2.5-2.6B | 96.6% BF16 | 回收 48.4% 的质量差距 |
💡 核心价值：QAD Q4_0 使用和普通 Q4_0 完全相同的 GGUF 格式和运行路径，不需要任何自定义算子或特殊 runtime，直接用 llama.cpp 即可；同时质量逼近更高精度的 Q5_K_M 或 Q4_K_M。
为什么值得关注
@maximelabonne（Maxime Labonne，Liquid AI Head of Post-Training）分享了什么
Maxime Labonne 在 X 上宣布了 LFM2.5 QAD checkpoint 发布，核心信息是：
- 同一个 Q4_0 文件，同时解决两个问题：内存占用和吞吐量继承 Q4_0 的优势，质量回收率接近 97% BF16——这是 PTQ Q4_0 做不到的。
- QAD Q4_0 对小模型效果最显著：LFM2.5-230M 回收了 70.6% 的量化损失（QAD closes 70.6% of the gap），小模型原来受 PTQ 伤害最深，QAD 救回最多。
- 无需换 runtime：最终 artifact 就是标准 Q4_0 GGUF，llama.cpp、LM Studio、Ollama（需注意 template 问题）均可直接加载。
解决了什么问题
本地/边缘部署 LLM 有两个核心矛盾：
- 精度 vs 体积：Q4_0 压缩率高，但 PTQ 量化后小模型质量损失可达 3-5%；Q5_K_M 质量好，但速度更慢、文件更大。
- 质量 vs 速度：小型 Transformer/LFM 模型用 PTQ Q4_0 质量尚可，但同等尺寸的非 Transformer 架构（如 LFM 线性状态空间模型）因为每参数量化噪声更集中在关键权重上，PTQ 伤害更大。
QAD 通过在蒸馏阶段就把量化噪声注入训练信号，让模型在"被量化"的环境中学会鲁棒，最终产出一个既是 Q4_0 体积、又有接近 BF16 质量的 artifact。
核验过程
官方来源
- Liquid AI 官方博客（liquid.ai/blog/qad）：QAD 技术说明、4 个模型的恢复率数字、 benchmark 方法（GPQA Diamond / MMLU-Pro / IFEval / IFBench / Multi-IF / BFCLv4 + GSM8K/AIME25）、4 平台实测吞吐对比（MacBook Pro M5 Max / NucBox AMD / Galaxy S26 Ultra / Raspberry Pi 5）。
- HuggingFace 官方博客（huggingface.co/blog/LiquidAI/qad）：确认 QAD Q4_0 文件名（
LFM2.5-2.6B-QAD-Q4_0.gguf）、下载命令、benchmark 方法与博客一致。 - HuggingFace 模型卡（LiquidAI/LFM2.5-2.6B-GGUF）：确认 QAD checkpoint 与 PTQ checkpoint 的区别（文件名不同，均为 Q4_0 格式），以及
llama-cli示例命令。
交叉验证结论
| 说法 | 来源 | 验证结果 |
|---|---|---|
| LFM2.5-2.6B QAD Q4_0 保留 96.6% BF16 质量 | Liquid AI 博客 + HF 博客 | ✅ 双方一致 |
| LFM2.5-230M/350M/1.2B QAD Q4_0 分别保留 97.1%/96.5%/97.4% | Liquid AI 博客 + HF 博客 | ✅ 双方一致 |
| QAD 回收 70.6%/73.4%/65.5%/48.4% 的 BF16→PTQ Q4_0 质量差距 | Liquid AI 博客 + HF 博客 | ✅ 双方一致 |
| 230M/350M QAD Q4_0 达到 Q5_K_M 质量（variance 内） | Liquid AI 博客 | ✅ 确认 |
| 1.2B/2.6B QAD Q4_0 达到 Q4_K_M 质量，吞吐高 3-14% | Liquid AI 博客 | ✅ 确认 |
| QAD Q4_0 吞吐与普通 Q4_0 完全相同（格式/算子一致） | Liquid AI 博客 | ✅ 确认 |
| X 帖 "5.4GB→1.6GB / 21→64 tok/s / 3.0s→1.2s"（F16→QAD Q4_0, LFM2.5-2.6B） | X @maximelabonne / @justinli9527 转述 | ⚠️ 原帖为 X 转述，官方博客/文档未直接列出此组精确数字；该说法与官方整体结论一致（LFM2.5-2.6B Q4_0 确实在 1.6GB 量级，质量回收显著），但具体吞吐数字无法从官方来源逐一核验 |
⚠️ 待核验数字处理：X 帖流传的 "21→64 tok/s" 和 "3.0s→1.2s" 为社区转述，官方博客仅提供跨平台吞吐对比图（非精确数字），官方未单独列出 LFM2.5-2.6B 的 F16 vs QAD Q4_0 精确对比。上述数字方向正确（量化后体积↓速度↑质量回收率高），但具体数值以官方 benchmark 图表为准。
上手步骤
步骤 1：下载 QAD Q4_0 GGUF 文件
所有 QAD checkpoint 在 Hugging Face 的对应模型仓库中，与原 PTQ Q4_0 文件并列，文件名带有 -QAD- 后缀：
| 模型 | 下载链接 |
|---|---|
| LFM2.5-230M | LiquidAI/LFM2.5-230M-GGUF（找 *-QAD-Q4_0.gguf） |
| LFM2.5-350M | LiquidAI/LFM2.5-350M-GGUF（找 *-QAD-Q4_0.gguf） |
| LFM2.5-1.2B-Instruct | LiquidAI/LFM2.5-1.2B-Instruct-GGUF（找 *-QAD-Q4_0.gguf） |
| LFM2.5-2.6B | LiquidAI/LFM2.5-2.6B-GGUF（找 LFM2.5-2.6B-QAD-Q4_0.gguf） |
步骤 2：命令行运行（llama.cpp）
# 直接从 HuggingFace 拉取并运行 LFM2.5-2.6B QAD Q4_0
llama-cli -hf LiquidAI/LFM2.5-2.6B-GGUF \
-hf-file LFM2.5-2.6B-QAD-Q4_0.gguf \
-c 4096 -i \
--temp 0.1 --top-k 50 --repeat-penalty 1.1 \
-p "What is C. elegans?"
# 若已下载 gguf 文件到本地
llama-cli -m ./LFM2.5-2.6B-QAD-Q4_0.gguf \
-c 4096 -i \
--temp 0.1 --top-k 50 --repeat-penalty 1.1
步骤 3：长上下文配置（Agent 场景推荐 32K-128K）
# 启用长上下文 + KV cache 量化（省显存）
llama-cli -m LFM2.5-2.6B-QAD-Q4_0.gguf \
-c 131072 \
--cache-type-k q8_0 \
--cache-type-v q8_0 \
--temp 0.1 --top-k 50
注意：LFM2.5 原生上下文 128K，Q4_0 格式下单张消费级显卡可轻松容纳 32K-128K 上下文。
步骤 4：验证是否加载了 QAD 版本（非 PTQ）
QAD checkpoint 和 PTQ checkpoint 文件体积几乎相同（均为标准 Q4_0），区分方式是文件名：
# ✅ QAD 版本（推荐）
LFM2.5-2.6B-QAD-Q4_0.gguf
# ❌ 普通 PTQ 版本（质量略低）
LFM2.5-2.6B-Q4_0.gguf
运行时可查看前几行 log，确认加载的是哪个文件。
步骤 5：在 LM Studio / Ollama 中使用
LM Studio：直接拖入 GGUF 文件，或在模型搜索中搜索 LFM2.5-2.6B，下载时确认文件名含 QAD。
Ollama（注意 template 兼容性）：
# Ollama 的 chat template 可能与 LFM2.5 不兼容
# 如遇问题，建议使用 llama-server --jinja 代替
llama-server --jinja \
-m LFM2.5-2.6B-QAD-Q4_0.gguf \
-c 32768
坑与适用边界
坑 1：QAD 对 2.6B 模型的回收率最低（48.4%）
QAD 对小模型（230M/350M）回收率最高（>70%），对 2.6B 回收率仅 48.4%——意味着在最大模型上，QAD Q4_0 相比 PTQ Q4_0 的质量优势相对较小，但仍明显优于纯 PTQ。如果对 2.6B 质量极为敏感，建议评估 BF16 版本的性价比。
坑 2：llama.cpp 的 Q4_0 吞吐是 QAD 和 PTQ 的共同天花板
QAD 并不改变 Q4_0 的计算路径，所以吞吐和原生 Q4_0 完全一致。如果追求更高速度，需要选择更小的量化位宽（如 Q3_K_M），而 QAD 的价值在于"用 Q4_0 的速度提供接近 BF16 的质量"，而非突破 Q4_0 的速度极限。
坑 3：benchmark 中的"97%"是跨任务平均，非单一任务
官方在 GPQA Diamond / MMLU-Pro / IFEval / IFBench / Multi-IF / BFCLv4 + math (GSM8K/AIME25) 共 7 个任务上取平均。实际使用时，特定任务（如数学推理 AIME25）可能比平均值偏差更大。
坑 4：Ollama template 兼容性问题
Maxime Labonne 在本地运行中发现 Ollama 会替换 chat template，导致部分参数失效。如果遇到模型输出异常，优先使用 llama-server --jinja 或 LM Studio，而非 Ollama。
适用边界
- 最适合场景：树莓派、手机、MacBook Air 等内存/算力受限的边缘设备；需要本地 Agent（Tool Use / Function Calling）能力且对质量有要求；不希望部署 BF16 大文件的用户。
- 不适用场景：追求极致 benchmark 分数（建议用 BF16 或更大模型）；对特定数学/代码任务有极高要求（2.6B 毕竟只有 2.6B）。
- 与 PTQ Q4_0 的选择：两者体积几乎相同，如果有 QAD 版本可选，优先选 QAD——同体积同速度，质量更好。
一句话结论
LFM2.5 QAD 通过训练时量化蒸馏，让标准 Q4_0 GGUF 文件恢复至 ~97% BF16 质量（同体积同速度），小模型回收率最高；在 llama.cpp 下可直接替换 PTQ Q4_0 使用，对边缘部署而言这是目前性价比最高的 4-bit 方案之一。
数据来源：Liquid AI 官方博客 liquid.ai/blog/qad + HuggingFace 官方博客 huggingface.co/blog/LiquidAI/qad；X 帖中 "21→64 tok/s / 3.0s→1.2s" 为社区转述，具体数字未经官方逐一确认，方向正确但精确值需以实际本地 benchmark 为准。