Холодный старт LLM в Kubernetes: 200 из 294 секунд уходят не на загрузку весов

Идея звучит заманчиво: запросы к модели приходят несколько раз в день, а платить за GPU-ноду приходится 24/7. Логичный ход — удалять поды между запросами и поднимать их, когда появляется нагрузка. Для обычного веб-сервиса это работает: задержка в пару секунд никого не смутит. С LLM всё иначе.

Почему LLM стартует так долго

После запуска пода модели нужно скачать образ, загрузить веса в GPU, скомпилировать графы и прогреть движок. В июле команда H Company писала, что новая реплика их крупнейших моделей выходила в готовность до 27 минут. Они используют vLLM на GPU-нодах Kubernetes и добавляют реплики по мере роста нагрузки от агентов. Автоскейлер поднимает число подов быстро, но все эти этапы настройками масштабирования не ускорить.

Автор разбора ожидал, что основное время съедает загрузка весов. Публичные замеры показали другое. У Tensorfuse запуск Llama 3.1 8B на L40S занял 294 секунды. На скачивание модели и перенос весов в GPU ушло только 94. Оставшиеся 200 секунд — компиляция, захват CUDA graphs, инициализация движка и импорты.

Что можно кэшировать

Важная деталь: значительная часть этой работы повторяется при каждом старте пода, хотя её результаты можно сохранить на ноде. Это и есть главный резерв ускорения. Если держать на ноде артефакты компиляции и заранее подтягивать веса, новый под не начинает с нуля.

В полной статье автор обещает разобрать практическую часть:

• откуда KEDA получает сигнал о нагрузке, когда подов нет вообще;
• что стоит закэшировать заранее;
• какие таймауты позволят первому запросу дождаться модели;
• манифесты KEDA HTTP Add-on, DaemonSet для предзагрузки и настройки vLLM.

Отдельный пункт — сигнал о нагрузке. Когда подов нет, метрики с них взять неоткуда, поэтому нужен компонент перед сервисом. KEDA HTTP Add-on как раз перехватывает запрос, поднимает под и удерживает соединение, пока модель не будет готова. Здесь критичны таймауты: клиент, шлюз и ingress не должны оборвать соединение раньше, чем модель прогреется.

Ограничения и вывод

Даже после всех оптимизаций холодный старт не станет секундным. Если у вас интерактивный чат, где пользователь не готов ждать минуту, scale-to-zero будет плохим выбором. Для фоновых задач, внутренних инструментов, батчей и агентов, которые терпят задержку, схема может сэкономить заметные деньги.

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

И последнее: оцените профиль нагрузки честно. Если запросы редкие и предсказуемые, нулевая реплика окупается. Если пользователи ждут ответа здесь и сейчас, лучше оставить одну тёплую реплику и платить за неё, а не за потерянных клиентов.