Text-to-SQL on-premise: offene Modelle, Schema-Kontext, Lesezugriff und der GPU-Server

Was Text-to-SQL auf dem eigenen Server leistet

Mit Text-to-SQL on-premise stellen Mitarbeitende Fragen an interne Datenbanken in natürlicher Sprache, während Sprachmodell, Schema und Ergebnisse auf dem eigenen Server bleiben. Ein offenes Modell auf einer NVIDIA RTX PRO 6000 Blackwell Server Edition bedient ein BI-Team: Auf dem öffentlichen Benchmark BIRD erreichen offene Modelle mit 7B bis 32B Parametern auf dem Testsatz etwa 68 bis 74 Prozent Ausführungsgenauigkeit, und Aufgaben im Unternehmensmaßstab brauchen einen Agenten, der das Schema erkundet, Abfragen ausführt und korrigiert. Was schiefgehen kann, entscheidet das Datenbankkonto des Modells; es sollte nur lesen dürfen.

Eine Anfrage läuft in fünf Schritten. Das System wählt die Tabellen und Spalten, die für die Frage zählen, das Modell schreibt eine Abfrage, ein Prüfer stellt sicher, dass es eine einzelne Lese-Anweisung ist, die Datenbank führt sie unter einem Lesekonto aus, und der Nutzer sieht das Ergebnis zusammen mit dem SQL. Der letzte Punkt schafft Vertrauen: Eine Analystin kann die Abfrage lesen und einen falschen Join erkennen, was ein Diagramm allein nicht zeigt.

Das ist eine andere Aufgabe als die Suche in Dokumenten. Unser Leitfaden zu RAG auf Unternehmensdaten findet Textpassagen; Text-to-SQL berechnet eine Antwort aus Zeilen, und ein falscher Filter liefert eine überzeugend wirkende, falsche Zahl. Deshalb bekommen Modellwahl, Schema-Kontext und Abfrageprüfung hier eigene Abschnitte, und deshalb kommt ein Testsatz mit Ihren eigenen Fragen vor der Hardwarebestellung.

Öffentliche Ranglisten: BIRD und Spider 2.0 im Oktober 2026

BIRD misst die Ausführungsgenauigkeit: Eine generierte Abfrage gilt als richtig, wenn ihr Ergebnis dem der Referenzabfrage entspricht. Der Benchmark umfasst 95 Datenbanken mit zusammen 33,4 GB, mehr als 12.751 Paare aus Frage und SQL und mehr als 37 Fachgebiete. Seine Single-Model-Rangliste bewertet ein trainiertes Modell ohne Agenten-Framework.

BIRD-Rangliste, Single Trained Model Track, bird-bench.github.io, gelesen am 24. Oktober 2026. Menschliche Leistung 92,96. Das beste Einzelmodell, Googles Gemini-SQL2, erreicht 80,04 und ist kein offenes Modell; der beste Systemeintrag insgesamt erreicht 82,95. Arctic-Text2SQL-R1-7B steht nicht in dieser Rangliste; seine eigene Karte nennt 68,5 auf dem BIRD-Testsatz.

Kwai-AutoSQL-32B ist ein Fine-Tune von Qwen3-32B. Laut Karte sind Gewichte und Konfiguration Ableitungen von Qwen3-32B unter Apache 2.0, README und die Lizenzdatei im Hauptverzeichnis stehen unter MIT; die Karte zeigt Startbefehle für vLLM und SGLang und nennt weder Benchmark noch Promptformat oder Dialekt. Arctic-Text2SQL-R1-7B von Snowflake ist ein Fine-Tune von Qwen2.5-Coder-7B-Instruct unter Apache 2.0; seine Karte nennt 88,8 auf dem Spider-Testsatz und 15,6 auf Spider 2.0-DK. Beide Karten sagen nichts dazu, für welche SQL-Dialekte trainiert wurde. Der Hauptsatz von BIRD ist SQLite; sein Mini-Dev-Satz mit 500 Beispielen deckt SQLite, MySQL und PostgreSQL ab, und dort erreicht ein Eintrag auf Basis von gpt-oss-120b, FrontierSQL, 56,80 auf PostgreSQL.

