Запуск Qwen3.8 27B на двух RTX 3090 требует расчета всей инференс-системы, а не только объема весов. В целевой схеме основная модель работает через vLLM, DFlash2 выступает drafter для speculative decoding, fp8 KV-cache сокращает расход VRAM, а LMCache переносит редко используемые блоки кэша в RAM и на NVMe.
Такая конфигурация имеет смысл при длинных контекстах и повторяющихся префиксах: системных инструкциях, документах RAG, истории диалогов или шагах AI-агента. Фиксированный прирост скорости гарантировать нельзя. Совместимость Qwen3.8 27B, DFlash2, fp8 KV-cache, LMCache и конкретной версии vLLM нужно проверять на выбранных релизах и собственном железе.
Главный практический вывод простой: две RTX 3090 могут дать необходимый объем GPU-памяти для крупной модели в подходящем формате весов, но стабильная работа длинного контекста зависит от свободного места под KV pool, временные буферы, scheduler и cache manager. Без совместимых изменений vLLM часть функций может перейти в fallback или не заработать вовсе.
Qwen3.8 27B на двух RTX 3090: что дает такой стек
Две RTX 3090 предоставляют суммарно 48 ГБ VRAM, однако этот объем распределен между двумя устройствами и не превращается автоматически в единый быстрый пул памяти. Tensor parallel должен корректно разделить модель, а межкарточное взаимодействие зависит от PCIe-топологии, настроек backend и конкретной реализации операций.
Вес модели занимает лишь один участок памяти. Во время работы GPU нужны буферы фреймворка, временные тензоры, служебные структуры, память под активации и KV-cache. При длинном контексте именно KV pool способен стать причиной OOM, даже если загрузка весов завершилась успешно.
- Qwen3.8 27B отвечает за итоговое качество и проверку токенов.
- DFlash2 предлагает предварительную последовательность токенов как drafter.
- Speculative decoding позволяет основной модели проверять несколько кандидатов за один цикл.
- fp8 KV-cache уменьшает объем памяти, занятый ключами и значениями attention.
- LMCache сохраняет части KV-cache в VRAM, RAM и NVMe для повторного использования.
- vLLM связывает модель, scheduler, распределение по GPU, KV-cache и endpoint.
Каждый слой закрывает отдельное ограничение. DFlash2 ускоряет decode, но не отменяет стоимость префилла. fp8 KV-cache освобождает VRAM, но требует совместимых kernels и проверки качества. LMCache сокращает повторные вычисления для знакомого префикса, но чтение из RAM или NVMe добавляет задержку.
По смыслу схема близка к serving-стекам, где DFlash2 используется как отдельный drafter, а native MTP сохраняется как запасной режим. Переносить характеристики такой конфигурации на Qwen3.8 27B без тестов нельзя. Практические результаты зависят от версии модели, формата весов, реализации attention и характера нагрузки.
Что нужно проверить до сборки
Почему веса модели, только часть расчета
При старте vLLM память распределяется между несколькими потребителями:
- весами основной модели и drafter;
- KV pool для активных последовательностей;
- рабочими буферами attention и матричных операций;
- CUDA Graph или другими служебными структурами backend;
- памятью для scheduler, токенизатора и сетевого слоя.
Размер квантованных весов дает нижнюю границу, но не описывает рабочий режим. Если после загрузки остается слишком мало VRAM, короткий запрос может пройти, а длинный контекст или второй параллельный запрос завершится OOM. Та же проблема возникает при слишком агрессивном резервировании KV pool: веса помещаются, но фреймворку не хватает памяти для временных операций.
В похожих serving-конфигурациях переход attention с bf16 на fp8 освобождает место под более крупный KV pool. Обратная ситуация приводит к нехватке памяти под кэш и framework. Для Qwen3.8 27B этот принцип нужно подтвердить отдельным замером, поскольку чужие модель и backend не дают готовых чисел.
RAM и NVMe как часть конфигурации, а не запасной план
LMCache требует заранее спроектированного storage-слоя. Проверьте свободную системную RAM, место на NVMe, скорость последовательных и случайных операций, нагрузку на CPU и устойчивость диска к длительной записи. Конкретный объем зависит от длины префиксов, числа пользователей и политики eviction.
Проверьте топологию PCIe. Две карты могут работать через разные корневые комплексы, делить пропускную способность или использовать соединение, которое ограничивает обмен тензорами. В такой системе задержка копирования влияет на итог сильнее, чем номинальная скорость отдельной операции.
Минимальный чек-лист перед сборкой:
- суммарный объем VRAM и фактическое распределение памяти между GPU;
- формат весов Qwen3.8 27B и его требования к runtime;
- поддержка нужных CUDA-операций, FP8 и tensor parallel;
- версии драйвера, CUDA, PyTorch и vLLM;
- свободная RAM для промежуточного слоя LMCache;
- быстрый NVMe с достаточным свободным пространством;
- настройки PCIe и возможность стабильной работы двух RTX 3090;
- поддержка OpenAI-compatible endpoint;
- совместимость DFlash2 и LMCache с выбранным релизом vLLM.
Релизные инструкции компонентов важнее универсальной команды из чужого примера. Интерфейсы cache manager, speculative decoding и FP8 меняются, поэтому перед сборкой нужно сверить документацию и исходный код конкретных версий.
Как KV-cache влияет на длинный контекст
Во время prefill модель читает входной текст и формирует KV-cache. При decode новые токены используют сохраненные key и value, поэтому системе не требуется заново прогонять весь уже обработанный префикс. Если кэш потерян, длинный prefill приходится выполнять повторно.
Для короткого уникального запроса эта разница может быть небольшой. Для RAG, агентских циклов и повторных обращений к одному документу она становится заметной: неизменная часть входа обрабатывается один раз, а последующие запросы используют готовые блоки.
Почему KV pool может стать главным ограничением
Расход KV-cache растет вместе с длиной контекста и числом активных последовательностей. Каждый дополнительный запрос конкурирует за тот же пул памяти. Поэтому режим с одним длинным диалогом и режим с несколькими средними диалогами могут упереться в разные ограничения.
На практике следует отдельно измерять:
- объем VRAM после загрузки модели;
- размер доступного KV pool;
- максимальную длину одной последовательности;
- число параллельных запросов до OOM;
- изменение prefill и decode при заполнении пула.
Проблема может появиться даже при стабильной генерации короткого ответа. Контекст уже занимает память, а новые токены продолжают расширять KV-cache до конца запроса.
Что меняет fp8 KV-cache
FP8 хранит KV-данные компактнее, чем bf16, и тем самым освобождает VRAM под большее число токенов или последовательностей. Выигрыш относится прежде всего к емкости памяти. Он не означает автоматического ускорения всех операций.
Перед включением fp8 KV-cache проверьте четыре условия: backend должен реально использовать FP8, GPU и kernels должны поддерживать нужные операции, масштабирование значений должно работать корректно, а модель не должна переходить в скрытый fallback. Сравните качество ответов на длинном контексте, стабильность генерации и фактический расход памяти.
Для понимания общего эффекта полезно разделять два режима. Prefill зависит от обработки входного текста и формирования кэша. Decode использует уже созданный кэш и генерирует новые токены. fp8 может увеличить доступный KV pool в обоих режимах, но DFlash2 воздействует главным образом на decode.
LMCache: перенос KV-cache из VRAM в RAM и NVMe
LMCache добавляет слой хранения между активной памятью GPU и долговременным локальным хранилищем. Горячие блоки остаются в VRAM. Менее востребованные блоки могут перемещаться в RAM, а более емкий слой размещается на NVMe. Когда повторный запрос содержит знакомый префикс, runtime пытается вернуть соответствующие блоки вместо полного префилла.
Какие данные имеет смысл кэшировать
Наибольшая польза появляется при повторении длинной неизменной части запроса:
- системной инструкции локального сервиса;
- набора документов для RAG;
- шаблона агента и его инструментов;
- истории длительного диалога;
- одного большого документа, который обрабатывается несколькими задачами.
Одноразовые запросы с уникальным префиксом редко дают высокий cache hit. В таком режиме LMCache добавляет настройки и точки отказа, но почти не сокращает вычисления.
VRAM, RAM и NVMe: компромисс емкости и задержки
VRAM обеспечивает минимальную задержку и ограниченный объем. RAM обычно вмещает больше данных, но требует копирования между CPU и GPU. NVMe дает еще большую емкость и переживает перезапуск процесса, однако чтение блоков с диска заметно медленнее доступа к VRAM.
Поэтому LMCache не превращает NVMe в расширение видеопамяти с такой же скоростью. При cache hit часть префилла может исчезнуть, но время поиска, чтения и передачи блоков остается. Итоговый выигрыш нужно оценивать целиком: сравнивать полный prefill с восстановлением кэша из каждого уровня хранения.
Почему аналогия с 3-2-1 здесь ограничена
Многоуровневое хранение можно объяснить через знакомую схему 3-2-1: несколько копий, разные носители и отдельный уровень хранения. Однако KV-cache не заменяет резервное копирование. Это производственный кэш, а не пользовательские данные.
Потеря блока KV-cache должна означать потерю ускорения. Система обязана уметь заново выполнить prefill и продолжить обработку. Транскрипты, документы, настройки и результаты нужно хранить отдельно.
DFlash2 и speculative decoding: откуда берется ускорение decode
Speculative decoding разделяет генерацию на два шага. Быстрый drafter предлагает несколько следующих токенов, затем target model проверяет их и принимает совместимый префикс. При высокой доле принятых токенов основная модель за один цикл подтверждает больше одного токена.
Что DFlash2 делает в serving-стеке
Qwen3.8 27B остается target model. DFlash2 не заменяет ее и не определяет финальный ответ. Он строит черновое продолжение, которое проверяет основная модель.
В крупных serving-стеках DFlash2 упоминается как отдельный drafter, а native MTP сохраняется как fallback. Для Qwen3.8 27B такая схема требует отдельной проверки совместимости: совпадения токенизации, формата входов, архитектурных ожиданий, интерфейсов vLLM и логики проверки кандидатов.
Когда speculative decoding помогает, а когда почти нет
Ускорение зависит от согласованности drafter с target model. Если DFlash2 часто предлагает токены, которые Qwen3.8 27B отвергает, стоимость проверки остается, а выигрыш сокращается.
Метод обычно интереснее для длинной генерации с предсказуемым продолжением. Для коротких ответов стоимость загрузки и запуска drafter может превысить пользу. Спекулятивное декодирование не сокращает задержку чтения LMCache и не устраняет повторный prefill при промахе кэша.
Проверяйте долю принятых токенов, tokens per second в decode, время одного шага, частоту fallback и загрузку обеих GPU. Одной высокой загрузки видеокарт недостаточно: нужно видеть, сколько работы реально выполняет drafter и сколько кандидатов принимает target model.
Почему для этой схемы могут потребоваться патчи vLLM
vLLM связывает сразу несколько подсистем: модель, scheduler, tensor parallel, KV-cache, speculative decoding и внешний cache manager. Штатный релиз может поддерживать каждый компонент по отдельности, но не их конкретную комбинацию.
Какие точки интеграции нужно проверить
- поддержку speculative decoding с выбранным DFlash2;
- формат KV-cache и его жизненный цикл;
- API внешнего cache manager;
- выгрузку и восстановление блоков из RAM и NVMe;
- eviction при заполнении каждого уровня хранения;
- освобождение памяти после завершения запроса;
- tensor parallel на двух GPU;
- совместимость FP8 kernels с выбранной моделью;
- поведение OpenAI-compatible endpoint при cache hit и cache miss.
Если в конкретной версии нет нужного hook или API, патч может менять scheduler, обработку KV-блоков, загрузку drafter или регистрацию backend. Названия коммитов и набор изменений нельзя надежно указать без привязки к конкретному репозиторию и релизу.
Риски запуска без совместимых изменений
Проблема может выглядеть как обычная нестабильность, хотя причина находится в несовместимом слое. Типичные направления диагностики:
- vLLM запускается в обычном режиме без speculative decoding;
- LMCache не дает cache hit, и полный prefill повторяется;
- формат FP8 заявлен в конфигурации, но backend использует другой тип;
- возникают ошибки tensor shape или dtype;
- загрузка блока из RAM или NVMe зависает;
- throughput падает из-за лишних копирований;
- KV pool учитывается неверно, что приводит к OOM;
- endpoint работает после старта, но ломается при повторных запросах.
Проверять нужно логи, счетчики cache hit и miss, сообщения о fallback, фактический тип KV-cache и изменение времени prefill. Успешная загрузка процесса сама по себе не подтверждает корректную работу всей схемы.
Пошаговая схема сборки локального стека
Этап 1. Базовый запуск модели без дополнительных оптимизаций
Сначала запустите Qwen3.8 27B на двух RTX 3090 без DFlash2 и LMCache. Подберите формат весов, проверьте tensor parallel и выполните короткий запрос через OpenAI-compatible endpoint.
Зафиксируйте исходные параметры: расход VRAM каждой карты, время загрузки, длительность prefill, скорость decode, ошибки и поведение при втором запросе. Эта точка нужна для сравнения последующих изменений.
Этап 2. Подключение fp8 KV-cache
Включите FP8 отдельно от остальных функций. Убедитесь, что runtime сообщает о выбранном формате и не использует скрытый fallback. Повторите короткий запрос, затем увеличьте длину контекста и проверьте несколько последовательностей.
Сравните объем KV pool, свободную VRAM, prefill, decode и качество ответов. При ошибке сначала вернитесь к базовому запуску и проверьте поддержку FP8 в GPU, CUDA и kernels.
Этап 3. Добавление DFlash2
После стабильной работы fp8 KV-cache подключите DFlash2. Проверьте загрузку drafter, связь с target model и наличие штатного fallback.
Для диагностики используйте короткую и длинную генерацию. Смотрите число предложенных и принятых токенов, задержку проверки, итоговый throughput и нагрузку каждой карты. Не смешивайте этот этап с LMCache, иначе источник сбоя будет трудно определить.
Этап 4. Подключение LMCache к RAM и NVMe
Настройте уровни хранения после того, как основной inference-стек уже работает. Сначала выполните запрос с длинным префиксом, затем повторите его без изменений. В логах должен появиться cache hit, а полный prefill должен сократиться или исчезнуть для совпавшей части.
Проверьте отдельные сценарии: очистка VRAM, перезапуск endpoint, заполнение RAM, нехватка места на NVMe и промах кэша. Каждый сценарий должен завершаться контролируемым fallback на обычный prefill.
Для сравнения с другими подходами полезен разбор [запуска Qwen3.8 27B в 24 ГБ VRAM через llama.cpp](https://ai-manual.ru/article/optimizatsiya-zapuska-qwen-38-27b-v-24-gb-vram-detalnyij-razbor-konfiguratsii-llamacpp-dlya-maksimalnogo-konteksta/), где отдельно показано влияние batch, MTP и памяти под кэш.
Как понять, что стек работает правильно
Минимальный набор сценариев для проверки
- Новый короткий запрос без повторяющегося префикса.
- Длинный запрос, который используется один раз.
- Повторный запрос с тем же системным промптом или документом.
- Несколько последовательных запросов с одинаковой базовой частью.
- Заполнение VRAM при длинном контексте.
- Восстановление кэша из RAM.
- Восстановление кэша из NVMe после очистки GPU-памяти или перезапуска.
Для каждого сценария записывайте prefill, decode, cache hit или miss, время восстановления блоков, объем VRAM, загрузку CPU и NVMe. Отдельно фиксируйте ошибки eviction и fallback speculative decoding.
Признаки скрытого fallback
Скрытый fallback выдает себя по наблюдаемым признакам: расход VRAM не меняется после включения FP8, повторный запрос снова выполняет полный prefill, в логах нет работы drafter, cache hit отсутствует, появляется сообщение о неподдерживаемом формате или throughput остается тем же при нагрузке, где ожидалось изменение.
Проверяйте результат на собственной рабочей нагрузке. В статье о пресетах для [Qwen3.8 27B на одной и двух RTX 5060 Ti](https://ai-manual.ru/article/rtx-5060-ti-dlya-lokalnyih-llm-prakticheskie-presetyi-i-harness-dlya-proverki-dlinnogo-konteksta/) отдельно подчеркивается необходимость измерять длинный контекст без подмены результата кэшированными входами. Это полезный принцип и для связки на RTX 3090.
При интерпретации загрузки GPU учитывайте memory-bound характер decode. Низкая загрузка одной или обеих карт не всегда означает ошибку, а высокий процент загрузки не подтверждает эффективную работу KV-cache или drafter.
Когда Qwen3.8 27B на двух RTX 3090 оправдан, а когда лучше упростить конфигурацию
Сценарии, где LMCache дает наибольший смысл
Полная схема оправдана, если сервис регулярно обрабатывает длинные повторяющиеся префиксы. К таким нагрузкам относятся локальный RAG с общей коллекцией документов, агентские циклы, многошаговая обработка одного файла, рабочие чаты с длинной историей и OpenAI-compatible приложения с большим системным промптом.
В этих случаях LMCache сокращает повторный prefill, fp8 KV-cache оставляет больше места для активных последовательностей, а DFlash2 может ускорить decode при высокой доле принятых кандидатов.
Сценарии, где достаточно базового vLLM
Упростите стек, если запросы короткие, почти каждый префикс уникален, обращений мало, а важнее простое обновление runtime и понятная диагностика. При редкой генерации стоимость обслуживания RAM, NVMe, патчей и нескольких fallback-сценариев может превысить пользу.
Сравнение с [низкими квантами Qwen3.8 27B](https://ai-manual.ru/article/qwen-38-27b-v-nizkih-kvantizatsiyah-kogda-q2-imeet-smyisl-i-chto-teryaetsya-po-sravneniyu-s-q3/) помогает оценить альтернативный путь: иногда выбор другого формата весов дает больше практической пользы, чем добавление нескольких интеграционных слоев.
Что обязательно перепроверить перед публикацией инструкции
- актуальные требования Qwen3.8 27B;
- совместимость DFlash2 с конкретной версией target model;
- поддержку fp8 KV-cache на RTX 3090 и выбранном CUDA-стеке;
- интерфейсы LMCache для RAM и NVMe;
- точный список изменений vLLM, если они нужны;
- tensor parallel на двух GPU и влияние PCIe-топологии;
- поведение при cache miss, eviction и перезапуске;
- фактические результаты prefill, decode и cache hit на целевой нагрузке.
Публиковать конкретные команды и числовые обещания стоит только после проверки указанной комбинации версий. Общие принципы позволяют спроектировать стек, но не заменяют тестирование.
Для двух RTX 3090 разумная стратегия выглядит так: сначала добиться стабильного базового запуска Qwen3.8 27B, затем отдельно проверить fp8 KV-cache, после этого подключить DFlash2 и последним добавить LMCache. Полный стек оправдан при длинных повторяющихся контекстах. Для коротких одноразовых запросов базовый vLLM обычно проще поддерживать, а его поведение легче диагностировать.