С тех пор, как я научил графические карты AMD, Intel и Nvidia работать с Raspberry Pi, меня мучил вопрос:

Какой в этом смысл?

У Raspberry Pi есть только одна линия шины PCIe Gen 3, доступная для подключения к eGPU. Этого очень мало, особенно учитывая, что у современного десктопа есть как минимум один разъём с 16 линиями шины PCIe Gen 5. То есть разница составляет 8 Гт/с (гигатранзакций/с) против 512 Гт/с. Бой явно неравный.

Но мне стало любопытно, действительно ли пропускная способность шины важна всегда.

Я хотел наконец покончить с вопросом о полезности, протестировав четыре задачи на разнообразных GPU для сравнения производительности на Raspberry Pi 5 и на современном десктопном PC:

• Jellyfin и транскодирование медиа.

• Производительность графики в рендеринге, ограниченном только GPU (при помощи GravityMark).

• Производительность LLM/ИИ (и prefill, и инференс).

• Области применения нескольких GPU (в частности, LLM, потому что их запустить проще всего).

Да, именно, сегодня мы выйдем за рамки одной графической карты. Благодаря Dolphin ICS, с представителями которой я встретился на Supercomputing 25, у меня есть внешний коммутатор PCIe Gen 4 и объединительная плата на три разъёма, поэтому я с лёгкостью смогу одновременно работать с двумя картами:

TL;DR: во многих случаях Pi держится хорошо и даже выигрывает по эффективности (часто с большим отрывом), если вы согласитесь пожертвовать всего 2-5% пиковой производительности!

Четыре GPU, один Pi

Самое безумное здесь то, что пока я заканчивал своё тестирование, пользователь GitHub mpsparrow подключил к одному Raspberry Pi четыре GPU Nvidia RTX A5000. При работе Llama 3 70b его машина генерировала производительность, всего на 2% отличающуюся от референсного сервера Intel:

На Pi она генерировала ответы со скоростью 11,83 токена в секунду. На современном сервере с точно такими же GPU он получил 12. Разница в производительности меньше двух процентов.

Как такое возможно? Причина в том, что Pi здесь никак не препятствует работе GPU; по крайней мере, Nvidia, способных обеспечивать общий доступ к памяти через шину PCIe. Внешний коммутатор PCIe может позволить картам разделять память по шине со скоростями Gen 4 или Gen 5, а не требовать перемещения «север-юг» по линии PCIe Gen 3 платы Pi.

Но даже без трюков с несколькими GPU и PCIe плата Pi может сравниться по производительности с современным PC, а в некоторых случаях и превзойти его.

Стоимость и эффективность

Можно учитывать не только экономичность, но и цену (в стоимость обеих систем не включена графическая карта):

Если вы не стремитесь к пиковой экономичности и производительности, то учтите, что Pi отдельно потребляет 4-5 Вт в режиме простоя. А что насчёт PC? 30 Вт. И это без работающей графической карты; кроме того, в обоих случаях единственное, что было подключено во время измерений — это дешёвые USB-клавиатура и мышь для Raspberry Pi.

Давайте перейдём к оборудованию.

Видео

Подробности об аппаратном содержимом машин можно посмотреть в видео:

Сравнения с одним GPU: Pi против Intel Core Ultra

Прежде чем мы перейдём к бенчмаркам, которые я выполнял, сначала следует упомянуть те, которые я пропустил, а именно игровые. В предыдущих итерациях моих систем из Pi + GPU я смог запустить в Steam и Proton игры Windows на Arm при помощи box64.

На этот раз в Pi OS 13 (Debian Trixie) у меня возникли проблемы с установкой Steam и в FeX, и в box64, поэтому я временно поставил на паузу эти бенчмарки. Я буду подробнее тестировать игры на Arm для видео в следующем году, в связи с разработкой Steam Frame.

Сегодня мы сосредоточимся на сырой мощи GPU.

