这听起来像偷工减料,其实是过去三年大模型架构最重要的一次转向。到 2026 年,你叫得出名字的开源旗舰里,几乎没有一个还是"老老实实每个参数都算"的稠密模型:DeepSeek V4-Pro(1.6 万亿总参 / 490 亿激活)、Qwen 3.5(3970 亿 / 170 亿)、Llama 4 Maverick(4000 亿 / 170 亿)、Kimi K2(1 万亿 / 约 320 亿)、Mistral Large 3(6750 亿 / 410 亿)。这个架构叫 Mixture-of-Experts,混合专家。

它解决的是一个很具体的矛盾:模型想变聪明,最直接的办法是堆参数;但参数一多,推理就慢、就贵。MoE 的本质,是把"模型有多少知识"和"算一次要花多少钱"这两件事拆开。这篇讲清楚它怎么做到的,以及它换来了什么样的工程代价。

先讲清楚:稠密模型贵在哪

传统的大模型——也就是 GPT-3、早期 Llama 那种"稠密"(dense)模型——有一个朴素的规则:每个 token 经过每一层时,所有参数都要参与计算。

一个 700 亿参数的稠密模型,处理一个 token 就要做大约 700 亿次乘加。处理一句 100 字的话,乘以 100。参数翻倍到 1400 亿,这个账单也跟着翻倍。算力、显存带宽、电费,全是线性涨上去的。

问题是,模型里真的每个参数对每个 token 都有用吗?

直觉上不是。你问它"今天北京天气",和你让它"写一段 Rust 的并发代码",用到的知识完全不同。稠密模型的浪费就在这:不管你问什么,它都把"写代码的脑区"和"聊天气的脑区"全部点亮算一遍。

MoE 想做的事很朴素——该用哪块脑子,就只用哪块。

用一个类比把它讲透

把稠密模型想象成一家公司,每来一个问题,全公司 200 个人都得开会、都得发言,然后把意见汇总。问题再小也这么干。开会效率极低,但好处是没人会漏掉。

MoE 是另一种公司。同样养着 200 个员工(这叫专家,expert),但每来一个问题,门口坐着一个调度员(这叫路由器,router 或 gating network),它扫一眼问题,只挑最对口的 8 个人进会议室,其余 192 人继续待岗。

关键点来了:

• 这家公司"知识总量"还是 200 人份的——养着这么多专业各异的人,什么问题都有人能接。
• 但"开一次会的成本"只有 8 人份——大部分人这次根本没参与。

这就是 MoE 那句听起来矛盾的话——“参数量大,但推理便宜”——的全部秘密。总参数(200 人)决定模型的知识容量;激活参数(8 人)决定你每跑一次推理的算力账单。MoE 把这两个数字解耦了。

DeepSeek V3 就是个标准样本:总参 6710 亿,但每个 token 只激活 370 亿。它每个 token 的计算量,大约相当于一个 370 亿的稠密模型,但它肚子里装的知识,是 6710 亿那个量级的。官方的说法是,它每 token 的有效计算成本,大致是同等总参稠密模型的二十分之一。

路由器:整个架构的开关

MoE 里最精巧、也最容易出问题的零件,是路由器。

它的工作具体发生在模型的每一个 MoE 层里。一个 token 进来,路由器算一个打分,给当前层的每个专家打个分,然后选出得分最高的几个(术语叫 top-K,DeepSeek V3 是 top-8),只把这个 token 送进这几个专家。专家各自算完,按打分加权汇总,再往下一层走。下一层又是一次全新的挑选。

flowchart TD
  T[输入 token] --> R{路由器
给每个专家打分}
  R -->|得分 0.41| E1[专家 1 ✓]
  R -->|得分 0.27| E2[专家 2 ✓]
  R -->|得分 0.02| E3[专家 3 跳过]
  R -->|得分 0.18| E4[专家 4 ✓]
  R -->|得分 0.01| E5[专家 ... 跳过]
  E1 --> M[加权汇总]
  E2 --> M
  E4 --> M
  M --> O[进入下一层]
  style E3 fill:#eee,stroke:#bbb,color:#999
  style E5 fill:#eee,stroke:#bbb,color:#999
  style R fill:#fde7c2,stroke:#e8b23c

