Переход с двух RTX 2060 12GB на RX 6800 + 6800 XT для llama.cpp: стоит ли менять связку

Короткий вывод: 32 ГБ VRAM не гарантируют ускорение

Переход с двух RTX 2060 12GB на пару RX 6800 и RX 6800 XT имеет смысл прежде всего ради вместимости. Номинальный объём памяти вырастет с 24 до 32 ГБ, то есть примерно на 33%. Это может открыть доступ к более тяжёлому кванту модели, большему контексту или дополнительному запасу под KV-кэш.

Прирост скорости в llama.cpp из этого автоматически не следует. В новой конфигурации придётся проверить ROCm или Vulkan, работу multi-GPU для RDNA2 и баланс нагрузки между RX 6800 и RX 6800 XT. Если программный стек распределяет слои неудачно или добавляет большие накладные расходы на обмен между картами, 32 ГБ превратятся в прирост вместимости без пропорционального ускорения генерации.

Практический вердикт такой: переход оправдан, когда текущих 24 ГБ не хватает для конкретной модели или кванта, а пользователь готов потратить время на настройку AMD-бэкенда. Для уже стабильной CUDA-среды, где главная задача состоит в скорости и предсказуемости запуска, менять карты без предварительного теста рискованно.

Что меняется при переходе с 24 на 32 ГБ VRAM

Две RTX 2060 12GB и связка RX 6800 + 6800 XT дают разный запас памяти для локальных LLM. В обоих случаях речь идёт о двух отдельных устройствах. Память суммируется только на уровне распределения частей модели между GPU, а не превращается в единую область с одинаковой задержкой доступа.

Конфигурация	Номинальный объём VRAM	Практический смысл
2 x RTX 2060 12GB	24 ГБ	Базовый запас для более компактных квантов и умеренного контекста
RX 6800 + RX 6800 XT	32 ГБ	Дополнительные 8 ГБ для тяжёлого кванта, KV-кэша и рабочих буферов

24 ГБ против 32 ГБ: где появляется практический запас

Видеопамять расходуется на несколько компонентов. Основную долю занимают веса модели, но рядом с ними нужны KV-кэш, scratch-буферы, временные тензоры и служебные структуры бэкенда. Поэтому модельный файл, который занимает условные 22 или 23 ГБ на диске, не обязан помещаться в 24 ГБ VRAM при запуске.

Дополнительные 8 ГБ могут решить несколько разных задач:

• поместить Q5 или Q6 вместо более компактного Q4;
• оставить больше памяти под контекст без немедленного переноса части данных в системную RAM;
• уменьшить необходимость в частичном offload на CPU;
• сохранить запас для batch size и рабочих буферов;
• запустить модель, которая проходит загрузку на 32 ГБ, но не проходит инициализацию на 24 ГБ.

Точная граница зависит от модели и режима. На результат влияют формат GGUF, длина контекста, тип KV-кэша, batch size, число выгруженных на GPU слоёв и конкретная сборка llama.cpp. Суммарные 32 ГБ нельзя полностью отдавать под веса.

Похожая логика действует и в конфигурациях с RX 6800, подключённой к более вместительной Radeon: дополнительные гигабайты расширяют диапазон запуска, но требуют проверки распределения слоёв и влияния PCIe. Практические ограничения такой схемы разобраны в статье о добавлении RX 6800 к RX 7900 XTX для локальных LLM.

Объём памяти и пропускная способность - разные преимущества

VRAM отвечает на вопрос, поместится ли модель. Пропускная способность памяти и вычислительная мощность влияют на то, как быстро бэкенд будет обрабатывать слои во время prefill и decode. Эти характеристики связаны с разными узкими местами.

При генерации токенов decode система многократно обращается к весам модели и KV-кэшу. Если рабочий набор помещается в VRAM, дополнительный объём сам по себе не ускоряет чтение данных. Ускорение появится только при удачном сочетании GPU, драйвера, kernel, распределения слоёв и межкарточного обмена.

В смешанной паре RX 6800 и RX 6800 XT одна карта может иметь свободную память, пока другая упирается в свои буферы или получает больше работы. Такой сценарий снижает пользу от номинальных 32 ГБ. Поэтому сравнивать нужно две величины: доступный объём для нужной модели и время обработки фиксированного запроса.

Сколько VRAM нужно для Qwen3.8 27B и длинного контекста

Для модели уровня Qwen3.8 27B одного размера весов недостаточно, чтобы оценить требования системы. Нужно заранее задать квант, длину контекста, формат KV-кэша и режим GPU offload. Одна и та же модель может запускаться при коротком контексте и переставать помещаться после его увеличения.

Квантование определяет, что поместится в память

Формат квантования задаёт компромисс между размером весов, качеством и требованиями к памяти. Q4 обычно требует меньше места, чем Q5 или Q6, а Q8 оставляет больше информации в весах, но увеличивает объём загрузки. При равном объёме VRAM переход на более тяжёлый квант может потребовать уменьшить контекст или перенести часть слоёв в RAM.

Размер файла GGUF служит ориентиром, но не финальным расчётом. Во время запуска добавляются буферы, метаданные, память под вычисления и KV-кэш. Для Qwen3.8 27B нужно проверять конкретный файл квантования, потому что обозначение уровня вроде Q5 не описывает все параметры расхода памяти.

Гибридное квантование распределяет точность между частями модели. Один из возможных вариантов хранит dense-слои в 8-битном формате, а expert-слои в 4-битном. Такой подход меняет соотношение качества и размера, поэтому оценивать его нужно по фактическому размеру файла и отчёту о загрузке, а не по одному названию формата.

Практический материал о запуске моделей уровня Qwen3.8 27B на нескольких GPU есть в разборе двух Radeon AI PRO R9700. Там отдельно показано, почему объём VRAM, KV-кэш и способ распределения данных нужно считать вместе.

Контекст съедает память через KV-кэш

KV-кэш хранит промежуточные ключи и значения attention для уже обработанных токенов. При увеличении контекстного окна кэш растёт, поэтому модель, которая уверенно работает на 8K или 16K токенах, может потребовать существенно больше памяти на 64K.

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

Batch size влияет на рабочие буферы и prefill. Большой batch ускоряет обработку длинного входа только при наличии свободной памяти. Если запас исчерпан, приходится уменьшать batch, контекст или число слоёв на GPU.

Для конфигурации RX 6800 + 6800 XT дополнительные 8 ГБ полезнее всего там, где текущая связка уже почти загружена весами и не оставляет места под KV-кэш. Это расширяет рабочий диапазон, но не гарантирует комфортную генерацию на длинном контексте.

Почему 1 миллион токенов не является целью для 32 ГБ VRAM

Контекст в 1 048 576 токенов требует совсем другого класса памяти. В одном примере запуска Qwen3.8-Flash-Next на Mac M5 Max с 128 ГБ unified memory пиковое потребление при полном окне оценивалось примерно в 117 ГБ.

Эту цифру нельзя переносить напрямую на RTX 2060, RX 6800 или RX 6800 XT. Unified memory Mac и VRAM дискретных GPU по-разному распределяют данные, а итог зависит от модели, формата кванта, типа KV-кэша и настроек сервера.

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

Как ведёт себя смешанная связка RX 6800 и RX 6800 XT

RX 6800 и RX 6800 XT имеют по 16 ГБ VRAM, поэтому номинальная сумма пары составляет 32 ГБ. Однако одинаковый объём памяти не означает одинаковую скорость обработки. Разница между картами проявляется при распределении слоёв и синхронизации.

Почему 32 ГБ не равны единому пулу памяти

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

Если один буфер требуется разместить на конкретном устройстве, свободные гигабайты второй карты его не заменят. Аналогичное ограничение возникает, когда бэкенд не умеет распределять определённую операцию между GPU. В результате реально доступный объём может быть ниже арифметической суммы 16 + 16 ГБ.

Итог зависит от выбранного бэкенда, версии llama.cpp и параметров split. У разных сборок могут отличаться правила выбора устройств, пропорции распределения и обработка временных буферов. Сумму VRAM нужно считать предварительной оценкой, а не гарантией загрузки конкретного GGUF.

Сходные ограничения описаны в разборе двух Radeon для локальных LLM, где отдельно рассматриваются PCIe-конфигурация, Linux, питание и размещение весов. Для RX 6800 и RX 6800 XT логика проверки остаётся той же, даже если сами карты относятся к другому уровню производительности.

Разница между RX 6800 и RX 6800 XT

RX 6800 XT относится к более производительной версии пары, а RX 6800 может обрабатывать свою часть модели медленнее. Равномерное деление слоёв по объёму памяти в таком случае не гарантирует равномерное время работы.

Если на каждую карту отправить одинаковую долю слоёв, более быстрая RX 6800 XT может ждать RX 6800 на синхронизации. Если отдать больше слоёв XT, можно лучше использовать её вычислительный ресурс, но возрастёт нагрузка на память и обмен. Оптимальная пропорция зависит от конкретной модели, кванта и бэкенда.

Смешанная конфигурация требует проверки минимум в трёх режимах:

• обе карты с автоматическим распределением слоёв;
• обе карты с ручной пропорцией нагрузки;
• каждая карта отдельно, чтобы увидеть вклад RX 6800 и RX 6800 XT.

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

ROCm и Vulkan для RDNA2: совместимость важнее обещаний

Для перехода с CUDA на AMD нужно выбрать рабочий путь запуска. ROCm и Vulkan не представляют один и тот же бэкенд с разными названиями. У них отличаются требования к сборке, поддержка операций, диагностика ошибок и поведение multi-GPU.

ROCm: что проверить до миграции

Поддержку RX 6800 и RX 6800 XT нужно сверять с конкретной версией ROCm, драйвера, операционной системы и исходного кода llama.cpp. Наличие AMD-бэкенда в документации ещё не подтверждает, что нужная связка стабильно работает с RDNA2 и двумя разными картами.

• Зафиксируйте версию операционной системы, драйвера, ROCm и llama.cpp.
• Проверьте, видит ли система обе видеокарты и отображает ли их с правильным объёмом памяти.
• Соберите или установите вариант llama.cpp с нужным вычислительным бэкендом.
• Запустите небольшую модель сначала на RX 6800, затем на RX 6800 XT.
• Проверьте загрузку модели на двух устройствах и отсутствие незаметного перехода части операций на CPU.
• Зафиксируйте ошибки kernel, нехватки памяти и аварийные завершения при увеличении контекста.

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

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

Vulkan стоит рассматривать как отдельный вариант запуска, а не как автоматическую замену CUDA. На одной системе он может оказаться удобнее для обнаружения AMD-карт, на другой потребуется больше ручной настройки или возникнут ограничения в multi-GPU.

Перед покупкой проверьте четыре вещи: видит ли сборка обе карты, доступен ли split между устройствами, корректно ли выделяются буферы и сохраняется ли скорость при работе нужной модели. Тест на маленькой модели показывает совместимость, но не подтверждает пригодность Qwen3.8 27B с выбранным контекстом.

Нужно отдельно проверить prefill и decode. Vulkan может вести себя по-разному на длинном prompt и при последовательной генерации. Ошибка загрузки, нестабильность после нескольких запросов или резкое падение скорости при заполнении KV-кэша важнее красивого результата короткого пробного запуска.

Что теряется при уходе от CUDA

Рабочая CUDA-конфигурация обычно ценна уже настроенными драйверами, сборкой llama.cpp, привычными параметрами запуска и совместимыми инструментами. После перехода на AMD часть этой предсказуемости придётся заменить самостоятельной проверкой.

Риск касается не только скорости. Возможны отличия в поддержке kernel, поведении квантов, работе KV-кэша, выборе устройств и обработке ошибок. Инструмент, который запускается поверх CUDA без дополнительных действий, может потребовать отдельной сборки или другого режима на ROCm и Vulkan.

Открытый AMD-стек даёт альтернативу CUDA, но не убирает стоимость диагностики. Если компьютер используется для рабочих задач, время на настройку и восстановление окружения нужно считать частью цены перехода.

Будет ли новая связка быстрее в llama.cpp

Универсальный ответ без замера невозможен. У RTX 2060, RX 6800 и RX 6800 XT нет одной подтверждённой цифры tokens per second, которая подходила бы для любого квантования и контекста. Результат меняется вместе с бэкендом, batch size, числом GPU-слоёв и способом распределения модели.

Какие параметры фиксировать в сравнении

Сравнение нужно проводить на одной машине и с одинаковым сценарием. Зафиксируйте следующие параметры:

1. Один и тот же файл модели и один и тот же формат квантования.
2. Одинаковую длину контекста и одинаковый тип KV-кэша.
3. Один prompt для измерения prefill и одинаковое число генерируемых токенов для decode.
4. Одинаковые batch size и ubatch size, если эти параметры используются сборкой.
5. Число слоёв на GPU и режим split-mode.
6. Пропорцию распределения слоёв между картами при ручной настройке.
7. Один и тот же backend и сопоставимую версию llama.cpp.
8. Время загрузки, пиковое потребление VRAM каждой карты, системную RAM и сообщения об ошибках.

Для каждого режима полезно выполнить несколько повторов после прогрева и записать медианное значение. Одного запуска мало: первые секунды могут включать загрузку библиотек, выделение памяти и компиляцию kernel.

Почему одна цифра tokens per second вводит в заблуждение

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

Связка RX 6800 + 6800 XT может получить преимущество в одном режиме и потерять его в другом. Например, больший объём памяти позволит оставить больше слоёв на GPU при длинном контексте, но межкарточный обмен способен снизить скорость последовательной генерации. При коротком prompt преимущество prefill может почти не влиять на субъективную скорость диалога.

Полезный формат отчёта выглядит так: prefill: N токенов/с, decode: M токенов/с, контекст: K, VRAM GPU0: X, VRAM GPU1: Y. Такие данные можно сопоставлять между конфигурациями без смешения разных режимов.

При сравнении длинного контекста пригодится разбор влияния VRAM и контекста на скорость Qwen3.8-Flash-Next в llama.cpp. Он показывает, почему mmap, размещение весов и тип KV-кэша способны менять результат сильнее, чем одна характеристика видеокарты.

Кому переход на RX 6800 + 6800 XT имеет смысл

Когда дополнительные 8 ГБ важнее экосистемы

Переход выглядит рационально в следующих сценариях:

• нужный квант Qwen3.8 27B не помещается в текущие 24 ГБ вместе с KV-кэшем;
• текущая конфигурация запускает модель только с коротким контекстом, а рабочая задача требует большего окна;
• частичный offload на CPU даёт неприемлемую задержку или расходует слишком много системной RAM;
• пользователь готов тестировать ROCm и Vulkan, подбирать сборку и вручную проверять распределение слоёв;
• приоритетом выступает вместимость локальной LLM, а не гарантированный прирост tokens per second.

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

Когда лучше не менять рабочую CUDA-конфигурацию

Сохранение двух RTX 2060 разумнее, если:

• текущие 24 ГБ уже покрывают нужный квант и типичный контекст;
• система используется ежедневно, а время на настройку и диагностику ограничено;
• требуемые инструменты, скрипты и окружение уже работают через CUDA;
• покупка AMD основана только на ожидании ускорения без теста конкретного сценария;
• новая пара требует заметной перестройки питания, охлаждения или PCIe-разводки.

В этом случае дополнительные 8 ГБ могут не окупить переход. Стабильный запуск с предсказуемыми параметрами часто полезнее теоретически большей вместимости, особенно когда модель и контекст уже помещаются в текущую систему.

Чек-лист перед покупкой и миграцией

Проверка программного стека

1. Запишите текущую рабочую конфигурацию: версию llama.cpp, параметры запуска, модель, квант, контекст и тип KV-кэша.
2. Проверьте поддержку RX 6800 и RX 6800 XT конкретной версией драйвера, ROCm или Vulkan.
3. Убедитесь, что обе карты видны системе одновременно и имеют доступный объём памяти.
4. Запустите небольшую модель на каждой карте отдельно.
5. Проверьте запуск той же модели на двух GPU, затем включите нужное число слоёв и целевой режим split.
6. Сохраните логи загрузки, распределение VRAM и сообщения об ошибках.
7. До продажи RTX 2060 сохраните рабочую CUDA-среду и возможность вернуть прежнюю конфигурацию.

Проверка реального сценария с нужной моделью

1. Загрузите Qwen3.8 27B в предполагаемом кванте.
2. Проверьте типичный контекст, который используется в работе, а затем увеличьте его до планируемого максимума.
3. Запишите prefill и decode отдельно, не объединяя их в одну среднюю цифру.
4. Проверьте пиковое потребление VRAM на RX 6800 и RX 6800 XT.
5. Убедитесь, что обе карты действительно загружены и одна из них не простаивает большую часть времени.
6. Повторите длинный диалог после заполнения KV-кэша, поскольку короткий запуск не показывает поведение системы на рабочем контексте.
7. Проверьте стабильность нескольких последовательных запросов, температуру, потребление, питание и работу PCIe-конфигурации.

Финальное решение по результатам проверки

Переход оправдан, если RX 6800 + 6800 XT решают конкретное ограничение по памяти, поддерживают нужный бэкенд и дают приемлемую скорость в целевом сценарии. Для Qwen3.8 27B нужно оценивать весь рабочий набор: веса, KV-кэш, временные буферы и запас под контекст.

Если тест подтвердил только увеличение доступной VRAM, а CUDA-конфигурация запускает те же задачи стабильнее или быстрее, однозначной выгоды нет. В таком случае AMD-пара остаётся способом расширить вместимость, но не универсальным апгрейдом производительности.

Главный критерий покупки прост: новая связка должна решать заранее названную проблему. Если проблема состоит в нехватке 8 ГБ, RX 6800 + 6800 XT может быть оправдана. Если проблема состоит в скорости генерации, ответ даст только воспроизводимое сравнение на одной модели, одном кванте, одном контексте и сопоставимых настройках llama.cpp.

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