Ознакомительный фрагмент — примерно четверть от полного материала, производительность в FP8. 4-бит, llama.cpp, hipfire и выводы в полной версии. Полная версия доступна по подписке.

Введение

Поводом для написания статьи, которая станет циклом, как упоминал в ТГ-канале, стало тестирование vLLM Radiance — форка vLLM с доработками специально для поддержки Radeon AI Pro R9700, который показал фантастический реальный рост производительности в этом сочетании.

<…>

Сами по себе попытки запустить AITER для Radeon R9700 делались давно и, в целом, запустить эти библиотеки было вполне возможно. Как и устранить все выявленные дефекты. И 23 сентября появляется сборка vLLM Radiance, которая интегрировала в себя не только свежайший vLLM 0.30.0, но и широчайший набор багфиксов, исправляющих производительность. А так же кастомное ядро для поддержки формата MXFP4 c вычислением на FP8 ядрах, что, как минимум, позволит существенно сэкономить память и работать с 4-бит квантами без фатальных потерь точности.

Таким образом, на сегодня у нас наконец-то появилась возможность посмотреть на топовую карту AMD для ИИ в ее полной красе.

Что тестируем

В данном материале мы будем исследовать производительность различных рантаймов при работе с Qwen3.8-27B, наиболее популярной моделью своего сегмента, максимально подходящей для одиночных карт с памятью в 32GB.

В сравнении будут участвовать:

1. AMD Radeon AI Pro R9700 32GB (далее R9700)
2. Nvidia RTX PRO 4500 Blackwell 32GB (далее RTX4500) — прямой конкурент по позиционированию и памяти
3. Nvidia RTX PRO 5000 Blackwell 72GB (далее RTX5000) — прямой конкурент по скорости памяти 1 GPU против суммы 2х R9700
4. Nvidia RTX PRO 6000 Blackwell 96GB (далее RTX6000) — для сравнения и как задел на будущие материалы

Все карты будут в вариантах TP1 и TP2. TP — tensor parallel. TP1 — означает один GPU, фактически без параллельности, как удобное обозначение. TP2 — две карты с параллельным исполнением одной модели. Кроме TP, могут встречаться обозначения PP (pipeline parallel — конвейерный параллелизм, количество этапов разделения по конвейеру), EP (EP — expert parallel, экспертный параллелизм — эксперты делятся по GPU) и DP (data parallel, параллельность по данным — количество независимых групп GPU, независимо вычисляющих одну и ту же модель, ресурсы GPU не объединяются) а так же их варианты PP1, PP2 и т. д. с логикой, аналогичной TP. В данной статье тестирование идет для TP1/TP2 PP1 EP1 DP1.

Испытания запускались на следующих платформах:

• R9700: CPU Ryzen 9 5950X 16 °C/32T, 128GB DDR4, 2x PCI-E 4,0×8 для GPU
• RTX4500: аренда в облаке, 32 vCPU, 148GB DDR5, 2x PCI--E 5,0×16 для GPU
• RTX5000: CPU Ryzen 9 9950X3D2 16 °C/32T, 128GB DDR5, 2x PCI-E 5,0×8 для GPU
• RTX6000: аренда в облаке, 32 vCPU, 288GB DDR5, 2x PCI--E 5,0×16 для GPU

<…>

Пока писалась большая статья, получилось побочное исследование скорости работы Unsloth/NVFP4 моделей, относительно таких же квантов Nvidia.

Изначально поводом для проверки стала страница unsloth/Qwen3.6-27B-NVFP4, на которой заявлялось, что NVFP4 квант Unsloth в 2,5 раза быстрее NVFP4 кванта Nvidia на том же железе.

Аналогичные заявления были у Unsloth и в заметке про Qwen3.8-27B, ссылаясь на анлогию с 3.6.

Т.к. именно на 3.8-27B готовились материалы к статье про Radeon, параллельно были проверены и кванты Unsloth против Nvidia. И как видно по первым 5 картинкам — разницы нет ни на одном из GPU Nvidia, на которых делались тесты:

Ок. Прогоним тест на Qwen3.6-27B вместо 3.8. Не могут же люди нас просто обманывать. Вторые пять картинок это как раз прогон на RTX PRO 5000:

Развернуть

Минутка проверки гипотез

