1
00:00:00,100 --> 00:00:06,432
本内容改编自小山学堂《学 AI 产品，从入门到精通》，为二次演绎配音版。

2
00:00:06,382 --> 00:00:09,435
这一集解决两个很实际的问题。

3
00:00:09,435 --> 00:00:18,665
第一个偏判断，当整个行业都在向少数几个老师学习的时候，模型会变得越来越像，这件事对你的产品意味着什么。

4
00:00:18,665 --> 00:00:25,733
第二个偏动手，你的机器到底能跑多大的模型，以及怎么用十分钟把它真正跑起来。

5
00:00:25,733 --> 00:00:27,307
先说第一个。

6
00:00:27,307 --> 00:00:31,995
蒸馏这个词听着中性，但它有个容易被忽略的副作用。

7
00:00:31,995 --> 00:00:41,286
让学生学老师，学生学到的是老师的全部，本事、口癖、偏见，甚至对自己身份的认知，全都一起学过去。

8
00:00:41,286 --> 00:00:43,930
这不是可以挑着继承的东西。

9
00:00:43,930 --> 00:00:54,927
后面我们会看到两组研究数据、三个你自己就能验证的症状，最后落到一个结论上，很多团队正在用的多模型交叉验证，可能是假的。

10
00:00:54,927 --> 00:01:09,062
后半段我们换到动手模式，先用一张表和一次乘法算清楚你的机器能吃下多大的模型，再讲清量化带来的损失到底掉在哪一步，最后用两个工具把它们真正跑起来。

11
00:01:09,062 --> 00:01:20,336
判断和动手这两件事看着不搭，其实有一条暗线连着，它们都在回答同一个问题，你以为你得到的，和你真正得到的，是不是同一个东西。

12
00:01:20,500 --> 00:01:22,481
先看研究怎么说。

13
00:01:22,431 --> 00:01:31,710
有一篇讲生成式单一文化的论文，作者是 Wu 和 Black，二零二四年挂在 arXiv 上，编号 2407.02209。

14
00:01:31,710 --> 00:01:38,140
研究发现，多个模型基于相同底座蒸馏之后，输出的多样性显著下降。

15
00:01:38,140 --> 00:01:46,698
在书评撰写、代码生成这类本来应该有很多种合理答案的任务上，不同模型给出的结果高度趋同。

16
00:01:46,698 --> 00:01:49,871
作者用单一文化来形容这个状态。

17
00:01:49,871 --> 00:01:58,777
另一篇覆盖二十七个模型，编号 2411.10683，发现其中百分之二十五点九三存在身份混淆。

18
00:01:58,777 --> 00:02:03,356
被问到你是谁的时候，错误地声称自己是另一个模型。

19
00:02:03,356 --> 00:02:06,541
这个数字不小，接近四分之一个。

20
00:02:06,541 --> 00:02:13,957
作者还指出一件更值得注意的事，这类错误对用户信任的伤害，比一般的逻辑错误更大。

21
00:02:13,957 --> 00:02:20,267
因为它动摇的是最基础的那一层，你连自己是谁都说不清，别的话还怎么信。

22
00:02:20,267 --> 00:02:24,101
两篇论文都能在 arXiv 上公开检索到。

23
00:02:24,101 --> 00:02:26,962
这里我还得提一句行业里的争议。

24
00:02:26,962 --> 00:02:38,344
蒸馏别人家的模型是否越界，目前没有共识，但已经有公开的指控，这些都是一方的指控，被指控方并未承认，也没有第三方机构给出裁定。

25
00:02:38,344 --> 00:02:45,159
把这件事放在这里不是为了评判谁，而是为了说明这个领域的边界还在形成中。

26
00:02:45,159 --> 00:02:51,650
各家的服务条款大多禁止用自家输出去训练竞品，但技术上很难取证。

27
00:02:51,796 --> 00:02:56,277
研究之外，有三个症状是你自己就能观察到的。

28
00:02:56,227 --> 00:02:58,919
第一个，口癖被整批继承。

29
00:02:58,919 --> 00:03:07,621
某些句式在一个头部模型上高频出现，之后就在大量模型里同时冒出来，成了识别 AI 写作的指纹。

