Große GPUs brauchen keinen großen PC

 (jeffgeerling.com)
9 Punkte von GN⁺ 2025-12-21 | 1 Kommentare | Auf WhatsApp teilen
  • Experimente auf dem Raspberry Pi 5, bei denen AMD-, Intel- und Nvidia-GPUs betrieben und mit einem Desktop-PC verglichen wurden, zeigen in vielen Fällen Leistungsverluste von nur 2 bis 5 %
  • Getestet wurden vier Bereiche: Jellyfin-Transkodierung, GravityMark-Rendering, LLM/AI-Inferenz und Multi-GPU-Konfigurationen, um Effizienz und Preis-Leistungs-Verhältnis zu messen
  • In einem Aufbau mit vier Nvidia RTX A5000 zeigte sich ein Leistungsunterschied von unter 2 % gegenüber einem Intel-Server; eine zentrale Rolle spielte dabei die gemeinsame Speichernutzung zwischen den GPUs über einen PCIe-Switch
  • Die Gesamtkosten eines Raspberry-Pi-eGPU-Systems liegen bei etwa $350–400, ein PC dagegen bei $1500–2000; auch der Stromverbrauch ist beim Pi deutlich geringer (im Leerlauf 4–5 W vs. 30 W)
  • Das belegt das Potenzial des Raspberry Pi als stromsparende und kostengünstige alternative Plattform, um große GPUs effizient zu nutzen

Überblick über das Experiment

  • Trotz der Begrenzung des Raspberry Pi 5 auf PCIe Gen 3 x1 Bandbreite (8 GT/s) wurde die Nutzbarkeit von GPUs überprüft
    • Als Vergleich diente ein moderner Desktop-PC (PCIe Gen 5 x16, 512 GT/s)
  • Die Tests umfassten Medientranskodierung (Jellyfin), GPU-Rendering (GravityMark), LLM/AI-Leistung und Multi-GPU-Konfigurationen
  • Mithilfe eines externen PCIe-Gen-4-Switches und eines 3-Slot-Backplanes von Dolphin ICS wurde ein Versuch mit zwei gleichzeitig betriebenen GPUs durchgeführt

Ein Raspberry Pi mit vier angeschlossenen GPUs

  • Der GitHub-Nutzer mpsparrow verband vier Nvidia RTX A5000 GPUs mit einem einzelnen Pi
    • Beim Ausführen des Llama 3 70B-Modells lag der Leistungsunterschied gegenüber einem Intel-Server bei unter 2 % (11.83 vs. 12 tokens/sec)
  • Über einen PCIe-Switch war gemeinsame Speichernutzung zwischen den GPUs möglich, wodurch die Bandbreitenbeschränkung des Pi umgangen wurde
  • Auch mit nur einer GPU wurde bei manchen Aufgaben eine dem Desktop vergleichbare oder sogar bessere Leistung festgestellt

Vergleich von Kosten und Effizienz

  • Raspberry-Pi-eGPU-Konfiguration: etwa $350–400, Intel-PC-Konfiguration: etwa $1500–2000
  • Leistungsaufnahme im Leerlauf: Pi 4–5 W, PC 30 W
  • Unter gleichen Bedingungen ohne GPU ist der Pi sowohl bei Kosten als auch bei Energieeffizienz im Vorteil

Jellyfin-Transkodierungs-Benchmark

  • Mit einer Nvidia 4070 Ti war der PC bei der Rohdurchsatzrate (2 GB/s) überlegen
    • Der Pi erreichte etwa PCIe 850 MB/s, USB-SSD 300 MB/s
  • Bei H.264/H.265-Medienstreaming konnte der Pi jedoch ebenfalls 1080p- und 4K-Transkodierung problemlos bewältigen
    • NVENC-Hardware-Encoding wird unterstützt, auch zwei gleichzeitige Transkodierungen liefen stabil
  • Bei AMD-GPUs traten teilweise Probleme bei der Stabilität der Transkodierung auf

GravityMark-Rendering-Test

  • Getestet wurde vor allem mit AMD-GPUs; der PC war etwas schneller, der Unterschied war jedoch gering
  • Mit einer RX 460 erzielte der Pi eine höhere Effizienz (Leistung/W) als der PC
  • Bei älteren GPUs mit derselben PCIe-Gen-3-Bandbreite hatte der Pi einen relativen Vorteil

