03.srt

1
00:00:00,000 --> 00:00:04,736
字幕校对:米哈游天下第一

2
00:00:04,736 --> 00:00:06,400
哈喽大家好

3
00:00:06,400 --> 00:00:08,720
今天ZOMI带来一节不一样的课

4
00:00:08,720 --> 00:00:11,280
虽然还在AI芯片的基础里面

5
00:00:11,280 --> 00:00:15,200
但是今天来通过CPU去看看计算的本质

6
00:00:15,200 --> 00:00:16,840
计算的工作原理

7
00:00:16,840 --> 00:00:19,520
这也是ZOMI觉得最有意思的一节

8
00:00:19,520 --> 00:00:22,880
现在处在的位置还是在AI芯片基础

9
00:00:22,880 --> 00:00:25,680
在上一节里面给大家去普及了一下

10
00:00:25,680 --> 00:00:28,120
通用处理器CPU的历史和发展

11
00:00:28,120 --> 00:00:29,960
最后看看它们的指令集架构

12
00:00:29,960 --> 00:00:33,920
接着今天来到了CPU里面非常重要的一节

13
00:00:33,920 --> 00:00:37,240
从数据看CPU的计算

14
00:00:37,240 --> 00:00:40,280
其实很多时候大家关注的是计算

15
00:00:40,280 --> 00:00:42,040
算力FLOPs

16
00:00:42,040 --> 00:00:45,200
但是实际上当如果深入到Kernel

17
00:00:45,200 --> 00:00:47,440
当深入到整个计算的本质的时候

18
00:00:47,440 --> 00:00:49,560
可能关注的点就会不一样了

19
00:00:49,560 --> 00:00:51,760
会更关注数据在哪里

20
00:00:51,760 --> 00:00:54,600
数据怎么跟计算相交互

21
00:00:54,600 --> 00:00:57,240
数据怎么充分的发挥算力

22
00:00:57,240 --> 00:00:59,400
通过数据看CPU的计算

23
00:00:59,400 --> 00:01:01,360
了解了计算的本质之后

24
00:01:01,360 --> 00:01:04,320
就有了下一节通用图形处理器GPU

25
00:01:04,320 --> 00:01:06,880
还有AI作用芯片NPU

26
00:01:08,160 --> 00:01:10,960
现在又回到了经典的图里面

27
00:01:10,960 --> 00:01:14,400
横周坐标是代表算力的敏感度

28
00:01:14,400 --> 00:01:16,920
每次操作能够执行多少的数据

29
00:01:16,920 --> 00:01:19,880
而纵坐标是性能

30
00:01:19,880 --> 00:01:22,680
每一秒能够执行多少的操作

31
00:01:22,680 --> 00:01:24,720
可以看到随着P的增加

32
00:01:24,720 --> 00:01:26,000
P就是计算单元

33
00:01:26,000 --> 00:01:27,440
P增加了之后

34
00:01:27,440 --> 00:01:30,560
整体的计算的峰值肯定是越高的

35
00:01:30,560 --> 00:01:33,120
当然了计算单元不会无限制的增加

36
00:01:33,120 --> 00:01:35,320
肯定会有一个数量的限制

37
00:01:35,320 --> 00:01:38,120
所以当P数量增加到一定程度的时候

38
00:01:38,120 --> 00:01:40,960
就会遇到了一个理论的峰值

39
00:01:40,960 --> 00:01:43,280
左边的灰色的这个峰块

40
00:01:43,280 --> 00:01:47,480
就是带宽Bandwidth的一个约束

41
00:01:47,480 --> 00:01:50,120
而右边的这个就是计算的Bounded

42
00:01:50,120 --> 00:01:51,240
计算的约束

43
00:01:51,240 --> 00:01:55,800
可以看到中间会有一条非常之明确的线段

44
00:01:55,840 --> 00:01:58,000
或者中间有一个转折点

45
00:01:58,000 --> 00:02:02,800
那这个就是带宽跟计算最好的一个中位数

