«Не лучшая модель, а самый эффективный inference-стек»: AWS подвела итоги 13 запусков SageMaker за 2026 год

18 сентября 2026 года Amazon Web Services выпустила обзорный материал о том, что SageMaker AI добавила в inference с начала года. По собственному подсчёту AWS, за это время вышло 13 новых возможностей на двух путях развёртывания: полностью управляемых endpoints, где AWS берёт на себя инфраструктуру, масштабирование и операционный мониторинг, и SageMaker HyperPod Inference — варианта для команд, которым нужен Kubernetes-контроль над выделенными GPU-кластерами.

Обе модели оплачиваются за инстанс, а не за токен. Такой набор задач AWS объясняет природой генеративного инференса: модели занимают от десятков до сотен гигабайт, требования к задержке измеряются в токенах в секунду, холодный старт может растягиваться на минуты, пока перекачиваются контейнеры и веса, GPU-ёмкость ограничена, а традиционный мониторинг не показывает token-level сигналы, которые важны в продакшене.

Две дороги и семь измерений

Обзор построен вокруг сравнения двух путей по семи измерениям: инфраструктура, цель развёртывания, масштабирование, кастомизация и контроль, протокол API, а также класс задач, для которого каждый путь подходит лучше. Управляемые endpoints разворачиваются из консоли, SDK или CLI, масштабируются managed-автоскейлингом с Amazon CloudWatch и отдают OpenAI-совместимый API; их AWS рекомендует там, где нужны быстрое развёртывание и минимум операционной работы. HyperPod Inference управляется через kubectl, Terraform, консоль, CLI и SDK, масштабируется Karpenter, KEDA и CloudWatch, даёт доступ на уровне узлов, собственные фреймворки и AMI, протоколы HTTP и gRPC со своим балансировщиком — и рассчитан на сценарии train-to-serve в мультиоблаке и гибридной инфраструктуре.

Из 13 возможностей семь пришлись на managed endpoints и шесть — на HyperPod Inference.

Семь запусков на managed endpoints

Inference recommendations (апрель 2026) автоматизируют выбор типа инстанса, serving-контейнера и настроек оптимизации, который вручную занимает две-три недели бенчмарков по 1000+ комбинациям. SageMaker сужает пространство инстансов по архитектуре, размеру и требованиям к памяти, затем применяет техники под цель — EAGLE 3.0 speculative decoding для пропускной способности, тюнинг ядер для задержки, tensor parallelism по размеру модели, — и прогоняет NVIDIA AIPerf на реальной GPU-инфраструктуре с отчётом о доверительных интервалах. На выходе — SageMaker Model Package с готовыми конфигурациями и метриками: TTFT, inter-token latency, перцентили P50/P90/P99, пропускная способность и оценка стоимости. В показанном примере оптимизация throughput на GPT-OSS-20B дала вдвое больше токенов в секунду при той же задержке запроса; сама генерация рекомендаций дополнительной платы не требует.

Capacity-aware instance pools (май 2026) снимают единственную точку отказа прежней схемы, когда endpoint требовал один тип инстанса и падал при нехватке ёмкости. Клиент задаёт приоритетный список — до пяти типов инстансов, — и SageMaker перебирает их при создании endpoint, при scale-out и при scale-in; при сокращении первыми уходят fallback-инстансы, чтобы флот возвращался к предпочтительному железу по мере освобождения ёмкости. Метрики CloudWatch по каждому типу инстанса позволяют строить взвешенные политики масштабирования для разнородного флота, а каждая запись пула может ссылаться на отдельную оптимизированную конфигурацию модели — tensor parallelism на инстансах с большой памятью, speculative decoding на среднем уровне, квантизацию на младших fallback-вариантах.

OpenAI-совместимые API (май 2026) убирают адаптеры и переписывание авторизации для приложений на OpenAI SDK, LangChain или Strands Agents: endpoints отдают путь /openai/v1 с Chat Completions и стримингом, миграция сводится к смене URL, а аутентификация использует bearer-токены из существующих AWS-креденшелов сроком до 12 часов. Возможность доступна в 14 регионах AWS, поддерживает vLLM и SGLang из AWS Deep Learning Containers, а также собственные контейнеры с путём /v1/chat/completions; multi-model endpoints позволяют держать несколько моделей с независимым выделением ресурсов и вызывать их через тот же OpenAI SDK, включая агентные нагрузки на собственных GPU.

Container caching (июнь 2026) решает проблему scale-out, когда новому инстансу приходилось сначала вытянуть весь образ из Amazon ECR: для serving-контейнеров свыше 10 ГБ это добавляло несколько минут простоя. Кэширование предварительно загружает образы локально, не требует конфигурации, изменений кода и контейнера и включается автоматически на поддерживаемых ускорителях. На Qwen3-8B на ml.g6.2xlarge с контейнером LMI (17,7 ГБ в сжатом виде) сквозная задержка старта сократилась с 525 до 258 секунд — на 51%, а загрузка модели — с 168 до 77 секунд, поскольку образ больше не конкурирует за сеть. В отдельном анонсе AWS описывала эту же возможность как ускорение сквозной задержки до 2x при событиях масштабирования. Ранние клиенты фиксировали улучшения от 38% до 65%.

Dashboard наблюдаемости и CloudWatch Insights (июнь 2026) закрывает разрыв, из-за которого token-level задержку, давление на KV-кэш, динамику GPU-памяти и размещение inference-компонентов по зонам доступности приходилось сопоставлять вручную уже после того, как пользователи пострадали. SageMaker теперь отдаёт более 100 детальных метрик через нативный OpenTelemetry вместе с предсобранным дашбордом в Amazon CloudWatch и без инструментирования кода; новые endpoints включают наблюдаемость по умолчанию, а метрики появляются в течение двух минут после перехода в статус InService. Дашборд покрывает производительность (TTFT, inter-token latency, пропускная способность, загрузка KV-кэша, глубина очереди), ёмкость (утилизация GPU, память, температура и диски по флоту с honeycomb-визуализацией) и надёжность (распределение по зонам доступности со скорингом риска, анатомия холодного старта по фазам и история событий масштабирования); PromQL-совместимый endpoint позволяет забирать метрики в Amazon Managed Grafana с авторизацией SigV4.

Async inference inline payloads (июнь 2026) убирают обязательную выкладку каждого входного пакета в Amazon S3: API InvokeEndpointAsync теперь принимает параметр Body с полезной нагрузкой до 128 000 байт прямо в запросе. Это минус один сетевой round-trip на запрос, отсутствие входного бакета и прав s3:PutObject, немедленная валидация размера и параметров и отказ от оплаты S3 PUT за вызов; обратная совместимость сохранена, а возможность доступна в 31 регионе AWS.

Prefix-aware routing (сентябрь 2026) борется с тем, что при раздаче запросов по флоту одинаковое начало промпта — системные инструкции, извлечённые документы, история диалога — попадает на разные инстансы, и каждый пересчитывает общие токены заново. Новая стратегия использует начало запроса как отпечаток и последовательно направляет похожие промпты на один инстанс, максимизируя переиспользование KV-кэша, со встроенной защитой от перегрузки и стабильным поведением при масштабировании. В бенчмарках на Llama 3.1 70B по семи инстансам на длинном контексте с префиксами по 8 000 токенов P90 TTFT снизился на 33–37%, P50 TTFT — на 71–77%, а доля попаданий в KV-кэш выросла примерно с 25% до 82%; на коротком контексте P90 TTFT уменьшился на 24–37% при накладных расходах маршрутизации всего 1,3–1,9 миллисекунды на запрос. В исходном анонсе AWS указывала снижение P50 TTFT до 77% и рост пропускной способности до 16% при доле попаданий в кэш выше 80%. Теперь у SageMaker три стратегии маршрутизации — RANDOM по умолчанию, LEAST_OUTSTANDING_REQUESTS и PREFIX_AWARE; включается это параметрами RoutingStrategy, PrefixLength и ConcurrencyThreshold без изменений контейнера модели.

Шесть запусков на HyperPod Inference

Simplified Inference Operator on EKS (апрель 2026) снимает с команд ручное описание Deployment, Service, ConfigMap, HorizontalPodAutoscaler и проверок здоровья для каждой модели. Оператор ставится как нативный add-on EKS за один шаг через консоль, CLI, SDK, kubectl или Terraform, после чего модель разворачивается одним custom resource вместо стека низкоуровневых объектов Kubernetes. Он умеет приоритетный fallback по списку типов инстансов, встроенный автоскейлинг с CloudWatch, Amazon Managed Service for Prometheus и KEDA, управляемый AWS жизненный цикл версий и совместимости и деплой моделей прямо из SageMaker JumpStart.

