LLM-Inferenz auf AWS betreiben: GPU-Autoscaling, RAG und Bedrock

Managed vs. Self-Hosted

Die erste Architekturentscheidung, die ich bei jedem LLM-Projekt treffe, ist die Frage, ob ich einen Managed Service nutze oder Inferenz selbst betreibe, nicht die Wahl des Modells. Bedrock gibt mir verwalteten Zugriff auf eine Reihe von Foundation-Modellen, ohne GPU-Kapazität, Patching oder Scaling-Logik selbst zu besitzen, und für die meisten Produkt-Use-Cases ist das der richtige Standard: Ich will keine Model-Serving-Infrastruktur betreiben, wenn eine verwaltete API die Anforderungen an Latenz und Kontrolle erfüllt. Zu containerisierten GPU-Services wechsle ich, wenn ich etwas brauche, das Bedrock nicht bietet: ein bestimmtes fein-getuntes oder Open-Weight-Modell, engere Kontrolle über Batching und Latenz, oder Datenresidenz-Anforderungen, die einen geteilten Managed Endpoint ausschließen. Das ist ein echtes Infrastruktur-Commitment, deshalb gehe ich es nur ein, wenn der Managed-Weg die Anforderung wirklich nicht erfüllen kann.

GPU-Workloads autoscalen

Selbst gehostete GPU-Inferenz muss auf das richtige Signal skalieren, und CPU-Auslastung ist das falsche. Ein GPU-gebundenes Modell kann bei niedriger CPU liegen, während der eigentliche Engpass, die GPU selbst, ausgelastet ist. Ich skaliere containerisierte Inferenz-Services stattdessen nach Queue-Tiefe und Request-Latenz, damit das System auf das reagiert, was tatsächlich degradiert. GPU-Instances haben zudem echte Cold-Start-Kosten: Das Laden von Modellgewichten auf eine frische Instance dauert spürbar länger als ein typischer Container-Start. Deshalb halte ich eine warme Mindestkapazität, dimensioniert auf die erwartete Grundlast, statt von null zu skalieren, und lasse Autoscaling die Lastspitzen darüber hinaus abfangen.

RAG als Architekturmuster

Retrieval-Augmented Generation ist der Bereich, in den ich die meiste Design-Zeit stecke, weil es weniger ein Feature als eine Architekturentscheidung darüber ist, wo Wissen liegt. Statt sich darauf zu verlassen, was ein Modell während des Trainings gelernt hat, holt eine RAG-Pipeline zur Anfragezeit relevanten Kontext aus einer Vektordatenbank und speist ihn zusammen mit der Nutzeranfrage in den Prompt ein. Der Retrieval-Schritt liegt im Request-Pfad vor der Generierung (Anfrage embedden, Vektordatenbank nach den nächstliegenden Treffern durchsuchen, diesen Kontext in den Prompt zusammenstellen), was bedeutet, dass Retrieval-Latenz und -Qualität die Qualität der finalen Antwort direkt begrenzen. Chunking- und Embedding-Strategie upstream richtig hinzubekommen, zählt mehr als jedes Prompt-Tuning downstream davon.

Kostenkontrolle von Anfang an

GPU-Kapazität ist teuer genug, dass Kosten von Beginn an eine Architekturfrage sein müssen, kein nachträglicher Aufräumdurchgang. Ich dimensioniere Instance-Typen nach dem tatsächlichen Speicher- und Durchsatzbedarf des Modells, statt standardmäßig zur größten verfügbaren GPU zu greifen, und route unterbrechungstolerante Arbeit (Batch-Embedding-Jobs, Offline-Evaluierung) auf Spot-Kapazität, während nur latenzsensitive Live-Inferenz auf On-Demand-Instances bleibt. Observability muss explizit Tokens und GPU-Auslastung abdecken, nicht nur Request-Anzahl und Antwortzeit, denn das sind die zwei Zahlen, die tatsächlich die Rechnung vorhersagen und verraten, ob die Kapazität richtig dimensioniert ist.

Kernaussagen

• Standardmäßig verwalteten Modellzugriff über Bedrock nutzen. Zu selbst gehostetem GPU-Serving nur wechseln, wenn Kontrolle nötig ist, die Bedrock nicht bietet.
• GPU-Inferenz nach Queue-Tiefe und Latenz skalieren, nicht nach CPU, und eine warme Mindestkapazität für Cold Starts vorhalten.
• RAG ist ein Architekturmuster. Retrieval-Qualität upstream begrenzt Generierungsqualität downstream.
• Token-Durchsatz und GPU-Auslastung explizit tracken, Spot-Kapazität für unterbrechungstolerante Batch-Arbeit nutzen.