这里有几个反常识的点,值得单独说:

专家不是"按学科分工"的。 你不会找到一个"数学专家"或者一个"法语专家"。训练完之后去看,专家学到的分工往往很碎、很说不清——可能某个专家专门处理标点和换行,某个专门管代码缩进。分工是训练里自己涌现出来的,人没法预先指派。

路由是逐层、逐 token 的。 不是一句话进来挑一次专家就定了。一个 token 在 60 层里,可能经过 60 组完全不同的专家组合。所以"激活了哪些专家"是个非常动态的东西。

2026 年的主流是"细粒度专家 + 共享专家"。 DeepSeek 带火的这套设计有两个改动。一是把专家切小切多——与其养 8 个大专家,不如养 256 个小专家,每次激活 8 个。专家越细,组合越多,分工越能专精。二是留一两个共享专家(shared expert)常驻,不参与路由,每个 token 都过——专门负责"标点、语法、常识"这类谁都要用的通用能力,这样路由的那些专家就能腾出来专攻各自的细分领域。

激活参数 vs 总参数:一张表说清楚

这两个数字,是 2026 年看模型参数表时唯一真正要分清的事。它们决定了完全不同的东西:

看这张表,你能立刻得到一条很实用的判断:一个标成 “397B-A17B” 的模型,前面那个数(397B)是你买显存时要看的,后面那个数(17B)是你估推理速度时要看的。两者别搞混——这是 MoE 部署里最常见的认知错误。

它带来的实际效果是反直觉的:Qwen3.5 那个 35B-A3B 的 MoE 版本,占的显存远比 9B 的稠密版大(光权重就 21GB 对 5.8GB),但在同一张卡上,它的吞吐和首 token 延迟反而更好。显存占得多,但跑得快——因为速度只跟那 3B 激活参数有关。

天下没有白吃的午餐:MoE 的工程代价

讲到这你可能觉得 MoE 是纯赚的——同样的算力,能装下大得多的模型。但它把成本从"算力"转移到了别的地方,而且这些地方往往更难搞。

第一笔账:显存。 推理时虽然只算 8 个专家,但你不知道下一个 token 会路由到哪 8 个,所以全部 256 个专家的权重都得待在显存里。MoE 省的是算力,不是显存。Kimi K2 这种 1 万亿参数的模型,FP16 精度下光权重就要 2TB 量级的显存,只能靠多卡集群伺候。“激活参数小"绝不意味着"能在小显卡上跑”。

第二笔账:负载均衡。 路由器是学出来的,它会"偏心"。如果不管,训练到后面会出现"马太效应"——几个专家因为早期表现好,被路由器越选越多,练得越来越强;另一批专家几乎没 token 光顾,等于白养。极端情况下,你那个 256 专家的模型,实际只有几十个在干活,知识容量大打折扣。

早期的解法是加一个辅助损失(auxiliary loss),硬性惩罚"分配不均",逼路由器雨露均沾。但这个惩罚项会和"把 token 送给最对的专家"这个主目标打架,损害模型质量。DeepSeek V3 改用了一个无辅助损失的方案:给每个专家的路由打分加一个可调的偏置项,某个专家最近太忙就把它的偏置调低、太闲就调高——只动路由、不进损失函数。这个细节,正是 DeepSeek 那一代模型训练能又稳又便宜的关键之一。

第三笔账:部署复杂度。 专家太多,一张 GPU 装不下,得专家并行(expert parallelism)——把 256 个专家摊到几十张卡上。这下问题来了:一个 token 路由到的 8 个专家,可能散在 8 张不同的卡上,token 得先被发过去、算完再收回来。这种跨卡通信(all-to-all)是 MoE 推理的头号瓶颈,而且负载是动态的——这一批 token 可能全挤向某几张卡,那几张卡就成了堵点。稠密模型完全没有这套烦恼。

所以 MoE 不是"免费午餐",而是一笔用工程复杂度换计算效率的交易。它假设你有能力搞定多卡集群、搞定专家并行、搞定负载均衡。对个人开发者和小团队,在本地跑一个大 MoE,门槛其实比同等"能力档位"的稠密模型更高——因为卡在显存上。

