GPU-Infrastruktur für lokale KI dimensionieren: Modell, Last und Betrieb zusammen planen
Von Kevin Kröger, Geschäftsführer, Software und PlattformbetriebDie passende GPU ergibt sich nicht allein aus der Zahl der Modellparameter. Entscheidend sind Zahlenformat und Quantisierung, Kontextlänge, parallele Anfragen, gewünschte Antwortzeit, Zusatzmodelle, Hochlauf, Ausfallszenario und tatsächliche Nutzungszeiten. Vor einer Beschaffung sollte ein repräsentativer Lasttest die benötigte Speicherreserve und den erreichbaren Durchsatz belegen.
Welche Aufgabe bestimmt die Infrastruktur?
Beginnt mit dem Nutzerweg: Wie lang sind Eingabe und Ausgabe, wie schnell muss die erste Antwort erscheinen, wie viele Personen arbeiten gleichzeitig und welche Fehlerfolge hat eine Verzögerung? Dokumentensuche, Stapelverarbeitung und interaktiver Assistent erzeugen unterschiedliche Lastprofile. Zusätzlich können Embedding, Bilderkennung, Spracherkennung oder Nachbewertung eigene Ressourcen benötigen. Erst diese Arbeitslast entscheidet, ob eine einzelne GPU, mehrere Karten oder ein zeitlich geteilter Aufbau sinnvoll ist.
Warum ist der Grafikspeicher so wichtig?
Modellgewichte, Zwischenergebnisse, Kontext und parallele Anfragen belegen Speicher. Eine theoretisch passende Modellgröße kann unter echter Parallelität nicht mehr stabil laufen. Quantisierung reduziert den Speicherbedarf, verändert aber je nach Verfahren Geschwindigkeit, Kompatibilität und möglicherweise Qualität. Die Dokumentation von Hugging Face zeigt, dass verschiedene Quantisierungsverfahren unterschiedliche Voraussetzungen und Laufzeiteigenschaften haben. Deshalb muss exakt die geplante Modellfassung mit der vorgesehenen Inferenzsoftware getestet werden.
Wie wird ein sinnvoller Lasttest aufgebaut?
Verwendet echte Längenverteilungen und nicht nur kurze Beispielprompts. Messt Zeit bis zum ersten Token, Ausgaberate, Gesamtdauer, Speicher, Energie, Fehler und Warteschlangen bei steigender Parallelität. Testet Normalbetrieb, Spitzenlast und eine längere Dauerphase. Wiederholt den Test mit den fachlich akzeptierten Modellvarianten. Ein guter Bericht zeigt nicht nur einen Maximalwert, sondern den Bereich, in dem Antwortzeit und Stabilität die vereinbarte Grenze einhalten.
Welche Reserve ist im Betrieb erforderlich?
Plant Platz für Sicherheitsupdates, neue Modellversionen, längere Kontexte und vorübergehende Doppelladung beim Wechsel. Klärt, ob eine Störung zu langsamerem Betrieb, Ausfall oder kontrolliertem Wechsel auf eine andere Plattform führen darf. Redundanz kann eine zweite GPU, einen zweiten Host oder einen bewusst eingeschränkten Ersatzprozess bedeuten. Die wirtschaftliche Lösung hängt von der akzeptierten Wiederanlaufzeit ab und muss Anwendung, Modell, Datenindex und Identität gemeinsam betrachten.
Wann sind Co-Hosting und Hybridbetrieb sinnvoll?
Eigene Hardware kann im Co-Hosting betrieben werden, wenn Investition und technische Kontrolle beim Unternehmen bleiben sollen, aber Strom, Netz, Zutritt und Überwachung professionell organisiert werden müssen. Ein hybrider Aufbau trennt vertrauliche oder stetige Last von seltenen Spezialaufgaben. Die Anwendung muss transparent entscheiden, welchen Weg sie nutzt. Ein externer Ersatz darf nicht unbemerkt Datenregeln umgehen. Betriebskosten, Energie, Bereitschaft und Erneuerung gehören in dieselbe Rechnung wie die Hardware.
Quellen und Grundlage
Zentrale Aussagen dieses Beitrags wurden anhand der folgenden Primärquellen geprüft.
Häufige Fragen
- Kann die GPU aus der Modellgröße berechnet werden?
- Nur grob. Quantisierung, Kontext, Parallelität, Inferenzsoftware und Zusatzmodelle verändern den tatsächlichen Speicherbedarf und Durchsatz erheblich.
- Ist eine größere GPU immer wirtschaftlicher?
- Nein. Ungenutzte Kapazität verursacht ebenfalls Kosten. Entscheidend sind reale Last, Wachstum, Reserve und die Kosten eines Engpasses.
- Muss lokale KI dauerhaft online sein?
- Das hängt vom Prozess ab. Für manche Aufgaben genügt ein geplanter Stapellauf, andere benötigen einen überwachten Dienst mit definiertem Wiederanlauf.
