Перейти к содержанию
Публикация AiManual

Как dual-GPU связка Radeon RX 7900 GRE и RX 480 влияет на llama.cpp в Vulkan в 2026 году

Разбираем, что реально может дать Radeon RX 480 в связке с RX 7900 GRE для llama.cpp через Vulkan: дополнительный резерв VRAM, KV-кэш, длинный контекст и ограни

Коротко

Что будет в материале

  1. 01

    Короткий ответ: что даст RX 480 связке с RX 7900 GRE

  2. 02

    Какие модели и контексты упираются в 16 ГБ VRAM

  3. 03

    Как работает llama.cpp на двух видеокартах AMD через Vulkan

  4. 04

    Почему prompt processing и generation реагируют на dual-GPU по-разному

Короткий ответ: что даст RX 480 связке с RX 7900 GRE

Radeon RX 480 с 8 ГБ VRAM может помочь Radeon RX 7900 GRE с 16 ГБ разместить более крупную модель, KV-кэш и рабочие буферы при запуске через llama.cpp с Vulkan. Это возможно только при поддержке распределения модели между двумя GPU конкретной сборкой, драйвером и платформой.

Номинальные 16 + 8 ГБ не превращаются автоматически в единый беспроблемный пул из 24 ГБ. Реальный доступный объем зависит от весов модели, квантования, длины контекста, KV-кэша, batch size, временных буферов, служебных расходов и выбранной схемы split/offload.

Скорость тоже не удвоится автоматически. Если модель уже полностью помещается на RX 7900 GRE, RX 480 может почти не изменить generation tok/s и даже добавить накладные расходы на синхронизацию. Если одиночная карта вынуждена отправлять часть данных в системную RAM, вторая GPU потенциально меняет сам сценарий запуска, но конкретный прирост можно определить только повторяемым тестом.

Главный практический вопрос звучит так: помогает ли RX 480 избежать медленного RAM offload для нужной модели и контекста? Для оценки dual-GPU это полезнее, чем простое сложение объемов VRAM.

Память расширяется условно, а не складывается автоматически

У каждой видеокарты остается собственная память. RX 7900 GRE хранит свою часть модели и буферов, RX 480 получает другую часть, а Vulkan-бэкенд организует обмен между устройствами через платформу. Программа должна знать, какие слои или тензоры отправить на каждую карту, и поддерживать такой режим на практике.

Условную оценку потребления можно записать так:

требуемая VRAM = веса модели + KV-кэш + временные буферы + служебный overhead + память других процессов

Файл GGUF показывает размер сохраненных весов, но не сообщает полный объем памяти, который понадобится во время инференса. После загрузки появляются рабочие буферы, данные для обработки входного текста, структуры Vulkan и память под KV-кэш. При большом контексте разница между размером файла и фактическим потреблением становится особенно заметной.

Даже при корректном распределении часть памяти на обеих картах может быть занята повторяющимися структурами. Поэтому доступный резерв обычно меньше арифметической суммы 24 ГБ. Точный результат нужно смотреть по логам llama.cpp и мониторингу VRAM во время загрузки и генерации.

Когда вторая карта полезнее как средство размещения, чем как ускоритель

RX 480 наиболее интересна в ситуации, когда RX 7900 GRE почти справляется с моделью, но несколько гигабайт не хватает для KV-кэша или временных буферов. Тогда llama.cpp может частично использовать системную RAM. Модель запускается, но скорость генерации часто падает из-за обмена между VRAM и оперативной памятью.

Если multi-GPU split позволяет перенести часть слоев на RX 480, система получает шанс сохранить рабочие данные в памяти видеокарт. Это не гарантирует высокую скорость. Слабая старая карта становится участником вычислений, а каждый проход может требовать синхронизации и обмена через PCIe.

Практический эффект может выглядеть как запуск Qwen3-27B с большим контекстом вместо отказа при загрузке или сильного замедления в RAM offload. В таком сравнении корректно говорить об устранении ограничения по памяти. Называть результат ускорением можно только после сопоставления prompt processing, задержки первого токена и generation tok/s.

Какие модели и контексты упираются в 16 ГБ VRAM

