前面已经用https://github.com/triton-inference-server/server/doc/examples开源仓的范例资源,创建一个最基础的模型仓以便执行一些基础的用户端范例,现在就要带着读者为模型仓添加新的模型。
在“创建模型仓”的文章里讲解过,Triton模型仓使用目录结构与相关文件来形成一个模型的基础要素,如下所列:
目录结构与文件 |
用途说明 |
<model_repo1> ├── <model_1> │ ├── <1> │ │ └──模型文件1 │ ├── <2> │ │ └──模型文件2 │ ├── config.pbtxt │ └── 标注文件(如果有) 。。。。。 |
根目录:模型仓名称 目录:模型model_1 目录:模型model_1的版本1 文件:模型model_1版本1的模型文件 目录:模型model_1的版本2 文件:模型model_1版本2的模型文件 文件:模型model_1的配置文件 文件:模型model_1的标注文件 |
上面的目录结构与模型文件是最基本的材料,处理起来是很容易的,比较复杂的部分是配置文件config.pbtxt的内容,里面提供Triton服务器用来管理模型执行特性的各项参数,这些设置的内容主要分为静态的基础(minimal)设置项与动态的优化(optimization)设置两大部分,本位内容先针对基础配置项的部分进行说明。
为了说明这些配置内容,这里先以范例模型仓里的inception_graphdef模型的配置文件config.pbtxt为例,来配合以下的简单说明,比较容易让大家理解详细的内容:
name: "inception_graphdef" platform: "tensorflow_graphdef"
max_batch_size: 128 input [ { name: "input" data_type: TYPE_FP32 format: FORMAT_NHWC dims: [ 299, 299, 3 ] } ] output [ { name: "InceptionV3/Predictions/Softmax" data_type: TYPE_FP32 dims: [ 1001 ] label_filename: "inception_labels.txt" } ] |
|
每个配置文件里都至少包含以下5个部分:
这部分直接使用存放模型的文件夹名称,因此可以省略,如果要指定的话就必须与文件夹名称一致。
这部分必须与模型训练时使用的框架与文件格式相匹配,以下是使用频率较高的种类:
后端(backend)种类 |
参数”platform”的值 |
TensorRT模型 |
"tensorrt_plan" |
TensorFlow的graphdef模型 |
"tensorflow_graphdef" |
TensorFlow的savedmodel模型 |
"tensorflow_savedmodel" |
ONNX Runtime模型 |
"onnxruntime_onnx" |
PyTorch模型 |
|
Python |
|
Dali |
|
OpenVino |
|
至于其他平台/后端的对应名称,就需要根据实际的平台与对应名称进行配置。
这个属性只有一个“解耦(decoupled)与否”的选项。使用解耦意味着模型生成的响应的数量可能与发出的请求的数量不同,并且响应可能与请求的顺序无关。
默认值为false,上面范例中并未列出这个参数的配置值,表示“不启用解耦”功能,意味着该模型将为每个请求生成一个响应。
如果需要启用解耦功能,就在配置文件内添加以下内容:
|
model_transaction_policy { decoupled: True } |
Triton服务器支持多种调度和批处理算法,可以为每个模型独立选择。这个属性表示执行该推理模型计算时的最大批量规模,包括“无状态(stateless)”或“有状态(stateful)”等类型的模型。
这个参数主要配合下面“输入/输出节点内容”的张量尺度部分,例如本范例中输入节点张量格式为“format: FORMAT_NHWC”,但是下面尺度“dims: [ 299, 299, 3 ]”的三个数值是对应到“HWC(高/宽/通道)”,缺少“批量值(N)”的部分,这正是这个“最大批量值”为输入节点与输出节点所配置的数值,这样Triton可以使用动态批处理器或序列批处理器自动对模型进行批处理。
在这种情况下,max_batch_size应设置为大于或等于1的值,表示应与该模型一起使用的最大批次大小;对于不支持批处理或不支持以上述特定方式进行批处理的推理模型,则将max_batch_size设置为0。
每个推理模型都有至少一个输入节点与输出节点,这部分的内容必须配合模型的内容,不能自己随便定义。
要添加新的推理模型时,推荐使用Netron工具查看模型的网络结构,只要在浏览器上输入“netron.app”后打开模型文件就可以。目前经过测试,Netron.APP工具能查看ONNX、TensorFlow/graphdef、Pytorch等模型文件的网络结构,相当方便。
下图是model_repository/inception_graphdef/1/model.graphdef模型文件所能看到的输入/输出节点的内容:
每个节点都包含“名称”、“数据类型”与“尺度(shape)”三个部分,现在就进一步说明:
上图最左边的输入节点在整个网络结构的最上方,名称为“input”;中间输出节点在网络结构最下方,点选“softmax”节点会出现右边灰色信息快,显示其完整名称为“InceptionV3/Predictions/Softmax”。现在对照模型的config.pbtxt里对应内容,是必须能匹配的,否则启动Triton服务器时会出现错误。
不过这个环节里对PyTorch模型需要特殊的处理,由于TorchScript模型文件中输入/输出的元数据不足,配置中输入/输出的“名称属性”必须遵循以下特定的命名约定:
Triton服务器的PyTorch后端支持以张量字典的形式将输入传递给模型,例如模型有如下的张量字典内容:
{'A':
tensor1, 'B': tensor2}
输入的名称映射到该特定张量的字符串“key”值,例如“A”或“B”,其中输入“A”是指对应于 tensor1 的值、“B”是指对应于 tensor2 的值。
当输入节点名称不在张量字典内,就使用TorchScript模型里所定义的forward()函数输入值。例如函数定义为“forward(self, input0, input1)”时,则两个输入节点的名称分别对应为“input0”与“input1”。
这里的<name>可以是任何字符串、<index>则对应到输入或输出顺序的整数,例如模型有两个输入节点与两个输出节点时,可以用“INPUT_0”与“INPUT_1”代表两个输入节点、用“OUTPUT_0”与“OUTPUT_1”代表两个输出节点。
输入和输出张量所允许的数据类型因模型类型而异,数据类型部分描述了允许的数据类型以及它们如何映射到每个模型类型的数据类型。
下表显示了Triton支持的张量数据类型:::
以上是关于模型数据类型的部分。
这里提供的张量尺度内容是去除第一个batch_size的部分,因此需要与前面设定的max_batch_size组合形成完整的张量尺度。
输入节点的张量尺度(如“dims: [ 299, 299, 3 ]”),表示模型和Triton在推理请求中预期的张量尺寸;输出节点的张量尺度(如“dims: [ 1001 ]”),表示模型生成的输出张量的形状,并由Triton服务器响应推断请求返回。
输入和输出尺度内的值都必须大于或等于1,也就是不允许使用[]空尺度,节点的尺度由max_batch_size和输入或输出dims属性指定的维度的组合指定,
例如本文范例中输入节点的尺度为“dims: [ 299, 299, 3 ]”、max_batch_size=128,则张量尺度的完整表达为“[ -1, 299, 299, 3]”;如果max_batch_size=0时,则张量尺度的完整表达为“[ 299, 299, 3]”。
每个模型可以有一个或多个版本,模型配置的ModelVersionPolicy属性用于设置以下策略之一。
配置方式 |
配置说明 |
version_policy: { all: {}} |
模型存储库中可用的模型的所有版本都可用于推断 |
version_policy: { latest: { num_versions: 2}} |
只有存储库中模型的最新版本可用于推断,寻找该模型数字最大的版本号。 |
version_policy: { specific: { versions: [1,3]}} |
只有特定列出的模型版本可用于推断。 |
如果未指定版本策略,则使用最新版本(n=1)作为默认值,表示Triton仅提供最新版本的模型。在所有情况下,从模型存储库中添加或删除版本子目录都可以更改后续推理请求中使用的模型版本。
以上是完成一个config.pbtxt模型配置文件的最基础内容,大部分内容都比较直观,除了最后面的张量尺度会有比较多的变化之外,不过只要逐渐熟悉推理运作的过程之后,就能更进一步掌握与batch_size相关的应用与调试方式。【完】
好文章,需要你的鼓励
临近年底,苹果公布了2024年App Store热门应用和游戏榜单,Temu再次成为美国下载量最多的免费应用。
云基础设施市场现在已经非常庞大,很难再有大的变化。但是,因为人们可以轻松地关闭服务器、存储和网络——就像开启它们那样,预测全球云基础设施开支可能非常困难。