Start/Vertiefung/Architektur/Fuenf Compute-Architekturen fuer AI: CPU, GPU, TPU, NPU und LPU verstehen
10. April 2026

Fuenf Compute-Architekturen fuer AI

Modelle werden nicht nur durch bessere Algorithmen schneller, sondern vor allem durch die Hardware darunter. Ein Gutteil der Fortschritte der letzten fuenf Jahre ist nicht auf neue Verlustfunktionen zurueckzufuehren, sondern auf die Tatsache, dass Nvidia H100 viermal schneller Matrix-Multiplikationen in BF16 ausfuehrt als eine V100 und dabei fast dreimal so viel Speicherbandbreite bietet. Wer die Architekturen unter dem Modell nicht versteht, versteht auch nicht, warum Meta und OpenAI hunderte Milliarden in Compute-Deals versenken, warum Groq ploetzlich einen Nischen-Boom erlebt und warum das iPhone lokale Diktierfunktionen bekommt, aber keine GPT-5-Inferenz.

Dieser Artikel ordnet die fuenf Klassen ein, die im Moment die gesamte KI-Infrastruktur tragen: CPU, GPU, TPU, NPU und LPU. Jede ist ein Kompromiss aus Flexibilitaet, Durchsatz, Latenz und Leistungsaufnahme -- und jede sitzt an einer anderen Stelle im Stack.

Intuition

Es hilft, die Architekturen auf zwei Achsen zu sortieren. Die erste reicht von general purpose bis spezialisiert: Wie viele unterschiedliche Programme laesst sich die Hardware beibringen? Die zweite reicht von Training bis Inference: Fuer welche Phase des Lebenszyklus ist sie optimiert?

Die interessante Einsicht: Training und Inference haben unterschiedliche Bottlenecks. Training ist rechengebunden und liebt massive Parallelitaet. Inference ist bei autoregressiven Modellen speichergebunden -- die Matrix-Multiplikationen pro Token sind klein, der Flaschenhals ist die Bandbreite, mit der Gewichte aus dem Speicher in die Rechenkerne fliessen. Diese Asymmetrie ist der Grund, warum spezialisierte Inferenz-Architekturen ueberhaupt existieren.

CPU

Die CPU ist der Kontrollpunkt des Systems, nicht ihr Rechenwerk. Ein moderner Server-Xeon oder EPYC hat 64 bis 128 Kerne mit Out-of-Order-Execution, tiefen Pipelines, Branch Prediction und drei Cache-Ebenen. Jeder einzelne Kern ist komplex genug, um beliebige Programme effizient auszufuehren -- aber genau diese Komplexitaet kostet Die-Flaeche, die fuer arithmetische Einheiten fehlt. Eine High-End-CPU erreicht bei FP32 ungefaehr 2 bis 4 TFLOPs. Eine H100 erreicht in FP16 knapp 1.000.

Fuer Training moderner LLMs ist die CPU damit praktisch unbrauchbar. Ein einzelner Trainingsschritt fuer ein 70B-Modell wuerde auf einer CPU Wochen dauern, auf einem GPU-Cluster Sekunden. Der Flaschenhals ist doppelt: zu wenig arithmetischer Durchsatz, und zu wenig Speicherbandbreite -- DDR5 liefert etwa 100 GB/s, HBM3e auf einer H200 fast 5 TB/s, also ein 50-facher Unterschied.

Trotzdem ist die CPU unverzichtbar. Sie orchestriert Trainingsruns, laedt Daten in den Tensor-Pipelines vor, fuehrt Tokenizer aus, verwaltet verteilte Kommunikation und haendelt alles, was nicht strikt numerisch ist. Bei Inference kleiner Modelle -- Embeddings, Klassifikatoren, LLMs im 1B-Bereich -- ist sie durchaus kompetitiv, besonders bei quantisierten Gewichten (INT8 oder INT4) mit Bibliotheken wie llama.cpp. Der Laptop-AVX-512- oder AMX-Pfad erreicht bei kleinen Modellen brauchbare Tokens pro Sekunde und spart die Umstaende eines GPU-Deployments.

