LLM-Inferenz auf AWS: Bedrock oder eigene GPUs, RAG und Kostenkontrolle

Ein KI-Prototyp ist schnell gebaut. Schwierig wird der Schritt in den Produktivbetrieb: Welche Infrastruktur brauchen Sie, wie bindet das Modell Ihr eigenes Wissen ein, und warum wächst die GPU-Rechnung schneller als der Nutzen?

Das Wichtigste in Kürze

• Für die meisten Produkt-Use-Cases ist verwalteter Modellzugriff über Amazon Bedrock der richtige Standard.
• Eigene GPU-Infrastruktur lohnt sich erst, wenn Sie ein bestimmtes Modell, engere Kontrolle über Latenz oder eine Datenresidenz brauchen, die Bedrock nicht bietet.
• GPU-Inferenz skaliert nach Queue-Tiefe und Latenz statt nach CPU-Auslastung und braucht eine warme Mindestkapazität gegen Cold Starts.
• Bei RAG begrenzt die Qualität des Retrievals die Qualität jeder Antwort, deshalb zählen Chunking und Embeddings mehr als Prompt-Tuning.
• Token-Durchsatz und GPU-Auslastung sind die zwei Zahlen, die Ihre Rechnung vorhersagen.

Die erste Entscheidung: Managed Service oder selbst gehostet

Die erste Architekturentscheidung bei jedem LLM-Projekt betrifft bei mir nicht das Modell. Ich kläre zuerst, ob ich einen Managed Service nutze oder die Inferenz selbst betreibe.

Wann Bedrock reicht

Bedrock gibt mir verwalteten Zugriff auf eine Reihe von Foundation-Modellen, ohne dass ich GPU-Kapazität, Patching oder Scaling-Logik selbst besitze. 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.

Wann eigene GPU-Services sinnvoll sind

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,
• Anforderungen an die Datenresidenz, die einen geteilten Managed Endpoint ausschließen.

Das ist ein echtes Infrastruktur-Commitment. Ich gehe es deshalb nur ein, wenn der Managed-Weg die Anforderung nicht erfüllen kann.

GPU-Workloads richtig 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. So reagiert das System auf das, was tatsächlich schlechter wird.

Cold Starts abfedern

GPU-Instances haben zudem echte Cold-Start-Kosten. Das Laden der Modellgewichte auf eine frische Instance dauert spürbar länger als ein typischer Container-Start.

Ich halte deshalb eine warme Mindestkapazität vor, dimensioniert auf die erwartete Grundlast, statt von null zu skalieren. Autoscaling fängt die Lastspitzen darüber ab.

RAG: Wissen zur Laufzeit in den Prompt holen

In Retrieval-Augmented Generation stecke ich die meiste Design-Zeit. RAG ist weniger ein Feature als eine Architekturentscheidung darüber, wo Wissen liegt.

Statt sich darauf zu verlassen, was ein Modell im Training gelernt hat, holt eine RAG-Pipeline zur Anfragezeit relevanten Kontext aus einer Vektordatenbank. Diesen Kontext speist sie zusammen mit der Nutzeranfrage in den Prompt ein.

Der Retrieval-Schritt im Request-Pfad

Das Retrieval liegt im Request-Pfad vor der Generierung und besteht aus drei Schritten:

1. Die Anfrage embedden.
2. Die Vektordatenbank nach den nächstliegenden Treffern durchsuchen.
3. Diesen Kontext in den Prompt zusammenstellen.

Latenz und Qualität des Retrievals begrenzen damit direkt die Qualität der finalen Antwort. Chunking- und Embedding-Strategie upstream richtig hinzubekommen, zählt mehr als jedes Prompt-Tuning downstream.

Kostenkontrolle von Anfang an

GPU-Kapazität ist teuer genug, dass Kosten von Beginn an eine Architekturfrage sein müssen. Ein nachträglicher Aufräumdurchgang kommt zu spät.

Instance-Typen und Spot-Kapazität

Ich dimensioniere Instance-Typen nach dem tatsächlichen Speicher- und Durchsatzbedarf des Modells, statt standardmäßig zur größten verfügbaren GPU zu greifen. Unterbrechungstolerante Arbeit wie Batch-Embedding-Jobs und Offline-Evaluierung läuft auf Spot-Kapazität. Nur latenzsensitive Live-Inferenz bleibt auf On-Demand-Instances.

Die richtigen Metriken

Observability muss explizit Tokens und GPU-Auslastung abdecken, zusätzlich zu Request-Anzahl und Antwortzeit. Diese zwei Zahlen sagen die Rechnung voraus und zeigen, ob die Kapazität richtig dimensioniert ist.

Was das für Ihr Unternehmen heißt

Für den Einstieg müssen Sie in den meisten Fällen keine eigene GPU-Infrastruktur aufbauen. Mit Bedrock lässt sich ein produktiver KI-Anwendungsfall ohne eigenes Model-Serving umsetzen. Eigene GPUs kommen erst ins Spiel, wenn konkrete Anforderungen an Modell, Latenz oder Datenresidenz das verlangen, und dann mit einem klaren Blick auf die laufenden Kosten.

Über die Qualität der Antworten entscheiden dagegen Ihre Daten. Wie gut Dokumente aufbereitet, zerlegt und durchsuchbar gemacht werden, bestimmt, ob ein Assistent brauchbare oder falsche Antworten liefert. Planen Sie deshalb Zeit und Budget für die Aufbereitung Ihrer Daten ein, und zwar von Beginn an. Wenn Sie gerade überlegen, wie Sie ein LLM-Projekt auf AWS mit kalkulierbaren Kosten in den Betrieb bringen, schreiben Sie mir.