2× Radeon AI PRO R9700: локальный сервер для Qwen 3.8 и Flash Next

Короткий ответ: что дают 2× Radeon AI PRO R9700 для LLM

Связка 2× Radeon AI PRO R9700 имеет смысл там, где одной видеокарте не хватает памяти для выбранной модели, KV-кэша или нескольких параллельных запросов. Вторая GPU расширяет доступный ресурс через шардирование модели, распределение KV-кэша, параллельную обработку запросов или комбинацию этих режимов. Удвоение скорости при этом не гарантируется: результат зависит от backend, обмена между картами, загрузки памяти и характера нагрузки.

Для Qwen 3.8 27B нужно отдельно сравнивать FP8 и MXFP4, а Qwen 3.8 Flash Next оценивать как самостоятельный сценарий с vLLM Radiance и R9V. В доступном описании кейса нет подтвержденных логов скорости, температур и потребления, поэтому корректный вывод строится вокруг архитектуры стенда и методики замеров, а не вокруг выдуманных значений tokens/s.

Две видеокарты - это расширение ресурса, а не один большой ускоритель

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

• Model parallelism: слои модели распределяются между GPU. Такой режим помогает разместить крупные веса, но добавляет обмен между ускорителями.
• Tensor parallelism: отдельные операции или тензоры делятся между картами. Скорость зависит от поддержки backend и задержек межGPU-коммуникации.
• Раздельная обработка запросов: каждая карта получает собственные задачи. Режим удобен для нескольких пользователей, но не увеличивает вместимость одной модели.
• Offload: часть весов, экспертов или служебных данных уходит в DDR5, а иногда и на SSD. Модель запускается при меньшем объёме VRAM, но обмен с CPU-RAM заметно медленнее работы внутри видеопамяти.

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

Кому такая схема действительно может быть полезна

• Пользователям, которым нужно разместить Qwen 3.8 27B или Flash Next с большим запасом под KV-кэш.
• Тем, кто работает с длинными документами, RAG-контекстом и большими входными последовательностями.
• Разработчикам, тестирующим разные runtime, квантизации и варианты offload.
• Небольшим командам, которым нужны несколько параллельных локальных запросов без отправки чувствительных данных в облако.
• Владельцам домашнего AI-сервера, готовым разбираться с ROCm, драйверами, PCIe-топологией и параметрами запуска.

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

Конфигурация кейса: что зафиксировано, а что требует проверки

Описание стенда фиксирует две Radeon AI PRO R9700, 64 ГБ DDR5 и схему PCIe 5.0 x8. Этого недостаточно для полноценного сравнения. Без точного объёма VRAM каждой карты, CPU, разводки линий, SSD и версий программного стека результаты нельзя воспроизвести или корректно сопоставить с одной флагманской GPU.

Компонент	Что известно по кейсу	Что нужно подтвердить
GPU	2× Radeon AI PRO R9700	Объём VRAM каждой карты, лимиты мощности, BIOS, частоты и режим работы под длительной нагрузкой
Системная память	64 ГБ DDR5	Частота, тайминги, количество модулей, профиль BIOS и стабильность при offload
PCIe	Указана схема PCIe 5.0 x8	Link width каждой карты, подключение к CPU или чипсету, фактическое поколение под нагрузкой
CPU	Точная модель не раскрыта	Число линий PCIe, NUMA-топология, влияние процессора на prefill и обмен с RAM
SSD	Модель не раскрыта	Тип накопителя, свободное место, скорость чтения, задержки и поведение при длительном кэше
ПО	Упомянуты vLLM Radiance и R9V	Версии драйвера, ROCm, vLLM, R9V, Python-зависимостей и конкретные параметры запуска

Какие параметры нужно раскрыть перед сравнением

Минимальный паспорт стенда должен содержать модель процессора, материнскую плату, схему слотов, блок питания, охлаждение, корпус, SSD и версии BIOS. Для каждой GPU нужно записать реальный объём доступной VRAM, ширину PCIe-соединения, температуру ядра и hotspot, частоты, загрузку и потребление.

Для модели список параметров не короче: revision, формат файла, chat template, stop-токены, длина контекста, batch size, concurrency, sampling и способ распределения по GPU. FP8 и MXFP4 нельзя считать сопоставимыми режимами, если вместе с форматом меняются модельная ревизия, backend или шаблон запроса.

Что можно взять из общего опыта AMD AI-станций, а что нельзя переносить напрямую

Для технологического контекста полезен пример AMD Threadripper Halo Station. В описанной AI-станции используются Ryzen Threadripper PRO 9995WX и два ускорителя Instinct MI350P с 144 ГБ HBM3e каждый. Суммарно это 288 ГБ памяти ускорителей, а конфигурация с четырьмя ускорителями увеличивает объём HBM3e до 576 ГБ и заявленную пропускную способность до 16 ТБ/с. Система поддерживает до 2 ТБ DDR5 RDIMM, а основные вычислительные компоненты получили жидкостное охлаждение.

Число 2,6 ТБ в описании такой платформы складывается из HBM3e и DDR5. Память ускорителей и системная память сохраняют разные задержки, пропускную способность и способы доступа. Этот пример полезен как напоминание о требованиях к охлаждению и иерархии памяти. Он не служит бенчмарком для Radeon AI PRO R9700: для AI-станции AMD не раскрыты независимые тесты, цена и полный набор серийных ограничений.

Память и PCIe: сможет ли система держать модель и длинный контекст

В локальном LLM-сервере нужно считать три уровня хранения: VRAM двух GPU, 64 ГБ DDR5 и SSD. Веса модели занимают лишь одну часть бюджета. Остаток нужен для KV-кэша, служебных буферов, временных тензоров, batch size и параллельных последовательностей. Запуск без ошибки показывает, что модель загрузилась. Он не подтверждает комфортную работу с длинным контекстом.

VRAM двух карт: считать суммарный объём только после проверки режима распределения

Если Qwen 3.8 27B целиком размещён на одной карте, вторая GPU может использоваться для отдельного процесса или оставаться свободной. При шардировании веса делятся между двумя ускорителями, но runtime резервирует память под собственные буферы и обмен. Поэтому доступный остаток под KV-кэш нельзя вычислить простым сложением паспортной VRAM.

Для каждого режима нужно записать:

• объём VRAM до загрузки модели;
• память после загрузки весов;
• резерв под KV-кэш;
• память при коротком и длинном контексте;
• изменение раскладки при FP8, MXFP4 и Flash Next;
• загрузку каждой GPU во время prefill и decode.

Практический пример чтения логов: если одна GPU загружена почти полностью, а вторая использует небольшой объём памяти, конфигурация не получает полного эффекта от двух ускорителей. Если память распределена равномерно, нужно проверить цену межGPU-обмена и фактическую скорость генерации.

64 ГБ DDR5: полезный запас для offload, но не замена VRAM

DDR5 может принять часть весов, служебные структуры, экспертов или KV-кэш, если это умеет выбранный runtime. Такой перенос увеличивает шанс загрузки модели, однако CPU-RAM обладает другой пропускной способностью и задержками. Каждое обращение к вынесенной части может увеличить latency.

Для 64 ГБ DDR5 особенно важно оставить запас операционной системе, драйверу, процессу runtime и кэшу файловой системы. Если весь объём занят моделью и offload-буферами, параллельные запросы быстро приведут к нехватке памяти. Сам факт размещения части весов в RAM не превращает сервер в систему с общей VRAM.

Практический разбор бюджета памяти для Qwen 3.8 27B есть в материале о Qwen 3.8 27B и расчёте VRAM. Логику расчёта можно перенести на двухGPU-сценарий, а конкретные значения нужно получать заново для Radeon и выбранного backend.

PCIe 5.0 x8: когда пропускная способность становится ограничением

PCIe 5.0 x8 может быть достаточным для части задач, но сам номер поколения не отвечает на вопрос о производительности. Нужно проверить фактический link width каждой карты, подключение к процессору, работу чипсета, совместное использование линий с SSD и поведение соединения под нагрузкой.

Ограничение проявляется сильнее в трёх сценариях:

• модель часто обращается к данным в DDR5;
• шардированный runtime передаёт промежуточные результаты между GPU;
• несколько процессов одновременно читают большие файлы или используют offload.

При раздельной обработке запросов обмен между GPU может быть небольшим. При tensor parallelism он способен стать главным фактором задержки. Поэтому PCIe 5.0 x8 нельзя заранее объявлять узким местом или гарантией высокой скорости. Нужны замеры с одной GPU, двумя GPU, offload и несколькими конкурентными запросами.

KV-кэш и длинный контекст: почему запуск модели ещё не означает поддержку большого окна

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

Длинный контекст может заполнить свободную VRAM после успешной загрузки весов. KV-квантизация снижает расход памяти, но может затронуть качество и скорость. При вынесении KV-кэша в DDR5 добавляется обмен через PCIe. При обращении к SSD задержка становится ещё выше, поэтому накопитель не заменяет запас видеопамяти.

В отдельном разборе Qwen 3.8 Flash Next в llama.cpp подробно показано, почему объём VRAM, размещение PLE и тип KV влияют на поведение модели при длинном контексте. Для vLLM Radiance и R9V понадобятся собственные замеры: одинаковые названия режимов не означают одинаковую механику памяти.

Qwen 3.8 27B: FP8 и MXFP4 - что меняется в реальной работе

FP8 и MXFP4 отвечают прежде всего за представление весов. Они меняют объём модели, доступный запас под KV-кэш и требования к kernel. Квантизация KV-кэша относится к другой части памяти. Смешивать эти эффекты в одном сравнении нельзя.

Что именно сравнивается: модель, revision, файл и runtime

Честный тест фиксирует одну ревизию Qwen 3.8 27B, одинаковый chat template, stop-токены, системный промпт, длину контекста, batch size, concurrency и параметры sampling. В таблице нужно указать точные имена файлов FP8 и MXFP4, backend, драйвер и аргументы запуска.

Если FP8 и MXFP4 запускаются через разные реализации, результат описывает связку «формат плюс runtime», а не чистую разницу квантизации. Это допустимый практический тест, если ограничение указано прямо. Сравнивать такие числа с результатами другой архитектуры или другого движка без оговорок нельзя.

FP8 как базовый режим для сравнения

FP8 удобно использовать как отправную точку, когда требуется проверить баланс между памятью, качеством и скоростью. На конкретном стенде нужно измерить, помещаются ли веса на одну GPU, как они распределяются на двух картах и сколько VRAM остаётся под KV-кэш.

Качество следует проверять на коде, рассуждениях, структурированном JSON, многошаговых инструкциях и длинных ответах. Отдельные тесты нужны для prefill и decode: формат может по-разному влиять на загрузку входа и генерацию токенов. Без логов нельзя объявлять FP8 самым быстрым или самым качественным режимом.

MXFP4: экономия памяти в обмен на дополнительные компромиссы

MXFP4 использует более компактное 4-битное представление и потенциально освобождает VRAM под KV-кэш или дополнительные последовательности. Практическая выгода появляется только при наличии поддержки формата в выбранном backend и подходящих kernel.

Нужно проверить четыре результата:

• размер модели и остаток VRAM после загрузки;
• TTFT и скорость decode;
• стабильность при длинном контексте и нескольких запросах;
• качество на одинаковом наборе задач.

Меньший файл не гарантирует более высокую скорость. Декодирование может упереться в пропускную способность памяти, межGPU-обмен, CPU или конкретную реализацию операций. Если MXFP4 позволяет держать больше KV-кэша, его преимущество может проявиться в длинном диалоге, даже при близкой скорости генерации.

Квантизация весов и квантизация KV-кэша - не одно и то же

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

Для сравнения FP8 и MXFP4 следует оставить одинаковый режим KV. Если одновременно меняются веса и KV, результат нужно разделить на два эксперимента. Иначе экономию памяти или изменение качества легко приписать неправильному фактору.

Qwen 3.8 Flash Next: локальный запуск с vLLM Radiance и R9V

Qwen 3.8 Flash Next нужно оценивать отдельно от Qwen 3.8 27B. У моделей могут отличаться архитектура, требования к памяти, способ размещения экспертов и поведение при длинном контексте. Связка vLLM Radiance и R9V способна изменить результат сильнее, чем формальная разница между двумя видеокартами, но конкретные функции компонентов требуют подтверждения по конфигурации кейса.

