Инженер-энтузиаст, известный под псевдонимом ciru.ai, провёл серию экспериментов с мини-ПК Beelink GTR9 Pro, оснащённым процессором AMD Ryzen AI Max+ 395 с интегрированной графикой Radeon 8060S. Целью было проверить, насколько такая система способна справляться с параллельной нагрузкой при работе с большими языковыми моделями — задача, традиционно считающаяся прерогативой серверных GPU. В коротких прогонах устройство достигло 236 токенов в секунду (tok/s) суммарной генерации на 32 одновременных запросах, а в 30-минутном тесте на выносливость удержало средние 226 tok/s без признаков тротлинга. Эти результаты опровергают распространённое мнение, что встроенные графические решения не способны эффективно обрабатывать множество параллельных запросов, хотя автор признаёт, что Radeon 8060S не предназначен для серверных стоек. Контекст эксперимента во многом определила дискуссия под предыдущей публикацией автора, где комментатор утверждал, что мини-ПК на Strix Halo «не потянет много параллельных запросов» в отличие от серверных GPU. Одновременно в ленте появился разбор от ciru.ai, где на аналогичном оборудовании было получено 242 tok/s в метрике Active weighted TG/s при работе с Gemma 4 26B в 32 слотах со спекулятивным драфтом. Эти два события побудили автора провести собственное исследование, взяв за отправную точку опубликованный рецепт и расширив его на другие модели, кванты, эмбеддинги, реранкеры и длинные промпты. В итоге была сформирована матрица из более чем двадцати тестов, результаты которых, включая ошибочные гипотезы, опубликованы в открытом репозитории.

В ходе тестирования была выявлена странная аномалия: при увеличении числа клиентов с 8 до 10 суммарная пропускная способность не росла, а падала со 149 до 99 tok/s, после чего к 32 клиентам восстанавливалась. Этот провал воспроизводился на разных сборках программного обеспечения и в разные дни, что исключило случайность. Первоначально автор предположил, что проблема связана с архитектурой модели Qwen3.6-35B-A3B, использующей гибридное линейное внимание Gated DeltaNet. Однако контрольный тест с моделью Gemma 4 26B A4B, имеющей принципиально другую структуру (чистое softmax-внимание и MoE с 3,8 млрд активных параметров), показал аналогичную впадину на тех же уровнях нагрузки. Таким образом, аномалия оказалась свойством не конкретной модели, а аппаратно-программного стека в целом. Автор перебрал размеры батча, типы KV-кэша и переменные окружения Vulkan, но кривая не сдвинулась, что указывает на более глубокие причины, возможно, связанные с управлением памятью или планировщиком задач в драйвере RADV.

Технически инференс проводился через Vulkan/RADV — основной проверенный путь для графического процессора gfx1151, с использованием готового Docker-образа. Каждый запрос был уникальным и содержал случайный префикс для исключения влияния кэша: все промпты генерировались с нуля (cache_prompt: false), а ответы ограничивались 128 токенами. Для измерения производительности использовались серверные метрики timings, а агрегированная скорость вычислялась как сумма сгенерированных токенов, делённая на фактическую длительность прогона, включая хвостовые запросы. Автор также отметил, что спекулятивный декодинг, призванный ускорять генерацию, в его конфигурации превратился из ускорителя в налог, снижая эффективность, что потребовало дополнительного анализа. Скрининг конфигов проводился одним прогоном по 75 секунд, а финальные числа снимались тремя прогонами с медианным значением. Нагрузка подавалась с соседней машины по локальной сети, а клиенты были непрерывными — отправляли следующий запрос сразу после завершения предыдущего, что имитирует максимальную нагрузку, в отличие от реальных пользователей с паузами.

Для российского рынка подобные тесты имеют особое значение в условиях ограниченного доступа к западным серверным решениям и высоких цен на GPU. Мини-ПК на базе Strix Halo могут стать доступной альтернативой для малого и среднего бизнеса, исследовательских лабораторий и стартапов, которым требуется локальный инференс без привязки к облачным сервисам. Результаты показывают, что такие системы способны обслуживать десятки одновременных пользователей, хотя и с оговорками: в тестах клиенты были непрерывными, тогда как в реальном использовании люди делают паузы, что снижает нагрузку. Тем не менее, выявленные провалы производительности требуют дальнейшего изучения, так как они могут влиять на стабильность работы в пиковые моменты. В отличие от серверных решений, где подобные аномалии часто нивелируются избыточными ресурсами, на компактных системах каждый спад пропускной способности может привести к заметным задержкам для пользователей, что критично для сценариев реального времени, таких как чат-боты или ассистенты.

Перспективы развития этого направления связаны с оптимизацией программного стека под архитектуру Strix Halo. Автор отмечает, что многие проблемы, включая провалы пропускной способности и неэффективность спекулятивного декодинга, могут быть решены обновлением драйверов, настройкой параметров батчинга и KV-кэша, а также использованием альтернативных путей инференса, например, через ROCm, который не тестировался в данной серии экспериментов. Открытые вопросы включают масштабируемость на большее количество клиентов (свыше 32), поведение при длинных промптах и влияние разных квантов на стабильность. Полные данные и конфигурации доступны в репозитории, что позволяет сообществу воспроизвести результаты и предложить собственные оптимизации. Автор также подчёркивает, что его тесты — лишь отправная точка, и для полноценного сравнения с серверными GPU необходимы аналогичные замеры на эталонных конфигурациях, например, на NVIDIA A100 или AMD MI250.

Стоит отметить, что подобные эксперименты становятся всё более актуальными на фоне глобального дефицита вычислительных ресурсов для ИИ. Например, китайские компании активно ищут альтернативы западным чипам, а в России наблюдается рост интереса к локальным решениям для инференса, особенно в сферах, где важна конфиденциальность данных. Beelink GTR9 Pro с процессором Ryzen AI Max+ 395, оснащённым 16 ядрами Zen 5 и 40 вычислительными блоками RDNA 3.5, представляет собой компромисс между производительностью, энергопотреблением и ценой. Однако, как показали тесты, даже такие системы могут преподносить сюрпризы в виде нелинейного поведения при масштабировании нагрузки. Дальнейшие исследования должны быть направлены на выяснение причин провалов и разработку методов их обхода, возможно, через изменение алгоритмов планирования запросов или использование гибридных подходов с разделением нагрузки между CPU и GPU.