Hosting für KI-Anwendungen: CPU, GPU und Storage dimensionieren

Den KI-Workload zuerst eingrenzen

Die Hardwareauswahl beginnt mit der Aufgabe, nicht mit einer GPU. Bei der Inferenz verarbeitet ein vorhandenes Modell Eingaben und erzeugt beispielsweise Antworten. Fine-Tuning passt ein vortrainiertes Modell an zusätzliche Daten oder eine Aufgabe an; vollständiges Training baut die Modellgewichte dagegen im Rahmen eines eigenen Trainingslaufs auf.

Diese Ziele führen zu unterschiedlichen Lastprofilen: Ein Chatdienst muss auf Anfragen reagieren, während ein Trainingsjob über längere Zeit Daten verarbeitet und Zwischenstände speichert. Für AI Hosting solltest du deshalb festhalten, ob Antwortzeit, verarbeitete Anfragen, Trainingsdauer oder etwa die Kosten einer bestimmten Aufgabe im Vordergrund stehen.

Dokumentiere Modellversion und Laufzeit ebenso wie Parameterzahl, Architektur, Präzision und eine geplante Quantisierung. Notiere außerdem die erwarteten Eingabe- und Ausgabelängen, gleichzeitige Anfragen beziehungsweise Batchgrößen sowie die Spitzenlast. So lassen sich Angebote und spätere Tests anhand derselben Annahmen vergleichen, statt nur nominelle Hardwaredaten gegenüberzustellen.

Bei einem internen Chatassistenten kann eine einzelne kurze Anfrage problemlos laufen, während mehrere lange Unterhaltungen den Speicher überfordern. Der KV-Cache hält bei der Textgenerierung zusätzliche Zustände vor; sein Bedarf hängt unter anderem von Modell und Verarbeitung ab. Plane daher nicht nur für den durchschnittlichen Dialog, sondern auch für lange Kontexte und parallele Nutzung.

Halte auch fest, welche Daten verarbeitet werden, wo sie liegen dürfen und welche Verfügbarkeit sowie Wiederherstellungszeit benötigt werden. Diese Betriebsziele beeinflussen die Wahl zwischen einem einzelnen Server und einer aufwendigeren Architektur. Die Annahmen bleiben eine Ausgangsbasis: Ob sie tragen, zeigt erst eine Prüfung mit repräsentativer Last.

CPU und RAM in der Pipeline

Auch wenn ein Modell auf einer GPU läuft, arbeitet die CPU entlang des Datenpfads mit. Sie kann Anfragen entgegennehmen, Text tokenisieren, Dateien lesen und Eingaben für die Modellverarbeitung vorbereiten. Ist diese Vorbereitung zu langsam, wartet die GPU auf Arbeit; ein größerer Beschleuniger behebt den Engpass dann nicht zwangsläufig.

Der Arbeitsspeicher nimmt je nach Anwendung Modellbestandteile, vorbereitete Daten und Dateicaches auf. Hinzu kommt Speicher für Prozesse, die Trainingsdaten laden und umwandeln. Plane daher nicht nur das Modell selbst, sondern auch den Weg vom Datensatz bis zum fertigen Batch und ausreichend Reserven für Spitzen bei der Verarbeitung.

PyTorch-DataLoader können mehrere Worker zur parallelen Datenaufbereitung nutzen. Zusätzliche Worker beanspruchen jedoch ebenfalls Speicher; auch der gemeinsam genutzte Speicherbereich kann knapp werden. Erhöhe ihre Zahl deshalb schrittweise und beobachte Datenwartezeiten und Speicherbedarf, statt einen festen Wert als allgemeingültige Empfehlung zu übernehmen.

Mehr CPU-Kerne helfen vor allem dort, wo sich die anstehenden Aufgaben parallel ausführen lassen. Begrenzen dagegen Storage-Zugriffe, ein einzelner Verarbeitungsschritt oder die GPU selbst den Durchsatz, können zusätzliche Kerne wenig ändern. Auch das Taktverhalten kann für kurze Anfragen relevant sein; mehr Hintergrund dazu bietet der Artikel zum CPU Governor auf Hosting-Servern.

