Triton教程 --- 模型管理

Triton教程 — 模型管理

Triton系列教程:

1. 快速开始
2. 利用Triton部署你自己的模型
3. Triton架构
4. 模型仓库
5. 存储代理
6. 模型设置
7. 优化
8. 动态批处理
9. 速率限制器

Triton 提供的模型管理 API 是 HTTP/REST 和 GRPC 协议的一部分，也是 C API 的一部分。 Triton 以三种模型控制模式之一运行：NONE、EXPLICIT 或 POLL。 模型控制模式决定了 Triton 如何处理模型存储库的更改以及哪些协议和 API 可用。

模型控制模式 NONE

Triton 尝试在启动时加载模型存储库中的所有模型。 Triton 无法加载的模型将被标记为不可用，并且不可用于推理。

服务器运行时对模型存储库的更改将被忽略。 使用模型控制协议的模型加载和卸载请求不会产生任何影响，并将返回错误响应。

该模型控制模式是通过在启动 Triton 时指定 --model-control-mode=none 来选择的。 这是默认的模型控制模式。 在 Triton 运行时更改模型存储库必须小心谨慎，如修改模型存储库中所述。

模型控制模式 EXPLICIT

在启动时，Triton 仅加载那些使用 --load-model 命令行选项明确指定的模型。 要在启动时加载所有模型，请将 --load-model=* 指定为唯一的 --load-model 参数。 将 --load-model=* 与另一个 --load-model 参数一起指定将导致错误。 如果未指定 --load-model 则在启动时不会加载任何模型。 Triton 无法加载的模型将被标记为不可用，并且不可用于推理。

启动后，必须使用模型控制协议显式启动所有模型加载和卸载操作。 模型控制请求的响应状态指示加载或卸载操作的成功或失败。 尝试重新加载已加载的模型时，如果由于任何原因重新加载失败，则已加载的模型将保持不变并保持加载状态。 如果重新加载成功，新加载的模型将替换已加载的模型，而不会损失模型的可用性。

通过指定 --model-control-mode=explicit 启用此模型控制模式。 在 Triton 运行时更改模型存储库必须小心谨慎，如修改模型存储库中所述。

如果您在使用模型控制协议加载和卸载模型时看到一些内存增长，这可能不是真正的内存泄漏，而是某些系统的 malloc 试探法导致内存无法立即释放回操作系统。 您可以尝试在运行 Triton 时通过设置 LD_PRELOAD 来从 malloc 切换到 tcmalloc 以获得更好的内存性能：

LD_PRELOAD=/usr/lib/$(uname -m)-linux-gnu/libtcmalloc.so.4:${LD_PRELOAD} tritonserver --model-repository=/models ...

tcmalloc 库已经安装在 Triton 容器中。 您还可以使用安装 tcmalloc

apt-get install gperf libgoogle-perftools-dev

模型控制模式 POLL

Triton 尝试在启动时加载模型存储库中的所有模型。 Triton 无法加载的模型将被标记为不可用，并且不可用于推理。

将检测对模型存储库的更改，Triton 将根据这些更改尝试根据需要加载和卸载模型。 尝试重新加载已加载的模型时，如果由于任何原因重新加载失败，则已加载的模型将保持不变并保持加载状态。 如果重新加载成功，新加载的模型将替换已加载的模型，而不会损失模型的可用性。

由于 Triton 会定期轮询存储库，因此可能无法立即检测到对模型存储库的更改。 您可以使用 --repository-poll-secs 选项控制轮询间隔。 控制台日志或模型就绪协议或模型控制协议的索引操作可用于确定模型库更改何时生效。

警告：Triton 轮询模型存储库和您对存储库进行任何更改之间没有同步。 因此，Triton 可以观察到导致意外行为的部分和不完整的变化。 因此，不建议在生产环境中使用 POLL 模式。

使用模型控制协议的模型加载和卸载请求不会产生任何影响，并将返回错误响应。

通过指定 --model-control-mode=poll 并在启动 Triton 时将 --repository-poll-secs 设置为非零值来启用此模型控制模式。 在 Triton 运行时更改模型存储库必须小心谨慎，如修改模型存储库中所述。

在 POLL 模式下，Triton 响应以下模型存储库更改：

• 可以通过添加和删除相应的版本子目录来在模型中添加和删除版本。 即使正在使用模型的删除版本，Triton 也将允许完成飞行中的请求。 对已删除模型版本的新请求将失败。 根据模型的版本策略，对可用版本的更改可能会更改默认提供的模型版本。

• 可以通过删除相应的模型目录来从存储库中删除现有模型。 Triton 将允许对已删除模型的任何版本的运行中请求完成。 对已删除模型的新请求将失败。

• 可以通过添加新模型目录将新模型添加到存储库中。

• 模型配置文件（config.pbtxt）可以更改，Triton 将卸载并重新加载模型以获取新的模型配置。

• 可以添加、删除或修改为代表分类的输出提供标签的标签文件，Triton 将卸载并重新加载模型以获取新标签。 如果添加或删除标签文件，则必须同时对模型配置中对应的输出的 label_filename 属性进行相应的编辑。

修改模型存储库

模型存储库中的每个模型都位于其自己的子目录中。 模型子目录内容允许的活动因 Triton 使用该模型的方式而异。 可以使用模型元数据或存储库索引 API 来确定模型的状态。

• 如果模型正在加载或卸载，则不得添加、删除或修改该子目录中的任何文件或目录。

• 如果模型从未加载或已完全卸载，则可以删除整个模型子目录，或者可以添加、删除或修改其任何内容。

• 如果模型已完全加载，则可以添加、删除或修改该子目录中的任何文件或目录； 除了实现模型后端的共享库。 Triton 在加载模型时使用后端共享库，因此删除或修改它们可能会导致 Triton 崩溃。 要更新模型的后端，您必须首先完全卸载模型，修改后端共享库，然后重新加载模型。 在某些操作系统上，还可以简单地将现有共享库移动到模型存储库之外的另一个位置，复制新的共享库，然后重新加载模型。

• 如果仅修改非序列模型的“config.pbtxt”上的模型实例配置（即增加/减少实例计数），则当在模型下收到加载请求时，Triton 将更新模型而不是重新加载模型 在模型控制模式 POLL 下检测到控制模式 EXPLICIT 或对“config.pbtxt”的更改。

• 如果使用运行中序列更新序列模型，Triton 不保证运行中序列的任何剩余请求将被路由到同一模型实例进行处理。 目前，用户有责任确保在更新序列模型之前完成任何飞行序列。

同时加载模型

为了减少服务停机时间，Triton 在后台加载新模型，同时继续对现有模型进行推理。 根据用例和性能要求，专用于加载模型的最佳资源量可能会有所不同。 Triton 公开了一个 --model-load-thread-count 选项来配置专用于加载模型的线程数，默认为 4。

要使用 C API 设置此参数，请参阅 tritonserver.h 中的 TRITONSERVER_ServerOptionsSetModelLoadThreadCount。