AWS развернула Qwen3.8-2.4T-A95B на одном узле HyperPod

2,4 трлн параметров обслуживаются на одном GPU-узле

AWS опубликовала пошаговое развёртывание Qwen3.8-2.4T-A95B в Amazon SageMaker HyperPod. Это open-weight версия Qwen3.8-Max и крупнейшая модель семейства Qwen: всего в ней 2,4 трлн параметров, но на каждый token активируются 95 млрд. Такая Mixture-of-Experts схема уменьшает объём вычислений на шаге inference по сравнению с одновременной активацией всей модели, хотя полный набор weights всё равно необходимо разместить в памяти.

Целевая машина — `ml.p6-b300.48xlarge` с восемью NVIDIA B300 Blackwell Ultra. AWS указывает 2,1 ТБ совокупной GPU memory и показывает single-node serving: все восемь ускорителей одного экземпляра объединяются через tensor parallelism. Это не компактное локальное развёртывание, а способ удержать очень крупную модель внутри одного управляемого GPU-узла без межузлового model parallelism.

NVFP4 освобождает память для контекста и вычислений

Для размещения weights используется NVFP4 quantization. По расчёту AWS, модель в таком представлении помещается в доступную память p6-b300 с запасом под KV cache и activations. Сам факт размещения ещё не определяет полезную пропускную способность: размер cache меняется с длиной запросов и числом одновременных сессий, поэтому свободная после загрузки weights память становится эксплуатационным ресурсом, а не просто резервом.

Нативный context window Qwen3.8 достигает 262 тысяч tokens и может расширяться до миллиона. Эти значения описывают максимальную техническую вместимость, но не обещают одинаковой latency или точности на любой длине. Перед production-запуском нужно отдельно измерить prefill time, скорость генерации, потребление KV cache и качество на действительно длинных документах, а не считать предельный размер контекста обычным рабочим режимом.

vLLM добавляет reasoning, tools и speculative decoding

Serving stack построен на vLLM. В конфигурации включены prefix caching, automatic tool choice, парсеры для tool calls и reasoning, а также Multi-Token Prediction speculative decoding. Последний механизм предлагает следующий token через встроенную MTP-голову модели и принимает его, если основной проход подтверждает предложение. AWS начинает с одного speculative token и рекомендует наблюдать acceptance rate, а не увеличивать глубину предположений вслепую.

Endpoint использует маршрут `v1/chat/completions` и совместим с форматом OpenAI API. После запуска к нему можно обращаться стандартным OpenAI Python SDK или через `curl`; в опубликованном примере сервис не выставляется напрямую в публичный интернет. Совместимый request format упрощает перенос клиента, но не делает endpoint автоматически эквивалентным любому hosted API по authentication, limits, availability и semantics ответа.

Один Kubernetes manifest описывает весь inference endpoint

HyperPod использует Amazon EKS как control plane. Разработчик создаёт `InferenceEndpointConfig`, где указывает model source, instance type, число replicas, восемь GPU в requests и limits и аргументы vLLM. SageMaker HyperPod Inference Operator превращает эту декларацию в работающий endpoint, а AWS управляет инфраструктурным lifecycle, включая networking, storage, GPU drivers и NVIDIA device plugin.

Такое разделение уменьшает объём ручной сборки, но manifest остаётся частью production-контракта. В официальном примере присутствует `--trust-remote-code`, поэтому команда должна закреплять проверенную ревизию model repository и анализировать исполняемый код вместе с container image. Декларативный deployment делает конфигурацию повторяемой; он не заменяет контроль происхождения weights, образов и зависимостей.

Холодный запуск начинается с загрузки примерно 1,2 ТБ

При первом развёртывании HyperPod загружает с Hugging Face около 1,2 ТБ model data, затем десериализует weights на GPU и проходит health checks. AWS оценивает полный путь без локального cache в 15–30 минут, оговаривая зависимость от пропускной способности сети. Повторные старты с weights в local NVMe должны быть заметно быстрее.

Эта последовательность показывает, почему обычного статуса Kubernetes pod недостаточно. Готовность node, завершение download, загрузка weights и способность выполнить inference — разные состояния. Официальная проверка сначала ждёт `Ready`, затем получает адрес service и обращается к `/health`; для строгого production canary к этому стоит добавить короткий реальный `chat/completions` request и проверку его структуры.

Публикация даёт рецепт, но не итоговый performance profile

AWS перечисляет метрики для дальнейшей настройки: acceptance rate speculative decoding и end-to-end latency, которую можно собирать в Amazon Managed Prometheus, показывать в Grafana и использовать для KEDA autoscaling. Для узкого места в MoE dispatch компания рекомендует сначала оставить backend в режиме `auto`, а явный вариант выбирать только после profiling через `nsys` или инструменты vLLM.

В статье нет готовых значений throughput, time-to-first-token, tokens per second, latency под параллельной нагрузкой или стоимости одного запроса. Поэтому публикация подтверждает воспроизводимый путь к endpoint, но не доказывает его экономическую эффективность для конкретного workload. AWS прямо предлагает запустить `vllm bench serve` или собственный evaluation harness и получить baseline на своём распределении prompts.

Практичный pilot должен закрепить versions manifest, container и weights, прогнать смесь коротких и длинных запросов, tool calling и reasoning, измерить cold start, p50/p95 latency, throughput и GPU memory, а затем проверить restart и удаление ресурсов. Главный результат инструкции — модель масштаба 2,4 трлн параметров сведена к управляемому single-node deployment. Решение о production требует следующего шага: измеренного поведения именно на целевых данных и нагрузке.