04.srt

1
00:00:00,000 --> 00:00:04,500
字幕生成：BLACK 字幕校对：凝渊

2
00:00:05,525 --> 00:00:06,600
Hello,大家好

3
00:00:06,600 --> 00:00:09,000
不知不觉又回到了AI编译器的

4
00:00:09,000 --> 00:00:11,600
这个围绕AI这个系列来展开

5
00:00:11,600 --> 00:00:14,400
那聊到AI可能很多人就不怎么关注了

6
00:00:14,400 --> 00:00:17,800
我发现传统的内容反而关注的人越来越多

7
00:00:17,800 --> 00:00:18,600
我是ZOMI

8
00:00:18,600 --> 00:00:21,000
今天就跟大家去汇报一下

9
00:00:21,000 --> 00:00:23,400
关于AI编译器的一些挑战

10
00:00:23,400 --> 00:00:26,200
还有关于它的发展的一些未来的思考和洞察

11
00:00:26,200 --> 00:00:28,600
今天的这个内容也是AI编译器

12
00:00:28,600 --> 00:00:31,200
和传统编译器里面的最后一个小节

13
00:00:31,200 --> 00:00:34,600
那未来我希望能够跟大家去详细的展开

14
00:00:34,600 --> 00:00:36,600
还关于AI编译器通用架构

15
00:00:36,600 --> 00:00:38,800
就是它的架构里面的每一个pass

16
00:00:38,800 --> 00:00:40,000
每一个细节点

17
00:00:40,000 --> 00:00:41,800
那讲完这些技术点

18
00:00:41,800 --> 00:00:43,800
大家再回过头来去看一下

19
00:00:43,800 --> 00:00:45,600
整个AI编译器的通用架构

20
00:00:45,600 --> 00:00:47,200
你就可能会想得更明白

21
00:00:47,200 --> 00:00:50,000
或者有更好的新的思路也可以告诉我

22
00:00:50,000 --> 00:00:52,600
然后我也希望大家能够参与到Math4

23
00:00:52,600 --> 00:00:53,800
还有其他AI框架

24
00:00:53,800 --> 00:00:56,000
参与到真正的开源项目当中

25
00:00:56,000 --> 00:00:58,000
现在想看一些比较新的

26
00:00:58,000 --> 00:01:00,800
或者比较热门的一些AI编译器的一个对比

27
00:01:00,800 --> 00:01:01,800
下面这个图

28
00:01:01,800 --> 00:01:05,200
我是取自于之前给大家去安利过的一篇文章

29
00:01:05,200 --> 00:01:09,000
The Deep Learning Compiler A Comprehensive Survey

30
00:01:09,000 --> 00:01:11,600
这篇文章是对AI编译器的综述

31
00:01:11,600 --> 00:01:13,000
那其中有一块table

32
00:01:13,000 --> 00:01:15,400
现在打开这篇文章来看看

33
00:01:15,400 --> 00:01:17,000
在这篇文章的第二页

34
00:01:17,000 --> 00:01:18,800
就横向的对比了TVM

35
00:01:18,800 --> 00:01:19,600
nGraph

36
00:01:19,600 --> 00:01:20,800
TC Glow

37
00:01:20,800 --> 00:01:21,600
还有XLA

38
00:01:21,600 --> 00:01:23,800
五个AI编译器的区别

39
00:01:23,800 --> 00:01:26,600
XLA是谷歌推出的为TensorFlow

40
00:01:26,600 --> 00:01:28,800
还有JAX作为它的底层编译层的

41
00:01:28,800 --> 00:01:31,000
它主要的特性是把神经网络

42
00:01:31,000 --> 00:01:33,400
或者计算图打开变成小算子

43
00:01:33,400 --> 00:01:34,600
那基于这些小算子

44
00:01:34,600 --> 00:01:36,400
再做一些图算的融合

45
00:01:36,400 --> 00:01:38,600
然后一起去做一个编译的

46
00:01:38,600 --> 00:01:41,000
整体的设计主要是定义了几个IR

47
00:01:41,000 --> 00:01:44,000
例如HLO、LLVM IR来去实现的

48
00:01:44,000 --> 00:01:45,600
在编译器里面的所有的Pass

49
00:01:45,600 --> 00:01:47,800
都是手工的提前去指定的

50
00:01:47,800 --> 00:01:51,000
也就是通过人工去发现一些规律

