02.srt

1
00:00:00,000 --> 00:00:03,823
字幕生成：qiaokai  字幕校对：A是传奇

2
00:00:05,350 --> 00:00:07,560
Hello,大家好,我是ZOMI	

3
00:00:07,560 --> 00:00:12,080
这里面ZOMI两个英文单词都是大写

4
00:00:12,080 --> 00:00:15,240
因为它是我中文名字的一个缩写

5
00:00:15,240 --> 00:00:20,600
今天我要给大家汇报的还是模型转换和优化这个内容里面

6
00:00:20,600 --> 00:00:23,480
在模型转换技术这个内容里面

7
00:00:23,480 --> 00:00:26,200
后面的更新频率应该会越来越慢

8
00:00:26,200 --> 00:00:27,200
因为很多知识

9
00:00:27,680 --> 00:00:29,627
其实在网上很难搜得到

10
00:00:29,627 --> 00:00:31,627
更多的是工程化的一些经验的总结

11
00:00:33,720 --> 00:00:36,880
这里面应该会分开两个视频给大家介绍的

12
00:00:36,880 --> 00:00:39,840
可以看一下主要有很多内容

13
00:00:40,400 --> 00:00:44,880
首先在第一个视频更多的是聚焦于一些工程理念和知识概念

14
00:00:44,880 --> 00:00:46,480
例如模型转换的挑战

15
00:00:46,480 --> 00:00:49,000
还有整体的架构应该长什么样子

16
00:00:49,000 --> 00:00:54,640
接着去看一看模型的序列化和反序列化的操作

17
00:00:54,800 --> 00:00:58,120
序列化的工作就是把其他AI框架的网络模型

18
00:00:58,120 --> 00:01:00,480
转换成为推进行的模型

19
00:01:01,240 --> 00:01:04,520
反序列化就是把已经保存下来的网络模型

20
00:01:04,520 --> 00:01:08,000
加载到内存当中给推进行去执行的

21
00:01:08,000 --> 00:01:11,360
接着会去介绍序列化和反序列化当中

22
00:01:11,360 --> 00:01:13,600
用的很多的两种格式

23
00:01:13,600 --> 00:01:15,440
一种是protobuffer

24
00:01:15,440 --> 00:01:17,280
一种是flatbuffer

25
00:01:17,280 --> 00:01:18,600
讲完这两个内容之后

26
00:01:18,840 --> 00:01:20,800
将会在下个内容里面

27
00:01:20,800 --> 00:01:24,480
来到一些比较内核的技术或者内核的内容

28
00:01:24,520 --> 00:01:27,000
就是自定义计算图的IR

29
00:01:27,000 --> 00:01:30,840
针对推力引擎的计算图的IR应该怎么定义

30
00:01:31,360 --> 00:01:34,040
然后第二个内容也是很重要的一块

31
00:01:34,040 --> 00:01:37,000
转换的流程和技术的细节

32
00:01:37,000 --> 00:01:40,440
流程和细节这个就是指导怎么去开发

33
00:01:40,440 --> 00:01:41,680
怎么去写代码的

34
00:01:43,520 --> 00:01:45,720
下面来到第一个正式的内容

35
00:01:45,720 --> 00:01:48,160
转换模块的挑战和架构

36
00:01:48,160 --> 00:01:49,440
其实挑战和架构

37
00:01:49,440 --> 00:01:53,360
在上一节里面已经详细的去给大家去汇报过

38
00:01:53,400 --> 00:01:55,640
今天简单的去罗列一下

39
00:01:56,800 --> 00:01:59,720
Converter这个模块其实有非常多的挑战

40
00:01:59,720 --> 00:02:03,640
第一个就是AI框架或者AI本身有非常多的模型

41
00:02:03,640 --> 00:02:05,720
而且有非常多的框架

42
00:02:05,720 --> 00:02:07,880
不同的框架有不同的知识格式

43
00:02:07,880 --> 00:02:10,920
而且需要支持非常多主流的网络模型

44
00:02:10,920 --> 00:02:12,560
AI发展的越来越多