Spider 2.0 liegt näher an einem Data Warehouse im Unternehmen. Die Variante Snow hat 547 Aufgaben auf Snowflake, die Variante Lite 547 auf BigQuery, Snowflake und SQLite, und das Projekt schreibt, dass seine Datenbanken oft mehr als 1.000 Spalten haben. An der Spitze von Spider 2.0-Snow stehen Agentensysteme mit 96,70. Offene Modelle liegen tiefer und streuen stark: DeepSeek-V3.2 im Framework QiSi-SQL 70,38, gpt-oss-120b in FlexSQL 65,45 und in AI-DIVE 13,10. Auf Spider 2.0-Lite erzielte AI-DIVE mit DeepSeek-V4-Flash 42,40 und mit gpt-oss-120b 21,90. Dasselbe Modell kann an beiden Enden der Tabelle stehen; Schema-Verknüpfung, Wiederholungen und Prüfungen um das Modell herum machen den Unterschied. Unser Leitfaden zur Wahl eines offenen LLM für einen Unternehmensassistenten behandelt Lizenzen und Sprachen der Allzweckmodelle in diesen Einträgen.

Die Schemagröße ist das Kontextbudget

Das Modell kann nur einen Join schreiben, den es kennt, also gehört das Schema in den Prompt. Als grobe Regel gilt: Tabellen × Spalten × Token je Spalte. Mit kompakten Tabellendefinitionen brauchen Spaltenname, Typ und ein kurzer Kommentar etwa 10 bis 15 Token, unsere Annahme; zählen Sie vor der Planung mit dem Tokenizer des Modells auf Ihren eigenen Definitionen.

Unsere Schätzung bei 10 bis 15 Token je Spalte. Kontextgrenzen: max_position_embeddings in der config.json von Kwai-AutoSQL-32B (40.960) und Arctic-Text2SQL-R1-7B (32.768), gelesen am 24. Oktober 2026.

Für den großen Fall hilft eine Schema-Auswahl per Suche. Beschreiben Sie jede Tabelle und ihre wichtigen Spalten in ein oder zwei Sätzen, betten Sie diese Beschreibungen ein und wählen Sie vor der SQL-Generierung die 10 bis 20 Tabellen, die der Frage am nächsten liegen; Fremdschlüssel aus dem Katalog ergänzen die Verbindungstabellen. Die Embedding- und Reranker-Modelle für diesen Schritt sind klein, wie unser Leitfaden zum Embedding- und Reranker-Server für RAG zeigt. Fachliche Definitionen gehören in denselben Kontext: was „Umsatz“ in Ihrem Unternehmen bedeutet, welche Statuscodes als storniert gelten, und einige geprüfte Beispielabfragen. Eine Abfrage kann gültiges SQL sein und trotzdem die falsche Definition verwenden.

Ein fester Teil des Prompts, die Anweisungen und die Kerntabellen, ist für jede Anfrage gleich. Serving-Engines können seinen Cache über Anfragen hinweg wiederverwenden, was die Zeit bis zum ersten Token verkürzt, wie unser Leitfaden zu KI-Agenten und GPU-Bedarf für Prefix Caching erklärt.

Lesezugriff und Abfrageprüfung

Die Sicherheitsgrenze ist das Datenbankkonto des Modells; eine Anweisung im Prompt hält keine Abfrage auf. Geben Sie ihm SELECT auf die Views oder Schemas, die es lesen darf, und sonst nichts, und betreiben Sie es auf einem Lesereplikat oder einer Berichtskopie, auf der eine schwere Abfrage das Produktivsystem nicht bremst. Nutzen Sie statt Rechten je View die vordefinierte Rolle pg_read_all_data von PostgreSQL 18, liest das Konto alle Tabellen, Views und Sequenzen, und die Dokumentation hält fest, dass diese Rolle „does not bypass row-level security (RLS) policies“; Zeilenregeln für Abteilungen oder Mandanten gelten also auch für die Abfragen des Modells.