Пока писалась большая статья, получилось побочное исследование скорости работы Unsloth/NVFP4 моделей, относительно таких же квантов Nvidia.

Изначально поводом для проверки стала страница unsloth/Qwen3.6-27B-NVFP4, на которой заявлялось, что NVFP4 квант Unsloth в 2,5 раза быстрее NVFP4 кванта Nvidia на том же железе.

Аналогичные заявления были у Unsloth и в заметке про Qwen3.8-27B, ссылаясь на анлогию с 3.6.

Т.к. именно на 3.8-27B готовились материалы к статье про Radeon, параллельно были проверены и кванты Unsloth против Nvidia. И как видно по первым 5 картинкам — разницы нет ни на одном из GPU Nvidia, на которых делались тесты:

Ок. Прогоним тест на Qwen3.6-27B вместо 3.8. Не могут же люди нас просто обманывать. Вторые пять картинок это как раз прогон на RTX PRO 5000:

Развернуть

В рамках эксперимента Qwen3.8-Flash-Next в паре с DeepSeek Harness была поставлена задача сделать source порт Commander Keen Episode 4.

После 4 дней разбора бинарников модель написала, что всё готово:

В целом, механики внутри даже работали. Можно было ходить, прыгать, стрелять и т. п. Полностью работает звук прямо сразу. Но графика и код — увы.

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

Оригинал выглядит так:

Как видит модель:

Оказалось, что не так просто сделать корректный скриншот из под Linux, особенно в безголовом режиме, когда не поднимается реальное окно. Интерактивно несколько часов потратили с моделью, пока не понял причину, что она не видит свои результаты из-за картинки. Фикс оказался простой — модель поняла, что надо снимать OpenGL буфер, а не просто скриншот.

Потом сверяли разрешения экрана и количество цветов. Тут пришлось помочь, т. к. игра запускалась изначально с меню в текстовом режиме:

А в текстовом режиме у нас 640*350. А только потом уже шла игра в 320*200. У модели самостоятельно сносило башню от этого.

Запустил тут более менее интересную нагрузку на оба ПК с GPU имеющихся в домашней лаборатории — 2x RTX PRO 5000 Blackwell 72ГБ и 2x Radeon AI Pro R9700 32ГБ.

Пара RTX PRO выдает 650-660 генерации токенов в секунду на 10-12 потоков параллельно при где-то 1,6-2 миллионах активного контекста (80-99% от примерно 2 миллионов, на которых хватает памяти) на Qwen3.8-Flash-Next-NVFP4. Бенчмарк говорил про 557 на 8 параллельных потоках, но это не предел с точки зрения мощности вычислительных блоков карт, как видно по картинке. Имеем 50-60 токенов на поток при максимально возможной загрузке, что очень не плохо. У облачного Opus — 61 токен в секунду, как писал в прошлой заметке. И это всё без MTP, который пока для свежей модели еще не работает, хотя тут возможен и регресс общей производительности. Этого за глаза не только для агентских нагрузок, но и для чата.

Два Radeon выдают около 30-40 в один поток при 200к контекста на Qwen3.8-27B-FP8 и 50+ на пустом. На 6-ти параллельных потоках картинка уже куда интереснее — до 140-180 токенов в секунду в зависимости от степени забивания памяти. У 27B модели нет чудесных n-gram весов, которые держат производительность ровной независимо от объема контекста. Это дикий скачок от llama.cpp, которая больше 50 с хвостиком не выдавала с пустым контекстом, опускаясь до 30 по мере наполнения и умирая на втором потоке. Т.е. 25-30 токенов на поток при 6 параллельных, чего для агентских сценариев в целом достаточно, хотя хотелось бы и побольше.

И для одного сетапа, и для другого это лучшее, что сейчас можно запустить, т. е. сравнение идет лучшему возможному качеству и скорости. RTX PRO с Qwen3.8-Flash-Next это где-то Opus 4.8 по общей оценке, Qwen3.8-27B где-то между Opus 4.6 и 4.7. Полез сравнивать результаты, и дальше оказалось куда интереснее:

Общий уровень интеллекта хоть и выше у американских облаков, но большей частью за счет того, что Qwen заточен именно под кодирование:

Смотрю я на графики GPT-6 и Fable-5.1 и вижу, что в задачах кодирования (SciCode) разница, конечно, в пользу облаков (увы, нет результатов Claude Opus 4.6 и 4.7 в базе), но она вообще не страшная. В агентских сценариях (GDPval-AA v2, 𝜏³-Banking? Terminal-Bench v2.1) или примерный паритет, или локальные модели где-то даже лидеры. С точки зрения галлюцинаций (AA-Omniscience Non-Hallucination Rate) опять же топовый уровень у открытых моделей.

Проигрыш в общей оценке идет полностью за счет научных бенчмарков и способности работать с документами. Да и общий уровень знаний хуже в разы, что не удивительно учитывая разницу в размере моделей в 1-2 порядка. Но какая разница для задач кодирования общего назначения? Скорее плюс Qwen в части умения сосредоточиться и выдать топовый результат в одной из самых интересных областей.

И всё это крутится на локальном железе с производительностью от весьма приемлемой до уровня «лучше чем в облаке».

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

Несколько выводов:

Вчера задали вопрос — зачем локальное железо, если есть облака.

Первый ответ был — для образования. Облака дешевле.

Потом посчитал.

Для сравнения берем Qwen3.8-Flash-Next в NVFP4 против Claude Opus 4.8 с максимальным мышлением в задачах кодирования.

Параметры моделей и результаты тестов отсюда.

Уровень интеллекта идентичный. Qwen лучше для агентских задач и кодирования. Opus больше знает про мир и науку. NVFP4 чуть снизит точность Qwen, т. е. сравнение будет практически идеальным. Локальный топ против облачного топа минус три месяца (это уже само по себе интересно).

Скорость Opus по данным по ссылке выше 61 токен в секунду. По другим источникам 67. Qwen выдает на двух RTX PRO 5000 72GB примерно 69 токенов в восемь потоков на каждый из них или до 110 на один в nighly vLLM 0.29.0. Сравнимо.

При работе 4 часа в день в 4 агентских потока (несколько консервативно) на Qwen получается около 4,8 миллиона токенов в день, чуть больше 100 миллионов в месяц. Входящие токены к исходящим у меня 3:1, 97%+ кэш.

Стоимость GPU будет около 30000$ (2,6 миллиона в Регард сегодня по курсу 87 рублей). Остальной ПК нам инвариантно нужен для работы.

При помощи облачного Qwen посчитал сколько это будет стоить через API Anthropic. Получается, что месяц работы будет стоить 2800-2900$ в месяц. Т.е. локальное железо догонит подписку через 11± месяцев. На самом деле это нормальный срок окупаемости оборудования. Даже гарантия не кончится. При этом все данные локально и есть еще огромный запас по производительности. И при низком количестве потоков скорость будет хорошо быстрее облака. Qwen держит больше 100 токенов в секунду в один поток без влияния размера контекста.

Расчет сделан для 1/10 пиковой нагрузки, т. к. можно гонять 8 потоков и получить где-то х1,6 токенов пропускной способности и 24 часа вместо 4-х. Тут подписка опередит стоимость карт через месяц.

Оказалось, что сделка в виде покупки железа, не такая уж и плохая идея даже по текущим диким ценам.

Т.е. если серьёзно работать с ИИ, стоимость карт назвать завышенной реально сложно. Для юрлиц так вообще оправданная инвестиция.

На этот расчет мне задали ответный вопрос: «Есть же подписка за 200$. Ее не хватит?»

Экспериментальная рубрика ИИ-шница. ИИ пишет про ИИ. Текст по сумме постоянных вопросов и обсуждений «почему в vLLM нет деградации производительности при большом количестве параллельных запросов». Промпты, вычитка и борьба с галлюцинациями авторские.

Запуск большой языковой модели (LLM) — это непрерывная борьба с пропускной способностью памяти (Memory Wall). Вычислительные блоки современных процессоров простаивают в ожидании весов модели. Единственный способ радикально ускорить генерацию токенов без физического увеличения шины памяти — уменьшить размер данных и изменить способ их хранения.

Часть 1. Алфавит точности: Форматы данных

Веса нейросети — это огромные матрицы чисел. Исторически они хранились в формате FP32 (32-битный float), но для модели на 70 млрд параметров это потребовало бы ~140 ГБ памяти. Индустрия перешла на форматы низкой точности.

