Что это за сборка и какие цифры она даёт
Восемь карт Radeon Pro V620 по 32 ГБ каждая складываются в 256 ГБ VRAM. Автор кейса собрал такой стенд примерно за $2800 и запустил на нём MoE-модель Qwen3.8-Flash-Next. Отчёт с конфигурацией и замерами опубликован в r/LocalLLaMA 8 октября 2026 года.
Результат после доработки софта: 60-100 токенов в секунду на декодировании и более 3000 t/s на prefill при concurrency=1 и PP=4 без tensor parallel. Это замеры автора сборки, а не тесты редакции AI-Manual.
Дорога к этим числам оказалась извилистой. Стандартный vLLM на картах не заработал совсем. llama.cpp запустился, но выдавал около 350-450 t/s на prefill и плохо справлялся с параллельными запросами. Помог кастомный форк vLLM с собственными ядрами под RDNA2, который автор писал и отлаживал вместе с Claude.
Почему Radeon Pro V620: 256 ГБ VRAM за небольшие деньги
Radeon Pro V620 - enterprise-карта на архитектуре RDNA2, которую выпускали для облачного гейминга. На борту 32 ГБ VRAM. Именно объём делает её интересной для локального инференса: восемь таких карт дают 256 ГБ видеопамяти, чего хватает под крупные MoE-модели целиком на GPU.
Автор оценивает всю сборку примерно в $2800, то есть около $11 за гигабайт VRAM, если считать по этой сумме. Сам он сразу оговаривается: по $350 за карту их, вероятно, уже не купить. Стоимость здесь не константа, а привязка к конкретной закупке и состоянию вторичного рынка.
Логика «много старой VRAM дешевле, чем мало новой» встречается и в других сборках. Похожий пример на четырёх V620 со 128 ГБ и EPYC 7452 разбирали на AI-Manual: домашний инференс-сервер за ~$3000. Родственный сюжет - CMP 170HX, где разгон памяти поднял генерацию в Qwen 3.8 27B со 110 до 202 токенов в секунду: разгон CMP 170HX до 1 890 ГБ/с.
Сколько VRAM нужно для крупных MoE-моделей
В MoE-моделях большая часть веса приходится на routed experts: набор экспертных подсетей, из которых на каждом токене активируется лишь несколько. Считается только активная часть, но хранить в памяти приходится всех экспертов. Поэтому объём VRAM для такой модели определяется не числом активных параметров, а полным набором весов.
256 ГБ позволяют держать модель целиком на картах и оставить место под KV-кэш и промежуточные буферы. Точные требования Qwen3.8-Flash-Next автор не приводит, поэтому ориентироваться на конкретные гигабайты не стоит: всё зависит от схемы квантования и длины контекста.
Ограничения старых enterprise-карт
Главное ограничение известно из того же кейса: стандартный vLLM на Radeon Pro V620 просто не работал. RDNA2 - не самая поддерживаемая архитектура для LLM-инференса, потому что основные сборки vLLM и оптимизированные ядра рассчитаны в первую очередь на NVIDIA и на свежие поколения AMD.
Практический вывод: без готовности собирать и править код такая конфигурация не поедет. Деталей про драйверы, охлаждение и питание восьми карт автор в отчёте не раскрывает, поэтому на этот счёт лучше не додумывать.
RTX 4090 на стенде присутствует, но для LLM не используется: только для моделей генерации изображений и видео. На приведённые цифры инференса она не влияет.
Почему стандартный vLLM и llama.cpp не подошли
Готовые движки провалились по двум разным причинам. vLLM не запустился на этих картах технически. llama.cpp запустился, но показал слабый prefill и не справился с параллельными запросами. Обе проблемы критичны для серверного сценария, поэтому пришлось идти своим путём.
Что такое prefill и почему он важен
Prefill - это обработка входного промпта, когда модель прогоняет через себя весь контекст перед первым токеном ответа. Decode - уже сама генерация, токен за токеном. От скорости prefill зависит время до первого токена (TTFT), и оно тем заметнее, чем длиннее промпт или контекст.
350-450 t/s на prefill для крупной MoE-модели означает секунды ожидания на длинных входах. В интерактивных сценариях, будь то чат, агент с большим системным промптом или работа с документами, это и есть та пауза перед ответом, которую пользователь замечает раньше всего.
Почему concurrency - больное место llama.cpp
llama.cpp изначально строился вокруг одиночного потока генерации, а параллельные запросы обрабатывает заметно хуже серверных движков. Автор кейса формулирует это прямо: llama.cpp плохо справляется с concurrency.
Для домашнего сервера это критично. Как только к модели обращаются несколько агентов или пользователей одновременно, слабое масштабирование превращается в очередь.
На AI-Manual разбирали отдельный случай с патчами под MoE-инференс в llama.cpp: что реально ускоряется на RTX 4080. Там видно, что ручные правки дают прирост на конкретных сценариях, но требуют времени и не снимают ограничения движка целиком. Это не делает llama.cpp плохим: он решает другую задачу и на одном потоке работает достойно, просто серверный сценарий не его профиль.
Как создавался кастомный форк vLLM с RDNA2-ядрами
Автор написал собственный форк vLLM, который работает с V620 и выдаёт приемлемые скорости. Ключевая часть - кастомные ядра под RDNA2: их собирали, тестировали и улучшали итерациями. Это адаптация движка под конкретную архитектуру GPU, а не косметический патч.
Роль Claude в разработке форка
Работа с ядрами шла с Claude: ассистент писал код, запускал сборку, прогонял тесты и правил по результатам. Получается прикладной пример использования AI-ассистента в низкоуровневой правке кода, где готового решения для поиска просто нет.
Простым такой путь не назовёшь. Итерации по ядрам требуют времени, а результат зависит от того, насколько внятно сформулирована задача и умеет ли человек читать вывод компилятора и бенчмарков. Гарантии, что форк под другую карту пройдёт тот же путь быстрее, никто не даёт.
PP=4 без tensor parallel: что это значит
Запуск идёт в режиме PP=4: pipeline parallelism на четыре стадии, tensor parallel при этом не используется. Разница принципиальная. Tensor parallel делит каждый слой между картами и требует постоянного обмена активациями на каждом шаге. Pipeline parallel разносит по картам группы слоёв, данные идут по конвейеру, а пересылок между GPU заметно меньше.
Почему выбран именно такой режим, автор не объясняет. При восьми картах меньший объём пересылок выглядит логичным выбором, но это лишь общее соображение. Второй момент: все замеры сделаны при concurrency=1, то есть при одном активном запросе.
Квантование и MTP: как выжали скорость
W4A16 для routed experts: что это даёт
В форке применена смешанная схема: routed experts квантованы в W4A16, всё остальное остаётся в BF16. W4A16 означает 4 бита на веса и 16 бит на активации, то есть основной объём весов сжимается вчетверо относительно 16-битного представления, а вычисления идут в более высокой точности.
Квантовать именно routed experts логично: в MoE-моделях они занимают большую часть веса, но на каждом токене работает лишь их часть, поэтому компактное представление даёт здесь максимальную экономию памяти. Остальные слои, включая attention и общие компоненты, оставлены в BF16, чтобы не терять точность там, где она влияет на все токены.
Замеров качества автор не приводит. Сравнивать деградацию от W4A16 на routed experts с полным BF16 просто нечем: цифры есть только по скорости.
MTP с драфтингом на 3 токена
MTP (Multi-Token Prediction) с драфтингом на три токена позволяет за один шаг предложить сразу несколько токенов и затем проверить их. Схема включена и заметно влияет на результат: с ней декодирование идёт на 60-100 t/s, без неё падает до 40-50 t/s.
Разница почти двукратная, и это важный момент для тех, кто будет повторять конфигурацию. Отчёты из разных источников без указания этого флага сравнивать бессмысленно: цифра decode сильно зависит от того, включён MTP или нет.
Результаты: 60-100 t/s decode и 3000+ t/s prefill
Итоговые цифры на Qwen3.8-Flash-Next при concurrency=1 и PP=4 без tensor parallel: 60-100 t/s на декодировании и более 3000 t/s на prefill. Диапазон 60-100 t/s взят из отчёта как есть; чем он определяется, длиной контекста или типом запроса, автор не уточняет.
| Метрика | llama.cpp | Кастомный форк vLLM |
|---|---|---|
| Prefill | 350-450 t/s | 3000+ t/s |
| Decode с MTP | нет данных | 60-100 t/s |
| Decode без MTP | нет данных | 40-50 t/s |
| Параллельные запросы | слабые, по оценке автора | данных нет (замеры при concurrency=1) |
Сравнение с llama.cpp: 800% прирост prefill
Обе цифры prefill получены на одной и той же модели, что делает сравнение корректным. Разница между 350-450 t/s и 3000+ t/s, по оценке автора, составляет примерно 800%.
По decode прямого сравнения с llama.cpp в отчёте нет, поэтому подставлять сюда цифры из других сборок не стоит: конфигурации, модели и квантование у них другие.
Для ориентира полезен разбор DeepSeek-V4-Flash на двух Radeon AI PRO R9700: prefill 1260-1360 tok/s и decode 31-50 tok/s. Это другой класс железа и другой движок, но порядок величин показывает, где проходит граница между бюджетной и современной сборкой.
Что происходит при concurrency больше 1
Все приведённые числа сняты при одном активном запросе. Как поведёт себя стенд при двух, четырёх или восьми параллельных запросах, автор не показывает.
Косвенно можно опираться на общие свойства vLLM: движок создавался как раз для обслуживания параллельных запросов через continuous batching и обычно справляется с этим лучше llama.cpp. Конкретные цифры для этого стенда остаются неизвестными.
Показательный контраст - опыт с DeepSeek-V4-Flash на одном B300: 770 токенов/с вместо ожидаемых тысяч. Причины искали в отказе MoE-ядра без expert parallel, деградации в насыщенном батче и eager-режиме. Даже на современном железе батч и параллелизм меняют картину сильнее, чем ожидается.
Ограничения и риски: что важно понимать до повторения
Начинать нужно с самого неприятного. Стандартный vLLM на V620 не работает, значит весь путь повторения упирается в наличие форка и умение его собрать. Дальше - оговорки, которые автор приводит сам в исходном отчёте.
- Цена $2800 - оценка конкретной закупки. По $350 за карту их, вероятно, уже не купить.
- Все замеры сделаны при concurrency=1 и PP=4 без tensor parallel. При других настройках цифры будут другими.
- Диапазон 60-100 t/s на decode указан с включённым MTP. Без него - 40-50 t/s.
- RTX 4090 в стенде не участвует в LLM-инференсе.
Совместимость с другими MoE-моделями
Автор планирует проверить, как форк поведёт себя с DeepSeek и GLM-5.3-Flash. На момент публикации подтверждённых данных об их работе на этом стенде нет: это планы, а не результат.
Поэтому рассчитывать, что любая крупная MoE-модель заработает сразу после загрузки весов, не стоит. Ядра писались под конкретную архитектуру и конкретную модель, перенос на другую может потребовать новых итераций.
Стоит ли повторять: кому подходит такой подход
Схема выглядит разумной, если задача - получить много VRAM за небольшие деньги и вы готовы платить за это временем на правку кода. Плюсы: 256 ГБ видеопамяти, крупные MoE-модели целиком на GPU, высокая скорость prefill после доработки. Минусы: зависимость от собственного форка, непроверенная совместимость с другими моделями, нераскрытые детали по драйверам, охлаждению и питанию восьми карт.
Плохо подходит тем, кому нужно plug-and-play. Готового образа, который ставится и работает, здесь нет: чтобы дойти до 3000+ t/s, придётся разбираться с ядрами, сборкой и конфигурацией параллелизма.
Что дальше: доработки форка и новые модели
Автор продолжает дорабатывать форк и планирует проверить совместимость с DeepSeek и GLM-5.3-Flash. Конкретных сроков и обещанных цифр он не называет, поэтому следить за обновлениями имеет смысл, но закладывать эти модели в планы заранее не стоит.
Кейс показывает работающий сценарий: старые enterprise-карты с большим объёмом VRAM остаются практичной базой для локального инференса крупных MoE-моделей, если под них адаптирован софт. Порог входа здесь не в деньгах, а в готовности работать с кодом движка.