Hardware-Software Co-design for 3D-DRAM-based LLM Serving Accelerator

Das Papier stellt Helios vor, einen auf Hybrid-Bonding basierenden LLM-Serving-Beschleuniger, der durch eine räumlich bewusste KV-Cache-Allokation und optimierte verteilte Aufmerksamkeitsausführung dynamische Workloads effizienter verarbeitet als bestehende GPU- und NMP-Designs und dabei signifikante Verbesserungen bei Geschwindigkeit und Energieeffizienz erzielt.

Das Wesentliche

Stellen Sie sich vor, Sie betreiben eine riesige, hochmoderne Bibliothek, in der ein künstlicher Intelligenz-Assistent (ein "LLM") Tausende von Büchern gleichzeitig schreibt. Manchmal kommt ein Besucher und fragt nur nach einem kurzen Fakt (eine kurze Anfrage), manchmal möchte jemand einen ganzen Roman schreiben (eine lange Anfrage). Und manchmal kommen plötzlich Tausende von Besuchern auf einmal, und dann wieder nur wenige.

Das Problem mit den aktuellen KI-Systemen ist, dass sie wie eine starre Bibliothek funktionieren: Jeder Mitarbeiter (ein "Prozessor") hat einen festen Regalbereich zugewiesen. Wenn ein Besucher einen kurzen Text braucht, steht ein ganzer Mitarbeiter nur für ein paar Zeilen herum und wartet. Wenn ein Besucher einen riesigen Roman braucht, ist ein Mitarbeiter überlastet, während andere untätig sind. Zudem müssen die Mitarbeiter oft lange Wege laufen, um Informationen aus den Regalen zu holen, was Zeit kostet.

Die Forscher von Helios (eine neue Hardware-Idee) haben eine Lösung gefunden, die diese starre Bibliothek in einen fließenden, dynamischen Organismus verwandelt. Hier ist die Erklärung, wie das funktioniert:

1. Das Grundproblem: Starre Regale vs. fließende Anfragen

In der aktuellen Technik (wie bei Grafikkarten oder speziellen Speicher-Chips) sind die "Mitarbeiter" (Rechenkerne) fest mit bestimmten "Regalen" (Speicherbereichen) verbunden.

• Das Problem: Wenn eine Anfrage sehr lang ist, passt sie vielleicht gar nicht mehr in das zugewiesene Regal. Wenn sie kurz ist, wird das ganze Regal verschwendet. Es entsteht "Platzverschwendung" und Chaos, weil die Mitarbeiter nicht flexibel genug sind, um sich gegenseitig zu helfen.

2. Die Helios-Lösung: Ein Team von Helfern mit einem gemeinsamen Gehirn

Helios nutzt eine Technologie namens Hybrid Bonding. Stellen Sie sich das wie eine 3D-Pyramide vor, bei der die Speicherchips direkt auf die Rechenchips geklebt sind. Das ist wie ein Regal, das direkt an der Hand des Bibliothekars sitzt – keine langen Wege mehr!

Aber das Besondere an Helios ist nicht nur die Nähe, sondern die Flexibilität:

• Der "Puzzle-Ansatz" (Dynamische KV-Cache-Verwaltung):
  Statt einem Mitarbeiter einen ganzen Roman zu geben, zerlegt Helios jede Anfrage in kleine Puzzleteile (Blöcke). Diese Teile werden nicht einem festen Mitarbeiter zugewiesen, sondern dynamisch auf alle verfügbaren Helfer verteilt.

  • Analogie: Wenn ein Besucher einen kurzen Text braucht, nehmen sich nur zwei Helfer die Arbeit. Wenn ein anderer einen langen Roman braucht, springen sofort 16 Helfer an, jeder bearbeitet ein Stück des Puzzles. Niemand steht untätig da, und kein Platz wird verschwendet.

• Der "Fließband-Effekt" (Tiled Attention):
  Früher mussten die Mitarbeiter warten, bis alle Teile eines Satzes fertig sind, bevor sie weitermachen konnten. Helios erlaubt es ihnen, wie auf einem Fließband zu arbeiten: Sobald ein kleines Stück fertig ist, wird es sofort weiterverarbeitet, während die nächsten Teile schon vorbereitet werden. Das spart enorm viel Zeit.

3. Der intelligente Koordinator (Spatially-Aware Allocation)

Helios hat einen super-intelligenten Chef, der genau weiß, wer wo steht.

• Wenn ein neues Puzzleteil (ein Stück Text) ankommt, schaut der Chef nicht nur, wer gerade frei ist, sondern auch: "Wer steht am nächsten?" und "Wer hat den besten Weg zu den anderen Helfern?".
• So wird verhindert, dass die Helfer sich gegenseitig im Weg stehen oder lange Wege laufen müssen, um Informationen auszutauschen. Sie arbeiten wie ein gut koordiniertes Fußballteam, das den Ball (die Daten) blitzschnell weiterreicht, ohne dass jemand stolpert.

