为什么要把模型做小
成本、速度、私有化三个现实动机，和小模型做不到的那些事
本页解决的问题
先给结论「为什么要把模型做小」要解决的关键问题是什么？
成本、速度、私有化三个现实动机，和小模型做不到的那些事
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
成本差的是数量级，不是几成
参数量小一个量级，一次推理要动用的算力通常也小一个量级。行业里的常见口径是，小模型的推理成本可以比旗舰模型低一到两个数量级。具体差多少，取决于尺寸、量化档位、批量大小和部署方式。别记死数字，记住这是量级上的差距，不是打个折。
速度本地跑省掉整段网络往返
调用远端旗舰模型，要走一次网络往返，还要排队，然后逐字生成。等上几秒是常态。本地跑的小模型省掉了网络这一段，首字出来得快得多。对话类产品对这一段特别敏感，用户等三秒和等零点三秒，是两种体验。
私有化与合规有些数据根本不允许出内网
病历、卷宗、内部代码、未公开的财务数据，这类内容的合规要求是不出内网。这时候对面的模型能力再强也用不上，因为第一步就过不去。本地部署的小模型是唯一一条路。第一节讲权重时说的那个控制权，在这里变成了硬约束。
「差一到两个数量级」这句话，换算成月底那张账单是多少？把你产品的请求量拖进去看看。
「小」是个相对的说法，但判断标准很具体：能不能塞进手上这块显卡。本章后面有一页交互工具专门算这件事，这里先把公式给出来。
FP16 取 2.6，INT4 取 0.65。系数里已经含了 KV Cache 这类运行时开销，不要在外面再乘一次。
按这个口径算几个尺寸。最后一列是 INT4 量化之后，在一块 24 GB 的消费级显卡上能不能跑。
结论很直白。8B 这个尺寸量化之后，一块几年前的游戏显卡就跑得动；旗舰尺寸不管怎么量化都进不去。于是问题变成了另一个：小尺寸的能力，能不能补上来。
补能力有两条路。一条是让小模型自己从头学，数据、算力、试错全部重来一遍。另一条是找一个已经学会的大模型来教它。后一条就是知识蒸馏。
这跟传统训练的差别，主要在一次能传过去多少信息。
训练数据给的是标准答案。答对了加分，答错了扣分。一道题传回来的信息基本就是一个「对」或者「错」。至于错得离谱还是只差一点，标签里看不出来。信息很稀疏，所以要靠海量数据和海量算力去堆。
老师给出的不只是最终那个答案，还有它在各个候选之间的倾向。同一道题，学生能看到老师觉得哪些选项接近、哪些完全不沾边。同样一条数据，携带的信息量大得多，学生学起来也就快得多。
这份信息具体怎么传过去、训练的时候怎么算，下一节 oss-6 会拆开讲。这一节只要记住动机：蒸馏省的是钱和时间，它不创造新能力。
2025 年 1 月 20 日，DeepSeek 发布 R1，同时开源了一批蒸馏版小模型。做法是用 R1 生成推理数据，再拿这批数据去训练更小的模型。这批蒸馏版里，有的以 Llama 为底座，有的以 Qwen 为底座。
这件事值得记一下，因为它是一次公开可查的第三方选择。一家公司做蒸馏时挑了哪些底座，比任何宣传口径都更能说明问题。R1 采用 MIT License，官方公告里明确写了允许通过蒸馏训练其他模型。这句话白纸黑字写出来，别人才敢把这条路走通。
这批模型的命名规则和具体做法，下一节展开。
二、能不能落地，先看显存这个硬指标，公式是参数量乘精度系数。
三、蒸馏是让大模型教小模型，目的是省掉从零训练的成本。
四、小模型有能力天花板，也会继承老师的缺陷。这两点在选型时要先摆到台面上。
下一节看蒸馏具体怎么做：老师怎么出题，学生怎么对答案，中间有哪些工程上的坑。
「先说结论」要放回选型约束
「参数量小一个量级，一次推理要动用的算力通常也小一个量级。行业里的常见口径是，小模型的推理成本可以比旗舰模型低一到两个数量级。具体差多少，取决于尺寸、量化档位、批量大小和部署方式。别记死数字，记住这是量级上的差距，不是打个折」说明，模型、许可证、接入方式和榜单都只是信息，不是脱离场景的答案。真正的选择取决于任务、数据边界、延迟、质量下限和运行成本。
先写淘汰条件，再看最高分
「调用远端旗舰模型，要走一次网络往返，还要排队，然后逐字生成。等上几秒是常态。本地跑的小模型省掉了网络这一段，首字出来得快得多。对话类产品对这一段特别敏感，用户等三秒和等零点三秒，是两种体验」涉及的比较，至少要使用同一组真实输入，并同时观察正确性、失败方式、响应时间和费用。一个在公开榜单上领先的模型，可能因为许可证、隐私要求或峰值延迟不适合你的任务。
没有测试集，就没有可靠的赢家
以「下一节看蒸馏具体怎么做：老师怎么出题，学生怎么对答案，中间有哪些工程上的坑」为起点，选几条真正会影响决策的输入，写下一个会改变选择的反例；这比记住一次排名更能支持下一次判断。
从「先说结论」走到「三个把模型往小里做的理由」
「先说结论」先把问题落在「把模型做小，是被现实逼出来的。 旗舰模型能力最强，但它贵、它慢，而且必须把数据发到别人的服务器上。很多场景里，一个能力够用的小模型才是唯一能落地的选项。蒸馏，就是把小模型的能力尽量补上来的那个手段」上；到了「三个把模型往小里做的理由」，讨论继续推进到「参数量小一个量级，一次推理要动用的算力通常也小一个量级。行业里的常见口径是，小模型的推理成本可以比旗舰模型低一到两个数量级。具体差多少，取决于尺寸、量化档位、批量大小和部署方式。别记死数字，记住这是量级上的差距，不是打个折」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
做模型选择时，先用真实任务写出不能妥协的条件，再用同一组输入比较质量、失败方式、延迟、许可和成本；榜单只适合作为起点。
- 「先说结论」：把模型做小，是被现实逼出来的。 旗舰模型能力最强，但它贵、它慢，而且必须把数据发到别人的服务器上。很多场景里，一个能力够用的小模型才是唯一能落地的选项。蒸馏，就是把小模型的能力尽量补上来的那个手段
- 「三个把模型往小里做的理由」：参数量小一个量级，一次推理要动用的算力通常也小一个量级。行业里的常见口径是，小模型的推理成本可以比旗舰模型低一到两个数量级。具体差多少，取决于尺寸、量化档位、批量大小和部署方式。别记死数字，记住这是量级上的差距，不是打个折
- 「最后的要点」：结论很直白。8B 这个尺寸量化之后，一块几年前的游戏显卡就跑得动；旗舰尺寸不管怎么量化都进不去。于是问题变成了另一个： 小尺寸的能力，能不能补上来
最后的「最后的要点」把讨论落到「结论很直白。8B 这个尺寸量化之后，一块几年前的游戏显卡就跑得动；旗舰尺寸不管怎么量化都进不去。于是问题变成了另一个： 小尺寸的能力，能不能补上来」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。