Что за модель Qwen3.8-2.4T-A95B и почему её сложно запустить
Qwen3.8-2.4T-A95B - open-weight модель на 2,4 трлн общих параметров, из которых 95 млрд активны на каждый токен. Слои собраны из двух типов: Gated DeltaNet и Gated Attention, контекст доходит до 262 000 токенов. Запустить её на одном узле реально: веса сжимаются в NVFP4 примерно до 1,2 ТБ и укладываются в 2,1 ТБ суммарной памяти GPU узла ml.p6-b300 с восемью NVIDIA B300 Blackwell Ultra. Дальше vLLM поднимает OpenAI-совместимый сервер, а манифест InferenceEndpointConfig в SageMaker HyperPod описывает, как этот сервер развернуть.
Разреженность меняет привычную логику. На генерацию каждого токена работают 95 млрд параметров, а не 2,4 трлн: роутер выбирает несколько экспертов из множества, остальные простаивают. Скорость определяет активная часть, память определяет всё целиком.
Отсюда конфликт, который задаёт весь план деплоя. MoE даёт шанс на высокий throughput, но веса приходится хранить полностью. Триллионный класс моделей упирается не в вычисления, а в объём памяти и в то, как эту память разложить по восьми картам.
Гибридная архитектура Gated DeltaNet + Gated Attention: что это даёт на практике
Два типа слоёв решают разные задачи. Gated Attention - привычный механизм с KV-cache, который растёт линейно с длиной контекста. Gated DeltaNet - линейный слой с состоянием фиксированного размера, KV-cache ему не нужен.
Для деплоя это значит: память под KV-cache платят только слои Gated Attention, а не все. На 262K токенов разница измеряется десятками гигабайт, и в бюджет узла она влезает или не влезает именно из-за этой пропорции. Второй эффект касается параллелизма. Attention-слои и экспертов MoE нужно раскладывать по восьми GPU так, чтобы коммуникация между картами не съела выигрыш от разреженности.
Почему 2,4T параметров не влезают в память без квантизации
Арифметика жёсткая и короткая.
| Формат | Байт на параметр | Размер весов | Помещается в 2,1 ТБ узла |
|---|---|---|---|
| BF16 | 2 | ~4,8 ТБ | Нет |
| FP8 | 1 | ~2,4 ТБ | Нет |
| NVFP4 | ~0,5 | ~1,2 ТБ | Да, остаётся ~0,9 ТБ |
BF16 отпадает сразу, FP8 тоже: 2,4 ТБ весов не помещаются в 2,1 ТБ, даже если забыть про KV-cache. FP8 на этой модели означал бы переход на несколько узлов и совсем другой бюджет. Один узел вытягивает только 4-битный формат.
Бюджет памяти: как NVFP4 умещает модель в один узел ml.p6-b300
Узел ml.p6-b300 даёт восемь NVIDIA B300 Blackwell Ultra и около 2,1 ТБ суммарной памяти GPU. Раскладка выглядит так: примерно 1,2 ТБ уходит на веса в NVFP4, остаток около 0,9 ТБ делят между собой KV-cache, активации, буферы коммуникации, графы CUDA и кэш префиксов. NVFP4 здесь не экзотика: Blackwell Ultra поддерживает этот формат аппаратно, поэтому декодирование не деградирует до медленного программного распаковывания.
0,9 ТБ выглядят большим числом, пока не начинаешь считать KV-cache. Он растёт линейно с длиной контекста и умножается на размер батча.
Сколько памяти остаётся под KV-cache и активации
Оценка KV-cache: число attention-слоёв умножается на число KV-голов, на длину контекста, на размер батча и на два (ключи и значения), плюс байты на элемент. При max_model_len в 262K токенов и активном батче это сотни гигабайт. На практике приходится выбирать между длиной контекста и параллелизмом запросов.
Что с этим делать:
- урезать max_model_len до реально нужного значения, а не держать максимум «на всякий случай»;
- ограничить max_num_seqs, иначе планировщик наберёт батч, который не оставит памяти под активации;
- следить за gpu_memory_utilization: слишком высокое значение приводит к OOM на пиках, слишком низкое выбрасывает память впустую;
- включить prefix caching, он экономит вычисления на повторяющихся префиксах, но сам занимает память под кэш.
При 262K контексте prefix caching перестаёт быть опцией. В агентных сценариях системный промпт и история переиспользуются десятки раз подряд, и без кэша каждый запрос заново прогоняет prefill по десяткам тысяч токенов.
NVFP4 vs FP8: что выбрать и почему
NVFP4 сжимает веса примерно вдвое сильнее FP8, и на Blackwell Ultra это нативный формат. Именно сочетание даёт возможность уложить 2,4T-модель в один узел. Плата за сжатие - риск просадки качества на задачах, чувствительных к точности весов: длинные цепочки рассуждений, редкие языки, точная арифметика внутри кода.
Проверять качество нужно на своих данных, а не на общих бенчмарках. Практика запуска NVFP4 на младших моделях Qwen разобрана в материале о Qwen 3.8 27B на одной RTX 5090: там же показано, почему NVFP4 и MTP дают разный эффект в prefill и decode, и как не спутать синтетический тест с реальной agentic-нагрузкой.
Деплой через SageMaker HyperPod: манифест InferenceEndpointConfig
HyperPod берёт на себя кластер и оркестрацию, а описание эндпоинта задаётся декларативно. Ты не пишешь скрипты запуска вручную, а указываешь в манифесте InferenceEndpointConfig, какой образ использовать, сколько GPU выделить и с какими аргументами стартовать vLLM.
Структура манифеста InferenceEndpointConfig
Критичных полей немного, и каждое влияет на то, поднимется сервис или упадёт с OOM.
# схематично: набор полей, которые описывает InferenceEndpointConfig
model:
id: <идентификатор весов Qwen3.8-2.4T-A95B>
quantization: nvfp4
container:
image: <образ vLLM со сборкой под Blackwell Ultra>
resources:
instanceType: ml.p6-b300
gpuCount: 8
env:
HF_TOKEN: <токен доступа к весам>
VLLM_TENSOR_PARALLEL_SIZE: "8"
args:
- --quantization nvfp4
- --max-model-len 262144
- --enable-prefix-caching
- --reasoning-parser qwen3
- --enable-auto-tool-choice
- --tool-call-parser <парсер вызова инструментов для Qwen>
Что здесь важно не перепутать. tensor-parallel-size обязан совпадать с числом GPU в узле, иначе vLLM не соберёт модель. Образ контейнера должен быть собран с поддержкой NVFP4 и архитектуры Blackwell Ultra, иначе квантизованные веса просто не загрузятся. Загрузка 1,2 ТБ весов из объектного хранилища занимает заметное время, поэтому локальный NVMe или быстрый сетевой том экономят десятки минут на каждом рестарте.
Запуск vLLM-сервера и проверка эндпоинта
vLLM поднимает OpenAI-совместимый HTTP-сервер. Доступны /v1/chat/completions, /v1/completions и /v1/models, поэтому клиенты, написанные под проприетарные API, переключаются сменой базового URL.
vllm serve <идентификатор весов> \
--tensor-parallel-size 8 \
--quantization nvfp4 \
--max-model-len 262144 \
--enable-prefix-caching \
--reasoning-parser qwen3 \
--enable-auto-tool-choiceПроверка после старта:
curl -s http://localhost:8000/health
curl -s http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "Qwen3.8-2.4T-A95B",
"messages": [{"role": "user", "content": "Объясни в двух абзацах, чем Gated DeltaNet отличается от обычного attention"}],
"max_tokens": 256
}'Типовые ошибки на этом этапе: OOM при первом же запросе (виноват обычно max_model_len или слишком высокий gpu_memory_utilization), несовпадение TP-размера с числом карт, недоступные веса из-за истёкшего токена. Логи vLLM показывают, сколько памяти ушло на веса и сколько осталось под KV-cache, и это первое, на что стоит смотреть.
Ключевые флаги vLLM: reasoning, tool calling и prefix caching
Три настройки определяют, будет ли эндпоинт пригоден для агентных и кодинг-нагрузок, а не только для демонстрации.
Reasoning-парсер qwen3 и параметр reasoning_effort
Reasoning-парсер отделяет блок рассуждений от финального ответа. Без него клиент получает одну строку, в которой перемешаны черновик и результат, и вынужден парсить её регулярками. Парсер qwen3 разводит эти части по разным полям ответа.
Параметр reasoning_effort управляет глубиной рассуждений. Высокий уровень даёт больше промежуточных шагов и лучший результат на сложных задачах, но заметно увеличивает latency и расход токенов на генерацию. Низкий уровень подходит для рутинных запросов: извлечение данных, короткие ответы, простые вызовы инструментов. Для агента с сотнями шагов разница в задержке накапливается, поэтому уровень усилий стоит выбирать под тип задачи, а не держать максимум по умолчанию.
Tool calling со schema-constrained decoding
Schema-constrained decoding заставляет модель генерировать JSON строго по схеме инструмента. На выходе гарантированно валидная структура с нужными полями и типами, поэтому парсер агента не падает на лишней запятой или незакрытой скобке. Для пайплайнов, где модель вызывает функции десятки раз за диалог, это убирает целый класс отказов и повторных запросов.
Включается парой флагов: auto-tool-choice разрешает модели самостоятельно выбирать инструмент, а tool-call-parser отвечает за разбор вызова в формат OpenAI API. Для Qwen нужен соответствующий парсер, иначе вызовы придут в неожиданном виде.
vLLM prefix caching: зачем включать и как это влияет на latency
Prefix caching кэширует KV для общего начала запроса: системный промпт, few-shot примеры, длинная история диалога. Если запросы начинаются одинаково, prefill по этому участку не выполняется повторно, и TTFT падает. В агентных сценариях и RAG выигрыш особенно заметен: системный промпт на десятки тысяч токенов остаётся неизменным, а меняется только хвост.
Ограничения тоже честные. Кэш занимает память, причём на длинном контексте довольно много, и при изменении префикса он инвалидируется. Если каждый запрос уникален, эффекта не будет, а память окажется занята. Схема с несколькими уровнями кэширования, включая внешнее хранилище, разобрана в кейсе запуска Qwen3.8 27B на двух RTX 3090 с DFlash2 и LMCache: там видно, где кэш ускоряет повторяющиеся запросы, а где просто усложняет стек.
MTP и параллелизм: сравнение TP, TP+MTP, TP+EP, TP+EP+MTP
Четыре конфигурации дают разный баланс между задержкой и пропускной способностью, и выбор зависит от профиля нагрузки.
TP vs EP для MoE-модели: что и когда выбирать
Tensor parallelism режет веса слоёв поперёк карт: каждая карта держит свою часть матриц, и на каждом слое требуется синхронизация. Expert parallelism раскладывает экспертов MoE по картам: запрос попадает только к нужным экспертам. Для разреженной модели EP экономичнее по коммуникациям, ведь активируется меньшая часть весов.
Сложности тоже реальны. EP чувствителен к балансировке: если роутер часто выбирает одних и тех же экспертов, часть карт простаивает, а часть захлёбывается. Разбор на живом примере, с отказом MoE-ядра без expert parallel и просадкой на насыщенном батче, есть в материале о запуске DeepSeek-V4-Flash на одном B300.
MTP-спекулятивное декодирование: как работает и что даёт
Multi-Token Prediction - нативный механизм модели, который предсказывает несколько токенов за один forward-проход. Черновые токены проверяются за один шаг, и если угаданы, число проходов через модель сокращается. Пропускная способность растёт, TTFT снижается.
Линейного выигрыша ждать не стоит. Когда модель уверена в продолжении, угадывается много токенов. На творческих задачах и ветвящихся рассуждениях энтропия растёт, доля принятых догадок падает, и ускорение тает. Кодинг с предсказуемым синтаксисом и структурированный вывод выигрывают больше, свободный текст меньше.
Итоговые бенчмарки: EP+MTP как оптимальная конфигурация
| Конфигурация | TTFT | Пропускная способность |
|---|---|---|
| TP | базовый уровень | базовый уровень |
| TP + MTP | ниже за счёт спекулятивного декодирования | выше базового |
| TP + EP | ниже, эксперты разложены по картам | выше базового |
| TP + EP + MTP | почти на 60% ниже базового | на 12,6% выше базового |
Комбинация EP и MTP выигрывает у остальных: почти 60% экономии на времени до первого токена и прирост пропускной способности 12,6%. Цифры получены на конкретном профиле запросов, и переносить их на другую нагрузку без проверки не стоит. На коротких промптах с большим батчем картина смещается в сторону throughput, на длинных одиночных запросах важнее TTFT.
Кому подходит self-hosted Qwen3.8-2.4T-A95B и какие есть ограничения
Сценарии, где собственный узел осмысленнен: агентные пайплайны с большим объёмом токенов, кодинг-ассистенты внутри закрытого контура, задачи с длинным контекстом, где нужен контроль над данными и нет желания упираться в rate-limit чужого API.
Когда self-hosted оправдан, а когда дешевле API
Главный фактор - объём. При небольших нагрузках аренда ml.p6-b300 не окупается никогда: проприетарный API выйдет дешевле. При стабильном и большом потоке токенов картина переворачивается, особенно если учесть, что квантизация NVFP4 позволяет обойтись одним узлом вместо нескольких.
Промежуточный вариант для тех, кто не готов держать GPU постоянно: управляемые эндпоинты, где платишь за время работы. Практика такого перехода, со снижением задержки с 200 до 80 мс и ростом стоимости на 24-50%, разобрана в статье о Hugging Face Inference Endpoints. А если триллионный класс не нужен, стоит сначала посмотреть, где вообще проходит граница возможностей компактных моделей: об этом есть отдельный разбор о пределах малых моделей и упоре в параметры или VRAM.
Подводные камни и что проверить перед запуском
- Доступность инстансов. ml.p6-b300 в нужном регионе может отсутствовать, а Capacity Blocks бронируются заранее.
- Квоты. Восемь GPU на узел - это отдельная квота, которую иногда приходится запрашивать заранее.
- Совместимость образа vLLM. NVFP4 требует сборки под Blackwell Ultra. Старый образ не увидит квантизованные веса.
- Бюджет памяти. Посчитайте KV-cache под свой max_model_len и размер батча до запуска, а не после первого OOM.
- Качество после квантизации. Прогоните свои задачи в NVFP4 и сравните с FP8 или BF16. Разница может проявиться именно там, где вы её не ждёте.
- Альтернативные движки. TensorRT-LLM и SGLang тоже умеют работать с крупными MoE-моделями, и на части профилей они обгоняют vLLM.
Триллионная модель на одном узле перестала быть теорией. Осталось посчитать, окупает ли она себя в вашем сценарии.