Управляемый двухуровневый KV-кэш с интеллектуальной маршрутизацией адресован длинному контексту и многоходовым диалогам, где LLM пересчитывает значения attention для общих префиксов на каждом запросе. Уровень L1 живёт в CPU-памяти каждого узла для быстрого локального переиспользования, уровень L2 использует Redis для обмена между узлами, так что префикс, посчитанный одним pod, доступен остальным. Маршрутизация при этом бывает трёх видов: prefix-aware — по общим системным промптам и префиксам документов, KV-aware — по реальному состоянию кэша на инстансах, и обычный round-robin там, где переиспользование не приоритет. Вместе кэширование и маршрутизация дают до 40% сокращения задержки на длинном контексте и многоходовых сценариях по сравнению с базовой линией без кэша.

Data capture (май 2026) закрывает требования регулируемых отраслей к защищённым от подмены логам инференса для комплаенса, мониторинга дрейфа и сборки офлайн-датасетов. Захват настраивается через custom resource definition в трёх точках: сам endpoint — полный запрос и ответ на границе приложения, ALB — трафик балансировщика для видимости маршрутизации и замеров задержки, и pod модели — запрос и ответ на границе контейнера для отладки на уровне модели. Данные уходят в Amazon S3 без собственных sidecar-контейнеров и инструментирования приложения, а включать захват можно выборочно в любой из трёх точек, чтобы держать расходы на хранение пропорциональными реальным потребностям.

Disaggregated prefill and decode (июль 2026) разносит фазы обработки промпта и генерации токенов по разным GPU-пулам: когда prefill и decode делят один пул, длинный prefill блокирует генерацию для всех, кто стоит в очереди, и задержка на токен становится непредсказуемой. Поставка DPD в составе Inference Operator v3.2 выделяет prefill- и decode-GPU в отдельные пулы, а готовый KV-кэш запроса передаётся в decode-пул через EFA и GPU-Direct RDMA — прямой обмен памятью в обход CPU. Каждый пул масштабируется независимо, а на Llama 3.3 70B под смешанной нагрузкой распределения TTFT и inter-token latency оказались заметно стабильнее, чем при совместном размещении фаз; оператор сам управляет конфигурацией EFA и передачей кэша.

Набор performance-возможностей (июль 2026) добавляет интеграцию с Hugging Face Hub — деплой моделей без предварительной выкладки весов в S3, с поддержкой gated-моделей, пином ревизий и изоляцией токенов для рантаймов vLLM, TGI и SGLang, — а также загрузку модели с локального NVMe для сокращения холодного старта с автоматическим откатом к облачному хранилищу, если NVMe недоступен. Туда же входят автоматическое создание, обновление и удаление DNS-записей для пользовательских доменов инференса через Amazon Route 53 по конфигурации CRD и custom service accounts с IRSA для прав IAM на уровне pod.

Model caching (сентябрь 2026) убирает основную часть холодного старта на HyperPod. Кэш весов заранее скачивает веса моделей на локальный NVMe каждого узла, позволяя читать их примерно на 7 ГБ/с вместо ожидания загрузки по сети, а кэш образов через DaemonSet предварительно вытягивает контейнеры инференса. Оба кэша используют preferred-, а не required-планирование, поэтому pod может стартовать и на некэшированном узле с плавным откатом; жизненным цикл, включая инвалидацию при смене источника модели, управляет оператор, а включается всё добавлением секции modelCacheConfig в ресурс InferenceEndpointConfig или JumpStartModel. В исходной публикации AWS отмечает, что образы inference-серверов на vLLM или LMI весят гигабайты и качаются 5–7 минут, а модель на 145 ГБ тянется из S3 ещё 20 с лишним минут. Бенчмарки показывают примерно 60% ускорения scale-out для моделей от 57 до 145 ГБ, а среди ограничений названы собственная копия кэша на каждом узле, ёмкость NVMe и отсутствие автоопределения изменений источника по тому же пути; возможность общедоступна во всех поддерживаемых регионах HyperPod.

Что дальше

AWS обещает продолжать инвестиции на обоих путях: на стороне managed endpoints фокус сделан на более глубокую интеграцию в ландшафт ИИ-сервисов AWS, а в дорожную карту HyperPod Inference заложены дополнительные стратегии маршрутизации, более широкая поддержка фреймворков обслуживания моделей и расширенные возможности multi-region networking.

Документация и вводные руководства по всем перечисленным возможностям собраны в Amazon SageMaker Developer Guide — там же AWS предлагает начинать развёртывание. Отдельно упомянута программа Experience-Based Acceleration: она разбирает профиль инференс-нагрузки компании, модальности данных, SLA и целевые затраты, прогоняет бенчмарки и настраивает стек под инференс в масштабе.

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