Für kleine Modelle oder seltene Anfragen ist CPU-Inferenz eine prüfenswerte Alternative zum dauerhaft bereitgestellten GPU-System. Vergleiche beide Varianten mit demselben Modell, passender Präzision und dem erwarteten Lastprofil. Entscheidend ist, ob die CPU die geforderte Antwortzeit auch bei Spitzen erreicht und welche Kosten dabei tatsächlich entstehen.

GPU und VRAM richtig verstehen

Bei einer vollständig GPU-residenten Inferenz müssen die Modellgewichte im verfügbaren GPU-Speicher untergebracht werden. Der VRAM-Bedarf endet dort aber nicht: Die Laufzeit benötigt weitere Bereiche für Zwischenergebnisse und temporäre Puffer. Eine Karte, auf die die Gewichte rechnerisch gerade passen, bietet deshalb noch keine sichere Grundlage für den produktiven Betrieb.

Bei autoregressiver Textgenerierung kommt der KV-Cache hinzu. Er speichert bereits berechnete Schlüssel- und Wertzustände, damit sie bei nachfolgenden Generierungsschritten erneut genutzt werden können. Lange Kontexte und gleichzeitig bearbeitete Anfragen können diesen zusätzlichen Speicherbedarf erhöhen; wie stark, hängt von Modell und Verarbeitung ab.

Die Dokumentation von Transformers 4.48.2 beschreibt unter anderem Cache-Quantisierung und Auslagerung als Möglichkeiten, VRAM zu sparen. Dabei hängt der Nutzen von Implementierung und Last ab; zusätzliche Verarbeitung oder Datentransfers können die Geschwindigkeit verringern. Prüfe daher Speicherverbrauch und Antwortzeit gemeinsam, statt eine Speicherersparnis automatisch als Leistungsgewinn zu behandeln.

Beim Training reicht die Inferenzrechnung erst recht nicht aus. Neben den Gewichten entstehen Speicherbedarf für Gradienten, Optimiererzustände und gespeicherte Aktivierungen. Wie groß diese Anteile ausfallen, hängt unter anderem vom Optimierer, der Präzision und dem Trainingsverfahren ab; längere Sequenzen oder größere Batches können insbesondere den Aktivierungsspeicher erhöhen.

Für eine vollständig GPU-residente Ausführung muss der verfügbare VRAM die benötigten Gewichte und Laufzeitdaten aufnehmen. Hybride Verfahren können Teile der Verarbeitung oder Modellgewichte außerhalb der GPU vorhalten; ihre Eignung und die Kosten von Datentransfers hängen von der Laufzeit ab. Das ist von der in Transformers 4.48.2 beschriebenen Auslagerung des KV-Caches zu unterscheiden.

Betrachte Modell, Laufzeit und geplante Parallelität gemeinsam und kontrolliere die Speicherhöchststände unter repräsentativer Last. Ausreichender Speicher für die gewählte Ausführungsweise ist noch kein Beleg für die gewünschte Antwortzeit oder Auslastung.

Modellspeicher überschlägig berechnen

Eine erste Speicherrechnung beginnt bei der Anzahl der Modellparameter und dem Format, in dem ihre Gewichte tatsächlich gespeichert werden. Sie liefert eine Untergrenze für diesen Speicheranteil, aber noch keine vollständige Dimensionierung des GPU-Servers. Insbesondere sagt sie nicht aus, wie viel Speicher eine konkrete Anfrage zur Laufzeit benötigt.

Illustratives Rechenbeispiel, keine Messung: Sieben Milliarden Parameter multipliziert mit zwei Byte ergeben 14 Milliarden Byte für die Gewichte. Geteilt durch 1.073.741.824 Byte pro GiB sind das rund 13,0 GiB. Voraussetzung ist, dass alle betrachteten Gewichte tatsächlich einheitlich mit zwei Byte pro Parameter vorliegen; andere Formate oder zusätzliche Repräsentationen verändern die Rechnung.

Nicht enthalten sind der KV-Cache für die Textgenerierung, temporäre Puffer und Laufzeit-Overhead. Gerade bei langen Kontexten kann der Cache erheblich wachsen; auch die Zahl gleichzeitig bearbeiteter Anfragen ist für die benötigte Reserve relevant. Die Cache-Dokumentation von Transformers 4.48.2 beschreibt außerdem Verfahren, die Speicher sparen können, aber je nach Verfahren Geschwindigkeit kosten.

