第 11 章 — 更小的模型,更聪明的模型

发布于: 2026-02-28 最后更新于: 2026-06-05 版本: 1

第 11 章 — 更小的模型,更聪明的模型

LLM Primer I: How Generative AI Works 章节走读的第十一篇。当尺寸不再就是优点 — 以及 2026 年,"聪明模型"的边界正在哪里。


光大模型本身,不是答案

前几章看到的那些大模型,运营起来的成本不轻。回答慢、单 token 贵、对底层基础设施压得重。回到真实工作里,自然就会冒出一个问题:能不能在更小的模型里保住大模型的能力 — 更快、更便宜?

第 11 章就是讲这个问题怎么细看。

一句话总结:"模型越大答案越好"是头条话术。在运营里,挑对任务的模型几乎总是胜过手边那个最大模型。

蒸馏 — 把"老师"的本事传给学生

最成熟的一条路是蒸馏。一句话:大模型("老师")在各种输入上生成回答;小模型("学生")学着模仿这些回答 — 不只是最后那个答案,还包括老师生成的整张分布。学生既学到了正确答案,也学到了老师"哪里有把握、哪里没有"的那种纹理。

所以一个蒸馏出来的学生,常常比只用"正确答案"训出来的学生更稳 — 它继承了老师的直觉,而不只是事实。

量化 — 把权重的精度调低

第二条路是量化。模型的权重 — 几十亿个数字 — 通常用 32 位或 16 位存。量化就是把这个精度降到 8 位、4 位,甚至更低。

精度一降,整个模型按比例缩。同一块 GPU 能装下更大的模型,同一个模型跑得更快。而且 — 多少有点意外 — 在量化做得合理的情况下,行为大体上保持不变。不是每个模型都能扛得住量化不掉精度,训得好的模型一般扛得住。

MoE — 把知识分给专家

第三条路在性质上不太一样。MoE(混合专家)在一个大模型里塞进几个"专家"子网络。对每个 token,只有部分子网络被激活。总参数量很大;每次调用真正参与计算的只是其中一部分。

有意思的是,模型整体里装着几种风格的专长,但每次调用都只调它最贴合当前输入的那一块。

§11.6 — 2026 版新加的"推理模型"

2026 版里我新开了 §11.6,讲一个完全不同方向的前线。它不是效率的事 — 是反过来的事。

一句话:让模型在每次调用里,在自己的"推理链"里写更多 token。然后用 RLHF 把这条链打磨,让模型学会在自己内部推理得更稳。最后给到你的答案,是经过比同等模型更深的推理过得来的。

效率让"同一个答案"做得更便宜。推理模型让"同一次回答"贵一些,换来质量。这两个方向今天在同一些模型家族里并存。这就是 2025–2026 这段时间最大的那根轴。

重要:效率和推理模型,是同一个选择的两面 — "在一次调用里,我们愿意烧多少 token?"一边是砍,一边是投。运营者得会选。

第 11 章那条主线

这章留下的话是:没有一个"放之四海皆准"的正确模型。只有针对具体任务、预算和你想要的回答类型的那个正确模型。能在效率和深度推理之间灵活挪动,是 2026 年好好运营 LLM 的一部分。


明天 — 第 12 章:搭一个 LLM 系统 — 以及之后。最后一篇。模型、工具、RAG、评估、护栏 — 缝成一套系统。以及从这本书走向系列后续第 2–7 卷的那座桥。

想看完整的全貌?书里把效率和推理收到一处,包括 2026 版 §11.6 的新内容。在亚马逊查看《LLM Primer I》→

下田 昌平
下田 昌平
作为株式会社Receipt Roller的CEO兼CTO,目前负责开发电子收据服务以及自动将对话分类并生成行动任务的系统「ACTIONBRIDGE」。从小便接触编程,1996年参与开发测量仪器的相关程序,始终保持着对技术的深刻探索与热情。 在此前的职业生涯中,曾担任日本最大呼叫中心行业企业的子公司——一家研究开发公司的CEO/CTO,领导了多个技术开发项目。目前,我依然活跃在编程的最前沿,持续书写代码。