46
00:02:02,800 --> 00:02:04,360
随着计算单元的增加

47
00:02:04,360 --> 00:02:05,920
如果带宽跟不上

48
00:02:05,920 --> 00:02:09,280
那这个时候计算的增加是没有效果的

49
00:02:09,280 --> 00:02:13,040
因此需要寻求一个从带宽到PE

50
00:02:13,040 --> 00:02:16,160
到计算单元之间一个最好的平衡点

51
00:02:16,160 --> 00:02:18,680
也就是中间的这一个转折点

52
00:02:20,240 --> 00:02:23,240
那现在看一下一些业界的最新的进展

53
00:02:23,240 --> 00:02:28,160
下面这个图我是来自于AMD最新的一个演讲视频来去截取的

54
00:02:28,160 --> 00:02:30,800
可以看到服务器的整体性能的趋势

55
00:02:30,800 --> 00:02:34,200
基本上每2.4年就会翻一番

56
00:02:34,200 --> 00:02:38,000
整个服务器架构的性能是提升的非常的夸张

57
00:02:38,000 --> 00:02:40,960
这里面的性能主要提升的是指算力

58
00:02:40,960 --> 00:02:43,600
而这里面看看单个GPU的性能

59
00:02:43,600 --> 00:02:48,040
这个FLOPs基本上每2.2年也是有一个翻一番的速率

60
00:02:48,040 --> 00:02:50,280
从2005年到2025年

61
00:02:50,320 --> 00:02:52,520
预计计算的速率

62
00:02:52,520 --> 00:02:56,200
计算的峰值会非常非常的高

63
00:02:57,280 --> 00:03:01,560
接着现在其实已经来到了整个计算架构的黄金十年

64
00:03:01,560 --> 00:03:03,360
因为刚才谈到服务器

65
00:03:03,360 --> 00:03:03,880
GPU

66
00:03:03,880 --> 00:03:06,000
单算力都在不断的增长

67
00:03:06,000 --> 00:03:10,520
于是整体的计算的架构肯定会迎来新的黄金的十年

68
00:03:10,520 --> 00:03:12,640
而随着计算的架构的增长

69
00:03:12,640 --> 00:03:14,160
计算的速率的增长

70
00:03:14,160 --> 00:03:15,720
计算的FLOPs增长

71
00:03:15,720 --> 00:03:19,800
肯定也会迎来一个编译器的黄金的十年

72
00:03:19,800 --> 00:03:23,520
所以非常欢迎大家去看看这两个YouTube上面对应的视频

73
00:03:23,520 --> 00:03:26,200
去了解一下计算架构编译器的架构

74
00:03:26,200 --> 00:03:27,960
近期的一个发展情况

75
00:03:29,160 --> 00:03:31,440
现在来看看一个更有意思的数据

76
00:03:31,440 --> 00:03:33,960
就是超算中心的性能

77
00:03:33,960 --> 00:03:36,920
超算中心就不仅仅是指GPU

78
00:03:36,920 --> 00:03:38,240
以及CPU

79
00:03:38,240 --> 00:03:40,280
更多的是指超异构的架构

80
00:03:40,280 --> 00:03:42,680
除了单单CPU和GPU的算力的增长

81
00:03:42,680 --> 00:03:44,960
还有很多异构芯片的增长

82
00:03:44,960 --> 00:03:49,800
于是可以看到性能基本上是1.2年在进行翻一番

83
00:03:49,800 --> 00:03:54,720
从95年到24年的整体预测是非常非常的夸张

84
00:03:54,720 --> 00:03:59,720
将会从Exascale迈进Zettascale新的算力时代

85
00:04:00,720 --> 00:04:03,000
现在看一下大家都谈大模型

86
00:04:03,000 --> 00:04:07,280
训练大模型整体的时间是已经越来越长了

87
00:04:07,280 --> 00:04:10,440
网络模型从10B到1000B

88
00:04:10,440 --> 00:04:13,120
从百亿到千亿到万亿

