AWS нацелен на задержки SageMaker Inference с помощью кэширования моделей HyperPod и маршрутизации по префиксу

AWS добавляет две инфраструктурные функции, нацеленные на разные, но связанные узкие места при обслуживании больших языковых моделей: кэширование моделей для Amazon SageMaker HyperPod и маршрутизацию с учетом префикса для SageMaker Inference. Первая предназначена для сокращения времени, необходимого для вывода новых inference-подов в рабочее состояние; вторая — для снижения задержки ответа за счет сохранения часто повторно используемых вычислений промпта на той же инстанции.

Эти изменения особенно важны для команд, работающих с большими моделями при переменном трафике. Без кэширования событие scale-out может потребовать, чтобы новые узлы загрузили контейнерные образы и веса модели размером в несколько гигабайт, прежде чем они смогут обслуживать запросы. Без маршрутизации, учитывающей содержимое промпта, prefix cache в framework’е обслуживания может оставаться недоиспользованным, потому что идентичные части промпта распределяются по всей ферме.

Оба анонса опубликованы в AWS Machine Learning Blog, поэтому показатели производительности и операционные утверждения заявлены AWS и не проверены независимо. Вместе они описывают более скоординированный подход к уменьшению как cold start’ов инференса, так и времени до первого токена в установившемся режиме.

Кэширование HyperPod закрывает разрыв при scale-out

AWS говорит, что развертывание модели в SageMaker HyperPod может задерживаться из-за двух последовательных загрузок. Kubernetes сначала загружает образ inference-сервера из Amazon Elastic Container Registry, после чего сервер скачивает веса модели из источника вроде Amazon S3, Amazon FSx for Lustre, Hugging Face Hub или JumpStart.

Для небольших моделей этот процесс может занимать минуты. AWS приводит пример модели размером 145 ГБ, загрузка весов которой из Amazon S3 может занимать более 20 минут в зависимости от сетевых условий. Для модели вроде DeepSeek-R1, которую AWS в приведенном сценарии описывает как превышающую 600 ГБ, процесс может занимать 30 минут и более. Только загрузка контейнерного образа, по оценке AWS, занимает от пяти до семи минут для типичных многогигабайтных inference-образов.

Такая задержка создает несоответствие между autoscaling и фактической емкостью. HorizontalPodAutoscaler может быстро запросить дополнительные поды, но эти поды не смогут принимать трафик, пока не будут доступны их образы и веса. Внезапный всплеск запросов, таким образом, может вызвать операционную реакцию, которая придет на десятки минут слишком поздно.

Новая функция кэширования моделей предварительно загружает веса в локальное NVMe-хранилище на целевых узлах. AWS говорит, что HyperPod Inference Operator заранее скачивает веса, помечает узлы как готовые к кэшу и ждет завершения процесса на целевых узлах, прежде чем создавать inference-развертывание. Как только pod запускается на подготовленном узле, он может читать локально со скоростью примерно 7 ГБ/с вместо загрузки модели по сети.

AWS также предлагает отдельный кэш образов. DaemonSet предварительно загружает контейнерный образ inference на узлы, позволяя последующим pod’ам пропустить загрузку из Amazon Elastic Container Registry. Несколько развертываний, использующих один и тот же образ, могут делить этот кэш, а оператор управляет ссылками и очисткой.

Как два кэширующих механизма ведут себя в production

Кэширование весов и кэширование образов не имеют одинаковой семантики развертывания. AWS говорит, что кэширование весов может задержать создание inference-развертывания, пока все целевые узлы не будут готовы, тогда как кэширование образов не блокирует создание развертывания. Поэтому pod может стартовать до завершения кэша образа на конкретном узле и откатиться к обычной загрузке образа.

Оба механизма используют предпочтительное, а не обязательное размещение. Pod’ы направляются к узлам с горячими данными, когда это возможно, но им не запрещается работать в других местах. Если быстрый scale-out превышает число подготовленных узлов, pod может использовать исходный источник модели и загрузить свой образ обычным образом. Компромисс — более медленный старт, а не провал развертывания.

Оператор управляет двумя базовыми custom resources: ModelDataCacheConfig для весов модели и ModelImageCache для контейнерных образов. Пользователи включают кэширование через modelCacheConfig в ресурсе InferenceEndpointConfig или JumpStartModel, а не управляют этими объектами жизненного цикла напрямую.

AWS также говорит, что обновления кэша обрабатываются, когда меняется источник модели или образ. Оператор создает новый кэш, разворачивает обновленное развертывание, а затем удаляет старый кэш. Это должно предотвращать устаревшие веса и одновременно поддерживать переходы без простоя, хотя практический результат все равно будет зависеть от доступного хранилища узлов и времени, необходимого для заполнения замещающего кэша.

Маршрутизация с учетом префикса делает кэши промптов LLM полезными

Второе изменение SageMaker затрагивает другой уровень стека обслуживания. Многие запросы LLM содержат длинный повторяющийся префикс — например, системные инструкции, извлеченные документы, историю диалога или исходный код — за которым следует короткий пользовательский суффикс. Framework’и вроде vLLM и TensorRT-LLM могут повторно использовать вычисленный key-value, или KV, кэш для этого повторяющегося префикса.

Случайное распределение запросов ослабляет это преимущество в multi-instance endpoint. Если последовательные запросы с одинаковым префиксом попадают на разные машины, каждой инстанции может понадобиться пересчитать общий контекст. Новая стратегия маршрутизации SageMaker Inference с учетом префикса анализирует начало запроса и последовательно отправляет совпадающие префиксы на ту же инстанцию.

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

