# TensorRT-LLM в Triton: переход со сборки engines на актуальный LLM API

Миграцию Triton TensorRT-LLM следует начинать с определения deployment пути, а не с автоматического повторения trtllm-build.

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

Миграцию Triton TensorRT-LLM следует начинать с определения deployment пути, а не с автоматического повторения `trtllm-build`. Актуальное руководство использует LLM API/PyTorch с конфигурацией `model.yaml` и прямым источником модели. Старые engine directories относятся к legacy workflow. Переносите контракт входа, sampling и готовности отдельно от способа загрузки. Совпадение имени backend не означает, что прежний набор файлов и аргументов остается правильным для нового пути.

## Зафиксируйте исходную архитектуру

Сохраните repository layout, версии и команды текущего deployment. [Актуальный guide](https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/getting_started/llm.html) отделяет современный LLM API от прежней последовательности конвертации checkpoint и сборки engine. Не удаляйте старые артефакты до проверки замены, но и не представляйте legacy шаг обязательным для любого текущего запуска. Миграционная карта должна показывать, какой компонент загружает веса, где находятся tokenizer и generation settings, а также каким endpoint пользуется клиент. Иначе два разных механизма легко смешать в одну неработающую инструкцию.

## Переведите конфигурацию по смыслу

[Backend README](https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/tensorrtllm_backend/README.html) связывает ключи `model.yaml` с аргументами LLM API. Сопоставляйте назначения, а не только похожие названия. Legacy scheduler или engine limit может не иметь прямого соответствия в том же файле. Для каждого перенесенного значения укажите подтвержденный источник и способ проверки effective behavior. Не обещайте поддержку любой Hugging Face модели: сверяйте support list выбранной версии и архитектуру конкретного checkpoint, даже если краткий пример руководства описывает прямую загрузку model ID.

## Пример таблицы миграции

Создайте строки «источник весов», «tokenizer/template», «sampling», «parallelism», «readiness» и «streaming». В каждой сохраните старый способ, новый способ и acceptance fixture. Это карта проверки, а не универсальный готовый config. Если значение неизвестно, обозначьте его как требующее исследования вместо переноса случайного default. Отдельно отметьте serialized TensorRT plan: его переносимость имеет собственные требования и не должна приписываться современному PyTorch LLM API только из-за общего названия TensorRT-LLM в проекте.

## Проверьте клиентский контракт

Сравните обычный и streaming запрос, формат prompt и завершение. Raw completion endpoint может не применять chat template автоматически, поэтому перенос клиента из chat API требует явной сверки. Сохраните tokenized input или контрольный rendered prompt, где это поддерживается. Проверьте output limits и условия остановки, а не только наличие правдоподобного ответа. При изменении endpoint schema приложение должно получить понятное согласованное преобразование, а не молчаливую потерю части параметров, которые раньше влияли на генерацию или возвращаемые поля.

## Приемка замены и rollback

Запустите новую конфигурацию отдельно, проверьте функциональные fixtures и representative нагрузку без выдуманных коэффициентов ускорения. Сохраните versions, source revisions, model.yaml и журнал готовности. Старый путь оставьте воспроизводимым до принятия решения о замене; это не означает необходимость поддерживать его бессрочно. Отчет должен ясно говорить, что именно мигрировано и какие возможности не подтверждены. Полезный результат — самостоятельный рабочий маршрут нового LLM API, а не смесь старой engine build инструкции с новыми настройками. Такой подход отделяет изменение backend реализации от изменения поведения клиента и позволяет объяснить различия без неверного утверждения, что любой современный TensorRT-LLM deployment обязан заранее компилировать переносимый engine для каждой модели.

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

[Воспроизводимый стек инференса: как сохранить результат GPU-пилота](/ru/journal/software-stack-reproducibility/); [Обновление LLM на GPU: как проверять новую версию небольшим запуском](/ru/journal/model-update-canary/).