Кэш torch.compile в vLLM: как переносить прогрев между релизами

Compilation cache vLLM ускоряет повторение совместимого пути запуска, но скопированная папка не доказывает совместимость нового релиза. Для переноса прогрева нужно сохранить зависимости кэша и отдельно проверить холодный и повторный старт. Изменения Python кода, runtime configuration или библиотек способны потребовать новую компиляцию. Это задача управления артефактами запуска, а не обещание одинакового времени готовности на любых серверах и GPU.

Что входит в ключ кэша

Документ об интеграции torch.compile описывает зависимость кэширования от конфигурации и кода. Поэтому папка с удачного запуска относится к определенному набору условий. Сохраните engine version, PyTorch configuration, model revision и параметры компиляции. Не ориентируйтесь только на совпадение имени модели: изменение служебного кода способно изменить вычислительный граф без нового checkpoint. В manifest полезно явно отметить, какие части окружения проверялись и каким способом было подтверждено повторное использование.

Разведите несколько уровней прогрева

Чтение весов, компиляция графов и CUDA Graph capture — разные этапы. Описание CUDA Graphs показывает связь захвата с режимами выполнения и partitions. Быстрый второй запуск может объясняться файловым кэшем ОС, даже если compilation cache не был использован. Сохраняйте временные границы этапов и соответствующие сообщения журнала. Отдельный Triton cache также не следует путать с Triton Inference Server: здесь речь идет об артефактах kernel compilation, а не о сетевом model repository.

Пример матрицы запуска

Создайте четыре записи: исходный релиз без прогрева, повтор исходного релиза, новый релиз с перенесенными артефактами и повтор нового релиза. Это структура эксперимента, а не заранее известные длительности. Для каждого случая сохраните место хранения кэша, фактические compile события и время до приемочного запроса. Если новый релиз пересоздает кэш, проверьте документированные причины инвалидирования. Не объявляйте процесс сломанным только потому, что безопасно отказался использовать несовместимый артефакт предыдущей конфигурации.

Подготовьте переносимый пакет

Пакет должен содержать manifest окружения и перечень файлов, которые действительно относятся к выбранному кэшу. Укажите владельца и доступность путей в рабочем контейнере. Перед измерением проверьте, что процесс читает нужный каталог, а не незаметно создает новый в другом месте. Не смешивайте результаты нескольких параллельных прогревов без идентификации: оператору будет трудно понять, какой запуск создал конкретный артефакт и по какой конфигурации он должен считаться действительным.

Приемка и rollback

Проведите короткий функциональный запрос после старта, затем профиль характерных batch shapes. Отсутствие compile сообщений не заменяет проверку корректного ответа. Для rollback сохраните прежнюю конфигурацию и понятный способ выполнить чистый прогрев, если старый кэш недоступен. В отчете отдельно назовите подтвержденное повторное использование и просто наблюдавшийся быстрый запуск. При обновлении runtime повторите матрицу, не превращая частный удачный перенос в универсальное правило. Важный итог — воспроизводимая процедура с версионированным manifest, позволяющая объяснить, почему сервер использовал готовый код либо запустил компиляцию заново, и сколько времени заняли именно эти этапы в конкретной проверенной среде, без выдуманных сравнений или скрытого смешивания с файловым прогревом.

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

Воспроизводимый стек инференса: как сохранить результат GPU-пилота; Автомасштабирование GPU: почему свободная карта ещё не готовая реплика.