В описанном кейсе vLLM-Radiance на системе с четырьмя Radeon R9700 AI Pro работал заметно быстрее обычного vLLM на том же железе. Главный вывод связан с программным стеком: количество GPU задаёт аппаратный потенциал, а серверный движок определяет, насколько эффективно этот потенциал используется при запуске конкретной модели.
Такое сравнение полезно именно потому, что видеокарты, процессор и платформа остаются неизменными. Разницу можно искать в runtime, поддержке операций, работе с памятью, распределении вычислений и параметрах запуска. При этом результат нельзя автоматически переносить на любую модель или нагрузку.
В доступном описании кейса нет численных значений prefill, TG и acceptance rate. Поэтому корректнее воспринимать его как практический сигнал для проверки альтернативного движка на AMD-конфигурации, а не как универсальное доказательство превосходства vLLM-Radiance. Перед покупкой оборудования или переносом рабочего сервера понадобится повторить замеры на своей модели, версии ROCm и схеме параллелизма.
Что показал запуск vLLM-Radiance на четырёх GPU
Главный вывод: четыре карты сами по себе не гарантируют высокую скорость
Четыре Radeon R9700 AI Pro могут дать большой запас вычислительных ресурсов и видеопамяти, однако суммарные характеристики карт не превращаются автоматически в пропорциональный прирост скорости. При распределении модели между устройствами появляются дополнительные операции синхронизации, обмен данными и требования к пропускной способности PCIe.
Если одна карта получает больше работы, отдельная операция не поддерживается выбранным backend или обмен между GPU становится узким местом, часть вычислительного потенциала простаивает. В мониторинге это может выглядеть как неравномерная загрузка устройств: одна карта занята, остальные ждут синхронизации или получают короткие очереди задач.
Сравнение vLLM-Radiance и обычного vLLM на одной системе помогает отделить влияние программного слоя от влияния железа. Оно не отвечает на вопрос, какой движок быстрее вообще. Корректный вывод звучит уже: конкретная связка vLLM-Radiance, модели, ROCm и настроек лучше использовала эту конфигурацию в описанной нагрузке.
Похожий подход к проверке четырёх R9700 разобран в материале о запуске Qwen3.8-Flash-Next через vLLM. Там отдельно рассматриваются распределение модели, квантование, память и показатели prefill и generation.
Почему результат нельзя переносить на любой сценарий
Производительность inference меняется вместе с моделью и характером запросов. На неё влияют:
- размер модели и архитектура, включая наличие MoE-компонентов;
- формат и уровень квантизации;
- длина входного контекста и размер ответа;
- batch size и число параллельных запросов;
- режим распределения модели, например tensor parallelism или pipeline parallelism;
- версии ROCm, драйвера и самого runtime;
- доля операций, которые движок выполняет на GPU без fallback на CPU.
Движок, который выигрывает на длинном prompt, может не дать такого же результата в интерактивном чате. Сервер с высоким суммарным throughput при нескольких пользователях способен иметь заметную задержку первого токена для одного запроса. Поэтому единичный максимум tokens per second описывает лишь один режим работы.
vLLM-Radiance против обычного vLLM: что именно сравнивается
Одинаковое железо не означает одинаковое поведение движка
Локальный стек LLM состоит из нескольких уровней. Модель задаёт набор операций и требования к памяти. Runtime планирует запросы и управляет выполнением. GPU backend выбирает поддерживаемые ядра и способы работы с памятью. Слой параллелизма распределяет вычисления между устройствами. API-сервер добавляет очередь, обработку запросов и сетевые накладные расходы.
Изменение одного уровня может повлиять на весь результат. Два движка способны по-разному загружать веса, выделять KV-кэш, обрабатывать батчи и синхронизировать карты. На AMD-системе к этому добавляется зависимость от версии ROCm и поддержки конкретных операций для выбранного поколения GPU.
При этом нельзя без логов утверждать, какая именно внутренняя функция дала преимущество vLLM-Radiance в описанной конфигурации. Для технического вывода нужны версии компонентов, параметры запуска, логи загрузки и мониторинг всех четырёх GPU. Без этих данных разница между движками остаётся наблюдаемым результатом конкретного теста, а не объяснённым механизмом.
Какие параметры сравнения нужно вынести в отдельную таблицу
Перед замером полезно зафиксировать окружение в одной таблице. Это защищает от ошибочного сравнения, когда вместе с движком меняются модель, квантизация или режим параллелизма.
| Параметр | Что записать | Зачем это нужно |
|---|---|---|
| Runtime | Версии vLLM-Radiance и обычного vLLM | Разные сборки могут содержать разные backend и исправления |
| GPU-стек | Версии ROCm и драйвера | Совместимость и доступность операций зависят от окружения |
| Модель | Название, размер, формат и квантизация | Вес модели и точность вычислений меняют требования к памяти и скорости |
| Параллелизм | Число GPU, tensor parallelism, pipeline parallelism | Схема распределения определяет объём обмена между картами |
| Контекст | Число входных и выходных токенов | Позволяет разделить нагрузку prefill и generation |
| Нагрузка | Число одновременных запросов и размер batch | Один запрос и очередь пользователей создают разный профиль нагрузки |
| Результат | Prefill, TG, TTFT, latency, acceptance rate | Набор метрик показывает поведение сервера полнее одного throughput |
Как читать prefill, TG и acceptance rate
Prefill: насколько быстро сервер обрабатывает входной контекст
Prefill, или первичная обработка prompt, проходит до начала последовательной генерации. Модель читает входные токены, строит внутренние представления и заполняет KV-кэш. Показатель обычно выражают в токенах в секунду.
Высокий prefill полезен при работе с длинными документами, RAG-контекстом, большими файлами и пакетной обработкой. Если в запросе много входных токенов, ускорение этой фазы сокращает время до первого токена. Однако итоговая задержка включает очередь, подготовку запроса и служебные накладные расходы, поэтому prefill нельзя напрямую приравнивать к TTFT.
Для честного сравнения нужно указывать размер prompt. Prefill 1000 токенов в секунду на коротком запросе и тот же показатель на длинном контексте создают разную нагрузку на систему. Полезная запись выглядит так: число входных токенов, время обработки, TTFT и доля времени, ушедшая на очередь.
TG: скорость генерации ответа после обработки prompt
TG, или token generation, описывает скорость декодирования после завершения prefill. На этой фазе модель последовательно выбирает новые токены, используя предыдущий контекст. Показатель особенно заметен в интерфейсе чата: при TG 20 токенов в секунду один новый токен появляется примерно за 50 миллисекунд, если не учитывать дополнительные задержки.
Для коротких диалогов TG часто сильнее влияет на субъективную отзывчивость, чем высокий prefill. Пользователь быстро отправляет небольшой prompt и ждёт поток ответа. В RAG-сценарии с большим документом картина другая: сначала важна обработка контекста, затем скорость генерации.
TG тоже нельзя рассматривать отдельно. При нескольких параллельных запросах движок может повысить суммарный throughput, распределяя вычисления пакетами, но задержка отдельного ответа при этом изменится. В отчёте нужно указывать, идёт ли речь о скорости одного запроса или о суммарной производительности сервера.
Acceptance rate: полезный показатель, но не универсальный рейтинг движка
Acceptance rate обычно связан с ускоренной генерацией, где один компонент предлагает несколько токенов, а основная модель проверяет их. Метрика показывает долю принятых предложенных токенов. В упрощённом виде её можно представить как отношение числа принятых токенов к числу предложенных.
Высокий acceptance rate способен повысить эффективность speculative decoding, но сам по себе не сообщает итоговую скорость. На показатель влияют модель и вспомогательный механизм, температура, структура текста, длина ответа и параметры проверки. Для кода, обычного диалога и строго структурированного JSON значения могут различаться.
Сравнивать acceptance rate нужно при одинаковой модели, одинаковых запросах и одинаковых настройках ускоренной генерации. Если один движок использует такой механизм, а второй нет, прямое сравнение показателя теряет смысл. Acceptance rate не измеряет качество ответа и не заменяет TG, TTFT или общую latency.
Почему одна высокая метрика не описывает весь inference
| Сценарий | Что смотреть в первую очередь | Почему |
|---|---|---|
| Короткий интерактивный чат | TTFT, TG, inter-token latency | Пользователь оценивает скорость старта и плавность потока ответа |
| Длинный RAG-контекст | Prefill, TTFT, расход KV-кэша | Основное время может уходить на чтение входного документа |
| Генерация длинного ответа | TG, общая latency, стабильность | Декодирование выполняется последовательно и занимает большую часть времени |
| Несколько пользователей | Суммарный throughput, latency каждого запроса, загрузка GPU | Высокая скорость очереди может сопровождаться ростом задержки отдельных запросов |
| Speculative decoding | Acceptance rate, TG, фактическое время ответа | Процент принятых токенов полезен только вместе с итоговым ускорением |
Методика сравнения prefill и decode на одной модели подробно разобрана в материале о честном сравнении локального запуска Qwen 3.8 27B. Такой подход помогает не смешивать скорость чтения prompt со скоростью генерации.
Что определяет результат: GPU, PCIe, CPU и выбранная модель
Четыре Radeon R9700 AI Pro: потенциал зависит от совместной работы карт
Главный вопрос для четырёх GPU звучит так: какую часть времени карты считают, а какую ждут друг друга. Если модель разделена между устройствами, runtime должен передавать промежуточные данные и синхронизировать этапы вычислений. Чем чаще происходит обмен, тем сильнее результат зависит от задержки и пропускной способности соединения.
Суммарная VRAM четырёх карт не превращается автоматически в единый быстрый пул памяти. Модель может распределяться между устройствами, однако каждый фрагмент вычисления всё равно зависит от выбранной схемы параллелизма и обмена данными. Ошибка в распределении способна привести к переполнению памяти одной карты даже при свободной памяти на остальных.
После запуска нужно проверить, что runtime видит все четыре Radeon R9700 AI Pro. В логах не должно быть сообщений о пропущенном устройстве, fallback на CPU или загрузке модели только на части карт. Мониторинг покажет, равномерно ли расходуется память и появляется ли вычислительная нагрузка на каждом ускорителе.
PCIe и топология системы могут стать скрытым ограничением
Материнская плата может предоставить четырём слотам разные режимы PCIe. Часть линий способна идти напрямую к процессору, другая часть, через чипсет. Нужно проверить фактический режим каждого слота, количество линий и то, не делятся ли они с накопителями или другими устройствами.
Для multi-GPU inference важна реальная топология, а не перечень слотов в спецификации платы. Даже при одинаковом названии PCIe разные устройства могут иметь неодинаковый путь обмена. При интенсивной передаче тензоров это отражается на масштабировании: добавление четвёртой карты увеличивает ресурсы, но одновременно повышает объём синхронизации.
Проверять нужно три уровня: режим PCIe каждой карты, связь GPU с CPU и размещение устройств в слотах. Изменение одного режима не гарантирует ускорение. Оно помогает только тогда, когда именно пропускная способность шины ограничивает выбранную нагрузку.
CPU, RAM и storage: сервер не заканчивается на видеопамяти
Локальная LLM-система использует процессор для подготовки запросов, работы очередей, токенизации, сетевого API и части служебных операций. Оперативная память нужна для загрузки модели, временных буферов, процессов runtime и вспомогательных сервисов. Storage влияет на время старта, чтение весов и работу с кэшем файловой системы.
Конфигурацию нужно подбирать по требованиям самой модели и нагрузки. Минимальные требования условного шлюза или API не описывают ресурсы, которые понадобятся при локальном запуске модели на том же сервере. Для sizing следует учитывать CPU, RAM, storage, VRAM, размер KV-кэша и число одновременных пользователей.
Особенно заметна роль RAM при частичном offload или загрузке больших файлов модели. Если операционная система начинает активно использовать swap, задержка растёт независимо от количества GPU. Для многокартового сервера полезно заранее оставить запас памяти под несколько запросов и фоновые процессы.
ROCm, драйвер и распознавание устройств
AMD-конфигурация зависит от согласованности GPU, драйвера, ROCm и сборки движка. Обновление одного компонента способно изменить список поддерживаемых операций, поведение памяти или стабильность запуска. Поэтому версию каждого слоя нужно записывать вместе с результатом теста.
Минимальный чек-лист диагностики выглядит так:
- система видит все четыре Radeon R9700 AI Pro;
- runtime перечисляет те же устройства без ошибок;
- модель загружается в ожидаемом режиме распределения;
- в логах нет fallback на CPU и пропущенных операций;
- память и загрузка GPU меняются во время запроса;
- температура, питание и частоты не указывают на троттлинг.
Для наблюдения можно использовать rocm-smi или radeontop, если конкретная версия инструмента поддерживает установленную модель GPU. Показания нужно сопоставлять с логами runtime. Нулевая загрузка карты во время prefill или decode часто указывает на неправильное распределение, ошибку обнаружения или короткую нагрузку, которую мониторинг не успел зафиксировать.
Модель и параметры запуска важнее абстрактного числа GPU
Большая модель с низкой битностью квантизации может поместиться в память четырёх карт, но получить меньшую скорость из-за обмена между устройствами. Меньшая модель способна работать быстрее на одной карте, если ей не требуется распределение. Ответ зависит от того, что ограничивает систему: объём памяти, вычисления, bandwidth, latency обмена или размер очереди.
На результат влияют размер batch, длина контекста, максимальное число токенов ответа и конкурентность запросов. При росте контекста увеличивается объём KV-кэша. При росте конкурентности меняется планирование батчей. При выборе tensor parallelism или pipeline parallelism меняется схема обмена и балансировка нагрузки.
Материал о влиянии VRAM и контекста на скорость Qwen3.8-Flash-Next показывает, почему объём доступной памяти и способ загрузки модели нужно оценивать вместе с длиной контекста. Этот принцип применим и к многокартовым серверам на AMD GPU.
Как правильно повторить сравнение vLLM-Radiance и vLLM
Зафиксировать окружение до начала замеров
Сначала составьте паспорт тестовой системы. В него входят модель и квантизация, версии vLLM-Radiance, обычного vLLM, ROCm и драйвера, конфигурация CPU и RAM, режимы PCIe, число доступных GPU и параметры распределения модели.
Для каждого теста отдельно запишите размер входного контекста, максимальную длину ответа, batch size, число параллельных запросов и настройки speculative decoding, если они используются. Даже небольшое изменение этих параметров делает результаты разных серий несопоставимыми.
Полезно сохранить логи запуска и сведения о свободной памяти до загрузки модели. Это позволит отличить нехватку VRAM от ошибки backend, а проблему PCIe от неправильной настройки parallelism.
Проверить каждый движок после прогрева
Холодный запуск включает чтение весов, выделение памяти, компиляцию и создание служебных структур. Эти операции нельзя смешивать с рабочей скоростью генерации. Для каждого движка нужны отдельные результаты холодного старта и прогретого режима.
Перед замером отправьте несколько одинаковых запросов и дождитесь стабильного состояния. Затем убедитесь, что все четыре карты действительно участвуют в вычислениях, модель загружена в ожидаемом режиме, а в логах нет fallback или неизвестных устройств.
Повторяйте каждый сценарий несколько раз и фиксируйте разброс. Один удачный запуск может совпасть с пустой очередью, особенностями кэша или кратковременным изменением частот. Среднее значение полезно сопровождать минимальным и максимальным результатом.
Сравнить несколько типов нагрузки
Минимальная тестовая матрица должна включать пять сценариев:
- короткий диалог с небольшим prompt и коротким ответом;
- длинный prompt, который нагружает prefill;
- генерацию длинного ответа для оценки TG;
- несколько одновременных запросов для проверки планировщика и суммарного throughput;
- RAG-подобный запрос с документом и инструкцией, близкими к рабочему сценарию.
В каждой серии используйте одинаковые входы и одинаковое ограничение длины ответа. Для повторяемости нужно сохранить текст запросов, температуру, seed при наличии такой настройки и число параллельных клиентов. Если модель генерирует разные ответы, сравнивайте временные метрики на нескольких повторах, а не один случайный запуск.
Смотреть не только на пиковый throughput
В отчёт следует включить prefill, TG, time to first token, inter-token latency, общую latency, acceptance rate при наличии ускоренной генерации и загрузку ресурсов. Отдельно укажите, сколько запросов одновременно обрабатывал сервер.
Пиковый throughput отвечает на вопрос о максимальной скорости потока токенов в конкретном режиме. TTFT показывает, как быстро пользователь увидит начало ответа. Inter-token latency описывает интервалы между последующими токенами. Общая latency связывает обе фазы и служебное время.
При наличии acceptance rate добавьте описание механизма, который формирует этот показатель. Число без контекста не позволяет оценить реальное ускорение. Финальный отчёт должен содержать условия теста, диапазон результатов и признаки стабильности, включая ошибки, падение загрузки отдельных GPU и рост потребления памяти.
Кому подойдёт такой стек и где начинаются ограничения
Сценарии, где важна скорость обработки контекста
Связка четырёх AMD GPU и runtime с высоким результатом prefill может заинтересовать пользователей, которые часто отправляют модели большие входные данные. К таким задачам относятся анализ документов, RAG, разбор исходного кода, обработка архивов текстов и пакетная классификация.
В этих сценариях нужно измерять время обработки контекста на реальном размере prompt. Короткий синтетический запрос не покажет поведение сервера при чтении большого документа. Одновременно контролируйте расход KV-кэша и доступную VRAM, поскольку длинный контекст увеличивает требования к памяти.
Сценарии, где важнее скорость генерации и задержка
В коротком чате, агентском цикле или редакторе кода пользователь часто отправляет последовательность небольших запросов. Здесь важны TTFT, TG и inter-token latency. Высокий prefill не компенсирует долгий старт ответа или медленное декодирование.
Для агентских систем нужно учитывать и суммарное время цикла. Если один шаг включает несколько обращений к модели, даже небольшая задержка каждого запроса накапливается. Поэтому тестируйте последовательные вызовы, а не только независимый поток параллельных запросов.
Ограничения, которые нельзя обходить маркетинговыми обещаниями
Многокартовый AMD-сервер требует проверки совместимости на каждом уровне. Возможны проблемы с распознаванием новых GPU, неполной поддержкой операций в ROCm, ограничениями материнской платы и неравномерной загрузкой карт.
Аппаратная часть тоже требует расчёта. Четыре ускорителя создают требования к питанию, охлаждению, корпусу и расстоянию между слотами. Без подтверждённых характеристик конкретной модели Radeon R9700 AI Pro нельзя заранее назвать расход энергии или необходимый блок питания. Эти параметры нужно брать из документации на реальные карты и платформу.
Обновление драйвера, ROCm или runtime способно изменить результат. Рабочую конфигурацию следует фиксировать по версиям и сохранять удачные параметры запуска. Иначе повторный тест через несколько месяцев может отличаться даже при том же железе.
Такой стек оправдан для локальных LLM, когда важны контроль над данными, большой объём доступной памяти, несколько одновременных пользователей или интерес к настройке AMD-платформы. Для одного короткого чата более простая система может дать лучшую совокупность цены, шума, энергопотребления и времени обслуживания.
Итоги: что действительно показывает кейс с четырьмя GPU
- vLLM-Radiance стоит рассматривать как отдельный runtime-кандидат для AMD-конфигураций. Описанный запуск показывает, что альтернативная сборка способна заметно изменить поведение многокартового inference на том же железе.
- Prefill, TG, acceptance rate, TTFT и общую latency нужно читать вместе. Высокий результат одной метрики не описывает весь пользовательский сценарий.
- Итог определяет полная связка: Radeon R9700 AI Pro, PCIe-топология, CPU, RAM, VRAM, storage, ROCm, драйвер, модель, квантизация и параметры нагрузки.
Перед повторением запуска зафиксируйте версии компонентов, проверьте распознавание всех GPU, прогрейте оба движка и сравните несколько типов запросов. Единичный бенчмарк помогает найти направление для проверки. Решение о переходе на vLLM-Radiance стоит принимать по результатам собственной тестовой матрицы, а не по одному максимальному числу.