Liquid AI 在 Hugging Face 上放出 LFM2.5 系列的一批新检查点，格式是 GGUF Q4_0，训练方法叫 QAD（quantization-aware distillation，量化感知蒸馏）。四个尺寸（230M、350M、1.2B-Instruct、2.6B）在评测上分别恢复了各自 BF16 基线 97.1%、96.5%、97.4% 和 96.6% 的成绩。
对不玩本地推理的人来说，这行字没什么冲击力。要看懂它，得先知道 Q4_0 在 llama.cpp 生态里是个什么地位。
一个被社区放弃的格式
Q4_0 是最早那批四比特量化方案，规则简单粗暴：每 32 个权重一组，共用一个缩放系数，剩下的直接压成 4 比特整数。后来社区做出了 K-quant 系列（Q4_K_M、Q5_K_M 这些），按张量重要性分配不同位宽，同样体积下精度明显更好，Q4_0 就基本退场了，只在一些老设备和老运行时里留着。
它有一个别人拿不走的好处：结构规整，能直接映射到 Arm CPU 的 int8 点积指令上。K-quant 的分块和查表在手机 CPU 上要多绕几道，Q4_0 不用。Liquid AI 这次给的速度数字就是冲着这一点来的——同一批模型，Q4_0 检查点比 Q5_K_M 快 4% 到 33%，比 Q4_K_M 快 3% 到 14%。
所以卡住 Q4_0 的一直是精度那一头。QAD 冲的就是这个。
把量化搬进训练
常规做法是 PTQ（后训练量化）：模型训完再压，压完看掉多少，掉太多就换个格式重来。QAD 的思路是让模型在训练阶段就知道自己将来要被压成什么样：高精度的教师模型往量化后的学生模型上蒸馏，量化约束参与训练，权重分布提前往四比特网格上靠。Liquid AI 在博客里的说法是 QAD substantially improves the Q4_0 checkpoint（QAD 大幅改善了 Q4_0 检查点）。
这不是新概念，量化感知训练在视觉模型上用了很多年。搬到语言模型上的麻烦在成本：每一种目标格式都要单独跑一轮训练。厂商愿意花这笔钱，说明它算过账。端侧模型的下载量和调用量，值得为一种格式单独训一次。
四台机器上的验证
测试覆盖两类硬件：MacBook Pro 和 NucBox EVO-X2 走 GPU 推理，三星 Galaxy S26 Ultra 和树莓派 5 走 Arm CPU 推理。树莓派 5 出现在名单上有点意思，它代表的是那类没有 GPU、内存也紧张的场景，Q4_0 的优势在这里最大。
粗算一下体积：2.6B 参数按四比特存，权重大约 1.4GB 出头，加上 KV cache 和运行时开销，一台 8GB 内存的手机装得下，还能腾出手干别的。230M 那个更是几百兆的量级，塞进一个 App 里当本地功能用完全现实。
这批检查点在赌什么
取舍的方向倒是新的。过去两年端侧推理的主流做法是把模型做小：蒸馏出更少的参数量，或者换更聪明的量化格式。Liquid AI 这次选了第三条路，格式不动、参数量不动，把优化压力全部转移到训练侧。
代价是它只对自家模型有效。社区没法拿这个方法去救别人放出来的 Q4_0 权重，那需要原始训练流程。这是模型厂商才能提供的东西，也是端侧小模型这条赛道上少数几个能拉开差距的地方——同样是 2.6B、同样跑在 llama.cpp 上，谁的四比特版本掉得少，谁就赢一局。
对开发者来说门槛没变：GGUF Q4_0 是最通用的格式，llama.cpp 和任何兼容 Q4_0 的运行时直接加载，不改代码，不加新算子。选它而不用自定义格式的原因也在这里，兼容性本身就是分发能力。
参考来源：Liquid AI 官方博客、CocoLoop、Hugging Face 模型页；四个尺寸的精度恢复比例与两组速度区间以官方公布口径核验。