51
00:01:51,000 --> 00:01:53,600
最后把这些规律汇总成为代码

52
00:01:53,800 --> 00:01:56,200
TVM作为一个端到端的深度学习编译器

53
00:01:56,200 --> 00:01:57,800
主要是用在推理场景

54
00:01:57,800 --> 00:01:59,600
当然了训练场景其实也可以使用

55
00:01:59,600 --> 00:02:02,000
这个项目是由CMU的助理教授

56
00:02:02,000 --> 00:02:03,800
陈天奇发起的

57
00:02:03,800 --> 00:02:05,000
作为一个AI编译器

58
00:02:05,000 --> 00:02:07,600
它跟所有的框架都是松果核的关系

59
00:02:07,600 --> 00:02:09,400
就是它可以对接到多个框架

60
00:02:09,400 --> 00:02:11,200
最重要的目的就是想去解决

61
00:02:11,200 --> 00:02:12,400
人工写Kernel的问题

62
00:02:12,400 --> 00:02:14,600
然后对多个不同的硬件平台

63
00:02:14,600 --> 00:02:16,800
低级层面的代码进行优化

64
00:02:16,800 --> 00:02:18,200
它里面分为两层

65
00:02:18,200 --> 00:02:19,000
一层是Relay层

66
00:02:19,000 --> 00:02:20,400
一层是TVM层

67
00:02:20,400 --> 00:02:21,800
而Relay层关注于图

68
00:02:21,800 --> 00:02:23,000
TVM层关注于算子

69
00:02:23,000 --> 00:02:26,000
而TVM里面就借鉴了halide的一个想法

70
00:02:26,000 --> 00:02:27,200
把Compute和Schedule

71
00:02:27,200 --> 00:02:28,200
就是我的计算

72
00:02:28,200 --> 00:02:30,800
还有我的调度分离的这种方案

73
00:02:30,800 --> 00:02:33,600
当然还有Facebook早期的一个项目TC

74
00:02:33,600 --> 00:02:36,400
不过很可惜的就是随着PyTorch的兴起

75
00:02:36,400 --> 00:02:38,200
TC这个项目在Facebook里面

76
00:02:38,200 --> 00:02:39,600
没有得到一个很好的重视

77
00:02:39,600 --> 00:02:41,600
而这个项目已经没有持续的更新了

78
00:02:41,600 --> 00:02:43,400
但是这个项目的很多idea

79
00:02:43,400 --> 00:02:44,800
它的一个Polyhedral Model

80
00:02:44,800 --> 00:02:46,400
就是多面体的技术

81
00:02:46,400 --> 00:02:47,600
去解决编译器的问题

82
00:02:47,600 --> 00:02:49,800
这个思想其实现在被MindSpore所继承

83
00:02:49,800 --> 00:02:51,400
或者MindSpore基于这个idea

84
00:02:51,400 --> 00:02:53,400
做了很多自己的创新

85
00:02:53,400 --> 00:02:54,600
有了AI编译器

86
00:02:54,600 --> 00:02:56,800
AI编译器的输入是计算图

87
00:02:56,800 --> 00:03:00,200
而计算图是这些AI框架所产生的

88
00:03:00,200 --> 00:03:02,800
包括MindSpore、TensorFlow、PyTorch、Paddle-Paddle

89
00:03:02,800 --> 00:03:04,400
等不同的AI框架

90
00:03:04,400 --> 00:03:06,400
都会去产生计算图

91
00:03:06,400 --> 00:03:08,200
对计算图不了解的同学们

92
00:03:08,200 --> 00:03:10,400
可以回头看一下计算图的系列

93
00:03:10,400 --> 00:03:11,800
有了计算图之后

94
00:03:11,800 --> 00:03:14,600
就去了解AI框架

95
00:03:14,600 --> 00:03:17,400
下面来看看AI编译器的挑战

96
00:03:17,400 --> 00:03:18,600
关于AI编译器的挑战

97
00:03:18,600 --> 00:03:19,800
其实有几条内容是

98
00:03:19,800 --> 00:03:22,400
摘之于金雪峰老师在知乎上面的一篇文章

99
00:03:22,400 --> 00:03:23,800
这里面我根据个人的理解

100
00:03:23,800 --> 00:03:25,200
做了一些修改和补充

101
00:03:25,200 --> 00:03:27,400
第一个就是动态Shape的问题