Für Training reicht die Gewichtsrechnung erst recht nicht. Die Dokumentation zu Transformers 4.35.0 veranschlagt für eine beispielhafte Mixed-Precision-Konfiguration mit AdamW 18 Byte pro Parameter zuzüglich Aktivierungen. Darin spiegeln sich weitere Bestandteile wie Gradienten und Optimiererzustände; die Aktivierungen hängen unter anderem von Sequenzlänge und Batchgröße ab.

Die 18 Byte sind kein allgemeiner Multiplikator für jedes Training: Optimierer, Präzision und Trainingsverfahren können den Bedarf verändern. Weder aus dieser Zahl noch aus den 13,0 GiB folgt deshalb eine Empfehlung für eine bestimmte VRAM-Größe. Für die Auswahl sind die konkrete Laufzeit und die erwarteten Speicherhöchststände unter repräsentativer Last entscheidend.

Workloads und Engpässe vergleichen

Die gleichen Modellgewichte können je nach Aufgabe sehr unterschiedliche Anforderungen erzeugen. Die Tabelle zeigt mögliche Prüfstellen, keine Rangfolge und keine garantierten Engpässe. Welche Ressource tatsächlich begrenzt, hängt unter anderem von Modell, Datenpipeline, Parallelisierung und Last ab.

Bei einem internen Chatassistenten sind Modell und Generierung nur ein Teil der Planung. Lege eine maximale Eingabelänge, eine erwartete Ausgabelänge und die Zahl gleichzeitiger Nutzer fest. Anschließend lässt sich prüfen, ob die Antwortzeit bei Spitzenlast akzeptabel bleibt und ob Gewichte, Cache und Puffer gleichzeitig in den verfügbaren Speicher passen.

Eine Dokumentensuche mit generativer Antwort hat einen längeren Datenpfad: Dokumente werden importiert und aufbereitet, Embeddings erzeugt, ein Index durchsucht und relevante Inhalte an das Sprachmodell übergeben. Import und Suche können andere CPU-, RAM- und Storage-Anforderungen haben als die Generierung. Deshalb lohnt es sich, die Zeiten und Speicherbedarfe dieser Schritte getrennt zu erfassen.

Beim Fine-Tuning kann Gradient Accumulation eine größere effektive Batchgröße ermöglichen, obwohl nur kleinere Einzelbatches gleichzeitig verarbeitet werden. Die Gradienten mehrerer Schritte werden gesammelt, bevor die Parameter aktualisiert werden. Das kann bei begrenztem Speicher helfen, ist aber kein garantierter Durchsatzgewinn; zusätzliche Verarbeitungsschritte können Zeit kosten.

Auch die Datenzufuhr verdient einen eigenen Blick: Wenn Vorverarbeitung oder Laden hinter der Modellverarbeitung zurückbleiben, hilft eine größere GPU nicht unbedingt. Umgekehrt kann eine schnelle Datenpipeline einen zu kleinen VRAM nicht ersetzen. Vergleiche Alternativen daher mit denselben Eingaben und einem nachvollziehbaren Lastprofil.

Storage und GPU-Verbindungen planen

Für die Speicherplanung lohnt die Trennung nach Datenart und Zugriff: Trainingsdatensätze werden wiederholt gelesen, Modellgewichte vor der Nutzung geladen. Beide brauchen eine verlässliche Quelle, aus der sie nach einem Hostwechsel erneut bereitgestellt werden können. Kapazität allein genügt nicht; auch Ladezeit und Zugriffsmuster beeinflussen den Betrieb.

Temporäre Arbeitsdaten können auf lokalem NVMe liegen, wenn ein schneller Arbeitsbereich benötigt wird. Kläre beim Anbieter, ob diese Daten Neustarts und Hostwechsel überstehen. Checkpoints und Backups benötigen dagegen eine bewusst geplante Aufbewahrung und einen überprüften Wiederherstellungsweg; ein lokales Scratch-Verzeichnis ist nicht automatisch ein unabhängiges Backup.