4. Das Ergebnis: Schnell und sparsam

Durch diese Kombination aus naher Hardware (Speicher direkt am Prozessor) und kluger Software-Steuerung (dynamische Verteilung der Aufgaben) erreicht Helios Wunder:

• Geschwindigkeit: Es ist im Durchschnitt 3,25-mal schneller als die besten aktuellen Systeme.
• Energie: Es verbraucht 3,36-mal weniger Strom für die gleiche Arbeit.
• Wartezeit: Die Zeit, die ein Nutzer warten muss, bis der nächste Buchstabe erscheint, ist drastisch reduziert.

Zusammenfassung in einem Satz

Helios verwandelt eine starre, ineffiziente KI-Bibliothek, in der Mitarbeiter oft untätig warten, in einen hochflexiblen, 3D-gestapelten Super-Organismus, der Aufgaben wie Puzzleteile dynamisch verteilt, damit immer alle Hände voll zu tun haben und keine Energie verschwendet wird.

Das ist der Durchbruch, um KI-Assistenten nicht nur schneller, sondern auch deutlich günstiger und effizienter in der Cloud betreiben zu können.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Hardware-Software Co-design for 3D-DRAM-based LLM Serving Accelerator" (Helios) auf Deutsch:

1. Problemstellung

Große Sprachmodelle (LLMs) werden zunehmend als Online-Dienste bereitgestellt, die stark dynamische Workloads verarbeiten müssen. Diese Dynamik äußert sich in:

• Fluktuierenden Anfrage-Raten: Spitzenlasten können das Off-Peak-Niveau um ein bis zwei Größenordnungen übersteigen.
• Variierenden Anfrage-Längen: Die Kontextlängen reichen von wenigen Tokens bis zu 10.000+ Tokens, was zu ungleichmäßigen Speicher- und Rechenaufwänden führt.

Bestehende Near-Memory Processing (NMP)-Architekturen, die Rechenkerne (Processing Engines, PEs) direkt in DRAM-Module integrieren, um den Speicherbandbreiten-Engpass zu lösen, scheitern an diesen dynamischen Anforderungen aufgrund zweier Hauptmängel:

1. Grobkörniges KV-Cache-Management: Bestehende Designs weisen Attention-Heads statisch festen NMP-Modulen (z. B. HBM-Cubes) zu. Dies führt zu:
   • Lastungleichgewicht: Bei kleinen Batches oder modernen Architekturen mit wenigen KV-Heads (z. B. GQA, MQA) bleiben viele PEs untätig.
   • Speicherfragmentierung: Da ganze KV-Caches nicht über Module hinweg verteilt werden können, führt dies zu ineffizienter Speichernutzung und verhindert die Aufnahme weiterer Anfragen, obwohl insgesamt noch Kapazität vorhanden ist.
2. Unflexibler Ausführungsfluss: Die Attention-Berechnung erfolgt oft als statische Aufteilung der Key/Value-Matrizen. Dies verhindert eine feinkörnige, blockbasierte Aufteilung (Tiled Attention), die für dynamische Längen und effizientes Online-Softmax notwendig wäre.

Es besteht eine fundamentale Lücke zwischen der dynamischen Natur des LLM-Servings und der nicht-uniformen Speicherabstraktion in NMP-Architekturen.

2. Methodik: Helios

Die Autoren stellen Helios vor, einen LLM-Serving-Beschleuniger, der auf Hybrid Bonding (HB)-Technologie basiert und Hardware-Software-Co-Design nutzt, um NMP-native dynamische KV-Cache-Verwaltung zu ermöglichen.

A. Hardware-Architektur (Hybrid Bonding)

• Technologie: Helios nutzt Hybrid Bonding, um DRAM-Dies direkt mit einer Logik-Die zu verbinden (Cu-Cu-Bonding mit 3µm Pitch). Dies bietet extrem hohe I/O-Dichte und Bandbreite bei geringer Latenz und Energieeffizienz (0,66 pJ/bit).
• Aufbau: Ein HB-Gerät besteht aus einer Logik-Die mit einem 4x4-Array von Processing Engines (PEs) und vier gestapelten DRAM-Dies (insgesamt ~80 GB Kapazität).
• PE-Architektur: Jeder PE verfügt über Matrix-Einheiten (für GEMM), eine Online-Softmax-Einheit, Vektor-Einheiten und eine Reduktions-Einheit. Die PEs sind über ein Mesh-NoC (Network-on-Chip) verbunden.

B. Operator-Ausführung (Intra-PE & Inter-PE)