GPU

Die GPU ist im Kern eine Maschine, die dieselbe Operation auf sehr viele Datenpunkte gleichzeitig anwendet: Single Instruction, Multiple Threads (SIMT). Eine Nvidia H100 besteht aus 132 Streaming Multiprocessors (SM), jeder mit 128 CUDA-Cores und vier Tensor Cores. Die Tensor Cores sind der eigentliche Grund, warum Nvidia die KI-Welt dominiert: Sie fuehren eine komplette Matrix-Multiply-Accumulate-Operation auf 4x4- oder 16x16-Bloecken in einem einzigen Takt aus, in FP16, BF16, FP8 oder neuerdings FP4. Genau diese Operation ist der rechenintensive Kern jedes Transformer-Layers.

Die Speicherhierarchie ist das zweite entscheidende Element:

Je weiter unten in der Hierarchie Daten liegen, desto schneller der Zugriff -- aber desto weniger passt hinein. Der gesamte Job des GPU-Programmierers ist, Daten so zu bewegen, dass die teuren Rechenkerne nicht auf den Speicher warten muessen. Bei Inference groesserer LLMs sind die Tensor Cores typischerweise zu 30-40% ausgelastet, weil die HBM-Bandbreite der Bottleneck ist.

Deshalb gibt es Flash Attention: Der klassische Attention-Kernel materialisiert die NxN-Attention-Matrix im HBM, was bei langen Kontexten quadratisch wird. Flash Attention berechnet den Attention-Output blockweise direkt im Shared Memory, ohne die vollstaendige Matrix je auszuschreiben. Das ist ein rein hardware-bewusster Kernel -- die Mathematik ist identisch, nur die Speicherbewegungen sind umsortiert. Das Ergebnis ist zwei- bis viermal schneller bei gleichzeitig linearem statt quadratischem Speicherverbrauch.

Nvidias Vorsprung ist damit nicht nur die Hardware, sondern das Software-Oekosystem darum: CUDA, cuDNN, cuBLAS, NCCL, Triton, TensorRT-LLM. Jedes mit Jahren an Optimierung. AMDs MI300X und Intels Gaudi 3 schliessen die Hardware-Luecke langsam, kaempfen aber gegen den Netzwerkeffekt einer Bibliothekslandschaft, die seit 2007 auf CUDA aufgebaut wird.

TPU

Die Tensor Processing Unit ist Googles hauseigener KI-Beschleuniger und unterscheidet sich architektonisch fundamental von einer GPU. Das Herzstueck ist das Systolic Array -- ein zweidimensionales Gitter aus Multiply-Accumulate-Einheiten, durch das Daten rhythmisch wie Blut durch ein Herz ("systolisch") stroemen. Auf einer TPU v4 misst dieses Array 128x128 Rechenzellen, auf v5p und Trillium mehr. In jedem Takt reicht jede Zelle ihr Zwischenergebnis weiter -- am Ende faellt das Produkt zweier Matrizen aus dem Array heraus, ohne dass ein einziger Zwischenwert jemals in einen Register oder Cache geschrieben werden musste.

Der Vorteil: Das Systolic Array nutzt einmal geladene Daten sehr oft wieder, was die Speicherbandbreiten-Last im Vergleich zu einer GPU deutlich reduziert. Der Nachteil: Es kann praktisch nur Matrix-Multiplikation. Alles, was nicht in diese Form passt, wird auf die deutlich kleineren skalaren und vektoriellen Einheiten der TPU ausgelagert und wird dort langsam. GPUs sind universeller, TPUs effizienter -- solange man beim Dense-Matmul bleibt.

