Performance-Optimierung
In KI-Systemen bestimmen Antwortzeit, Durchsatz und Betriebskosten, ob ein System im Alltag nutzbar ist. Die systematische Arbeit an diesen drei Größen heißt Performance-Optimierung.
Warum Geschwindigkeit und Kosten zusammenhängen
Ein KI-System, das pro Anfrage drei Sekunden braucht, wird anders genutzt als eines, das in 200 Millisekunden antwortet. Ein System, das pro Anfrage zwei Cent kostet, skaliert anders als eines, das 20 Cent kostet. In beiden Fällen beeinflusst die technische Leistung direkt, ob und wie das System eingesetzt werden kann.
Bei KI-Anwendungen entstehen diese Kosten an spezifischen Stellen: beim Berechnen von Vektoren durch ein Einbettungsmodell, beim Durchsuchen einer Vektordatenbank, beim Generieren von Text durch ein Sprachmodell. Jeder dieser Schritte verbraucht Rechenzeit, Arbeitsspeicher und häufig GPU-Kapazität.
Beispiel: Ein RAG-System für internen Kundensupport beantwortet 500 Anfragen pro Tag. Jede Anfrage erfordert eine Vektorsuche (20 ms), ein Reranking (50 ms) und eine Textgenerierung (800 ms). Die Gesamtlatenz beträgt rund 900 ms pro Anfrage. Davon entfallen über 90 % auf die Textgenerierung.
Beispiel: Ein Indexierungsjob verarbeitet 100.000 Dokumente mit einem Einbettungsmodell. Bei 50 ms pro Dokument dauert der Durchlauf 83 Minuten. Bei 5 ms pro Dokument (nach Optimierung durch Batching) nur noch 8 Minuten.
Wo die Engpässe liegen
Bevor optimiert werden kann, muss der Engpass identifiziert sein. In typischen KI-Pipelines gibt es vier Stellen, an denen Leistung verloren geht.
- Embedding-Berechnung: Bestimmt, wie schnell neue Dokumente indexiert und Anfragen in Vektoren umgewandelt werden. Große Modelle liefern bessere Vektoren, brauchen aber mehr Rechenzeit.
- Vektorsuche: In kleinen Datenbanken vernachlässigbar. Bei Millionen von Vektoren wird die Suchstrategie (exakt vs. approximativ) zum entscheidenden Faktor.
- Inference / Textgenerierung: Bei Sprachmodellen häufig der größte Anteil an der Gesamtlatenz. Hängt von Modellgröße, Eingabelänge und gewünschter Ausgabelänge ab.
- I/O und Netzwerk: Datenbankabfragen, API-Aufrufe an externe Dienste, Festplattenzugriffe. Oft unterschätzt, besonders bei verteilten Systemen.
Beispiel: Ein Profiling zeigt, dass 70 % der Latenz auf die Textgenerierung entfallen, 20 % auf die Vektorsuche und 10 % auf Netzwerk-Overhead. Eine Optimierung der Vektorsuche bringt in diesem Fall wenig. Der größte Hebel liegt bei der Inference.
Methoden der Optimierung
Je nach Engpass kommen unterschiedliche Methoden zum Einsatz.
Caching
Wenn dieselbe Anfrage oder ähnliche Anfragen wiederholt auftreten, kann das Ergebnis zwischengespeichert werden. Statt die gesamte Pipeline erneut zu durchlaufen, wird das gespeicherte Ergebnis zurückgegeben.
Beispiel: In einem FAQ-System stellen 40 % der Nutzer eine von 20 häufigen Fragen. Ein Cache für diese Antworten reduziert die Gesamtlast um fast die Hälfte, ohne die Pipeline für neue Fragen zu verändern.
Batching
Statt Anfragen einzeln zu verarbeiten, werden mehrere Anfragen zu einem Paket zusammengefasst und gemeinsam an das Modell übergeben. GPUs sind für parallele Verarbeitung ausgelegt und nutzen ihre Kapazität bei Einzelanfragen nur teilweise aus.
Beispiel: Ein Indexierungsjob verarbeitet 10.000 Dokumente. Mit Einzelverarbeitung dauert das 50 Minuten. Mit Batches von 64 Dokumenten sinkt die Zeit auf 12 Minuten, weil die GPU bei jedem Batch besser ausgelastet ist.
Quantisierung
Die Gewichte eines Modells werden standardmäßig als 32-Bit-Gleitkommazahlen gespeichert. Bei der Quantisierung werden diese auf 16, 8 oder sogar 4 Bit reduziert. Das verkleinert das Modell, senkt den Speicherbedarf und beschleunigt die Berechnung.
Beispiel: Ein 7-Milliarden-Parameter-Modell benötigt in FP32 rund 28 GB Speicher. In INT8-Quantisierung sinkt der Bedarf auf 7 GB. Das Modell läuft damit auf einer einzelnen Consumer-GPU statt auf teurer Server-Hardware. Der Qualitätsverlust ist aufgabenabhängig und muss im Einzelfall gemessen werden.
Approximative Suche
Bei der Vektorsuche über große Datenmengen wird häufig nicht exakt gesucht, sondern annäherungsweise. Verfahren wie HNSW oder IVF opfern minimale Genauigkeit für deutlich höhere Geschwindigkeit.
Beispiel: Eine Vektordatenbank mit 10 Millionen Einträgen. Exakte Suche dauert 200 ms. Mit HNSW-Index dauert dieselbe Suche 5 ms bei einem Recall von 98 %. Die verbleibenden 2 % sind in den meisten Anwendungsfällen tolerierbar.
Der Optimierungsprozess
Optimierung ohne Messung ist Raten. Der Prozess folgt einem festen Ablauf.
Beispiel: Ein Team stellt fest, dass die Antwortzeit ihres RAG-Systems bei 2,5 Sekunden liegt. Profiling zeigt: 1,8 Sekunden entfallen auf die Textgenerierung, 0,5 Sekunden auf die Vektorsuche, 0,2 Sekunden auf Netzwerk. Das Team quantisiert das Sprachmodell von FP16 auf INT8. Die Generierungszeit sinkt auf 0,9 Sekunden. Die neue Gesamtlatenz beträgt 1,6 Sekunden. Ein zweiter Durchlauf zeigt, dass der nächste Hebel bei der Vektorsuche liegt.
Kompromisse
Jede Optimierung hat einen Preis. Die Kunst liegt darin, den richtigen Kompromiss für den jeweiligen Einsatzzweck zu finden.
- Geschwindigkeit vs. Qualität: Quantisierung beschleunigt, kann aber die Ausgabequalität verschlechtern. Approximative Suche ist schneller, findet aber nicht immer den besten Treffer.
- Latenz vs. Durchsatz: Batching erhöht den Durchsatz, kann aber die Latenz für einzelne Anfragen erhöhen, weil eine Anfrage auf das volle Batch warten muss.
- Kosten vs. Latenz: Leistungsfähigere Hardware senkt die Latenz, erhöht aber die Betriebskosten. Caching spart Kosten, erfordert aber zusätzliche Infrastruktur.
Beispiel: Ein Chatbot für Endkunden braucht niedrige Latenz (unter 1 Sekunde), weil Nutzer sofortige Antworten erwarten. Ein Batch-Job, der nachts 50.000 Dokumente zusammenfasst, braucht hohen Durchsatz, aber keine niedrige Latenz. Beide Systeme nutzen dasselbe Sprachmodell, erfordern aber unterschiedliche Optimierungsstrategien.
Beispiel: Ein Team setzt INT4-Quantisierung ein, um die Kosten zu halbieren. Bei Zusammenfassungen funktioniert das gut. Bei Code-Generierung treten vermehrt Fehler auf. Die Lösung: INT8 für Code-Aufgaben, INT4 für Textaufgaben. Verschiedene Aufgaben können verschiedene Optimierungsstufen vertragen.
Grenzen der Optimierung
Optimierung verbessert die Nutzung vorhandener Ressourcen. Sie ändert nicht, was das System grundsätzlich leisten kann.
- Modellqualität: Ein schwaches Modell liefert auch nach Optimierung schwache Ergebnisse. Schneller falsch ist nicht besser als langsam falsch.
- Architekturgrenze: Wenn die Pipeline selbst falsch entworfen ist (etwa ein zu kleines Kontextfenster oder fehlende Retrievalkomponente), hilft Optimierung an den Einzelschritten wenig.
- Diminishing Returns: Die erste Optimierungsrunde bringt häufig 50 bis 80 % Verbesserung. Jede weitere Runde bringt weniger. Irgendwann übersteigt der Aufwand den Nutzen.
Beispiel: Ein Team hat die Latenz von 3 Sekunden auf 1,2 Sekunden gesenkt. Die nächste Optimierungsrunde würde 0,1 Sekunden bringen, erfordert aber zwei Wochen Arbeit und eine neue Infrastrukturkomponente. Ob sich das lohnt, hängt vom Einsatzkontext ab, nicht von der technischen Machbarkeit.
Fachliche Einordnung: Wenn Optimierung an ihre Grenzen stößt, bleiben drei Hebel: bessere Hardware (mehr GPUs, schnellerer Speicher), bessere Modelle (ein neueres, effizienteres Modell einsetzen) oder Architekturänderungen (etwa asynchrone Verarbeitung, Streaming-Ausgabe oder eine mehrstufige Pipeline mit leichtem Vorfilter und schwerem Hauptmodell).