Ровно 294 секунды требуется инфраструктуре Tensorfuse, чтобы запустить модель Llama 3.1 8B на ускорителе L40S с нуля до первого ответа. Когда запросы к сервису приходят лишь несколько раз в день, графический процессор большую часть времени простаивает, но платить за выделенную ноду компании приходится круглосуточно. Желание оптимизировать бюджет подталкивает платформенных инженеров к схеме scale-to-zero — полному удалению подов при отсутствии нагрузки и их повторному развертыванию по требованию. Однако масштабирование LLM до нуля экономит средства на аренде железа ценой полной потери интерактивности: сервис становится непригодным для реального времени из-за затяжной инициализации движка.
В обычном веб-сервисе подъем реплики занимает считаные секунды, но здесь инфраструктура сталкивается с жестким барьером производительности. На что именно уходит почти пятиминутная пауза?
Анатомия холодного старта
Первичные замеры показывают, что физическая передача данных составляет лишь меньшую часть проблемы. У Tensorfuse из 294 секунд ожидания на скачивание модели и перенос весов в графический процессор ушло только 94 секунды.
Остальные 200 секунд потребовались на компиляцию, захват CUDA graphs, инициализацию движка и импорты. Вместо быстрой подгрузки параметров машина тратит основное время на запуск программного конвейера.
В более масштабных системах задержки возрастают многократно. В июле команда H Company рассказала, что новая реплика их крупнейших моделей выходила в готовность до 27 минут. Автоскейлер в Kubernetes добавляет поды по мере роста нагрузки от агентов, но ускорить этапы скачивания образа, компиляции и прогрева движка стандартными настройками масштабирования невозможно.
Проблема перехвата метрик
Стандартная телеметрия оборудования оказывается бесполезной для управления жизненным циклом таких контейнеров. Утилизация графического процессора при непрерывном батчинге держится около 100% при совершенно разном объеме задач, а занятая видеопамять не отражает реальное число входящих сообщений: движок vLLM заранее резервирует память под веса и KV-кэш — по умолчанию 90%.
Внутренняя очередь vllm:num_requests_waiting становится доступной на эндпоинте /metrics только после полного запуска vLLM, поэтому при отсутствии активных подов она не может подать команду на старт.
В KEDA HTTP Add-on эту задачу выполняет interceptor — обратный прокси, который считает запросы в обработке и передаёт метрики KEDA. Пока контейнер разворачивается, прокси удерживает входящие пакеты у себя. Но сам KEDA HTTP Add-on пока находится в статусе beta, что создает прямые эксплуатационные риски при внедрении в продакшене. Очередь ожидания жестко ограничена: например, лимит можно задать на уровне 200 запросов, после чего сервер начнет возвращать клиентам код ошибки 503.
Кроме того, порог входящей нагрузки для старта новой реплики, взятый из руководства llm-d, составляет 16 запросов.
Обещание нулевых затрат на простаивающее железо оборачивается жестким инженерным тупиком. Попытка гасить ноды при штатном периоде охлаждения cooldownPeriod приводит к тому, что короткая пауза в трафике удаляет только что поднятую реплику, вынуждая следующий запрос снова ждать запуска несколько минут. В итоге инженерам приходится вручную растягивать этот интервал до получаса и ограничивать масштабирование добавлением лишь одного пода за пять минут, превращая номинальный scale-to-zero в обычное удержание прогретой инфраструктуры.
Финансовые последствия пятиминутного ожидания
Для бизнеса пятиминутный простой или ожидание ответа означают прямую потерю клиентов и разрушение сценариев использования ИИ в реальном времени. Когда пользователь или автономный агент сталкивается с тем, что сервис молчит почти пять минут из-за холодного старта, бизнес теряет операционную гибкость, ради которой внедрялись языковые модели. Попытки сэкономить на аренде простаивающих графических ускорителей через scale-to-zero приводят к парадоксальному результату: компании либо платят за непрерывную работу оборудования для удержания инфраструктуры в прогретом состоянии, либо теряют пользователей, не готовых ждать инициализации программного конвейера, компиляции и захвата CUDA graphs.
Где подвох
Сэкономить на облачных счетах без потери клиентов не выйдет: классический scale-to-zero просто ломает интерактивность языковых моделей. Платформенные инженеры попадают в ловушку физики — если гасить контейнеры ради экономии аренды, то редкий входящий запрос намертво зависает из-за тяжелой инициализации движка и компиляции. В попытках обойти этот барьер команды растягивают интервалы охлаждения до получаса, но это лишь возвращает постоянную плату за постоянно прогретые графические процессоры. Красивая идея платить только за секунды чистой генерации разбилась о необходимость держать дорогие ускорители постоянно включенными.