Лимит 16 ГБ определяется не названием модели и не одним числом параметров. На расход памяти влияют формат файла, квантование, размер контекста, тип KV-кэша, batch size и конкретные параметры запуска.

Веса модели, квантование и служебный overhead

Квантование уменьшает размер весов и требования к памяти, но не отменяет остальные расходы. Для грубой арифметики 27 млрд параметров при 4 битах требуют около 13,5 млрд байт только в идеализированном представлении весов: 27 млрд умножить на 4 и разделить на 8. Это не прогноз размера GGUF и не оценка полного потребления VRAM.

В реальном запуске добавляются метаданные, масштабы квантования, рабочие тензоры, буферы операций и память под контекст. Поэтому файл, размер которого близок к свободному объему VRAM, не оставляет достаточного запаса для работы. Часть памяти может быть занята графическим окружением или другими процессами.

4-битный вариант обычно дает больше шансов разместить крупную модель, чем 8-битный или FP16, но выбор квантования влияет и на качество, и на скорость. Сравнивать две конфигурации нужно при одинаковом файле модели, иначе эффект второй видеокарты смешается с эффектом другого формата весов.

KV-кэш и длинный контекст

KV-кэш хранит ключи и значения уже обработанных токенов, чтобы модель могла продолжать диалог без повторного вычисления всего контекста. При увеличении используемой длины контекста этот кэш растет. Архитектура модели, число слоев, размер скрытого состояния, тип данных KV и параметры batch влияют на итоговый расход.

Короткий чат может помещаться на RX 7900 GRE, а документ, кодовая база или RAG-контекст с теми же весами уже создают нехватку памяти. В такой ситуации добавление RX 480 способно освободить место под KV-кэш. Сохранение прежней скорости зависит от того, где именно окажется кэш и как Vulkan организует обмен между картами.

Длинный контекст влияет и на задержку первого токена. Перед началом генерации llama.cpp должен обработать входной текст и сформировать необходимые состояния. Если часть операций или данных проходит через медленную связь с другой GPU, увеличение доступной памяти может сопровождаться ростом задержки.

Почему Qwen3-27B и Qwen3-30B-A3B требуют отдельного расчета

Qwen3-27B подходит для проверки границы между комфортным запуском на одной 16-гигабайтной карте и сценарием, где дополнительная память уже меняет конфигурацию. При 4-битном квантовании грубая оценка весов выглядит привлекательной, но KV-кэш и буферы могут вытеснить модель за пределы свободной VRAM, особенно при большом контексте.

Qwen3-30B-A3B относится к MoE-моделям. Обозначение A3B указывает на число активных параметров в отдельном вычислительном шаге, но для размещения нужно учитывать полный набор весов экспертов и маршрутизацию. Нельзя оценивать такую модель только по активным 3 млрд параметров.

Для обеих моделей нужно зафиксировать конкретный GGUF-файл, квантование, контекст и batch size. Один и тот же Qwen3-27B может вести себя по-разному при коротком диалоге и при обработке большого документа. В случае Qwen3-30B-A3B разрыв между вычислительной нагрузкой и объемом хранимых весов требует еще большей осторожности.

Два базовых сценария: модель помещается и модель требует распределения

СценарийRX 7900 GREРоль RX 480Что сравнивать
Модель и контекст помещаютсяПолный GPU offloadМожет не использоваться или добавлять накладные расходыgeneration, prompt processing, задержку первого токена
Модель помещается, но контекст вызывает нехватку VRAMВозможен partial offload в RAMРезерв под слои, KV-кэш или буферы при поддержке splitпамять, задержку, скорость длинного контекста
Модель не помещается на одной картеНедостаточно памяти для полного сценарияМожет сделать запуск возможнымфакт загрузки, стабильность и generation

Главным кандидатом на пользу от RX 480 становится второй и третий сценарий. В первом карта может не дать ощутимого результата, потому что вычислительную работу уже выполняет более быстрая RX 7900 GRE.

Как работает llama.cpp на двух видеокартах AMD через Vulkan

Наличие двух GPU в системном блоке еще не означает, что llama.cpp использует их вместе. Нужно проверить обнаружение обоих устройств, выбор Vulkan-бэкенда, поддержку multi-GPU и фактическое распределение модели по логам запуска.