45
00:02:12,560 --> 00:02:15,080
很多模型都是千奇百怪

46
00:02:15,080 --> 00:02:18,720
最后就是需要支持很多AI特有的一些特性

47
00:02:19,840 --> 00:02:21,560
为了应对上面的这些挑战

48
00:02:21,720 --> 00:02:24,720
所以设计了一个转换模块的整体的架构

49
00:02:24,720 --> 00:02:26,640
主要是由Graph Converter

50
00:02:26,640 --> 00:02:29,760
还有Graph Optimizer两个模块来去组成

51
00:02:29,760 --> 00:02:32,360
今天主要是围绕着Graph Converter

52
00:02:32,360 --> 00:02:35,240
就是图转换的模块

53
00:02:35,240 --> 00:02:36,640
下面可以看一下

54
00:02:36,640 --> 00:02:40,040
主要就是聚焦于上面的这坨内容

55
00:02:40,040 --> 00:02:42,760
每一个AI框架都会有自己的一个Converter

56
00:02:42,760 --> 00:02:46,960
最终都会汇聚成自己推理引擎的IR

57
00:02:48,040 --> 00:02:49,720
既然IR很重要

58
00:02:49,720 --> 00:02:52,640
看一下整个转换模块的工作流程当中

59
00:02:52,640 --> 00:02:55,640
可以看到左边的很多的不同的框架

60
00:02:55,640 --> 00:02:58,720
最后都会汇聚成自己的一个独立的IR

61
00:02:59,160 --> 00:03:00,680
转换模块的阶段

62
00:03:00,920 --> 00:03:03,680
统一了整个计算图的IR

63
00:03:03,880 --> 00:03:05,560
于是在优化模块的时候

64
00:03:05,560 --> 00:03:08,120
就可以通过统一的自定义的IR

65
00:03:08,120 --> 00:03:11,080
完成很多不同的计算图的优化的模式

66
00:03:11,080 --> 00:03:12,280
或者优化图的Path

67
00:03:12,280 --> 00:03:15,000
这个就是为什么需要自定义的IR

68
00:03:15,000 --> 00:03:17,560
为什么需要深入的去给大家讲解

69
00:03:17,560 --> 00:03:19,520
转换模块的作用

70
00:03:20,320 --> 00:03:22,760
下面来看一下第二个比较重要的内容

71
00:03:22,760 --> 00:03:26,200
就是模型的序列化和反序列化

72
00:03:26,440 --> 00:03:29,360
首先来了解一下模型的序列化的工作

73
00:03:29,600 --> 00:03:31,480
其实序列化很简单

74
00:03:32,240 --> 00:03:34,360
把模型在部署的时候

75
00:03:34,360 --> 00:03:36,320
怎么去把已经训练好的模型

76
00:03:36,320 --> 00:03:38,400
AI框架训练出来的模型

77
00:03:38,400 --> 00:03:40,480
把它存储起来

78
00:03:40,480 --> 00:03:42,280
给后续需要Fine Tuning

79
00:03:42,280 --> 00:03:44,000
或者推理的时候使用的

80
00:03:44,000 --> 00:03:47,240
而反序列化就是把刚才保存下来的

81
00:03:47,240 --> 00:03:49,320
网络模型的结构还有权重

82
00:03:49,800 --> 00:03:51,800
反序列到内存当中

83
00:03:51,800 --> 00:03:54,080
内存就变成一个具体的对象

84
00:03:54,080 --> 00:03:56,880
看一下下面的图

85
00:03:57,880 --> 00:03:59,280
在AI框架执行阶段

86
00:03:59,400 --> 00:04:01,480
写的很多网络模型的代码

87
00:04:01,480 --> 00:04:02,920
还有一些权重参数

88
00:04:03,040 --> 00:04:06,120
其实都变成内存的一个对象

89
00:04:06,120 --> 00:04:07,360
需要保存下来

90
00:04:07,360 --> 00:04:08,160
把权重

91
00:04:08,160 --> 00:04:09,600
把代码固化下来

92
00:04:09,600 --> 00:04:12,520
变成硬盘的一些具体的地址