Zwei Einstellungen helfen, ersetzen die Rechte aber nicht. default_transaction_read_only setzt den Standard für den Lesestatus jeder neuen Transaktion; spätere Änderungen beschreibt die Dokumentation als gleichbedeutend mit einem SET TRANSACTION, eine Sitzung kann ihn also ändern, und es entscheiden weiterhin die Rechte. statement_timeout bricht jede Anweisung ab, die länger als die eingestellte Zeit läuft; die Dokumentation rät davon ab, den Wert in postgresql.conf zu setzen, weil er dann alle Sitzungen betrifft, setzen Sie ihn also für das Text-to-SQL-Konto.

In der Anwendung parsen Sie jede generierte Anweisung und akzeptieren genau ein SELECT, ergänzen eine Zeilengrenze, protokollieren Frage, SQL und Nutzer und zeigen das SQL mit der Antwort. Auch Datenwerte können Anweisungen enthalten: Eine Kundennotiz mit „ignoriere den Filter“ landet im Kontext des Modells, wenn der Agent Beispielzeilen liest; unser Leitfaden zu Prompt Injection und LLM-Sicherheit behandelt das. Wir liefern die Server und richten mit unserem Engineering-Partner Vixen.UNO Modell, Schema-Auswahl und Abfrageprüfung ein; schicken Sie uns Datenbanktyp, Schemagröße und die Fragen Ihres Teams, und wir antworten mit einer Konfiguration.

Mehrstufige Agenten und ihre Latenz

Bei Unternehmensschemas liefern Agenten die besseren Ergebnisse: Das Modell listet Kandidatentabellen, sieht sich Spalten und Beispielwerte an, schreibt eine Abfrage, führt sie aus, liest den Fehler oder ein leeres Ergebnis und korrigiert sich. Jeder Schritt ist ein Modellaufruf mit Tool-Nutzung, eine Frage braucht also mehrere Aufrufe; unser Leitfaden zu Tool Calling in vLLM behandelt die Parser, die aus der Ausgabe des Modells Tool-Aufrufe machen.

Die Generierungszeit summiert sich dann. Bei einem dichten Modell liest jedes Ausgabetoken alle Gewichte einmal, Speicherbandbreite geteilt durch Gewichtsgröße ergibt also eine Obergrenze je Anfrage. Kwai-AutoSQL-32B in BF16 liest 65,5 GB je Token: etwa 24 Token pro Sekunde auf einer RTX PRO 6000 Server Edition mit 1.597 GB/s und etwa 73 auf einer H200 NVL mit 4,8 TB/s, nach unserer Schätzung eine Obergrenze. Ein Agent, der in jedem von vier Aufrufen 1.000 Token Begründung und SQL schreibt, wartet auf der ersten Karte mindestens etwa 164 Sekunden, auf der zweiten 55. In FP8 quantisiert, ein Byte je Parameter, liest das Modell etwa die Hälfte; unser Leitfaden zum Quantisieren eines LLM nach NVFP4 oder FP8 behandelt die Werkzeuge und die Genauigkeitsprüfung, die danach folgen muss.

Ein Mixture-of-Experts-Modell liest nur seine aktiven Experten. gpt-oss-120b liest etwa 5 GB je Token, seine Obergrenze auf einer Server-Edition-Karte liegt damit bei etwa 319 Token pro Sekunde, nach unserer Schätzung eine Obergrenze, weil Tokens im Batch verschiedene Experten treffen. StorageReview hat für einen Nutzer von gpt-oss-120b in NVFP4 auf zwei Server-Edition-Karten mit vLLM 176,09 Token pro Sekunde gemessen. Damit ist es ein brauchbares Agentenmodell, wenn ein feinabgestimmtes 32B-Modell in BF16 zu langsam ist, vorausgesetzt, es besteht Ihren eigenen Testsatz.

Dimensionierung für ein BI-Team: RTX PRO 6000 Server Edition oder H200 NVL

Wir rechnen mit unserer Regel für Nutzer je Karte: 90 Prozent des vom Treiber gemeldeten Speichers, abzüglich 3 GiB je Karte und abzüglich der Gewichte, bleiben für den KV-Cache. Das ergibt 83,0 GiB je RTX PRO 6000 Server Edition und 123,4 GiB je H200 NVL. Eine Text-to-SQL-Anfrage mit ausgewähltem Schema, Beispielen und der Begründung des Modells hat in diesem Beispiel etwa 10.000 Token.