И у меня есть три теста для нагрузочной проверки каждой из систем: Jellyfin, GravityMark и LLM.

Результаты бенчмарков Jellyfin

Начнём с самого практичного: использования Pi в качестве сервера транскодинга медиа.

Так как кодировщик Nvidia более совершенный, я сначала протестировал его. Даже более старой бюджетной карты было бы достаточно для одного-двух потоков, но у меня имелась 4070 Ti, так что я протестировал её.

В encoder-benchmark PC побеждает Pi с разгромным счётом:

Изучив nvtop, я нашёл виновника: медленный ввод-вывод Raspberry Pi.

В Encoder Benchmark используется два сырых видеопотока, которые довольно велики (например, более 10 ГБ для файла разрешением 4K). Из-за этого все данные приходится загружать с диска, затем копировать их по шине PCIe в GPU, после чего GPU выводит поток сжатого видео, который записывается обратно на диск.

На Pi шина PCIe максимум выдавала примерно 850 МБ/с, а поскольку у неё есть только одна линия и в качестве загрузочного диска я использовал USB 3.0 SSD, в среднем получалось всего до 300 МБ/с.

PC мог скачивать данные с SSD PCIe Gen 4 x4 со скоростью 2 ГБ/с.

С точки зрения сырой производительности PC однозначно вышел победителем.

Но из-за того, как работает Jellyfin, по крайней мере, для моей собственной библиотеки медиа, где хранятся файлы с лёгким сжатием H.264 и H.265, транскодингу не требуется такая большая пропускная способность.

Я установил Jellyfin и выбрал аппаратное кодирование NVENC. Всё заработало без проблем.

При кодировании фильма «Тихушники» в 1080p не возникало никаких задержек при перескакивании между кадрами. Можно было менять битрейты для имитации воспроизведения через мой домашний VPN при просмотре «В поисках галактики», и у Jellyfin не возникало никаких проблем. Файл «Аполлон-11» в разрешении 4K и формате H.265 в этой системе тоже идеально гладко работал при всех битрейтах.

Даже когда одновременно выполнялись два транскодинга, например, как на скриншоте с «Дюной» в 4K и «Тихушниками» в 1080p, всё работало так же идеально. Похоже, на этом этапе движок декодирования работал по максимуму, но никаких торможений это не вызывало.

PC с Intel выигрывает в сырой пропускной способности, что отлично, если вы собираете полнофункциональный сервер транскодинга, но Pi вполне хватает для большинства других сценариев применения транскодинга (например, OBS, Plex или Jellyfin).

Карты AMD не так хороши в транскодинге, но достаточно адекватны. Транскодинг работал на протестированном мной AI Pro, но возникали некоторые проблемы со стабильностью.

Результаты бенчмарков GravityMark

Мне хотелось посмотреть, как покажет себя сырой 3D-рендеринг, поэтому я выполнил бенчмарк GravityMark; на этот раз только на картах AMD, потому что пока не нашёл дисплея для запуска драйвера Nvidia на Pi.

Неудивительно, что PC с Intel был быстрее... но лишь ненамного.

Весь рендеринг выполняется на стороне GPU, и он практически не зависит от CPU или линии PCIe Raspberry Pi, поэтому может выполняться достаточно быстро.

Что действительно удивило меня, так это ситуация, возникшая, когда я прогнал тесты повторно на более старой карте AMD RX 460.

В компьютерных годах это древний GPU, но я думаю, что это помогает Pi. RX 460 работает на PCIe Gen 3, то есть именно с той скоростью, которую обеспечивает Pi, и Pi на самом деле обошла PC. Но по-настоящему потрясли меня результаты на ватт.

Этот бенчмарк замеряет общую экономичность системы, и хотя сегодня Intel не радует своей экономичностью, Pi тоже нельзя назвать лучшим на данный момент Arm.

Я получил результаты бенчмарков для Nvidia 3060, 3080 Ti и A4000, но только для PC. Мне пока всё ещё не удалось найти десктопное окружение или дисплейный вывод, работающий на Pi.