93
00:04:12,880 --> 00:04:14,000
最后要加载的时候

94
00:04:14,160 --> 00:04:16,080
就变成需要反序列化

95
00:04:16,080 --> 00:04:17,640
回去内存对象

96
00:04:17,880 --> 00:04:19,800
这个就是一般的AI框架里面

97
00:04:19,800 --> 00:04:22,080
所使用的一个流程

98
00:04:23,960 --> 00:04:25,920
而在推理引擎也是相同的

99
00:04:25,920 --> 00:04:28,640
左边就是AI框架训练的一个网络模型

100
00:04:28,640 --> 00:04:29,880
把它序列化

101
00:04:29,880 --> 00:04:32,000
需要用推理引擎的序列化的API

102
00:04:32,000 --> 00:04:32,960
把它固化下来

103
00:04:32,960 --> 00:04:34,760
成为硬盘的数据

104
00:04:35,040 --> 00:04:36,680
在真正推理引擎执行的时候

105
00:04:36,800 --> 00:04:38,080
需要把一些数据

106
00:04:38,080 --> 00:04:39,880
反序列化成为内存的对象

107
00:04:40,080 --> 00:04:41,280
最后再去执行

108
00:04:41,280 --> 00:04:42,880
这个就是整体的流程

109
00:04:45,808 --> 00:04:48,048
下面来看一下序列化的分类

110
00:04:48,640 --> 00:04:50,800
实际上序列化的格式有很多种

111
00:04:50,800 --> 00:04:51,400
有XML

112
00:04:51,600 --> 00:04:51,920
JSON

113
00:04:52,120 --> 00:04:54,120
还有Protobuffer和flatbuffer

114
00:04:55,115 --> 00:04:58,115
而在AI框架或者AI的领域里面

115
00:04:58,115 --> 00:05:00,649
Protobuffer是用的最为广泛的

116
00:05:00,731 --> 00:05:02,211
可以看到下面这个图

117
00:05:02,460 --> 00:05:05,013
谷歌是protobuffer的一个发起者

118
00:05:05,171 --> 00:05:07,491
最后现在经常用的onix

119
00:05:07,957 --> 00:05:10,113
是Facebook和微软组成一个联盟

120
00:05:10,113 --> 00:05:12,233
一起去支持这种开放性的格式

121
00:05:13,035 --> 00:05:13,755
而另外一方面

122
00:05:13,755 --> 00:05:15,635
平时用的苹果很多AI功能

123
00:05:15,635 --> 00:05:18,035
包括Siri用的就是CoreML的格式

124
00:05:18,035 --> 00:05:20,155
而CoreML也是继承于Protobuffer

125
00:05:20,155 --> 00:05:21,675
进行自己一个魔改

126
00:05:21,675 --> 00:05:23,635
或者自己的一个修改定义的

127
00:05:25,492 --> 00:05:27,252
下面以一个简单的例子

128
00:05:27,252 --> 00:05:29,852
去看一下Pytorch的序列化的方式

129
00:05:30,372 --> 00:05:31,492
Pytorch的内部格式

130
00:05:31,692 --> 00:05:34,492
只是存储已经训好的网络模型的状态

131
00:05:34,492 --> 00:05:35,732
所谓的这些状态

132
00:05:35,732 --> 00:05:38,012
主要是包括权重了

133
00:05:38,012 --> 00:05:38,812
偏移了

134
00:05:38,812 --> 00:05:41,126
优化器的更新的参数

135
00:05:41,126 --> 00:05:44,486
更多的是对网络模型的权重参数信息

136
00:05:44,486 --> 00:05:46,206
进行加载和保存的

137
00:05:46,486 --> 00:05:49,086
其他参数其实也有非常的多

138
00:05:49,086 --> 00:05:50,726
只是不一一列举了

139
00:05:50,726 --> 00:05:51,406
另外的话

140
00:05:51,406 --> 00:05:52,766
像Pytorch的内部格式

141
00:05:52,966 --> 00:05:54,846
非常类似于Python里面的

142
00:05:54,846 --> 00:05:55,846
序列化的方式