1. Форматы с плавающей запятой (Float)

• FP16 (Half Precision): 1 знак, 5 бит экспоненты, 10 бит мантиссы. Диапазон мал (до ~65504). При обучении LLM градиенты часто «вылетают» за этот предел (overflow), что приводит к появлению NaN и краху обучения.
• BF16 (Brain Float 16): Разработан Google. 1 знак, 8 бит экспоненты (как у FP32), и всего 2 бита мантиссы. Огромный диапазон значений предотвращает overflow. Это золотой стандарт для обучения и базовый формат для инференса на серверных ускорителях.
• FP8 (8-bit Float): Текущий стандарт высокопроизводительного инференса. Делится на два формата:
• E4M3: 4 бита экспоненты, 3 мантиссы. Высокая точность, малый диапазон. Используется для весов и активаций.
• E5M2: 5 бит экспоненты, 2 мантиссы. Широкий диапазон, низкая точность. Используется для градиентов при обучении.
• FP4 (4-bit Float): Экстремальное сжатие. Без аппаратной поддержки бесполезен — накладные расходы на программную распаковку съедают всю выгоду.

2. Целочисленные форматы (Integer)

• INT8: Фиксированная запятая. Отлично подходит для квантования весов, не требует сложной экспоненты.
• INT4: Самый популярный формат для потребительских видеокарт (серии RTX 30/40, Mac). Алгоритмы AWQ и GPTQ работают именно с INT4, позволяя запускать 70B модели в 24 ГБ памяти.

3. Микромасштабирование (MX — Microscaling)

• MXFP8, MXFP6, MXFP4 (NVFP4): Это не просто типы данных, а упаковочный стандарт. Суть в том, что один 8-битный коэффициент масштабирования (scale) применяется к микроблоку из 32 элементов (например, FP8 или FP4). Это позволяет сохранить точность, близкую к FP16, используя при этом 4 или 8 бита памяти.

Часть 1.1. Эффективная битовая плотность (Bits Per Parameter)

Когда говорят «4-битная модель», имеют в виду сырой размер самих весов. Но на диске и в видеопамяти (VRAM) модель всегда весит больше. Это происходит из-за накладных расходов (overhead): коэффициентов масштабирования (scales), точек нуля (zero-points), метаданных и таблиц важности (importance matrix).

Метрика BPP (Bits Per Parameter) показывает реальный размер, который занимает один параметр модели с учетом всех необходимых для его расшифровки метаданных.

Для начала, кто такой Джарвис из известного фильма:

В фильме «Железный человек» (и в других фильмах киновселенной Marvel) Джарвис (J.A.R.V.I.S.) — это искусственный интеллект, помощник Тони Старка.

Что он делает: — Управляет системами дома и лаборатории Старка: следит за безопасностью, климатом, доступом и т. д. — Помогает с бронёй Железного человека: анализирует данные в бою, подсказывает, помогает с диагностикой и управлением костюма. — Поддерживает диалог с Тони: нередко иронизирует и проявляет характер, оставаясь при этом предельно лояльным. — Его имя — акроним: Just A Rather Very Intelligent System («Просто довольно очень умная система»).

Почему автор начинает с воспоминания об выдуманном ИИ помощнике? Из-за того, что похоже этот помощник больше не выдуманный. Или, иначе говоря, автор поймал «момент Джарвиса».

Расскажу поподробнее. В домашней лаборатории присутствует несколько машин, включая моего любимца на базе двух Radeon. Во-первых, это самая бюджетная из всех машин (если не считать GPU, конечно), собранная на Авито. Материнская плата от барыги из Люберец, память из объявлений с Авито и, самое главное, плотная и постоянная любовь с софтом AMD для выжимания из двух потенциально хитовых GPU адекватной производительности. Романтика.

Но в начале теория в максимально научно популярном виде.

Посмотрим на характеристики Radeon в части вычислений:

У Radeon 9000 есть аппаратные ускорители для FP16, FP8, INT8 и INT4 вычислений.