Близкий по теме разбор запуска Qwen 3.8 Flash Next на четырёх R9700 через vLLM полезен как ориентир для списка проверок. Его нельзя автоматически использовать как бенчмарк для двух GPU.

Что именно нужно зафиксировать в связке vLLM Radiance и R9V

Воспроизводимость начинается с точных версий. В карточке эксперимента нужно указать версию vLLM Radiance, назначение R9V, версию драйвера, ROCm, Python и ключевых зависимостей. Если R9V выступает патчем, библиотекой или отдельным компонентом runtime, это определение должно присутствовать в описании.

Параметры запуска должны включать число GPU, режим tensor parallelism или model parallelism, batch size, concurrency, максимальную длину контекста, лимит памяти GPU, режим attention и используемые kernel. Полезно сохранить полный командный вызов, а не перечень нескольких самых заметных флагов.

Пример списка полей для лога:

model_revision
weights_format
runtime_version
driver_and_rocm
parallelism_mode
context_length
batch_size
concurrency
kv_cache_dtype
offload_mode

Tiered expert offload: где он помогает и какой ценой

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

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

В логах нужно разделить:

• объём экспертов в VRAM;
• объём данных в DDR5;
• роль SSD и размер его кэша;
• частоту обращений к каждому уровню;
• время загрузки и время генерации после прогрева;
• нагрузку PCIe, CPU и системной памяти.

Offload расширяет пространство размещения модели. Он не создаёт бесплатную дополнительную VRAM и не гарантирует прежнюю задержку.

Похожие вопросы по сочетанию VRAM, RAM, NVMe и патчей vLLM разобраны в материале о локальном стеке Qwen 3.8 27B на двух GPU. Аппаратные и программные цифры там нельзя переносить на Radeon без повторной проверки.

Flash Next и длинный контекст: что проверять кроме запуска без ошибки

Для Flash Next нужно отдельно замерить короткий диалог, длинный документ, RAG-контекст и длительную генерацию. В каждом сценарии фиксируются TTFT, prefill, decode, расход VRAM и DDR5, рост KV-кэша, число ошибок и поведение после OOM.

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

Как сравнивать конфигурации без самообмана

Один показатель tokens/s плохо описывает локальный сервер. Пользователь видит задержку первого токена, время обработки длинного входа, скорость продолжения ответа и поведение при конкуренции. Поэтому тест должен разделять prefill, TTFT, decode и полный latency.

Какие метрики публиковать

Метрика	Что показывает	Почему нужна
TTFT	Задержка до первого токена	Описывает ощущение отклика сервера
Prefill, tokens/s	Скорость обработки входного текста	Особенно важна для длинных документов и RAG
Decode, tokens/s	Скорость генерации продолжения	Показывает поведение при обычном диалоге
Полное время ответа	Время от запроса до последнего токена	Связывает prefill и decode с пользовательским результатом
Throughput	Суммарная производительность при параллельных запросах	Нужна для нескольких пользователей и фоновых задач
VRAM и DDR5	Распределение памяти по уровням	Показывает запас под контекст и новые запросы
Температура и hotspot	Поведение GPU после прогрева	Помогает выявить троттлинг и проблемы охлаждения
Энергопотребление	Нагрузка на GPU и платформу	Влияет на питание, шум и стоимость эксплуатации
Ошибки	OOM, сбои kernel, зависания и переполнения	Отделяет демонстрационный запуск от рабочего режима

Единый протокол для FP8, MXFP4 и Flash Next

1. Закрепить версии моделей, файлов, runtime, драйвера и ROCm.
2. Использовать одинаковые промпты, chat template, длину входа и длину ответа там, где сравнение это допускает.
3. Зафиксировать batch size, concurrency, sampling, контекст и режим KV.
4. Выполнить несколько прогонов после прогрева GPU и отдельно записать первый запуск.
5. Снять показатели каждой видеокарты, CPU, DDR5, SSD, температуры и питания.
6. Повторить тест на одной GPU, двух GPU с шардированием, двух GPU с раздельными запросами и с offload.
7. Проверить качество на одинаковых заданиях: код, JSON, извлечение фактов, длинный документ и многошаговая инструкция.

Для каждого числа нужно обозначить происхождение: лог конкретного кейса, документация компонента или самостоятельный замер. Если подтверждённых логов нет, корректная формулировка звучит как «требует проверки», а не как готовый результат.

Масштабирование с одной GPU на две

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

Теоретическое удвоение вычислительного ресурса редко превращается в двукратное ускорение одиночного запроса. Причины понятны: межGPU-обмен, последовательные участки вычислений, загрузка CPU, несовершенные kernel и ожидание данных из DDR5. В режиме параллельных запросов масштабирование может выглядеть лучше, если запросы распределяются независимо.

Качество и формат ответа - отдельные критерии

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

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

Где проявляются ограничения: нагрев, SSD, DDR5 и настройки платформы

Многокартовый сервер может пройти короткий запуск и потерять стабильность через час. Узкие места часто возникают в охлаждении, питании, SSD, системной памяти или разводке PCIe. Их нужно проверять вместе с моделью, потому что поведение при prefill, decode и offload отличается.

Нагрев и длительная генерация

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

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

SSD как часть memory hierarchy

SSD влияет на скорость загрузки файлов модели, работу mmap, кэширование и tiered offload. При больших файлах важны свободное место, последовательное чтение и задержки случайного доступа. Длительная запись кэша может нагреть накопитель и снизить его скорость.

SSD остаётся медленнее VRAM. Он помогает хранить и подгружать данные, но перенос активных весов или KV-кэша на накопитель увеличивает latency. Для проверки нужны холодный запуск, повторный запуск после прогрева SSD, работа с одним запросом и параллельная нагрузка.

Настройки DDR5 и стабильность системы

Частота, тайминги, напряжение и режим контроллера памяти влияют на стабильность CPU-RAM. Ошибка может проявиться только при длительном offload, когда система одновременно держит модель, кэш и несколько потоков обмена.

Перед сравнением следует сохранить профиль BIOS, проверить память длительным тестом и затем прогнать инференс с максимальным планируемым объёмом DDR5. Если система стабильна на базовой частоте и нестабильна с агрессивным профилем, это нужно указать в паспорте стенда. Универсальные настройки для всех платформ здесь не работают.

PCIe-топология, питание и размещение карт

Нужно выяснить, к каким линиям подключены обе GPU и SSD, не делят ли устройства ресурс чипсета и какой link width видит система под нагрузкой. Проверка в состоянии простоя недостаточна: некоторые ограничения проявляются при одновременном чтении, offload и межGPU-обмене.

Две производительные карты требуют достаточного питания, подходящих разъёмов, свободного пространства и эффективного отвода тепла. Конкретные требования к блоку питания, кабелям и корпусу зависят от фактических лимитов Radeon AI PRO R9700 и выбранной платформы. Без этих спецификаций нельзя честно называть точную мощность БП или обязательный тип охлаждения.

Кому подходят две видеокарты для локальной нейросети, а кому лучше один флагман

Выбор определяется размером модели, требуемым контекстом, числом запросов и готовностью обслуживать сложный программно-аппаратный стек. 2× Radeon AI PRO R9700 выглядят разумно при подтверждённой пользе дополнительной памяти или параллелизма. Одна флагманская GPU практичнее, когда модель уже помещается в её VRAM и важны простота с предсказуемостью.

Когда связка 2× Radeon AI PRO R9700 выглядит разумно

• Модель или нужный запас под KV-кэш не помещаются на одной доступной GPU.
• Планируется шардирование Qwen 3.8 27B или Flash Next, и выбранный runtime корректно распределяет нагрузку.
• Сервер должен обслуживать несколько запросов одновременно.
• Длинный контекст важнее минимальной задержки короткого ответа.
• Пользователь готов проверять ROCm, vLLM Radiance, R9V, драйверы и режимы offload.
• Данные нужно хранить внутри собственной инфраструктуры, без передачи запросов в облако.

Каждый пункт требует подтверждения тестом. Поддержка двух GPU на уровне драйвера ещё не доказывает эффективное распределение конкретной модели.

Когда одна дорогая флагманская GPU будет проще

• Модель, веса и нужный KV-кэш уже помещаются на одной карте.
• Основная нагрузка состоит из коротких одиночных запросов.
• Нет желания настраивать сложную PCIe-топологию, offload и альтернативные backend.
• Критичны низкий шум, простой корпус, меньшее энергопотребление и быстрый ремонт.
• Нужна максимально предсказуемая совместимость с прикладным ПО.

Одна GPU сокращает число компонентов и межGPU-операций. В результате настройка обычно проще, а причины просадки производительности легче найти.

Матрица выбора: модель, контекст, запросы или простота эксплуатации

Критерий	2× Radeon AI PRO R9700	Одна флагманская GPU
Крупная модель	Подходит при рабочем шардировании или offload	Подходит, если модель и буферы помещаются в VRAM
Длинный контекст	Есть дополнительный ресурс, но KV и обмен нужно измерять	Проще оценить бюджет памяти, запас может быть меньше
Параллельные запросы	Можно распределять запросы между картами	Проще настройка, но меньше независимого ресурса
Одиночный запрос	Прирост зависит от эффективности шардирования	Меньше межGPU-обмена
Программный стек	Потребуется проверка ROCm, runtime и kernel	Чаще достаточно одного поддерживаемого backend
Охлаждение и питание	Выше требования к корпусу, воздушному потоку и БП	Проще разместить и охладить
Стоимость платформы	Считать нужно GPU, CPU, плату, БП, корпус, SSD и охлаждение	Меньше сопутствующих компонентов, но цена самой карты может быть выше

Итоговый чек-лист перед сборкой локального сервера для Qwen 3.8

Перед покупкой или сборкой нужно подтвердить характеристики обеих Radeon AI PRO R9700, реальную VRAM, PCIe-топологию и совместимость выбранного runtime. После этого проверяются формат весов, место под KV-кэш, tiered expert offload, SSD, DDR5 и стабильность при длительной нагрузке.

Что обязательно указать в итоговой таблице

Группа	Поля для публикации
GPU	Модель, VRAM каждой карты, лимит мощности, частоты, загрузка, температура ядра и hotspot
Платформа	CPU, материнская плата, PCIe generation и link width, NUMA-топология, блок питания, корпус и охлаждение
Память	64 ГБ DDR5, частота, тайминги, свободный объём, распределение данных между VRAM и RAM
Накопитель	Модель SSD, свободное место, скорость чтения, роль в mmap, кэше и offload
Модель	Qwen 3.8 27B FP8, Qwen 3.8 27B MXFP4 или Flash Next, revision и точный файл
Runtime	vLLM Radiance, R9V, версии драйвера и ROCm, backend, kernel, режим parallelism
Контекст	Длина входа, длина ответа, максимальный контекст, KV dtype и размер KV-кэша
Скорость	TTFT, prefill tokens/s, decode tokens/s, полное время ответа и throughput
Надёжность	OOM, ошибки kernel, зависания, восстановление после сбоя и результат длительного прогона
Происхождение данных	Описание кейса, документация компонента или лог конкретного запуска, с указанием условий измерения

Короткий практический вывод без маркетинговых обещаний

2× Radeon AI PRO R9700 стоит рассматривать как специализированную платформу для локальных LLM. Её смысл раскрывается при работе с моделями, которым тесно на одной карте, с длинным контекстом, несколькими параллельными пользователями и экспериментами с распределением экспертов.

В связке с Qwen 3.8 27B нужно отдельно проверить FP8 и MXFP4, а Flash Next запускать как самостоятельный сценарий через зафиксированные версии vLLM Radiance и R9V. Пока нет подтверждённых логов конкретного стенда, нельзя обещать определённую скорость, температуру или коэффициент ускорения.

Если модель помещается на одной флагманской GPU, а приоритетом служат простая настройка, умеренный шум и предсказуемость, одна карта может оказаться практичнее. Если важнее запас памяти, локальность данных и параллельная работа, две Radeon способны дать полезный ресурс при условии, что программный стек, PCIe, охлаждение, DDR5 и SSD выдерживают выбранную нагрузку.

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