# Переносимость TensorRT engine: GPU, runtime, plugins и платформа

Сериализованный TensorRT engine нельзя считать универсальным файлом для любой NVIDIA GPU и версии runtime.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/tensorrt-plan-portability/
Language: ru

Сериализованный TensorRT engine нельзя считать универсальным файлом для любой NVIDIA GPU и версии runtime. Проверяйте build version, аппаратную совместимость, plugins и платформу. Это относится к TensorRT plan и соответствующему Triton backend, отдельно от современного TensorRT-LLM LLM API/PyTorch. Перед переносом составьте матрицу исходной и целевой среды, затем подтвердите загрузку и функциональный результат, не выводя переносимость из одинакового объема VRAM устройств.

## Установите тип артефакта

[Документация Triton TensorRT backend](https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/tensorrt_backend/README.html) описывает исполнение serialized TensorRT engines. Убедитесь, что переносится именно plan, а не model.yaml или Hugging Face checkpoint другого deployment пути. Эти артефакты имеют разные зависимости и правила приемки. Сохраните процесс сборки, source model и параметры compatibility. Без этих сведений невозможно уверенно объяснить, почему файл принимается одним runtime и отклоняется другим: само расширение или имя модели не хранит весь смысл предусмотренных ограничений и условий загрузки.

## Проверьте версии и платформу

В [руководстве engine compatibility](https://docs.nvidia.com/deeplearning/tensorrt/latest/inference-library/engine-compatibility.html) описаны version compatibility и проверки при десериализации. Режимы совместимости включаются при соответствующей сборке, а не появляются автоматически после копирования файла. Host platform тоже важна. Не обещайте перенос Linux engine на другую ОС или CPU architecture без предусмотренной поддержки. Запишите версии builder и runtime полностью, а также выбранные compatibility settings. Формулировка «оба используют TensorRT» слишком широка для подтверждения допустимого сочетания и может скрывать несовместимые версии библиотек.

## Учтите GPU и plugins

По умолчанию engine связан с типом устройства сборки; предусмотренные hardware compatibility уровни меняют условия и допустимые tactics. Они могут влиять на производительность, поэтому совместимость не равна оптимальности. Plugins также должны быть доступны корректным способом и соответствовать ожидаемым интерфейсам. Не копируйте библиотеку только по совпадению имени файла. Сохраните ее происхождение и версию вместе с plan. Достаточная VRAM не заменяет поддержку инструкций или доступность custom operations, без которых десериализация либо выполнение не завершатся корректно.

## Пример матрицы переноса

Создайте столбцы builder host, target host, TensorRT versions, GPU capabilities, plugins, compatibility flags и итог. Для каждой целевой среды выполните загрузку, known-input inference и representative shapes. Это приемочный план без готовых результатов. Если десериализация проходит, но определенная форма входа отказывается, проверьте поддерживаемые shapes и профили engine отдельно. Не объявляйте весь перенос успешным по одному короткому запросу, который не покрывает предполагаемый рабочий диапазон, и не заменяйте диагностику случайным уменьшением input length без записи.

## Когда нужен rebuild

Если нужная среда не входит в поддерживаемую область, воспроизводимая сборка для нее предпочтительнее угадывания комбинации runtime libraries. Сохраните исходный checkpoint, build recipe и validation fixtures. После rebuild повторите функциональную и временную приемку, не предполагая идентичную скорость. Итоговый документ должен разделять «загружается», «корректно работает на нужных shapes» и «соответствует latency требованиям». Такой подход позволяет переносить поддерживаемый artifact с понятными ограничениями и не смешивает TensorRT plan portability с инструкцией современного LLM API, где предварительная engine compilation не является обязательным универсальным шагом загрузки модели. Это также предотвращает ложный вывод, что новый GPU автоматически принимает любой старый plan только потому, что относится к тому же производителю.

## Связанные материалы

[Воспроизводимый стек инференса: как сохранить результат GPU-пилота](/ru/journal/software-stack-reproducibility/); [Эталонная конфигурация GPU-узла: зачем она небольшому пулу](/ru/journal/gpu-reference-configuration/).