Liquid AI在8月19日的官方博客里贴出一个漂亮数字:旗下LFM2.5系列四款边缘模型(230M、350M、1.2B-Instruct、2.6B)改用"量化感知蒸馏"(QAD)训练4-bit检查点后,能恢复约97%的BF16基准性能——听起来量化几乎白量了。但把这份博客里的另一组数据摆在一起看,故事没那么圆满:同一篇公告里,2.6B模型"实际弥合的量化损失缺口"只有48.4%,不到一半。两套算法算的是同一件事,说出来却是两种效果。
这不是文字游戏,而是量化评测里长期存在的口径分裂——一个衡量"离满分还差多少",一个衡量"从零分爬回来多少"。Liquid AI把前者写进了标题,后者留在数据表深处。对开发者来说,真正该问的是:这套号称能让手机、树莓派流畅跑大模型的新技术,到底解决了多少实际问题,又在哪里露了怯。
一个数字,两种算法
97.1%、96.5%、97.4%、96.6%,这是四款模型相对BF16全精度的平均准确率保留比例——分母是"满分",数字越接近100%,越像"量化几乎无损"。
但博客里还有一组更严格的指标:QAD相对PTQ Q4_0实际弥合的质量缺口。换算下来,四款模型分别是70.6%、73.4%、65.5%、48.4%。这个指标的分母不是"满分",而是"量化本来会丢掉多少分",算的是补救手段到底把丢掉的分数捡回来了多少。
一个模型两套成绩单,差距最大的恰恰是旗舰款2.6B——按第一套算法它拿了96.6%的高分,按第二套算法它只补回了不到一半的损失。
越大的模型,补得越少
四款模型的缺口弥合率放在一起看,趋势很扎眼:230M和350M这两款迷你模型补得最多,都在70%以上;参数量最大的2.6B反而垫底,只有48.4%。
这跟"参数越多、模型越强、量化损失越好补"的直觉正好相反。一种解释是大模型的知识分布更密集,4-bit压缩丢的信息本来就更"结构性",蒸馏这种事后补救天生够不着;另一种可能是教师模型和训练数据选择在起作用,而不是QAD方法论本身。目前只有Liquid AI一家的数据,两种解释谁对谁错,外部无从判断。
这也是这次发布最容易被忽略的一点:标题式的"97%"给人的印象是全系列表现一致优秀,实际上模型越接近实用规模,QAD交出的答卷反而越勉强。
谁来验证这97%
量化质量这件事,业内早有前车之鉴。此前有独立测试者对同一款LFM2.5-2.6B做过困惑度和KLD复测,发现Q6_K、Q8_0几乎无损,但多个渠道转出的Q4_K_M质量却天差地别——Liquid AI官方和另一家常见转换者mradermacher转出的Q4_K_M都表现"异常差",反倒是第三方bartowski转出的版本更好。结论只有一个:同一个量化等级、同一套权重,换个转换实现,质量能差出一大截。
这次QAD-Q4_0的所有benchmark——GPQA Diamond、MMLU-Pro、IFEval、BFCLv4——目前全部来自Liquid AI自己跑分,社区里的文件命名甚至常把它简单标成"Q4_0",跟传统PTQ版本混在一起,辨识都成问题。硬件吞吐量的对照也有类似错位:官方给出的是Galaxy S26 Ultra实测,而公开可查的对照数据(比如Unsloth在上一代S25 Ultra上跑Q4_0的吞吐和内存占用)来自不同代际的设备,直接拿来对齐并不严谨。这轮"更快更省"的结论,目前完全立在发布方自己的实验记录上。
自证的成绩单,经不起换个算法的追问
开发者该怎么选
对真正要落地的人,数字之外还有更朴素的参考:以1.2B-Instruct为例,官方GGUF里Q4_0体积约696MB,Q4_K_M约731MB,Q5_K_M约843MB——三者体积差距并不大,如果QAD-Q4_0真能在696MB下追平Q5_K_M的质量,对手机、树莓派这类内存紧张的场景确实划算。
- 建议.跑聊天、摘要这类对精度不敏感的任务,QAD-Q4_0的体积和速度优势值得直接换;涉及工具调用、结构化输出、代码生成的场景,先等独立评测跟进,尤其是2.6B这一档。
- 风险.目前没有非Liquid AI背景的团队公开复测过QAD-Q4_0的困惑度或真实任务表现,"97%恢复"暂时只是单方陈述。
边缘AI的量化竞赛正在从"谁的方法论听起来更先进"转向"谁的实测数据经得起别人重新跑一遍"。QAD是不是真解法,答案不在Liquid AI自己的博客里,而在下一份独立复测报告里。