Создавайте с CometAPIНужен один API для нескольких моделей?Протестируйте рабочий процесс в Playground, затем создайте API-ключ, когда модель и стоимость подойдут для вашего сценария.
Как развернуть Qwen 3.8 Max локально: аппаратное обеспечение, vLLM, SGLang и руководство по квантизации
Ниже — практическая памятка по локальному развёртыванию Qwen 3.8 Max на открытых весах Qwen3.8-2.4T-A95B с учётом GPU-требований, FP8/FP4, vLLM, SGLang, 1M-контекста и prod-оптимизаций.
1) Аппаратные требования и форматы чисел
- Архитектура/размер:
- Если это dense ~95B: FP16 весов ≈ 2 байта/параметр → ~190 ГБ только на веса (без KV-кэша и оверхеда). Нужны минимум 4×80 ГБ (A100/H100) с тензорным параллелизмом.
- Если это MoE A95B (модель с суммарно ~95B параметров, но активен поднабор экспертов): потребление VRAM ближе к «активным» параметрам. Уточняйте число активных экспертов/экспертных параметров — от этого зависит реальная планка VRAM.
- FP8:
- Полноценный FP8 (Transformer Engine/TE) требует Hopper (H100/H200) или новее. Выигрыш по памяти ≈ 2× против FP16.
- Для vLLM/SGLang обычно доступно FP8 для вычислений и/или KV-кэша; поддержка FP8 именно для весов — зависит от сборки/бекэнда.
- FP4/INT4:
- На практике чаще используется weight-only 4-bit (AWQ/GPTQ, NF4/INT4). Экономит ~4× на весах, но активации и KV остаются FP16/FP8/FP32 по настройке.
- KV-кэш и 1M контекст:
- Память KV-кэша растёт линейно с длиной контекста: ~layers × heads × head_dim × 2 (K+V) × bytes × tokens.
- Для больших моделей пер-токенный KV может составлять мегабайты. 1M токенов в полном KV нереалистичен в чистой VRAM (счёт на десятки/сотни ТБ). На практике используют:
- Paged KV (выгрузка на CPU/NVMe),
- квантованный KV (FP8/bf16),
- скользящее окно/streaming attention,
- chunked prefill и агрессивное освобождение «дальних» ключей/значений.
2) Получение весов
- Скачайте репозиторий модели (HF/safetensors):
- git lfs install
- git clone https://huggingface.co/ORG/Qwen3.8-2.4T-A95B
- Проверьте config.json: max_position_embeddings, rope_scaling, attention_impl. Для 1M желательно уже обученные или валидированные long-context веса. Если их нет — используйте RoPE-scaling (например, YaRN/NTK-aware) на свой риск качества.
Пример rope_scaling (в config.json):
{
"rope_scaling": {
"type": "yarn",
"factor": 8,
"original_max_position_embeddings": 131072
}
}
- factor подберите под целевой максимум (для 1M обычно нужен большой множитель); корректные параметры зависят от исходных настроек RoPE у Qwen 3.8.
3) Квантование весов (опционально)
- AWQ (weight-only 4-bit):
- Подготовьте отдельный репозиторий/папку с квантованной моделью AutoAWQ/GPTQ. Для vLLM/SGLang удобнее сразу указывать готовый quantized чекпоинт.
- FP8 для весов:
- Если поддерживается вашим стеком (Hopper + TE/встроенная поддержка в движке), используйте соответствующую сборку и флаги. В противном случае — используйте FP16/BF16 для весов и FP8 для KV.
4) Развёртывание с vLLM
- Требования: CUDA 12.x, PyTorch 2.1+, FlashAttention/FlashInfer (входит в vLLM), драйверы NVIDIA актуальные. Для FP8 — Hopper.
- Базовый сервер (FP16, шардирование по GPU):
vllm serve /path/to/Qwen3.8-2.4T-A95B \
--tensor-parallel-size 4 \
--dtype float16 \
--max-model-len 1048576 \
--gpu-memory-utilization 0.90 \
--max-num-seqs 256 \
--enforce-eager \
--kv-cache-dtype fp8 \
--enable-chunked-prefill \
--host 0.0.0.0 --port 8000
Ключевые моменты:
- --tensor-parallel-size: число GPU.
- --max-model-len: целевая длина контекста (например, 1,048,576).
- KV-кэш: используйте --kv-cache-dtype fp8 для экономии памяти; при необходимости настройте swap/offload.
- Включайте chunked prefill для длинного ввода.
- С AWQ (4-bit, weight-only):
vllm serve /path/to/Qwen3.8-2.4T-A95B-AWQ \
--quantization awq \
--tensor-parallel-size 2 \
--dtype float16 \
--max-model-len 1048576 \
--gpu-memory-utilization 0.95 \
--kv-cache-dtype fp8 \
--enable-chunked-prefill
Примечания:
- Указывайте именно квантованный репозиторий.
- Веса 4-bit, но активации/KV остаются FP16/FP8; производительность/качество проверьте на своих задачах.
- FP8 для весов (если доступно в вашей сборке):
- Используйте dtype/параметры TE согласно документации сборки vLLM+TE. Обязательно Hopper. Часто это билд-опция/переменные окружения. KV оставляйте fp8.
- Длинный контекст:
- Настройте rope_scaling в config.json (см. выше) или используйте override (если ваша версия vLLM поддерживает).
- Рассмотрите windowed/streaming attention, чтобы удерживать в VRAM только «окно» недавних токенов; остальное — в NVMe/CPU либо отбрасывать.
- Продакшен-настройки vLLM:
- --gpu-memory-utilization 0.9–0.95, --max-num-seqs по целевому TPS,
- включите PagedAttention v2 (по умолчанию в новых версиях),
- при больших префиллах — --enable-chunked-prefill,
- выставьте таймауты и лимиты на длину генерации,
- используйте Prometheus-метрики vLLM для автоскейлинга.
5) Развёртывание с SGLang
- Требования: CUDA 12.x, PyTorch 2.1+, FlashInfer, совместимые колёса SGLang. Для FP8 — Hopper.
- Базовый запуск (FP16):
python -m sglang.launch_server \
--model /path/to/Qwen3.8-2.4T-A95B \
--tp 4 \
--dtype float16 \
--max-model-len 1048576 \
--kv-cache-dtype fp8 \
--enable-chunked-prefill \
--host 0.0.0.0 --port 30000
- С AWQ (4-bit):
python -m sglang.launch_server \
--model /path/to/Qwen3.8-2.4T-A95B-AWQ \
--quantization awq \
--tp 2 \
--dtype float16 \
--max-model-len 1048576 \
--kv-cache-dtype fp8
- Примечания:
- Переопределяйте длину контекста через config.json (rope_scaling) у модели.
- Включите speculative decoding (если доступно в версии SGLang) с лёгкой черновой моделью — даст значительный прирост TPS при длинном контексте.
- SGLang хорош на многозапросной нагрузке (эффективный планировщик, FlashInfer). Тюньте размер батча префилла и decode-конкарренси.
6) 1M контекст на практике
- Реально держать полный 1M KV для 95B в VRAM нельзя. Рабочие стратегии:
- Prefill большими чанками с chunked prefill, далее — агрессивное окно (например, 8k–32k) для decode.
- FP8 KV-кэш, CPU/NVMe offload, при необходимости — ограничение исторического KV на уровне фреймворка.
- Алгоритмика: сжатие контекста, RAG, суммаризация, индексирование, многошаговые пайплайны вместо «сырого» 1M.
7) Оптимизация для продакшена
- Параллелизм:
- Tensor Parallel (TP) по GPU; при очень больших моделях — добавляйте Pipeline Parallel (если поддерживается сборкой).
- Закрепляйте topology (NVLink/NVSwitch приоритетен для TP).
- Память и кэш:
- FP8 KV, paged KV, оффлоад на CPU/NVMe, ограниченное окно внимания.
- Выделите достаточно системной RAM и быстрый NVMe (несколько ТБ на узел), настройте своп пространства у движка.
- Планировщик и throughput:
- Включите chunked prefill, настройте лимиты на max_num_seqs и concurrency под вашу задержку/TPS-цель.
- Спекулятивная декодировка (черновая маленькая модель) для ускорения decode.
- Квантование:
- Начните с AWQ/GPTQ 4-bit для весов (минимум усилий, сильная экономия VRAM).
- Для Hopper — рассматривайте FP8 (веса/активации) в поддерживаемой сборке, тщательно валидируйте качество.
- Стабильность и мониторинг:
- Health-checks, автоперезапуск, лимиты на длину/время запроса.
- Метрики (GPU util, VRAM, P50/P95 latency, токены/с) → автоскейлинг.
- Закрепление версий драйверов/CUDA/библиотек, реплицируемые образы контейнеров.
- Тестирование качества:
- Отдельные профили для long-context: проверяйте деградацию точности при RoPE-scaling.
- A/B: FP16 vs FP8 KV; AWQ 4-bit vs FP16; выбирайте порог, приемлемый для бизнеса.
8) Быстрые ориентиры по конфигурациям
- Минимум для FP16 (dense ~95B): 4×H100 80 ГБ (или 4–8×A100 80 ГБ) + быстрый NVMe для KV/офлоада. 1M только через окно/оффлоад.
- FP8 (Hopper): 2×H100 80 ГБ для весов может быть достаточно при FP8 весах и FP8 KV, но всё равно потребуется оффлоад для длинного контекста.
- AWQ 4-bit: 1×H100/A100 80 ГБ может уместить веса, но длинный контекст потребует оффлоад и/или окна; для стабильной нагрузки лучше 2×80 ГБ.
9) Проверка работоспособности
- Сделайте короткий прогон с max_model_len = 8k–32k, затем поэтапно увеличивайте до 128k/256k/512k/1M, измеряя:
- пиковое VRAM/CPU/NVMe потребление,
- пропускную способность префилла/декода,
- стабильность и качество ответов.
Итого: берите готовые long-context конфиги у Qwen 3.8, включайте rope_scaling, используйте FP8 для KV и weight-only 4-bit/FP8 для весов по доступности «железа», разворачивайте модель во vLLM или SGLang с тензорным параллелизмом, chunked prefill и оффлоадом KV. Для 1M контекста опирайтесь на окно внимания и/или дисковый кэш; «полный» 1M в VRAM нецелесообразен.
Deon GoodwinКоманда исследователей AI-моделей и API
Запуск Qwen3.8-Max локально теперь возможен, но выражение «Qwen 3.8 Max локально» требует важного уточнения. Хостинговый продукт Max от Alibaba и доступный для скачивания чекпойнт тесно связаны, но это не идентичные продукты.
Qwen впервые запустила управляемый сервис Max в начале августа 2026 года и выпустила Qwen3.8-2.4T-A95B как открытые веса 12 августа 2026 года. Именно этот чекпойнт вы фактически разворачиваете в своей инфраструктуре.
Это не обычный учебник «Ollama на игровом ПК». Не квантизированный чекпойнт — это Mixture-of-Experts модель с 2,4 трлн параметров, и текущий рецепт vLLM оценивает размер её весов в BF16 в 4,45 ТиБ. Даже ориентированные на продакшн варианты с 4-битной плавающей запятой всё ещё занимают примерно 1,3–1,5 ТиБ весов.
Ответ коротко: полноценный self-hosting класса Qwen 3.8 Max — это развёртывание в дата-центре. Практическая отправная точка для продакшна — ; для H200 нужно больше GPU. Для обычной рабочей станции используйте Qwen3.8-27B.
Qwen 3.8 Max и открытая модель, которую вы фактически разворачиваете
Скачиваемый чекпойнт Qwen3.8-2.4T-A95B официально описывается как каузальная языковая модель с 2,4T параметров и около 95B активируемых параметров на токен. Управляемый сервис Max добавляет продуктовые возможности, которых нет в текущем открытом чекпойнте.
Характеристика
Хостинговый сервис Qwen3.8-Max
Открытый чекпойнт Qwen3.8-2.4T-A95B
Всего параметров
2.4T
2.4T
Активных параметров
~95B
~95B
Архитектура
Разреженный MoE
Разреженный MoE
Ввод
Текст, изображение, видео
Текст
Контекст
1M управляемого контекста
262 144 нативно; расширяемо до ~1,01M
Поведение рассуждений
Управляемые/неуправляемые режимы
Требуются рассуждения; усилие настраивается
Встроенные инструменты
Доступны в управляемом сервисе
Приложение должно предоставлять инструменты
Самостоятельный хостинг
Управление весами не требуется
Да; открытый чекпойнт
Хостинговый продукт предоставляет ввод текста, изображений и видео с контекстом 1 000 000 токенов. В отличие от него, открытый чекпойнт — только для текста и имеет нативный контекст в 262 144 токена. Эта разница важна, если ваше приложение зависит от мультимодального ввода или управляемых встроенных инструментов.
Архитектура и спецификации Qwen 3.8
CometAPI уже охватывает фон модели в What is Qwen3.8 Max, поэтому это руководство по развёртыванию фокусируется на деталях, влияющих на память, параллелизм и сервинг.
Важная для развёртывания спецификация
Qwen3.8-2.4T-A95B
Всего / активных параметров
2.4T / ~95B на токен
Слоистая структура
92 слоя: 69 Gated DeltaNet + 23 full attention
Маршрутизация MoE
512 маршрутизируемых экспертов; 10 маршрутизируемых + 1 общий активны
Не интерпретируйте «95B активных параметров» как объём памяти модели в 95B. Разреженная активация снижает вычисления на токен, но система сервинга всё равно должна иметь доступ ко всему набору весов экспертов.
Снимок бенчмарков Qwen 3.8 Max
Поскольку существующий обзор Qwen3.8 Max на CometAPI уже подробно обсуждает бенчмарки, эта статья использует только релевантное для развёртывания подмножество из официальной таблицы бенчмарков модель-карты Qwen.
Бенчмарк
Qwen3.8-Max
Qwen3.7-Max
GPT-5.6 Sol (max)
Terminal Bench 2.1
86.6
74.5
88.8
SWE-bench Pro
67.7
60.6
64.6
PaperBench
93.0
64.8
90.5
FrontierSWE
73.5
40.7
—
CoWorkBench
74.8
64.6
71.5
GPQA Diamond
92.6
92.4
94.1
Официальная графика производительности Qwen3.8, опубликованная командой Qwen.
Наибольшие заявленные улучшения по сравнению с Qwen3.7-Max в этом подмножестве — PaperBench и FrontierSWE. Qwen3.8-Max также превосходит GPT-5.6 Sol в SWE-bench Pro и PaperBench, в то время как GPT-5.6 Sol остаётся впереди в Terminal Bench 2.1. Для решений о развёртывании относитесь к этим значениям как к контексту возможностей; приведённые ниже измерения по памяти и сквозной производительности более актуальны операционно.
Таблицы бенчмарков — это не универсальные рейтинги. Харнесс, таймауты, лимиты контекста, доступ к инструментам и квантизация могут менять результаты. Бенчмарките именно тот чекпойнт, точность, движок сервинга и распределение подсказок, которые планируете использовать.
Какое оборудование нужно Qwen3.8 для локального развёртывания?
Требования к GPU для Qwen3.8-2.4T-A95B
Это ключевой вопрос развёртывания. Текущий рецепт vLLM для Qwen3.8 публикует объёмы чекпойнта и реалистичные числа GPU с запасом по рантайму, что полезнее, чем оценка VRAM по числу параметров.
Точность
Объём весов
B300 (268 GB)
MI355X (288 GB)
H200 (141 GB)
Наилучшее применение
BF16
4,45 ТиБ
24 GPU
24 GPU
48 GPU
Максимальная достоверность/исследования
FP8
2,27 ТиБ
16 GPU
16 GPU
32 GPU
Высокая достоверность в продакшне
MXFP4
1,45 ТиБ
—
8 GPU
16 GPU
Практичное развёртывание на AMD
NVFP4 W4A4
1,32 ТиБ
8 GPU
—
16 GPU
Практичное развёртывание на NVIDIA
Для большинства организаций, которым действительно нужен self-hosted Qwen3.8, FP4 — практичная отправная точка. Выдающаяся конфигурация NVIDIA — NVFP4 W4A4 на 8× B300; соответствующий путь для AMD — MXFP4 на 8× MI355X.
Сервер с 8× H200 недостаточен для этих рекомендованных развертываний полного масштаба. Официальный рецепт оценивает H200 в 16 GPU для FP4, 32 для FP8 и 48 для BF16.
Требования к VRAM для Qwen3.8-27B
Qwen3.8-27B — практичная альтернатива уровня рабочей станции. Память под «сырые» веса составляет примерно 54 ГБ в BF16, 27 ГБ в FP8 и 13,5 ГБ при 4-битной точности. Накладные расходы рантайма и KV-кэш повышают фактические требования, особенно при длинных контекстах.
Точность
Ориентир по памяти весов
Практические рекомендации по развёртыванию
BF16
~54 ГБ
Используйте GPU на 64–80 ГБ в зависимости от контекста и накладных расходов.
FP8 / INT8
~27 ГБ
GPU на 40–48 ГБ обеспечивает более практичный запас по рантайму.
4-бит
~13,5 ГБ
Потребительский GPU на 20–24 ГБ может быть достаточен при умеренных длинах контекста.
Эти цифры — плановые оценки, выведенные из числа параметров. Подтвердите точный чекпойнт, формат квантизации, движок сервинга, длину контекста и настройки KV-кэша перед sizing аппаратного обеспечения для продакшна.
Можно ли запускать Qwen3.8 на потребительских GPU?
Полный Qwen3.8-2.4T-A95B непрактичен на обычных потребительских GPU, даже при агрессивной квантизации. Сообщество продемонстрировало агрессивно сжатую сборку UD-Q1_0 на 397 ГБ на четырёх системах DGX Spark, но это путь экстремальной квантизации, а не базовый вариант для сервинга, чувствительного к качеству.
Для рабочей станции или домашней лаборатории более подходящая модель — Qwen3.8-27B, открытые веса которой были выпущены 14 августа 2026 года. Эта модель на порядки проще в хостинге и является правильным выбором, если «локально» означает одну рабочую станцию, а не кластер GPU.
Прежде чем устанавливать Qwen 3.8 Max
Спланируйте инфраструктуру до выполнения команды установки. Вам понадобятся Linux, совместимый стек ускорителей, достаточно локального или общего хранилища для чекпойнта, высокоскоростные межсоединения GPU и — при跨узловой работе — сеть, спроектированная для распределённого инференса. Рецепт vLLM в настоящее время рекомендует vLLM nightly и Transformers 5.4.0 или новее.
FP8 — разумный выбор, когда вы хотите чекпойнт, предоставленный Qwen, и можете позволить себе многоузловую инфраструктуру. Официальный чекпойнт — Qwen/Qwen3.8-2.4T-A95B-FP8.
Для двух узлов и 16 GPU класса B300 запустите головной узел:
bash
export HEAD_ADDR="10.0.0.10"
vllm serve Qwen/Qwen3.8-2.4T-A95B-FP8 \
--tensor-parallel-size 16 \
--nnodes 2 \
--node-rank 0 \
--master-addr "$HEAD_ADDR" \
--max-model-len 262144 \
--kv-cache-dtype fp8 \
--reasoning-parser qwen3
On the worker node, use the same topology with a different node rank and no API server:
На рабочем узле используйте ту же топологию с другим рангом узла и без API-сервера:
Не копируйте пример с 16 GPU на серверы H200 без изменения топологии. Тот же вариант FP8 в текущем рецепте vLLM рассчитан на 32× H200.
Как запустить Qwen 3.8 на одном сервере с 8× B300
Для NVIDIA Blackwell наиболее практичная конфигурация полного масштаба — NVFP4. vLLM в настоящее время валидирует NVFP4 W4A4 с тензорным параллелизмом по восьми GPU B300.
Сборка Inferact NVFP4 — это квантизированный чекпойнт, а не оригинальный артефакт Qwen в BF16. Проверьте качество модели на своём наборе приемочных тестов, прежде чем считать её полноценной заменой BF16 или FP8.
Как развернуть Qwen 3.8 с SGLang
SGLang добавил поддержку Qwen3.8 в день релиза — 12 августа и особенно привлекателен для высокопроизводительного сервинга, префиксного кэширования, expert parallelism, speculative decoding и разнесения prefill/decode.
SGLang сообщает 346 токенов/с на вывод при размере батча 1 на TP8 B300 с MTP и существенно более высокую суммарную пропускную способность в разнесённых схемах сервинга. Рассматривайте эти числа как показатели стека сервинга, а не бенчмарки качества модели.
Тест локального совместимого с OpenAI эндпойнта
И vLLM, и SGLang предоставляют совместимые с OpenAI API, что упрощает интеграцию приложений.
python
from openai import OpenAI
client = OpenAI(
api_key="EMPTY",
base_url="http://localhost:8000/v1",
timeout=3600,
)
response = client.chat.completions.create(
model="Qwen/Qwen3.8-2.4T-A95B-FP8",
messages=[
{
"role": "user",
"content": "Design a fault-tolerant Redis architecture for three regions."
}
],
temperature=1.0,
top_p=0.95,
max_tokens=8192,
)
print(response.choices[0].message.content)
Официальная модель-карта рекомендует temperature=1.0, top_p=0.95 и top_k=20 как базовые параметры сэмплирования. Для агентных задач оставляйте достаточно бюджета на вывод для рассуждений, а не задавайте max_tokens только под конечный видимый ответ.
Не делайте 1M значением по умолчанию только потому, что это поддерживается. Большие максимальные контексты резервируют больше ёмкости кэша и могут резко снизить конкуррентность. Устанавливайте --max-model-len под реальную нагрузку.
Как улучшить производительность инференса Qwen3.8?
Используйте MTP-3 для снижения задержки одного пользователя
Qwen3.8 включает Multi-Token Prediction. В опубликованных измерениях vLLM MTP-3 увеличивает скорость вывода на пользователя с 130 до 307 токенов/с для FP8 TP16 и с 133 до 304 токенов/с для NVFP4 TP8.
Для моделей терабайтного масштаба время старта имеет значение. В одном измерении vLLM время загрузки весов сократилось с 545 с до 306 с с fastsafetensors и ленивой загрузкой.
Используйте expert parallelism для увеличения конкуррентной пропускной способности
Для высокой конкуррентности Qwen3.8 выигрывает от схем с expert-parallel, поскольку у неё 512 маршрутизируемых экспертов. vLLM сообщает до 3 200 суммарных токенов/с на GPU для FP8 EP и до 4 300 суммарных токенов/с на GPU для оптимизированной конфигурации NVFP4 DEP16.
Настройте --max-model-len для баланса VRAM и конкуррентности
Устанавливайте значение --max-model-len по самой длинной последовательности, которая действительно нужна нагрузке. Большое значение резервирует больше ёмкости KV-кэша, увеличивает давление на память и может снизить число параллельных запросов, даже если веса модели уже помещаются.
Начните с репрезентативного продакшн-процентиля, а не с максимального рекламируемого контекста модели. Проведите нагрузочное тестирование выбранного лимита с той же точностью, паттерном батчей и движком сервинга, что в продакшне, и повышайте его только при реальной необходимости большего контекста.
Локальное развёртывание Qwen 3.8 Max vs. API
Открытые веса автоматически не делают локальный инференс экономичным. Правильное решение зависит от утилизации, требований по размещению данных, штата, целевых уровней доступности и от того, нужны ли вам на самом деле мультимодальные возможности управляемой модели.
Измерение
Self-hosted Qwen3.8-2.4T-A95B
Qwen3.8-Max через CometAPI
Инфраструктура
Многогпу-сервер или кластер
Без GPU-инфраструктуры
Модальность
Текст
Текст, изображение, видео
Контекст
262K нативно; ~1,01M расширяемо
Управляемый 1M
Контроль данных
Максимальный
Облачный API
Операции
Вы отвечаете за мониторинг, обновления и HA
Управляется провайдером
Лучшее применение
Размещение данных, устойчивая утилизация, своя инфраструктурная команда
Большинство продуктовых команд и переменные нагрузки
Если у вас уже есть подходящие ускорители и стабильно высокая утилизация, self-hosting может быть оправдан. Если вы купили бы кластер только ради этой модели, Qwen3.8-Max на CometAPI обычно — путь с меньшим трением. Существующее руководство по API охватывает интеграцию с управляемым сервисом, а руководство по ценам — моделирование стоимости; поэтому эта статья остаётся сфокусированной на локальном развёртывании.
Типичные проблемы локального развёртывания Qwen 3.8
Сервер исчерпывает память GPU во время старта
Сначала уменьшите --max-model-len, если проблема в кэше. Если сами веса не помещаются, уменьшение контекста не решит корень проблемы; переходите на валидированный чекпойнт более низкой точности или добавляйте GPU.
Тензорный параллелизм не работает из-за недопустимого размера
У Qwen3.8 — 64 attention heads в слоях full-attention, поэтому vLLM требует, чтобы TP делил 64. Простые размеры TP: 1, 2, 4, 8, 16 и 32. Поэтому суммарной VRAM недостаточно для выбора топологии.
Сервер долго запускается
Загрузка от одного до нескольких терабайт весов плюс JIT ядер может занять минуты. Увеличьте VLLM_ENGINE_READY_TIMEOUT_S и проверяйте реальный эндпойнт инференса, а не полагайтесь на короткое окно старта.
Локальная модель не может обработать изображение
Это ожидаемо. Открытый чекпойнт Qwen3.8-2.4T-A95B — только для текста. Это ограничение специфично для Qwen3.8-2.4T-A95B. Qwen3.8-27B поддерживает визуальный ввод при загрузке его отдельных файлов vision projection.
Контекст 1M резко снижает пропускную способность
Уменьшите --max-model-len до самой длинной последовательности, которая действительно нужна вашей нагрузке. Наибольшее поддерживаемое окно контекста не обязательно лучший продакшн-настрой; выберите лимит контекста, который балансирует требования нагрузки, использование KV-кэша и конкуррентность.
Могут ли Ollama или LM Studio запустить Qwen 3.8 Max?
Экосистема может упаковывать сильно квантизированные веса Qwen3.8 для инференса в стиле llama.cpp, но это не следует путать с обычным десктопным рабочим процессом Ollama. Квантизированная сборка, занимающая сотни гигабайт, всё равно требует сотен гигабайт доступной памяти и связана со значительными компромиссами по качеству и производительности.
Для обычной локальной разработки правильная цель — Qwen3.8-27B. Полную модель 2,4T следует рассматривать как серверную/кластерную, даже когда экстремальные квант-сборки сообщества делают её технически запускаемой на необычном оборудовании.
Какой метод развёртывания выбрать?
Для NVIDIA Blackwell наиболее чистой отправной точкой полного масштаба является развёртывание NVFP4 на 8× B300. Для AMD соответствующая практичная конфигурация — 8× MI355X с MXFP4. Используйте FP8, когда вы отдаёте приоритет происхождению чекпойнта и качеству над размером инфраструктуры, и BF16 — только когда максимальная достоверность оправдывает требования к памяти на уровне нескольких стоек.
Для рабочей станции используйте Qwen3.8-27B. Для продуктовых команд, которым нужны возможности Max без эксплуатации GPU-кластера, используйте управляемую модель Qwen3.8-Max на CometAPI.
Заключение
Qwen3.8-Max пересёк важную границу со времени первоначального запуска API: семейство Qwen класса Max теперь имеет открытый чекпойнт 2,4T, который организации могут полностью эксплуатировать в своей инфраструктуре.
Но открытые веса — это не потребительское железо. Следы в 4,45 ТиБ для BF16, 2,27 ТиБ для FP8 и 1,3–1,5 ТиБ для FP4 делают Qwen3.8-2.4T-A95B одной из самых требовательных к инфраструктуре открытых моделей. Практический плюс в том, что vLLM и SGLang уже поддерживают эту архитектуру, а FP4 делает развёртывание на одном узле 8× B300 или 8× MI355X осуществимым.
Хостите самостоятельно, когда контроль над данными, устойчивая утилизация и владение инфраструктурой оправдывают кластер. В противном случае используйте управляемый Max API — или Qwen3.8-27B, если на самом деле вам нужна сильная модель Qwen на одной рабочей станции.
Как развернуть Qwen 3.8 Max локально: аппаратное обеспечение, vLLM, SGLang и руководство по квантизации - CometAPI
