💬 NLP

Hardware Co-Design Scaling Laws via Roofline Modelling for On-Device LLMs

Diese Arbeit stellt ein neues Framework für das Hardware-Software-Co-Design vor, das durch die Kombination von Scaling Laws für die Modellgenauigkeit und Roofline-Modellierung für die Latenz eine effiziente und präzise Auswahl optimaler LLM-Architekturen für ressourcenbeschränkte On-Device-Anwendungen ermöglicht.

Ursprüngliche Autoren: Luoyang Sun, Jiwen Jiang, Yifeng Ding, Fengfa Li, Yan Song, Haifeng Zhang, Jian Ying, Lei Ren, Kun Zhan, Wei Chen, Yan Xie, Cheng Deng

Veröffentlicht 2026-02-12

📖 3 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Luoyang Sun, Jiwen Jiang, Yifeng Ding, Fengfa Li, Yan Song, Haifeng Zhang, Jian Ying, Lei Ren, Kun Zhan, Wei Chen, Yan Xie, Cheng Deng

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stell dir vor, du möchtest ein extrem leistungsfähiges Auto bauen – aber es darf nicht nur schnell sein, sondern muss auch in eine winzige Garage passen, mit einem winzigen Tank auskommen und darf beim Fahren nicht plötzlich stehen bleiben, weil der Sprit ausgeht.

Genau das ist das Problem der Forscher in diesem Papier. Sie versuchen nicht, das „schnellste“ KI-Modell der Welt zu bauen (das wäre ein riesiger Supercomputer in der Cloud), sondern das perfekte KI-Modell für dein Smartphone, dein Auto oder einen kleinen Roboter.

Hier ist die Erklärung der wissenschaftlichen Arbeit in einfachen Bildern:

1. Das Problem: Das „Dilemma des Giganten“

Aktuelle Sprachmodelle (wie ChatGPT) sind wie riesige, schwerfällige Ozeandampfer. Sie sind unglaublich intelligent, aber sie brauchen riesige Mengen an Energie und Platz. Wenn du versuchst, einen Ozeandampfer in einen kleinen Kanu-See (dein Smartphone) zu schicken, passiert eines von zwei Dingen:

Entweder das Kanu sinkt unter der Last (zu viel Speicherbedarf).
Oder das Kanu bewegt sich nur im Schneckentempo (zu hohe Verzögerung/Latency).

Bisher haben Ingenieure oft erst das Modell gebaut und dann versucht, es irgendwie „passend zu machen“. Das ist so, als würde man erst ein Haus bauen und dann versuchen, die Fenster nachträglich in die Wand zu hämmern.

2. Die Lösung: Das „Architekten-Gesetz“ (Hardware-Software Co-Design)

Die Forscher haben etwas Revolutionäres gemacht: Sie haben ein mathematisches Gesetz entwickelt, das Modell-Design und Hardware-Grenzen gleichzeitig betrachtet.

Stell dir vor, du bist ein Architekt. Anstatt nur zu fragen: „Wie schön kann das Haus sein?“, fragst du gleichzeitig: „Wie viel Sand habe ich auf der Baustelle?“ und „Wie schnell können die Lastwagen die Steine liefern?“.

Sie nutzen dafür das sogenannte „Roofline-Modell“. Stell dir das wie ein Dach vor:

Die Fläche des Daches ist die maximale Rechenpower deines Chips.
Die Steilheit des Daches ist die Geschwindigkeit, mit der dein Speicher Daten liefern kann.
Das KI-Modell muss sich genau unter dieses Dach schmiegen, um nicht „aus der Kurve zu fliegen“.

3. Der Trick mit den „Spezialisten“ (MoE - Mixture of Experts)

Ein Kernpunkt des Papers ist die Nutzung von sogenannten „Experten-Modellen“ (MoE).
Stell dir eine riesige Bibliothek vor. Ein normales KI-Modell ist wie ein Bibliothekar, der jedes einzelne Buch der Welt im Kopf behalten muss, um eine Frage zu beantworten. Das ist extrem anstrengend und langsam.

