这件事一年前还做不到。

过去这一年,所有头条都给了旗舰大模型:更长的上下文、更强的推理、更贵的订阅。但真正改变"AI 装在哪儿"这个问题的,是另一条没什么人盯着的线——几 B 参数的小模型,和把它们塞进手机、笔电、边缘盒子的工程。这条线今年悄悄拉满了。

我想把这件事讲清楚:小模型现在到底能做好哪些事,为什么端侧值得,量化和蒸馏在中间干了什么,以及——同样重要——它干不了什么。

先说清楚:小模型不是"大模型的劣化版"

很多人对小模型的印象停留在"便宜但是笨"。这个印象在 2024 年大致成立,现在不成立了。

关键的转变是:小模型不再靠"也学一点世界知识"来对标大模型,而是放弃了一部分知识广度,换取在窄任务上的密度。微软的 Phi 系列把这条路走得最直白——靠精心筛选的高质量训练数据,Phi-4 在 MATH 和 GPQA(研究生级科学题)这类基准上能压过体量大得多的模型。它不是"小一号的 GPT",它是另一种东西。

阿里的 Qwen3 把尺寸切得很细:0.6B、1.7B、4B、8B 一路排下来。官方技术报告里有个反直觉的数据——Qwen3 的 4B / 1.7B,在过半数基准上能打过上一代的 Qwen2.5-7B / 3B,尤其在 STEM 和代码题上。新一代的 4B,约等于老一代的 7B。 这就是过去一年小模型走过的距离。

谷歌的 Gemma 也在做同样的事。4 月发布的 Gemma 4,最小的 E2B / E4B 变体用了 Per-Layer Embeddings 这类结构技巧,4-bit 量化后 5GB 内存就能在现代手机上跑起来。

所以判断一个小模型,别再问"它知道的有没有大模型多"——它注定不多。要问的是:在我这个具体任务上,它够不够。

它现在能做好哪些任务

把场景摊开看,小模型今天在这几类任务上已经够用,而且是真的够用,不是"凑合":

文本的搬运和改造。 总结、改写、润色、抽取实体、分类、按格式重排——这类任务不需要模型"懂很多",只需要它"听话且稳"。苹果那个 3B 端侧模型的官方定位就写得很白:它擅长总结、抽取、文本理解、润色、短对话,它明确不是一个用来问世界知识的聊天机器人。这个定位是诚实的,也是对的。

结构化输出和函数调用。 这是过去一年小模型最大的一块进步。Gemma 4 是第一个把"agentic 能力"当成一等设计目标的开源模型族——它不靠语法约束,就能稳定吐出合法的、可解析的 JSON 工具调用。这意味着一个本地小模型可以真的当"调度员"用:理解你的意图,挑对工具,填对参数,剩下的交给确定性代码去做。对很多 Agent 场景,模型本来就不该负责"算出答案",它只负责"派活"。

作为流水线里的快环节。 在我做的实时语音方向,小模型有个特别实在的用法:用一个本地快模型先兜住首句——“嗯"“好的,我看一下”——同时大模型在后台接管真正的内容。用户感知到的延迟一下就下来了。小模型在这里不是主角,是"垫话的人”,但这个角色很值钱。

垂直微调后的专用任务。 有评测把 12 个小模型放在 8 类任务上比,结论是 Qwen3-4B 微调后整体最强,在不少具体任务上能逼近一个 120B 级别的"老师"模型,而它只要一块消费级显卡就能部署。针对单一任务微调过的 4B,常常比通用的大模型更好用——它没有"什么都想说一点"的毛病。

一句话:凡是任务边界清晰、对世界知识依赖不深的活,小模型现在基本能接。

为什么端侧值得——算三笔账

能在端侧跑,和值得在端侧跑,是两件事。值得不值得,得算账。

第一笔,延迟。 端侧推理省掉的是网络往返和服务端排队。一次云端调用,光网络和排队的尾巴就可能几十到几百毫秒,还不稳定——你控制不了用户的网络。端侧模型首 token 不走网络,延迟低且可预测。对实时交互(语音、输入法、补全)来说,可预测比平均值低更重要。

第二笔,隐私。 数据不出设备,这不是宣传话术,是合规上实打实的区别。用户的短信、相册、健康数据、剪贴板——这些东西一旦"为了 AI 功能"传到云端,你就要为它的存储、传输、留存负责。端侧推理把这个责任直接消掉了。这也是苹果整条 Apple Intelligence 叙事的地基。

