Перейти к основному содержимому

Чтобы получить чистое Markdown-содержимое этой страницы, добавьте .md к этому URL. Полный индекс документации см. на https://docs.nvidia.com/dynamo/llms.txt. Полное содержимое, включая справочник API и примеры SDK, см. на https://docs.nvidia.com/dynamo/llms-full.txt.

Создание пользовательского контейнера TensorRT-LLM

О предварительно собранном контейнере см. краткое руководство по TensorRT-LLM.

Как устроен образ​

Образ Dynamo TensorRT-LLM добавляет Dynamo поверх исходного релизного контейнера NVIDIA TensorRT-LLM — он не собирает TensorRT-LLM из исходного кода. Базовый образ, который использует сгенерированный Dockerfile, задан в container/context.yaml:

trtllm:
  cuda13.1:
    runtime_image: nvcr.io/nvidia/tensorrt-llm/release
    runtime_image_tag: 1.3.0rc14

Для --target=runtime (это основной сценарий в данном руководстве) container/render.py создает этап, который:

  1. Начинается с ${RUNTIME_IMAGE}:${RUNTIME_IMAGE_TAG} (исходного образа TRT-LLM),
  2. Собирает wheels Dynamo (ai-dynamo, ai-dynamo-runtime, опционально kvbm) на отдельном manylinux-этапе wheel_builder, и
  3. Устанавливает эти wheels в виртуальное окружение /opt/dynamo/venv, созданное с --system-site-packages, чтобы исходное Python-окружение оставалось доступным для импорта.

Цели dev и local-dev создают /opt/dynamo/venv в container/templates/dev.Dockerfile и добавляют инструменты сборки (maturin, uv), чтобы пользователь мог во время выполнения запустить maturin develop для примонтированной рабочей области и получить редактируемую установку. Wheels Dynamo в /opt/dynamo/wheelhouse/ в этих целях остаются неустановленными.

Исходный образ nvcr.io/nvidia/tensorrt-llm/release поставляется с многоархитектурным манифестом (linux/amd64 и linux/arm64), поэтому образ Dynamo TensorRT-LLM можно собрать для любой из этих архитектур.

Сборка образа по умолчанию​

# On an x86_64 host:
python container/render.py --framework=trtllm --target=runtime --output-short-filename --cuda-version=13.1
docker build -t dynamo:trtllm-latest -f container/rendered.Dockerfile .

# On an arm64 host (Grace, arm64 EC2, etc.):
python container/render.py --framework=trtllm --target=runtime --platform=linux/arm64 --output-short-filename --cuda-version=13.1
docker buildx build --platform=linux/arm64 -t dynamo:trtllm-latest -f container/rendered.Dockerfile .

Запустите полученный образ:

./container/run.sh --image dynamo:trtllm-latest -it

Закрепление другого исходного релиза TensorRT-LLM​

Чтобы использовать другой исходный релиз TRT-LLM (более новый rc-тег, тег с hotfix и т. п.) без редактирования context.yaml, переопределите ARG-параметры runtime-образа во время docker build:

python container/render.py --framework=trtllm --target=runtime --output-short-filename --cuda-version=13.1
docker build --pull \
  --build-arg RUNTIME_IMAGE=nvcr.io/nvidia/tensorrt-llm/release \
  --build-arg RUNTIME_IMAGE_TAG=<your-tag> \
  -t dynamo:trtllm-latest -f container/rendered.Dockerfile .

--pull рекомендуется использовать, когда меняется только исходный тег: без него Docker может повторно использовать ранее закешированный слой, который был разрешен по манифесту старого тега. В результате получится частично устаревший образ, который запускается, но ломается при инициализации NIXL, если в исходном образе между тегами переместили поставляемые библиотеки.

Если из-за перемещения тега меняется место, куда исходный образ устанавливает libnixl.so или каталог плагинов NIXL, проверки test -f / test -d на runtime-этапе прерывают сборку вместо того, чтобы создать незаметно сломанный образ. Если это произошло, обновите пути LD_PRELOAD / NIXL_PLUGIN_DIR в container/templates/trtllm_runtime.Dockerfile и повторно запустите render.py (иначе container/rendered.Dockerfile останется устаревшим, а сборка незаметно использует старые пути).

Сборка TensorRT-LLM из исходного кода​

Dynamo больше не собирает TensorRT-LLM самостоятельно. Если вам нужна пользовательская сборка TRT-LLM (собственный патч, невыпущенный commit и т. п.), поддерживаемый путь — самостоятельно создать образ, эквивалентный исходному, и указать Dynamo на него через те же build args RUNTIME_IMAGE / RUNTIME_IMAGE_TAG.

  1. Соберите контейнер TensorRT-LLM по исходной инструкции: TensorRT-LLM — сборка из исходного кода в Linux. Используйте раздел "Building a TensorRT LLM Docker Image" (конкретно make -C docker release_build) — он создает контейнер с tensorrt_llm в системном site-packages и поставляемым libnixl.so по каноническому пути. Простой вызов build_wheel.py создает только wheel и не содержит компонентов NIXL.

    Полученный образ должен удовлетворять трем ограничениям, иначе сборка Dynamo не пройдет проверки работоспособности:

    • Python 3.12 в системном Python (/usr/local/lib/python3.12/dist-packages/...) — пути LD_PRELOAD и NIXL_PLUGIN_DIR в runtime-Dockerfile жестко привязаны к 3.12. Если ваша пользовательская сборка переходит на другую минорную версию Python, измените эти env vars в container/templates/trtllm_runtime.Dockerfile и выполните рендеринг заново.
    • tensorrt_llm установлен в системный site-packages (не в venv), с той же структурой, что и в исходном образе.
    • libnixl.so находится в /usr/local/lib/python3.12/dist-packages/tensorrt_llm/libs/nixl/libnixl.so, а плагины — в nixl/plugins/.

  2. Назначьте ему локальный тег, например my-registry/tensorrt-llm:<commit-sha> (используйте исходный commit, из которого выполнена сборка, чтобы тег нес сведения о происхождении; буквальный :custom позже сделает образ неотслеживаемым).

  3. Сгенерируйте Dockerfile и соберите образ Dynamo на базе вашего пользовательского базового образа:

    python container/render.py --framework=trtllm --target=runtime --output-short-filename --cuda-version=13.1
    docker build \
      --build-arg RUNTIME_IMAGE=my-registry/tensorrt-llm \
      --build-arg RUNTIME_IMAGE_TAG=<commit-sha> \
      -t dynamo:trtllm-<commit-sha> -f container/rendered.Dockerfile .

    Не добавляйте здесь --pull — ваш пользовательский образ существует только локально, а --pull заставит Docker попытаться получить его с docker.io, что завершится ошибкой. --pull полезен только тогда, когда базовый образ находится в удаленном registry (см. предыдущий раздел о закреплении исходного тега).

Если ваша пользовательская сборка размещает поставляемый с TRT-LLM NIXL по другому пути (или использует Python не версии 3.12), измените env vars LD_PRELOAD и NIXL_PLUGIN_DIR в container/templates/trtllm_runtime.Dockerfile (а также соответствующие проверки test -f/test -d), затем повторно запустите python container/render.py ..., чтобы перед docker build заново создать container/rendered.Dockerfile. Иначе сборка незаметно использует ранее сгенерированный файл. Эти env vars нужны, чтобы обойти ai-dynamo/nixl#1668: поставляемый с nixl-cu13 UCX 1.20.0 зависает при multi-agent-инициализации, поэтому каждый процесс в образе принудительно загружает вместо него libnixl.so версии 0.9.0 из TRT-LLM.