Das neue Design nutzt „Experten“: Wenn du eine Frage zu Mathe stellst, wird nur der „Mathe-Experte“ geweckt. Der „Geschichts-Experte“ bleibt schlafen. Das spart unglaublich viel Energie und Zeit, während das Modell trotzdem so schlau bleibt, als hätte es das gesamte Wissen der Bibliothek.

4. Das Ergebnis: Das „Goldene Gleichgewicht“ (Pareto-Frontier)

Die Forscher haben nicht nur ein Modell gefunden, sondern eine Art „Menü der Perfektion“ (die Pareto-Frontier).

Wenn du sagst: „Ich brauche eine KI für mein Auto, die extrem schnell reagiert (wenig Verzögerung)“, zeigt dir das System das perfekte Rezept: „Nimm ein eher flaches, breites Modell mit vielen Experten.“

Wenn du sagst: „Ich brauche eine KI für mein Handy, die sehr klug ist, aber der Akku darf nicht leer werden“, sagt das System: „Nimm ein tieferes Modell, aber mit weniger Experten.“

Zusammenfassung: Warum ist das wichtig?

Früher hat die Auswahl des richtigen KI-Modells für ein Gerät Monate gedauert. Mit dieser neuen Methode dauert es nur noch wenige Tage.

Das Ergebnis: In ihrem Test war ihr selbst gebautes Modell bei gleicher Geschwindigkeit fast 20 % klüger als die aktuellen Standard-Modelle (wie Qwen). Das bedeutet: In Zukunft werden deine Geräte viel smarter reagieren, ohne dass sie heiß werden oder der Akku sofort leer ist.

Technische Zusammenfassung: Hardware-Software-Co-Design für On-Device LLMs

1. Problemstellung

Die Bereitstellung von Large Language Models (LLMs) auf Edge-Geräten (z. B. autonomen Fahrzeugen, Robotern oder Smartphones) stellt eine enorme Herausforderung dar. Im Gegensatz zu Cloud-Umgebungen sind On-Device-Plattformen durch strikte Beschränkungen hinsichtlich Speicherbandbreite, Rechenleistung (FLOPS), Speicherplatz (DRAM) und Latenz begrenzt.

Das Kernproblem ist die Diskrepanz zwischen der Architekturoptimierung und der Hardware-Effizienz:

Rechen- vs. Speicherlimitierung: Transformer-Modelle sind in verschiedenen Phasen unterschiedlich limitiert. Die Prefill-Phase (Verarbeitung des Input-Kontexts) ist oft rechengebunden (compute-bound), während die Decode-Phase (autoregressives Generieren von Token) aufgrund des ständigen Ladens von Gewichten extrem speicherbandbreitengebunden (memory-bandwidth-bound) ist.
Ineffiziente Suche: Traditionelle Methoden zur Suche nach optimalen Architekturen (Neural Architecture Search, NAS) berücksichtigen oft nur die Genauigkeit (Loss) und vernachlässigen die spezifischen Hardware-Latenzen, was zu Modellen führt, die zwar präzise, aber auf dem Zielgerät zu langsam sind.

2. Methodik

Die Autoren schlagen ein neues Framework vor, das Hardware-Software-Co-Design durch die Verknüpfung von zwei mathematischen Modellen ermöglicht:

A. Präzisionsmodellierung via Scaling Laws (Loss Modeling):
Anstatt jedes Modell voll zu trainieren, entwickeln die Autoren ein analytisches Ersatzmodell für den Validierungsverlust ( $\hat{L}$ ). Durch das Training von 170 verschiedenen Architekturen (sowohl dichte Modelle als auch Mixture-of-Experts, MoE) stellen sie eine funktionale Beziehung zwischen den Architektur-Hyperparametern (Tiefe $l$ , Breite $d$ , FFN-Ratio $r$ , MoE-Aktivierungsrate $\rho$ ) und dem Trainingsverlust her.