Vergleich der AI- und LLM-Leistung

  • Beim Test der AMD Radeon AI Pro R9700 (32 GB VRAM) lag die Leistung unter den Erwartungen; möglich sind Probleme mit Treibern oder den BAR-Einstellungen
  • Mit einer Nvidia RTX 3060 (12 GB) war der Pi beim Llama 2 13B-Modell schneller als der PC
  • Die Effizienzmessung zeigte, dass der Pi beim Durchsatz pro Watt besser abschnitt als der PC
  • Auch beim Test mit einer RTX 4090 lag der Leistungsunterschied bei großen Modellen (Qwen3 30B) innerhalb von 5 %, wobei der Pi in vielen Fällen effizienter war
  • Sowohl das CUDA-Backend als auch das Vulkan-Backend funktionierten auf dem Pi normal

Experiment mit Dual-GPU-Konfiguration

  • Verwendet wurden ein Dolphin PCIe Interconnect Board und ein MXH932 HBA
  • Durch Deaktivierung von ACS wurde direkter Speicherzugriff zwischen den GPUs möglich
  • Bei Kombinationen unterschiedlicher GPU-Modelle (4070, A4000) wurde kein VRAM-Pooling unterstützt, wodurch Leistungssteigerungen begrenzt blieben
  • Mit identischen GPUs konnten größere Modelle (Qwen3 30B usw.) ausgeführt werden
  • Die Kombination AMD RX 7900 XT + R9700 scheiterte bei einigen Modellen an Treiberproblemen
  • Der Intel-PC war insgesamt schneller, doch auch der Pi hielt bei großen Modellen eine ähnliche Leistung