30
00:03:07,621 --> 00:03:17,705
比如那种不仅仅是技术问题更是产品问题的句式，比如让我们深入探讨一下这个话题，比如值得注意的是这里有几个关键点。

31
00:03:17,705 --> 00:03:21,203
你大概都见过，而且一眼就能认出来。

32
00:03:21,203 --> 00:03:23,955
第二个，格式怪癖被继承。

33
00:03:23,955 --> 00:03:32,501
有的模型习惯在中文里给名词补上英文标注，学它的模型也跟着这么写，哪怕那个场景完全不需要。

34
00:03:32,501 --> 00:03:38,703
你在中文文档里看到一堆名词后面跟着括号和英文，多半就是这么来的。

35
00:03:38,703 --> 00:03:42,068
第三个最直白，连身份都学过去了。

36
00:03:42,068 --> 00:03:45,962
问一个模型它是谁，它报出的是老师的名字。

37
00:03:45,962 --> 00:03:49,316
这三个都不是 bug，是蒸馏的必然结果。

38
00:03:49,316 --> 00:03:50,974
原因很朴素。

39
00:03:50,974 --> 00:03:56,058
训练数据是老师的输出，老师怎么说话，学生就怎么说话。

40
00:03:56,058 --> 00:04:04,929
你没法只继承能力而不继承习惯，因为在训练数据里，这两样东西根本就分不开，没有一把刀能把它们切开。

41
00:04:04,929 --> 00:04:15,950
你可以要求一个模型不要在回答里说某个句式，但你没法在训练阶段只把那个句式剔除掉，因为它和老师的推理方式长在同一段文本里。

42
00:04:15,950 --> 00:04:21,119
所以这类问题只能在使用侧治理，不能指望在上游解决。

43
00:04:21,119 --> 00:04:30,217
想清楚这一点，你就不会把预算花在反复换模型上，那是在用错误的方式解决一个不可能在那一层解决的问题。

44
00:04:30,364 --> 00:04:34,015
接下来是这个副作用最伤产品的地方。

45
00:04:33,965 --> 00:04:38,437
某个开源系列的衍生模型数量已经超过二十万个。

46
00:04:38,437 --> 00:04:47,499
从生态角度看这是影响力的证明，但换个角度看，它同时意味着二十万个模型共享同一批底层假设。

47
00:04:47,499 --> 00:04:54,434
底座模型里的偏见、知识盲区、表达倾向，会沿着蒸馏链条一层层传下去。

48
00:04:54,434 --> 00:04:58,689
上游改一个训练策略，下游几万个模型跟着变。

49
00:04:58,689 --> 00:05:03,905
这种结构在软件工程里有个很熟悉的名字，单点依赖。

50
00:05:03,905 --> 00:05:06,574
二十万个模型，一个上游。

51
00:05:06,574 --> 00:05:11,610
对产品最直接的影响是，多模型交叉验证可能是假的。

52
00:05:11,610 --> 00:05:18,605
很多团队会同时调用两三个不同厂商的模型，让它们互相校验来降低出错概率。

53
00:05:18,605 --> 00:05:22,824
这套做法成立的前提是，它们会犯不同的错。

54
00:05:22,824 --> 00:05:30,925
如果这几个模型的血缘上溯到同一个老师，它们很可能在同一个地方一起错，而且错得一模一样。

55
00:05:30,925 --> 00:05:35,804
这时候交叉验证给你的不是安全感，是虚假的安全感。

56
00:05:35,804 --> 00:05:38,425
为什么这件事特别难发现。

57
00:05:38,425 --> 00:05:43,641
因为真实产品用的是什么底座，多数厂商并不写在产品页上。

58
00:05:43,641 --> 00:05:49,651
你面前只有名字和宣传，而名字和宣传恰恰是最不能说明血缘的东西。

59
00:05:49,651 --> 00:05:54,963
所以这一步得你自己主动去查，等厂商告诉你，多半等不到。

60
00:05:54,963 --> 00:06:03,413
我建议你现在就做一件事，把你正在用的几个模型的模型卡翻出来，看看它们的底座分别是什么。

61
00:06:03,413 --> 00:06:10,011
如果底座是同一个，那你手上那套交叉验证的置信度，需要重新估一遍。