B. Performance-Modellierung via Roofline-Modellierung (Latency Modeling):
Die Latenz wird nicht durch Messungen, sondern durch ein physikalisches Modell auf Basis des Roofline-Modells vorhergesagt. Dabei wird die Rechenlast (FLOPs) und der Speicherzugriff (Bytes) der einzelnen Operatoren (Attention, FFN, MoE) analysiert. Das Modell berücksichtigt:

Die Rechenkapazität ( $\pi_H$ ) und die Speicherbandbreite ( $\beta_H$ ) der Hardware.
Den Einfluss des KV-Caches auf die Speicherbandbreite während der Decode-Phase.
Die Unterscheidung zwischen Prefill- und Decode-Latenz.

C. Pareto-Optimierung:
Durch die Kombination beider Modelle wird die Architekturwahl als ein bi-objektives Optimierungsproblem formuliert: Minimierung des Verlusts bei gleichzeitiger Einhaltung von Latenz- und Speicherbudgets. Dies ermöglicht die Identifizierung der Pareto-Frontier – der Menge der optimalen Architekturen, bei denen keine Verbesserung der Genauigkeit möglich ist, ohne die Latenz zu verschlechtern.

3. Hauptbeiträge (Key Contributions)

Hardware Co-Design Scaling Law: Das erste Framework, das Scaling Laws für die Genauigkeit direkt mit der Hardware-Latenz (via Roofline) koppelt.
PLAS (Pareto-optimal LLM Architecture Search): Ein effizienter Suchalgorithmus, der die Architekturwahl von Monaten auf wenige Tage reduziert.
Theoretisches Framework: Eine mathematische Herleitung optimaler Parameter (Tiefe, Breite, Sparsity) für verschiedene Hardware-Regime (rechengebunden, speichergebunden oder dual-beschränkt).
Empirische Validierung: Eine groß angelegte Untersuchung von 1.942 Architekturen auf dem NVIDIA Jetson Orin.

4. Ergebnisse und Erkenntnisse

Dominanz von MoE: In On-Device-Szenarien (Batch-Size 1) sind Mixture-of-Experts (MoE) Architekturen fast immer Pareto-optimal. Sie bieten eine höhere Kapazität bei vergleichbarer Rechenlast pro Token.
"Wide-and-Shallow" Präferenz: Im Gegensatz zu Cloud-Modellen bevorzugen On-Device-optimierte Modelle tendenziell breitere und flachere Strukturen (weniger Layer, aber größere Hidden Dimension), da die Breite effizienter zur Verlustreduktion beiträgt, bevor die Latenz zu stark steigt.
Sparsity-Width Scaling Law: Die Autoren beweisen theoretisch und empirisch, dass mit zunehmender Modellbreite die Aktivierungsrate ( $\rho$ ) der Experten sinken sollte (das Modell muss "sparser" werden), um das Speicherlimit optimal zu nutzen.
Überlegenheit gegenüber Standardmodellen: Ein durch das Framework co-designedes Modell erreichte bei gleicher Latenz wie das Qwen2.5-0.5B Modell eine um 19,42 % geringere Perplexity (WikiText-2).
Quantisierung: INT8-Quantisierung verbessert die Effizienz deutlich, aber der Gewinn ist sublinear, da nicht-lineare Operationen (Softmax, LayerNorm) weiterhin in höherer Präzision verbleiben müssen.

5. Bedeutung (Significance)

Die Arbeit ist wegweisend für die Entwicklung von Physical AI (Robotik, autonomes Fahren). Sie bietet Ingenieuren ein Werkzeug, um nicht mehr "auf gut Glück" Architekturen zu wählen, sondern mathematisch fundiert Modelle zu designen, die exakt auf die verfügbare Hardware zugeschnitten sind. Das Framework ermöglicht eine schnelle Iteration und stellt sicher, dass die maximale Intelligenz (niedrigster Loss) innerhalb der harten Echtzeit-Anforderungen von Edge-Systemen realisiert wird.