# Qwen3.8-27B: сколько видеопамяти нужно для RTX 5090 и двух GPU > Для Qwen3.8-27B важен не только размер весов: при 262 144 токенах неквантизированный KV-кэш добавляет 16 GiB. Разбираем, какой запас оставляют разные форматы, как начать с одной RTX 5090 и что проверить при запуске на двух видеокартах. - URL: https://blog.laozhang.ai/ru/posts/qwen3-8-27b-vram-guide - Published: 2026-09-06 - Updated: 2026-09-06 - Author: LaoZhang AI Team (https://blog.laozhang.ai/ru/about) - Topic: Инструменты разработчика - Tags: Qwen3.8-27B, RTX 5090, Квантизация, Локальные LLM --- **Для одной RTX 5090 разумно начинать с 4-битных весов и умеренной длины контекста, затем увеличивать её по результатам проверки памяти.** [Поддержка 262 144 токенов у Qwen3.8-27B](https://huggingface.co/Qwen/Qwen3.8-27B) сама по себе не означает, что такой запрос поместится на одной карте. У настольной [RTX 5090 заявлены 32 GB GDDR7, NVLink отсутствует](https://www.nvidia.com/en-us/geforce/graphics-cards/50-series/rtx-5090/); доступный объём нужно смотреть на своей машине. Например, [файл Unsloth UD-Q4_K_M](https://huggingface.co/unsloth/Qwen3.8-27B-GGUF/tree/4ca720788d1e01f1bff70c033e0d0028fd02e502) занимает около 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](https://huggingface.co/Qwen/Qwen3.8-27B/blob/main/config.json). Обозначения 262K и 256K встречаются для одного предела: точное значение равно 256 × 1 024. Поэтому обычный расчёт KV-кэша для 64 слоёв полного внимания завысит результат в четыре раза. Но и считать остальные 48 слоёв бесплатными нельзя: у них сохраняются состояния. В [документации SGLang](https://docs.sglang.io/cookbook/autoregressive/Qwen/Qwen3.8-27B) для одного слота состояния 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](https://huggingface.co/Qwen/Qwen3.8-27B/blob/main/model.safetensors.index.json); заголовки файлов добавляют небольшой объём. Одной 32-гигабайтной карты для полного размещения исходных весов недостаточно. У [официальной FP8-версии](https://huggingface.co/Qwen/Qwen3.8-27B-FP8/tree/main) суммарный размер файлов safetensors — 30 866 866 928 байт, то есть 28,747 GiB. Это не ровно половина BF16: в файлах остаются дополнительные данные и части другой точности. Варианты GGUF ниже относятся к [снимку репозитория Unsloth](https://huggingface.co/unsloth/Qwen3.8-27B-GGUF/tree/4ca720788d1e01f1bff70c033e0d0028fd02e502), а не к любой сборке с похожим названием. | Вариант весов | Размер, GB | Размер, GiB | | --- | ---: | ---: | | UD-IQ4_XS | 14,253 | 13,274 | | UD-Q4_K_M | 16,464 | 15,334 | | UD-Q5_K_M | 19,772 | 18,414 | | UD-Q6_K | 21,984 | 20,474 | | Q8_0 | 29,047 | 27,052 | Это **размеры файлов**, а не измерение занятой видеопамяти. Они помогают отсеять невозможные варианты, но точный расход после загрузки определяет движок. Нельзя также ранжировать качество сборок только по числу гигабайт: проверяйте ответы на своих задачах, особенно код, числа и извлечение сведений из длинных документов. Квантизация весов и квантизация 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-кэша одной последовательности. Состояния линейного внимания, выравнивание памяти и служебные расходы сюда не входят. | Сохранено токенов | F16/BF16, GiB | FP8, идеальный объём, GiB | llama.cpp q8_0, GiB | llama.cpp q4_0, GiB | | --- | ---: | ---: | ---: | ---: | | 32 768 | 2 | 1 | 1,0625 | 0,5625 | | 65 536 | 4 | 2 | 2,125 | 1,125 | | 131 072 | 8 | 4 | 4,25 | 2,25 | | 262 144 | 16 | 8 | 8,5 | 4,5 | Почему FP8 и q8_0 различаются? В [описании блоков llama.cpp](https://github.com/ggml-org/llama.cpp/blob/master/ggml/src/ggml-common.h) 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. ![Расчёт памяти для UD-Q4_K_M при 262 144 токенах с кэшем F16, q8_0 и q4_0](https://blog.laozhang.ai/posts/ru/qwen3-8-27b-vram-guide/img/kv-cache-memory-budget.webp) Для нескольких независимых запросов учитывайте сумму сохранённых токенов. Две последовательности по 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](https://github.com/ggml-org/llama.cpp/tree/master/tools/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](https://recipes.vllm.ai/Qwen/Qwen3.8-27B): ```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: | Сборка | Веса на GPU, GiB | Ёмкость KV-пула при старте, токенов | | --- | ---: | ---: | | Официальная FP8 | 14,28 | 377 456 | | Inferact NVFP4 | 12,02 | 445 875 | | Unsloth NVFP4 | 10,64 | 920 517 | Приведённый там запуск использует `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](https://github.com/MiaAI-Lab/Qwen3.8-27B-NVFP4-RTX-5090) описывает 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](https://docs.sglang.io/cookbook/autoregressive/Qwen/Qwen3.8-27B): потребительские конфигурации проверялись при 8 192 входных и 1 024 выходных токенах, с одним запросом. Максимальная длина в описании не превращает эти результаты в тест 262K. MTP, дополнительные запросы и изображения вводите после проверки основной текстовой нагрузки, поскольку они меняют расход памяти. ## Как проверить, что длинный контекст действительно работает Успешная загрузка модели, выделенный KV-пул, принятый запрос и полезный ответ — четыре разные проверки. Чтобы подтвердить нужный режим на своей машине: 1. **Посчитайте токены окончательного запроса.** Используйте токенизатор выбранного чекпойнта и тот же шаблон диалога, что применяет сервер. Учитывайте системное сообщение и историю, а для мультимодального запроса — обработку изображений. Размер текста в символах не заменяет этот подсчёт. 2. **Оставьте место для ответа.** При резерве 8 192 выходных токена из 262 144 остаётся максимум 253 952 токена на весь оформленный вход. Служебные токены шаблона уже должны входить в эту сумму. 3. **Исключите незаметное обрезание.** Сверьте фактическое число входных токенов в ответе или журнале сервера с ожидаемым. Проверьте сообщения об усечении и сдвиге контекста. 4. **Дождитесь обработки входа и генерации.** Следите за пиком памяти отдельно на каждой GPU. Короткий ответ на короткую реплику не проверяет буферы предварительной обработки длинного документа. 5. **Проверьте сведения в разных частях текста.** Добавьте известные, различимые факты в начало, середину и конец документа; попросите извлечь их и сопоставить. Затем повторите на реальных материалах. Одно удачное извлечение ещё не показывает качество всей задачи. 6. **Меняйте один параметр за раз.** Сравните одинаковые запросы при выбранной точности весов и кэша. Запишите задержку до первого токена, скорость продолжения, ошибки и качество результата. Только затем включайте параллельность или MTP. ![Проверка запроса на 262 144 токена: резерв ответа, отсутствие обрезания и точность извлечения фактов](https://blog.laozhang.ai/posts/ru/qwen3-8-27b-vram-guide/img/full-context-validation.webp) Если ошибка возникает при загрузке весов, первым делом проверяйте их формат и размещение. Если при создании кэша — его точность, длину контекста и число запросов. Если после поступления длинного входа — рабочие буферы и размер пакета обработки токенов. При корректном запуске, но испорченном тексте проверьте совместимость движка, весов и квантизации кэша, а не только наличие свободных гигабайт. Практический критерий выбора конфигурации — достаточный запас на вашей рабочей нагрузке и приемлемое качество ответа. Для одной RTX 5090 проверяйте этот запас, начиная с компактных весов и 32K; для двух GPU дополнительно проверяйте распределение и обмен между картами. Если вопрос уже в том, нужна ли именно 27B для вашей задачи, отдельное [сравнение Qwen3.8-Flash-Next и Qwen3.8-27B](https://blog.laozhang.ai/ru/posts/qwen3-8-flash-next-vs-qwen3-8-27b) поможет выбрать модель до дальнейшей настройки оборудования. ## Источники Внешние страницы, на которые ссылается это руководство, в порядке упоминания. Последнее обновление: 2026-09-06. - [Поддержка 262 144 токенов у Qwen3.8-27B](https://huggingface.co/Qwen/Qwen3.8-27B) (huggingface.co) - [RTX 5090 заявлены 32 GB GDDR7, NVLink отсутствует](https://www.nvidia.com/en-us/geforce/graphics-cards/50-series/rtx-5090/) (nvidia.com) - [файл Unsloth UD-Q4_K_M](https://huggingface.co/unsloth/Qwen3.8-27B-GGUF/tree/4ca720788d1e01f1bff70c033e0d0028fd02e502) (huggingface.co) - [конфигурации Qwen3.8-27B](https://huggingface.co/Qwen/Qwen3.8-27B/blob/main/config.json) (huggingface.co) - [документации SGLang](https://docs.sglang.io/cookbook/autoregressive/Qwen/Qwen3.8-27B) (docs.sglang.io) - [индексе весов BF16](https://huggingface.co/Qwen/Qwen3.8-27B/blob/main/model.safetensors.index.json) (huggingface.co) - [официальной FP8-версии](https://huggingface.co/Qwen/Qwen3.8-27B-FP8/tree/main) (huggingface.co) - [описании блоков llama.cpp](https://github.com/ggml-org/llama.cpp/blob/master/ggml/src/ggml-common.h) (github.com) - [параметров llama-server](https://github.com/ggml-org/llama.cpp/tree/master/tools/server) (github.com) - [рецепте vLLM для RTX 5090](https://recipes.vllm.ai/Qwen/Qwen3.8-27B) (recipes.vllm.ai) - [Опубликованный эксперимент MiaAI-Lab](https://github.com/MiaAI-Lab/Qwen3.8-27B-NVFP4-RTX-5090) (github.com)