У GPU-инференса нашёлся неприятный налог на масштабирование: cold start GPU для 70B-класса моделей занимал до восьми минут, а после серии инфраструктурных и конфигурационных правок сократился до менее чем 30 секунд на уже прогретой ноде. Для команд, которые гоняют LLM в Kubernetes, это не косметика, а разница между нормальным автоскейлингом и сервисом, который успевает «проснуться» уже после того, как пик нагрузки ушёл.
О таких результатах 3 сентября сообщил The New Stack в материале Sajjan Gundapuneedi, который руководит разработкой вычислительной инфраструктуры EKS в AWS. Авторы замерили весь путь от создания pod до первого inference-ответа на GPU-ноде с моделью класса 70B и вместо одного узкого места нашли шесть последовательных фаз. На тёплой ноде, где железо уже поднято, время старта удалось снизить с диапазона 1,5-8 минут до менее чем 30 секунд. На полностью новой ноде показатель тоже улучшили, но уже скромнее: с 8-15 минут примерно до пяти минут, потому что часть задержки там упирается в сам факт выделения инстанса и первичную инициализацию платформы.
Разбор по слоям выглядит полезнее любого маркетингового слайда. В цепочке cold start GPU авторы выделили шесть этапов: provisioning ноды, инициализацию драйвера GPU, загрузку контейнерного образа, скачивание весов модели, компиляцию GPU-ядер и запуск самого inference-движка. Только на первый этап с Karpenter и EKS Auto Mode уходит около 60-90 секунд. Ещё 30-120 секунд может съедать инициализация движка, включая CUDA graph capture, профилирование KV cache и старт HTTP-сервера. Но самые дорогие участки меняются в зависимости от размера модели, и именно это делает материал интересным для практиков: не существует одной «волшебной кнопки», которая лечит все сценарии сразу.
Для модели объёмом 64 ГБ, которую в статье называют Qwen3.6-35B-A3B, главным тормозом оказалась компиляция через torch.compile: около 53 секунд, или 65% времени старта модели. Загрузка весов в этом случае занимала примерно 29 секунд, то есть 35%. А вот у модели на 203 ГБ, указанной как Llama-4-Scout с tensor parallelism 4, картина перевернулась. Там на загрузку весов уходило около 423 секунд, или 92% времени, а на компиляцию только 34 секунды. Проще говоря, для моделей меньше примерно 100 ГБ CPU и GPU ещё спорят, кто больше тормозит запуск, а для тяжёлых моделей сеть и объектное хранилище выходят на первый план почти без конкурентов.
Самая показательная часть истории связана не с экзотическими оптимизациями, а с тем, что многое ломается настройками по умолчанию. AWS пишет, что в типичной конфигурации оператор NVIDIA добавляет к загрузке ноды ещё 2-3 минуты, потому что компилирует kernel module драйвера на лету. В EKS Auto Mode это обходят заранее скомпилированными драйверами, и модуль просто подгружается при старте образа. Отдельно ускорили pull контейнеров за счёт SOCI, то есть seekable OCI-образов с параллельной загрузкой, а локальный NVMe instance store использовали под кэш артефактов. Для тёплого рестарта набор вообще выглядит почти обидно простым: переменные окружения плюс volume mount для кэша компиляции и весов. То есть часть восьмиминутной задержки была не «ценой больших моделей», а платой за дефолты.
Ещё интереснее история с передачей весов из S3. В статье говорится, что для 203-гигабайтной модели до оптимизации простаивало до 98% доступной полосы пропускания, потому что range-запросы обрабатывались последовательно внутри worker-потоков. Команда подстроила размер chunk под типичные SafeTensors-шарды примерно на 3-5 ГБ, выставила более агрессивный timeout и retry для медленных S3-соединений и явно настроила concurrency под число shard-файлов на каждый tensor-parallel rank. Результат для больших моделей получился почти неприличным: время загрузки весов упало с 423 до 25 секунд. Для 64-гигабайтной модели та же группа настроек сократила этап с 29 до 12 секунд. И это, пожалуй, главный практический вывод для платформенных команд: если у вас inference-платформа уже живёт в Kubernetes, то часть выигрыша лежит не в переписывании движка, а в профилировании сетевого и storage-пути до байта и до таймаута.
Для рынка здесь тоже есть понятный сигнал. В 2026 году вокруг inference-стека в Kubernetes уже хватает зрелых кирпичиков: OCI image volumes стали стабильными, Dynamic Resource Allocation даёт более внятную модель работы с GPU, Gateway API получает inference-aware расширения. Но всё это не отменяет старую инженерную правду: пользователю всё равно, сколько красивых аббревиатур у платформы, если после пересоздания pod она молчит несколько минут. Для разработчиков и SRE это означает, что метрика time to first token served начинает конкурировать по важности с привычными p95 и p99. Для бизнеса смысл ещё проще: если rolling update, scale-up или OOM recovery тянут за собой многоминутный простой дорогих GPU, вы платите не только за вычисления, но и за паузы между ними.
Следующий вопрос уже не в том, можно ли урезать cold start GPU, а в том, кто именно возьмёт на себя эту работу: команда платформы, облачный провайдер или поставщик inference-движка. Пока отрасль движется к тому, что «холодный» запуск больших моделей становится не неизбежностью, а диагностируемой суммой из шести отдельных задержек. И это меняет разговор: вместо сакрального ужаса перед 70B-моделью остаётся вполне земной список мест, где теряются минуты.