蒸馏的代价 · 本地能跑多大 · Ollama 与 LM Studio 上手

本集对应课程：开源专题 ·《蒸馏的代价：模型正在变得越来越像》《你的电脑能跑多大的模型》《Ollama 与 LM Studio 怎么上手》

音频与本文配套，本文为文字版深度解读，可独立阅读。

一句话速览

蒸馏让学生学老师，而学生学到的是老师的全部——本事、口癖、偏见、身份认知一起继承。当整个行业向少数几个老师学习，多模型交叉验证可能是假的。后半段动手：一个乘法算清显存，两个工具十分钟跑通本地模型。

---

能力地图

本集横跨两个主题，一张图看清全貌：

主题	核心问题	关键结论	对应工具/动作
蒸馏的代价	学生向老师学，学到了什么	学到的是全部：本事 + 口癖 + 偏见 + 身份认知	查模型卡的底座血缘
蒸馏的代价	生态集中会怎样	20 万衍生模型共享同一批底层假设 = 单点依赖	多模型冗余要选底座不同的组合
蒸馏的代价	交叉验证还成立吗	血缘同源 → 在同一个地方一起错，交叉验证可能是假的	别把安全感建在厂商名字不同上
本地部署	我的机器能跑多大	显存 ≈ 参数量 × 精度系数（系数已含 KV Cache）	一张表 + 一个乘法
本地部署	量化损失掉在哪	连续权重被舍入到有限档位，损失不均匀	长链条任务：小一号跑 INT8 > 大一号跑 INT4
本地部署	选什么硬件	NVIDIA 拼速度，Apple 拼容量	显存大小 > 显卡贵贱
本地部署	怎么跑起来	Ollama（命令行）/ LM Studio（图形界面）	标签三段式 + 三个常见坑

---

一、先看研究怎么说

论文	作者 / 编号	核心发现
Generative Monoculture in Large Language Models	Wu & Black · arXiv:2407.02209 · 2024	多个模型基于相同底座蒸馏后，输出多样性显著下降。书评撰写、代码生成等本该有多种合理答案的任务上，不同模型结果高度趋同。作者用「单一文化」形容此状态
Measuring and Understanding LLM Identity Confusion	Xu et al. · arXiv:2411.10683 · 2024-11	覆盖 27 个模型，25.93% 存在身份混淆——被问「你是谁」时错误声称自己是另一个模型。作者指出这类错误对用户信任的伤害比一般逻辑错误更大

两篇论文均可在 arXiv 公开检索，编号如上。核对日期 2026-08-07。

行业争议（仅陈述存在，不作事实认定）

蒸馏别人家的模型是否越界，目前没有共识，但已有公开指控。这些都是一方的指控，被指控方并未承认，也没有第三方机构给出裁定。

放在这里是为了说明：这个领域的边界还在形成中。各家的服务条款大多禁止用自家输出去训练竞品，但技术上很难取证。

---

二、三个你自己就能观察到的症状

#	症状	典型表现
1	口癖被整批继承	某些句式在头部模型上高频出现后，在大量模型中同时冒出，成为识别 AI 写作的指纹
2	格式怪癖被继承	有的模型习惯在中文里给名词补英文标注，学它的模型也跟着写，哪怕场景完全不需要
3	连身份都学过去	问一个模型它是谁，它报出的是老师的名字

提示1：这不是 bug，是必然结果

训练数据是老师的输出，老师怎么说话，学生就怎么说话。你没法只继承能力而不继承习惯——因为在训练数据里，这两样东西根本分不开，没有一把刀能把它们切开。

---

三、生态越集中，交叉验证越可能是假的

某个开源系列的衍生模型数量已超过 20 万个。

• 从生态角度看：这是影响力的证明
• 换个角度看：20 万个模型共享同一批底层假设

底座模型里的偏见、知识盲区、表达倾向，会沿着蒸馏链条一层层传下去。上游改一个训练策略，下游几万个模型跟着变。

这种结构在软件工程里有个熟悉的名字：单点依赖。20 万个模型，一个上游。

对产品最直接的影响

很多团队会同时调用两三个不同厂商的模型，让它们互相校验以降低出错概率。这套做法成立的前提是它们会犯不同的错。

如果这几个模型的血缘上溯到同一个老师，它们很可能在同一个地方一起错，而且错得一模一样。

提示2：交叉验证此时给的不是安全感，是虚假的安全感

为什么特别难发现：真实产品用的是什么底座，多数厂商并不写在产品页上。你面前只有名字和宣传，而名字和宣传恰恰是最不能说明血缘的东西。

---

四、能做什么

1. 选型时查一下血缘。 模型卡里通常会写明底座是什么。做多模型冗余设计时，优先选底座不同的组合，而不是只看厂商名字不同。
2. 产品差异化别建在模型层。 如果竞争力来自「我们的回答质量更好」而血缘相近，这个优势不牢固。真正的差异通常来自数据、工作流和对场景的理解。
3. 把口癖当成需要治理的问题。 有品牌调性要求时，默认输出大概率带着上游的表达习惯。要靠提示词约束和后处理去改，指望换个模型通常没用——因为它们都这样。

