Запуск Qwen Next на связке RTX 3090 24 ГБ и CMP 170HX 64 ГБ нельзя гарантировать только по сумме видеопамяти. Номинальные 88 ГБ VRAM принадлежат двум отдельным устройствам и превращаются в рабочее пространство одной модели только при поддержке multi-GPU, распределения слоёв и нужного формата весов в выбранном backend.
Теоретически крупную модель можно разделить между RTX 3090 и CMP 170HX, а часть весов вынести в системную DRAM. Практический результат будет зависеть от версии Qwen Next, формата модели, драйвера, backend, расположения KV-кэша и характера обмена через PCIe 2.0 x4. Схема подходит для эксперимента и редких запросов, однако не обещает скорость одной большой видеокарты.
Проверять конфигурацию нужно поэтапно: сначала каждая GPU отдельно, затем multi-GPU без DRAM offload, после этого частичное размещение в RAM. Такой порядок помогает отделить несовместимость карты или модели от нехватки памяти и узкого PCIe.
Короткий ответ: Qwen Next на двух видеокартах запустится только при поддержке backend
Что означает связка RTX 3090 24 ГБ + CMP 170HX 64 ГБ
RTX 3090 и CMP 170HX дают два независимых ресурса VRAM: 24 ГБ на первой карте и 64 ГБ на второй. Операционная система может видеть обе GPU, но сам факт обнаружения устройств не создаёт общий пул памяти для Qwen Next.
Backend должен уметь распределять модель между несколькими GPU. Обычно речь идёт о layer split, когда разные слои нейросети размещаются на разных картах. При обработке запроса активации проходят через эти слои последовательно, а backend организует обмен между устройствами.
Свободная память каждой карты меньше её паспортного объёма. Часть VRAM занимают драйвер, CUDA или другой вычислительный API, рабочие буферы, графы операций и KV-кэш. Поэтому 88 ГБ нельзя считать объёмом, полностью доступным под веса.
Какие условия должны выполниться для запуска
- Поддержка архитектуры Qwen Next. Backend должен распознавать конкретный чекпойнт, его формат и операции, которые использует модель.
- Поддержка формата весов. Квантование, FP16, BF16 или 8-bit должны поддерживаться выбранной сборкой инструмента.
- Обнаружение обеих карт. Драйвер и вычислительный API должны корректно инициализировать RTX 3090 и CMP 170HX.
- Multi-GPU и распределение слоёв. Backend должен уметь направлять части одной модели на разные устройства, а не только запускать два отдельных процесса.
- CPU/DRAM offload. При нехватке VRAM инструменту нужен режим, который позволяет держать часть весов или служебных данных в системной памяти.
- Достаточный объём RAM. Оперативной памяти требуется больше, чем размер вынесенной части модели. Нужен запас под операционную систему, сам backend, KV-кэш и фоновые процессы.
- Подходящая топология PCIe. Пропускная способность PCIe 2.0 x4 может ограничить обмен между GPU и повлиять на генерацию.
Отсутствие любого пункта меняет сценарий. Если backend не умеет распределять одну модель, две карты можно использовать для двух независимых LLM-процессов, но память одной модели от этого не увеличится.
Что проверить у конкретной версии Qwen Next до настройки
Название семейства модели недостаточно для расчёта требований. До запуска нужно зафиксировать точный идентификатор Qwen Next, размер модели, формат файла, тип квантования, целевой контекст и предполагаемую нагрузку. Разные варианты одного семейства могут заметно отличаться по весу, поддерживаемым операциям и потреблению памяти.
Размер весов - не единственная статья расходов памяти
Память инференса складывается из нескольких частей:
- Веса модели. Это основной постоянный объём. Квантование уменьшает его, но не устраняет расходы на остальные компоненты.
- KV-кэш. Он хранит состояние уже обработанного контекста. При увеличении длины диалога или документа потребление памяти растёт.
- Временные буферы. Backend выделяет память под промежуточные результаты, batch, вычислительные графы и операции attention.
- Служебные расходы. Сюда входят память драйвера, runtime и структуры, необходимые для работы модели.
Файл весов может помещаться в свободную VRAM, а запуск всё равно завершится ошибкой нехватки памяти. Причиной часто становится KV-кэш. Например, модель примерно на 27 млрд параметров в Q4 может занимать около 16 ГБ, однако длинный контекст потребует дополнительный запас. Этот пример иллюстрирует принцип и не задаёт требования для конкретной версии Qwen Next.
| Компонент | Когда расход растёт | Что проверить |
|---|---|---|
| Веса | При выборе большей модели или менее агрессивного формата | Размер файла и фактическое размещение по GPU |
| KV-кэш | При длинном контексте и нескольких параллельных запросах | Расположение, тип данных и лимит контекста |
| Буферы | При увеличении batch и размера вычислительных операций | Свободную VRAM после загрузки |
| DRAM | При CPU offload и хранении части состояния в RAM | Пиковое потребление и наличие свободного запаса |
Проверка поддержки backend: llama.cpp, vLLM и альтернативы
Поддержку нужно проверять для конкретной версии backend, а не для названия проекта в целом. В llama.cpp и vLLM могут различаться возможности по multi-GPU, неоднородным картам, layer split, формату квантования, CPU offload и размещению KV-кэша.
Перед настройкой проверьте пять вопросов:
- Распознаёт ли backend архитектуру и формат выбранной версии Qwen Next?
- Можно ли явно выбрать обе GPU и задать распределение слоёв?
- Поддерживается ли совместная работа RTX 3090 и CMP 170HX в одном процессе?
- Можно ли вынести часть весов или KV-кэша в CPU/DRAM?
- Есть ли в логах сведения о фактическом размещении слоёв и использовании памяти каждого устройства?
Практические разборы multi-GPU полезны как ориентир по методике, но их параметры нельзя переносить на другую пару карт без проверки. Например, в разборе двух Radeon AI PRO R9700 отдельно показано, почему объём VRAM, KV-кэш, PCIe и offload нужно оценивать вместе.
Какой режим нагрузки планируется
Одна и та же конфигурация может оказаться приемлемой для коротких редких запросов и неудобной для постоянного чата. Заранее выберите рабочий сценарий:
| Сценарий | Главное ограничение | Что измерять |
|---|---|---|
| Одиночный чат | Задержка первого токена и скорость генерации | Время старта, latency первого токена, токены в секунду |
| Длинный контекст | Размер KV-кэша и свободная память | Пиковые VRAM и RAM, стабильность длинного запроса |
| RAG | Prefill и объём входного текста | Время обработки документов и задержку ответа |
| Несколько запросов | Параллельная нагрузка и batch | Пропускную способность, RAM и падение скорости |
| Два агента | Раздельная память каждого процесса | Стабильность процессов и конкуренцию за GPU |
Для интерактивного использования узкий канал между GPU обычно заметнее, чем при редкой проверке совместимости. Для пакетных задач важна суммарная пропускная способность, а для длинного контекста сначала нужно убедиться, что KV-кэш не вытесняет рабочие буферы.
Как распределяются VRAM и DRAM в гибридной схеме
VRAM двух карт не становится общей автоматически
Каждая GPU сохраняет собственное адресное пространство. Backend должен самостоятельно загрузить часть слоёв на RTX 3090, часть на CMP 170HX и организовать вычисления в нужном порядке.
Если multi-GPU отсутствует, процесс на RTX 3090 видит доступные ему 24 ГБ с учётом резервов. Процесс на CMP 170HX работает со своей памятью. Их можно запустить параллельно, но один диалог не получит общий контекст объёмом 88 ГБ.
Вторая карта может пригодиться для отдельной модели, агента или RAG-сервиса. Это часто проще, чем пытаться заставить неоднородные устройства работать как единый вычислительный контур.
Распределение слоёв между 3090 и CMP 170HX
Пропорция 24/64 ГБ задаёт только верхнюю границу возможного размещения. Модель не обязательно делится в той же пропорции. Backend учитывает размер отдельных слоёв, свободную память после резервов, выбранный batch, KV-кэш и собственный алгоритм раскладки.
CMP 170HX может принять большую часть весов из-за большего заявленного объёма VRAM. RTX 3090 при этом способна разместить оставшиеся слои или часть служебных буферов. Итог нужно оценивать по логам загрузки и фактическому заполнению памяти.
Неудачная раскладка проявляется по-разному: одна карта быстро заполняется, backend не находит место для очередного слоя, модель запускается с большим объёмом CPU offload или генерация резко замедляется. Поэтому распределение выбирают после базовой проверки, а не рассчитывают только по арифметике объёмов.
Что именно уходит в DRAM при частичном offload
DRAM, или системная оперативная память, может хранить часть весов, если backend поддерживает CPU offload. Это расширяет доступное пространство, но не превращает RAM в быструю VRAM.
Нужно разделять два режима:
- Постоянное хранение весов в RAM. Часть модели остаётся на CPU и обращается к ней по мере необходимости.
- Регулярная передача данных между CPU и GPU. При частых обращениях через системную шину задержка растёт на каждом проходе.
Чем больше активных данных вынесено из GPU, тем выше риск снижения скорости. При дефиците RAM операционная система начнёт вытеснять страницы, и запуск может перейти из медленного режима в нестабильный. Swap или файл подкачки не следует считать полноценной заменой оперативной памяти для интерактивного инференса.
Отдельно проверьте, где backend хранит KV-кэш. Возможность держать веса в DRAM не означает автоматическую поддержку KV offload. Эти режимы могут настраиваться независимо или вообще отсутствовать в конкретной сборке.
Одна модель на двух GPU или два независимых процесса
| Схема | Преимущество | Ограничение |
|---|---|---|
| Одна модель на двух GPU | Можно разместить модель, которая не помещается на одной карте | Нужны multi-GPU, layer split и обмен между устройствами |
| Одна модель на GPU плюс DRAM | Можно преодолеть нехватку VRAM | Растут задержки, требования к RAM и зависимость от CPU |
| Два независимых процесса | Каждая карта работает со своим агентом или сервисом | Память одного диалога не складывается между процессами |
Для независимых процессов PCIe 2.0 x4 обычно менее заметен: GPU не передают активации друг другу на каждом проходе. Такая схема подходит для отдельного чата на каждой карте, параллельного RAG и двух автономных AI-агентов.
Почему PCIe 2.0 x4 может стать главным ограничением
Разовая загрузка модели против обмена во время генерации
Узкий PCIe влияет на два разных этапа. При загрузке он увеличивает время передачи весов и подготовки устройств. После загрузки проблема сохраняется, если слои одной модели находятся на разных GPU и активации регулярно переходят между ними.
В идеальной схеме большая часть вычислений проходит внутри VRAM каждой карты, а обмен между GPU ограничен. В другой раскладке почти каждый проход требует передачи данных через PCIe 2.0 x4. Тогда медленный интерфейс становится частью критического пути генерации.
Время успешной загрузки не показывает поведение модели после старта. Оценка нужна на реальных запросах с фиксированной длиной контекста и ответа.
Когда PCIe 2.0 x4 особенно критичен
- При частом обмене активациями между RTX 3090 и CMP 170HX.
- При большом объёме данных, вынесенных из VRAM.
- При длинных ответах, когда узкий канал влияет на каждый следующий токен.
- При параллельных запросах, которые конкурируют за передачу данных.
- При RAG с крупным входным контекстом и интенсивным prefill.
Конкретные потери нельзя честно вывести без теста. Зафиксируйте задержку первого токена, скорость генерации, время загрузки и потребление VRAM/RAM. Сравнение с однокарточным режимом на той же модели покажет цену межGPU-обмена.
Когда узкий интерфейс можно терпеть
PCIe 2.0 x4 может оказаться приемлемым при редких запросах, экспериментальной проверке совместимости и невысоких требованиях к скорости. Пользователь получает возможность загрузить крупную модель, даже если повседневный комфорт от генерации ограничен.
Другой подход, два независимых процесса, уменьшает потребность в постоянном обмене между GPU. В таком режиме каждая карта обслуживает собственную задачу, а PCIe требуется главным образом для связи с CPU и системными устройствами.
Терпимость интерфейса нужно подтверждать нагрузочным тестом. Если короткий запрос отвечает приемлемо, это ещё не говорит о поведении длинного диалога, RAG и параллельной очереди.
Неоднородные GPU и эффект самого медленного этапа
RTX 3090 и CMP 170HX могут отличаться вычислительными возможностями, поддержкой драйвера, API и поведением backend. Больший объём памяти второй карты не гарантирует пропорциональный вклад в скорость.
При последовательном layer split весь проход зависит от времени каждого этапа. Быстрая карта будет ждать медленную, если следующая часть вычислений или передача активаций не готовы. Узкое место может появиться в вычислениях, PCIe, CPU offload или синхронизации.
Поэтому конфигурацию нужно оценивать по двум независимым критериям: помещается ли модель и сколько времени занимает один проход. Первый вопрос отвечает за возможность запуска, второй за пригодность для работы.
При выборе схемы полезно сопоставить этот сценарий с разбором добавления второй GPU к основной видеокарте, где отдельно разбираются VRAM, RAM, PCIe, питание и охлаждение.
Аппаратная и программная проверка перед запуском Qwen Next multi-GPU
Материнская плата, слоты и линии PCIe
До установки модели проверьте физическую и электрическую конфигурацию:
- какие слоты доступны одновременно;
- какой режим линий получает каждый слот;
- действительно ли CMP 170HX подключена через PCIe 2.0 x4;
- не отключается ли второй слот при установке накопителя или другого устройства;
- не возникает ли конфликт ресурсов при инициализации двух GPU.
Фактическую топологию нужно зафиксировать средствами ОС и драйвера до загрузки модели. Название слота на материнской плате не всегда описывает реальное число линий и их режим.
Питание и охлаждение двух GPU
Длительный инференс создаёт продолжительную нагрузку. Краткий успешный старт не подтверждает стабильную работу в течение часа или при длинном контексте.
Проверьте запас блока питания, отдельные кабели для карт, фиксацию тяжёлой платы, доступ воздуха к вентиляторам и температуру обеих GPU. Следите за троттлингом, сбросом драйвера и ошибками вычислений во время длительного запроса.
Для CMP 170HX отдельно сверяйте требования к питанию, охлаждению и способу подключения с используемой платформой. Совместимость нельзя выводить из одного факта, что карта физически устанавливается в слот.
Драйвер и обнаружение обеих карт
Начните с проверки каждой GPU отдельно. Для каждой карты нужно убедиться, что:
- драйвер завершается без ошибок;
- вычислительный API видит устройство;
- доступен ожидаемый объём памяти с учётом резервов;
- простая операция инициализации проходит успешно;
- backend не сообщает о неподдерживаемой архитектуре или формате.
После этого проверьте список устройств вместе. Если одна карта пропадает или инициализация завершается ошибкой, переходить к настройке Qwen Next рано. Для CMP 170HX потребуется отдельно сверить совместимость конкретного драйвера и backend.
Пошаговый порядок запуска: от одной карты к offload в DRAM
Шаг 1. Зафиксировать модель, формат и целевой контекст
Запишите в рабочую заметку:
- точное имя и версию Qwen Next;
- формат файла весов;
- режим точности или квантования;
- размер контекста;
- максимальную длину ответа;
- число параллельных запросов;
- требование к скорости первого токена и генерации.
Без этих параметров нельзя сопоставить размер весов с доступной VRAM. Контекст 8k и контекст 128k создают разные требования к KV-кэшу, даже если используется один файл модели.
Шаг 2. Проверить запуск на каждой карте отдельно
Сначала запустите выбранную версию Qwen Next на RTX 3090 без второй карты. Затем повторите проверку на CMP 170HX. Записывайте этап сбоя:
- До загрузки весов: возможна проблема формата, архитектуры или инициализации backend.
- При выделении памяти: не хватает VRAM, RAM или служебного запаса.
- При создании вычислительного графа: возможна неподдерживаемая операция или несовместимый API.
- При генерации: нужно проверить runtime, драйвер, охлаждение и стабильность конкретной карты.
Этот этап нужен даже при уверенности в каждой карте по отдельности. Смешанная конфигурация добавляет собственные проблемы, и без базовых результатов их трудно локализовать.
Шаг 3. Включить распределение модели между GPU без DRAM
Если обе карты работают отдельно, включите multi-GPU средствами выбранного backend. На первом запуске используйте минимальный контекст и один запрос без параллельной нагрузки.
Проверьте по логам и мониторингу:
- видит ли процесс обе GPU;
- какие слои попали на каждую карту;
- сколько VRAM осталось после загрузки;
- не возникли ли ошибки синхронизации;
- проходит ли генерация нескольких коротких ответов.
Если модель не помещается без DRAM, это ещё не повод сразу включать максимальный offload. Сначала зафиксируйте причину: нехватка места под веса, KV-кэш, буферы или неудачная раскладка слоёв.
Шаг 4. Добавить частичный CPU/DRAM offload
Вынесите в RAM минимальный объём, который нужен для загрузки. Чем меньше постоянный обмен с CPU, тем выше шанс получить приемлемую задержку.
После изменения проверьте:
- время загрузки модели;
- задержку первого токена;
- скорость генерации;
- пиковое потребление системной RAM;
- свободную память после старта;
- ошибки под нагрузкой и после повторного запуска.
Если RAM почти полностью занята, остановите эксперимент и уменьшите контекст, batch или объём offload. Система, которая формально запускает модель за счёт подкачки, редко подходит для стабильного интерактивного использования.
Шаг 5. Постепенно увеличивать контекст и нагрузку
Меняйте один параметр за раз. Сначала увеличьте контекст, затем длину ответа, после этого проверьте второй параллельный запрос. Такой порядок показывает, какая часть конфигурации достигла предела.
На каждом шаге записывайте VRAM RTX 3090, VRAM CMP 170HX, RAM, задержку первого токена, скорость генерации и наличие ошибок. Повторите каждый сценарий несколько раз, чтобы отличить стабильное поведение от случайного удачного запуска.
Для проверки длинного контекста полезно использовать одинаковый входной документ и одинаковую длину ответа. Методика сравнения режимов mmap, RAM-resident loading и KV-размещения разобрана в статье о влиянии VRAM и контекста на скорость в llama.cpp.
Типовые симптомы и направление диагностики
| Симптом | Вероятное направление проверки |
|---|---|
| OOM на GPU при загрузке | Распределение слоёв, формат весов, KV-кэш и служебный запас |
| Заполняется RAM | Размер CPU offload, контекст, batch и наличие подкачки |
| Модель загружается, но медленно отвечает | PCIe 2.0 x4, межGPU-обмен, CPU offload и неоднородность карт |
| Сбой при инициализации | Драйвер, API, архитектура карты или неподдерживаемый backend |
| Сбой после долгой работы | Температура, питание, утечка памяти, переполнение KV-кэша |
| Одна GPU почти простаивает | Неудачная раскладка слоёв или ограничение backend |
Какие схемы offload и квантования имеет смысл сравнить
FP16 или BF16 без offload
FP16 и BF16 требуют больше памяти, чем 8-bit и 4-bit варианты. Для крупной Qwen Next такая схема может не поместиться даже в суммарную доступную VRAM после учёта KV-кэша и буферов.
Если модель в нужной точности помещается на двух GPU без DRAM, схема проще для диагностики. Она уменьшает зависимость от системной памяти и регулярных обращений к CPU. Поддержку конкретного формата и вычислений всё равно нужно подтвердить для обеих карт и выбранного backend.
8-bit и 4-bit, включая Q4
8-bit обычно занимает больше памяти, чем 4-bit, и может дать другой баланс между качеством, скоростью и совместимостью. Q4 сильнее сокращает объём весов, но оставляет расходы на KV-кэш, временные буферы и служебные структуры.
Для модели примерно на 27 млрд параметров Q4 с объёмом около 16 ГБ может быть достаточно одной видеокарты по весам. При длинном контексте свободная VRAM быстро уменьшается из-за KV-кэша. Сравнивать этот пример с Qwen Next напрямую нельзя без размера и формата конкретного чекпойнта.
GPU offload без DRAM и с минимальным DRAM offload
Полное размещение на GPU предпочтительно по задержке, если модель, KV-кэш и буферы помещаются с запасом. В multi-GPU-сценарии это требует корректного layer split и стабильного обмена между картами.
Минимальный DRAM offload помогает преодолеть нехватку VRAM. Цена решения, дополнительная задержка, нагрузка на CPU и требования к RAM. Если вынесенная часть модели используется в каждом проходе, падение скорости может быть заметнее, чем ожидалось по одному факту успешной загрузки.
Комбинация двух GPU, DRAM и отдельного размещения KV-кэша
Возможны разные комбинации:
- слои модели на RTX 3090 и CMP 170HX, KV-кэш на одной GPU;
- слои на двух GPU, часть весов в DRAM;
- основные веса на CMP 170HX, служебные буферы и часть слоёв на RTX 3090;
- модель на одной карте, KV-кэш или отдельный процесс на второй;
- два независимых процесса, каждый со своей моделью и собственной памятью.
Поддержка этих вариантов зависит от backend. Возможность распределять слои не подтверждает автоматически возможность вынести KV-кэш в RAM. Конфигурацию нужно собирать по логам, где видны реальные устройства и объёмы выделенной памяти.
Как сравнивать режимы без выдуманных бенчмарков
Для каждого режима используйте одну модель, один промпт, одинаковый контекст и одинаковую длину ответа. Зафиксируйте:
- время полной загрузки;
- задержку первого токена;
- скорость генерации после первого токена;
- время обработки длинного входа;
- пиковое потребление VRAM на каждой GPU;
- пиковое потребление RAM;
- ошибки, зависания и сбросы драйвера;
- поведение после повторного запуска.
Один показатель не описывает пригодность конфигурации. Быстрая генерация короткого ответа не компенсирует переполнение RAM на длинном контексте, а успешная загрузка не доказывает, что multi-GPU подходит для постоянной работы.
Где проходит практическая граница: одна видеокарта, две GPU или два процесса
Когда одной видеокарты достаточно
Если квантованная модель вместе с KV-кэшем и служебным запасом помещается на одной GPU, однокарточный режим обычно проще диагностировать и поддерживать. В нём нет постоянного обмена активациями между устройствами и меньше факторов, влияющих на задержку.
Вторая карта может понадобиться для длинного контекста, более высокой точности или отдельного процесса. Она не обязана ускорять модель, которая уже полностью помещается на RTX 3090 или CMP 170HX.
Перед multi-GPU сравните фактическую скорость одной карты с ограничениями гибридной схемы. Иногда меньшая, но полностью GPU-резидентная модель полезнее крупной конфигурации с постоянным DRAM offload.
Когда две видеокарты действительно полезны
Multi-GPU оправдан, если выбранная модель не помещается в доступную память одной карты, а backend подтверждённо распределяет её между устройствами. Вторая GPU может дать место для весов, KV-кэша или режима с меньшей степенью квантования.
Главный выигрыш здесь, возможность загрузить модель. Автоматического удвоения скорости не происходит. На результат влияют PCIe 2.0 x4, баланс слоёв, вычислительная производительность каждой карты и стоимость CPU offload.
Для длинного контекста заранее проверьте, где хранится KV-кэш. Если весь запас памяти уйдёт на веса, контекст может оказаться значительно меньше ожидаемого.
Два независимых агента или RAG-процесса
Вторая GPU часто рациональнее работает как отдельное устройство. На RTX 3090 можно держать один LLM-процесс, на CMP 170HX, другой процесс, RAG-сервис или AI-агента. Такой вариант не расширяет контекст одного диалога, зато не требует постоянной передачи активаций между картами.
Схема удобна, когда задачи независимы: например, один процесс отвечает на пользовательские запросы, второй индексирует документы или выполняет фоновую обработку. Для неё нужно отдельно рассчитать память каждой модели и исключить конкуренцию процессов за одну GPU.
Разбор запуска Qwen на двух одинаковых RTX 3090 показывает другой класс конфигурации: одинаковые карты упрощают распределение, однако проблемы VRAM, KV-кэша и backend всё равно сохраняются. Это полезное сравнение перед переходом к неоднородной паре.
Почему модель в DRAM может быть формально запущена, но практически неудобна
Факт отсутствия ошибки OOM подтверждает только загрузку. Он не сообщает, сколько времени занимает ответ и насколько стабильно система выдерживает длинный запрос.
DRAM offload может подойти для редких запросов, проверки формата, экспериментов с архитектурой и моделей, которые иначе не стартуют. Для постоянного интерактивного чата потребуется измерить задержку первого токена, скорость генерации и поведение при заполнении контекста.
Если каждый запрос активно обращается к вынесенной части весов, узкие места складываются: CPU, RAM, PCIe и межGPU-синхронизация. При таком результате меньшая квантованная модель или два независимых процесса могут дать более предсказуемую работу.
Итоговый алгоритм решения по конфигурации RTX 3090 и CMP 170HX
Минимальный чек-лист перед попыткой запуска
- Зафиксировать точную версию Qwen Next, формат весов, квантование и целевой контекст.
- Проверить поддержку архитектуры и формата в выбранном backend.
- Убедиться, что драйвер и вычислительный API видят RTX 3090 и CMP 170HX.
- Проверить каждую GPU отдельно, включая простую генерацию.
- Проверить слоты материнской платы, электрический режим линий и PCIe 2.0 x4.
- Оценить питание, кабели, охлаждение и вентиляцию корпуса.
- Проверить наличие свободной системной RAM с запасом под CPU offload.
- Уточнить поддержку multi-GPU, layer split и неоднородных GPU.
- Уточнить, где backend хранит KV-кэш и какие параметры на это влияют.
- Запустить модель на двух GPU без DRAM offload и записать метрики.
- Добавить минимальный CPU/DRAM offload, если VRAM недостаточно.
- Увеличивать контекст и параллельную нагрузку постепенно, меняя один параметр за раз.
Финальный вывод по Qwen Next на двух видеокартах
Связка RTX 3090 24 ГБ и CMP 170HX 64 ГБ может расширить пространство для одной модели только через программное распределение ресурсов. Сумма 88 ГБ VRAM не превращается в единый пул автоматически, а совместимость этой пары с конкретным backend требует отдельной проверки.
PCIe 2.0 x4 может быть терпимым при редких запросах или независимых процессах. При частом межGPU-обмене, длинном контексте и большом DRAM offload он способен заметно увеличить задержку и снизить скорость генерации.
Практическое решение выглядит так: если backend подтверждает multi-GPU, модель корректно распределяется, RAM хватает, а измеренная скорость соответствует задаче, гибридный запуск можно использовать. Если модель помещается на одной карте, сначала проверьте однокарточный режим. Если multi-GPU отсутствует или DRAM становится постоянным узким местом, выбирайте меньшую квантованную модель либо запускайте два независимых процесса.
Критерий успеха здесь простой: Qwen Next должна стабильно работать с нужным контекстом и приемлемой задержкой. Одного факта загрузки в 88 ГБ суммарной VRAM для такого вывода недостаточно.