Результаты бенчмарков ИИ

AMD Radeon AI Pro R9700 имеет 32 ГБ VRAM, поэтому должен идеально подходить для большого спектра LLM вплоть до модели Qwen3 с 30 миллиардами параметров, занимающей до 20 ГБ VRAM.

Вот результаты сравнения Pi и PC:

Ой. Не это я ожидал увидеть.

Это меня немного расстроило, поэтому я вернулся к моему верному RX 460:

Это больше похоже на то, чего я ожидал. Возможно, нехватка производительности R9700 связана со странностями драйверов или с отсутствием большого BAR?

Не могу винить инженеров AMD в том, что они не протестировали свои GPU для ИИ на Raspberry Pi.

Это заставило меня задаться вопросом, а не лучше ли будет Nvidia, ведь она годами оптимизировала свои драйверы для Arm.

Вот результаты RTX 3060 на 12 ГБ: это популярная карта для дешёвого домашнего инференса, потому что её объёма VRAM как раз достаточно для полезной работы:

Pi отлично себя показывает. Похоже, некоторые модели имеют чуть лучшую производительность на PC, например tinyllama и llama 3.2 3B, но в случае моделей среднего размера Pi наступает на пятки. В Llama 2 13B Pi даже обогнал PC.

По-настоящему меня удивил следующий график:

Он измеряет экономичность каждой системы. С учётом блока питания, CPU, ОЗУ, GPU и всего остального, Pi на самом деле работает с токенами гораздо эффективнее, чем PC, и близка при этом к его производительности.

Хотя ладно, это ведь просто 3060. Этой карте уже пять лет. Возможно, с более новыми и мощными картами показатели будут не такими хорошими?

Я прогнал свой ИИ-бенчмарк на всех картах Nvidia, которые смог достать, включая RTX 3080 Ti, RTX 4070 Ti, RTX A4000 и RTX 4090. Можете посмотреть видео, чтобы увидеть все результаты, но я перейду сразу к концу, показав на Pi производительность RTX 4090 (это самый быстрый GPU, который у меня сейчас есть):

Размер графической карты по сравнению с Pi выглядит комично, по сравнению с ней кажутся маленькими даже многие сборки PC, в которые её можно установить!

Похоже, tinyllama полностью уничтожает здесь Pi. Но, как ни удивительно, с большинством моделей Pi проявляет себя неплохо — Qwen3 30B на Pi медленнее меньше, чем на 5%.

А какой будет экономичность с этой картой, которая сама по себе съедает сотни ватт?

Я думал, что поскольку остальная часть системы будет потреблять меньший процент питания, PC проявит себя лучше; на самом деле, для некоторых моделей так и получилось. Но Pi всё равно слегка обгоняет PC в большинстве этих тестов (для крупных моделей).

И это... странно.

Честно говоря, я этого не ожидал. Мне казалось, что Pi будет повержена; ну, или чудом одержит одну-две победы.

Здесь есть одна тонкость: я использую Vulkan-бэкенд llama.cpp, чтобы результаты не зависели от производителя. CUDA могла бы немного изменить абсолютные значения, но ненамного, судя по тестированию CUDA на RTX 2080 Ti; к тому же, как ни удивительно, CUDA хорошо работает на Pi.

А если читающие этот пост участники r/LocalLLaMA уже готовы оставлять комментарии о скорости обработки и контексте, то выше есть ссылки на issue GitHub со всеми тестовыми данными, так что посмотрите эти issue, прежде чем писать комментарии.

Сдвоенные GPU

Пока мы проводили тестирование только на одном GPU. А что, если попробовать два?

Я подключил объединительную плату Dolphin PCIe с Dolphin MXH932 PCIe HBA к Pi CM5 через адаптер M.2 - SFF-8643 и кабель SFF-8643 - SFF-8644, идущий от Pi к карте Dolphin.