143
00:05:55,846 --> 00:05:57,886
直接用pickle来去做的

144
00:05:57,886 --> 00:06:00,846
这个就是Pytorch原生的方式

145
00:06:01,000 --> 00:06:03,360
在代码里面就直接torch.save

146
00:06:03,360 --> 00:06:05,400
然后把网络模型

147
00:06:05,800 --> 00:06:06,480
告诉API

148
00:06:06,480 --> 00:06:08,720
要存在哪个地址就可以了

149
00:06:09,400 --> 00:06:10,480
下次加载的时候

150
00:06:10,600 --> 00:06:12,400
直接model.load_state_dict

151
00:06:12,400 --> 00:06:14,280
然后就可以进行一个推理

152
00:06:14,280 --> 00:06:16,480
所以用起来是比较简单的

153
00:06:17,000 --> 00:06:19,800
但是这种方式实在是太naive了

154
00:06:19,800 --> 00:06:21,320
就是非常的原始

155
00:06:21,600 --> 00:06:24,480
它只是保存了网络模型的对应的参数

156
00:06:24,480 --> 00:06:25,680
网络模型的结构

157
00:06:25,680 --> 00:06:27,560
网络模型的信息计算图

158
00:06:27,560 --> 00:06:29,160
这些信息它都没有保存

159
00:06:29,160 --> 00:06:31,080
而是通过代码来去承载

160
00:06:31,080 --> 00:06:32,360
那下面来看一下

161
00:06:32,360 --> 00:06:33,440
另外一个方面

162
00:06:33,560 --> 00:06:34,720
就是Pytorch

163
00:06:34,720 --> 00:06:36,720
另外一个序列化的方式

164
00:06:36,720 --> 00:06:37,720
ONNX

165
00:06:39,400 --> 00:06:40,800
ONNX

166
00:06:40,800 --> 00:06:43,520
大家都知道Pytorch要导到一些推理引擎

167
00:06:43,520 --> 00:06:44,480
去计算的时候

168
00:06:44,880 --> 00:06:48,200
一般都会把它转成一个ONNX的格式

169
00:06:48,200 --> 00:06:49,520
那Pytorch

170
00:06:49,520 --> 00:06:51,000
那Pytorch内部

171
00:06:51,200 --> 00:06:53,520
其实是支持ONNX的export的

172
00:06:53,520 --> 00:06:55,120
包括现在在昇腾

173
00:06:55,120 --> 00:06:57,040
去对接到Pytorch的框架

174
00:06:57,040 --> 00:07:00,360
也是通过ONNX的一个接口去实现的

175
00:07:00,360 --> 00:07:03,040
下面确实看到代码很简单

176
00:07:03,040 --> 00:07:05,920
前面的都是一些加载网络模型

177
00:07:05,920 --> 00:07:08,760
最重要的就是这条torch.onnx.export

178
00:07:08,760 --> 00:07:10,920
这条语句就告诉

179
00:07:11,120 --> 00:07:13,600
需要把Pytorch的一个网络模型

180
00:07:13,880 --> 00:07:16,560
保存为alexnet.onnx

181
00:07:16,720 --> 00:07:17,920
这里面的保存的信息

182
00:07:18,040 --> 00:07:20,240
就会比Pytorch原生要多很多

183
00:07:20,240 --> 00:07:22,240
除了网络模型的权重偏移

184
00:07:22,240 --> 00:07:23,520
还有优化器的参数

185
00:07:23,520 --> 00:07:25,680
它还会保存网络模型的结构

186
00:07:25,680 --> 00:07:27,360
每一层所使用的算子

187
00:07:27,360 --> 00:07:28,120
tensor的shape

188
00:07:28,120 --> 00:07:29,960
还有很多的额外的信息

189
00:07:29,960 --> 00:07:32,720
那这些就是Pytorch序列化的一个过程

190
00:07:36,961 --> 00:07:38,360
在最后一个内容里面

191
00:07:38,360 --> 00:07:39,800
也是比较长的一个内容

192
00:07:39,800 --> 00:07:42,800
来看一下目标文件的格式