Стратегия настраивается для каждого production variant и может изменяться через конфигурацию endpoint без повторного разворачивания модели. AWS по-прежнему предлагает случайную маршрутизацию по умолчанию, а также маршрутизацию по наименьшему числу ожидающих запросов для workloads, где длительность запросов варьируется. Маршрутизация с учетом префикса специально нацелена на LLM workloads с общим начальным контекстом и включенным prefix cache.

Доказательства, бенчмарки и ограничения

AWS сравнила маршрутизацию с учетом префикса со случайной маршрутизацией, используя Llama 3.1 70B Instruct на семи инстансах ml.p5.48xlarge с включенными vLLM и prefix caching. В 16 тестовых конфигурациях, охватывающих различные варианты endpoint и API, AWS сообщает о снижении медианного времени до первого токена до 77%, приросте throughput до 16% и росте KV cache hit rate примерно с 25% до более чем 80%.

Это результаты бенчмарка, сообщенные вендором, а не независимая оценка. AWS говорит, что трафик в тестах оставался сбалансированным, при этом каждая инстанция получала от 13,3% до 15,4% запросов. Также сообщается о дополнительной стоимости маршрутизации в 1,3–1,9 миллисекунды на запрос по сравнению с результатами времени до первого токена модели в диапазоне от 63 до 280 миллисекунд в тестируемых конфигурациях.

Величина эффекта сильно зависит от формы workloads. AWS говорит, что более длинные общие префиксы дают больший выигрыш, потому что можно пропустить больше вычислений. Среди use cases, которые AWS выделяет, — RAG-системы, которые многократно обращаются к одному и тому же документу, многотуровые диалоги, шаблонные ассистенты и автодополнение кода. Workloads с короткими или в основном уникальными промптами должны получать меньше пользы.

Заявления по HyperPod также зависят от условий, не полностью описанных в источнике, включая доступность узлов, время заполнения кэша, емкость хранилища, формат модели и производительность сети во время первоначальной предварительной загрузки. Указанный переход от десятков минут к секундам применим, когда pod попадает на узел, где нужные данные уже закэшированы; неподготовленный узел идет по обычному пути загрузки.

Что означают изменения для команд AI-инфраструктуры

Для разработчиков и enterprise platform-команд эти анонсы разделяют два решения, которые часто считают одной проблемой задержки. Кэширование моделей улучшает эластичность: оно может быстрее сделать новую мощность полезной при росте трафика. Маршрутизация с учетом префикса повышает эффективность запросов: она может сократить повторную prefill-работу после того, как мощность уже онлайн.

Комбинация может быть полезна для RAG-приложений и ассистентов, у которых есть и всплески трафика, и большие повторяющиеся контексты. Команда может использовать HyperPod caching, чтобы подготовить узлы к scale-out, а затем применить маршрутизацию с учетом префикса, чтобы поддерживать документы или conversational prefixes теплыми по всей активной ферме. Но это не отменяет необходимости рассчитывать локальную NVMe-емкость, настраивать лимиты concurrency и измерять rate кэша на реальном трафике.

Есть также вопросы стоимости и надежности, которые покупателям нужно проверять. Хранение весов на каждом целевом узле потребляет локальное хранилище и может увеличить время подготовки перед готовностью развертывания. Приоритет префикса может улучшать задержку, но он вводит зависящее от содержимого поведение маршрутизации, которое командам следует наблюдать вместе с глубиной очереди, загрузкой инстансов, заполнением кэша и tail latency. Важными могут быть и проверки privacy/data governance, поскольку решения маршрутизации анализируют начало payload запроса, хотя AWS делает маршрутизацию автоматически.

На что смотреть дальше

Командам, оценивающим эти функции, стоит искать независимо воспроизведенные результаты на моделях, оборудовании и распределениях промптов за пределами теста AWS на Llama 3.1 70B. Наиболее полезные метрики будут включать p95 и p99 времени до первого токена, rate попаданий в кэш во время scale-out и процент запросов, попадающих на неподготовленные узлы.

Также важны операционные рекомендации по размеру локального NVMe, orchestration warm-up кэша и multi-model кластерам. Покупателям следует проверить, как подготовка кэша влияет на rollout’ы, замену узлов, spot или interruption-сценарии и быстрое масштабирование сверх предварительно загруженной фермы.

Наконец, endpoint-level controls маршрутизации AWS могут стать более значимыми по мере того, как hosted serving platforms конкурируют не только за доступ к модели, но и за предсказуемую задержку. Следующий сигнал — смогут ли клиенты использовать эти controls без существенного усложнения scheduling или без потери сбалансированного использования GPU.

Мнение Creati.ai

AWS устраняет две практические слабости в операциях LLM вместо того, чтобы вводить новую способность модели. Кэширование моделей HyperPod снижает штраф за добавление мощности, а маршрутизация с учетом префикса делает существующую оптимизацию serving — повторное использование KV cache — более надежной на нескольких инстансах.

Самый сильный кейс — предсказуемые workloads с повторяющимся контекстом и достаточным трафиком, чтобы оправдать предварительную загрузку больших моделей. Для команд, у которых в основном уникальные промпты или редкие развертывания, издержки на хранилище и подготовку могут перевесить выгоды. Бенчмарки AWS обнадеживают, но покупателям инфраструктуры следует проверить их на собственном overlap промптов, паттернах масштабирования и целевых задержках, прежде чем считать кэширование гарантированным улучшением.