89
00:04:13,160 --> 00:04:15,960
随着增长的不仅仅是算力

90
00:04:15,960 --> 00:04:19,920
还有内存和数据都在跨越式的增长

91
00:04:19,920 --> 00:04:23,880
而这个时候又迎来了一个新的趋势的预言

92
00:04:23,880 --> 00:04:25,880
就是逻辑电路的趋势

93
00:04:25,880 --> 00:04:28,880
从2008年开始迈进了纳米的时代

94
00:04:28,880 --> 00:04:31,040
2010年是在45纳米

95
00:04:31,040 --> 00:04:35,400
直到现在所处的是5纳米到4纳米量产的阶段

96
00:04:35,400 --> 00:04:37,520
未来可能还会进一步突破

97
00:04:37,520 --> 00:04:39,640
硅的极限接近2纳米

98
00:04:40,720 --> 00:04:42,960
随着制程的提高

99
00:04:42,960 --> 00:04:46,040
整体的算力也会不断的增长

100
00:04:46,040 --> 00:04:48,840
但这个时候ZOMI就有一个疑问了

101
00:04:48,840 --> 00:04:51,000
谁会真正的在乎算力呢?

102
00:04:51,000 --> 00:04:53,200
谁会真正在乎Flops呢?

103
00:04:53,200 --> 00:04:55,240
虽然我在跟客户交流的时候

104
00:04:55,240 --> 00:04:57,080
非常多人都会问

105
00:04:57,080 --> 00:04:59,560
你的硬件你的昇腾的算力到底是多少

106
00:04:59,560 --> 00:05:02,120
对比起英伟达的算力到底有多少区别

107
00:05:02,120 --> 00:05:03,520
很多时候我只能说

108
00:05:03,520 --> 00:05:06,480
峰值算力会比英伟达的要高

109
00:05:06,480 --> 00:05:09,360
而同期寒武纪、壁仞、百度、昆仑这些

110
00:05:09,360 --> 00:05:11,720
都在强调自己的峰值算力

111
00:05:11,840 --> 00:05:13,440
这个时候就非常有趣了

112
00:05:13,440 --> 00:05:15,400
我引入了另外一个新的话题

113
00:05:15,400 --> 00:05:18,080
像D1 chip是特斯拉发布的一片芯片

114
00:05:18,080 --> 00:05:20,320
它里面一发布就强调了

115
00:05:20,320 --> 00:05:23,200
它有非常之夸张的算力的峰值

116
00:05:23,200 --> 00:05:25,040
362TFLOPs

117
00:05:25,040 --> 00:05:28,160
还有226TFLOPs的FP32

118
00:05:28,160 --> 00:05:31,960
FP16的峰值算力非常非常的夸张

119
00:05:31,960 --> 00:05:34,560
而这里面看一下Graphcore里面的IPU

120
00:05:34,560 --> 00:05:37,600
也是非常强调它的峰值算力

121
00:05:37,600 --> 00:05:39,440
5.6PetaFLOPs

122
00:05:39,480 --> 00:05:40,880
还有11.2PetaFLOPs

123
00:05:40,880 --> 00:05:43,080
到它的一个集群POD的集群

124
00:05:43,080 --> 00:05:46,320
已经有了358.4PetaFLOPs

125
00:05:46,320 --> 00:05:49,160
整体的算力越来越夸张越来越大

126
00:05:49,160 --> 00:05:53,240
这个时候各大厂商都会去跟英伟达对比

127
00:05:53,240 --> 00:05:55,720
到底在FP32的计算里面

128
00:05:55,720 --> 00:05:57,560
它有2P-FLUX的算力

129
00:05:57,560 --> 00:06:00,520
同期英伟达只有156T-FLUX的算力

130
00:06:00,520 --> 00:06:02,640
整体的算力是它的12倍

131
00:06:02,640 --> 00:06:05,560
在AI计算里面英伟达有2.5PFLOP

132
00:06:05,560 --> 00:06:07,760
而整个Graphcore它有8PFLOP

133
00:06:07,760 --> 00:06:08,800
是它的三倍

134
00:06:08,840 --> 00:06:10,160
不管怎么样来看

135
00:06:10,160 --> 00:06:12,800
整体的峰值算力也是越来越高的

136
00:06:12,800 --> 00:06:15,200
大家都在强调峰值算力

137
00:06:15,200 --> 00:06:18,400
但是客户真正在乎的是算力吗?

138
00:06:18,400 --> 00:06:20,160
客户真正在乎的是Flops吗?

139
00:06:20,160 --> 00:06:22,520
是每秒能够运行多少算力吗?

140
00:06:25,760 --> 00:06:28,880
其实我觉得最重要的是物理定律

141
00:06:28,880 --> 00:06:30,920
还有硬件本身很大程度决定了

142
00:06:30,920 --> 00:06:33,720
对机器的编程的方式

143
00:06:33,720 --> 00:06:35,920
而机器的编程的方式不一样

144
00:06:35,920 --> 00:06:38,760
当深入到整个计算的本质的时候

145
00:06:38,760 --> 00:06:40,720
就会有一个更深的体会

146
00:06:40,720 --> 00:06:43,200
我的数据到底在哪里

147
00:06:43,200 --> 00:06:46,320
真正关心的可能是数据搬运

148
00:06:46,320 --> 00:06:48,720
我算得非常的非常的快

149
00:06:48,720 --> 00:06:50,760
但是我的数据来得及提供吗?

150
00:06:50,760 --> 00:06:53,000
如果我的数据来不及提供

151
00:06:53,000 --> 00:06:56,040
那可能永远都处于这个位置

152
00:06:56,040 --> 00:06:58,560
还达不到真正的峰值算力

153
00:06:58,560 --> 00:07:01,960
所以算力不一定是最重要的

154
00:07:01,960 --> 00:07:05,720
所以下面来到一个真正非常具有争议性的话题

155
00:07:05,720 --> 00:07:08,480
我觉得没有人真的会在意Flops

156
00:07:08,480 --> 00:07:11,680
就是每秒浮点运算的次数

157
00:07:11,680 --> 00:07:14,440
当然了Flops是跟机器的算力非常相关的

158
00:07:14,440 --> 00:07:16,440
所以很多客户在买机器的时候

159
00:07:16,440 --> 00:07:18,920
希望能够了解它到底有多少算力

160
00:07:18,920 --> 00:07:19,880
有多少Flops

161
00:07:19,880 --> 00:07:22,000
每秒能够执行的多快

162
00:07:22,000 --> 00:07:24,000
不过我真的是想告诉你

163
00:07:24,000 --> 00:07:26,680
这个不是真正应该关注的点

164
00:07:26,680 --> 00:07:28,200
因为真正关注的点

165
00:07:28,200 --> 00:07:30,560
重点不在这里面

166
00:07:30,560 --> 00:07:34,200
为什么ZOMI认为没有太必要去关心Flops呢?

167
00:07:34,200 --> 00:07:36,200
有多少倍的NV（NVIDIA）的比例呢?

168
00:07:36,200 --> 00:07:39,320
现在来看看CPU跟它的内存之间

169
00:07:39,320 --> 00:07:40,920
是什么样的一个关系

170
00:07:40,920 --> 00:07:44,520
首先内存会把它的数据传到CPU上面

171
00:07:44,520 --> 00:07:49,320
每秒钟假设大概能够传输200G的字节

172
00:07:49,320 --> 00:07:51,720
200G bytes per second

173
00:07:51,720 --> 00:07:53,160
而往上看一看

174
00:07:53,160 --> 00:07:57,840
CPU大概每秒钟能够进行2万亿次的双精度

175
00:07:57,840 --> 00:08:00,360
也就是Flops64的运算

176
00:08:00,360 --> 00:08:03,320
这个数看上去非常非常的夸张

177
00:08:03,320 --> 00:08:06,000
不过这个计算量对于CPU来说

178
00:08:06,000 --> 00:08:09,000
它只是一个非常经典典型的速率

179
00:08:09,000 --> 00:08:11,960
知道每一个FP64(口误)是8个字节

180
00:08:11,960 --> 00:08:15,440
内存每秒钟传输200G的字节

181
00:08:15,440 --> 00:08:20,520
也就是说每秒能够传输25Giga-FP64的数值

182
00:08:20,520 --> 00:08:22,240
这个数值对于内存来说

183
00:08:22,240 --> 00:08:26,920
就是每秒可以提供250亿个FP64的数据

184
00:08:26,920 --> 00:08:28,840
这是非常非常的多的

185
00:08:28,840 --> 00:08:34,200
但是CPU每秒确实能够处理2万亿个FP64的数据

186
00:08:34,200 --> 00:08:35,640
这两个值一对比

187
00:08:35,640 --> 00:08:38,560
就是左边的这条公式

188
00:08:38,560 --> 00:08:40,640
设备的计算强度

189
00:08:40,640 --> 00:08:43,160
Required Compute Intensity

190
00:08:43,160 --> 00:08:44,680
在上面这个例子

191
00:08:44,680 --> 00:08:49,360
就需要计算强度来维持整体的计算平衡

192
00:08:49,360 --> 00:08:53,960
也就是说对每一个数据都要进行80次操作

193
00:08:53,960 --> 00:08:55,440
否则PE

194
00:08:55,440 --> 00:08:56,240
CPU

195
00:08:56,240 --> 00:08:59,560
PU就会处于空闲的状态

196
00:08:59,560 --> 00:09:01,840
处于等待的状态

197
00:09:01,840 --> 00:09:05,880
如果CPU不能够做到对每个数据进行80次操作

198
00:09:05,880 --> 00:09:08,560
那这个时候还不如买一个更便宜的CPU

199
00:09:08,560 --> 00:09:09,760
它的FLOP数

200
00:09:09,760 --> 00:09:11,240
它的价格没有那么高

201
00:09:11,240 --> 00:09:14,160
每秒没有必要去计算那么多FLOPs

202
00:09:14,160 --> 00:09:15,600
不过话说回来

203
00:09:15,600 --> 00:09:18,840
每一个数据都进行80次操作

204
00:09:18,840 --> 00:09:20,240
这真的有必要吗

205
00:09:20,240 --> 00:09:25,160
真的会有算法对每一个数据都执行这么多遍操作吗

206
00:09:25,160 --> 00:09:27,200
我个人觉得在通用CPU里面

207
00:09:27,200 --> 00:09:29,280
这种情况是非常少见的

208
00:09:29,280 --> 00:09:32,600
实际上只有一种非常之特殊的情况

209
00:09:32,600 --> 00:09:34,040
AI

210
00:09:34,040 --> 00:09:36,040
图形图像

211
00:09:36,040 --> 00:09:37,880
也就是迎来了GPU

212
00:09:37,880 --> 00:09:39,600
可能有这种情况

213
00:09:39,600 --> 00:09:42,760
MBU AI芯片针对矩阵乘

214
00:09:42,760 --> 00:09:44,680
可能会有这种情况

215
00:09:44,680 --> 00:09:48,720
下面这里有一个不同处理器的速度的表格

216
00:09:48,720 --> 00:09:52,760
表中左边的这一部分是英特尔和AMD的

217
00:09:52,760 --> 00:09:55,240
右边那部分是英伟达的

218
00:09:55,240 --> 00:09:59,200
可以看到大家的计算强度或者计算比都是差不多的

219
00:09:59,200 --> 00:10:02,960
知道了不同的芯片都有非常强大的FLOPs

220
00:10:02,960 --> 00:10:04,840
就是计算能力

221
00:10:04,840 --> 00:10:06,360
也有很大的内存带宽

222
00:10:06,360 --> 00:10:09,360
去平衡计算和带宽之间中间的一个gap

223
00:10:09,360 --> 00:10:10,560
在CPU里面