62
00:06:10,156 --> 00:06:11,704
那能做什么。

63
00:06:11,654 --> 00:06:13,818
三条，都很具体。

64
00:06:13,818 --> 00:06:16,714
第一条，选型时查一下血缘。

65
00:06:16,714 --> 00:06:19,935
模型卡里通常会写明底座是什么。

66
00:06:19,935 --> 00:06:26,666
做多模型冗余设计的时候，优先选底座不同的组合，而不是只看厂商名字不同。

67
00:06:26,666 --> 00:06:32,339
厂商名字不同这件事，在蒸馏普及之后几乎不能说明任何问题。

68
00:06:32,339 --> 00:06:35,921
第二条，产品差异化不要建在模型层。

69
00:06:35,921 --> 00:06:43,361
如果你的竞争力来自我们的回答质量更好，而大家用的模型血缘相近，这个优势不牢固。

70
00:06:43,361 --> 00:06:50,536
真正的差异通常来自数据、工作流和对场景的理解，这三样才是别人抄不走的东西。

71
00:06:50,536 --> 00:06:54,154
第三条，把口癖当成需要治理的问题。

72
00:06:54,154 --> 00:07:00,596
如果你的产品有品牌调性要求，默认输出大概率会带着上游的表达习惯。

73
00:07:00,596 --> 00:07:08,012
这要靠提示词约束和后处理去改，指望换个模型解决通常没用，因为它们都这样。

74
00:07:08,012 --> 00:07:16,318
这一条最容易被忽略，因为大家习惯把输出风格当成模型的能力问题，其实它是血缘问题。

75
00:07:16,468 --> 00:07:19,494
判断的部分讲完，接下来动手。

76
00:07:19,444 --> 00:07:22,533
你的机器到底能跑多大的模型。

77
00:07:22,533 --> 00:07:24,673
结论其实就一个乘法。

78
00:07:24,673 --> 00:07:31,283
需要的显存，单位是 GB，约等于参数量，单位是 B，乘以一个精度系数。

79
00:07:31,283 --> 00:07:37,750
举个例子，八 B 的模型跑 INT4，八乘以零点六五，约等于五点二 GB。

80
00:07:37,750 --> 00:07:40,069
需要解释的是这个系数。

81
00:07:40,069 --> 00:07:46,644
单纯装载权重的话，INT4 每个参数占零点五字节，八 B 的模型只要四 GB。

82
00:07:46,644 --> 00:07:55,190
但模型跑起来还需要额外一块地方，用来存放对话过程中积累的中间状态，也就是前面讲过的 KV Cache。

83
00:07:55,190 --> 00:08:02,726
系数里已经含了这部分开销，所以不要在外面再乘一次余量，否则会算出没有机器跑得动的结论。

84
00:08:02,726 --> 00:08:10,839
这一句很重要，很多人在网上看到的显存估算之所以离谱到不可用，就是因为重复乘了余量。

85
00:08:10,839 --> 00:08:13,771
四个精度档位也顺便说清楚。

86
00:08:13,771 --> 00:08:17,329
FP32 是全精度，基本只在训练时用。

87
00:08:17,329 --> 00:08:22,654
FP16 是半精度，模型发布时的原始格式，质量的基准线。

88
00:08:22,654 --> 00:08:26,608
INT8 体积减半，质量损失通常察觉不到。

89
00:08:26,608 --> 00:08:32,329
INT4 体积只有原来的四分之一，多数日常任务上感受得到但可接受。

90
00:08:32,329 --> 00:08:44,240
本地跑最常用的是 INT4，它是把本地部署门槛拉低最有效的一招，一张八 GB 的显卡跑不动 FP16 的八 B 模型，换成 INT4 就轻松了。

91
00:08:44,240 --> 00:08:52,822
选档位的思路其实很简单，先看你的显存能吃下哪个尺寸，再在这个尺寸下尽量选高一档的量化。

92
00:08:52,822 --> 00:09:01,920
顺序不能反过来，先挑档位再挑尺寸，很容易挑到一个精度很高但能力很弱的模型，那不是你想要的。

93
00:09:02,068 --> 00:09:05,239
那精度掉了，究竟掉在哪一步。

