Beste Cloud-GPUs für das Bereitstellen und Deployment von LLMs

Was das Serving von LLMs tatsächlich von einer gemieteten GPU verlangt

Das Serving eines großen Sprachmodells ist eine grundlegend andere Arbeitslast als das Training eines solchen Modells. Das Training ist durch den Durchsatz begrenzt und toleriert Latenz; das Serving ist latenzsensitiv, speichergebunden und burstartig. Wenn Sie eine GPU mieten, um ein LLM hinter einer API bereitzustellen, ist der Engpass selten die rohe FLOPS-Leistung. Entscheidend ist, wie viel vom Modell und seinem KV-Cache Sie im VRAM halten können, wie schnell dieser Speicher Daten liefert und wie viele gleichzeitige Anfragen Sie bündeln können, bevor die Tokens pro Sekunde pro Nutzer zusammenbrechen.

Der KV-Cache ist der Teil, den die meisten unterschätzen. Jede aktive Anfrage speichert die Aufmerksamkeits-Schlüssel und -Werte für ihren Kontext, und dieser Speicherbedarf wächst mit der Sequenzlänge und der Anzahl gleichzeitiger Nutzer. Ein Modell, das im Leerlauf bequem passt, kann sofort den Speicher überschreiten, sobald Sie echten Traffic mit langen Prompts schicken. Deshalb benötigen Serving-Deployments oft mehr VRAM-Reserve als die Modellgewichte allein vermuten lassen.

Wie man die GPU passend zum Modell dimensioniert

Die praktische erste Frage ist, ob das Modell auf eine GPU passt oder auf mehrere verteilt werden muss. Vergleichen Sie anhand der obigen Übersicht mit Ihrem Modell und berücksichtigen Sie diese Faktoren:

• VRAM-Kapazität bestimmt, welche Modelle passen. Ein quantisiertes 7B–13B-Modell in FP8 oder INT8 kann von einem einzelnen Mittelklasse-Beschleuniger bedient werden, während ein 70B-Modell in BF16 in der Regel eine Karte mit viel Speicher oder einen Multi-GPU-Knoten benötigt. Sehr große Frontier-Modelle erfordern effektiv mehrere Top-GPUs, die miteinander verbunden sind.
• Speicherbandbreite bestimmt die Geschwindigkeit der Token-Generierung. Autoregressives Decoding liest für jedes erzeugte Token den kompletten Satz an Gewichten, daher erzeugt HBM-Speicher (wie bei Rechenzentrumskarten) Tokens deutlich schneller als GDDR-basierte Consumer-Karten bei gleicher Modellgröße. Für interaktive Chats ist die Bandbreite oft wichtiger als die Rechenleistung.
• Unterstützte Präzisionen bestimmen, wie stark Sie das Modell komprimieren können. Karten mit FP8- und INT8-Tensor-Unterstützung erlauben es, größere Modelle mit weniger VRAM und höherem Durchsatz zu bedienen, vorausgesetzt, Ihr Serving-Stack und das Quantisierungsschema des Modells sind kompatibel.
• Interconnect wird wichtig, sobald ein Modell mehrere GPUs umfasst. Tensor-paralleles Serving tauscht Aktivierungen zwischen GPUs auf jeder Schicht aus, daher liefern NVLink-ähnliche Verbindungen innerhalb eines Knotens deutlich bessere Latenz als reine PCIe-Konfigurationen. Für Single-GPU-Deployments ist der Interconnect irrelevant.

Single-GPU- versus Multi-GPU-Serving

Wenn Ihr Modell und sein maximaler KV-Cache auf eine GPU passen, behalten Sie es dort. Single-GPU-Serving vermeidet vollständig den Overhead der geräteübergreifenden Kommunikation und ist einfacher zu betreiben. Wechseln Sie zu Tensor-Parallelistik oder Multi-Node-Serving nur, wenn das Modell wirklich nicht passt, denn jede zusätzliche GPU bringt Synchronisationskosten mit sich und erschwert das automatische Skalieren. Wenn Sie mehrere GPUs benötigen, bevorzugen Sie Instanzen aus der obigen Liste, die Hochspeicherkarten mit einem schnellen In-Node-Interconnect kombinieren, anstatt lose gekoppelte Karten zusammenzuschalten.

Provider-Funktionen, die für Serving wichtig sind, nicht fürs Training

Über die Hardware hinaus entscheidet das Betriebsmodell des Anbieters, ob ein Deployment praktikabel ist. Wenn Sie die obige Übersicht für eine Serving-Arbeitslast statt für einen Trainingslauf betrachten, priorisieren Sie anders:

• Cold-Start- und Einrichtungszeit werden zu erstklassigen Anliegen. Ein Serving-Endpunkt, der zwischen Traffic-Spitzen auf null skaliert, zahlt die Cold-Start-Kosten bei jedem Hochfahren, daher beeinflussen schnelle Bereitstellung und Image-Caching direkt die Latenzspitzen.
• Abrechnungsgranularität verändert die Wirtschaftlichkeit bei burstartigem Traffic. Abrechnung pro Sekunde oder Minute passt zu autoskalierenden Endpunkten, die Instanzen hoch- und runterfahren; grobe Abrechnung pro Stunde bestraft dieses Muster.
• On-Demand-Zuverlässigkeit gegenüber Spot ist meist die richtige Wahl. Unterbrechbare oder Spot-Instanzen sind hervorragend für Training und Batch-Jobs, aber riskant für nutzerorientierte Endpunkte, wo eine Rücknahme mitten in einer Anfrage den Live-Traffic unterbricht. Spot eignet sich weiterhin gut für nicht-interaktive Batch-Inferenz.
• Persistenter Speicher und schnelles Modell-Laden reduzieren Neustartzeiten. Mehrgigabyte-Gewichte, die bei jedem Neustart aus kaltem Objektspeicher geladen werden, verursachen Minuten Ausfallzeit; gecachte oder angehängte Volumes verkürzen diese Zeit.
• Netzwerk und Ausgangsverkehr beeinflussen die Kosten im großen Maßstab. Hochdurchsatz-Inferenz kann große Datenmengen nach außen bewegen; prüfen Sie die Ausgangsverkehrsbedingungen, bevor Sie sich auf ein Deployment mit hohem Traffic festlegen.

Batch- versus Echtzeit-Serving und wo die Kosten liegen

Entscheiden Sie früh, welchen Modus Sie optimieren wollen. Echtzeit-interaktives Serving legt Wert auf geringe Zeit bis zum ersten Token und konstante Token-Raten pro Nutzer, was hohe Speicherbandbreite und moderate Batch-Größen bevorzugt. Batch- oder Offline-Inferenz legt Wert auf Gesamtdurchsatz und kann große Batches auf günstigere oder unterbrechbare Hardware packen, wobei die Latenz pro Anfrage gegen deutlich bessere Kosten pro Token eingetauscht wird. Viele Teams betreiben beides: eine reaktionsschnelle On-Demand-Schicht für Live-Nutzer und eine Spot-gestützte Batch-Schicht für Bulk-Generierung.

Bei den Mietkosten deckt Serving das gesamte Spektrum ab. Ein kleines quantisiertes Modell auf einer Mittelklasse-Karte ist günstig und weit verbreitet; Frontier-Modelle auf Multi-GPU-Hochspeicher-Knoten sind rar, teurer und manchmal während Nachfragespitzen kapazitätsbeschränkt. Da die Preise ständig schwanken und je nach Region und Vertragsbindung variieren, betrachten Sie die obige Live-Vergleichstabelle als Quelle der Wahrheit statt einer festen Zahl und vergleichen Sie Instanzen anhand von VRAM, Bandbreitenklasse, Interconnect und Abrechnungsmodell zusammen, nicht nur anhand des Preises.

Häufig gestellte Fragen

Wie viel VRAM benötige ich, um ein LLM zu serven?

Planen Sie die Modellgewichte in der gewählten Präzision plus erheblichen Spielraum für den KV-Cache ein, der mit Kontextlänge und gleichzeitigen Nutzern wächst. Als grobe Richtlinie dienen quantisierte kleine und mittlere Modelle von einer einzelnen Mittelklasse-Karte, während große Modelle in höherer Präzision eine Hochspeicher-Karte oder mehrere GPUs benötigen. Dimensionieren Sie immer für die maximale Gleichzeitigkeit, nicht für den Leerlauf.

Sind Spot- oder unterbrechbare GPUs für das Serving von LLMs geeignet?

Für nutzerorientierte Echtzeit-Endpunkte in der Regel nein, da eine Rücknahme laufende Anfragen abbricht und kalte Neustarts erzwingt. Spot-Instanzen eignen sich gut für Offline- oder Batch-Inferenz, wo Unterbrechungen nur den Durchsatz verzögern, aber keine interaktive Sitzung unterbrechen. Viele Teams halten On-Demand-Kapazität für Live-Traffic vor und nutzen Spot für Bulk-Jobs.

Warum ist die Speicherbandbreite für das Serving wichtiger als die Rechenleistung?

Das Token-für-Token-Decoding liest die Modellgewichte aus dem Speicher für jedes erzeugte Token, daher ist die Generierungsgeschwindigkeit durch die Geschwindigkeit begrenzt, mit der die GPU Speicher streamt, und nicht durch ihre maximale FLOPS-Leistung. Deshalb erzeugen HBM-ausgestattete Rechenzentrumskarten Tokens schneller als Consumer-Karten mit gleichem Modell, und deshalb ist die Bandbreite eine wichtige Vergleichsgröße oben.

Soll ich auf einer GPU serven oder auf mehrere aufteilen?

Verwenden Sie eine einzelne GPU, wann immer das Modell und sein maximaler KV-Cache passen, da dies geräteübergreifende Kommunikation vermeidet und das Skalieren vereinfacht. Wechseln Sie zu Multi-GPU-Tensor-Parallelistik nur, wenn das Modell wirklich nicht passt, und wählen Sie dann Instanzen, die Hochspeicherkarten mit schnellem In-Node-Interconnect kombinieren.