---

五、你的机器能跑多大：一个乘法

需要的显存（GB） ≈ 参数量（B） × 精度系数

举例：8B 模型跑 INT4 → 8 × 0.65 ≈ 5.2 GB

提示3：系数里已经含了 KV Cache，别再乘一次余量

单纯装载权重的话，INT4 每个参数占 0.5 字节，8B 模型只要 4 GB。但模型跑起来还要额外一块地方存放对话过程中积累的中间状态——即 KV Cache。

系数里已经含了这部分开销，所以不要在外面再乘一次余量，否则会算出没有机器跑得动的结论。

很多人在网上看到的显存估算之所以离谱到不可用，就是因为重复乘了余量。

四个精度档位

档位	说明
FP32	全精度。基本只在训练时用，本地推理没人这么跑
FP16	半精度。模型发布时的原始格式，质量的基准线
INT8	体积减半，质量损失通常察觉不到。显存够的话是稳妥选择
INT4	体积只有原来的 1/4。多数日常任务上感受得到但可接受，本地跑最常用

量化是把本地部署门槛拉低最有效的一招：一张 8GB 显卡跑不动 FP16 的 8B 模型，换成 INT4 就轻松了。

---

六、量化的损失掉在哪

量化做的事只有一件：把原本连续的权重，四舍五入到有限个档位上。

• 位数决定档位数：4 位 = 16 档，8 位 = 256 档
• 档位越少，每个权重被挪动的距离越远

INT4 有兩处值得停一下：

1. 绝对值最小的几个权重被四舍五入后正好落在 0 上——这些参数在量化后的文件里不再起任何作用。模型里这样的小权重数量庞大，单个都不重要，合起来却承担着不少细节。
2. 刻度尺上的点变少了——那不是点丢了，是几个原本不同的权重被挤到了同一个档位上。16 个档位装不下那么多种取值，只能让它们共用一个数，原来的区别就没有了。

为什么挪一点点会影响回答质量

模型每写一个词，都是在一堆候选里挑分数最高的那个。大多数时候第一名遥遥领先，挪一点无所谓；但总有些时候前两名咬得很紧，一点点扰动就足以让它们换位。

推论：量化的损失不是均匀分布的。

• 日常问答、总结、改写 → INT4 基本够用（大多一两步出结果）
• 长链条推理、精确计算 → 前面错一步，后面全跟着错

要求高的场景，宁可选小一号的模型跑 INT8，也别选大一号的跑 INT4。

---

七、两种硬件，两套逻辑

	NVIDIA 显卡	Apple Silicon
显存	独占，标称多少基本能用多少	CPU 与 GPU 共享统一内存，系统不允许全部划给 GPU
折算	—	按可分配的约 75% 折算（保守估计，可通过 iogpu.wired_limit_max 调整）
速度	带宽高，生成速度快	带宽通常不及同价位独显，大模型上会慢一些
容量	硬上限，消费级目前顶到 32GB 左右	优势大，高配能装下消费级显卡碰不到的尺寸
生态	最成熟	Apple 芯片上有 MLX 引擎

一句话：NVIDIA 拼速度，Apple 拼容量。

反直觉的结论

决定你能跑多大模型的不是显卡多贵，是显存多大。

• RTX 4090（24GB）→ 停在 30B
• Mac 统一内存 128GB（约 96GB 可用）→ 能吃下 122B

后者的图形算力远不如前者，但模型装得进去，前者装不进去。

MoE 模型的特殊之处

标签里带 A 字样的是 MoE（如总参数 30B、每次激活 3B）。

显存按总参数算，速度按激活参数算。 30B 的 MoE 你得准备装下 30B 的显存，但跑起来速度接近 3B。占地方大，跑得快。

适用场景：显存充裕但希望响应快（如大内存 Mac）。反过来，显存紧张时同样占用下选稠密小模型更划算。

---

八、Ollama 与 LM Studio 上手

	Ollama	LM Studio
形态	命令行	图形界面
上手	一条命令下载并运行	内置模型浏览器，可看到体积与量化档位再决定
服务	装好后自动在后台提供	也能开本地服务器
接口	兼容 OpenAI 格式	同样兼容 OpenAI 格式
特色	适合接进自己的程序 / 习惯终端	会提示当前机器能否带得动；Apple 芯片支持 MLX 引擎

不用纠结，两个可以都装——下载的模型文件互不冲突。很多人用 LM Studio 挑模型和试效果，用 Ollama 跑常驻服务。

标签怎么读

标签通常有三段：模型系列名 / 尺寸 / 量化档位。尺寸那一段带 a 的就是 MoE（表示激活参数量）。

