В этом материале
Отличие повторного запуска ядер от компиляции графа: старт, установившаяся работа и разные формы запросов при выборе оптимизации инференса.
CUDA Graphs и torch.compile часто подают как альтернативные ускорители инференса. Компиляция способна преобразовать исполнение участка, а повтор CUDA Graph сокращает накладные расходы запуска поддерживаемой последовательности GPU-операций. Их можно использовать совместно. Правильный вопрос состоит в том, какие расходы присутствуют в реальном сервисе и каким механизмом они устраняются, а не в выборе наиболее знакомого названия.
Отделите преобразование от повторения
Справочник torch.compile описывает оптимизацию через backend и режимы с разными компромиссами. Компиляция не является запоминанием прошлого ответа и не отменяет исполнение модели для нового запроса с изменёнными входными данными.
Документация CUDAGraph Trees объясняет повтор и ограничения. Захваченная последовательность предъявляет требования к операциям, зависимостям и адресам памяти. Произвольный общий поток управления автоматически не повторяется. Читайте возможности выбранного релиза, не предполагая превращения любой Python-функции в один универсальный GPU-граф.
Найдите ограничивающие расходы
Профилированием разделите GPU-вычисления, промежутки запуска на CPU, разрывы графа и первую компиляцию. Официальное руководство профилирования torch.compile помогает читать соответствующие события и отличать исполнение оптимизированной области от подготовки этой области.
Нагрузка с доминирующими большими матричными операциями отличается от малых batch, где много времени проходит между ядрами. Если пользовательскую задержку определяет очередь запросов, сокращение одного запуска может почти ничего не изменить. Назовите измеренное ограничение перед сменой режима и сохраните исходную трассу для сравнения.
Учтите разнообразие форм и управления
Сервер LLM получает меняющиеся длины входов, batch, длины декодирования, иногда разные адаптеры. Запишите формы, для которых движок компилирует или захватывает граф, и случаи другого пути. Повтор одной формы полезен для диагностики, но не представляет весь рабочий трафик.
Проверьте последовательность реальных форм в характерном порядке. Ищите повторные компиляции, смену захватов и рост памяти. Улучшение одного прогретого случая способно снизить предсказуемость воркера, если множество запросов постоянно создаёт новые специализации и расходует ресурсы подготовки.
Отделите старт от установившейся работы
Измерьте готовность воркера, первый запрос, прогрев и продолжительное обслуживание. Сохраните модель, точность, attention backend и поступление запросов. До объяснения разницы подтвердите фактическое применение нужной оптимизации, а не только наличие соответствующего параметра запуска.
Считайте полезные завершения и хвост задержки вместе с памятью. Долгоживущий воркер распределяет стартовые расходы по множеству запросов. Часто заменяемый воркер может тратить на те же расходы существенную часть доступной ёмкости. Покажите оба случая, не исключая инициализацию из каждого графика.
Выберите документированный режим
Предпочитайте поддерживаемую конфигурацию движка накоплению несвязанных флагов до успешного старта. Сохраните базовый путь для сравнения корректности и неподдерживаемых форм. При изменении численного исполнения проверки результатов задач остаются необходимыми.
В выводе назовите модель, релиз, формы и срок жизни воркера. Объясните источник выигрыша: ядра, повтор, сокращение Python-работы или взаимодействие механизмов. Не перемножайте рекламные ускорения: оптимизации одинаковых накладных расходов не складываются автоматически, а дополнительная память способна изменить допустимую конкурентность воркера.
Материалы по теме
Кэш torch.compile в vLLM: как переносить прогрев между релизами, Режимы CUDA Graphs в vLLM: как заметить fallback после обновления.