102
00:03:27,400 --> 00:03:29,600
这个问题在昇腾硬件上面

103
00:03:29,600 --> 00:03:31,800
对接到PyTorch动态图的时候

104
00:03:31,800 --> 00:03:33,200
非常的突出

105
00:03:33,200 --> 00:03:34,800
也是非常难解决的

106
00:03:34,800 --> 00:03:36,400
第二个就是MindSpore底层的

107
00:03:36,400 --> 00:03:37,400
AI编译器的时候

108
00:03:37,400 --> 00:03:40,400
去解决动态Shape也是花了不少的精力

109
00:03:40,400 --> 00:03:43,600
第二点就是PyTorch的编译的时候的静态化

110
00:03:43,600 --> 00:03:45,400
这个也是很难解决的问题

111
00:03:45,400 --> 00:03:47,600
第三点就是如何通过AI编译器

112
00:03:47,600 --> 00:03:51,000
去压榨更多或者去发挥更多的硬件的性能

113
00:03:51,000 --> 00:03:54,400
第四点就是如何处理神经网络的一些特性

114
00:03:54,400 --> 00:03:56,200
例如自动微分和自动并行

115
00:03:56,200 --> 00:03:59,600
第五点就是如何去兼顾易用性和性能

116
00:04:02,600 --> 00:04:04,400
下面来看看第一点

117
00:04:04,400 --> 00:04:07,200
就是动态Shape和动态计算图的问题

118
00:04:07,200 --> 00:04:09,200
那比较突出的就是动态Shape

119
00:04:09,200 --> 00:04:11,200
现在一些主流的AI编译器

120
00:04:11,200 --> 00:04:14,000
主要是针对静态Shape进行输入

121
00:04:14,000 --> 00:04:15,600
然后完成整个编译化的

122
00:04:15,600 --> 00:04:16,800
包括TVM

123
00:04:16,800 --> 00:04:19,600
后来TVM其实也推出了一些解决动态Shape的方案

124
00:04:19,600 --> 00:04:22,400
但一开始确实也只是面向于静态Shape

125
00:04:22,400 --> 00:04:24,800
当计算图里面含有空字流的时候

126
00:04:24,800 --> 00:04:26,800
也是一个很大的挑战

127
00:04:26,800 --> 00:04:28,200
例如在NLP任务里面

128
00:04:28,200 --> 00:04:31,400
我输入给网络模型的一个序列的长度是不固定的

129
00:04:31,400 --> 00:04:32,400
有些句子长一点

130
00:04:32,400 --> 00:04:34,000
有些句子短一点

131
00:04:34,000 --> 00:04:36,800
这个时候就会引起大量的动态Shape需求

132
00:04:36,800 --> 00:04:38,800
第三点就是有些AI任务

133
00:04:38,800 --> 00:04:42,200
例如检测模型的SSP金字塔的时候

134
00:04:42,200 --> 00:04:45,000
很难通过把动态Shape改成静态Shape

135
00:04:45,000 --> 00:04:46,600
然后去解决的

136
00:04:47,600 --> 00:04:50,800
第二个比较大的挑战就是Python数据语言的static

137
00:04:50,800 --> 00:04:52,000
就是它的静态化

138
00:04:52,000 --> 00:04:54,400
在AI编辑器业界最常用的一种方法

139
00:04:54,400 --> 00:04:56,400
就是通过JIT即时编译

140
00:04:56,400 --> 00:04:59,200
让Python程序执行一个静态的优化

141
00:04:59,200 --> 00:05:01,000
从而提升性能

142
00:05:01,000 --> 00:05:03,400
而业界做一个JIT的通常的方法

143
00:05:03,400 --> 00:05:07,000
第一点就是提供一个Python的JIT的虚拟机

144
00:05:07,000 --> 00:05:10,000
第二种就是通过修饰符的方式

145
00:05:10,600 --> 00:05:14,000
下面来展开理解一下Python去执行的时候

146
00:05:14,000 --> 00:05:17,000
首先拿到一个Python的原代码.py

147
00:05:17,000 --> 00:05:21,200
然后Python的编译器会对原代码进行一个编译的处理

148
00:05:21,200 --> 00:05:25,400
所以会看到编译处理完经常会看到一些字节码.pyc

149
00:05:25,400 --> 00:05:28,000
在文件夹里面去存着

150
00:05:28,000 --> 00:05:29,600
就是我运行一个.py的时候