Поддержка multi-GPU в конкретной сборке llama.cpp

Совместимость нужно проверять для конкретной сборки, версии драйвера, Vulkan-реализации и операционной системы. Материалы по другим AMD-конфигурациям нельзя автоматически переносить на пару RX 7900 GRE и RX 480: у карт разный возраст, разная производительность и разные требования стека.

Перед тестом проверьте следующие признаки:

  • обе видеокарты видны системе и Vulkan-бэкенду;
  • llama.cpp не завершается с ошибкой при инициализации RX 480;
  • лог запуска показывает выбранные Vulkan-устройства;
  • параметры split или offload принимаются текущей версией программы;
  • потребление памяти и загрузка второй GPU меняются при включении multi-GPU;
  • длительный запуск не приводит к сбоям, зависаниям или потере устройства.

Названия ключей командной строки могут меняться между сборками. Сначала откройте справку конкретного бинарника через llama-cli --help или интерфейс используемого запускающего инструмента. Пример схемы, которую нужно сверять со справкой, может выглядеть так:

llama-cli -m model.gguf -ngl 99 --split-mode layer --tensor-split 2,1

Значение 2,1 здесь обозначает пропорцию распределения, а не гарантию оптимальной загрузки. Соотношение памяти RX 7900 GRE и RX 480 близко к 2:1, но вычислительная производительность карт отличается. Для конкретной модели более равномерное распределение по памяти может оказаться медленнее или стабильнее, чем схема, учитывающая скорость GPU.

Split и offload: что именно распределяется между GPU

В multi-GPU-режиме llama.cpp может распределять слои модели между устройствами. В зависимости от бэкенда и сборки отдельные рабочие данные могут дублироваться, перемещаться между картами или оставаться на главном устройстве. Поэтому одинаковый объем VRAM не гарантирует одинаковое поведение разных режимов.

Full GPU offload означает, что доступные слои и связанные структуры отправляются в память видеокарт. Partial offload оставляет часть вычислений или весов в системной RAM. Первый вариант обычно предпочтительнее по задержке, но требует достаточного GPU-резерва и рабочей схемы распределения.

Split нужно оценивать по логам, пиковому потреблению памяти и скорости. Успешная загрузка модели отвечает только на вопрос о размещении. Она ничего не говорит о том, сколько времени занимает обмен между RX 7900 GRE и RX 480 на каждом шаге генерации.

Для сравнения конфигураций полезно сохранить параметры запуска в отдельном текстовом файле:

модель: Qwen3-27B, конкретный GGUF-файл
квантование: указать точный вариант
контекст: указать число токенов
batch size: указать значение
режим: одна GPU или multi-GPU
split: указать фактическую пропорцию
бэкенд: Vulkan

Почему разная производительность RX 7900 GRE и RX 480 важна

RX 7900 GRE и RX 480 образуют неоднородную пару. Более быстрая карта может простаивать, пока RX 480 завершает назначенную ей часть работы. Если между слоями требуется обмен, время каждого шага определяется не усредненной мощностью, а самым медленным участком цепочки и задержкой передачи.

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

Поэтому RX 480 может дать больший объем размещения и одновременно снизить generation tok/s по сравнению с одиночной RX 7900 GRE на той же модели. Это не противоречие. Система получает возможность запускать сценарий, который раньше требовал RAM, но платит за участие более медленного устройства.

Полезные замеры для этой части: загрузка каждой GPU, объем занятой VRAM, загрузка PCIe, время обработки одного и того же промпта, скорость генерации и число ошибок за длительный прогон.

Почему prompt processing и generation реагируют на dual-GPU по-разному

У локального инференса минимум три отдельные метрики: скорость обработки входного текста, задержка до первого токена и скорость последующей генерации. Их нельзя заменить одной цифрой tok/s.

Prompt processing: обработка входного текста

Prompt processing, или prefill, обрабатывает входной текст и строит состояния, которые понадобятся модели при ответе. Длинный документ, история диалога или RAG-контекст создают заметную нагрузку еще до появления первого токена.