193
00:07:42,800 --> 00:07:44,000
这里面用的更多的

194
00:07:44,000 --> 00:07:44,840
在AI领域

195
00:07:44,920 --> 00:07:47,240
更多的是Protocol Buffer和Fact Buffer

196
00:07:47,600 --> 00:07:49,880
现在来看一下protobuffer

197
00:07:49,880 --> 00:07:52,080
其实protobuffer它aka叫protobuffer

198
00:07:52,480 --> 00:07:55,080
实际上它叫做Portoco Buffer

199
00:07:55,080 --> 00:07:56,280
看一下它的logo

200
00:07:56,280 --> 00:07:57,720
五颜六色的就知道

201
00:07:57,720 --> 00:08:00,040
大部分都是像谷歌的风格

202
00:08:00,320 --> 00:08:03,400
也是谷歌发起的一个开源性的项目

203
00:08:03,400 --> 00:08:06,120
因为它确实有很多特殊的优点

204
00:08:06,120 --> 00:08:07,960
比XML还有JSON要好

205
00:08:07,960 --> 00:08:10,000
所以现在很多AI框架

206
00:08:10,000 --> 00:08:10,680
Tensorflow

207
00:08:10,680 --> 00:08:11,480
MindSpore

208
00:08:11,480 --> 00:08:13,760
Pytorch都是使用protobuffer

209
00:08:13,760 --> 00:08:16,480
作为它一个主要的导出的格式

210
00:08:18,480 --> 00:08:19,320
现在看一下

211
00:08:19,320 --> 00:08:21,640
protobuffer的一个文档的语法

212
00:08:21,640 --> 00:08:23,040
那基本的语法的规则

213
00:08:23,240 --> 00:08:24,960
下面就是一段message

214
00:08:24,960 --> 00:08:26,160
然后就告诉我

215
00:08:26,160 --> 00:08:28,240
这段message属于哪个域

216
00:08:28,280 --> 00:08:30,840
然后在这个域里面加了个花括号

217
00:08:30,840 --> 00:08:32,120
那中间的这两行

218
00:08:32,280 --> 00:08:35,080
就是具体的字段的规则或者内容

219
00:08:35,080 --> 00:08:36,400
具体的中间两行

220
00:08:36,560 --> 00:08:37,840
就是具体的内容了

221
00:08:37,840 --> 00:08:39,840
看一下每一行代表什么意思

222
00:08:40,040 --> 00:08:42,320
首先有一个字段的规则

223
00:08:42,320 --> 00:08:44,560
告诉它这个字段是属于哪个范围

224
00:08:44,560 --> 00:08:46,000
然后有个数据类型

225
00:08:46,000 --> 00:08:47,200
有个名称

226
00:08:47,200 --> 00:08:48,040
等于

227
00:08:48,040 --> 00:08:49,400
然后就有一个域值了

228
00:08:49,400 --> 00:08:50,360
等于什么

229
00:08:50,560 --> 00:08:53,400
这个就是protobuffer的一个文档的

230
00:08:53,400 --> 00:08:54,920
最主要的语法规则

231
00:08:55,880 --> 00:08:57,160
下面就是Caffe

232
00:08:57,160 --> 00:09:00,040
这个AI框架用protobuffer去表示的

233
00:09:00,040 --> 00:09:02,520
那这里面有一个Data Layer

234
00:09:02,520 --> 00:09:04,760
去声明Data Layer是怎么组成的

235
00:09:04,920 --> 00:09:07,560
这种也是protobuffer的写的格式

236
00:09:07,560 --> 00:09:10,000
那右边就是卷积层

237
00:09:10,520 --> 00:09:14,080
通过这种方式去表示卷积层

238
00:09:15,640 --> 00:09:17,920
下面看一下两个AI框架有什么区别

239
00:09:18,600 --> 00:09:20,520
像Caffe这种早期的AI框架

240
00:09:20,640 --> 00:09:22,000
是使用protobuffer的格式

241
00:09:22,120 --> 00:09:24,320
去写网络模型的定义的

242
00:09:24,320 --> 00:09:26,440
而后来TensorFlow确实觉得

243
00:09:26,440 --> 00:09:28,280
大家去写这种网络模型的定义

244
00:09:28,600 --> 00:09:30,920
去写底层的这些protobuffer很容易出错

245
00:09:30,920 --> 00:09:33,600
那还不如通过python去封装好

246
00:09:33,600 --> 00:09:36,360
然后给到TFTensorFlow去封装好的API

247
00:09:36,360 --> 00:09:37,520
给用户去调

248
00:09:37,520 --> 00:09:40,000
然后通过简单的去调一些API

249
00:09:40,000 --> 00:09:42,360
就可以把protobuffer给调起来

250
00:09:42,360 --> 00:09:43,880
去写网络模型

251
00:09:43,880 --> 00:09:46,160
所以说当时候TensorFlow出来

252
00:09:46,320 --> 00:09:47,720
确实大家觉得

253
00:09:48,120 --> 00:09:51,600
原来AI框架开发AI程序还能这么玩

254
00:09:51,600 --> 00:09:52,920
在1718年的时候

255
00:09:53,080 --> 00:09:55,960
确实它已经是一个很大的一个创新

256
00:09:56,080 --> 00:09:57,880
不过后来又有了PyTorch

257
00:09:57,880 --> 00:09:59,400
这也是另外一个故事

258
00:09:59,400 --> 00:10:00,920
不在今天的主线

259
00:10:03,600 --> 00:10:06,080
现在稍微深入的去看一下

260
00:10:06,080 --> 00:10:08,560
protobuffer的一个编码的模式

261
00:10:09,280 --> 00:10:10,480
简单的去理解一下

262
00:10:11,720 --> 00:10:12,600
计算机

263
00:10:13,160 --> 00:10:15,920
一般来说它是通过二进制进行编码

264
00:10:15,920 --> 00:10:19,360
那么就是010101这种方式

265
00:10:20,040 --> 00:10:21,320
它的基数是2

266
00:10:21,320 --> 00:10:23,040
规则就是逢二进一

267
00:10:23,040 --> 00:10:25,680
像int这种类型是由32位去组成

268
00:10:25,800 --> 00:10:27,600
每位的数值就是2的n

269
00:10:27,600 --> 00:10:30,480
次方n就是0的31这个范围

270
00:10:30,480 --> 00:10:31,680
大家可以去翻一翻

271
00:10:31,680 --> 00:10:33,760
计算机原理去了解一下

272
00:10:33,920 --> 00:10:35,760
这里面就不详细的展开

273
00:10:35,760 --> 00:10:37,040
而protobuffer这种

274
00:10:37,160 --> 00:10:39,240
采用的是TLV的编码模式

275
00:10:39,440 --> 00:10:40,400
TLV说白了

276
00:10:40,400 --> 00:10:41,400
你可能听不懂

277
00:10:41,400 --> 00:10:42,440
我一开始也听不懂

278
00:10:42,440 --> 00:10:45,040
但是把它的详细打印出来

279
00:10:45,040 --> 00:10:46,040
它其实就是Tag

280
00:10:46,560 --> 00:10:47,040
Length

281
00:10:47,280 --> 00:10:49,560
还有Value的模式进行编码

282
00:10:50,120 --> 00:10:53,200
像Tag跟Value它其实是一对的

283
00:10:53,200 --> 00:10:54,040
对应起来的

284
00:10:54,040 --> 00:10:57,040
一个类似于经常字典里面的key

285
00:10:57,040 --> 00:10:58,480
一个类似于Value

286
00:10:58,480 --> 00:11:01,200
而Length就代表整个Value的长度

287
00:11:01,200 --> 00:11:02,120
写Value的时候

288
00:11:02,400 --> 00:11:04,320
有一个长度告诉计算机

289
00:11:04,320 --> 00:11:05,520
我要保存多长

290
00:11:05,520 --> 00:11:07,040
方便地址索引

291
00:11:07,520 --> 00:11:09,520
这个时候整个protobuffer的

292
00:11:09,520 --> 00:11:10,280
对外的对象

293
00:11:10,600 --> 00:11:12,920
就用一个Message来去描述

294
00:11:12,920 --> 00:11:14,760
这整一个数据结构

295
00:11:14,760 --> 00:11:16,840
或者整个的对象结构

296
00:11:17,040 --> 00:11:17,880
通过这种方式

297
00:11:18,040 --> 00:11:20,200
就比较好的进行一个编码

298
00:11:20,200 --> 00:11:22,200
看一下它protobuffer的编码模式

299
00:11:22,200 --> 00:11:26,120
字里面就不详细的去给大家介绍了

300
00:11:26,120 --> 00:11:28,040
因为它会有一个编码的过程

301
00:11:28,040 --> 00:11:29,960
也会有一个解码的过程

302
00:11:30,800 --> 00:11:32,320
通过TLV的编码方式

303
00:11:32,440 --> 00:11:34,840
就把内存的对象和内存的数据结构

304
00:11:35,200 --> 00:11:37,080
变成硬盘的数据

305
00:11:37,760 --> 00:11:39,880
第二个看一下flatbuffer

306
00:11:39,880 --> 00:11:41,960
可能很多人听过protobuffer

307
00:11:41,960 --> 00:11:46,000
但是至少在ZOMI开发推理引擎的时候

308
00:11:46,120 --> 00:11:48,120
我是真没接触过flatbuffer

309
00:11:48,120 --> 00:11:49,640
确实用的也比较小

310
00:11:49,640 --> 00:11:52,120
像protobuffer用的会更多

311
00:11:52,320 --> 00:11:54,040
看一下flatbuffer

312
00:11:54,040 --> 00:11:57,200
它对比protobuffer有一些的主要的优点

313
00:11:57,200 --> 00:11:59,280
所以会在推理引擎里面

314
00:11:59,280 --> 00:12:01,280
大量的去用到flatbuffer

315
00:12:01,280 --> 00:12:03,600
后面会去讲讲有哪些用到

316
00:12:05,080 --> 00:12:07,600
像flatbuffer它有自己主要的特点

317
00:12:07,600 --> 00:12:10,520
一个就是数据的访问不需要解析

318
00:12:10,520 --> 00:12:11,520
这点很重要

319
00:12:11,520 --> 00:12:12,400
不需要解析

320
00:12:12,400 --> 00:12:14,680
证明了内存肯定会更高效

321
00:12:14,680 --> 00:12:15,800
速度会更快

322
00:12:15,800 --> 00:12:18,880
生成的代码量也会相对来说比较少

323
00:12:18,880 --> 00:12:21,320
所以说这是它的一个很重要的优点

324
00:12:22,240 --> 00:12:23,720
很多人就会问

325
00:12:23,720 --> 00:12:25,520
既然flatbuffer那么好

326
00:12:25,520 --> 00:12:28,480
为什么你不直接用flatbuffer去代替掉

327
00:12:28,480 --> 00:12:29,720
protobuffer呢

328
00:12:29,720 --> 00:12:32,280
这个就是它们之间的一个对比

329
00:12:32,280 --> 00:12:34,640
我就在这里面不详细的展开

330
00:12:36,240 --> 00:12:39,240
其实protobuffer支持的格式和类型会更加多

331
00:12:39,240 --> 00:12:41,720
而且它的接口也会更加多

332
00:12:41,720 --> 00:12:44,400
非常方便做一些常用的工作

333
00:12:44,760 --> 00:12:47,960
除了在AI框架里面用protobuffer去表示

334
00:12:47,960 --> 00:12:49,680
神经网络模型的Meta数据

335
00:12:49,680 --> 00:12:50,920
还有它的权重数据

336
00:12:50,960 --> 00:12:52,560
它其实还有很多作用

337
00:12:52,560 --> 00:12:54,680
特别是在一些游戏的协议的传输

338
00:12:54,920 --> 00:12:56,920
还有网络自动的传输里面

339
00:12:56,920 --> 00:12:59,080
protobuffer还是做得非常好的

340
00:12:59,080 --> 00:13:02,520
而且它经过编解码有利于数据的加减密