Для тех, кто не погружен в дебри программирования, расскажу кратко про типы данных в ПК. Глобально они делятся на целочисленные — INT (Integer) и с плавающей точкой, проще говоря, с поддержкой дробей — FP (Floating Point). Целые числа просто хранят двоичное значение. Например 0011 в INT4 это 3 в привычной десятичной системе счисления. 4 в INT4 обозначает длину в 4 бита, т. е. нуля или единицы. Если нужно отличать положительные и отрицательные значения, то первый бит означает знак. Т.е. у INT4 могут быть значения от 0 до 15 или от -7 до 7 в зависимости от трактовки. В INT32 уже 32 нуля или единицы и диапазон значений до 4 миллиардов с лишним.

С FP ровно точно так же, но система чуть хитрее. Числа хранятся в виде знака, экспоненты и мантиссы. Это та самая научная запись из школы, например 3,14×10^5 (3,14 умножить на 10 в 5 степени, т. е. приписать 5 нулей. В стандартной записи это 314000).

Здесь:

3,14 — это мантисса: она хранит «значимые цифры», то есть точность числа.

10^5 — это экспонента (показатель степени): она говорит, «на сколько позиций сдвинуть запятую», то есть отвечает за масштаб (диапазон) числа.

В ПК используют 2 как основание, поэтому вместо 10 будут степени двойки.

Экспериментальная рубрика ИИ-шница. ИИ пишет про ИИ. Текст по сумме постоянных вопросов и обсуждений «почему в vLLM нет деградации производительности при большом количестве параллельных запросов». Промпты, вычитка и борьба с галлюцинациями авторские.

Управление KV-кэшем в vLLM и llama.cpp: Архитектурные различия и их последствия

Фундамент: Prefill, Decode и роль KV-кэша

Прежде чем обсуждать планировщики и сериализацию, необходимо детально разобраться в том, как именно LLM генерирует текст. Инференс любой авторегрессионной модели состоит из двух принципиально разных фаз: prefill и decode. Понимание их различий — ключ ко всей статье, потому что все оптимизации в vLLM и llama.cpp существуют исключительно для решения проблем, порождаемых этой двойственностью.

Но сначала определим центральное понятие, вокруг которого строится вся статья.

Что такое KV-кэш

KV-кэш (Key-Value Cache) — это буфер в памяти GPU/CPU, в котором хранятся промежуточные тензоры Key и Value, вычисленные механизмом самовнимания (self-attention) для каждого обработанного токена.

В трансформере на каждом слое внимания каждый токен формирует три вектора: Query (Q), Key (K) и Value (V). При генерации нового токена его Query должен быть сопоставлен с Keys всех предыдущих токенов, чтобы определить, на какие части контекста обратить внимание, и затем агрегировать соответствующие Values. Без кэша эти K и V пришлось бы пересчитывать заново на каждом шаге генерации, что привело бы к квадратичной сложности по времени. KV-кэш сохраняет их один раз, превращая каждый последующий шаг decode из O(N²) в O(N) по вычислениям. Именно этот кэш является главным потребителем VRAM при длинных контекстах и главным объектом оптимизаций, описанных в этой статье.

Prefill (Фаза заполнения)

Prefill — это первая фаза обработки запроса, на которой модель параллельно обрабатывает все входные токены промпта (включая системный промпт, историю диалога и текущее сообщение пользователя).

Как это работает технически:

1. Весь промпт токенизируется в последовательность token IDs длиной N.
2. Токены превращаются в эмбеддинги (Embeddings — плотные векторные представления токенов фиксированной размерности, полученные из таблицы эмбеддингов модели; каждый токен отображается в точку в многомерном пространстве, где семантически близкие токены расположены рядом) и подаются в трансформер одним батчем размера N.
3. На каждом слое attention вычисляется сразу для всех позиций: матрица Q умножается на транспонированную K, получается матрица attention scores размера N × N, которая затем умножается на V.
4. Результатом prefill является матрица скрытых состояний (hidden states) размера N × d (где d — размерность модели), содержащая контекстуализированные представления всех токенов промпта, а также заполненный KV-кэш для всех N позиций. Из последнего столбца этой матрицы извлекается вектор, который проходит через выходной слой (lm_head) и превращается в логиты последнего токена.

Логит (Logit) — это «сырой» числовой скор, выдаваемый финальным линейным слоем модели до применения функции softmax. Логиты представляют собой ненормализованные оценки правдоподобия каждого токена словаря; после softmax они превращаются в вероятности, из которых семплер выбирает следующий токен.

Характеристики prefill: