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

2
00:00:06,382 --> 00:00:11,490
这一集要解决的，是一个让很多产品经理睡不好觉的问题。

3
00:00:11,490 --> 00:00:16,442
产品做得越好，用户用得越爽，账上的利润反而越薄。

4
00:00:16,442 --> 00:00:23,605
你花大力气把留存做上去了，结果最忠诚的那批用户，成了成本表上最贵的一行。

5
00:00:23,605 --> 00:00:27,632
看到月度消费账单的时候，多少会有点窒息。

6
00:00:27,632 --> 00:00:30,372
为什么产品经理要关心这件事。

7
00:00:30,372 --> 00:00:38,713
因为在人工智能产品里，推理成本不是财务月底才看的一张报表，它同时决定另外两件更要命的事。

8
00:00:38,713 --> 00:00:46,009
一个是用户要等多久才看到第一个字，另一个是同一张显卡到底能扛住多少并发。

9
00:00:46,009 --> 00:00:51,346
也就是说，成本、速度、质量，是同一枚硬币的三个面。

10
00:00:51,346 --> 00:00:57,692
这一集的内容，整理自作者团队的一次内部分享，讲的是词元降本增效。

11
00:00:57,692 --> 00:01:02,956
原文有十三节，我们挑出和产品经理决策最相关的五节来讲。

12
00:01:02,956 --> 00:01:07,307
所以这一集我们不看模型参数，看报价表。

13
00:01:07,307 --> 00:01:08,990
一共分五段。

14
00:01:08,990 --> 00:01:13,004
第一段，讲清楚这场对赌到底赌的是什么。

15
00:01:13,004 --> 00:01:18,425
第二段，讲词元是怎么数出来的，以及中文为什么天生就更贵。

16
00:01:18,425 --> 00:01:22,211
第三段，把报价表摊开，分出三个梯队。

17
00:01:22,211 --> 00:01:29,915
第四段和第五段，讲两道最容易被踩的定价断崖，一道按输出分档，一道按输入分档。

18
00:01:29,915 --> 00:01:33,930
最后一段，是可以直接带去开会的判断清单。

19
00:01:33,930 --> 00:01:37,259
看懂报价表还有一层额外的好处。

20
00:01:37,259 --> 00:01:41,574
你会第一次拥有和工程团队对话的共同语言。

21
00:01:41,574 --> 00:01:54,927
以前你提降本，工程师听到的是又要砍需求；现在你可以直接说，把这个任务的输出压到二百以内，或者把输入预算卡在三万二，这是一句有明确验收标准的话。

22
00:01:55,080 --> 00:01:58,323
作者给过一个很直观的简化账本。

23
00:01:58,273 --> 00:02:05,869
会员费固定，人均日调用十五次，单次平均上下文八千个词元，这个时候毛利还是正的。

24
00:02:05,869 --> 00:02:16,626
你只要把人均日调用次数往上拖，假装用户真的爱上了你的产品，月收入和词元成本这两条线就开始交叉，毛利一路往下掉。

25
00:02:16,626 --> 00:02:20,809
这就是那个交互演示想让你亲手感受的东西。

26
00:02:20,809 --> 00:02:22,708
先把账摆清楚。

27
00:02:22,708 --> 00:02:30,304
订阅制的逻辑很简单，会员费是固定的，不管用户每天问一次还是问一百次，你收的钱都一样。

28
00:02:30,304 --> 00:02:35,989
可成本不是这样走的，用户每多问一句，你就得多付一次推理的钱。

29
00:02:35,989 --> 00:02:41,302
收入是一条平线，成本是一条上坡线，两条线迟早会交叉。

30
00:02:41,302 --> 00:02:43,357
这就是对赌的含义。

31
00:02:43,357 --> 00:02:47,888
你的最忠诚用户，同时是你成本表上最贵的一行。

32
00:02:47,888 --> 00:02:54,294
靠涨价和限流去硬顶，只是缓兵之计，涨价伤留存，限流伤体验。

33
00:02:54,294 --> 00:02:58,705
真正的出路，是让每一次调用本身变得更便宜。

34
00:02:58,705 --> 00:03:02,455
再往深看一层，词元成本有三重身份。

35
00:03:02,455 --> 00:03:04,547
第一重，它是账单。

36
00:03:04,547 --> 00:03:13,417
每百万词元几块钱，乘上调用量就是月度支出，千万级的调用量之下，百分之十的浪费就是一个人的工资。