94
00:09:05,189 --> 00:09:11,775
量化做的事情其实只有一件，把原本连续的权重，四舍五入到有限个档位上。

95
00:09:11,775 --> 00:09:18,266
位数决定了有多少个档位可用，四位就是十六档，八位是二百五十六档。

96
00:09:18,266 --> 00:09:21,859
档位越少，每个权重被挪动的距离越远。

97
00:09:21,859 --> 00:09:24,924
INT4 那一档有两处值得停一下。

98
00:09:24,924 --> 00:09:34,083
第一，绝对值最小的几个权重被四舍五入之后正好落在零上，这些参数在量化后的文件里不再起任何作用。

99
00:09:34,083 --> 00:09:40,417
模型里这样的小权重数量庞大，单个都不重要，合起来却承担着不少细节。

100
00:09:40,417 --> 00:09:43,145
第二，刻度尺上的点变少了。

101
00:09:43,145 --> 00:09:48,470
那不是点丢了，是几个原本不同的权重被挤到了同一个档位上。

102
00:09:48,470 --> 00:09:55,441
十六个档位装不下那么多种取值，只能让它们共用一个数，原来的区别就没有了。

103
00:09:55,441 --> 00:09:59,552
那权重挪一点点，为什么会影响回答质量。

104
00:09:59,552 --> 00:10:04,792
因为模型每写一个词，都是在一堆候选里挑分数最高的那个。

105
00:10:04,792 --> 00:10:08,903
大多数时候第一名遥遥领先，挪一点无所谓。

106
00:10:08,903 --> 00:10:14,984
但总有些时候前两名咬得很紧，这时一点点扰动就足以让它们换位。

107
00:10:14,984 --> 00:10:18,410
所以量化的损失不是均匀分布的。

108
00:10:18,410 --> 00:10:28,386
日常问答、总结、改写这类任务上 INT4 基本够用，它们大多一两步就出结果，就算某个词换了个近义词也不影响你读懂。

109
00:10:28,386 --> 00:10:34,744
但需要长链条推理、精确计算的任务不一样，前面错一步，后面全跟着错。

110
00:10:34,744 --> 00:10:41,234
要求高的场景，宁可选小一号的模型跑 INT8，也别选大一号的跑 INT4。

111
00:10:41,380 --> 00:10:43,385
再往下要看硬件。

112
00:10:43,335 --> 00:10:45,907
两种硬件是两套逻辑。

113
00:10:45,907 --> 00:11:00,402
NVIDIA 显卡这边，显存独占，标称多少基本就能用多少，带宽高，生成速度快，容量是硬上限，消费级卡目前顶到三十二 GB 左右，软件生态最成熟，遇到问题基本都能搜到解法。

114
00:11:00,402 --> 00:11:02,229
Apple Silicon 不一样。

115
00:11:02,229 --> 00:11:12,157
CPU 和 GPU 共享统一内存，系统不允许全部划给 GPU，估算时通常按可分配的约百分之七十五折算，这是保守估计。

116
00:11:12,157 --> 00:11:22,409
它的容量优势大，高配机型能装下消费级显卡碰不到的尺寸，但带宽通常不及同价位独显，大模型上生成速度会慢一些。

117
00:11:22,409 --> 00:11:26,316
一句话总结，NVIDIA 拼速度，Apple 拼容量。

118
00:11:26,316 --> 00:11:29,429
这里有个反直觉的结论值得记住。

119
00:11:29,429 --> 00:11:34,392
决定你能跑多大模型的不是显卡多贵，是显存多大。

120
00:11:34,392 --> 00:11:42,914
一张 RTX 4090 停在三十 B，而一台统一内存一百二十八 GB 的 Mac 能吃下一百二十二 B。

121
00:11:42,914 --> 00:11:48,707
后者的图形算力远不如前者，但模型装得进去，前者装不进去。

122
00:11:48,707 --> 00:11:51,436
还有一个坑专门留给 MoE 模型。

123
00:11:51,436 --> 00:11:57,169
标签里带 A 字样的是 MoE，比如总参数三十 B、每次激活三 B 那种。

124
00:11:57,169 --> 00:12:02,818
这类模型的规律是，显存按总参数算，速度按激活参数算。

125
00:12:02,818 --> 00:12:09,308
三十 B 的 MoE 模型你得准备装下三十 B 的显存，但它跑起来的速度接近三 B。

126
00:12:09,308 --> 00:12:11,520
占地方大，跑得快。

127
00:12:11,520 --> 00:12:21,929
所以 MoE 特别适合显存充裕但希望响应快的场景，反过来如果显存紧张，同样占用下选一个稠密的小模型更划算。

128
00:12:22,084 --> 00:12:23,933
最后是把它跑起来。

129
00:12:23,883 --> 00:12:27,572
两个工具，一个命令行一个图形界面。

130
00:12:27,572 --> 00:12:40,673
Ollama 是命令行的，一条命令下载并运行，装好后自动在后台提供服务，可以直接被程序调用，接口兼容 OpenAI 的格式，原来调用云端接口的代码改个地址就能用。

131
00:12:40,673 --> 00:12:56,771
LM Studio 是图形界面的，内置模型浏览器，能看到体积和量化档位再决定下不下，还会提示当前机器能不能带得动，对新手友好，在 Apple 芯片上支持 MLX 引擎，同样的模型速度会明显好于通用格式。

132
00:12:56,771 --> 00:13:02,624
不用纠结选哪个，两个可以都装，它们下载的模型文件互不冲突。

133
00:13:02,624 --> 00:13:04,932
标签怎么读也要说一句。

134
00:13:04,932 --> 00:13:10,148
标签通常有三段，模型系列名、尺寸、量化档位。

135
00:13:10,148 --> 00:13:12,757
尺寸那一段带 a 的就是 MoE。

136
00:13:12,757 --> 00:13:21,374
这里藏着第一个坑，你不写量化后缀的时候，工具拉的默认就是量化版，通常是 Q4 档，不是原始精度。

137
00:13:21,374 --> 00:13:28,057
很多人拿它跟官方接口的效果比，觉得开源模型不行，其实比的根本不是同一个东西。

138
00:13:28,057 --> 00:13:32,360
要对比质量，先确认两边跑的是不是同一个档位。

139
00:13:32,360 --> 00:13:34,415
档位怎么选也有规律。

140
00:13:34,415 --> 00:13:50,016
日常默认 Q4_K_M，写代码或者做数学题选 Q5_K_M 更稳，显存充裕又想要最好效果用 Q8_0，Q3 及以下除非显存实在不够否则不建议。

141
00:13:50,016 --> 00:13:54,511
还有一条实用规律，模型越大，量化越安全。

142
00:13:54,511 --> 00:14:00,461
三十二 B 的模型量化到 Q4 掉的那点分，往往还是比八 B 跑 Q8 强。

143
00:14:00,461 --> 00:14:04,908
所以显存有限时，优先保尺寸，再考虑档位。

144
00:14:04,908 --> 00:14:14,836
这条规律背后的道理跟前面那节是一致的，大模型的冗余更多，丢一点细节还有得剩，小模型本来就紧，再丢就真的没了。

145
00:14:14,836 --> 00:14:17,504
最后三个坑，都是高频的。

146
00:14:17,504 --> 00:14:29,680
第一，上下文开太大会直接爆显存，现象是生成到一半卡死，或者速度突然慢到不可用，先按默认值跑通，需要长文再一档一档往上加。

147
00:14:29,680 --> 00:14:44,202
第二，显存不够时不一定报错，有些工具会自动把装不下的部分放到内存里靠 CPU 算，结果是能跑但慢十倍以上，如果你发现生成速度慢得离谱，先检查是不是没完全装进显存。

148
00:14:44,202 --> 00:14:51,895
第三，硬盘会被吃掉，一个八 B 的 Q4 模型三四个 GB，试几个就是几十个 GB，定期清理。

149
00:14:51,895 --> 00:14:56,979
把这三条记住，本地跑模型这件事就基本不会翻车。

150
00:14:56,979 --> 00:15:05,500
最后留一个问题给你，你现在用的几个模型，底座是同一个吗，如果答案是不知道，那今天这一集就没白听。

151
00:15:05,500 --> 00:15:07,604
这一集就到这里。