模型管理#

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

模型控制模式 NONE#

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

服务器运行时对模型仓库的更改将被忽略。使用模型控制协议的模型加载和卸载请求将不起作用，并将返回错误响应。

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

模型控制模式 EXPLICIT#

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

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

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

如果您在使用模型控制协议加载和卸载模型时看到一些内存增长，则可能是实际的内存泄漏，而是一些系统的 malloc 启发式方法导致内存无法立即释放回操作系统。为了提高内存性能，您可以考虑从 malloc 切换到 tcmalloc 或 jemalloc，方法是在运行 Triton 时设置 LD_PRELOAD 环境变量，如下所示

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

# Using jemalloc
LD_PRELOAD=/usr/lib/$(uname -m)-linux-gnu/libjemalloc.so:${LD_PRELOAD} tritonserver --model-repository=/models ...

我们建议您同时尝试 tcmalloc 和 jemalloc，以确定哪一个更适合您的用例，因为它们在内存分配和释放方面具有不同的策略，并且可能因工作负载而异。

tcmalloc 和 jemalloc 库都已安装在 Triton 容器中。但是，如果您需要安装它们，可以使用以下命令执行此操作

# Install tcmalloc
apt-get install gperf libgoogle-perftools-dev

# Install jemalloc
apt-get install libjemalloc-dev

模型控制模式 POLL#

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

模型仓库的更改将被检测到，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”上的模型实例配置（即增加/减少实例计数），则在模型控制模式 EXPLICIT 下收到加载请求时，或者在模型控制模式 POLL 下检测到“config.pbtxt”的更改时，Triton 将更新模型而不是重新加载模型。
- 新的模型配置也可以通过加载 API 传递给 Triton。
- 某些文本编辑器在就地修改“config.pbtxt”时会在模型目录中创建交换文件。交换文件不是模型配置的一部分，因此它在模型目录中的存在可能会被检测为新文件，并导致模型完全重新加载，而只期望进行更新。
如果序列模型被更新（即减少实例计数），Triton 将等待正在进行的序列完成（或超时），然后删除序列后面的实例。
- 如果实例计数减少，则在空闲实例和具有正在进行的序列的实例中选择任意实例以进行删除。
如果序列模型在有正在进行的序列的情况下被重新加载（即更改模型文件），则 Triton 不保证来自正在进行的序列的任何剩余请求将被路由到同一模型实例进行处理。目前，用户有责任确保在重新加载序列模型之前完成任何正在进行的序列。

并发加载模型#

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

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