Эта фаза хорошо использует пакетную обработку. Размещение слоев на двух GPU может увеличить доступный объем памяти и иногда улучшить прохождение длинного входа, если одиночная RX 7900 GRE раньше упиралась в RAM offload. С другой стороны, обмен между разными картами и синхронизация могут съесть часть выигрыша.

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

Generation: скорость выдачи токенов

Generation, или decode, создает ответ последовательно: следующий токен зависит от уже полученных. В этом режиме обмен между GPU может повторяться на каждом шаге, а скорость RX 480 сильнее влияет на общий темп.

Если модель полностью помещается на RX 7900 GRE, одиночный запуск может оказаться быстрее благодаря отсутствию меж-GPU синхронизации. Если одна карта использует системную RAM, dual-GPU способен обойти этот тяжелый сценарий. Сравнивать нужно три варианта: одна RX 7900 GRE, dual-GPU с полным распределением и одна RX 7900 GRE с частичным offload в RAM.

Скорость генерации измеряйте после завершения prompt processing. Первые токены ответа могут иметь отдельную задержку, поэтому полезно записывать и средний темп после прогрева, и время появления первого токена.

Задержка первого токена и стабильность

Задержка первого токена, или TTFT, включает подготовку запроса, обработку промпта, планирование и запуск генерации. Для короткого чата пользователь ощущает именно ее, даже если дальнейшая скорость ответа высокая.

В локальном кодинге важна связка TTFT и generation tok/s. Долгий первый ответ раздражает при коротких запросах, а медленная генерация заметна при создании большого фрагмента кода. В RAG-сценарии к этим показателям добавляется обработка объемного контекста.

Зафиксируйте разброс результатов, сообщения об ошибках, длительность непрерывной работы и поведение после нескольких последовательных запросов. Номинальный прирост памяти теряет практический смысл, если старая RX 480 периодически выпадает из Vulkan-контекста или требует перезапуска процесса.

Как сравнить одну RX 7900 GRE и dual-GPU связку без самообмана

Тест должен отвечать на два разных вопроса: меняется ли скорость на помещающейся модели и позволяет ли RX 480 запустить сценарий, который на одной карте уходит в системную RAM или не стартует.

Что зафиксировать в конфигурации

Запишите параметры до первого прогона:

  • точную модель каждой видеокарты и фактически свободную VRAM;
  • процессор, объем оперативной памяти и материнскую плату;
  • электрический режим PCIe для каждого слота;
  • блок питания, схему подключения кабелей и температуру GPU;
  • операционную систему, драйвер AMD и Vulkan-стек;
  • версию или commit llama.cpp и название запускающего бинарника;
  • конкретный файл модели и вариант квантования;
  • размер контекста, batch size и параметры KV-кэша;
  • режим offload, split и список выбранных устройств;
  • фоновые процессы, которые занимают VRAM или CPU.

Перед каждым прогоном проверьте, что память видеокарт свободна примерно в одинаковом объеме. Одинаковая команда при разном остатке VRAM может привести к другому распределению или отказу при загрузке.

Минимальная матрица сравнения

ТестКонфигурацияЗачем нужен
КонтрольныйRX 7900 GRE, модель и контекст помещаютсяПроверить базовую скорость без второй GPU
Контрольный dual-GPURX 7900 GRE + RX 480 на той же моделиУвидеть накладные расходы multi-GPU
Память одной картыRX 7900 GRE, крупная модель или длинный контекстЗафиксировать partial offload или отказ
Память двух картТа же модель и контекст, полный доступный multi-GPU offloadПроверить, меняет ли RX 480 факт запуска
RAM offloadОдна RX 7900 GRE с частью данных в системной RAMСопоставить dual-GPU с альтернативой
Qwen-контрольQwen3-27B или Qwen3-30B-A3B при фиксированном квантованииПроверить крупную модель с отдельным расчетом памяти

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

Как представлять результаты

Таблица результатов должна разделять скорость и возможность запуска:

ПоказательRX 7900 GRERX 7900 GRE + RX 480Что означает
Prompt processing, tok/sзаполнить замеромзаполнить замеромскорость обработки входного текста
Задержка первого токеназаполнить замеромзаполнить замеромвремя до начала ответа
Generation, tok/sзаполнить замеромзаполнить замеромскорость последовательной выдачи
Пиковая VRAMзаполнить мониторингомзаполнить мониторингомфактический запас памяти
Системная RAMзафиксировать объемзафиксировать объемпризнак RAM offload
Стабильностьошибки и длительностьошибки и длительностьпригодность для длительной работы

Если одиночная карта не загружает модель, результат нужно обозначить как «не запустилось», а не как нулевую скорость. Dual-GPU в этом случае выигрывает по доступности сценария, даже если его generation tok/s ниже результата меньшей модели на одной карте.

Не смешивайте холодный запуск с прогретым. Время чтения GGUF с накопителя, заполнение кэшей и инициализация Vulkan относятся к запуску, а prompt processing и generation описывают работу уже загруженной модели.

Что означает прирост или его отсутствие в реальной работе

Интерактивный чат и локальный кодинг

Для обычного диалога пользователь чувствует задержку первого токена и темп генерации. Если модель и короткий контекст уверенно помещаются на RX 7900 GRE, подключение RX 480 не имеет очевидного преимущества. Дополнительная карта может увеличить время инициализации, усложнить драйверную конфигурацию и добавить синхронизацию.

Для локального кодинга картина меняется при длинной истории диалога, больших файлах и нескольких открытых контекстах. RX 480 может освободить память под KV-кэш и сохранить работоспособность запроса. Проверяйте, не компенсируется ли этот выигрыш падением generation tok/s.

В качестве практического критерия используйте не максимальное число токенов в секунду, а время получения полезного фрагмента ответа. Быстрая генерация короткого ответа на одной карте может оказаться удобнее, чем медленная работа dual-GPU с большим контекстом, если этот контекст не нужен постоянно.

Длинный контекст, документы и RAG

В сценариях с документами память часто ограничивает запуск раньше, чем вычислительная мощность. RAG добавляет к запросу найденные фрагменты, а длинная история диалога увеличивает KV-кэш. При достижении лимита RX 7900 GRE система может перейти к RAM offload или завершить загрузку с ошибкой.

RX 480 может оказаться полезной, если ее память принимает часть слоев или связанных данных. Проверяйте эффект на нескольких размерах контекста, например на коротком контрольном запросе и на заранее зафиксированном длинном входе. Сравнивайте пиковую VRAM, системную RAM, TTFT и generation.

Практику сравнения VRAM, KV-кэша и длинного контекста для локальных моделей можно дополнить материалом о влиянии объема памяти и контекста на скорость llama.cpp. Его выводы нельзя переносить на RX 7900 GRE и RX 480 без собственного теста, но сама логика измерений подходит для планирования эксперимента.

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

При увеличении batch size растет нагрузка на рабочие буферы и prompt processing. Несколько параллельных запросов требуют отдельного учета KV-кэша для каждого активного сеанса. Конфигурация, которая работает для одного чата, может упереться в память при двух или трех одновременных запросах.

Dual-GPU может увеличить вместимость, но RX 480 способна стать узким местом при синхронизации. Для пакетного режима нужны отдельные замеры: throughput всех запросов, latency одного запроса, пиковое потребление VRAM, загрузка PCIe и частота ошибок.

Не переносите результат одиночной генерации на серверный режим. В пакетной обработке больше возможностей загрузить GPU, однако дополнительный обмен между картами и конкуренция за память меняют профиль нагрузки.

Платформа и ограничения Radeon RX 480 в 2026 году

Смешанная система требует проверки аппаратной совместимости до установки карт. Успешная загрузка операционной системы еще не подтверждает пригодность конфигурации для продолжительного инференса.

Материнская плата, процессор и PCIe

Проверьте количество физических слотов и их электрическую конфигурацию. Второй длинный слот может работать с меньшим числом линий PCIe, чем ожидает пользователь. Для multi-GPU это влияет на передачу данных между устройствами, загрузку модели и синхронизацию во время вычислений.

Уточните, какие линии идут от процессора, какие делит чипсет и не отключает ли установка второй карты отдельные разъемы или накопители. Расстояние между слотами тоже имеет значение: толстая RX 7900 GRE может перекрыть разъем, необходимый для RX 480.