341
00:13:04,200 --> 00:13:06,280
下面看一下flatbuffer

342
00:13:06,280 --> 00:13:10,120
刚才说到flatbuffer其实也是谷歌去发起的

343
00:13:10,120 --> 00:13:12,320
后来很多AI推理的框架

344
00:13:12,440 --> 00:13:14,320
确实把flatbuffer用起来

345
00:13:14,600 --> 00:13:16,920
最主要的两个有MNN

346
00:13:16,920 --> 00:13:20,320
MNN就是阿里推出的一个推理引擎

347
00:13:20,520 --> 00:13:23,680
推理引擎在阿里非常多的APP里面已经用到了

348
00:13:23,680 --> 00:13:26,400
官网宣传有18个APP已经用了

349
00:13:26,400 --> 00:13:28,680
包括经常刷的淘宝

350
00:13:28,680 --> 00:13:32,480
里面的很多AI功能就是用了MNN做一个推理的

351
00:13:32,800 --> 00:13:35,960
像华为的MindSpore Lite里面的schema

352
00:13:35,960 --> 00:13:39,480
或者里面的IR也是用flatbuffer去定义的

353
00:13:39,920 --> 00:13:42,240
好了今天的内容就到这里为止

354
00:13:42,240 --> 00:13:44,360
简单的总结一下

355
00:13:45,480 --> 00:13:48,080
因为转换模块会遇到很多的挑战

356
00:13:48,080 --> 00:13:51,000
于是设计了一个转换模块的架构

357
00:13:51,000 --> 00:13:54,080
去承载这些挑战或者去应对这些挑战的

358
00:13:55,200 --> 00:13:58,320
在推理引擎里面的转换模块很重要的一个工作

359
00:13:58,720 --> 00:14:01,720
就是把不同AI框架训练出来的网络模型

360
00:14:02,120 --> 00:14:06,080
序列化成推理引擎能够识别的网络模型

361
00:14:06,280 --> 00:14:08,240
在推理引擎真正去执行的时候

362
00:14:08,400 --> 00:14:12,520
就会把网络模型反序列化为内存的对象

363
00:14:12,520 --> 00:14:14,240
然后给RunTime去执行

364
00:14:14,240 --> 00:14:17,720
这个就是模型序列化和反序列化最重要的工作

365
00:14:17,800 --> 00:14:21,000
序列化和反序列化里面用到什么数据的格式

366
00:14:21,000 --> 00:14:23,120
或者文档的格式或者标准呢

367
00:14:24,440 --> 00:14:26,360
于是最后就介绍了

368
00:14:26,360 --> 00:14:30,480
protobuffer和Thread Buffer两种文档格式的内容

369
00:14:30,480 --> 00:14:33,800
而在推理引擎里面用的更多的是flatbuffer

370
00:14:34,200 --> 00:14:36,080
因为它在反序列化的过程当中

371
00:14:36,080 --> 00:14:40,040
不需要解析反序列化序列化的过程会更加的快

372
00:14:40,880 --> 00:14:44,280
在推理引擎里面更多的会用到flatbuffer

373
00:14:44,280 --> 00:14:45,440
而不是protobuffer

374
00:14:45,600 --> 00:14:47,360
将会在下一节内容里面

375
00:14:47,360 --> 00:14:50,360
去跟大家看看如何自定义图的IR

376
00:14:50,360 --> 00:14:53,560
还有转换的流程和具体的技术细节

377
00:14:53,560 --> 00:14:55,640
后面的这节课更吸引哦

378
00:14:55,640 --> 00:14:56,440
谢谢各位

379
00:14:56,440 --> 00:14:57,400
拜了个拜

380
00:14:58,080 --> 00:14:58,840
卷的不行了

381
00:14:58,840 --> 00:14:59,720
卷的不行了

382
00:14:59,720 --> 00:15:01,520
记得一键三连加关注哦

383
00:15:01,520 --> 00:15:04,720
所有的内容都会开源在下面这条链接里面

384
00:15:05,160 --> 00:15:06,040
拜了个拜