Fazit

  • Bei absoluter Leistung und Komfort ist der PC überlegen
  • Bei GPU-zentrierten Workloads und in stromsparenden, kostengünstigen Umgebungen ist der Raspberry Pi jedoch eine praktikable Alternative
  • 20–30 W weniger Leerlaufverbrauch, und Rockchip- oder Qualcomm-basierte SBCs bieten noch höhere Effizienz und I/O-Bandbreite
  • Ziel des Experiments war es, die Grenzen des Pi und die Struktur von GPU-Computing zu verstehen; dabei wurde auch das Potenzial kleiner Systeme sichtbar

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-12-21
Hacker-News-Kommentare

  • Um LLMs lokal auszuführen, ist am Ende die GPU der entscheidende Faktor
    Deshalb überlege ich, was der günstigste Computer ist, den man danebenstellen kann
    Ich habe weder die Fähigkeit, Probleme wie BAR zu verstehen oder zu beheben, also nutze ich einfach eine günstige x86-Box mit einer halbwegs passenden GPU
    Trotzdem bekomme ich den Gedanken nicht aus dem Kopf, dass es noch einen effizienteren Weg geben müsste

    • Ich betreibe eine Crowdsourcing-Seite, die optimale Hardware-Kombinationen für lokale LLMs sammelt
      Die Seite ist inferbench.com, der Quellcode liegt im GitHub-Repository
    • Noch ist es schwierig, mit einem einzelnen PCIe-Gerät nennenswerte Leistung zu erzielen
      Meiner Meinung nach braucht die GPU mindestens 128GB RAM
      Die CPU-Leistung kann gering sein, aber sie muss viele PCIe-Lanes unterstützen, deshalb eignet sich eine einfache Server-CPU wie AMD EPYC
    • Hast du nicht darüber nachgedacht, Apple Silicon wie den M4 Max oder M3 Ultra zu verwenden?
      Für mittelgroße LLMs passt das ziemlich gut
    • Das System, das du beschreibst, ist im Grunde genau die Rolle von DGX Spark

  • Ich verstehe nicht, warum dich der Multi-GPU-Teil überrascht
    Die meisten LLM-Frameworks, etwa llama.cpp, teilen das Modell auf Layer-Ebene auf, wodurch sequentielle Abhängigkeiten entstehen und mit mehreren GPUs keine echte Parallelisierung möglich ist
    Manche GPUs sind bei der Prompt-Verarbeitung schneller, andere bei der Token-Generierung, daher bringt eine Mischung aus Radeon und NVIDIA manchmal etwas
    Der echte Leistungsschub ist bei Backends wie dem tensor parallel-Modus möglich
    Dabei wird das neuronale Netz entlang der Datenflussrichtung aufgeteilt, weshalb eine gute Verbindung zwischen den GPUs nötig ist, etwa PCIe x16, NVlink oder Infinity Fabric
    Fehlt das, wirkt die GPU-Auslastung mitunter sehr ungleichmäßig
    Interessant ist, LLMs so aufzuteilen, dass mehrere Aufgaben parallel laufen können, zum Beispiel in einer Agentenstruktur mit getrennten Rollen wie „Manager“ und „Ingenieur“

    • Genau, das ist im Kern das Konzept eines Agentensystems
      Das Manager-Modell erstellt die Prompts, die untergeordneten Modelle arbeiten parallel und liefern anschließend ihre Ergebnisse zurück
    • Die Aussage, dass die Inter-Layer-Übertragungsgröße im Kilobyte-Bereich liege, ist übertrieben
      Tatsächlich wächst sie je nach Sequenzlänge in den Megabyte-Bereich
      Wenn zum Beispiel Qwen3 30B einen hidden state von 5120 hat, sind das bei 8-Bit-Quantisierung 5120 Byte pro Token
      Schon bei mehr als 200 Tokens landet man im MB-Bereich
      Selbst die Bandbreite von PCIe x1, also etwa 2GB/s, reicht dafür aus, aber Latenz könnte das größere Problem sein

  • Ich freue mich wirklich, dass jemand solche Experimente macht
    Ich habe auch schon eine eGPU an ein Ersatz-Laptop angeschlossen und dabei gedacht: „Müsste das nicht auch mit einem Raspberry Pi gehen?“

  • Ich hätte mir gewünscht, dass auch die Gaming-Leistung betrachtet wird
    Allerdings ist es schwer, AAA-Spiele mit ARM-Unterstützung zu finden, und es wäre nicht fair, mit FEX eine x86-Emulation zu erzwingen

    • Entscheidend wäre wohl, ein Spiel ohne CPU-Flaschenhals zu finden

  • Bei constrained decoding (auf Basis eines JSON-Schemas) steigt die CPU-Auslastung auf 100%
    Dasselbe habe ich auch bei meiner vLLM-Instanz gesehen

  • PCIe 3.0 liefert pro Lane ungefähr 1GB/s, also Geschwindigkeiten auf dem Niveau von 10Gb-Ethernet
    Vielleicht kommt irgendwann der Tag, an dem GPUs ohne Host-System eigenständig arbeiten
    Es gab schon Beispiele wie die Radeon Pro SSG, bei denen eine SSD direkt an die GPU angebunden war,
    und ein kleiner RISC-V-Chip oder ein Controller auf Raspberry-Pi-Niveau könnte dafür schon ausreichen
    Verwandter Artikel: TechPowerUp
    Eine Architektur, bei der GPUs direkt an einen Netzwerkswitch angebunden sind und über 400Gbe oder CXL-basierte Kommunikation laufen, erscheint realistisch
    Außerdem könnten Flash-Technologien der nächsten Generation wie High Bandwidth Flash irgendwann DRAM ersetzen
    Verwandte Artikel: ServeTheHome, Tom’s Hardware

  • Diese Datenpunkte bringen mich dazu, mein Haupt-PC-Setup noch einmal zu überdenken
    Ein 300-Dollar-Mini-PC, der unter 20W läuft, scheint völlig auszureichen
    Für Webbrowsing, Videos und leichtes Gaming ist das mehr als genug,
    und für schwere Aufgaben kann man sich per Fernzugriff auf eine Workstation schalten

    • Ich experimentiere gerade mit einer Kombination aus Proxmox-VM + eGPU
      Schon mit 1 vCPU und 4GB RAM reicht es für Surfen und Hobbyprojekte aus
      Die Hardwarehersteller scheinen in ihrer Werbung übertrieben zu haben, wenn sie behaupten, Profis bräuchten zwingend Hochleistungs-Laptops
    • Als ich von einem 8-Kern-Ryzen-Mini-PC auf einen 8-Kern-Desktop gewechselt habe, liefen Unit-Tests deutlich schneller
      Der Unterschied bei der TDP macht leistungsmäßig viel aus
    • Ich nutze ebenfalls einen Beelink-Mini-PC, dadurch ist der Schreibtisch aufgeräumter,
      und wenn leistungsstarke Geräte in einem schallgedämmten Raum stehen, ist das sehr angenehm

  • Ich frage mich, warum die PCI/CPU-Struktur an sich überhaupt nötig ist
    Wie bei Apple und NVIDIA CPU und MPP im selben Package unterzubringen, scheint der richtige Weg zu sein

    • Dieser Ansatz ist bei latenzkritischen Aufgaben im Vorteil,
      aber für große Rechenlasten wie AI oder HPC macht das womöglich keinen großen Unterschied