Прежде, чем запускать LLM, я хотел проверить, смогу ли я обеспечить использование общей памяти между двумя картами. У PCI Express есть функция, позволяющая устройствам напрямую общаться друг с другом вместо задействования пути «север-юг» через CPU. Благодаря этому мы избавимся от узкого места, которое представляет собой Gen 3 x1 в Pi, обеспечив картам полную связь Gen 4 x16 с гораздо большей пропускной способностью.

Чтобы это заработало, нужно отключить ACS (Access Control Service). Очевидно, Dolphin уже сделала это за нас на своей карте коммутатора.

mpsparrow тестировал четыре одинаковых карты Nvidia RTX A5000, но у меня есть лишь разные модели. Похоже, драйвер Nvidia не поддерживает такой же пулинг VRAM при наличии разных карт, например, моих 4070 и A4000 или моих A4000 и A400.

Но это нормально, у меня есть ещё тесты, которые можно провести с llama.cpp и несколькими GPU, задействующие путь «север-юг» через CPU.

Выше показана производительность 4070 и A4000 по сравнению с запуском тех же моделей непосредственно на A4000.

Подозреваю, что из-за дополнительного трафика между Pi и картами присутствует куча маленьких задержек, когда llama.cpp передаёт данные через два GPU. Это не улучшает производительность, но такая схема действительно позволяет масштабироваться до более крупных моделей, не умещающихся в один GPU.

Например, Qwen 3 30B занимает примерно 18 ГБ, и этого слишком много для любой из этих карт по отдельности. Было бы быстрее и эффективнее использовать GPU с объёмом VRAM, достаточным для всей модели. Но если у вас уже есть две графические карты и вы хотите, чтобы они работали вместе, то это как минимум возможно.

Также я провёл две самые большие карты AMD, которые у меня были, RX 7900 XT (20 ГБ) и Radeon AI Pro R9700 (32 ГБ), что суммарно дало мне аж целых 52 ГБ VRAM. Но, возможно, из-за драйверов AMD здесь я снова не смог завершить прогоны некоторых моделей, а если прогоны всё-таки заканчивались, то они были не очень быстрыми:

В заключение моих тестов сдвоенных GPU я также выполнил все проверки на PC Intel; не особо удивительно, что они оказались быстрее:

Но как минимум с Qwen3 30B Pi снова была на уровне.

Вывод: если у вас есть несколько одинаковых карт и если вы даже пробуете другие инструменты наподобие vLLM (который я не смог установить на Pi), то у вас могут получиться более высокие результаты, чем у меня.

Но главный вывод по-прежнему актуален: увеличение количества GPU может дать вам больший объём, но они определённо будут медленнее одного большого GPU и менее экономичны.

Заключение

Так кто же в конечном итоге оказался победителем?

Разумеется, PC, если вам важна сырая производительность и простота настройки. Но для очень узкой ниши пользователей Pi лучше, когда система не работает постоянно при полной загрузке, а задачи почти полностью выполняются на GPU. Энергопотребление машины с Pi в режиме простоя всегда на 20-30 Вт ниже. А другие Arm SBC с SoC Rockchip или Qualcomm даже более экономичны и часто имеют более высокую пропускную способность ввода-вывода.

В конечном итоге, я провёл этот эксперимент не потому, что он разумен, а потому что мне интересно было узнать об ограничениях Pi, вычислениях на GPU и PCI Express. И этой цели я достиг.

1. При расчёте цены можно сэкономить на загрузочном накопителе. Если вы готовы отказаться от половины производительности чтения/записи, то можно купить быструю карту microSD, но я не рекомендую этого делать.

2. В апреле 2025 года я заплатил за 64 ГБ памяти DDR5 $209. Мне повезло, что я купил этот набор тогда, потому что в конце 2025 года тот же набор стоит больше $600. На настоящий момент тестовый PC невозможно было бы собрать по той же цене.