KI-Inferenz bezeichnet die Ausführung bereits trainierter KI-Modelle, um Vorhersagen, Klassifikationen oder generierte Inhalte bereitzustellen. Anders als beim Training werden die Modellgewichte dabei nicht fortlaufend angepasst. Stattdessen müssen KI-Inferenz-Systeme Anfragen mit definiertem Durchsatz und innerhalb vorgegebener Latenzgrenzen verarbeiten. Für IT-Architekten, die LLM-Serving-Plattformen, Echtzeit-Recommendation-Engines oder Computer-Vision-Anwendungen bereitstellen, steht deshalb nicht allein die maximale Rechenleistung im Vordergrund. Entscheidend ist, welche Serverarchitektur die geforderte Leistung bei einer wirtschaftlich vertretbaren Auslastung erreicht.
Dieser Artikel erklärt, welche Hardware für KI-Inferenz benötigt wird, wann CPU- oder GPU-basierte Inferenz sinnvoll ist und welche Rolle Speicherkapazität, Speicherbandbreite, Interconnect und Serving-Software spielen. Darüber hinaus zeigt er, welche Beschleunigerklassen für unterschiedliche Inferenz-Workloads infrage kommen.
Was unterscheidet KI-Inferenz vom Training?
Beim KI-Training werden Modellparameter durch wiederholte Berechnungen und die Verarbeitung großer Datensätze angepasst. Die KI-Inferenz verwendet dagegen bereits trainierte Modellgewichte, um neue Eingaben zu verarbeiten und Ergebnisse zu erzeugen.
| Kriterium | KI-Inferenz | KI-Training |
|---|---|---|
| Ziel | Trainiertes Modell auf neue Eingaben anwenden | Modellparameter anhand von Trainingsdaten optimieren |
| Berechnungen | Forward-Pass zur Berechnung von Vorhersagen oder Ausgaben | Forward- und Backward-Pass, Gradientenberechnung und Parameterupdates |
| Rechenleistung | Abhängig von Modell, Batch-Größe und Anfrageprofil | Hohe Rechenleistung für Training und Gradientenberechnung erforderlich |
| Speicherbedarf | Modellgewichte, Aktivierungen und bei autoregressiven Transformern KV-Cache | Modellgewichte, Gradienten, Aktivierungen und Optimizer-Zustände |
| Speicherbandbreite | Besonders wichtig beim LLM-Decoding mit kleinen Batch-Größen | Relevant für Datenbewegungen während des Trainings |
| Wichtige Leistungsmetriken | Latenz, Token-Durchsatz, Anfragekapazität und Kosten pro Anfrage | Trainingsdurchsatz, Konvergenzzeit und Modellqualität |
| Hardware-Dimensionierung | Modellgröße, Präzision, Kontextlänge, Parallelität und Latenzziele | Modellgröße, Trainingsverfahren, Präzision und Trainingsdauer |
Bei der KI-Inferenz großer Sprachmodelle ist insbesondere die Token-Generierung bei kleinen Batch-Größen häufig durch die Speicherbandbreite begrenzt. Die Verarbeitung längerer Eingaben, auch Prefill genannt, sowie größere Batch-Größen können dagegen stärker durch die verfügbare Rechenleistung begrenzt sein. Ein 70-Milliarden-Parameter-Modell benötigt bei FP16 rund 140 GB allein für seine Modellgewichte. Bei der autoregressiven Token-Generierung müssen diese Gewichte für aufeinanderfolgende Decoding-Schritte wiederholt aus dem GPU-Speicher gelesen werden. Wie schnell dies geschieht, hängt unter anderem von der Speicherbandbreite, der Modellarchitektur und der Effizienz der eingesetzten Inferenz-Software ab.
Bei der Inferenz spielt die Reduzierung der numerischen Präzision eine wichtige Rolle. Während beim Training häufig gemischte Präzisionsverfahren eingesetzt werden, können Inferenz-Modelle vielfach mit INT8, FP8 oder 4-Bit-Quantisierung ausgeführt werden. Dadurch lässt sich der Speicherbedarf reduzieren. Ob die Modellqualität ausreichend erhalten bleibt, muss jedoch für das jeweilige Modell und den Anwendungsfall geprüft werden.
Hinzu kommt die Anfrageverarbeitung: Inferenz-Systeme müssen häufig wechselnde Ankunftsraten, unterschiedliche Eingabelängen und mehrere gleichzeitige Nutzer bewältigen. Dynamisches Batching kann die GPU-Auslastung verbessern, indem mehrere Anfragen gemeinsam verarbeitet werden. Größere Batches erhöhen jedoch nicht automatisch die Leistung jeder einzelnen Anfrage und können zusätzliche Wartezeiten verursachen.
KI-Inferenz auf CPU, GPU oder spezialisierten Beschleunigern
CPUs sind eine praktikable Option für Inferenz-Workloads mit kleineren Modellen, moderatem Anfrageaufkommen oder ausreichend großzügigen Latenzanforderungen. Ein Bildklassifikationsmodell, das nur gelegentlich Anfragen verarbeitet, kann beispielsweise auf einem Intel Xeon Prozessor oder einer AMD EPYC CPU wirtschaftlich betrieben werden, ohne dass eine dedizierte GPU erforderlich ist. Moderne Server-Prozessoren unterstützen zudem Vektor- und Matrixoperationen, die bestimmte Inferenz-Berechnungen beschleunigen können. Ob CPU-Inferenz ausreicht, hängt jedoch von der Modellarchitektur, der verwendeten Software und dem gewünschten Durchsatz ab. Bei größeren Modellen, hohen Anfragezahlen und rechenintensiven Anwendungen kommen zunehmend KI-GPUs zum Einsatz. Sie bieten spezialisierte Recheneinheiten und hohe Speicherbandbreiten für die parallele Verarbeitung von Modelloperationen.
Für GPU-beschleunigte Inferenz stehen unterschiedliche Beschleunigerklassen zur Verfügung. Die NVIDIA RTX PRO 6000 Blackwell Server Edition mit 96 GB GDDR7 eignet sich beispielsweise als Plattform für professionelle Inferenz-Anwendungen, multimodale Modelle und produktive KI-Server. Für größere Sprachmodelle und speicherintensive Workloads kommen Beschleuniger mit hoher HBM-Kapazität wie NVIDIA H200 oder AMD Instinct MI350X und MI355X infrage.
Bei hohen Anforderungen an den Gesamtdurchsatz und die parallele Verarbeitung vieler Anfragen können Multi-GPU-Plattformen mit NVIDIA B200 oder B300 sinnvoll sein. HBM4-basierte Beschleuniger wie NVIDIA Rubin und AMD Instinct MI455X erweitern die Möglichkeiten für besonders anspruchsvolle Inferenz-Infrastrukturen. Die Auswahl sollte jedoch nicht allein anhand der GPU-Generation erfolgen. Entscheidend sind Modellgröße, Präzision, Speicherbedarf, Parallelität und die tatsächlich erreichbaren Latenz- und Durchsatzwerte.
GPU-Speicherkapazität und Bandbreite bei der KI-Inferenz
Die GPU-Speicherkapazität bestimmt wesentlich, welche Modelle auf einem Beschleuniger ausgeführt werden können. Ein 7-Milliarden-Parameter-Modell benötigt bei FP16 theoretisch rund 14 GB für die Modellgewichte. Zusätzlich werden Speicher für den KV-Cache, Aktivierungen, Laufzeitumgebung und weitere Berechnungen benötigt. Eine Server GPU mit 24 GB kann für bestimmte 7B-Inferenz-Konfigurationen ausreichen, stellt jedoch keine allgemeingültige Mindestanforderung dar.
Ein 70B-Modell benötigt bei FP16 rund 140 GB allein für die Gewichte. Eine einzelne NVIDIA H100 mit 80 GB kann diese Gewichte nicht vollständig im lokalen GPU-Speicher halten. Eine AMD Instinct MI300X mit 192 GB HBM3 bietet dagegen ausreichend Kapazität für die Modellgewichte und einen zusätzlichen Speicherbereich. Wie viel Speicher für Kontext und gleichzeitige Anfragen verfügbar bleibt, hängt von der konkreten Implementierung ab. Neben der Kapazität beeinflusst die Speicherbandbreite die Leistung. Die NVIDIA H100 SXM bietet beispielsweise bis zu 3,35 TB/s HBM-Bandbreite, während AMD für die MI300X bis zu 5,3 TB/s angibt. Diese Werte sind technische Spezifikationen der jeweiligen Beschleuniger und kein direkter Vergleich des erreichbaren Inferenz-Durchsatzes.
Die höhere Speicherbandbreite kann den Token-Durchsatz bei kleinen Batch-Größen verbessern, sofern die Token-Generierung tatsächlich speicherbandbreitenbegrenzt ist. Bei größeren Batches können dagegen Rechenleistung, Cache-Kapazität und Scheduling stärker ins Gewicht fallen.
Wie viel Arbeitsspeicher benötigt ein Inferenz-Server?
Der Arbeitsspeicher des Servers unterstützt unter anderem die Vor- und Nachverarbeitung, Datenpufferung, Modellbereitstellung und weitere Aufgaben der Serving-Software. Computer-Vision-Anwendungen benötigen beispielsweise Ressourcen für Bilddekodierung und Skalierung. Bei LLMs kommen Tokenisierung, Anfrageverwaltung und die Verarbeitung generierter Ausgaben hinzu.
Die erforderliche Systemspeicherkapazität hängt von der GPU-Anzahl, der Modellbereitstellung, dem Anfrageaufkommen und den Aufgaben der Vor- und Nachverarbeitung ab. Pauschale Empfehlungen wie 512 GB oder 1 TB RAM sind ohne eine konkrete Workload-Beschreibung deshalb nicht belastbar.
LLM-Inferenz: KV-Cache, Quantisierung und Multi-GPU-Serving
Große Sprachmodelle stellen besondere Anforderungen an den GPU-Speicher. Neben den Modellgewichten müssen zusätzliche Daten für die Verarbeitung laufender Anfragen bereitgestellt werden. Bei autoregressiven Transformer-Modellen erfolgt die Textgenerierung schrittweise. Für jedes neue Token wird ein weiterer Vorwärtsdurchlauf ausgeführt. Insbesondere bei kleinen Batch-Größen kann die wiederholte Verarbeitung der Modellgewichte die Speicherbandbreite stark beanspruchen.
Warum ist der KV-Cache wichtig?
Der KV-Cache speichert Key- und Value-Tensoren bereits verarbeiteter Tokens, damit diese Informationen bei nachfolgenden Decoding-Schritten nicht vollständig neu berechnet werden müssen.
Der benötigte Speicher hängt unter anderem von folgenden Faktoren ab:
- Modellarchitektur und Anzahl der Transformer-Schichten
- Anzahl der Key-Value-Heads und deren Dimension
- Kontextlänge und Präzision des KV-Caches
- Anzahl gleichzeitig verarbeiteter Anfragen
Bei längeren Kontextfenstern und hoher Gleichzeitigkeit kann der KV-Cache einen erheblichen Teil des verfügbaren GPU-Speichers beanspruchen. Die Parameteranzahl eines Modells allein reicht deshalb nicht aus, um den gesamten VRAM-Bedarf zu bestimmen. Zwei Modelle mit vergleichbarer Parameteranzahl können aufgrund ihrer Architektur deutlich unterschiedliche Cache-Anforderungen aufweisen.
Wie beeinflusst Quantisierung den Speicherbedarf?
Quantisierung reduziert die numerische Präzision der Modellgewichte und gegebenenfalls weiterer Datenstrukturen. Ein 70B-Modell benötigt für seine Gewichte theoretisch ungefähr:
| Präzision | Speicherbedarf der Modellgewichte |
|---|---|
| FP16 / BF16 | 140 GB |
| INT8 | 70 GB |
| 4-Bit | 35 GB |
Vereinfachte Berechnung ohne Quantisierungsmetadaten, zusätzliche Modellstrukturen, KV-Cache und Laufzeit-Overhead.
Durch die Quantisierung der Modellgewichte kann das bei der Token-Generierung zu übertragende Datenvolumen reduziert werden. Bei speicherbandbreitenbegrenzten Workloads kann dies den Durchsatz verbessern. Die physische Speicherbandbreite der GPU verändert sich dadurch nicht. Außerdem hängt der tatsächliche Leistungsgewinn davon ab, ob die Hardware und das Serving-Framework die gewählten Präzisionsformate effizient unterstützen. Auch die Modellqualität muss nach einer Quantisierung anhand repräsentativer Aufgaben überprüft werden.
Tensor- und Pipeline-Parallelismus
Wenn ein Modell auf mehrere GPUs verteilt wird, stehen unterschiedliche Parallelisierungsverfahren zur Verfügung. Beim Tensor-Parallelismus werden Berechnungen innerhalb einzelner Modellschichten auf mehrere Beschleuniger verteilt. Dadurch entstehen regelmäßige Kommunikationsvorgänge zwischen den GPUs. Die verfügbare Interconnect-Bandbreite und die Kommunikationslatenz beeinflussen deshalb die Skalierung.
Beim Pipeline-Parallelismus werden unterschiedliche Modellschichten auf verschiedene GPUs verteilt. Dies kann die Anforderungen an die Kommunikation zwischen den Beschleunigern verändern, führt aber zu Abhängigkeiten zwischen den Verarbeitungsschritten. Welche Methode geeignet ist, hängt von Modellarchitektur, GPU-Topologie, Batch-Größe und Latenzzielen ab. Tensor-Parallelismus ist nicht grundsätzlich schneller und Pipeline-Parallelismus nicht automatisch die bessere Wahl für PCIe-Systeme.
Bei großen Inferenz-Installationen können beide Verfahren kombiniert werden. Für hohe Anfragezahlen kann zudem die Bereitstellung mehrerer unabhängiger Modellinstanzen sinnvoller sein als die Verteilung eines einzelnen Modells über sämtliche GPUs.
Serving-Software für KI-Inferenz: Triton, TensorRT und ONNX Runtime
Die Serving-Software beeinflusst, welche Server Hardware eingesetzt werden kann und wie effizient die vorhandenen Ressourcen genutzt werden.
NVIDIA Triton Inference Server
Der NVIDIA Triton Inference Server (der Manager) unterstützt unterschiedliche Backends, darunter TensorRT, ONNX Runtime, PyTorch und TensorFlow. Zu seinen Funktionen gehören unter anderem dynamisches Batching, die Verwaltung mehrerer Modelle und HTTP-/gRPC-Schnittstellen. Die Hardware-Anforderungen hängen vom eingesetzten Backend ab. TensorRT setzt NVIDIA-GPUs voraus, während ONNX Runtime je nach Execution Provider auch CPU-basierte Inferenz ermöglicht.
Für die Dimensionierung eines Triton-Servers sind neben der GPU-Leistung die Anfrageverarbeitung, die Vor- und Nachverarbeitung sowie die parallele Ausführung mehrerer Modelle zu berücksichtigen.
NVIDIA TensorRT und TensorRT-LLM
NVIDIA TensorRT (der Tuner) optimiert neuronale Netze für die Ausführung auf unterstützten NVIDIA-GPUs. Dazu gehören beispielsweise die Auswahl geeigneter Rechenkerne, die Optimierung von Operatoren und die Nutzung unterstützter Präzisionsformate.
TensorRT-LLM erweitert diese Möglichkeiten für große Sprachmodelle und unterstützt unter anderem optimierte Decoding-Verfahren, Quantisierung und Inflight-Batching. Die verfügbaren Funktionen hängen von der TensorRT-LLM-Version, der GPU-Architektur und dem jeweiligen Modell ab. Eine bestimmte Leistungssteigerung gegenüber PyTorch lässt sich daraus nicht pauschal ableiten. Für belastbare Vergleiche müssen Modell, Präzision, Hardware und Testbedingungen übereinstimmen.
ONNX Runtime
ONNX Runtime (der Allrounder) ermöglicht die Ausführung unterstützter Modelle über unterschiedliche Execution Provider. Dazu gehören CPU-basierte Ausführungsumgebungen sowie GPU-Backends für unterstützte Hardwareplattformen. ONNX Runtime kann deshalb für Inferenz-Umgebungen interessant sein, in denen Portabilität und die Unterstützung unterschiedlicher Beschleuniger eine wichtige Rolle spielen.
Die tatsächlich erreichbare Leistung hängt jedoch vom Modell, dem Execution Provider und den verfügbaren Optimierungen ab. Eine generell niedrigere Performance gegenüber TensorRT lässt sich nicht für alle Modelle und Konfigurationen feststellen.
Die Framework-Wahl beeinflusst die Serverarchitektur
Eine auf TensorRT ausgerichtete Bereitstellung ist an unterstützte NVIDIA-GPUs gebunden. Bei AMD Instinct müssen die Kompatibilität mit ROCm und den vorgesehenen Inferenz-Frameworks geprüft werden. Für heterogene Modellumgebungen können Serving-Plattformen mit mehreren Backends Vorteile bieten. Gleichzeitig müssen die benötigten Laufzeitumgebungen, Modellinstanzen und Speicherressourcen berücksichtigt werden. Die Auswahl der Serving-Software sollte deshalb vor der endgültigen Festlegung der Serverkonfiguration erfolgen.
KI-Inferenz dimensionieren: Modell, Hardware und Workload
Die Dimensionierung eines Inferenz-Servers beginnt mit den Eigenschaften des Modells und den Anforderungen der Anwendung. Dazu gehören die Parameteranzahl, die Modellarchitektur, die Zielpräzision, die erwartete Anzahl gleichzeitiger Anfragen und die gewünschten Antwortzeiten. Insbesondere bei LLM-Serving müssen Eingabe- und Ausgabelängen getrennt betrachtet werden. Die Verarbeitung langer Eingaben stellt andere Anforderungen an die Hardware als die anschließende Token-Generierung.
Auch NVIDIA behandelt in seinem Fachbeitrag zur GPU-Dimensionierung für AI-Inferenz die Verbindung zwischen Workload-Anforderungen und Total Cost of Ownership. Für die Planung sollten deshalb neben der Modellgröße insbesondere Time to First Token (TTFT), Token-Durchsatz, Parallelität und GPU-Auslastung berücksichtigt werden. Erst auf dieser Grundlage lässt sich beurteilen, ob zusätzliche GPU-Kapazität die Wirtschaftlichkeit verbessert oder lediglich ungenutzte Ressourcen schafft.
Typische Inferenz-Anforderungen und geeignete GPU-Plattformen
Basierend auf unserer Erfahrung in der Beratung und Konfiguration professioneller KI-Server haben wir typische Inferenz-Anforderungen passenden GPU- und Plattformklassen zugeordnet. Die Übersicht dient als Orientierung für die Hardwareauswahl und stellt keine direkte Leistungsrangliste dar.
| Inferenz-Anforderung | Geeignete GPUs / Plattformen | Entscheidende Kriterien |
|---|---|---|
| Professionelle KI-Inferenz | NVIDIA RTX PRO 6000 Blackwell Server Edition, NVIDIA L40S | Modellgröße, GPU-Speicher, Latenz, Energiebedarf |
| Speicherintensive LLM-Inferenz | NVIDIA H200, AMD Instinct MI350X / MI355X | HBM-Kapazität, Speicherbandbreite, KV-Cache, Modellpräzision |
| Skalierte Multi-GPU-Inferenz | NVIDIA HGX B200 / B300, AMD Instinct MI350-Serie Plattformen | Parallele Anfragen, Gesamtdurchsatz, GPU-Interconnect, Serving-Framework |
| Inferenz-Infrastruktur der nächsten Generation | NVIDIA Vera Rubin Plattformen, AMD Instinct MI455X-basierte Systeme | HBM4, Scale-up-/Scale-out-Architektur, Netzwerk, Plattformverfügbarkeit |
Die tatsächliche Eignung einer Plattform hängt vom konkreten Modell und der Serving-Konfiguration ab. Eine GPU mit hoher Speicherkapazität ist nicht automatisch die wirtschaftlichste Lösung für jede Inferenz-Anwendung.
Ebenso kann eine Plattform mit mehreren unabhängigen Modellinstanzen für bestimmte Anfragemuster geeigneter sein als ein großer Multi-GPU-Verbund, sofern jede Instanz über ausreichend GPU-Speicher verfügt.
Wie lässt sich der Hardwarebedarf systematisch bestimmen?
Eine belastbare Kapazitätsplanung sollte folgende Schritte umfassen:
- Modellanforderungen bestimmen: Architektur, Parameteranzahl, Präzision und Speicherbedarf der Modellgewichte.
- Anfrageprofil erfassen: Gleichzeitige Nutzer, Eingabe- und Ausgabetoken, Kontextlängen und erwartete Lastspitzen.
- Leistungsziele definieren: TTFT, Token-Generierungsrate, Gesamtlatenz und erforderlicher Durchsatz.
- GPU-Speicher dimensionieren: Modellgewichte, KV-Cache, Laufzeit-Overhead und erforderliche Reserven.
- Plattformarchitektur auswählen: Single-GPU, mehrere unabhängige GPU-Instanzen oder verteiltes Modell-Serving.
- Reale Workloads testen: Latenz, Durchsatz, Speicherbelegung und Auslastung unter repräsentativer Last messen.
- Wirtschaftlichkeit bewerten: Hardwarekosten, Energiebedarf, Infrastrukturaufwand und Kosten pro verarbeitetem Token berücksichtigen.
Erst danach sollten die endgültige CPU-Ausstattung, der Systemspeicher, die Netzwerkanbindung und die Storage-Konfiguration festgelegt werden.
Ein für Training optimierter Server ist nicht zwangsläufig die beste Lösung für Inferenz. Insbesondere das Verhältnis zwischen GPU-Ressourcen, CPU-Leistung, Speicher und Interconnect muss zum tatsächlichen Serving-Workload passen.
Praxisbeispiel: KI-Inferenz mit einem 70B-Modell im Unternehmen
Ein Unternehmen möchte ein 70B-Sprachmodell für eine interne Wissensplattform bereitstellen. Die Anwendung soll mehrere gleichzeitige Nutzer bedienen und Antworten mit geringer Wartezeit erzeugen. Bei FP16 benötigt das Modell rund 140 GB allein für die Gewichte. Hinzu kommen KV-Cache, Laufzeit-Overhead und weitere Speicheranforderungen. Durch Quantisierung kann der Speicherbedarf der Modellgewichte reduziert werden. Ob das Modell anschließend auf einer einzelnen GPU betrieben werden kann, hängt von der verfügbaren Kapazität und dem zusätzlichen Speicherbedarf ab. Bei mehreren GPUs muss entschieden werden, ob das Modell über mehrere Beschleuniger verteilt oder auf ausreichend ausgestatteten GPUs mehrfach als unabhängige Instanz bereitgestellt wird. Diese Entscheidung beeinflusst sowohl die Kommunikationsanforderungen als auch die erreichbare Parallelität. Für eine fundierte Hardwareauswahl müssen deshalb unterschiedliche Konfigurationen mit repräsentativen Eingabe- und Ausgabelängen getestet werden. Die höchste theoretische Rechenleistung liefert nicht zwangsläufig die niedrigsten Kosten pro Anfrage.
Bei KI-Inferenz entscheidet der Workload über die Hardware
Eine Echtzeit-Computer-Vision-Anwendung stellt andere Anforderungen an die Serverarchitektur als eine interne LLM-Plattform oder ein hochskalierter Inferenz-Dienst. Entscheidend für die Hardwareauswahl sind das Zusammenspiel von Modellarchitektur, GPU-Speicher, Interconnect und Serving-Software sowie die geforderten Latenz- und Durchsatzwerte.
Sie planen GPU-Server für KI-Inferenz? server-hardware.com unterstützt Unternehmen, Systemintegratoren und technische Einkäufer bei der Auswahl und Konfiguration geeigneter Server-Systeme. Senden Sie uns Ihre Anforderungen an Modell, Framework, Latenz und Durchsatz – unsere Serverspezialisten beraten Sie bei der passenden Systemarchitektur.
Technische Quellen:
Online Marketing Managerin
