DDR5-Bandbreite begrenzt LLM-Inferenz auf APUs: Benchmarks zeigen Engpässe

Ein kürzlich durchgeführter Benchmark auf einem AMD-Ryzen-APU-System enthüllte ein zentrales Problem für KI-Agenten: DDR5-Bandbreite wird zum Flaschenhals, wenn mehrere Sprachmodelle gleichzeitig Inferenz durchführen sollen. Die Tests auf einem Minisforum UM790Pro mit integrierter Radeon 780M-Grafikeinheit zeigen, dass bereits die Kombination aus einem 35 Milliarden Parameter großen Modell und einem kleineren 1,5 Milliarden Parameter Modell zu spürbaren Leistungseinbußen führt.

Die Ergebnisse widerlegen die Annahme, dass moderne APUs dank Unified Memory Architecture effizient mehrere KI-Modelle parallel betreiben können. Stattdessen offenbart sich ein fundamentales Hardware-Limit, das Entwickler bei der Planung verteilter LLM-Architekturen berücksichtigen müssen.

Warum ein 35B-Modell plötzlich wie ein 4B-Modell läuft

Die Initialzündung für die Tests lieferte eine überraschende Erkenntnis über das Qwen3.6-35B-Modell: Obwohl es über 36 Milliarden Parameter verfügt, aktiviert es pro generiertem Token nur acht von 256 Experten. Diese Mixture-of-Experts-Architektur kombiniert mit State-Space-Modellen (SSM) reduziert den Rechenaufwand pro Token auf etwa 4-5 Milliarden Parameter – ein Niveau, das mit herkömmlichen kleinen Modellen vergleichbar ist.

Diese Einsicht führte zu der Frage, ob ein zusätzliches leichtes Modell für Klassifizierungs- oder Tool-Aufrufe parallel betrieben werden könnte, ohne die Performance des Hauptmodells zu beeinträchtigen. Die Antwort der Benchmarks fiel jedoch vernichtend aus.

Testumgebung: AMD APU als gemeinsamer Engpass

Das getestete System basiert auf einem AMD Ryzen 9 7940HS mit integrierter Radeon 780M-Grafikeinheit (12 RDNA-3-Compute-Units). Die Hardwarekonfiguration zeigt, warum die Ergebnisse so problematisch sind:

• Einziger DDR5-Speichercontroller mit ~80 GB/s Bandbreite
• 96 GB DDR5-5600-RAM, davon 48 GB als GPU-accessible Speicher (GTT) verfügbar
• Kein separater GDDR6-Bus – alle Komponenten teilen sich denselben Speicher

Zum Vergleich: Eine diskrete NVIDIA-Grafikkarte würde für GPU- und CPU-Berechnungen separate Speicherbusse nutzen. Auf der APU hingegen müssen sich CPU-Kerne, iGPU und Systemoperationen die verfügbare Bandbreite teilen.

Benchmark-Ergebnisse: Performance-Einbrüche bis zu 53%

Die Tests umfassten vier Modelle mit unterschiedlichen Parametern, die sowohl einzeln als auch in Kombination ausgeführt wurden. Die Messungen erfolgten über ollama ps und direkte API-Abfragen mit festgelegten Prompts. Die Ergebnisse zeigen ein klares Muster:

Einzelausführung als Baseline

| Modell | Parameter | GPU (Tokens/s) | CPU (Tokens/s) | |--------|-----------|----------------|-----------------| | Qwen3.6:35b | 36B (MoE) | 17,8 | — | | gemma4-e2b-abliterated | 4,6B | 42,9 | 28,7 | | qwen3:4b-instruct | 4B | 26,2 | 19,6 | | qwen2.5:1,5b | 1,5B | — | 53,4 |

Dual-Modell-Ausführung: Deutliche Performance-Verluste

Die Kombination aus einem großen GPU-Modell und einem kleineren CPU-Modell führte zu dramatischen Einbußen:

Szenario 1: Beide Modelle auf der GPU

• Qwen3.6:35b: 17,8 → 13,1 Tokens/s (-26%)
• gemma4-e2b: 42,9 → 25,3 Tokens/s (-41%)

Szenario 2: Großes Modell GPU + kleines Modell CPU

• Qwen3.6:35b: 17,8 → 14,9 Tokens/s (-16%)
• qwen2.5:1,5b: 53,4 → 26,2 Tokens/s (-51%)

Szenario 3: Großes Modell GPU + 4B-Modell CPU mit vollem Kontext

• Qwen3.6:35b: 17,8 → 11,6 Tokens/s (-35%)
• qwen3:4b-instruct: 19,6 → 11,1 Tokens/s (-43%)

Der schlechteste Fall trat bei der Kombination aus dem 35B-Modell auf der GPU und einem 4B-Modell mit 256K Kontext auf. Die KV-Caches des kleinen Modells beanspruchten allein 24,2 GB RAM, während das große Modell weitere 32 GB GPU-Speicher benötigte. Das System war damit an der Grenze seiner DDR5-Bandbreite angelangt.

Der technische Hintergrund: Warum Shared Memory scheitert

Der fundamentale Unterschied zwischen APUs und diskreten GPUs liegt im Speicherzugriffsmodell:

• Diskrete GPU: Separater GDDR6-Speicher (300+ GB/s) + DDR5 für die CPU
• APU: Einziger DDR5-Speichercontroller für CPU und iGPU

LLM-Inferenz ist primär speichergebunden. Jedes generierte Token erfordert das Laden von Modellgewichten in die Compute-Einheiten. Selbst bei MoE-Modellen müssen die aktivierten Expertengewichte bei jedem Schritt von DDR5 gelesen werden. Wenn ein zweites Modell gleichzeitig dieselben Ressourcen nutzt, entsteht ein Bandbreiten-Wettlauf.

Konsequenzen für KI-Agenten-Architekturen

Die Testergebnisse haben direkte Auswirkungen auf die Planung verteilter KI-Systeme:

• Agenten-Frameworks, die auf parallele Modellausführung setzen, stoßen auf APUs an fundamentale Hardware-Grenzen
• Memory-Mapped-Dateien und KV-Caches großer Kontextmodelle verschärfen den Bandbreitenmangel
• Hybridansätze (GPU für große Modelle + CPU für kleine Aufgaben) führen zu inakzeptablen Performance-Verlusten

Die ursprüngliche Idee eines Planer-Executor-Agenten – mit einem 35B-Modell für strategische Entscheidungen und einem 4B-Modell für Tool-Aufrufe – scheitert auf APUs an der gemeinsamen Speichernutzung. Entwickler müssen entweder auf diskrete GPUs ausweichen oder alternative Architekturen wählen, die den Speicherbedarf minimieren.

Ausblick: Lösungsansätze und zukünftige Hardware

Die Benchmarks zeigen klar, dass APUs für Multi-LLM-Szenarien aktuell ungeeignet sind, sofern nicht extrem kleine Modelle eingesetzt werden. Drei mögliche Lösungswege zeichnen sich ab:

1. Diskrete GPUs mit separatem GDDR6-Speicher nutzen
2. Speichereffiziente Modelle (z. B. quantisierte Versionen) einsetzen, um den Bandbreitenbedarf zu reduzieren
3. Batch-Verarbeitung implementieren, um die Speichernutzung zu optimieren

Hardware-Hersteller arbeiten bereits an Lösungen wie HBM (High Bandwidth Memory) für APUs, die höhere Speicherbandbreiten ermöglichen könnten. Bis dahin bleiben diskrete Grafikkarten die zuverlässigere Wahl für anspruchsvolle LLM-Anwendungen auf Consumer-Hardware.

Für Entwickler bedeutet dies: Bei der Planung von KI-Agenten-Architekturen muss die Hardware-Infrastruktur frühzeitig berücksichtigt werden – sonst drohen unerwartete Performance-Probleme, die sich nicht durch Software-Optimierungen beheben lassen.