LFM2.5 再压一档，4bit 部署更便宜

Liquid AI 近日在 Hugging Face 发布了基于量化感知蒸馏（Quantization-Aware Distillation，QAD）训练的 LFM2.5 Q4_0 检查点。它解决的不是“模型能不能量化”这个老问题，而是让模型从训练阶段就适应 4bit 权重，减少量化后常见的能力损失，进一步降低本地部署对内存、带宽和芯片算力的要求。

这批检查点面向 llama.cpp 等支持 GGUF 的推理工具，核心目标很明确：让 LFM2.5 这类小模型在 CPU、NPU 和移动端设备上更容易跑起来。对需要在个人电脑、手机、边缘网关或嵌入式设备中部署模型的开发者来说，Q4_0 的价值不在于又多了一个文件后缀，而在于它把“模型质量”和“低比特部署”之间的折损进一步压低了。

先说结论：这不是一次普通的模型量化

量化是把模型权重从高精度数值映射到更低比特数值的压缩技术。 例如，FP16 通常用 16 bit 表示一个权重，而 Q4_0 使用 4 bit 表示权重，并通过额外的缩放参数恢复数值范围。

量化感知蒸馏是让低精度学生模型在训练过程中直接面对量化误差，并学习高精度教师模型输出行为的方法。 它与发布后再执行的“训练完成后量化”不同：后者通常先训练好一个 BF16 或 FP16 模型，再用校准数据把权重压缩到 INT4；QAD 则把低比特表示引入训练或蒸馏环节，让学生模型学会在受限精度下完成同样的任务。

这一区别很重要。模型里的权重并不是平均分布的普通数字，注意力层、MLP 层和输出头对误差的敏感度也不一样。把 16 bit 权重简单压到 4 bit，有些层会产生更明显的误差，最终表现为指令遵循变差、格式输出不稳定、数学推理退化，或者工具调用时参数更容易出错。

传统后训练量化（PTQ）更像是给一辆已经调校好的车换上低滚阻轮胎：成本低、速度快，但车辆原本的悬挂和动力系统并没有为新轮胎重新适配。QAD 则是在调校阶段就让车辆反复使用这套轮胎，训练出的模型通常更适合目标部署精度。

Q4_0 到底意味着什么

GGUF 是面向本地大模型推理的模型文件格式，通常用于 llama.cpp 及其兼容工具。 Q4_0 是 GGUF 中常见的 4bit 量化方案之一，通常以 32 个权重为一个分组，为每组保存一个缩放因子，再用 4bit 数值表示组内权重。

Q4_0 的优点是实现成熟、兼容性广、内存占用低，缺点是它并非精度最高的 4bit 方案。不同量化格式会在权重分组方式、缩放参数和误差分配策略上有所区别，因此 Q4_0、Q4_K_M、INT4、AWQ 或 GPTQ 并不能简单视为同一种东西。

从部署角度看，Q4_0 的收益主要有三层：

• 模型文件更小。 权重从 FP16 压缩到 4bit 后，理论权重存储约降为四分之一，实际还要计入缩放参数、词表、运行时缓存和上下文所需的 KV cache。
• 内存带宽压力更低。 自回归解码时，推理速度很大程度受限于不断读取模型权重。权重变小后，CPU 或 NPU 每次搬运的数据量减少。
• 本地设备门槛更低。 小模型可以进入普通笔记本、手机和边缘设备的内存预算，不必为一个轻量级分类、抽取或工具调用任务单独准备高端 GPU。

但“4bit 等于占用四分之一内存”只是理想化估算。实际运行还需要保存中间激活、KV cache、运行时工作区以及部分未量化参数。上下文越长，KV cache 占用越明显，因此一个在短上下文测试中只占几百 MB 的模型，放进长上下文 Agent 后，整体内存仍可能快速上涨。

Liquid AI 为什么要用蒸馏做 Q4_0

知识蒸馏是让一个较小或受约束的学生模型，模仿更强教师模型输出分布和行为的训练方法。 在这次方案中，Liquid AI 的思路不是只盯着权重误差，而是让量化后的 LFM2.5 学习高精度模型在真实输入上的判断方式。

一个普通的量化流程关注的是“每个权重被压缩后离原值有多远”。但对生成模型来说，单个权重偏差并不一定直接造成输出错误，真正影响用户体验的是最终 logits、下一个 token 的排序、结构化输出格式和多轮对话行为。蒸馏可以把优化目标从局部数值误差拉回到模型行为层面。

可以把两种方法放在一起看：

| 方案 | 训练阶段是否感知低比特 | 主要优化对象 | 优点 | 主要风险 | | --- | --- | --- | --- | --- | | 后训练量化 PTQ | 否 | 权重数值误差 | 流程快、成本低、适配现有模型方便 | 低比特下可能出现能力损失 | | 量化感知训练 QAT | 是 | 任务损失与量化后的模型行为 | 对目标精度适应更好 | 需要重新训练或继续训练 | | 量化感知蒸馏 QAD | 是 | 低比特学生模型对高精度教师模型的行为拟合 | 适合在小模型上保留指令遵循和推理能力 | 依赖教师质量、蒸馏数据和训练配方 |

Liquid AI 公开的 QAD 方案可以理解为“QAT 加上教师示范”。模型在低精度约束下训练，同时利用高精度教师提供的行为信号。这样做尤其适合 LFM2.5 这类参数量不大的模型：模型本身已经在追求边缘部署，量化带来的相对误差更容易成为最终效果的主要瓶颈。

需要强调的是，QAD 并不会让 4bit 模型凭空获得高于原始模型的能力。它更现实的作用是降低量化造成的退化，让开发者在更低内存预算下尽量接近原始检查点的使用体验。对于部署成本敏感的场景，这种收益往往比跑分榜上的小幅变化更有价值。

实测数据：1.2B 模型已经可以在普通设备上高速解码

Liquid AI 已公布的 LFM2.5-1.2B-Thinking 测试数据显示，Q4_0 版本在 AMD Ryzen AI 9 HX 370 的 CPU 上使用 llama.cpp 推理时，预填充速度达到 2975 tok/s，解码速度达到 116 tok/s，内存占用约 856MB。

这里的两个速度指标需要区分。预填充（prefill）是模型一次性处理已有输入上下文的阶段，解码（decode）是模型逐 token 生成回答的阶段。 对聊天和 Agent 应用而言，用户更直接感知的是解码速度；116 tok/s 已经足以让短回答几乎即时出现。预填充速度则更能说明 CPU 在处理长提示词时的吞吐能力。

同一系列模型在不同硬件和推理后端上的数据如下：

| 设备与后端 | 模型 | 精度或格式 | 预填充速度 | 解码速度 | 内存占用 | | --- | --- | --- | ---: | ---: | ---: | | AMD Ryzen AI 9 HX 370 CPU + llama.cpp | LFM2.5-1.2B-Thinking | Q4_0 | 2975 tok/s | 116 tok/s | 856MB | | AMD Ryzen AI 395+ NPU + FastFlowLM | LFM2.5-1.2B-Thinking | 原生低精度部署路径 | 1487 tok/s | 60 tok/s | 1600MB（完整上下文） | | AMD Ryzen AI 9 HX 370 NPU + FastFlowLM | LFM2.5-1.2B-Thinking | 原生低精度部署路径 | 1487 tok/s | 57 tok/s | 1600MB（完整上下文） | | Snapdragon X Elite NPU + NexaML | LFM2.5-1.2B-Thinking | NPU 优化路径 | 2591 tok/s | 63 tok/s | 约 0.9GB |

这组数据说明一个容易被忽视的事实：小模型的本地体验不只取决于有没有 NPU，也取决于推理框架对量化格式的支持。 在给出的测试中，Ryzen AI 9 HX 370 使用 CPU 和 llama.cpp 跑 Q4_0，解码速度反而达到 116 tok/s，高于两个 NPU 测试路径的 57 tok/s 和 60 tok/s。

这不代表 CPU 永远比 NPU 快。不同后端的算子融合、内存布局、线程数、上下文长度和测试环境都会改变结果。它至少说明，对 1.2B 规模模型来说，成熟的 Q4_0 + llama.cpp 组合已经足够有竞争力，开发者没有必要把所有问题都寄托在专用 NPU 上。

和 Qwen3-1.7B 比，LFM2.5 的优势在哪里

LFM2.5-1.2B-Thinking 是 Liquid AI 面向推理任务的小型开放权重模型，参数量约为 12 亿。 在 Liquid AI 公布的对比数据中，它与 Qwen3-1.7B thinking mode 处在相近的轻量级竞争区间，但两者优势不同。

| 模型 | 参数规模 | GPQA Diamond | MMLU-Pro | IFEval | IFBench | Multi-IF | GSM8K | MATH-500 | AIME25 | BFCLv3 | | --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: | | LFM2.5-1.2B-Thinking | 1.2B | 37.86 | 49.65 | 88.42 | 44.85 | 69.33 | 85.60 | 87.96 | 31.73 | 56.97 | | Qwen3-1.7B（thinking mode） | 1.7B | 36.93 | 56.68 | 71.65 | 25.88 | 60.33 | 85.60 | 81.92 | 36.27 | 55.41 |

从这些指标看，LFM2.5-1.2B-Thinking 在 IFEval、IFBench、Multi-IF、MATH-500 和 BFCLv3 上更占优势，尤其是 IFEval 达到 88.42%，明显高于 Qwen3-1.7B 的 71.65%。这意味着它更擅长按照明确格式和多重约束完成任务，也更适合数据抽取、结构化输出和工具调用等工作流。

Qwen3-1.7B 在 MMLU-Pro 和 AIME25 上领先，说明它在部分知识密集型和高难度竞赛数学任务上更强。两者不是简单的代际替代关系：如果任务是复杂知识问答或冲击更高难度数学题，Qwen3 可能更合适；如果任务是本地运行、严格遵循格式、快速做工具路由，LFM2.5 的参数效率和 Q4_0 部署形态更有吸引力。

还要注意，这些分数来自不同测试设置，不能直接等同于所有真实场景的效果。尤其是 Thinking 模型的推理长度、停止条件和评测提示词都会影响结果。实际选型时，应该用自己的提示词、上下文长度和工具协议做回归测试。

对开发者最有用的三个场景

第一类场景是本地 Agent 的意图识别和工具路由。 一个 Agent 不一定需要把所有任务都交给几十亿甚至数百亿参数的模型。用户输入“查一下订单，再把结果整理成表格”，本地 1.2B 级模型可以先负责意图分类、参数抽取和工具选择，复杂推理再升级到云端大模型。Q4_0 把这类常驻进程的内存门槛压到 1GB 左右，普通办公电脑也更容易长期运行。

第二类场景是结构化数据抽取。 发票、工单、日志和商品信息往往不需要开放式创作，而需要从文本中找出字段并输出固定 JSON。IFEval 和 Multi-IF 的表现对这类任务有参考价值，但开发者仍应验证异常输入、缺失字段和长文本截断等边界情况。模型足够小，也意味着可以在数据不离开内网的情况下处理敏感内容。

第三类场景是端侧交互。 Liquid AI 此前强调 LFM2.5-230M 可以运行在低成本 CPU 上，在 Galaxy S25 Ultra 上达到 213 tok/s，在 Raspberry Pi 5 上达到 42 tok/s。1.2B 级模型的 Q4_0 检查点则适合对质量要求更高、设备资源相对充足的端侧任务，例如离线问答、设备控制和个人知识库检索后的答案整理。

不过，端侧部署不能只看模型文件大小。手机和嵌入式设备通常更关注峰值功耗、持续运行温度、首 token 延迟和应用包体积。一次短暂的跑分并不等于连续对话半小时后的体验。开发者需要实际测量从加载模型到首 token 的时间，以及不同上下文长度下的内存曲线。

这次发布的边界也很清楚

Q4_0 并不是所有任务的最佳选择。4bit 权重会降低模型精度，虽然 QAD 的目标就是控制这种损失，但它不能消除低精度计算的全部影响。需要高可靠代码生成、复杂数学证明、长上下文检索或多语言高质量写作时，仍应对比 BF16、FP16 或更高质量的量化方案。

另外，模型权重压缩后，KV cache 并不会自动按相同比例下降。长上下文应用如果把 32K、64K 甚至更长的历史全部塞进提示词，最终内存瓶颈可能来自缓存，而不是模型权重。Q4_0 能解决的是“加载模型太占内存”和“解码带宽不足”，不能替代上下文裁剪、摘要、分层记忆等工程优化。

框架兼容性也是一个现实问题。官方资料给出的路径包括原生模型、GGUF 和 ONNX 等不同格式，分别对应 Transformers/vLLM、llama.cpp 以及 ONNX Runtime 等生态。Q4_0 检查点主要适用于支持该格式的本地推理工具；如果目标设备依赖特定 NPU SDK，仍需确认算子、权重布局和运行时是否真正支持，而不是看到“INT4”就认为可以直接加速。

OpenAI Hub 判断

这次发布的真正价值，是把低比特部署从“模型发布后的压缩步骤”推进成“模型训练目标的一部分”。对于参数规模在 1B 左右的小模型，量化带来的资源收益很容易转化为实际产品收益：更少的内存、更低的带宽压力、更低的设备成本，以及更大的并发空间。

Liquid AI 没有靠单纯堆参数来竞争，而是在模型架构、蒸馏、量化和硬件适配之间做组合优化。LFM2.5-1.2B-Thinking 在部分知识和竞赛数学指标上不一定胜过更大的模型，但它在指令遵循、工具调用和本地吞吐上的平衡，确实更贴近端侧 Agent 的实际需求。

对开发者而言，Q4_0 检查点值得优先尝试，但建议把它当作一个部署基线，而不是最终答案。可以先用 Q4_0 验证功能闭环，再根据业务数据比较 BF16、Q4_0 和其他量化格式的准确率、首 token 延迟、持续吞吐和内存占用。若一个 1.2B 模型在你的工作流中已经够用，那么把它放在本地做第一层处理，往往比所有请求都发送给大型云端模型更经济，也更容易满足隐私和离线要求。

截至 2026 年 8 月 19 日，LFM2.5 Q4_0 的看点并不是“4bit 终于能用了”，而是量化感知蒸馏正在让 4bit 模型更像一个经过专门训练的产品版本，而不是高精度模型的临时压缩件。这条路线能否在更大模型和更多硬件上复制，仍要看后续检查点、跨设备测试和真实业务评测；但在轻量级本地推理领域，它已经是一个值得关注的工程方向。

参考来源

• Liquid AI：LFM2.5 Q4_0 Checkpoints from Quantization-Aware Distillation：本次 Q4_0 检查点与量化感知蒸馏方案的官方说明。
• LiquidAI/LFM2.5-1.2B-Thinking：模型卡、评测数据、推理框架和硬件性能信息。