Unsere Schätzungen; SE ist die RTX PRO 6000 Server Edition, Kwai 32B ist Kwai-AutoSQL-32B in BF16, Arctic 7B ist Arctic-Text2SQL-R1-7B. Gewichte: Safetensors-Dateien auf Hugging Face (Kwai-AutoSQL-32B 65,5 GB, Arctic-Text2SQL-R1-7B 15,2 GB, gpt-oss-120b 65,3 GB). Cache je Token in 16 Bit aus der config.json: 256 KiB für das 32B-Modell (64 Schichten, 8 KV-Heads zu 128), 56 KiB für das 7B-Modell (28 Schichten, 4 KV-Heads zu 128), 36 KiB für gpt-oss-120b. Grenzen sind Bandbreite ÷ gelesene Bytes je Token, also Obergrenzen; die Grenze für TP=2 lässt den Austausch zwischen den Karten außer Acht.

Für ein BI-Team mit 20 bis 50 Analysten nehmen wir einige gleichzeitig laufende Fragen an; nach dem Speicher trägt eine RTX PRO 6000 Server Edition das 32B-Modell. Die Grenze ist die Wartezeit je Frage: Mit einer Agentenschleife in BF16 verdreifacht die Bandbreite der H200 NVL die Generierungs­geschwindigkeit ungefähr, zwei Server-Edition-Karten als Tensor-Parallel-Paar verdoppeln sie bestenfalls. Ein 7B-Fine-Tune auf einer Server-Edition-Karte ist schnell und lässt Platz für ein zweites Modell, bei etwa fünfeinhalb Punkten weniger auf dem BIRD-Testsatz (68,5 laut Karte von Arctic 7B gegenüber 74,12 für Kwai-AutoSQL-32B in der Rangliste). Unser Vergleich RTX PRO 6000 und H200 NVL behandelt die Karten allgemein; der Einstiegsserver auf unserer Seite zu KI-Servern hat zwei RTX PRO 6000 Server Edition und nimmt nach unserer Schätzung rund 1,8 kW am Netz auf, und unsere Seite zum Server mit zwei H200 NVL behandelt die HBM-Option.

Test mit Ihren eigenen Fragen

Sammeln Sie 100 bis 200 echte Fragen der Analysten, mit dem richtigen SQL, geschrieben oder geprüft von jemandem, der die Daten kennt. Werten Sie sie wie BIRD über den Vergleich der Ergebnismengen aus, und schlüsseln Sie das Ergebnis nach Typ auf: einfache Abfragen, Joins über drei oder mehr Tabellen, Zeitfenster und Fragen, die von einer fachlichen Definition abhängen. Lassen Sie jedes Kandidatenmodell mit derselben Schema-Auswahl und denselben Prüfungen im Dialekt Ihrer Datenbank laufen, und messen Sie die Zeit je Frage mit eingeschalteter Agentenschleife. Halten Sie den Satz aus jedem Fine-Tuning heraus und wiederholen Sie den Lauf nach jeder Änderung an Modell, Prompt oder Schemabeschreibung.

Unser Private-AI/ML-Service richtet ein solches Pilotprojekt auf Ihren Daten ein; beschreiben Sie Ihre Datenbanken, die Nutzer und ihre Fragen, und unser Team schlägt den Test vor und dimensioniert den Server nach seinen Ergebnissen.

Was wir liefern

Sie können dieses System bei uns kaufen: Unser Team legt die Konfiguration auf Ihre Arbeitslast und Ihr Budget aus und antwortet innerhalb eines Werktages. Wir liefern die RTX PRO 6000 Server Edition und die H200 NVL als GPUs und in KI-Servern auf Bestellung, vor der Lieferung montiert und getestet, über einen EU-Vertrag und eine Rechnung mit Herstellergarantie auf jede Komponente. Betriebssystem, Treiber, CUDA und eine Container-Runtime installieren wir auf Wunsch; Modell, Schema-Auswahl und Abfrageprüfung sind Teil unseres Service Private AI/ML.

FAQ