151
00:05:29,600 --> 00:05:31,400
经常会出现一些.pyc

152
00:05:31,400 --> 00:05:33,200
一开始也是觉得莫名其妙的

153
00:05:33,200 --> 00:05:35,400
后来理解了Python的一个编译流程之后

154
00:05:35,600 --> 00:05:38,600
就搞懂了.pyc就是它的字节码

155
00:05:38,600 --> 00:05:40,400
然后产生完字节码之后

156
00:05:40,600 --> 00:05:42,600
就给编译器进行编译处理

157
00:05:42,600 --> 00:05:44,800
最后程序再进行执行的

158
00:05:44,800 --> 00:05:47,000
而Python在执行的时候有两种方式

159
00:05:47,000 --> 00:05:48,400
第一种就是产生一个字节码

160
00:05:48,400 --> 00:05:51,400
然后通过Python的虚拟机给硬件去执行

161
00:05:51,600 --> 00:05:54,600
第二种就是提供JIT即时编译的编译器

162
00:05:54,600 --> 00:05:55,800
然后产生一个机器码

163
00:05:55,800 --> 00:05:57,800
然后直接给硬件去执行

164
00:05:57,800 --> 00:06:00,600
所以说Python在执行的时候有两种执行方式

165
00:06:00,600 --> 00:06:02,600
而左边的这种是最通用的

166
00:06:02,800 --> 00:06:04,400
刚才提到的一点就是

167
00:06:04,400 --> 00:06:07,000
Python它提供一个JIT的虚拟机

168
00:06:07,000 --> 00:06:11,000
好像Cpython它就混合了编译还有解析的功能

169
00:06:11,000 --> 00:06:14,800
将Python的原代码直接翻译成一系列的中间字节码

170
00:06:14,800 --> 00:06:16,000
就是.pyc

171
00:06:16,000 --> 00:06:18,400
然后由Cpython的一个内部虚拟机

172
00:06:18,400 --> 00:06:21,000
然后不断的去执行Python的一些指令

173
00:06:21,000 --> 00:06:22,800
第二种就是pypy

174
00:06:22,800 --> 00:06:26,200
直接利用JIT的即时编译器来去执行Python的代码

175
00:06:26,200 --> 00:06:28,000
假设现在有一些Python的原代码

176
00:06:28,000 --> 00:06:31,200
我按一些Python原代码的快进行一个编译

177
00:06:31,200 --> 00:06:32,600
编译成字节码

178
00:06:32,600 --> 00:06:33,600
编译成字节码的时候

179
00:06:33,800 --> 00:06:37,000
JIT编译器去执行Python的原代码的时候

180
00:06:37,000 --> 00:06:40,400
实际上程序执行的是已经编译好的字节码

181
00:06:40,600 --> 00:06:43,200
刚才提到了Python静态化的第二种方案

182
00:06:43,400 --> 00:06:45,000
就是通过修饰符

183
00:06:45,000 --> 00:06:46,200
对于修饰符这种

184
00:06:46,200 --> 00:06:48,600
其实在计算图的系列里面

185
00:06:48,600 --> 00:06:51,400
其实已经简单的去提过了

186
00:06:51,400 --> 00:06:52,400
这里面有两种

187
00:06:52,400 --> 00:06:53,800
第一种就是Tracing Based

188
00:06:53,800 --> 00:06:56,200
类似于PyTorch的fx的功能

189
00:06:57,000 --> 00:06:58,600
第二种就是AST Transform

190
00:06:58,600 --> 00:07:00,200
基于原码的转换

191
00:07:00,200 --> 00:07:02,200
类似于PyTorch的JIT的功能

192
00:07:02,200 --> 00:07:06,000
可以看到这下面的左右都是PyTorch的代码

193
00:07:06,000 --> 00:07:10,200
而PyTorch fx就是Tracing Based的这种方式

194
00:07:10,200 --> 00:07:12,000
我前面加一个修饰符

195
00:07:12,000 --> 00:07:13,000
然后通过修饰符

196
00:07:13,200 --> 00:07:15,400
一条一条语句去做一个跟踪

197
00:07:15,400 --> 00:07:16,800
然后把它做一个翻译

198
00:07:16,800 --> 00:07:18,800
第二种就是AST Transform

199
00:07:18,800 --> 00:07:20,000
就是原码转换