37
00:03:13,417 --> 00:03:15,496
第二重，它是延迟。

38
00:03:15,496 --> 00:03:23,153
输入越长，预填充越久，首字延迟就越高，用户还没看到第一个字，耐心已经消磨掉一半。

39
00:03:23,153 --> 00:03:25,364
第三重，它是质量。

40
00:03:25,364 --> 00:03:35,304
上下文塞得越满，有效信息越容易被废话淹没，高信噪比就等于高智能，所以省词元常常能顺带把效果提上去。

41
00:03:35,304 --> 00:03:39,246
要理解报价表，还得知道推理分两个阶段。

42
00:03:39,246 --> 00:03:44,883
第一个阶段叫预填充，负责吃进你写的输入，算力密集但可以并行。

43
00:03:44,883 --> 00:03:51,999
第二个阶段叫解码，负责一个字一个字往外吐，没法并行，受的是显存带宽的限制。

44
00:03:51,999 --> 00:03:57,648
输入价和输出价之间的差距，本质上就是这两种资源消耗的差距。

45
00:03:57,648 --> 00:04:00,556
所以这一章叫定价即架构。

46
00:04:00,556 --> 00:04:06,578
价格牌不是财务部门随手定的，它精确反映了推理算力的边际成本曲线。

47
00:04:06,578 --> 00:04:14,174
读懂定价结构，等价于读懂算力成本曲线，然后把你的应用架构，设计到便宜的那一侧。

48
00:04:14,330 --> 00:04:18,510
账单按词元结算，可词元到底是怎么数出来的。

49
00:04:18,460 --> 00:04:23,761
它既不是字符，也不是单词，而是基于统计规律生成的子词。

50
00:04:23,761 --> 00:04:26,477
早期的做法走过两个极端。

51
00:04:26,477 --> 00:04:36,044
一种是词级别分词，语义明确，但英语几十万个单词再加上词形变化，词表直接爆炸，还处理不了没见过的新词。

52
00:04:36,044 --> 00:04:44,157
另一种是字符级别分词，什么词都拆得开，但序列太长，单个字符信息量太低，推理效率极差。

53
00:04:44,157 --> 00:04:48,544
现代大模型选了中间路线，叫子词分词。

54
00:04:48,544 --> 00:04:58,917
常见的词保留成完整单元，不常见的词拆成有意义的片段，词表控制在三万二到二十万之间，既不爆炸，又什么都能表示。

55
00:04:58,917 --> 00:05:00,948
那词表是怎么来的。

56
00:05:00,948 --> 00:05:06,153
不是人工编的，是从语料里合并出来的，方法叫字节对编码。

57
00:05:06,153 --> 00:05:07,655
一共四步。

58
00:05:07,655 --> 00:05:13,689
先把语料全部拆成最小单位，对统一码文本先转成以字节为单位。

59
00:05:13,689 --> 00:05:17,186
然后统计所有相邻字节对的出现频率。

60
00:05:17,186 --> 00:05:21,681
接着把最频繁的一对合并成新符号，加进词表。

61
00:05:21,681 --> 00:05:25,455
最后反复迭代，直到词表达到预设大小。

62
00:05:25,455 --> 00:05:31,946
某开源模型的词表是三万二，某海外主流模型的词表是十万零二百七十七。

63
00:05:31,946 --> 00:05:34,590
这里有一条直接能用的结论。

64
00:05:34,590 --> 00:05:40,095
词表越大，你的文本越常见，词元就越少，账单就越薄。

65
00:05:40,095 --> 00:05:44,025
反过来，非拉丁语系要交一笔隐形的词元税。

66
00:05:44,025 --> 00:05:50,227
主流分词器的训练语料以英文为主，学到的合并规则高度偏向英语。

67
00:05:50,227 --> 00:05:56,225
同一个名字，英文写法是三个词元，中文写法是六个，韩文写法是七个。

68
00:05:56,225 --> 00:06:04,542
表达同样的语义，中文用户要多消耗两倍以上的词元，既多付了钱，又变相缩短了上下文窗口。

69
00:06:04,542 --> 00:06:09,121
所以估算预算的时候，千万别按英文经验拍脑袋。

70
00:06:09,121 --> 00:06:11,417
中文还有一个专属的坑。

71
00:06:11,417 --> 00:06:20,624
英文有天然的护栏，合并之前先按空格做预分词，合并只发生在单词内部，边界基本符合语言学直觉。

72
00:06:20,624 --> 00:06:25,672
中文没有空格，只能完全依赖统计共现频率来决定边界。

73
00:06:25,672 --> 00:06:34,891
于是，一段哪怕毫无逻辑的文本，只要在语料里重复出现千万次，就会被整个合并成一个不可分割的最小单元。

74
00:06:34,891 --> 00:06:45,972
最有名的例子是那句网络博客时代的高频留言，给主人留下些什么吧，它在词表里被强行合并成了独立单元，成了著名的故障词元。

75
00:06:45,972 --> 00:06:49,590
这不是段子，是统计逻辑的必然产物。

76
00:06:49,590 --> 00:06:56,465
选模型的时候，分词器效率也是一项成本参数，这一点经常被人忽略。

77
00:06:56,590 --> 00:07:01,912
把常用模型的定价摊到一张表上，会看到三个清晰的梯队。

78
00:07:01,862 --> 00:07:03,713
先说一句免责。

79
00:07:03,713 --> 00:07:16,357
下面提到的价格，都是作者团队当时拿到的折后协议价，只用来演示计算方法，各家牌价和折扣随时在变，真正选型之前，请去核对各家平台的实时报价。

80
00:07:16,357 --> 00:07:18,232
第一梯队是旗舰。

81
00:07:18,232 --> 00:07:23,653
代表是通义千问三的旗舰版，以及智谱四点六的长输出档。

82
00:07:23,653 --> 00:07:27,379
特点是输出昂贵，能力天花板高。

83
00:07:27,379 --> 00:07:33,821
留给复杂推理、代码生成、多模型仲裁这类答错了损失更大的任务。

84
00:07:33,821 --> 00:07:35,624
第二梯队是主力。

85
00:07:35,624 --> 00:07:40,131
代表是通义千问加强版和智谱四点五的轻量版。

86
00:07:40,131 --> 00:07:46,502
特点是性价比均衡，日常对话、检索问答、摘要归纳都扛得住。

87
00:07:46,502 --> 00:07:50,011
大部分请求，本来就应该落在这一层。

88
00:07:50,011 --> 00:07:51,958
第三梯队是走量。

89
00:07:51,958 --> 00:08:01,934
代表是通义千问的极速版，近乎免费，它的标准输入价是每百万词元零点零七五元，缓存输入价只有零点零一五元。

90
00:08:01,934 --> 00:08:09,566
数据清洗、意图分类、高频监控这类活可以随便跑，它也是给大模型打下手的最佳人选。

91
00:08:09,566 --> 00:08:16,069
对比一下，旗舰档的输入价是一点六元，输出价是六点四元，中间差了几十倍。

92
00:08:16,069 --> 00:08:20,636
分梯队的意义不在于省钱，而在于把钱花对地方。

93
00:08:20,636 --> 00:08:27,487
选型的原则可以压成一句话，能用便宜的绝不用贵的，但答错代价大的别省。

94
00:08:27,487 --> 00:08:34,651
作者还留了一个小练习，给出五个真实的业务场景，让你先猜该用哪个梯队，再揭晓答案。

95
00:08:34,651 --> 00:08:41,201
这个练习的价值在于训练直觉，因为真正上线的时候是没有标准答案给你抄的。

96
00:08:41,201 --> 00:08:44,074
表上还有一个容易被跳过的细节。

97
00:08:44,074 --> 00:08:50,828
缓存输入价普遍只有标准价的两成甚至更低，有的模型甚至直接给到零。

98
00:08:50,828 --> 00:08:58,292
这个巨大的差价能不能吃到，完全取决于你的架构设计，而不是取决于你会不会砍价。

99
00:08:58,292 --> 00:09:06,862
换句话说，同样的模型、同样的任务，两个人能跑出相差五倍的成本，差别就在有没有命中缓存。

100
00:09:06,862 --> 00:09:10,191
最后一条，也是最反直觉的一条。

101
00:09:10,191 --> 00:09:13,905
同一个模型内部，价格能差出两到三倍。

102
00:09:13,905 --> 00:09:19,891
所以真正值得盯的，不是选哪个模型，而是那些价格跳变的边界线。

103
00:09:19,891 --> 00:09:24,807
大部分成本事故的根源，是用旗舰去干走量的活。

104
00:09:24,960 --> 00:09:27,962
第一道断崖，来自智谱四点六。

105
00:09:27,912 --> 00:09:36,446
它的定价有个很特别的设计，不按输入长度分档，而是按输出长度分档，分界线画在二百个词元上。

106
00:09:36,446 --> 00:09:42,335
输出一百九十九和输出二百零一，适用的是两套完全不同的价格。

107
00:09:42,335 --> 00:09:43,850
具体涨多少。

108
00:09:43,850 --> 00:09:48,802
输出单价从每百万词元四元涨到七元，涨了七成五。

109
00:09:48,802 --> 00:09:53,381
更狠的是输入，从一元涨到一点五元，涨了五成。

110
00:09:53,381 --> 00:10:02,372
而最容易被忽略的一点是，只要输出超过了二百，前面那几千个词元的输入，也要按更高的价格重新结算。

111
00:10:02,372 --> 00:10:06,698
也就是说，输出多写两个字，整单回溯涨价。

112
00:10:06,698 --> 00:10:08,585
智谱为什么这么定。

113
00:10:08,585 --> 00:10:11,819
因为这反映的就是算力成本曲线。

114
00:10:11,819 --> 00:10:18,453
短输出非常轻量，解码压力小，键值缓存占用有限，几十毫秒就能跑完。

115
00:10:18,453 --> 00:10:27,564
可输出一旦变长，每多生成一个词元，缓存就多占一份显存，注意力就多算一轮，成本是非线性往上走的。

116
00:10:27,564 --> 00:10:33,970
厂商在用价格杠杆传递一个信号，鼓励短平快的任务，惩罚冗长的生成。

117
00:10:33,970 --> 00:10:35,905
看一个真实场景。

118
00:10:35,905 --> 00:10:42,528
从用户评论里提取结构化结果，情绪、方面、痛点、建议四个字段。

119
00:10:42,528 --> 00:10:49,222
提示词已经写得很规范了，问题在于你无法预知每条评论会提取出多少内容。

120
00:10:49,222 --> 00:10:55,340
简单的评论一百五十个词元就够，用户多吐槽两个点，就变成二百三。

121
00:10:55,340 --> 00:11:03,213
业务输出天然在一百五到二百三之间波动，而断崖恰好画在二百，这就是结构性的冲突。

122
00:11:03,213 --> 00:11:06,013
四种应对策略，各有代价。

123
00:11:06,013 --> 00:11:14,703
第一种是任务拆分，把提取拆成多次调用，每次只提取一两个字段，代价是调用次数增加、延迟上升。

124
00:11:14,703 --> 00:11:23,718
第二种是字段分级，核心字段实时提取，次要字段异步补充或者后处理，代价是架构复杂度上升。

125
00:11:23,718 --> 00:11:31,771
第三种是接受波动加监控，允许偶发跳档，但盯着整体分布看，成本可控但不是最优。

126
00:11:31,771 --> 00:11:41,170
第四种是模型降级，把价格敏感的高频任务切到极速版这类走量模型，代价是可能牺牲一点精度。

127
00:11:41,170 --> 00:11:46,819
核心的判断点只有一句，这个任务的输出，天然落在哪个区间。

128
00:11:46,819 --> 00:11:52,275
如果大部分请求在一百到一百五，偶发超过二百，那可以接受。

129
00:11:52,275 --> 00:12:03,177
如果分布的中位数就压在一百八到二百二，说明这个任务天然踩在断崖上，要么重新设计任务粒度，要么干脆换一个不按输出分档的模型。

130
00:12:03,177 --> 00:12:12,612
代码生成也是同理，一个二十行的函数轻松占掉一百多个词元，稍微复杂一点的修改建议，就会突破二百。

131
00:12:12,740 --> 00:12:15,947
第二道断崖，来自通义千问系列。

132
00:12:15,897 --> 00:12:22,988
它的分档逻辑和智谱完全不同，按输入长度计费，分界线在三万二和十二万八。

133
00:12:22,988 --> 00:12:31,125
最容易被忽略的计费细节是，越线之后不是超出部分加价，而是整个请求全量按高价档结算。

134
00:12:31,125 --> 00:12:43,024
假设输入是三万三千个词元，只比三万二多了一千，那全部三万三千都按每百万词元三点二元来算，不是前三万二按一点六、后一千按三点二。

135
00:12:43,024 --> 00:12:46,798
多出来的这一千，直接让整单成本翻倍。

136
00:12:46,798 --> 00:12:51,221
这个坑在检索增强生成的场景里尤其尖锐。

137
00:12:51,221 --> 00:12:55,825
假设检索回来五个文档片段，拼起来刚好三万三。

138
00:12:55,825 --> 00:13:01,281
这时候必须问一句，第五个片段对最终回答的贡献到底有多大。

139
00:13:01,281 --> 00:13:06,606
如果它是核心的法律条款、关键的技术参数，那可能值得。

140
00:13:06,606 --> 00:13:14,130
但如果它只是网页页脚、版权声明、重复的段落，甚至只是格式带来的多余换行符呢。

141
00:13:14,130 --> 00:13:18,409
一些粗放的检索策略，正在为垃圾付双倍的钱。

142
00:13:18,409 --> 00:13:25,500
解法是把三万二，从一个事后才发现的账单事故，变成一条写进代码的预算约束。

143
00:13:25,500 --> 00:13:38,565
拼提示词的逻辑不能是无脑拼接，而应该是先算好系统提示词和用户问题的词元数，再按相关性从高到低逐个加入片段，一旦超过预算，立刻停止。

144
00:13:38,565 --> 00:13:42,411
动态取前若干个，永远优于固定取五个。

145
00:13:42,411 --> 00:13:44,611
同样的思路可以推广。

146
00:13:44,611 --> 00:13:49,070
多轮对话里，历史接近三万时就触发压缩摘要。

147
00:13:49,070 --> 00:13:54,466
长文档处理，不要一次性塞进去，改成先分段再归并的模式。

148
00:13:54,466 --> 00:14:03,661
甚至可以在业务里直接画一条红线，三万二是预算上限，除非有极强的业务理由，否则绝不踏入高价区。

149
00:14:03,661 --> 00:14:05,704
把三家放在一起看。

150
00:14:05,704 --> 00:14:11,954
智谱是输出长度跳档，阈值二百，应对思路是任务拆分或者换模型。

151
00:14:11,954 --> 00:14:18,914
通义是输入长度跳档，阈值三万二和十二万八，应对思路是预算感知截断。

152
00:14:18,914 --> 00:14:27,027
还有一类的成本来自思维链在多轮里不断累积膨胀，应对思路是上下文清洗，用完即弃。

153
00:14:27,160 --> 00:14:31,412
最后把这集浓缩成五条能直接带去开会的判断。

154
00:14:31,362 --> 00:14:33,838
第一，先分梯队再选型。

155
00:14:33,838 --> 00:14:38,502
能用便宜的绝不用贵的，但答错代价大的别省。

156
00:14:38,502 --> 00:14:45,942
把三成以上的请求从旗舰降到主力，往往是最快的一笔降本，也是风险最小的一笔。

157
00:14:45,942 --> 00:14:50,846
判断标准不是任务难不难，而是答错了损失有多大。

158
00:14:50,846 --> 00:14:55,846
第二，报价表上真正要看的不是单价，是跳档的边界线。

159
00:14:55,846 --> 00:15:03,922
上线之前，把本任务的输出分布和输入分布各画一张直方图，看中位数离断崖有多远。

160
00:15:03,922 --> 00:15:10,497
中位数压在断崖上的任务，必须在设计阶段就解决，不能等账单出来再说。

161
00:15:10,497 --> 00:15:14,776
第三，把预算写进代码，而不是写进复盘。

162
00:15:14,776 --> 00:15:19,644
按相关性排序、到预算即停，动态取前若干个。

163
00:15:19,644 --> 00:15:25,761
这条改动通常半天就能上线，但它挡住的是整单翻倍的那种事故。

164
00:15:25,761 --> 00:15:30,064
第四，中文用户天然要多交一倍以上的词元税。

165
00:15:30,064 --> 00:15:36,386
估算预算、估算上下文窗口、估算延迟的时候，都别拿英文经验拍脑袋。

166
00:15:36,386 --> 00:15:43,069
第五，记住省词元的本质不是抠门，它同时优化账单、延迟和质量三件事。

167
00:15:43,069 --> 00:15:48,802
高信噪比本身就是高智能，这句话值得写在团队的工程规范第一页。

168
00:15:48,802 --> 00:15:51,459
最后补一句心态上的提醒。

169
00:15:51,459 --> 00:15:58,922
降本这件事很容易被做成运动，一紧张就全局限流、全员降级，用户体验先塌了。

170
00:15:58,922 --> 00:16:06,867
正确的姿势是把它当成架构约束，写进设计文档的第一页，而不是写进季度复盘的最后一页。

171
00:16:06,867 --> 00:16:14,019
定价即架构，说的是价格牌上的每一道线，最终都会变成你系统里的一个分支判断。