Qwen3.8-27B: сколько видеопамяти нужно для RTX 5090 и двух GPU

Для одной RTX 5090 разумно начинать с 4-битных весов и умеренной длины контекста, затем увеличивать её по результатам проверки памяти. Поддержка 262 144 токенов у Qwen3.8-27B сама по себе не означает, что такой запрос поместится на одной карте. У настольной RTX 5090 заявлены 32 GB GDDR7, NVLink отсутствует; доступный объём нужно смотреть на своей машине.

Например, файл Unsloth UD-Q4_K_M занимает около 15,334 GiB, а KV-кэш полной последовательности из 262 144 токенов в F16 по расчёту ниже требует ещё 16 GiB. Получается 31,334 GiB до рабочих буферов и остальных расходов. Именно поэтому фраза «4-битная модель помещается в 16 ГБ» недостаточна для выбора конфигурации с длинным контекстом.

Ниже — расчёты по конфигурации модели и разбор опубликованных запусков по состоянию на 6 сентября 2026 года. Опубликованные измерения относятся к конкретным конфигурациям, а расчётные суммы не заменяют проверку пикового потребления на вашей машине. Все оценки относятся к инференсу, а не к обучению.

Сначала определите, на что уходит память

Пиковое потребление складывается из нескольких частей:

text
веса на GPU
+ KV-кэш слоёв полного внимания
+ состояния слоёв линейного внимания
+ активации, рабочие буферы и CUDA-графы
+ обработка изображений и MTP, если они включены

Qwen3.8-27B — плотная мультимодальная модель с гибридным вниманием. Из 64 слоёв только 16 используют полное внимание, остальные 48 — линейное. Штатный предел — 262 144 токена; в него входят входные данные и генерируемое продолжение. Эти параметры доступны в конфигурации Qwen3.8-27B. Обозначения 262K и 256K встречаются для одного предела: точное значение равно 256 × 1 024.

Поэтому обычный расчёт KV-кэша для 64 слоёв полного внимания завысит результат в четыре раза. Но и считать остальные 48 слоёв бесплатными нельзя: у них сохраняются состояния. В документации SGLang для одного слота состояния GDN приведены 153,9 MB при fp32 или 78,4 MB при bf16. Общее резервирование зависит от числа слотов и настроек движка. MTP — предсказание нескольких токенов для спекулятивной генерации — также требует дополнительных ресурсов, поэтому его стоит включать после проверки базовой конфигурации.

Для расчётов дальше используются двоичные GiB: 1 GiB = 1 073 741 824 байта. Десятичный GB равен 1 000 000 000 байт. Размер загрузки на сайте, паспортная память видеокарты и показания утилит могут использовать разные единицы. Сравнивайте байты либо сначала приводите всё к одной единице; не вычитайте число с подписью GB из числа с подписью GiB.

Какие веса выбирать и сколько они занимают

У официального BF16-чекпойнта сумма размеров тензоров составляет 55 562 855 904 байта, или примерно 51,75 GiB. Это указано в индексе весов BF16; заголовки файлов добавляют небольшой объём. Одной 32-гигабайтной карты для полного размещения исходных весов недостаточно.

У официальной FP8-версии суммарный размер файлов safetensors — 30 866 866 928 байт, то есть 28,747 GiB. Это не ровно половина BF16: в файлах остаются дополнительные данные и части другой точности.

Варианты GGUF ниже относятся к снимку репозитория Unsloth, а не к любой сборке с похожим названием.

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

Квантизация весов и квантизация KV-кэша — независимые настройки. Файл Q4 не означает, что кэш тоже будет 4-битным. GGUF предназначен для совместимого с ним движка, например llama.cpp; NVFP4 требует поддержки соответствующей сборки и вычислительных ядер. Переименовать формат или заменить единственный флаг для перехода между ними нельзя.

Для обработки изображений в том же репозитории есть отдельный mmproj-F16.gguf размером 927 607 488 байт, около 0,864 GiB. Помимо согласованного с моделью проектора понадобятся буферы обработки изображений. Прибавлять к текстовой оценке только размер проектора и считать это полным пиком для мультимодального запроса было бы ошибкой.

KV-кэш: от 32K до полного контекста

В слоях полного внимания модель использует четыре KV-головы размерности 256. Для одной сохранённой позиции при двухбайтовом F16/BF16 расчёт по конфигурации выглядит так:

text
2 × 16 × 4 × 256 × 2 = 65 536 байт = 64 KiB на токен
│   │    │    │    └─ байты на элемент
│   │    │    └────── размерность головы
│   │    └─────────── KV-головы
│   └─────────────── слои полного внимания
└─────────────────── K и V

В таблице — полезные данные KV-кэша одной последовательности. Состояния линейного внимания, выравнивание памяти и служебные расходы сюда не входят.

Почему FP8 и q8_0 различаются? В описании блоков llama.cpp q8_0 хранит 32 значения в 34 байтах, q4_0 — в 18 байтах. Служебные значения уже входят в расчёт этих двух столбцов. Для q8_0 и q4_0 предполагается, что оба массива, K и V, используют указанный формат. Возможность такого запуска зависит от установленной версии и поддерживаемых операций.

Из таблицы можно получить начальную оценку. Для UD-Q4_K_M на полном контексте:

• с F16-кэшем: 15,334 + 16 = 31,334 GiB;
• с q8_0-кэшем: 15,334 + 8,5 = 23,834 GiB;
• с q4_0-кэшем: 15,334 + 4,5 = 19,834 GiB.

Первый вариант оставляет слишком мало места для обычного запуска на одной RTX 5090. Второй и третий дают больший расчётный запас, однако ещё требуют проверки расхода памяти и качества длинного ответа. Квантизированный кэш нельзя считать безусловно эквивалентным F16.

Для нескольких независимых запросов учитывайте сумму сохранённых токенов. Две последовательности по 131 072 токена дают те же 262 144 позиции полного KV-кэша, но могут потребовать больше состояний и рабочих буферов. Экономию от общего префикса учитывайте только тогда, когда движок действительно переиспользует его.

Запуск на одной RTX 5090: начните с воспроизводимой базы

Перед загрузкой проверьте свободную память и версии:

bash
nvidia-smi --query-gpu=index,name,memory.total,memory.used,memory.free --format=csv
llama-server --version
llama-server --help

Дисплей, другие процессы и драйвер уже могут занимать часть памяти. Сохраните эти показания вместе с версией движка и точным названием скачанных весов: без них сравнение с чужой конфигурацией мало что объяснит.

Для GGUF можно начать с 32 768 токенов и одного запроса. Пример ниже адаптирован из параметров llama-server; проверьте поддержку этих параметров и модели в своей сборке. Замените путь после -m на скачанный файл UD-Q4_K_M:

bash
CUDA_VISIBLE_DEVICES=0 llama-server \
  -m /models/qwen3.8-27b.gguf \
  --n-gpu-layers 99 \
  --ctx-size 32768 \
  --parallel 1 \
  --flash-attn on \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --host 127.0.0.1 \
  --port 8080

Проверьте журнал загрузки: сколько слоёв действительно размещено на GPU, какие типы K/V приняты, сколько памяти выделено под кэш. Далее меняйте только длину контекста: 65 536, 131 072, затем 262 144. На каждой ступени нужен запрос соответствующей длины, а не только успешный старт сервера.

Для NVFP4 есть опубликованная база в рецепте vLLM для RTX 5090:

bash
vllm serve Inferact/Qwen3.8-27B-NVFP4 \
  --tensor-parallel-size 1 \
  --max-model-len 32768 \
  --kv-cache-dtype fp8 \
  --enforce-eager \
  --reasoning-parser qwen3

В описанном окружении без --enforce-eager возникала ошибка нехватки памяти при захвате CUDA-графа. Флаг отключает этот режим выполнения; его необходимость не следует переносить на все движки и сборки NVFP4. Замена 32768 на 262144 здесь не доказывает работоспособность полного контекста.

Две видеокарты: проверяйте каждую, а не только сумму

Две карты не образуют общий прозрачный пул памяти. Движок должен распределить между ними веса и другие данные. При тензорном параллелизме, например --tensor-parallel-size 2 в vLLM, операции разделяются между GPU и требуют обмена данными. Отсутствие NVLink у RTX 5090 не запрещает такую работу, но вторая карта не обещает двукратного ускорения.

Для двух RTX 5090 рецепт vLLM сообщает следующие результаты на версии 0.26.1rc1.dev608+g99a10304d с TP2:

Приведённый там запуск использует unsloth/Qwen3.8-27B-NVFP4, --tensor-parallel-size 2, --max-model-len 262144 и --kv-cache-dtype fp8. Ёмкость пула при старте — не измеренная скорость обработки полного контекста. Отличия сборок NVFP4 также нельзя свести к одному числу «4 бита».

В llama.cpp другой вариант — распределение слоёв. Для исходной GGUF-команды выше замените префикс на CUDA_VISIBLE_DEVICES=0,1 и добавьте:

bash
--split-mode layer --tensor-split 1,1

Согласно документации llama-server, режим layer распределяет слои и KV-кэш, а при row промежуточные данные и KV находятся на главной GPU. Для равных карт 1,1 — стартовая пропорция, которую нужно сверить с фактической памятью каждой карты. Если одна обслуживает дисплей или карты отличаются по объёму, равное деление может оказаться неудачным.

Расчёт помогает увидеть ограничения ещё до запуска. Q8_0 плюс F16-кэш на 262 144 токена — около 43,052 GiB без прочих расходов. Для двух карт по 24 GB это лишь повод проверить возможность размещения, а не обещание успеха: одна карта может переполниться раньше другой. BF16 плюс такой же кэш — примерно 67,75 GiB, что превышает даже суммарный номинальный объём двух карт по 32 GB ещё до буферов.

Если все слои не помещаются, уменьшайте контекст, выбирайте более компактные веса либо допускайте частичное размещение в оперативной памяти. Последний вариант требует запаса RAM и отдельной проверки задержки: освобождённая видеопамять не означает сохранение прежней производительности. Фиксируйте в журнале фактическое распределение, чтобы случайная выгрузка на CPU не выглядела загадочным замедлением GPU.

Что известно о 262K на одной карте

Опубликованный эксперимент MiaAI-Lab описывает 262 144 токена на одной RTX 5090, но с конкретным набором условий: веса RadixArk NVFP4, vllm==0.27.1 с переносом исправления № 40914, кэш turboquant_4bit_nc, один запрос, max-num-batched-tokens равный 512 и MTP с тремя спекулятивными токенами. Автор указывает KV-пул в 5 905 580 032 байта, то есть 5,5 GiB.

Это полезная отправная точка для точного воспроизведения, а не универсальная команда для любой установки vLLM. В репозитории отдельно отмечены искажённые ответы в стандартной конфигурации и возможные сбои при сочетании MTP с параллельными запросами. При повторении сохраняйте версии и патч; нельзя оставлять только название весов, а остальные условия считать несущественными.

Похожее ограничение есть у таблиц SGLang: потребительские конфигурации проверялись при 8 192 входных и 1 024 выходных токенах, с одним запросом. Максимальная длина в описании не превращает эти результаты в тест 262K. MTP, дополнительные запросы и изображения вводите после проверки основной текстовой нагрузки, поскольку они меняют расход памяти.

Как проверить, что длинный контекст действительно работает

Успешная загрузка модели, выделенный KV-пул, принятый запрос и полезный ответ — четыре разные проверки. Чтобы подтвердить нужный режим на своей машине:

1. Посчитайте токены окончательного запроса. Используйте токенизатор выбранного чекпойнта и тот же шаблон диалога, что применяет сервер. Учитывайте системное сообщение и историю, а для мультимодального запроса — обработку изображений. Размер текста в символах не заменяет этот подсчёт.
2. Оставьте место для ответа. При резерве 8 192 выходных токена из 262 144 остаётся максимум 253 952 токена на весь оформленный вход. Служебные токены шаблона уже должны входить в эту сумму.
3. Исключите незаметное обрезание. Сверьте фактическое число входных токенов в ответе или журнале сервера с ожидаемым. Проверьте сообщения об усечении и сдвиге контекста.
4. Дождитесь обработки входа и генерации. Следите за пиком памяти отдельно на каждой GPU. Короткий ответ на короткую реплику не проверяет буферы предварительной обработки длинного документа.
5. Проверьте сведения в разных частях текста. Добавьте известные, различимые факты в начало, середину и конец документа; попросите извлечь их и сопоставить. Затем повторите на реальных материалах. Одно удачное извлечение ещё не показывает качество всей задачи.
6. Меняйте один параметр за раз. Сравните одинаковые запросы при выбранной точности весов и кэша. Запишите задержку до первого токена, скорость продолжения, ошибки и качество результата. Только затем включайте параллельность или MTP.

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

Практический критерий выбора конфигурации — достаточный запас на вашей рабочей нагрузке и приемлемое качество ответа. Для одной RTX 5090 проверяйте этот запас, начиная с компактных весов и 32K; для двух GPU дополнительно проверяйте распределение и обмен между картами. Если вопрос уже в том, нужна ли именно 27B для вашей задачи, отдельное сравнение Qwen3.8-Flash-Next и Qwen3.8-27B поможет выбрать модель до дальнейшей настройки оборудования.