• Distributed Tiled Attention: Im Gegensatz zu statischen NMP-Designs wird der KV-Cache in feinkörnige Blöcke (z. B. 64 Tokens) zerlegt und über alle PEs verteilt.
• Ausführungsfluss:
  • Intra-PE: Die Berechnung nutzt „Online Softmax" und überlappt GEMM-Operationen mit Vektoroperationen (Reduktion, Normalisierung), um Latenzen zu verbergen.
  • Inter-PE: Es werden effiziente kollektive Primitive (All-Reduce, All-Gather, Reduce-Scatter) über das Mesh-Netzwerk implementiert, um partielle Summen zu aggregieren und Daten für Attention-Heads zu verteilen.
  • MLA-Unterstützung: Für Multi-Latent-Attention (MLA) wird eine „Matrix-Absorption"-Technik angewendet, um die Rekonstruktion großer KV-Tensoren zu vermeiden und die Berechnung direkt auf latenten Vektoren durchzuführen.

C. Systemdesign: Räumlich bewusste KV-Cache-Allokation

Um die Diskrepanz zwischen dynamischen Workloads und der verteilten Speicherarchitektur zu überbrücken, wurde ein Spatially-Aware KV Cache Allocation-Algorithmus entwickelt:

• Ziel: Ausgewogene Lastverteilung über alle PEs bei Minimierung der Datenübertragungskosten zwischen PEs.
• Strategie: Der Algorithmus priorisiert PEs basierend auf:
  1. Der aktuellen Token-Anzahl (Lastausgleich).
  2. Der Manhattan-Distanz zu zentralen PEs (Reduzierung der NoC-Hops für Scatter/Gather-Operationen).
  3. Der Fragmentierung innerhalb von Blöcken.
• Ergebnis: Dies ermöglicht eine feinkörnige Verteilung von KV-Blöcken über das gesamte Gerät, unabhängig von der Anfrage-Länge, und vermeidet Speicherfragmentierung.

3. Schlüsselbeiträge

1. Analyse der Grenzen: Eine tiefgehende Untersuchung zeigt, warum bestehende NMP-Designs (wie AttAcc, Duplex) bei dynamischen LLM-Serving-Workloads ineffizient sind (Lastungleichgewicht, Fragmentierung).
2. Helios-Architektur: Ein neuer Beschleuniger, der Hybrid Bonding nutzt, um eine NMP-native, verteilte Tiled-Attention über ein PE-Array zu ermöglichen.
3. System-Software-Integration: Ein räumlich bewusster Allokator, der die dynamische KV-Cache-Verwaltung (Blockweise) direkt mit der Hardware-Architektur abstimmt, um Kommunikationskosten zu minimieren.
4. Vollständige Implementierung: Unterstützung verschiedener Attention-Varianten (MHA, GQA, MQA, MLA) und FFN/MoE-Blöcke mit optimierten Kommunikationsmustern.

4. Ergebnisse

Die Evaluation wurde mit mehreren State-of-the-Art-Modellen (OPT 66B, LLaMA3 70B, Mixtral 8x22B, Qwen3, DeepSeek 236B) durchgeführt und mit GPUs (A100) sowie bestehenden NMP-Designs verglichen.

• Beschleunigung (Speedup): Helios erreicht einen geometrischen Mittelwert von 3,25-facher Geschwindigkeitssteigerung im Vergleich zu bestehenden GPU/NMP-Designs.
• Energieeffizienz: Eine Verbesserung um den Faktor 3,36 (geometrischer Mittelwert).
• Serving-Performance:
  • Reduktion der P50/P99 „Time-Between-Tokens" (TBT) Latenz um bis zu 72% / 76%.
  • Deutlich höhere Durchsatzkapazität, da Helios dynamische Workloads effizienter handhabt und keine Speicherfragmentierung auftritt.
• Vergleich mit WaferLLM: Helios ist 1,06–1,68-fach schneller bei der Decodierung und 1,07–3,81-fach effizienter in der Geräteausführung, da es keine statischen Partitionen entlang kurzer Dimensionen erzwingt.
• Skalierbarkeit: Die Architektur skaliert gut über verschiedene Batch-Größen und Kontextlängen (bis zu 16K+ Tokens).

5. Bedeutung und Fazit

Helios adressiert kritische Engpässe im LLM-Serving, indem es die Lücke zwischen der dynamischen Natur von LLM-Anfragen und der statischen Abstraktion traditioneller NMP-Architekturen schließt. Durch die Kombination von Hybrid Bonding (für hohe Bandbreite und Integration) und feinkörnigem, räumlich bewusstem Software-Management (für Lastausgleich und Fragmentierungsvermeidung) bietet Helios einen vielversprechenden Weg für zukünftige, hocheffiziente KI-Inferenz-Systeme. Die Arbeit zeigt, dass eine enge Kopplung von Hardware-Architektur und System-Scheduling essentiell ist, um die Vorteile von 3D-DRAM-basierten Beschleunigern in realen, dynamischen Szenarien voll auszuschöpfen.