Gemeinsam erreichbarer oder objektbasierter Storage kann das Verteilen und Aufbewahren von Datensätzen, Gewichten und Checkpoints erleichtern. Entscheidend ist, ob die Anwendung den gewählten Zugriff unterstützt und ob sich Daten innerhalb der vorgesehenen Zeit laden und wiederherstellen lassen. Ein zusätzlicher lokaler Arbeitsbereich kann sinnvoll sein, ersetzt aber die dauerhafte Ablage nicht.

GPUDirect Storage ermöglicht unter passenden Hardware-, Software- und Dateisystembedingungen einen direkteren Datenpfad zwischen Storage und GPU-Speicher. Das ist vor allem dann interessant, wenn Ein- und Ausgabe auf dem kritischen Pfad liegt und die Anwendung den unterstützten Pfad nutzt. Muss die CPU Daten zunächst dekodieren oder vorverarbeiten, kann das den Nutzen begrenzen.

Bei mehreren GPUs ist zwischen Replikation und Aufteilung zu unterscheiden. Replikation stellt Modellkopien bereit, um Anfragen zu verteilen; sie macht aus getrennten VRAM-Bereichen keinen automatisch gemeinsamen Speicher. Die Dokumentation zu vLLM 0.20.1 beschreibt eine solche Datenparallel-Bereitstellung; daraus folgt keine Aussage über jede andere Laufzeitversion.

Tensor- und Pipeline-Parallelismus verteilen dagegen Teile der Verarbeitung und erzeugen Kommunikationsbedarf. Prüfe dafür die Verbindungen zwischen GPUs sowie bei mehreren Servern die Netzwerktopologie und die Unterstützung durch Modell und Laufzeit. Die Dokumentation zu vLLM 0.8.5 behandelt diese Strategien für verteiltes Serving; ihre konkreten Hinweise sind versionsgebunden.

Engpässe unter Last erkennen

Ein aussagekräftiger Vergleich beginnt mit einem dokumentierten Lastprofil. Halte Modellversion, Präzision, konkrete Hardwarevariante und Version der Laufzeit fest. Ergänze typische und maximale Kontextlängen, Ausgabelängen sowie die Zahl gleichzeitiger Anfragen. So lässt sich eine spätere Änderung der Infrastruktur unter denselben Bedingungen prüfen.

Miss bei der Inferenz die Zeit bis zum ersten Token und die Generierungsgeschwindigkeit. Erfasse außerdem Fehler und Antwortzeiten bei gewöhnlicher Last und bei erwarteten Spitzen. Ein hoher durchschnittlicher Durchsatz genügt nicht, wenn einzelne Anfragen bei langen Kontexten oder hoher Parallelität zu lange warten oder scheitern.

Für Training und Fine-Tuning eignen sich Schritte oder verarbeitete Beispiele pro Zeiteinheit als Ausgangspunkt. Beobachte daneben, wie lange die Datenpipeline auf das nächste Batch warten lässt. PyTorch-DataLoader können mit mehreren Workern vorbereiten; deren Speicherbedarf und die Belastung des gemeinsam genutzten Speichers gehören ebenfalls in die Bewertung.

Erfasse Spitzen für GPU-Speicher und RAM sowie Storage-Auslastung und Wartezeiten. Auf einem vorhandenen NVIDIA-System zeigt der lesende Befehl nvidia-smi abhängig von Gerät und Treiber unter anderem GPU-Zustand und Speicherbelegung. Er verändert keine produktive Konfiguration, ersetzt aber keine Messung der Anwendung.

Eine niedrige GPU-Auslastung belegt für sich genommen weder ein CPU- noch ein Storage-Problem. Vergleiche sie zeitlich mit Datenwartezeiten, Anfrageverlauf und Speicherbelegung und ändere möglichst nur eine relevante Größe pro Vergleich. Dokumentiere auch die Grenzen des Tests, etwa wenn seltene Lastspitzen oder besonders lange Eingaben noch fehlen.

KI-Infrastruktur zuverlässig betreiben

Zur Betriebsplanung gehört eine überprüfbare Kombination aus GPU-Variante, Treiber, Framework und Modelllaufzeit. Kläre vor Updates, welche Versionen zusammen unterstützt werden und wie du bei Problemen zur vorherigen Kombination zurückkehrst. Bei speziellen Datenpfaden wie GPUDirect Storage müssen zusätzlich Hardware, Software und Dateisystem zum vorgesehenen Einsatz passen.

Lege fest, wer Modelle, Trainingsdaten, Protokolle und Verwaltungsoberflächen lesen oder verändern darf. Für sensible Eingaben sind außerdem Speicherort, Datenübertragung und Aufbewahrungsdauer mit den Datenschutzanforderungen abzugleichen. Prüfe diese Punkte für alle beteiligten Dienste, nicht nur für den Server, auf dem das Modell läuft.

Ein Checkpoint hält einen Trainingsstand für den späteren Wiederanlauf fest. Plane, welche Zustände deine Trainingssoftware dafür benötigt, wie häufig sie gespeichert werden und wie lange sie erhalten bleiben. Modellgewichte für die Auslieferung und Checkpoints für die Fortsetzung erfüllen unterschiedliche Zwecke und sollten entsprechend gekennzeichnet werden.

Lokaler Arbeits-Storage ist nicht automatisch dauerhaft und kein Ersatz für ein unabhängiges Backup. Frage beim Anbieter nach, was bei Neustart, Austausch des Hosts oder Vertragsende mit lokalen Daten geschieht. Bewahre benötigte Daten unabhängig vom Arbeitsbereich auf und prüfe die Wiederherstellung praktisch, einschließlich der Zeit bis zur erneuten Einsatzfähigkeit.

Bei verteilten Jobs umfasst Monitoring neben den einzelnen GPUs auch Knoten, Netzwerkverbindungen und den Fortschritt der gesamten Anwendung. Plane, von welchem gespeicherten Stand ein Job nach einem Ausfall neu startet und welche Ressourcen dafür verfügbar sein müssen. Wenn Modellteile über mehrere Server verteilt sind, beeinflussen deren Verbindungen auch den Betrieb; die Hinweise der vLLM-Dokumentation 0.8.5 sind dabei versionsgebunden.

Hostingmodell und GPU Server auswählen

Bei unregelmäßigen Jobs kann ein zeitweise bereitgestellter GPU Server sinnvoll sein: Du bezahlst nach den konkreten Angebotsbedingungen für die benötigte Bereitstellung, statt dauerhaft Kapazität vorzuhalten. Vergleiche dabei auch Startzeiten, Verfügbarkeit zum gewünschten Zeitpunkt sowie Kosten für gespeicherte Daten und Datenübertragung.

Bei gleichmäßiger Last lohnt die Gegenrechnung für dauerhaft reservierte Infrastruktur. Sie kann mehr Kontrolle über Laufzeit und Datenpfad bieten, verlangt aber eigene Planung für Updates, Überwachung und Wiederherstellung. Ein verwalteter Inferenzdienst übernimmt Teile dieses Betriebs; prüfe im Gegenzug, welche Modelle, Einstellungen und Datenpfade dort tatsächlich verfügbar sind.

Für die Auswahl der Machine Learning Infrastructure fordere Angaben zur konkreten GPU-Variante an: VRAM-Kapazität, Speicherbandbreite, unterstützte Rechenformate und Bauform. Übertrage keine Maximalwerte einer Produktfamilie ungeprüft auf jede Variante. Vergleiche Leistungsangaben nur mit ihren Testbedingungen und dem vorgesehenen Modell, statt allein nach einem theoretischen Spitzenwert zu entscheiden.

Auch die Skalierungsart gehört ins Angebot: Replizierte Instanzen können Anfragen verteilen, während eine Modellaufteilung Unterstützung durch Laufzeit und Verbindungstopologie voraussetzt. Die Dokumentation von vLLM behandelt Datenparallelität in Version 0.20.1 und verteiltes Serving in Version 0.8.5; diese Aussagen sollten nicht ohne Prüfung auf eine andere Version übertragen werden.

Grenze zuerst Modell und Lastprofil ein, schätze dann Speicher und Datenpfad ab und hole passende Angebote ein. Prüfe anschließend Antwortzeit, Fehler und Ressourcenbedarf mit repräsentativen Anfragen beziehungsweise Trainingsdaten. Weitere Aspekte zur Einordnung findest du beim GPU-Hosting für Webanwendungen. Eine allgemeingültige GPU-Empfehlung lässt sich ohne diesen Workload-Vergleich nicht ableiten.