224
00:10:10,560 --> 00:10:14,560
其实尽可能的希望能够降低整个计算的强度

225
00:10:14,560 --> 00:10:17,560
因为不可能有算法在每一次加载的时候

226
00:10:17,560 --> 00:10:20,960
都要执行接近100多次同样的计算

227
00:10:20,960 --> 00:10:22,480
针对同样的数据

228
00:10:22,480 --> 00:10:24,480
所以这是一个很奇怪的事情

229
00:10:24,480 --> 00:10:25,800
你啥意思

230
00:10:25,800 --> 00:10:26,760
我告诉你刘能

231
00:10:26,760 --> 00:10:27,160
我告诉你

232
00:10:27,160 --> 00:10:29,280
我自个儿你收拾你都卑服你 你信不信

233
00:10:29,280 --> 00:10:32,080
当FLOP的计算的速度的增加

234
00:10:32,080 --> 00:10:34,480
比内存带宽速度增加更快的时候

235
00:10:34,480 --> 00:10:36,760
计算强度就会去上升

236
00:10:36,760 --> 00:10:38,960
就好像左边英特尔这一款

237
00:10:38,960 --> 00:10:42,320
可以看到明显它的计算强度高了很多

238
00:10:42,320 --> 00:10:43,120
而这个时候

239
00:10:43,280 --> 00:10:45,440
就需要在程序算法上面

240
00:10:45,440 --> 00:10:47,120
不断的去做一些创新

241
00:10:47,120 --> 00:10:49,560
来保持尽可能的去塞满

242
00:10:49,600 --> 00:10:52,600
尽可能的去提升算力的利用率

243
00:10:53,360 --> 00:10:55,600
现在回到这个观点

244
00:10:55,600 --> 00:10:59,320
ZOMI其实并不是说非常的在乎FLOPs

245
00:10:59,320 --> 00:11:02,480
因为现在已经知道已经有足够多的FLOPs了

246
00:11:02,480 --> 00:11:03,280
GPU

247
00:11:03,280 --> 00:11:03,920
CPU

248
00:11:03,920 --> 00:11:07,920
NPU已经有足够多的计算的能力

249
00:11:07,920 --> 00:11:11,120
要做的是提升算力利用率

250
00:11:11,840 --> 00:11:14,080
如果不能够让CPU忙起来

251
00:11:14,080 --> 00:11:16,880
那情况就会变得非常的糟糕

252
00:11:16,880 --> 00:11:20,040
因此我觉得更应该去关注的是

253
00:11:20,040 --> 00:11:22,320
内存、带宽、还有时延

254
00:11:22,320 --> 00:11:25,400
尽可能的提升算力的利用率

255
00:11:26,160 --> 00:11:27,520
在后面的一个小视频里面

256
00:11:27,680 --> 00:11:29,400
我会给大家去分享一下

257
00:11:29,400 --> 00:11:31,520
CPU里面的内存带宽时延

258
00:11:31,520 --> 00:11:32,160
更加深刻

259
00:11:32,160 --> 00:11:35,320
或者我个人觉得更加有意思的一个简单的DEMO

260
00:11:35,320 --> 00:11:36,080
然后去看看

261
00:11:36,080 --> 00:11:40,360
什么时候才应该去满足内存和带宽时延的要求

262
00:11:40,360 --> 00:11:42,680
同时也可以提升算力利用率

263
00:11:43,440 --> 00:11:43,960
好了

264
00:11:43,960 --> 00:11:45,920
今天的内容就到这里为止

265
00:11:45,960 --> 00:11:46,560
谢谢各位

266
00:11:46,560 --> 00:11:47,400
拜了个拜

267
00:11:47,400 --> 00:11:49,400
卷的不行了卷的不行了

268
00:11:49,400 --> 00:11:51,400
记得一键三连加关注哦

269
00:11:51,400 --> 00:11:54,312
所有的内容都会开源在下面这条链接里面

270
00:11:54,312 --> 00:11:56,312
拜了个拜