200
00:07:20,000 --> 00:07:22,400
我现在先写了一个函数

201
00:07:22,400 --> 00:07:24,000
然后通过一个修饰符

202
00:07:24,000 --> 00:07:26,600
对刚才的函数进行一个原码转换

203
00:07:28,000 --> 00:07:32,200
PyTorch它是一个动态图表达非常灵活的一个AI框架

204
00:07:32,200 --> 00:07:33,600
在它的动态图方案里面

205
00:07:33,800 --> 00:07:36,200
它是没有任何AI编辑相关的功能

206
00:07:36,200 --> 00:07:38,000
但是为了提升执行效率

207
00:07:38,200 --> 00:07:41,800
所以PyTorch推出了fx,JIT不同的一些方案

208
00:07:41,800 --> 00:07:44,200
但这些方案多多少少都有一些问题

209
00:07:44,200 --> 00:07:45,400
不是说非常纯粹

210
00:07:45,400 --> 00:07:47,400
而在最新的PyTorch 2.0里面

211
00:07:47,400 --> 00:07:49,400
他们说已经解决了这个问题了

212
00:07:49,400 --> 00:07:52,600
所以我希望能够后面有点时间去分析

213
00:07:52,600 --> 00:07:55,800
PyTorch 2.0这一块机制到底是怎么运作的

214
00:07:56,800 --> 00:07:58,800
下面看回PyTorch Static

215
00:07:58,800 --> 00:08:00,800
就是静态化所遇到的一些挑战

216
00:08:00,800 --> 00:08:03,200
第一个就是类型的推导

217
00:08:03,200 --> 00:08:06,000
从动态语言去编译成一个静态语言

218
00:08:06,000 --> 00:08:08,200
肯定是会有很多类型的转换

219
00:08:08,200 --> 00:08:09,200
静态类型

220
00:08:09,200 --> 00:08:12,200
不一定把所有的动态类型都能够表达出来

221
00:08:12,200 --> 00:08:14,200
第二个就是控制流的表达

222
00:08:14,200 --> 00:08:16,000
就是if,else,while,for等控制流

223
00:08:16,000 --> 00:08:18,000
其实你很难通过静态图

224
00:08:18,000 --> 00:08:19,400
完完全全的表示的

225
00:08:19,400 --> 00:08:22,200
现在比较好的一种方案就是子图的展开

226
00:08:22,200 --> 00:08:25,600
第三种就是灵活的语言表达和数据类型的转换

227
00:08:25,600 --> 00:08:28,400
因为Python里面有非常多灵活的表示

228
00:08:28,400 --> 00:08:30,600
其实还是归根于第一个问题

229
00:08:30,600 --> 00:08:33,200
就是动态的类型怎么把它静态化

230
00:08:33,200 --> 00:08:35,800
第四个就是JIT的编译性能

231
00:08:35,800 --> 00:08:38,800
不管是Tracing Based还是AST Transform

232
00:08:38,800 --> 00:08:39,800
就是源码转换

233
00:08:39,800 --> 00:08:43,600
都需要额外增加编译的开销

234
00:08:43,600 --> 00:08:46,000
有编译肯定会损失性能

235
00:08:46,000 --> 00:08:47,600
既想提升性能

236
00:08:47,600 --> 00:08:49,600
但是又忍不住编译的开销

237
00:08:49,600 --> 00:08:51,400
这是个矛盾

238
00:08:51,400 --> 00:08:53,800
假设开发一个MindSpore的AI框架

239
00:08:53,800 --> 00:08:55,800
希望对接到不同的硬件上面

240
00:08:55,800 --> 00:08:57,400
但是不可能每个硬件

241
00:08:57,400 --> 00:09:00,600
自己都会去做一些开发和性能的优化

242
00:09:00,600 --> 00:09:03,800
所以这里面极度的去依赖于AI的编译器

243
00:09:03,800 --> 00:09:06,200
去发挥不同硬件的算力

244
00:09:06,200 --> 00:09:08,400
在面向专用硬件的AI编译器

245
00:09:08,400 --> 00:09:11,200
其实也是遇到了非常大的挑战

246
00:09:11,200 --> 00:09:14,000
例如性能的优化了依赖于图算的融合

247
00:09:14,000 --> 00:09:16,000
就是我把小算子合成一个大算子

248
00:09:16,000 --> 00:09:18,800
那我算得起来可能更快少了一些IO

249
00:09:18,800 --> 00:09:21,400
面向DSA第二个比较大的挑战

250
00:09:21,400 --> 00:09:22,800
就是优化的复杂度

251
00:09:22,800 --> 00:09:25,800
是随着硬件的复杂度而提升的

252
00:09:25,800 --> 00:09:28,600
现在的硬件会有标量、向量、张量

253
00:09:28,600 --> 00:09:30,000
还有一些加速的指令

254
00:09:30,000 --> 00:09:32,000
还有一些多级的存储结构

255
00:09:32,200 --> 00:09:34,600
所以说在做一些kernel的优化

256
00:09:34,600 --> 00:09:35,750
在写编译器的时候

257
00:09:35,750 --> 00:09:35,800
或者底层Codegen的时候

258
00:09:35,800 --> 00:09:37,750
或者底层Codegen的时候

259
00:09:37,800 --> 00:09:40,400
其实复杂度是从指数是增长的

260
00:09:40,400 --> 00:09:42,600
随着硬件的复杂度提升

261
00:09:42,600 --> 00:09:44,600
专用的优化也会提出来

262
00:09:44,600 --> 00:09:47,200
而这些专用的优化又不能做好一个泛化

263
00:09:47,200 --> 00:09:50,000
所以这里面其实是挺矛盾的

264
00:09:50,000 --> 00:09:52,600
第四点就是特殊的优化

265
00:09:52,600 --> 00:09:55,000
这里面以自动并行为例子

266
00:09:55,000 --> 00:09:56,800
现在大模型非常火

267
00:09:57,000 --> 00:09:58,200
包括Diffusion model

268
00:09:58,200 --> 00:09:59,600
LLM语言大模型

269
00:10:00,000 --> 00:10:01,800
其实你都离不开自动并行

270
00:10:01,800 --> 00:10:03,600
而自动并行你就会遇到一些

271
00:10:03,600 --> 00:10:05,400
内存墙、性能墙的问题

272
00:10:05,400 --> 00:10:07,000
所以业界面向Scale out

273
00:10:07,000 --> 00:10:09,200
就提出了很多并行的方式

274
00:10:09,200 --> 00:10:10,200
就多维孔和并行

275
00:10:10,200 --> 00:10:12,400
数据并行、战略并行、流水线并行

276
00:10:12,400 --> 00:10:15,200
Scale up会做一些重计算混合精度

277
00:10:15,400 --> 00:10:18,200
遇到最大的问题还是效率墙

278
00:10:18,200 --> 00:10:21,600
效率墙说起来感觉比较抽象

279
00:10:21,600 --> 00:10:23,200
其实简单的理解一下

280
00:10:23,200 --> 00:10:25,400
就是工程师需要去自动的

281
00:10:25,400 --> 00:10:27,400
去配置上面的这些算法

282
00:10:27,400 --> 00:10:29,000
那你要配置这些算法

283
00:10:29,000 --> 00:10:30,800
对算法工程师来说

284
00:10:30,800 --> 00:10:32,000
可能会比较轻松

285
00:10:32,000 --> 00:10:33,600
但对于系统工程师来说

286
00:10:33,600 --> 00:10:34,800
可能会比较陌生

287
00:10:34,800 --> 00:10:36,600
我连这些算法听都没听过

288
00:10:37,000 --> 00:10:38,200
所以说算法工程师

289
00:10:38,200 --> 00:10:40,400
跟系统工程师之间有一个gap

290
00:10:40,400 --> 00:10:42,000
怎么去解决人的问题

291
00:10:42,000 --> 00:10:43,600
去把人释放出来

292
00:10:43,600 --> 00:10:46,200
真正的去依赖于编译和优化

293
00:10:46,200 --> 00:10:47,800
去解决并行配置的问题

294
00:10:47,800 --> 00:10:49,200
未来AI框架

295
00:10:49,200 --> 00:10:51,000
能不能自动微分做得更好

296
00:10:51,000 --> 00:10:52,800
现在所提的自动微分

297
00:10:52,800 --> 00:10:55,200
还是基于反向传播的一阶梯导

298
00:10:55,200 --> 00:10:58,000
那未来HPC这种高性能场景

299
00:10:58,000 --> 00:11:00,800
怎么去解决高阶微分

300
00:11:00,800 --> 00:11:03,400
能不能会有更高效的方式

