运行测试#

对于开发 FIL 后端的开发人员来说，运行测试的最简单方法是调用 ci/local/build.sh 脚本，该脚本将构建服务器镜像和测试镜像，然后运行基于该镜像的容器，该容器运行完整的测试套件。

运行测试套件最耗时的部分之一是训练端到端测试模型。ci/local/build.sh 脚本将在运行之间缓存 qa/L0_e2e/model_repository 和 qa/L0_e2e/cpu_model_repository 中已训练的模型。有时，您可能会进行更改，从而使以前生成的模型无效。在这种情况下，您可以清除这些目录以重新开始。

ci/local/build.sh 脚本使用以下环境变量来控制测试的构建和执行

  • RETRAIN：如果设置为 1，则重新训练测试模型。

  • USE_CLIENT_WHEEL：如果设置为 1，则从 Triton SDK 镜像复制的 wheel 安装 Triton 客户端。这对于在 ARM 机器上进行测试非常有用，因为 Triton Python 客户端无法通过 pip 获取。

  • SDK_IMAGE：如果设置，则从此特定 Docker SDK 镜像复制 Triton 客户端 wheel

  • HOST_BUILD：在主机上而不是通过 Docker 构建。这对于开发期间的快速迭代非常有用。

  • TEST_PROFILE： “dev” 或 “ci”。此变量提供在运行测试时要使用的 Hypothesis 测试配置文件的名称。“ci” 配置文件运行更多示例，而 “dev” 配置文件执行速度更快。默认为 “dev”。

CI 测试脚本#

除了 ci/local/build.sh 之外，仓库还包含一个 ci/gitlab/build.sh 脚本，该脚本用于在 CI 中运行测试。有时，调用此脚本以更紧密地复制 CI 环境很有用。此脚本不在运行之间缓存模型，并且通常会运行比用于 local 脚本的测试更多且更慢的测试。

ci/gitlab/build.sh 脚本使用以下环境变量来控制测试的构建和执行

  • PREBUILT_SERVER_TAG：使用此 Docker 镜像作为要测试的 Triton 服务器镜像，而不是构建它。

  • PREBUILT_TEST_TAG：使用此 Docker 镜像作为 Triton 测试镜像，而不是在服务器镜像之上构建它。

  • MODEL_BUILDER_IMAGE：使用此 Docker 镜像来训练测试模型，而不是构建镜像。

  • LOG_DIR：用于存储测试日志的主机目录

  • NV_DOCKER_ARGS：一个 bash 表达式，当求值时，返回用于控制 CI 中 GPU 访问的 Docker 参数

  • BUILDPY：如果设置为 1，则使用 Triton 的 build.py 脚本而不是 FIL 后端 Dockerfile 进行构建。

  • CPU_ONLY：如果设置为 1，则在不使用 GPU 支持的情况下进行构建。

  • NO_CACHE：设置为 0 以启用 Docker 缓存。默认情况下，缓存已禁用。

  • USE_CLIENT_WHEEL：如果设置为 1，则从 Triton SDK 镜像复制的 wheel 安装 Triton 客户端。这对于在 ARM 机器上进行测试非常有用，因为 Triton Python 客户端无法通过 pip 获取。

  • SDK_IMAGE：如果设置，则从此特定 Docker SDK 镜像复制 Triton 客户端 wheel

手动运行测试#

强烈建议您使用提供的测试脚本来运行测试。如果您希望手动运行测试，则必须使用 qa/generate_example_models.sh 脚本生成测试模型，针对生成的模型仓库启动 Triton 服务器，然后运行 pytest --repo qa/L0_e2e/model_repository qa/L0_e2e。

此方法不是官方支持的测试方法，并且将为此方法提供最少的支持。如果您发现它有用并希望贡献文档以使此方法更轻松，欢迎提交拉取请求。

在本页中