TPUs sind eng mit JAX und dem XLA-Compiler verzahnt. XLA uebernimmt Graph-Fusionen, Layout-Optimierungen und die Abbildung auf das Systolic Array. Der Preis: Wer eigene Kernel schreiben will, hat bei weitem nicht die Freiheit wie mit CUDA oder Triton. Der Nutzen: Ein gut kompilierter JAX-Graph skaliert auf tausende TPUs nahezu linear. Gemini wird auf TPU-Pods mit zehntausenden Chips trainiert, die ueber das Inter-Chip Interconnect (ICI) in einer 3D-Torus-Topologie verbunden sind.

Aktueller Stand (Stand April 2026): TPU v5p mit 8.960 Chips pro Pod, und Trillium (v6) als Generation mit deutlich hoeherer Energieeffizienz und HBM-Erweiterung, gezielt fuer die naechste Gemini-Generation. TPUs gibt es ausschliesslich in Google Cloud -- man kauft sie nicht, man mietet sie. Der zweitgroesste TPU-Konsument neben Google selbst ist Anthropic, das bekanntermassen sowohl auf TPU als auch auf H100/H200 trainiert.

NPU

Neural Processing Units sind die Antwort auf eine andere Frage: Wie bringe ich ein 3-Milliarden-Parameter-Modell auf ein Smartphone, ohne den Akku in zehn Minuten zu leeren? Eine NPU ist kein Konkurrent zur GPU im Rechenzentrum, sondern ein spezialisierter Block auf einem SoC, der Inferenz kleiner Modelle bei Bruchteilen des Stromverbrauchs erledigt.

Apples Neural Engine sitzt seit dem A11 (2017) in jedem iPhone-Chip; im M4 und M5 erreicht sie 38 bis 50 TOPS bei INT8 und einem Power-Budget von wenigen Watt. Qualcomms Hexagon NPU in den Snapdragon-8-Gen-X- und X-Elite-Chips kommt auf aehnliche Groessenordnungen. Googles Edge TPU (Coral) und die NPU im Tensor G4 bedienen Pixel-Devices. Microsofts Copilot+ PC-Initiative verlangt mindestens 40 TOPS fuer die NPU-Zertifizierung, was Qualcomm, AMD und Intel zu Ryzen AI und Lunar Lake mit integrierten NPUs gedraengt hat.

Der Trick an NPUs ist nicht roher Durchsatz, sondern Effizienz. Sie arbeiten praktisch ausschliesslich in INT8 oder INT4, haben fest verdrahtete Datenpfade fuer typische Operationen (Convolution, Depthwise Conv, Matmul, Activation Fusion) und verzichten auf die Flexibilitaet einer GPU. Weniger Flexibilitaet bedeutet weniger Transistoren im Kontrollpfad und mehr im Rechenpfad -- und damit mehr TOPS pro Watt. Eine Apple Neural Engine erreicht bei einem typischen Diffusionsmodell etwa 5-10x die Energieeffizienz der GPU im selben SoC.

Was nicht geht: Training. NPUs haben keinen Support fuer Rueckwaertspass, oft keinen FP16/BF16-Pfad, und ihr Speicher ist auf wenige GB begrenzt. Was gut geht: On-Device-Inferenz von Modellen bis etwa 8B Parameter (quantisiert), Echtzeit-Bildklassifikation, Sprachsynthese, ASR, Diffusion fuer Bildbearbeitung. Apples Vision Pro, Pixel-Kamera-Pipeline und Windows Copilot+ Recall nutzen genau diese Hardware.

LPU

Die Language Processing Unit ist der juengste Zugang und stammt von Groq, das sie 2023-2024 bekannt gemacht hat. Bei oberflaechlichem Blick wirkt "LPU" wie Marketing, tatsaechlich steckt aber eine echte, von GPU und TPU fundamental verschiedene Architektur-Idee dahinter: deterministische, streamingorientierte Ausfuehrung ohne HBM.

Das Problem, das Groq loest, ist die Latenz autoregressiver Inference. Ein LLM generiert Token fuer Token. Jeder Token erfordert einen vollstaendigen Forward-Pass durch alle Modellgewichte. Auf einer GPU limitiert die HBM-Bandbreite: Man kann die Gewichte pro Token nur einmal lesen, also ist die maximale Token-Rate durch Bandbreite / Modellgroesse nach oben begrenzt. Fuer ein 70B-Modell in FP16 auf einer H100 sind das theoretisch etwa 23 Tokens pro Sekunde, in der Praxis weniger.

Groqs Loesung: weg mit dem HBM. Ein Groq-Chip (der LPU oder intern Tensor Streaming Processor) hat rund 230 MB SRAM on-die und keinen externen Speicher. SRAM ist schneller als HBM um Groessenordnungen und hat deutlich niedrigere Latenz, ist aber viel teurer pro Byte und passt nicht auf einen einzelnen Chip in Groessenordnungen, die fuer moderne LLMs noetig waeren. Deshalb verteilt Groq ein Modell auf hunderte Chips, die ueber ein deterministisches Netzwerk verbunden sind, und schiebt die Gewichte als Datenstrom durch diesen Verbund.

Das Ganze funktioniert nur, weil die Ausfuehrung vollstaendig deterministisch kompiliert wird. Kein dynamisches Scheduling, kein Caching, keine Branch Prediction. Der Compiler weiss zu jedem Zyklus genau, welcher Chip welche Operation ausfuehrt und welche Daten zu welchem Nachbarn fliessen. Das macht die Hardware stark vereinfachbar -- keine Caches, keine komplizierten Speichercontroller -- und erlaubt Taktraten, die unter Volllast nicht einbrechen.

Die Zahlen, die Groq publiziert, sind beeindruckend: ueber 500 Tokens pro Sekunde auf Llama-3-70B, teils ueber 1.000 auf kleineren Modellen. Das ist etwa eine Groessenordnung schneller als eine gut ausgelastete H100 bei Batchsize 1. Genau deshalb erlebt Groq seinen Nischen-Boom: Fuer interaktive Agenten, Voice-Interfaces und Latency-kritische Chatbots ist der Unterschied zwischen 40 und 500 Tokens pro Sekunde wahrnehmbar und produktrelevant.

Die Limitierungen sind ebenso klar. LPUs koennen nicht trainieren -- sie haben keinen Backward-Pass-Support, und das deterministische Scheduling macht variable Graphen nahezu unmoeglich. Die Context Length ist durch SRAM-Kapazitaet begrenzt. Grosse Modelle brauchen viele Chips (hunderte fuer 70B-Modelle), was den Preisvorteil relativiert. Und jeder Architektur-Wechsel eines Modells erfordert eine komplette Compiler-Neudurchlaufsrunde. Cerebras' Wafer-Scale Engine und SambaNovas RDU verfolgen verwandte Ideen -- dataflow-orientierte Architekturen ohne HBM-Bottleneck -- mit jeweils anderen Kompromissen.

Praxis-Relevanz

Wer heute trainiert oder deployt, faehrt je nach Szenario auf unterschiedlichen Schienen:

Die groessere Einsicht: Es gibt keine "beste" Architektur, sondern Architekturen, die an unterschiedlichen Punkten des Compute-Pareto-Fronts sitzen. Wer Modelle trainieren will, braucht rohe FLOPs und viel HBM -- GPU oder TPU. Wer Modelle mit minimaler Latenz inferieren will, braucht Bandbreite naeher am Rechenwerk -- LPU oder GPU mit Speculative Decoding. Wer sie auf einem Geraet mit Batterie ausfuehren will, braucht TOPS pro Watt -- NPU. Und wer den Kleber zwischen all dem schreibt, laesst CPUs die Arbeit machen, die kein Beschleuniger effizient erledigen kann.

Die Hardware ist keine Commodity, sondern eine Design-Entscheidung. Und diese Entscheidung bestimmt zunehmend, welche Modelle ueberhaupt moeglich sind.

Quellen

Nach oben