301
00:11:03,400 --> 00:11:05,400
而不是通过现在去模拟

302
00:11:05,400 --> 00:11:07,400
Hessian矩阵的方式去求解呢

303
00:11:07,400 --> 00:11:08,800
第五点挑战就是

304
00:11:08,800 --> 00:11:10,800
易用性和性能的兼顾

305
00:11:10,800 --> 00:11:13,400
其实现在跟AI框架的边界

306
00:11:13,400 --> 00:11:14,800
是不同的

307
00:11:14,800 --> 00:11:18,000
接着就是对用户透明性的问题

308
00:11:18,000 --> 00:11:19,200
虽然透明性这个词

309
00:11:19,200 --> 00:11:21,400
还是比较隐晦比较学术的

310
00:11:21,400 --> 00:11:22,400
简单的来说

311
00:11:22,400 --> 00:11:24,600
就是现在部分的AI编译器

312
00:11:24,600 --> 00:11:25,400
我直接说了

313
00:11:25,400 --> 00:11:28,200
就是TVM它并不是真正完全自动的

314
00:11:28,200 --> 00:11:30,400
它现在的一些性能的优化

315
00:11:30,400 --> 00:11:32,800
还是基于模板的实现

316
00:11:32,800 --> 00:11:34,000
那模板实现的越好

317
00:11:34,000 --> 00:11:35,200
它优化的越好

318
00:11:35,200 --> 00:11:37,800
后面TVM也会详细的去展开

319
00:11:37,800 --> 00:11:39,400
所以这里面听不懂也没关系

320
00:11:39,400 --> 00:11:40,600
大概了解一下

321
00:11:40,600 --> 00:11:42,000
后面回头再来看

322
00:11:42,000 --> 00:11:43,800
可能就会豁然开朗了

323
00:11:43,800 --> 00:11:45,200
关于透明性的第二点就是

324
00:11:45,200 --> 00:11:47,400
现在对AI编译器的

325
00:11:47,400 --> 00:11:48,400
一些抽象的pass

326
00:11:48,400 --> 00:11:49,600
或者抽象的优化

327
00:11:49,600 --> 00:11:52,000
没有办法很好的去满足新的硬件

328
00:11:52,000 --> 00:11:53,400
或者新的算子

329
00:11:53,400 --> 00:11:54,400
这个时候

330
00:11:54,400 --> 00:11:56,800
最近的Pytorch 2.0就推出一个特性

331
00:11:56,800 --> 00:11:59,200
就是我只支持250多个基础算子

332
00:11:59,200 --> 00:12:01,200
其他算子都使用Python

333
00:12:01,200 --> 00:12:02,600
去写底层的硬件

334
00:12:02,600 --> 00:12:04,400
我觉得这个特性还是很有意思的

335
00:12:04,400 --> 00:12:06,600
到时候可以跟大家一起解读一下

336
00:12:06,600 --> 00:12:08,800
后面就是关于性能的一个问题

337
00:12:08,800 --> 00:12:11,200
编译会有开销

338
00:12:11,200 --> 00:12:12,000
想象一下

339
00:12:12,000 --> 00:12:15,200
其实我以前是一个算法的工程师

340
00:12:15,200 --> 00:12:17,400
但是我其实并不喜欢用AI编译器

341
00:12:17,400 --> 00:12:19,600
因为我希望能够我一按个回车

342
00:12:19,600 --> 00:12:21,200
像Pytorch一样没有编译器

343
00:12:21,200 --> 00:12:23,400
我在调试的阶段并不关心我的性能

344
00:12:23,400 --> 00:12:26,400
我更关心我的模型能不能够跑得通

345
00:12:26,400 --> 00:12:28,600
但是我的开发跟部署的情况

346
00:12:28,600 --> 00:12:30,400
不是在同一个模式下面的

347
00:12:30,400 --> 00:12:32,200
这时候就推出了新的功能

348
00:12:32,200 --> 00:12:34,600
就是之前讲的动静统一

349
00:12:34,600 --> 00:12:36,400
在计算图系列里面

350
00:12:36,400 --> 00:12:38,400
在整体AI编译器结束之前

351
00:12:38,400 --> 00:12:40,200
我想再抛出几个问题

352
00:12:40,200 --> 00:12:43,200
跟大家一起去思考碰撞

353
00:12:43,200 --> 00:12:46,200
AI编译器现在处于一个高速发展的状态