为什么 2026 年几乎全是 MoE

把上面的账合起来算,结论就很清楚了。

到 2026 年,纯靠堆稠密参数这条路已经走到头:再大的稠密模型,推理成本高到没法规模化服务。而模型厂商面对的需求又是确定的——既要在榜单上有竞争力(要知识容量、要总参数),又要能用可接受的成本服务上亿用户(要推理便宜、要激活参数小)。

MoE 是目前唯一能同时满足这两头的架构。它让厂商可以理直气壮地把总参数推到万亿级,同时把激活参数压在二三十亿到五十亿这个"服务得起"的区间。DeepSeek、Qwen、Llama、Kimi、Mistral——这些团队各自独立地收敛到同一个设计,不是跟风,是因为约束条件相同,最优解也就相同。

但要泼一点冷水:MoE 不是没有代价的银弹。它把模型能力做大了,却把工程门槛也抬高了——显存、通信、负载均衡,每一样都需要专门的基础设施。它真正改变的,不是"模型能多强",而是"多强的模型能被服务得起"。 对 2026 年要做规模化部署的团队来说,这恰恰是最重要的那个问题。

参考来源:

• DeepSeek-V3 Technical Report (arXiv)
• DeepSeekMoE: Towards Ultimate Expert Specialization (arXiv)
• MoE Model Inference on GPU Cloud: Expert Parallelism, Memory, and Cost (2026) — Spheron
• LLM Landscape May 2026: DeepSeek V4 vs Qwen 3.5 vs Llama 4 — QubitTool
• A Review on Load Balancing Strategy in MoE LLMs — Hugging Face

假设你的 Agent 有一段 4000 token 的 system prompt:角色设定、工具说明、几个 few-shot 例子,雷打不动。用户每轮真正输入的,可能就 30 个字。一天 10 万次请求,这 4000 token × 10 万,就是 4 亿个 token 反复进入模型做同一件事——把固定前缀重新算一遍。

这部分计算,90% 是白烧的。因为前缀一模一样,模型每次算出来的中间结果(KV cache)也一模一样。Prompt caching 就是把这份中间结果存下来,下次直接复用。 它不改你的代码逻辑,不动模型质量,却能把输入侧成本砍掉一大半,顺带把首 token 延迟压下去。

2026 年,它依然是被严重低估的省钱手段。不是因为难,恰恰是因为太简单——简单到大家以为"开了就行",结果断点放错位置,缓存全程没命中,白付一笔写入费还不自知。

它到底缓存了什么

要用对,先得知道模型推理分两个阶段。

Prefill(预填充):把你的整段 prompt 一次性喂进模型,逐 token 算出每一层的 KV(key/value)向量。这一步是并行的、算力密集的,prompt 越长越慢。

Decode(解码):基于 prefill 的结果,一个一个吐出回答 token。

Prompt caching 缓存的,就是 prefill 阶段算出来的那份 KV。注意:它缓存的是前缀,不是"整个 prompt"。模型从第一个 token 开始,一段一段比对——只要某个位置往前的内容和缓存里的完全一致,这段就能复用;一旦遇到第一个不一样的 token,从那里往后全部得重算。

flowchart LR
  A["请求 prompt"] --> B{"逐 token 比对前缀"}
  B -->|"前缀命中"| C["复用 KV
(便宜 + 快)"]
  B -->|"遇到第一个差异"| D["从这里往后重新 prefill"]
  C --> D
  D --> E["Decode 出 token"]

这张图就是 prompt caching 的全部精髓。所有的"怎么用对",归结成一句话:让不变的东西待在前面,让变化的东西待在后面。

为什么前缀的顺序决定一切

各家请求体的拼接顺序是固定的:tools(工具定义)→ system(系统提示)→ messages(对话历史)。模型按这个顺序拼成一条长 prefix,再从头比对。

这意味着排在越前面的内容,越"值钱"——它一旦变化,后面所有东西的缓存全部作废。所以一个合格的可缓存 prompt,结构应该长这样,从稳定到易变排列:

最常见的翻车,是把"变化的东西塞进了前面"。比如有人喜欢在 system prompt 顶部写一句 当前时间:2026-05-05 11:23:07。看着无害,实际是灾难——这个时间戳每秒都不一样,等于把整条 prefix 的第一个字就改了,后面 4000 token 的缓存全程一次都命中不了。同类的坑还有:user ID、请求 UUID、A/B 实验分组标记、随机打乱的 few-shot 顺序。

如果你确实需要给模型当前时间,把它放到对话消息的最后,跟用户输入待在一起。前面那一大坨稳定前缀,该缓存照样缓存。

缓存断点放哪:自动 vs 手动

这里是各家最大的分歧,也是最容易用错的地方。

自动派(OpenAI、Google 隐式缓存、DeepSeek):你什么都不用做。系统自动识别请求之间的公共前缀,命中了就给你折扣。OpenAI 对超过 1024 token 的 prompt 自动启用;DeepSeek 是后端自动复用磁盘上的前缀缓存;Gemini 2.5 及以后的模型默认开启隐式缓存。

自动派的好处是零成本接入,坏处是没有保证。命中是"尽力而为"的——Google 自己也写明,隐式缓存只在系统判定命中时才给折扣,你无法强制。

手动派(Anthropic,以及 Gemini 的显式缓存):你得自己在 prompt 里打一个 cache_control 标记,告诉模型"缓存到这里为止"。这个标记叫缓存断点(cache breakpoint)。Anthropic 一个请求最多打 4 个断点。

手动派麻烦一点,但换来确定性:你明确知道哪一段被缓存了。

手动派最经典的错误,是把断点打在了会变的块上。比如这样的结构——一大段静态知识库,后面跟一个"包含时间戳 + 用户输入"的块,然后断点打在最后这个块上。结果时间戳每次都变,这个块的 hash 每次都不同,缓存永远写入、永远读不到。

正确做法:断点打在「最后一个跨请求不变」的块的末尾,而不是打在变化的块上。把静态前缀和动态后缀切开,断点卡在它们的交界处。

flowchart TB
  subgraph 错误["错误:断点在变化块上"]
    A1["静态知识库 8000 token"] --> A2["时间戳 + 用户输入 ⟵ 断点"]
  end
  subgraph 正确["正确:断点在静态前缀末尾"]
    B1["静态知识库 8000 token ⟵ 断点"] --> B2["时间戳 + 用户输入"]
  end

还有一个多轮对话特有的坑:对话越滚越长,你的断点可能被挤到"上一次写入位置"20 多个块之外,超出回溯窗口,于是又一次踩空。多轮场景里,务必随着对话增长滚动更新断点位置,让它始终贴着最新的稳定边界。

四家的计费和 TTL,差得不小

省多少、贵多少、能存多久——各家规则不一样,接之前一定要看清。

几个要点单独拎出来说。

Anthropic 是唯一对"写入"收钱的。 写一次缓存比正常输入贵 25%(5 分钟档)。这意味着如果你的 prompt 写进去之后根本没被复用就过期了,你是净亏的——多付了 25%,一分钱折扣没拿到。所以 Anthropic 的缓存只对"高频复用同一前缀"的场景划算。读取确实便宜,只要 1/10 输入价。

TTL 是个隐形雷区。 Anthropic 默认 TTL 在 2026 年初从 1 小时悄悄变回了 5 分钟,不少团队因此缓存创建成本涨了 20%~30% 还没察觉。5 分钟意味着:如果你的请求间隔超过 5 分钟,缓存早凉了,每次都是冷启动重新写入。好消息是 TTL 的时钟会在每次命中时重置——只要请求够密,缓存能一直续命。需要长间隔复用的,Anthropic 可以花 2 倍写入价买 1 小时 TTL。

OpenAI 和 DeepSeek 对开发者最省心:不收写入费,自动命中,几乎是"白送的折扣"。DeepSeek 2026 年 4 月把 cache hit 价格再砍到发布价的 1/10,V4-Flash 上缓存命中把输入成本从 $0.14 压到 $0.0028 每百万 token——98% 的降幅。

省钱幅度的体感:输入侧能省 50%~90%。具体看你的 prompt 里"固定前缀占比"有多高——前缀越长、变量越短,省得越狠。一个 8000 token 知识库 + 50 token 提问的 RAG 应用,几乎是为 prompt caching 量身定做的。

别忘了它还能压延迟

省钱是它最出名的好处,但对实时类应用,降延迟才是关键收益。

命中缓存时,prefill 这一步被整段跳过。前面说过,prefill 是算力密集的,prompt 越长越慢。跳过它,首 token 延迟(TTFT)的下降立竿见影——DeepSeek 给过一个数据:128K 的长 prompt 高度命中缓存时,首 token 延迟从 13 秒压到 500 毫秒。

这对语音 Agent、实时对话这种"首 token 延迟就是及格线"的场景,意义比省钱大得多。一个挂着长 system prompt 和工具定义的语音助手,把这部分缓存住,等于每一轮对话都省掉了几千 token 的 prefill 时间。如果你正在为 TTFT 抠毫秒,prompt caching 应该排在优化清单的前列。

不过有个前提:省下来的延迟,得真的有缓存可命中。冷启动那一次(第一次写入)不但不快,Anthropic 那边还更慢更贵。所以 prompt caching 优化的是"稳态延迟",不是"首次延迟"。

一份排查清单:为什么我没命中

如果你接了 prompt caching,但账单没怎么降,大概率是踩了下面某一条。按顺序自查:

1. 前缀里有变量。 时间戳、UUID、user ID、随机数——但凡有一个混进了 system prompt 或工具定义,整条缓存作废。把它们全部赶到 messages 末尾。

2. 断点打错位置(手动派)。 断点要打在"最后一个不变块"的末尾,不是打在变化块上。切开静态与动态的交界。

3. 请求间隔超了 TTL。 Anthropic 默认才 5 分钟。低频请求(比如定时任务、长间隔轮询)很可能每次都冷启动。要么提高请求密度,要么买长 TTL。

4. prompt 太短没够门槛。 OpenAI 要超过 1024 token 才会自动缓存。短 prompt 本来也省不了多少,不用纠结。

5. 工具定义或 system prompt 偷偷变了。 多人协作时,有人调了一下工具描述、改了个标点,排在最前面的 tools 段一变,后面全塌。把可缓存前缀当成发布制品来管理,别让它随手改。

6. few-shot 例子顺序不固定。 有些代码每次随机打乱 few-shot 顺序"增加多样性"——这会让前缀每次都不同。要缓存,就固定顺序。

落地建议

不用一上来就上复杂方案。三步走:

第一步,把 prompt 重新排版。 不管你用哪家,先按"工具 → system → 知识库 → 用户输入"从稳到变重排一遍,把所有变量揪到最后。光这一步,自动派(OpenAI / DeepSeek / Gemini)就能开始命中了,一行代码没动。

第二步,手动派打好断点。 用 Anthropic,就在静态前缀末尾打 cache_control;多轮对话记得滚动更新断点。

第三步,盯住命中率。 各家 API 响应里都会返回 cache 相关字段(命中 token 数、写入 token 数)。把"缓存读取 token / 总输入 token"做成一个监控指标。它要是长期偏低,回到上面那份清单逐条查。

最后提醒一句取舍:prompt caching 不是"开了就一定赚"。对 Anthropic 这种收写入费的厂商,低频、前缀短、变量多的场景,反而可能亏。先搞清楚自己的流量形态——高频复用同一份长前缀,才是它的主场。判断对了,这是你能拿到的、性价比最高的一次优化:不掉质量,不改逻辑,省一半成本,还顺手降了延迟。

参考资料:

• Prompt caching - Claude API Docs
• Cache TTL silently regressed from 1h to 5m · Issue #46829
• Prompt Caching in the API | OpenAI
• Prompt caching | OpenAI API
• Context caching overview | Google Cloud
• Gemini 2.5 Models now support implicit caching - Google Developers Blog
• DeepSeek API introduces Context Caching on Disk

这个数字有意思的地方在于:它比 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