Практические вопросы к платформе:

  • видит ли прошивка обе карты;
  • доступны ли нужные слоты одновременно;
  • какой режим PCIe получает каждый GPU;
  • не подключен ли второй слот через слишком узкий канал для выбранной нагрузки;
  • достаточно ли линий и ресурсов для устройств, которые уже установлены в системе;
  • не меняется ли режим работы NVMe или других плат после установки RX 480.

Сравнение с двухкарточными системами на X570 и X870 Taichi полезно для понимания вопросов PCIe, питания и размещения GPU. Конкретные выводы для RX 7900 GRE и RX 480 потребуют проверки вашей платы, поскольку топология слотов у разных моделей отличается. Смежный разбор есть в статье о двух Radeon для локальных LLM.

Питание, охлаждение и место в корпусе

Вторая видеокарта добавляет потребление, тепло и нагрузку на систему питания. Проверяйте характеристики конкретных исполнений RX 7900 GRE и RX 480, процессора, накопителей и остальных устройств. Универсальное значение мощности блока питания без состава всей системы будет приблизительной догадкой.

Убедитесь, что для каждой карты хватает отдельных кабелей питания и что разъемы не натянуты боковой крышкой. Не оставляйте RX 480 вплотную к горячей RX 7900 GRE, если корпус не выводит воздух между платами. Температура и частоты нужно записывать во время длинного запуска, а не сразу после старта.

Старая карта может иметь изношенные вентиляторы, высохшую термопасту или нестабильный разъем. Такие проблемы проявляются именно при продолжительной нагрузке. Если RX 480 используется только как резерв памяти, ее физическое охлаждение все равно должно выдерживать постоянную работу Vulkan.

Драйверы и Linux/AMD-стек

RX 480 к 2026 году остается устаревшим GPU с ограниченным запасом производительности и потенциально меньшей совместимостью с современными приложениями. Один общий драйверный стек может корректно обнаруживать обе карты, но это не гарантирует, что выбранная сборка llama.cpp будет эффективно использовать их вместе.

Проверьте по отдельности:

  • обнаружение RX 7900 GRE и RX 480 операционной системой;
  • создание Vulkan-устройств без ошибок;
  • доступность обеих карт в логах llama.cpp;
  • загрузку тестовой модели только на RX 7900 GRE;
  • загрузку той же модели в multi-GPU-режиме;
  • стабильность после серии длинных запросов.

Не меняйте одновременно драйвер, сборку llama.cpp, параметры контекста и схему split. Иначе невозможно определить причину изменения скорости или сбоя. Для старой RX 480 особенно важно сохранить рабочую конфигурацию и зафиксировать ее перед экспериментами.

Вывод: стоит ли добавлять RX 480 для llama.cpp на двух видеокартах AMD

Если нужные модели и контекст полностью помещаются на RX 7900 GRE, покупка или установка RX 480 не дает гарантированного ускорения. Одиночная карта может оказаться быстрее за счет отсутствия меж-GPU обмена, а программная настройка будет проще.

Если без RX 480 появляется частичный offload в системную RAM, дополнительная карта может иметь практический смысл. Она способна помочь разместить модель, KV-кэш и буферы, а для Qwen3-27B или Qwen3-30B-A3B при 4-битном квантовании и большом контексте иногда меняет сам факт запуска. Generation tok/s при этом нужно измерять отдельно: слабый участник связки способен ограничить скорость.

Если Vulkan-бэкенд, драйвер или материнская плата не умеют эффективно распределять нагрузку, номинальные 24 ГБ не дают полезного резерва. Физическая установка второй карты без подтвержденного split не решает проблему VRAM.

Решение принимайте по матрице из трех конфигураций: RX 7900 GRE с полным GPU offload, dual-GPU с распределением модели и одиночная карта с RAM offload. Сопоставьте prompt processing, задержку первого токена, generation tok/s, пиковое потребление памяти и стабильность. Такой тест покажет, помогает ли RX 480 именно вашему локальному инференсу, а не только увеличивает цифру в списке установленного оборудования.

Подписаться на канал