AWS Nova Micro für Text-to-SQL: Fine-Tuning + Serverless Bedrock für 0,80 Dollar pro Monat

Amazon Web Services veröffentlichte am 16. April 2026 eine detaillierte Fallstudie über den Aufbau eines Text-to-SQL-Systems mit Nova Micro mit LoRA-Fine-Tuning und Bedrock On-Demand-Inference. Die Autoren Zeek Granston und Felipe Lopez präsentieren zwei parallele Implementierungen — eine über Amazon Bedrock Customization und eine über SageMaker AI — und liefern eine klare Kostenaufstellung für jeden Ansatz.

Warum LoRA + Serverless?

Der traditionelle selbst gehostete Ansatz für benutzerdefinierte SQL-Generierung erfordert ständige Infrastruktur — GPU-Instanzen, die unabhängig von der Nutzung rund um die Uhr laufen. Für interne BI-Tools, bei denen SQL gelegentlich generiert wird, ist das eine massive Ressourcenverschwendung.

Low-Rank Adaptation (LoRA) ermöglicht das Fine-Tuning einer kleinen zusätzlichen Parameterschicht auf dem Basismodell. In Kombination mit serverloser Inference zahlen Sie nur pro Token — keine Fixkosten, wenn das System im Leerlauf ist. AWS beschreibt diesen Ansatz als “benutzerdefiniertes Text-to-SQL ohne die Kosten des kontinuierlichen Modell-Hostings”.

Konkrete Kosten

Der Beitrag liefert eine präzise wirtschaftliche Analyse, die in AWS-Technologiematerialien selten ist:

Einmalige Trainingskosten:

• Bedrock Customization: 8,00 Dollar (2.000 Beispiele, 5 Epochen)
• SageMaker AI: 65,15 Dollar (4-Stunden-Auftrag auf ml.g5.48xlarge)

Monatlicher Produktions-Workload von 22.000 Abfragen:

• Eingabekosten: 0,616 Dollar
• Ausgabekosten: 0,184 Dollar
• Gesamt monatlich: 0,80 Dollar

Der Unterschied ist dramatisch im Vergleich zu jedem Selbst-Hosting-Szenario, bei dem allein eine GPU-Instanz mehrere Hundert Dollar pro Monat kosten würde, unabhängig von der Anzahl der Abfragen.

Technische Hyperparameter

Die Autoren teilen die konkrete Konfiguration, die über Bedrock funktioniert hat:

• Anzahl der Epochen: 5
• Lernrate: 0,00001
• Warmup-Schritte: 10
• Trainingsdauer: 2–3 Stunden

Die Trainingsdaten stammten aus dem öffentlichen sql-create-context-Datensatz mit mehr als 78.000 Paaren aus natürlicher Sprache und SQL-Abfragen. Die Trainings- und Validierungsverlust-Kurven sinken konsistent und konvergieren — ein Indikator für stabiles Fine-Tuning ohne Überanpassung.

Der Latenz-Preis

Nichts ist umsonst. Der LoRA-Adapter fügt bei der Inference Overhead hinzu:

• Cold-Start-TTFT (Time-to-First-Token): 639 ms (34 % über dem Basismodell)
• Warm-Start-TTFT: 380 ms (7 % darüber)
• Token-Generierungsrate: ~183 Token/Sekunde (27 % unter dem Basismodell)
• End-to-End-Antwort: ~477 ms

AWS beschreibt diese Latenz als “für interaktive Anwendungen nach wie vor sehr geeignet” — eine Beschreibung, die sorgfältig interpretiert werden sollte. Für eine Benutzeroberfläche, bei der SQL während der Eingabe des Benutzers generiert wird, ist eine zusätzliche Latenz von ~30 Prozent akzeptabel. Bei einem Batch-Prozess, der Hunderte von Abfragen auf einmal generiert, kann der kumulative Overhead erheblich sein.

Wann dieser Ansatz geeignet ist

AWS zielt explizit auf variable Workloads ab, bei denen Kosten Vorrang vor absoluter Geschwindigkeit haben. Typische Szenarien umfassen interne BI-Tools in Unternehmen, Chat-Assistenten für Legacy-Datenbanken und Analyse-Tools, die gelegentlich statt kontinuierlich genutzt werden. Für Systeme mit hohem und vorhersehbarem Volumen ist dediziertes Hosting nach wie vor wirtschaftlicher.