Ein LLM-Inferenzserver wird nicht allein anhand der Modellgröße dimensioniert. Zunächst werden die tatsächliche Länge der Eingabeaufforderungen und Antworten, die Spitzenrate der Anfragen, die Anzahl gleichzeitig verarbeiteter Anfragen und die zulässige Latenz ermittelt. Anschließend berechnet man den Speicherbedarf für die Modellgewichte und den KV-Cache separat, schätzt den Token-Durchsatz und wählt erst danach GPU, CPU, RAM, NVMe-Speicher und Netzwerk aus. Für einen kleinen internen Chatbot kann ein einzelner Beschleuniger ausreichen, während dasselbe Modell mit langem Kontext und Dutzenden aktiven Dialogen mehrere GPUs oder mehrere Server-Replikate erfordern kann.
Modell + Kontext + aktive Anfragen + Ziellatenz + Reserve = Serverkonfiguration.
Das Modell selbst kann vollständig in den GPU-Speicher passen, dennoch kann der Dienst bei steigender Last beginnen, Anfragen abzulehnen. Der Grund dafür ist, dass der Speicher nicht nur für die Gewichte verwendet wird. Einen erheblichen Anteil belegen der KV-Cache, temporäre Puffer, Dienststrukturen und Daten der Softwareumgebung.
Auch die Zahl der Benutzer allein sagt wenig aus. Hundert Mitarbeitende, die einen Chatbot mehrmals täglich nutzen, erzeugen eine ganz andere Last als zwanzig Kunden, die gleichzeitig umfangreiche Dokumente senden und ausführliche Antworten erwarten.
GPU servers
Warum die Modellgröße allein nicht ausreicht
Bei der Auswahl eines Servers müssen vier voneinander unabhängige Einschränkungen geprüft werden.
Kapazität
Im GPU-Speicher müssen gleichzeitig die Gewichte, der KV-Cache aktiver Anfragen, temporäre Puffer, Dienststrukturen und eine Reserve für Fragmentierung Platz finden. Der Start des Modells ohne Benutzer bestätigt lediglich, dass der minimale Datensatz hineinpasst.
Latenz und Durchsatz
Der Benutzer wartet zunächst auf die Verarbeitung des Kontexts und auf den ersten Teil der Antwort und anschließend auf die weitere Generierung. Ein Test mit einem Kontext von 500 Token lässt sich nicht auf eine Last mit 8.000 oder 16.000 Token übertragen.
Der Server muss den eingehenden Datenstrom außerdem schneller verarbeiten, als die Warteschlange wächst. Deshalb wird die Leistung bei festgelegten Eingabe- und Ausgabelängen, Parallelitätsgraden und Latenzgrenzen gemessen.
Skalierung
Es gibt drei mögliche Architekturen:
- Ein Modell wird auf mehrere GPUs verteilt.
- Mehrere unabhängige Kopien des Modells werden ausgeführt.
- Das Modell oder seine Replikate werden auf mehrere Server verteilt.
Modellparallelität ist erforderlich, wenn das Modell nicht auf einen einzelnen Beschleuniger passt. Replikate eignen sich besser, um mehr Benutzer zu bedienen und die Ausfallsicherheit zu erhöhen. Eine Multi-Node-Architektur wird eingesetzt, wenn die Ressourcen eines einzelnen Servers nicht ausreichen, sie erfordert jedoch ein schnelles Netzwerk und eine komplexere Verwaltung.
Welche Daten für die Berechnung benötigt werden
Bei einer bestehenden Anwendung werden die Parameter aus den Anfrageprotokollen entnommen. Für ein neues Projekt erstellt man drei Profile: normal, Spitzenlast sowie ungünstig, aber noch zulässig.
| Parameter | Was gemessen werden muss | Worauf es sich auswirkt |
|---|---|---|
| Modell | Parameter, Schichten, KV-Köpfe, Kopfgröße | Größe der Modellgewichte und KV-Cache |
| Gewichtsformat | 16, 8 oder 4 Bit | GPU-Speicherverbrauch |
| Kontext | Median, 95. Perzentil und Grenzwert | Zeit bis zum ersten Token und KV-Cache |
| Antwort | Durchschnittliche Länge, 95. Perzentil und Grenzwert | Anfragedauer und Ausgabedurchsatz |
| Rate | Anfragen pro Sekunde oder Minute bei Spitzenlast | Parallelität und Warteschlangengröße |
| Latenz | Erstes Token, Token-Intervalle, Gesamtzeit | GPU-Klasse und Anzahl der Replikate |
| Verfügbarkeit | Zulässige Ausfallzeit | Redundanz |
| Wachstum | Last in 6–12 Monaten | Leistungsreserve der Plattform |
Der Kontext sollte mit dem Tokenizer des konkreten Modells gemessen werden. Eine Umrechnung von Zeichen oder Wörtern in Token ist ungenau, weil die Tokenisierung von Sprache und Vokabular abhängt.
Die vom Hersteller angegebene maximale Kontextlänge darf nicht für jede Anfrage angesetzt werden. Für die Berechnung werden die tatsächliche Längenverteilung und ein produktseitiger Grenzwert benötigt. Auch ein Durchschnittswert reicht nicht aus: Sind fünf Prozent der Anfragen deutlich länger als der Rest, verschlechtert eine auf dem Durchschnitt basierende Konfiguration die Latenz gerade beim anspruchsvollsten Teil der Last.
So berechnen Sie den Speicherbedarf der Modellgewichte
Die NVIDIA H200 ist ein Beispiel für eine Server-GPU mit großem, schnellem Speicher. Quelle: NVIDIA.
Bildquelle: NVIDIA
Die vorläufige Größe der Gewichte wird mit folgender Formel berechnet:
Speicher für Gewichte ≈ Anzahl der Parameter × Bit pro Parameter ÷ 8
Für eine schnelle Schätzung:
- 7 Milliarden Parameter im 16-Bit-Format — etwa 14 GB;
- 14 Milliarden — etwa 28 GB;
- 32 Milliarden — etwa 64 GB;
- 70 Milliarden — etwa 140 GB;
- 70 Milliarden im 8-Bit-Format — etwa 70 GB;
- 70 Milliarden im 4-Bit-Format — etwa 35 GB.
Dies ist nur die theoretische Größe der Gewichte. Die Empfehlungen von Hugging Face zur Optimierung der Inferenz behandeln Quantisierung und weitere Möglichkeiten zur Verringerung des Speicherverbrauchs, doch der gesamte Speicherbedarf des Dienstes lässt sich nicht mit einer einzigen Formel bestimmen.
Zu den Gewichten müssen hinzugerechnet werden:
- Quantisierungsskalen und Metadaten;
- temporäre Tensoren und Arbeitsbereiche der Bibliotheken;
- Speicher für Ausführungsgraphen;
- der KV-Cache;
- Strukturen des Schedulers;
- Fragmentierung;
- Reserve für einen stabilen Betrieb bei Spitzenlast.
Aus diesem Grund sollte kein Beschleuniger unter der Annahme ausgewählt werden, dass die Gewichte nahezu den gesamten verfügbaren Speicher belegen dürfen. Selbst wenn das Modell startet, kann für Kontext und parallele Anfragen kein Platz mehr übrig sein.
Was sich durch Quantisierung ändert
Die Umstellung der Gewichte von 16 auf 4 Bit reduziert deren Größe theoretisch um etwa den Faktor vier, der gesamte Speicherverbrauch sinkt jedoch nicht im gleichen Verhältnis. Der KV-Cache kann weiterhin im 16- oder 8-Bit-Format gespeichert werden, während Puffer und einige Operationen eine höhere Genauigkeit verwenden können.
Es gibt weitere Einschränkungen:
- unterschiedliche Modelle verlieren unterschiedlich stark an Qualität;
- das Format muss von der ausgewählten Umgebung und GPU unterstützt werden;
- ein 4-Bit-Modell ist nicht zwangsläufig schneller als ein 8-Bit-Modell;
- eine Formatkonvertierung kann den Leistungsgewinn teilweise verringern;
- bei Mixture-of-Experts-Modellen werden in der Regel die Gewichte aller Experten im Speicher gehalten, obwohl für ein einzelnes Token nur ein Teil davon aktiv ist.
Quantisierung löst in erster Linie ein Kapazitätsproblem. Ihre Auswirkungen auf Qualität und Geschwindigkeit müssen mit produktiven Anfragen getestet werden.
KV-Cache: Wie Kontext und parallele Anfragen Speicher verbrauchen
Während der Generierung speichert das Modell Zwischenschlüssel und -werte für bereits verarbeitete Token. Dadurch muss der gesamte vorherige Kontext bei jedem neuen Token nicht erneut berechnet werden. Diese Daten werden als Key-Value-Cache oder KV-Cache bezeichnet.
Der Cache wächst mit der Sequenz und existiert separat für jede aktive Anfrage. Er enthält sowohl die Token des Eingabekontexts als auch den bereits generierten Teil der Antwort.
Für verbreitete Transformer-Architekturen wird folgende Näherungsformel verwendet:
KV-Cache = 2 × Anzahl der Schichten × Anzahl der KV-Köpfe × Kopfgröße × Byte pro Element × Token × aktive Sequenzen
Der Faktor 2 berücksichtigt Schlüssel und Werte. Die Anzahl der KV-Köpfe muss aus der Modellkonfiguration übernommen werden und darf nicht durch die Gesamtzahl der Attention-Köpfe ersetzt werden. Seitenbasierte Speicherzuweisung, Wiederverwendung von Blöcken und Cache-Grenzen werden in der TensorRT-LLM-Dokumentation beschrieben.
Beispiel für ein hypothetisches Modell mit 70 Milliarden Parametern
Nehmen wir folgende Architektur an:
- 80 Schichten;
- 8 KV-Köpfe;
- Kopfgröße 128;
- 2 Byte pro Element.
Ein Token in einer Sequenz benötigt:
2 × 80 × 8 × 128 × 2 = 327.680 Byte, also ungefähr 0,3125 MiB.
Daraus ergibt sich:
- 8.192 Token belegen etwa 2,5 GiB für eine Sequenz;
- 16.384 Token belegen etwa 5 GiB;
- 16 Sequenzen mit jeweils 8.192 Token belegen etwa 40 GiB;
- 32 Sequenzen mit jeweils 16.384 Token belegen etwa 160 GiB.
Die Gewichte eines 4-Bit-Modells belegen theoretisch etwa 35 GB. Bei sechzehn langen parallelen Anfragen nähert sich der kombinierte Speicherbedarf von Gewichten und KV-Cache jedoch bereits 75 GB, noch bevor Puffer und Reserve berücksichtigt werden. Auf einem Beschleuniger mit 80 GB Speicher liegt diese Konfiguration nahe an der Kapazitätsgrenze, obwohl das Modell im Leerlauf weniger als die Hälfte des Speichers belegt.
Der Speicherverbrauch des KV-Caches wird üblicherweise auf mehrere Arten reduziert:
- den Arbeitskontext begrenzen;
- alte Gesprächsverläufe zusammenfassen oder entfernen;
- eine maximale Antwortlänge festlegen;
- die Anzahl aktiver Sequenzen pro Replikat verringern;
- ein kompakteres Cache-Format verwenden, sofern es unterstützt wird;
- seitenbasierte Speicherzuweisung nutzen;
- identische Anfragepräfixe wiederverwenden;
- lang laufende Hintergrundaufgaben von der interaktiven Warteschlange trennen.
Bei RAG ist es besonders wichtig, Anzahl und Größe der abgerufenen Textabschnitte zu kontrollieren. Werden alle Suchergebnisse in die Eingabe aufgenommen, steigen sowohl der KV-Cache als auch die Verarbeitungszeit der Eingabe. Ein zusätzliches Reranking ist häufig effizienter als eine bloße Vergrößerung des Kontexts.
So wird die Benutzerzahl in aktive Anfragen umgerechnet
Für den Server sind registrierte Benutzer weniger wichtig als Anfragen, die in der Warteschlange stehen, deren Kontext verarbeitet wird oder deren Antwort gerade generiert wird.
Aktive Anfragen ≈ maximale Ankunftsrate × durchschnittliche Verarbeitungszeit
Wenn pro Sekunde eine Anfrage eintrifft und die Antwortgenerierung 20 Sekunden dauert, werden ungefähr 20 Anfragen gleichzeitig bedient. Steigt die Verarbeitungszeit auf 40 Sekunden, verdoppelt sich bei gleicher Ankunftsrate die parallele Last.
Berücksichtigt werden müssen kurze Spitzen, die vollständige Dauer gestreamter Antworten, lange Anfragen, Kundenlimits und das rechtzeitige Abbrechen nicht mehr benötigter Generierungen. Auch Wiederholungen nach Zeitüberschreitungen sind gefährlich: Bei Überlastung erzeugen sie zusätzliche Anfragen.
Tausend Mitarbeitende können nur zwei oder drei aktive Dialoge erzeugen, während wenige große API-Kunden dauerhaft Dutzende Sequenzen aktiv halten können.
Welche Latenzmetriken gemessen werden sollten
Für einen LLM-Dienst gibt es keine einzelne universelle Latenzmetrik. Für eine interaktive Anwendung sind drei Messgrößen entscheidend.
Zeit bis zum ersten Token
Dies ist der Zeitraum vom Absenden einer Anfrage bis zum Empfang des ersten Teils der Antwort. Er umfasst Warteschlange, Tokenisierung, Verarbeitung des Eingabekontexts und den Beginn der Generierung. Bei einem Chatbot fällt diese Kennzahl besonders auf: Schrittweise ausgegebener Text wirkt normal, während eine lange Zeit ohne Ausgabe wie ein eingefrorenes Programm erscheint.
Latenz zwischen den Token
Sie zeigt, wie gleichmäßig der restliche Text generiert wird. Beeinflusst wird sie durch Modellgröße, Speicherbandbreite der GPU, Batching, Konkurrenz zwischen Anfragen und Kommunikation zwischen den Beschleunigern.
Gesamte Antwortzeit
Sie hängt sowohl von der Generierungsgeschwindigkeit als auch von der Ausgabelänge ab. Konfigurationen müssen daher mit derselben Verteilung von Ein- und Ausgaben verglichen werden. Metriken für die LLM-Inferenz unterscheiden zwischen der Zeit bis zum ersten Token, Generierungsintervallen, Ende-zu-Ende-Latenz und Durchsatz.
Eingabe-Token, Ausgabe-Token und abgeschlossene Anfragen pro Sekunde sollten separat gemessen werden. Ein hoher Gesamtdurchsatz garantiert keinen guten Dienst: Große Batches können die GPU-Auslastung verbessern, gleichzeitig aber die Wartezeit einzelner Benutzer erhöhen.
Sinnvoller ist es, Anfragen zu zählen, die innerhalb der vorgegebenen Grenzen abgeschlossen werden. Beispielsweise können nur Antworten berücksichtigt werden, deren erstes Token in weniger als zwei Sekunden eintrifft und deren Generierungsintervalle akzeptabel bleiben. Dieser Ansatz wird in GenAI-Perf verwendet.
Welche Serverkomponenten das Ergebnis bestimmen
Dell PowerEdge XE9680.
Bildquelle: infohub.delltechnologies.com
GPU und Videospeicher
Bei der Auswahl eines Beschleunigers werden folgende Punkte bewertet:
- Kapazität und Bandbreite des GPU-Speichers.
- Leistung im gewählten Modellformat.
- Verbindungsmethode zwischen mehreren GPUs.
- Stromverbrauch und Kühlungsanforderungen.
Die Kapazität bestimmt, ob Gewichte, KV-Cache und Puffer Platz finden. Die Speicherbandbreite ist insbesondere bei autoregressiver Generierung wichtig. Mehrere GPUs bilden nicht automatisch einen gemeinsamen Speicherpool: Die Softwareumgebung muss das Modell aufteilen, und Daten müssen zwischen den Beschleunigern übertragen werden. Standard-PCIe und eine Hochgeschwindigkeitsverbindung können trotz gleicher Gesamtspeicherkapazität zu unterschiedlichen Latenzen führen.
Zentralprozessoren
CPUs übernehmen Tokenisierung, APIs, Routing, Netzwerkoperationen und einen Teil der RAG-Pipeline. Bei der Dokumentenverarbeitung führen sie außerdem Dekomprimierung, Formatkonvertierung und Aufteilung des Textes in Abschnitte aus.
Neben Anzahl und Leistung der Kerne sind folgende Punkte wichtig:
- PCIe-Lanes;
- Position der GPUs relativ zu den CPU-Sockeln;
- Speicherbandbreite;
- NUMA-Topologie;
- Anzahl verfügbarer Speichergeräte und Netzwerkadapter.
Für dichte Konfigurationen kommen AMD-EPYC-Server und Intel-Xeon-Server infrage. Die Auswahl sollte sich an der Plattformtopologie sowie an der Kompatibilität mit Beschleunigern und Software-Stack orientieren und nicht allein am Namen des Prozessors.
Arbeitsspeicher und NVMe
RAM wird zum Laden des Modells, für Container, Dateicache, Vektordatenbanken, Indizes, Dokumentvorbereitung und die Speicherung von Adaptern verwendet. Das Auslagern eines Teils des Modells in den RAM kann den Start einer zu großen Konfiguration ermöglichen, dauerhafte Übertragungen über PCIe erhöhen jedoch in der Regel die Latenz.
NVMe-Speicher beeinflusst vor allem Kaltstarts, Modellwechsel, RAG-Indizes und Batchverarbeitung. Wenn Generierung, Vektordatenbank und Indexierung auf demselben Server ausgeführt werden, sollte deren I/O nach Möglichkeit auf verschiedene Laufwerke oder Speicherpools verteilt werden.
Netzwerk
Bei einer Text-API ist die Clientverbindung selten der wichtigste Engpass. Das Netzwerk wird kritischer, wenn sich die Vektordatenbank auf einem anderen Knoten befindet, das Modell auf mehrere Server verteilt ist oder mehrere Knoten große Datenmengen austauschen. Latenz und Stabilität sind ebenso wichtig wie Gigabit pro Sekunde.
Stromversorgung, Gehäuse und Kühlung
Folgende Punkte müssen geprüft werden:
- Formfaktor und Leistungsaufnahme der unterstützten GPUs;
- Riser, Kabel und Abstände zwischen den Karten;
- Gesamtstromverbrauch;
- zulässige Stromkapazität des Racks;
- ob die Taktraten unter dauerhafter Last gehalten werden;
- Betrieb bei Ausfall eines Netzteils.
Spezialisierte Plattformen eignen sich besser für mehrere Beschleuniger in voller Baugröße. Die Reihen Dell PowerEdge der 16. Generation und Dell PowerEdge der 17. Generation enthalten Systeme unterschiedlicher Klassen, die Kompatibilität muss jedoch für das konkrete Gehäuse, den GPU-Typ und die thermische Verlustleistung geprüft werden.
Warum die Softwareumgebung ebenso wichtig ist wie die Hardware
Identische GPUs können aufgrund der Implementierung von Scheduler und Speicherverwaltung unterschiedliche Leistung liefern. Moderne Inferenzumgebungen verwenden:
- kontinuierliches Batching;
- seitenbasierte Zuweisung des KV-Caches;
- Caching gemeinsamer Präfixe;
- abschnittsweise Verarbeitung langer Kontexte;
- Quantisierung;
- Modellparallelität über mehrere GPUs;
- mehrere Replikate;
- spekulative Dekodierung;
- separate Warteschlangen für interaktive und Hintergrundaufgaben.
Diese Funktionen werden in der vLLM-Dokumentation beschrieben, doch jede Optimierung hat Einschränkungen. Das Caching gemeinsamer Präfixe ist nur bei wiederholten Präfixen nützlich. Große Batches steigern den Gesamtdurchsatz, können aber die Zeit bis zum ersten Token verschlechtern. Die Aufteilung des Modells erhöht die Kommunikation zwischen GPUs, während spekulative Dekodierung zusätzlichen Speicher benötigt. Die Einstellungen sollten anhand von Messungen der tatsächlichen Arbeitslast gewählt werden. (vLLM)
Most popular GPU
Konfiguration Schritt für Schritt berechnen
Zunächst werden das genaue Modell, das Gewichtsformat und die Attention-Architektur festgelegt. Danach:
- Die theoretische Größe der Gewichte berechnen und den tatsächlichen Verbrauch nach dem Laden messen.
- Median, 95. Perzentil und Grenzwert für Ein- und Ausgabe bestimmen.
- Den KV-Cache für die typische Spitzenlast und die anspruchsvollste zulässige Anfrage berechnen.
- Den Durchsatz der Eingabe- und Ausgabe-Token schätzen.
- Modellparallelität oder unabhängige Replikate auswählen.
- Das Ergebnis nach dem Aufwärmen mit einem Lasttest überprüfen.
Eingabe- und Ausgabedurchsatz werden separat berechnet:
Eingabe-Token/s = Anfragen/s × durchschnittliche Eingabelänge
Ausgabe-Token/s = Anfragen/s × durchschnittliche Antwortlänge
Eine lange Eingabe erhöht die Verarbeitungszeit des Kontexts und die Zeit bis zum ersten Token. Eine lange Antwort hält die Anfrage länger aktiv und erhöht die parallele Last.
Beispielberechnung für ein 70B-Modell
Ausgangsdaten:
- 70 Milliarden Parameter;
- 4-Bit-Gewichte;
- durchschnittliche Eingabe — 4.000 Token;
- 95. Perzentil — 8.000 Token;
- durchschnittliche Antwort — 300 Token;
- eine Anfrage pro Sekunde;
- etwa 20 aktive Sequenzen;
- der 16-Bit-KV-Cache aus dem obigen Beispiel.
Die Gewichte belegen theoretisch etwa 35 GB. Der KV-Cache für eine Sequenz mit 8.000 Token beträgt ungefähr 2,44 GiB, für zwanzig Sequenzen etwa 48,8 GiB. Die Summe überschreitet bereits 83 GB, ohne Quantisierungsmetadaten, Puffer und Reserve.
Eine einzelne GPU mit 80 GB kann diese Last beim 95. Perzentil nicht garantieren. Mehrere Lösungen sind möglich:
- ein Beschleuniger mit mehr Speicher;
- zwei miteinander verbundene GPUs;
- eine niedrigere Kontextgrenze;
- weniger aktive Sequenzen pro Replikat;
- ein separater Pool für lange Anfragen;
- mehrere Replikate mit Verteilung der Benutzer.
Der Durchsatz beträgt ungefähr 4.000 Eingabe-Token und 300 Ausgabe-Token pro Sekunde. Diese Werte definieren das Testprofil, sagen jedoch die Latenz einer bestimmten GPU nicht voraus: Sie muss mit dem ausgewählten Modell und der gewählten Softwareumgebung gemessen werden.
Konfigurationen für unterschiedliche Arbeitslasten
| Szenario | Hauptrisiko | Priorität |
|---|---|---|
| Interner Chatbot | Unnötig teurer, ungenutzter Server | Schnelles erstes Token, begrenzter Verlauf |
| RAG-System | Langer Kontext und Wachstum des KV-Caches | Auswahl der Abschnitte, RAM und NVMe |
| Produkt-API | Warteschlangen und instabile Latenz | Replikate, Grenzwerte, Redundanz |
| Batchverarbeitung | Die GPU wartet auf die Datenvorbereitung | Große Batches und schnelle Datenzufuhr |
| Mandantenfähige Plattform | Modelle konkurrieren um Speicher | Separate Pools, Quoten und Routing |
Interner Chatbot
Für einen kleinen Unternehmensassistenten kann eine einzelne GPU mit 24–48 GB ausreichen, wenn das Modell kompakt ist, der Gesprächsverlauf begrenzt wird und nur wenige Dialoge gleichzeitig aktiv sind. Ist eine Ausfallzeit nicht akzeptabel, wird auch dann ein zweites Replikat benötigt, wenn die Leistung eines einzigen ausreicht.
RAG-System
Der Kontext umfasst die Systemanweisung, die Frage, den Gesprächsverlauf und die abgerufenen Dokumente. Die Anzahl der Abschnitte sollte begrenzt und Filterung sowie Reranking eingesetzt werden. Vektordatenbank und Generierungsdienst müssen nicht auf demselben Knoten laufen, insbesondere wenn die Indexierung ressourcenintensiv ist.
Produkt-API
Skaliert werden Replikate mit gemessenem nutzbarem Durchsatz und nicht einfach „die Gesamtzahl der GPUs“. Für Kunden werden Grenzwerte für Eingabelänge, Ausgabelänge und Parallelität festgelegt. Updates ohne Ausfallzeit erfordern ein zusätzliches aufgewärmtes Replikat.
Batchverarbeitung
Hier ist eine höhere Latenz einzelner Aufgaben akzeptabel, sodass Batching aggressiver eingesetzt werden kann. CPU und NVMe-Speicher müssen die Daten schnell genug bereitstellen, damit die GPU ausgelastet bleibt. Die Hintergrundwarteschlange sollte von der interaktiven Warteschlange getrennt werden.
Mandantenfähige Plattform
Mehrere Modelle und Adapter konkurrieren um GPU-Speicher. Erforderlich sind separate Pools, Token- und Parallelitätsquoten, Routing nach Kontextlänge sowie für einen Knotenausfall reservierte Kapazität. Häufig ist es effizienter, mehrere unabhängige Replikate einzusetzen, als alle GPUs unter einem Modell zusammenzufassen.
Mehrere GPUs oder mehrere Server
Mehrere GPUs in einem Server werden gewählt, wenn das Modell nicht auf einen Beschleuniger passt oder eine einzelne große Instanz beschleunigt werden muss. Geprüft werden müssen die Verbindung zwischen den GPUs, die Unterstützung der gewählten Parallelitätsart, Stromversorgung und Kühlung.
Mehrere Replikate sind vorzuziehen, wenn das Modell auf eine GPU passt, aber mehr Benutzer bedient werden müssen. Diese Architektur lässt sich durch Hinzufügen eines weiteren Replikats leichter skalieren, ermöglicht Updates ohne vollständige Abschaltung und hält den Dienst bei Ausfall eines Beschleunigers verfügbar.
Ein einzelnes Modell sollte nur dann auf mehrere Server verteilt werden, wenn ein Server nicht genügend Ressourcen bereitstellen kann. Diese Architektur ist von einem schnellen internen Netzwerk abhängig und schwieriger zu betreiben; für kleine und mittelgroße Modelle ist sie nur selten die optimale Wahl.
Fehler bei der Berechnung
Konfigurationen werden meist unterschätzt, weil Teams:
- nur die Datei mit den Gewichten berücksichtigen;
- die durchschnittliche statt der Spitzenlast verwenden;
- den maximalen Kontext mit allen registrierten Benutzern multiplizieren;
- KV-Cache und Antwortlänge vergessen;
- Tests mit unterschiedlichen Eingaben vergleichen;
- nahezu den gesamten GPU-Speicher mit Gewichten belegen;
- annehmen, ein 4-Bit-Modell sei automatisch viermal schneller;
- RAG-Indexierung und interaktive API vermischen;
- PCIe-Topologie, Stromversorgung und Kühlung ignorieren;
- das System nur mit einer kurzen Anfrage testen;
- kein Standby-Replikat vorsehen.
Ein LLM-Inferenzserver sollte in folgender Reihenfolge ausgewählt werden: Arbeitslastprofil beschreiben, Gewichte und KV-Cache berechnen, Token-Durchsatz bestimmen, GPU-Architektur auswählen und erst danach CPU, RAM, NVMe-Speicher, Netzwerk und Gehäuse konfigurieren. Die Speicherberechnung beantwortet die Frage, ob die Arbeitslast hineinpasst. Nur ein Lasttest des konkreten Modells in der ausgewählten Softwareumgebung kann zeigen, ob die Ziele für Latenz und Benutzerkapazität erreicht werden.
Inhaltsverzeichnis:
