Jenseits des Modells: Hardware für Ihre KI-Strategie

Hinweis: Dieser Beitrag wurde aus dem Englischen übersetzt. Fachbegriffe, Code und Befehle wurden bewusst im Original belassen.

Große Sprachmodelle sind längst nicht mehr nur eine faszinierende Technologie, sondern ein Grundbaustein der nächsten Welle von Softwareinnovationen. Wir alle haben ihre Fähigkeit bestaunt, zu schreiben, zu schlussfolgern und zu erschaffen. Doch wer vom Nutzer zum Entwickler werden will, muss über die Dialogoberfläche hinausblicken und den Motor darunter verstehen.

Warum benötigt ein Modell mit 70 Milliarden Parametern High-End-Rechenzentrums-GPUs, nur um eine einfache Frage zu beantworten? Wie berechnet man den Speicherbedarf eines LLM und wählt die passende Infrastruktur? Und was ist der größte einzelne Hardware-Engpass, der Kosten und Leistung Ihrer gesamten Anwendung bestimmt?

Dieser Artikel entzaubert diese Grundlagen. Wir gehen von der Magie zur Mechanik und vermitteln Ihnen das nötige Wissen, um zentrale Designentscheidungen zu treffen, Zielkonflikte zu verstehen und die richtige Infrastruktur für leistungsfähige und effiziente GenAI-Anwendungen zu wählen.

Inhalt

1. Was sind LLMs?

2. Wie groß sind LLMs?

3. Speicherbedarf für Training und Inferenz

4. Die richtige Infrastruktur für Training und Inferenz wählen

5. Der VRAM-Engpass: Warum Speicher die zentrale Herausforderung in der LLM-Infrastruktur ist

6. Von der Theorie in die Praxis

1. Was sind LLMs?

Große Sprachmodelle (Large Language Models, LLMs) sind eine Kategorie von Deep-Learning-Modellen, die auf gewaltigen Datenmengen trainiert werden. Dadurch können sie natürliche Sprache und andere Inhalte verstehen und erzeugen und ein breites Aufgabenspektrum bewältigen. LLMs bauen auf einer Architektur neuronaler Netze namens Transformer auf, die besonders gut mit Wortfolgen umgehen und Muster in Texten erfassen kann.

LLMs arbeiten wie riesige statistische Vorhersagemaschinen, die wiederholt das nächste Wort in einer Sequenz vorhersagen. Sie lernen Muster in ihren Texten und erzeugen Sprache, die diesen Mustern folgt.

LLMs markieren einen großen Sprung in der Interaktion zwischen Mensch und Technik, denn sie sind das erste KI-System, das unstrukturierte menschliche Sprache in großem Maßstab verarbeiten kann – und damit natürliche Kommunikation mit Maschinen ermöglicht.

2. Wie groß sind LLMs?

Ein wichtiges Merkmal eines LLM ist seine Größe. Gemeint ist die Zahl seiner Parameter, die üblicherweise im Namen angegeben wird. Das Modell „Llama-2-13b-chat-hf" hat beispielsweise eine Modellgröße von 13 Milliarden Parametern (angezeigt durch „13b").

Die Größe eines LLM, also die Zahl seiner Parameter, bestimmt, wie komplex das Modell ist und wie viele Daten es verarbeiten kann. Ein größeres Modell verfügt über detaillierteres Wissen und ist meist in mehr Bereichen trainiert. Dadurch erhalten Nutzer auf mehr Fragen zufriedenstellende Antworten. Unabhängig von ihrer Größe können alle LLMs menschliche Sprache verstehen, verarbeiten und darauf antworten (bekannt als Natural Language Processing bzw. NLP-Fähigkeiten).

2.1 Überblick über LLMs unterschiedlicher Größe und Zweckbestimmung

Wie die Tabelle zeigt, variieren die Größen von LLMs erheblich. 2019 war die Parameterzahl noch klein: Das 2019 veröffentlichte LLM RoBERTa hat 340 Millionen Parameter. Ab 2022 entstanden vermehrt LLMs mit über 60 Milliarden Parametern (Llama-70B-Modelle, GPT-4, GPT-5 usw.). Diese sind überwiegend für mehrere bzw. allgemeine Zwecke ausgelegt und bilden eine breite Wissensbasis ab. Aufgrund ihrer beträchtlichen Größe ist Fine-Tuning jedoch sehr zeitaufwendig und wenig attraktiv, und auch das Hosting ist sehr teuer. Aus diesem Grund entstehen neben sehr großen LLMs zunehmend „kleine" LLMs, sogenannte SLMs.

2.2 Small Language Models (SLM)

Small Language Models (SLMs) sind leichtgewichtige Varianten klassischer Sprachmodelle, die effizient in ressourcenbeschränkten Umgebungen wie Smartphones, eingebetteten Systemen oder stromsparenden Rechnern laufen. Typischerweise umfassen sie 1 Million bis 10 Milliarden Parameter. SLMs sind deutlich kleiner, behalten aber die zentralen NLP-Fähigkeiten wie Textgenerierung, Zusammenfassung, Übersetzung und Fragebeantwortung.

Der Begriff „Small Language Model" (SLM) ist zwar weit verbreitet, doch manche Fachleute halten ihn für irreführend, da Modelle mit einer Milliarde Parametern objektiv groß sind. Als Alternative wurde „small Large Language Model (sLLM)" vorgeschlagen, gilt aber als zu umständlich. Deshalb hat sich in der Community weitgehend „Small Language Model" durchgesetzt – mit dem Verständnis, dass „small" nur im Vergleich zu den weit größeren Sprachmodellen gemeint ist.

SLMs unterscheiden sich von klassischen LLMs nicht nur durch ihre geringere Größe, sondern auch durch ihre Auslegung als spezialisiertes, optimiertes Sprachmodell. Sie sollten für eine einzelne Aufgabe, einen konkreten Zweck oder eine bestimmte Anwendung eingesetzt werden. Fine-Tuning ist fester Bestandteil der Anpassung: Die vortrainierten Modelle bringen alle nötigen Fähigkeiten zur Kommunikation in natürlicher Sprache und zum Verstehen von Prompts mit, während Fine-Tuning dem SLM domänenspezifisches Verständnis und/oder aufgabenspezifische Fähigkeiten verschafft. Mehr zum Fine-Tuning lesen Sie im letzten Kapitel dieses Artikels (LLM Integration Patterns).

Sie können mehrere spezialisierte SLMs in eine umfassendere Anwendung oder Plattform integrieren, um die Anforderungen komplexer Anwendungsfälle ressourceneffizient und zugleich mit hoher Genauigkeit und Zuverlässigkeit zu erfüllen.

3. Speicherbedarf für Training und Inferenz (inklusive Formel)

3.1 Einführung

Wer große Sprachmodelle selbst hosten oder feintunen möchte, muss den Speicherbedarf eines Modells kennen. Der Gesamtbedarf setzt sich aus dem Speicher zum Laden des Modells in den Arbeitsspeicher des Servers und dem zusätzlichen Speicher für Inferenz (auch Model Serving genannt) oder Fine-Tuning zusammen. Tatsächlich ist bereits das Laden des Modells häufig sehr anspruchsvoll und schränkt den verbleibenden Speicher für Training und Inferenz stark ein – oder erfordert spezielle Server bzw. VMs mit viel (Video-)Speicher.

Beim Laden des Modells spielen die Parameterzahl und die gewünschte Genauigkeit die entscheidende Rolle. Die gewünschte Präzision bestimmt den Datentyp je Parameter:

Von diesen Datentypen wird BF16 am häufigsten verwendet, da er einen guten Kompromiss zwischen Präzision und Speicherbedarf bietet. BF16 wurde von Google Brain als verbesserte Variante von FP16 entwickelt (daher das „b"). FP32 bietet die beste Präzision, benötigt aber auch den meisten Speicher. INT8 und INT4 kommen in Techniken wie der Quantisierung zum Einsatz: Dabei wird häufig ein Modell mit BF16-Parametern geladen und dessen Parameter anschließend über spezielle Algorithmen auf INT8 oder INT4 reduziert, was den Speicherbedarf halbiert bzw. viertelt.

3.2 Den Grundspeicherbedarf berechnen

Kennen Sie die Parameterzahl eines Modells und die gewünschte numerische Präzision, können Sie den zum Laden nötigen Speicher berechnen. Die gewählte Präzision bestimmt, wie viel Speicher jeder Parameter belegt. Den Gesamtbedarf berechnen Sie mit folgender Formel:

Formel 1: Formel zur Bestimmung des Speicherbedarfs eines Machine-Learning-Modells

Beachten Sie, dass die obige Formel für alle ML-Modelle gilt und die Parameterzahl in der klassischen ML-Welt typischerweise in Millionen angegeben wird. Für Modelle mit Parametern im Milliardenbereich lässt sich die Formel vereinfachen:

Formel 2: Vereinfachte Formel zur Berechnung des Speicherbedarfs eines LLM bei Parameterzahlen im Milliardenbereich

Alternativ können Sie statt mit 0,93 auch mit 1 (eins) multiplizieren – so gelingt eine überschlägige Rechnung im Kopf.

Am Beispiel des Modells „Llama-3-8B" mit dem Parameter-Datentyp BF16 lässt sich der exakte Speicherbedarf zum Laden wie folgt berechnen:

Formel 3: Berechnung des Speicherbedarfs eines Llama-3-8B bei Standardpräzision

3.3 Speicherbedarf bei der Inferenz

Inferenz (Model Serving) benötigt zusätzlichen Speicher. Für jede Anfrage muss Speicher in Höhe der Eingabetokens und des bisher erzeugten Texts verfügbar sein. Der insgesamt verfügbare Speicher begrenzt somit die Zahl gleichzeitig verarbeitbarer Anfragen. Bei der Bedarfsrechnung empfiehlt sich die vereinfachte Variante mit dem Faktor eins. Sie schafft unmittelbar einen kleinen Puffer für eingehende Inferenzanfragen.

3.4 Speicherbedarf bei Training und Fine-Tuning

Den Speicherbedarf für Training und Fine-Tuning zu berechnen, ist deutlich komplizierter und hängt stark von den eingesetzten Algorithmen und Trainingseinstellungen ab. In jedem Fall liegt er erheblich über dem der Inferenz. Als grobe Faustregel können Sie das Vier- bis Sechsfache des Inferenzbedarfs ansetzen. Für das Modell „Llama-3-8B" mit dem Datentyp BF16 wären das rund 60 bis 90 GB.

Für den Speicherbedarf spielt es keine Rolle, ob von Grund auf trainiert oder feingetunt wird – er ist in beiden Fällen identisch. Die beim Fine-Tuning üblicherweise geringere Menge an Trainingsdaten beeinflusst lediglich Dauer und Auslastung der GPU, nicht jedoch den Speicherbedarf. Nur speicheroptimierte Algorithmen wie Parameter-Efficient Fine-Tuning (kurz: PEFT) und (quantisierte) Low-Rank Adaptation (kurz: LoRA und QLoRA) senken ihn deutlich.

4. Die richtige Hardware für Training und Inferenz wählen

Für Training und Inferenz von LLMs müssen Sie sich für eine Hardware entscheiden. Dabei sind besondere Ressourcenbeschränkungen zu berücksichtigen: die in Training und Inferenz eingesetzten Algorithmen und Technologien bzw. Werkzeuge. Sie bestimmen, welche Hardware angeschafft werden kann und sollte. GPU-basierte Algorithmen lassen sich beispielsweise in der Regel nicht auf CPUs ausführen. Und obwohl gängige Werkzeuge wie vLLM in der Inferenz häufig eine Vielzahl von Hardware unterstützen (CPUs, GPUs, TPUs usw.), liefern sie mit anderer Hardware als CPUs deutlich bessere Leistung.

4.1 CPUs vs. GPUs/TPUs

Grundsätzlich können CPU-basierte Machine-Learning-Algorithmen große Datenmengen nicht in vertretbarer Zeit verarbeiten. Sie sind meist auf Effektivität optimiert – also darauf, ein bestimmtes Problem möglichst gut zu lösen – statt auf Effizienz (etwa Zeit bis zum Ergebnis). Im Vergleich dazu bieten GPU-/TPU-basierte Algorithmen eine attraktive Alternative: hohe Parallelisierbarkeit (mehr Aufgaben und Anfragen lassen sich gleichzeitig verarbeiten), höherer Durchsatz, schnellere Datenverarbeitung und eine deutlich höhere Spitzenleistung als bei CPUs derselben Generation.

4.2 GPUs vs. TPUs

Spezialisierte Leistung

Tensor Processing Units (TPUs) sind eigens für Berechnungen neuronaler Netze konzipiert. Sie glänzen bei den massiven Matrix- und Tensoroperationen, die das Fundament von LLMs bilden, und ermöglichen bei kompatiblen Modellen oft schnellere Trainingszeiten und höheren Inferenzdurchsatz. Genau diese Spezialisierung ist zugleich ihr größter Nachteil.

Graphics Processing Units (GPUs) sind universellere Prozessoren. Sie bewältigen effizient ein breiteres Spektrum an Rechenaufgaben jenseits reiner Matrixmathematik – etwa Datenvorverarbeitung und weitere eigene Operationen, die Teil einer komplexen Modellarchitektur sein können. Workloads, die nicht von dichter Matrixmultiplikation dominiert werden, profitieren auf TPUs womöglich nicht und könnten sogar langsamer laufen.

Ökosystem und Unterstützung

Das GPU-Ökosystem, vor allem getrieben durch NVIDIAs CUDA-Plattform, ist weit ausgereifter und universell verbreitet. Nahezu alle Machine-Learning-Frameworks (etwa PyTorch, TensorFlow, JAX) bieten native, gut unterstützte GPU-Integration. TPUs hingegen erfordern, dass Code mit dem XLA-Compiler (Accelerated Linear Algebra) übersetzt wird. Das macht Codeänderungen beim Wechsel zwischen GPUs und TPUs nötig und schränkt die Flexibilität ein.

Verfügbarkeit

GPUs sind bei allen großen Cloud-Anbietern breit verfügbar (auch bei europäischen bzw. souveränen Anbietern) und lassen sich für eigene Rechenzentren erwerben. TPUs sind dagegen im Wesentlichen nur auf der Google Cloud Platform (GCP) verfügbar.

4.3 Weitere Recheneinheiten

Über die bislang genannten Rechenzentrumsprozessoren hinaus verdienen zwei weitere Hardwarekategorien Beachtung: NPUs und proprietäre KI-Beschleuniger.

Neural Processing Units (NPUs) sind Prozessoren, die eigens für die effiziente Berechnung neuronaler Netze in stromsparenden Umgebungen entwickelt wurden. Man findet sie häufig in Endgeräten wie Smartphones, Laptops und IoT-Hardware; ihre wesentlichen Vorteile sind Energieeffizienz und die Fähigkeit zur Verarbeitung direkt auf dem Gerät. Das ermöglicht Offline-Funktionalität und stärkt die Privatsphäre, da Daten lokal bleiben. Für die Anforderungen leistungsstarken LLM-Trainings oder großskaliger Inferenz sind sie jedoch nicht ausgelegt und werden nicht als Rechenzentrumsressource angeboten.

Daneben gibt es proprietäre KI-Beschleuniger in der Cloud: eigens entwickelte KI-Chips großer Cloud-Anbieter zur Optimierung bestimmter Workloads. Prominente Beispiele sind AWS Inferentia, Intel Gaudi und die bereits vorgestellten Google TPUs. Ihr Hauptziel ist ein überlegenes Preis-Leistungs-Verhältnis für eine spezialisierte Aufgabe. Da diese Chips eine eigene Hardwarearchitektur besitzen, erfordern sie ein spezifisches Software Development Kit (SDK). Das bedeutet Codeänderungen, zusätzlichen Implementierungsaufwand und insgesamt einen deutlich stärkeren Vendor Lock-in.

4.4 Was wir wählen würden

Für die überwiegende Mehrheit der LLM-Anwendungsfälle sind GPUs die klare Wahl. Sie bleiben die vielseitigste und verlässlichste Option – mit ausgereiftem Ökosystem, unerreichter Flexibilität und hervorragender Leistung, was sie sowohl für Training als auch für Inferenz zum Goldstandard der Branche macht.

Proprietäre KI-Chips von Cloud-Anbietern bieten einen bemerkenswerten Kompromiss: Flexibilität gegen überlegenes Preis-Leistungs-Verhältnis bei bestimmten Aufgaben. Während Google TPUs auf großskaliges Training und AWS Inferentia auf durchsatzstarke, kostengünstige Inferenz ausgelegt sind, hat diese Spezialisierung ihren Preis: erheblicher Vendor Lock-in und eingeschränkte Verfügbarkeit, besonders auf souveränen Cloud-Plattformen.

CPUs bleiben eine Nische und eignen sich am besten für latenzunkritische, asynchrone Anwendungen, bei denen unmittelbare Antwortzeiten keine Rolle spielen und die Kosten im Vordergrund stehen.

5. Der VRAM-Engpass: Warum Speicher die zentrale Herausforderung in der LLM-Infrastruktur ist

5.1 Begrenzte VRAM-Kapazität in Infrastrukturangeboten

Bei der Suche nach passenden GPUs von Cloud-Anbietern stoßen Sie schnell auf eine wesentliche Einschränkung: die Größe des verfügbaren Videospeichers (VRAM). Wichtiger Kontext: GPU-Cloud-Instanzen bzw. VMs verfügen üblicherweise über viel regulären Arbeitsspeicher in Kombination mit CPUs, wobei nur ein kleiner Teil auf die eigentliche GPU samt VRAM entfällt. Allein dieser kleinere VRAM-Anteil (der auf der Anbieter-Website oft schwer zu finden ist) eignet sich für die leistungsstarke Verarbeitung von LLM-Aufgaben. CPUs und regulärer Arbeitsspeicher übernehmen eine wichtige unterstützende Rolle: Sie bereiten Daten vor, laden fortlaufend frische Batches in die GPU, dienen bei bestimmten Algorithmen als Überlaufpuffer und erledigen alle übrigen Aufgaben der Cloud-Instanz bzw. VM, etwa das Betriebssystem. Dennoch sollte die – oft schwer auffindbare – VRAM-Kapazität Ihr Hauptaugenmerk bei der GPU-Wahl sein.

Selbst bei professionellen Rechenzentrums-GPUs ist der Videospeicher im Vergleich zu CPU-basierten Servern klein. Die häufig in Benchmarks genannte, 2020 erschienene Nvidia A100 etwa gibt es in Varianten mit 40 GB und 80 GB VRAM. Die 2024 erschienene Nvidia H200 bietet maximal 141 GB VRAM. Das ist mehr als bei der A100, reicht aber nicht, um große Modelle wie GPT-3-175B oder Falcon 180B ohne mögliche Genauigkeitsverluste auf einer einzelnen GPU zu betreiben. Nur die neueste Rechenzentrums-GPU Nvidia B200 mit 192 GB VRAM könnte den Speicherbedarf ohne Präzisionsverlust decken – allerdings zu extremen Kosten. Mit sich stetig weiterentwickelnden Techniken wie Quantisierung lässt sich der Speicherbedarf für Training und Inferenz jedoch stark senken, bei leicht geringerer Präzision, wodurch verfügbare Ressourcen effizienter genutzt werden. Ebenso können Sie mit Model Parallelism (bzw. Tensor Parallelism) ein Modell über mehrere GPUs verteilen – das geht allerdings mit leichten Leistungseinbußen und Netzwerk-Overhead einher.

Die Tabelle zeigt die mindestens erforderliche VRAM-Kapazität bei Standardpräzision (BF16) und bei Einsatz von Quantisierung (INT8/INT4). Der Bedarf für Training und Inferenz kommt jeweils hinzu. Achten Sie bei der Modellwahl außerdem auf die gängigsten VRAM-Größen von Rechenzentrums-GPUs: 24 GB (budgetorientiert), 40 oder 48 GB (Allzweck), 80 GB (neuer Standard für Training) sowie High-End-GPUs (128 GB, 141 GB, 192 GB).

5.2 Der VRAM-Engpass erklärt
Damit sich eine GPU für LLM-Aufgaben nutzen lässt, müssen sämtliche für einen Prozess oder eine Aufgabe benötigten Daten im Hauptvideospeicher der GPU vorliegen. Aufgrund der hohen Parameterzahl von LLMs entfällt ein großer Teil des verfügbaren Videospeichers allein auf das Laden des Modells. Microsofts offenes Modell Phi-3-medium mit 14 Milliarden Parametern belegt bei einem 16-Bit-Datentyp beispielsweise rund 26 GB VRAM allein zum Laden (siehe die zuvor beschriebene Formel). Der Speicherbedarf für Fine-Tuning oder die Verarbeitung von Anfragen bzw. Prompts während der Inferenz kommt obendrauf.

Abbildung 1:
Links: Speicherbedarf beim Laden des 14B-Modells Phi-3-medium mit Standardpräzision in die GPU.
Rechts: Request Batching (mit vLLM umgesetzt), um VRAM effizienter zu nutzen.

Selbst mit speicheroptimierenden Inferenztechniken wie Request Batching, KV-Batching und Paged Attention bleibt der nach dem Laden eines einzelnen Modells verbleibende Videospeicher einer GPU sehr knapp. In der Praxis wird bei der Inferenz nur ein Bruchteil der verfügbaren Rechenleistung genutzt, wodurch die Größe des Videospeichers zum limitierenden Faktor wird (memory-bound). Das Anstoßen an die VRAM-Obergrenze verursacht einen großen Teil der Latenz.

Bei der Auswahl von GPUs für die Inferenz von LLMs sollte daher die Größe des Videospeichers stets Vorrang vor der Rechenleistung der GPU haben. Nur beim Pre-Training oder Fine-Tuning eines LLM zählt die Rechenleistung wirklich. Vergessen Sie dabei aber nicht, dass der VRAM-Bedarf in diesen Fällen deutlich höher liegt als bei der Inferenz, sofern keine speichereffizienten Fine-Tuning-Algorithmen wie PEFT, LoRA und QLoRA zum Einsatz kommen.

Prüfen Sie außerdem sorgfältig (oder ermitteln Sie experimentell), ob Sie die aktuelle Modellgröße wirklich benötigen oder ob ein kleineres bzw. quantisiertes LLM für Ihren Anwendungsfall ausreicht.

6. Von der Theorie in die Praxis

Die Entscheidung für ein großes Sprachmodell ist nur der erste Schritt. Wie dargestellt, sind die anschließenden zentralen Weichenstellungen nicht bloß technischer Natur – sie sind wirtschaftlich und strategisch.

Zu verstehen, wie sich die Parameterzahl eines Modells in Gigabyte VRAM übersetzt, ist nicht nur eine ingenieurtechnische Fingerübung: Es ist die Grundlage Ihres Budgets und der Schlüssel zur Leistung Ihrer Anwendung. Die Abwägung zwischen einer Allzweck-GPU und einem spezialisierten Cloud-Beschleuniger ist eine strategische Entscheidung über Vendor Lock-in, Skalierbarkeit und langfristige Betriebskosten.

Wie also übersetzen Sie diese Grundlagen in einen Wettbewerbsvorteil?

Genau diese Herausforderung lösen wir. Seit Jahren ist Liquid Reply darauf spezialisiert, robuste, skalierbare Internal Developer Platforms (IDPs) auf Kubernetes zu bauen und komplexe Infrastruktur zu beherrschen. Diese tiefe Expertise bringen wir nun in das nächste Feld ein: Organisationen dabei zu unterstützen, souveräne, produktionsreife KI- und LLMOps-Plattformen aufzubauen.

Die technischen Herausforderungen sind vergleichbar – komplexe Pipelines steuern, knappe GPU-Ressourcen optimieren und eine reibungslose Developer Experience bieten. Unsere Referenzarchitektur auf Basis von Kubernetes gibt Ihnen die Kontrolle über Ihre Modelle, Ihre Daten und Ihre Kosten.

Bleiben Sie dran: Wir veröffentlichen weitere Artikel zu LLMOps mit praxisnahen Umsetzungen von Model Serving, Monitoring und automatisierten Fine-Tuning-Pipelines.

Damit Sie schneller vom Konzept in die Produktion kommen: Sprechen Sie uns an, um zu besprechen, wie wir Ihre KI-Plattform gemeinsam aufbauen.