第一个坑：不写量化后缀时，工具拉的默认就是量化版（通常是 Q4 档），不是原始精度。很多人拿它跟官方接口的效果比，觉得开源模型不行——其实比的根本不是同一个东西。要对比质量，先确认两边跑的是不是同一个档位。

量化档位怎么选

档位	建议
Q4_K_M	默认选它。体积与质量的平衡点，绝大多数工具的默认档
Q5_K_M	写代码或做数学题选这档更保险——这两类任务对精度损失敏感
Q8_0	接近原始质量，体积也接近翻倍。显存充裕又想要最好效果时用
Q3 及以下	除非显存实在不够，否则不建议。掉分开始明显，不如换小一号模型跑高一档

一条实用规律：模型越大，量化越安全。 32B 量化到 Q4 掉的那点分，往往还是比 8B 跑 Q8 强。显存有限时，优先保尺寸，再考虑档位。

---

九、三个最常见的坑

1. 上下文开太大，显存直接爆。 最高频的问题。模型加载时显存看着够，一旦把上下文拉到几十 K，KV Cache 涨上来就崩了。现象是生成到一半卡死，或速度突然慢到不可用。→ 先按默认上下文跑通，需要长文再一档一档往上加。
2. 显存不够时不一定报错。 有些工具会自动把装不下的部分放到内存里靠 CPU 算。结果是能跑，但慢十倍以上。→ 发现生成速度慢得离谱，先检查是不是没完全装进显存。
3. 硬盘会被吃掉。 一个 8B 的 Q4 模型三四个 GB，试几个就是几十个 GB。→ 定期清理。

---

十、审查清单

• 你的多模型交叉验证里，几个模型的底座是否相同？（查过模型卡吗？）
• 你的产品差异化是不是建立在模型层？如果血缘相近，这个优势有多牢固？
• 产品有没有品牌调性要求？默认输出里有没有上游的口癖，靠什么治理？
• 估显存时有没有重复乘余量？（系数里已含 KV Cache）
• 长链条推理任务上是不是用了 INT4？（该不该换小一号跑 INT8？）
• 选 MoE 时是按总参数准备显存的吗？
• 对比本地与云端效果时，两边跑的是同一个量化档位吗？
• 显存有限时，是优先保了尺寸还是优先保了档位？
• 上下文是不是一上来就开到最大？
• 本地磁盘还剩多少？试过的模型清理了吗？

---

十一、约束说明

1. 论文口径：两篇论文均可在 arXiv 公开检索（编号 2407.02209、2411.10683），核对日期 2026-08-07。文中只转述其公开结论，不延伸推断。
2. 行业争议的性质：Anthropic 与 OpenAI 侧均有公开指控，但被指控方并未承认，亦无第三方裁定。本文仅陈述争议存在，不对指控本身作事实认定。
3. 量化实验的性质：档位数、步长、舍入误差、权重被挪到哪个值，是由量化的定义直接算出的；而候选概率、扰动幅度与推理链示意，是为说明机制构造的示意，不是任何模型的实测掉分。真实误差如何从权重传到输出，取决于模型结构与具体量化实现（分组大小、是否保留敏感层高精度等），没有通用公式。链条概率还假设各步独立，而真实推理前后相关。
4. 显存数字均为估算：实际占用还受上下文长度（最大变量）、并发数量、量化具体实现、系统占用影响。计算器给的是可行性判断，不是精确预算——结论是「勉强」时，就当作跑不动来准备。
5. 硬件折算：统一内存的 GPU 可用比例在 macOS 上可通过 iogpu.wired_limit_max 调整，75% 是默认情况下的保守估计，不是硬上限。
6. 模型标签：推荐只登记 Ollama 官方库里确实存在的标签，核对日期 2026-08-07，来源 ollama.com/library。可用标签会随版本更新，实际拉取前建议到对应模型的 tags 页确认。
7. 本集不含题库内容：课程中的选型演示产品为虚构（名字、公司、宣传全为假，现实中不存在），本集不引用其名称。

---

十二、可带走的原则

1. 蒸馏继承的是全部，不是能力子集。 别指望只挑好的继承——训练数据里能力与习惯分不开。
2. 血缘比厂商名字重要。 多模型冗余要选底座不同的组合；厂商名字不同几乎不说明任何问题。
3. 差异化建在数据、工作流和场景理解上，不要建在模型层。
4. 估显存只乘一次系数。 系数已含 KV Cache，重复乘余量会得出没人能跑动的结论。
5. 宁可小一号跑 INT8，别大一号跑 INT4——长链条任务上损失不均匀，前面错一步后面全错。
6. 显存大小比显卡贵贱更能决定上限。 显存有限时优先保尺寸，再考虑档位。
7. 对比效果前先对齐量化档位，否则你比的根本不是同一个东西。

---

*来源：xueai.miyang.cn（小山学堂 · 洛小山《学 AI 产品，从入门到精通》）*