354
00:12:46,200 --> 00:12:48,600
所以它有很多未知的问题

355
00:12:48,600 --> 00:12:50,400
等着一起去破解

356
00:12:50,400 --> 00:12:52,200
等着去发一些paper

357
00:12:52,400 --> 00:12:55,200
第一个问题就是说了stage 3的时候

358
00:12:55,200 --> 00:12:56,400
就在第三个阶段

359
00:12:56,400 --> 00:12:58,600
希望图算能够统一表达

360
00:12:58,600 --> 00:13:01,000
但是图和算子真的能够统一表达吗

361
00:13:01,000 --> 00:13:04,200
真的能够统一整个编译优化的流程吗

362
00:13:04,200 --> 00:13:07,000
而形成一个通用的AI编译器吗

363
00:13:07,000 --> 00:13:09,200
不管是训练大模型还是小模型

364
00:13:09,200 --> 00:13:11,600
都希望尽可能的去利用云

365
00:13:11,600 --> 00:13:13,400
去利用AI集群去训练

366
00:13:13,400 --> 00:13:15,000
让训练时间更短

367
00:13:15,000 --> 00:13:16,200
训练的更快

368
00:13:16,200 --> 00:13:18,400
但是一涉及到集群

369
00:13:18,400 --> 00:13:20,800
真的能够做到并行吗

370
00:13:20,800 --> 00:13:22,200
机器跟机器之间

371
00:13:22,200 --> 00:13:23,600
机器跟机柜之间

372
00:13:23,600 --> 00:13:25,000
机柜跟机柜之间

373
00:13:25,000 --> 00:13:26,400
网段跟网段之间

374
00:13:26,400 --> 00:13:29,000
有大量的问题等着去解决

375
00:13:29,000 --> 00:13:31,400
真的自动并行可行不

376
00:13:31,400 --> 00:13:34,600
AI芯片真的需要AI编译器吗

377
00:13:34,600 --> 00:13:36,600
没有AI编译器又如何呢

378
00:13:36,600 --> 00:13:38,600
像英伟达它就没有自己的AI编译器

379
00:13:38,600 --> 00:13:40,000
但是它卖的非常火

380
00:13:40,000 --> 00:13:41,600
它现在是业界的标杆

381
00:13:41,600 --> 00:13:44,200
它只有一个传统的NVCC的编译器

382
00:13:44,200 --> 00:13:47,600
去把CUDA kernel编译成GPU能执行的代码

383
00:13:47,600 --> 00:13:50,000
我觉得这个是个革命性的问题

384
00:13:50,000 --> 00:13:53,200
说不好不小心把自己给革命掉了

385
00:13:53,200 --> 00:13:54,200
最后的最后

386
00:13:54,200 --> 00:13:56,400
来看看AI编译器的未来

387
00:13:56,400 --> 00:13:58,600
虽然现在有充满着很多未知的问题

388
00:13:58,600 --> 00:14:00,400
但是未来还是很可观的

389
00:14:00,400 --> 00:14:02,200
未来的编译器的形态

390
00:14:02,200 --> 00:14:03,800
可能会分开推理和训练

391
00:14:03,800 --> 00:14:04,600
也讲了

392
00:14:04,600 --> 00:14:05,200
另外的话

393
00:14:05,200 --> 00:14:07,600
IR的形态可能会做一个统一

394
00:14:07,600 --> 00:14:08,200
另外的话

395
00:14:08,200 --> 00:14:09,800
希望能够做一个自动并行

396
00:14:09,800 --> 00:14:10,800
还有自动微分

397
00:14:10,800 --> 00:14:13,800
最后一个就是大家都很关心的

398
00:14:13,800 --> 00:14:15,800
kernel能不能够自动生成

399
00:14:15,800 --> 00:14:17,400
减少我的人工成本

400
00:14:17,400 --> 00:14:18,800
那这个就是未来

401
00:14:18,800 --> 00:14:21,800
希望去真正去解决的一些问题

402
00:14:21,800 --> 00:14:23,600
希望大家了解完这个系列之后

403
00:14:23,600 --> 00:14:25,400
能够参与到华为昇腾

404
00:14:25,400 --> 00:14:28,000
华为图灵解决方案的建设当中

405
00:14:29,300 --> 00:14:29,700
好了

406
00:14:29,700 --> 00:14:30,300
谢谢各位