第三笔,成本。 这笔账最容易被低估。高频调用的场景下,把推理从云端 API 挪到端侧或边缘自托管,成本能降九成以上,高频负载的回本周期常常不到 18 个月。注意前提是高频——一个一天被调用三次的功能,没必要折腾端侧;一个每次输入都触发的补全功能,云端账单会吓到你。

但端侧不是免费午餐,它也有反方向的代价:

flowchart LR
  subgraph 端侧
    A1[延迟低且可预测]
    A2[数据不出设备]
    A3[高频场景成本极低]
    A4[受设备内存/算力封顶]
    A5[模型更新要走发版]
  end
  subgraph 云端
    B1[模型可以很大很强]
    B2[随时热更新]
    B3[网络抖动/排队不可控]
    B4[高频调用账单线性增长]
    B5[数据要出设备]
  end
  style A4 fill:#fde7c2,stroke:#e8b23c
  style A5 fill:#fde7c2,stroke:#e8b23c
  style B3 fill:#fde7c2,stroke:#e8b23c
  style B5 fill:#fde7c2,stroke:#e8b23c

端侧的两个真痛点:算力封顶(用户的旧手机就是跑不动 7B),和更新慢(模型修了 bug 要等 App 发版,不能像云端那样当天热推)。所以现实里成熟团队的做法是混合:简单高频的活落端侧,复杂低频的活路由到云端。

量化和蒸馏:把模型塞进设备的两把钳子

小模型能上端侧,光靠"参数少"还不够。一个 4B 模型用 FP16 存,也要 8GB,塞进手机内存还是紧。真正把它压进去的,是量化和蒸馏。

量化是压"表示精度"。 模型权重原本是 16 位浮点,量化把它降到 8 位、4 位甚至更低。直觉上这会掉精度,但实际上掉得没你想的多——4-bit 的 Q4_K_M 这类方案,跟原始 BF16 比通常只掉 1~3 个百分点的基准分。代价换来的是:一个 Llama 3.2 3B 做 4-bit 后训练量化,体积砍掉约 69%,就能在普通安卓机上顺跑。

这里要分清两种量化:

苹果那个 3B 端侧模型用的就是更狠的一招:2-bit 量化感知训练。在 2-bit 这种极端低比特下,纯后训练量化会崩,只有训练时就让模型"知道自己会被压成 2 位",精度才扛得住。这是用训练成本换部署体积的典型取舍。

蒸馏是压"知识"。 它不动表示精度,而是让一个小模型(学生)去模仿一个大模型(老师)的输出分布。学生学到的不只是"正确答案",还有老师对每个选项的"软概率"——这里面藏着大模型的判断方式。蒸馏过的小模型,在被蒸馏的那个任务域上,表现会明显超过同尺寸从头训的模型。

要点是:量化和蒸馏不冲突,是叠着用的。 典型流水线是先蒸馏出一个能干活的小模型,再量化把它压进设备内存。一把钳子压知识,一把钳子压精度,两把一起上,4B 才进得了手机。

flowchart LR
  A[大模型 / 老师] -->|蒸馏
传递知识| B[小模型 / 学生
4B FP16]
  B -->|量化
压缩精度| C[端侧模型
4B 4-bit]
  C --> D[手机 / 笔电 / 边缘盒子]
  style B fill:#fde7c2,stroke:#e8b23c
  style C fill:#fde7c2,stroke:#e8b23c

硬件这边也在同步补位。今年笔电上的 NPU 终于不只是"参数表上的一行字"了——谷歌的 LiteRT-LM 在 Linux、macOS、Windows 上都能把推理路由到 NPU;AMD 的 Ryzen AI Max+ 这类芯片配上百 GB 级的统一内存,本地跑 7B~13B 已经不费劲。模型在变小,设备在变强,两条线在中间撞上了。

它干不了什么——别被"逆袭"冲昏头

写到这儿得踩一脚刹车。小模型这一年确实猛,但有几件事它现在做不到,而且短期也做不到。

它的世界知识就是浅。 这是参数量的物理限制,不是调教问题。研究里反复出现的一个结论:小模型的幻觉率显著高于大模型。尤其当你拿大模型的输出去微调小模型时,会出现"知识错配"——喂给它的知识超出了它本身装得下的量,反而更容易胡说。所以任何依赖"模型自己知道很多事实"的场景——开放域问答、冷门领域咨询——别指望端侧小模型。要做,就得给它接检索(RAG),让事实从外部来,模型只负责组织语言。

长链条、多步推理它会断。 需要七八步严密推演才能得到的答案,小模型中途容易掉链子。它适合"一两步就能想清"的任务,不适合当复杂推理的主脑。

再小一点就崩了。 别被"参数越小越好"带跑偏。1B 以下的模型(比如 270M、0.5B 这个量级)是真能跑,但质量在除了最简单的分类之外的任务上断崖式下跌。不是所有任务都越小越好,有个下限,过了就是不能用。

我的判断很直接:小模型不是来取代大模型的,这场"逆袭"不是零和的。它做的事是把 AI 能力的下限抬高了——以前必须上云、必须付费、必须联网才能做的一批活,现在一台设备本地就能办。大模型继续往上探能力的天花板,小模型在下面把地基铺宽。这两件事都在发生,而且互不矛盾。

如果你现在要做端侧

给一个落地顺序,和我做语音 Agent 时的优先级思路一致——先想清楚,再动手:

1. 先问任务边界,别先挑模型。 任务边界清晰、不靠深度世界知识,才适合端侧小模型。边界模糊的,先别碰。
2. 按调用频率决定端侧还是云端。 高频(每次输入都触发)优先端侧;低频复杂任务留给云端。混合是常态,不是妥协。
3. 要事实,就上 RAG,别让小模型硬背。 把"知道什么"外置成检索,模型只管"怎么说"。这一步能把幻觉问题压下去一大半。
4. 模型选型从 4B 这一档试起。 今天 4B 是端侧的甜区——Qwen3-4B、Gemma 4 E4B 这一档,能力够、塞得进、微调后很能打。往下到 1B 以下要非常谨慎。
5. 量化按设备定。 手机这种内存紧的,认 4-bit、认 GGUF;有 NPU 的笔电,把推理路由过去,能凉一截也快一截。

端侧 LLM 今年最大的变化,不是某个模型刷新了某个榜单,而是**“在设备上本地跑一个够用的语言模型"这件事,从研究 demo 变成了产品默认选项**。你的手机已经在这么做了。接下来一年,轮到你的产品。

这个数字有意思的地方在于:它比 QwQ-32B-Preview 还高。一个 7B 的小模型,在硬核推理题上,打过了一个参数量是它四倍多的模型。

更反常识的是后面这句——DeepSeek 自己说的:直接拿强化学习去训练那个 7B 小模型,效果还不如蒸馏。小模型自己练,练不出这种推理能力;但你拿一个 671B 的大模型当老师,把它的思考过程喂给小模型学,小模型就学会了。

这就是蒸馏。它不是模型压缩里的某种玄学技巧,而是 2026 年几乎每家做小模型的团队都在用的标准动作。这篇把它讲清楚:蒸馏到底搬走了什么,和微调是什么关系,能搬多少,做不到什么,以及一套能落地的流程。

为什么要蒸馏:质量和成本之间那道墙

先说动机。

大模型好用,但贵。一个 400B 参数的旗舰模型,推理延迟高、单次调用成本高、显存吃得狠,你不可能把它塞进每一台手机、每一个边缘设备、每一条高并发的客服管道。可小模型呢?便宜、快、能本地跑,但你直接拿一个 7B 模型出来用,它在复杂任务上的回答质量,和旗舰模型差着一大截。

这就是那道墙:质量在大模型这边,成本和延迟在小模型那边,你想两个都要。

传统的过墙办法有两种。一种是直接训练一个小模型——但小模型受参数量限制,见的数据再多,某些能力(尤其是多步推理)就是练不出来,这是容量天花板。另一种是把大模型剪枝、量化——这能省一点,但省不了数量级,而且剪过头质量就崩。

蒸馏是第三条路,也是目前性价比最高的一条:不让小模型自己悟,而是让大模型手把手教它。Meta 拿 Llama 4 Behemoth 去训 Llama 4 的 Scout 和 Maverick,Google 用 Gemini 去带 Gemma 2 和 Gemma 3,DeepSeek 用 R1 蒸出 1.5B 到 70B 一整个系列——2026 年你能叫得出名字的小模型,背后基本都站着一个大模型老师。

道理很朴素:让一个聪明人把题做一遍、把思路讲给你听,比你自己对着标准答案死磕,学得快得多。

蒸馏到底在传递什么

很多人对蒸馏的第一印象是"用大模型造点数据,拿去训小模型"。这个理解对了一半,但漏掉了最关键的东西。

蒸馏的精髓在于软标签(soft label)。

举个例子。你问模型"这句话情感是正面还是负面",一个普通的训练样本只会告诉小模型一个硬标签:正面。但大模型老师给出的不是一个字,而是一整个概率分布——比如"正面 0.82、负面 0.11、中性 0.07"。

这个分布里藏着硬标签给不了的信息:老师不光告诉你答案是什么,还告诉你它有多确定、它觉得别的选项有多接近。这种"模型对各种可能性的相对判断",业内叫暗知识(dark knowledge)。小模型学的不只是结论,是老师那套打分的体感。

技术上,这通常通过让学生去拟合老师的 logits(输出层的原始分数)来实现,用 KL 散度当损失函数,衡量学生分布和老师分布差了多远。这条路线效果最好,但有个前提:你得能拿到老师的 logits——也就是老师得是个"白盒"。

flowchart TB
  T[教师大模型] -->|完整概率分布
soft label| K[KL 散度损失]
  T -->|生成的答案 + 思维链
hard label| C[交叉熵损失]
  K --> S[学生小模型]
  C --> S
  S -->|采样自己的回答| V[教师/验证器打分]
  V -->|纠正学生的错误| S
  style T fill:#fde7c2,stroke:#e8b23c
  style S fill:#cfe8d8,stroke:#4ca877

如果老师是个只给你返回文字的 API(黑盒),你拿不到 logits,那就退而求其次:让老师大量生成完整的答案和推理过程,再拿这些文本当训练数据去教小模型。DeepSeek 蒸馏 R1 用的就是这条路——他们用 R1 生成了 80 万条样本,然后纯靠监督微调(SFT)把这些样本喂给 Qwen 和 Llama,连强化学习都没加。这条路拿不到暗知识,但胜在简单、不挑老师、谁的 API 都能蒸。

蒸馏和微调,到底什么关系

这是最容易绕晕的一个点,我直接给结论:蒸馏和微调不是对立的,蒸馏的落地往往就是一次微调,只是数据来源不同。

把它们放一起看:

看出来了:微调是"怎么训"的问题,蒸馏是"用什么数据训、为了什么目的"的问题。当你拿 R1 生成的 80 万条数据去 SFT 一个 Qwen,你既在做蒸馏,也在做微调——这两件事在那一刻是同一件事。

实践里常见的组合拳是这样的:先蒸馏,把大模型的通用推理能力搬进小模型,得到一个"底子好"的基座;再拿你自己的业务数据做一次轻量微调,让它贴合具体场景。先蒸再调,各管一段,这是 2026 年成熟团队的标准配方。

它能搬走多少,又搬不走什么

蒸馏不是魔法。说清楚它的边界,比吹它的效果更重要。

搬得动的: 有明确"过程"和"答案"的能力,蒸馏搬运效率最高。数学推理、代码生成、逻辑规划、结构化抽取、指令遵循——这些任务有清晰的思维链可以模仿,有可验证的对错。DeepSeek-R1-Distill 系列在 AIME、MATH-500、代码这些榜单上的大幅领先,就是证据。一个被好好蒸过的小模型,在它擅长的窄领域里,能逼近甚至偶尔超过原始大模型在该领域的表现。

搬不动的,有三类要心里有数:

第一,老师不会的,学生也学不会。蒸馏是能力的转移,不是能力的创造。老师的水平就是学生的天花板,你不可能蒸出一个比老师还强的模型(在老师覆盖的能力上)。

第二,广度会被压缩。小模型参数量摆在那,容量有限。你蒸数学,它数学强;但如果你想让它数学、代码、多语言、长文本、创意写作样样精通,它装不下。蒸馏逼着你做取舍:想清楚这个小模型到底要干什么,然后只蒸那部分。什么都想要,结果是什么都平庸。

第三,泛化能力可能变弱,这是个隐蔽的代价。2026 年有研究指出一个值得警惕的现象:蒸馏(尤其是自蒸馏)会让小模型推理变快、在分布内的题上表现好,但在没见过的、需要灵活变通的题上,泛化反而退步了。原因是学生学的是老师在特定题型上的"套路",套路学得越熟,越容易在新题型上水土不服。这个权衡叫"更快的推理,更弱的泛化"——蒸的时候要盯着分布外的测试集,别只看训练集附近的漂亮数字。

推理蒸馏:2026 年最值得关注的一支

推理模型的兴起,给蒸馏带来一个新麻烦,也催生了一个新方法。

麻烦在于:推理模型动不动就是几千 token 的长思维链。链条越长,误差越会一步步累积——老师在第三步走错一小步,学生照单全收,后面全错。你按传统办法,把老师生成的思维链整段喂给学生去模仿,学生学的是"老师在老师自己的思路上怎么走",可一旦学生自己推到一个老师从没经过的中间状态,它就懵了,因为训练时没人教过它这种情况怎么办。

2026 年的解法叫在线蒸馏(on-policy distillation),现在已经是 DeepSeek-V4、Qwen3、Gemma、Nemotron 这些前沿模型做推理后训练的标配。

它的思路反过来:不让学生模仿老师的轨迹,而是让学生先自己走。学生针对一道题,用自己当前的水平生成一条推理路径;然后老师(或者一个奖励模型、一个验证器)来给这条路径打分、指出哪里错了;学生再根据这个反馈修正。

关键区别在于:学生学的是"在我自己会犯的错误状态下,该怎么爬出来",而不是"老师在它的完美状态下怎么走"。这就解决了前面那个状态不匹配的问题——学生纠错纠的是自己真实会遇到的坑。代价是工程更复杂:你需要一个能在线打分的老师或验证器,训练时还得不断采样,比离线蒸馏重不少。

一套能落地的流程,和几个坑

如果你要真的蒸一个模型出来,我建议按这个顺序走:

1. 先把任务边界划死。这个小模型只干一件事还是几件事?接受多大的质量损失换多少成本?这一步想不清楚,后面全是返工。
2. 选老师和基座。老师选你能力范围内最强、且最好是白盒(能拿 logits)的;基座小模型选参数量匹配你部署预算的。Qwen、Llama 这些开源系列是常见选择。
3. 造数据。让老师在你的目标任务分布上大量生成,带上完整推理过程。数据的覆盖面决定了学生的上限——老师没生成过的题型,学生就是盲区。
4. 训练。黑盒老师就纯 SFT;白盒老师就加上 logits 的 KL 损失,效果更好。资源紧就 LoRA。
5. 评估,而且要评分布外。别只看训练集附近的指标,一定要拿没蒸过的题型测泛化,盯住前面说的"泛化退化"。

几个反复见到的坑:

• 老师数据不验证。大模型也会生成错答案,你不筛一遍就喂给学生,学生连错误一起学。蒸推理任务时,务必用验证器或答案对照过滤掉老师做错的样本。
• 盯着平均分,忽略短板。蒸完看总分涨了就交差,结果某个子能力悄悄崩了。要按子任务分别看。
• 以为蒸馏能省掉数据工程。蒸馏省的是人工标注,不是数据设计。老师生成什么、覆盖哪些分布,仍然得你来设计,这活儿一点不轻。
• 法律和合规边界。用某个商业 API 的输出去蒸自己的模型,可能违反对方的服务条款。蒸之前先看清楚老师那边的许可,这是工程之外、但绕不开的一道坎。

最后回到开头那个 7B 模型。它能打过 32B,不是因为它聪明,是因为它有个好老师,而且有人想清楚了"只让它学推理这一件事"。蒸馏的价值从来不是"免费得到一个强模型",而是让你能在质量和成本之间,精确地选一个你要的点——前提是你真的想清楚了要选哪个点。

参考资料

• On-Policy Distillation — Thinking Machines Lab
• A Survey of On-Policy Distillation for Large Language Models — arXiv
• The paradox of LLM self-distillation: Faster reasoning, weaker generalization — TechTalks
• DeepSeek-R1 — GitHub
• Understanding LLM Distillation Techniques — MarkTechPost
• The Best Open-Source Small Language Models in 2026 — BentoML
• Knowledge Distillation: Teacher-Student Loss Explained — Label Your Data