← Alle Beiträge

Kleinere LLMs erledigen DBA-Aufgaben genauso gut wie große – zu einem Bruchteil der Kosten

Kleinere LLMs erledigen DBA-Aufgaben genauso gut wie große – zu einem Bruchteil der Kosten

Kleinere Open-Weight-Sprachmodelle (LLMs) können Datenbankadministrationsaufgaben (DBA) bereits genauso gut erledigen wie deutlich größere Modelle – und kosten pro Durchlauf nur ein Zehntel. Das geht aus einem Benchmark hervor, den Percona am 17. September 2026 veröffentlicht hat. Vadim Tkachenko, Autor der Untersuchung, hat ein Testsystem entwickelt, mit dem verschiedene LLMs echte DBA-Arbeiten auf entfernten Servern ausführen können, und veröffentlicht die Ergebnisse offen.

Das Testsystem namens DBA AI Benchmark folgt einem einfachen Ablauf. Es erhält eine Aufgabe wie „Installiere Perconas Distribution der Open-Source-relationalen Datenbank, Version 8.4“, sendet diese Aufgabe an das ausgewählte LLM und fordert das Modell auf, die Anfrage in Kommandozeilenbefehle oder Bash-Skripte zu übersetzen. Anschließend führt das Testsystem diese Befehle über SSH (Secure Shell, ein Protokoll zum sicheren Ausführen von Befehlen auf einem entfernten Server) auf einem Zielsystem aus, sendet die Befehlsausgabe, Fehler und den Systemzustand an das Modell zurück und lässt das Modell entscheiden, was als Nächstes zu tun ist. Der Prozess wiederholt sich, bis die Aufgabe erledigt ist, eine Zeitüberschreitung auftritt, die maximale Anzahl an Schritten erreicht ist oder ein konfiguriertes Kostenlimit überschritten wird. Das Projekt ist auf GitHub unter Percona-Lab/dbaai_bench verfügbar.

Tkachenko testet acht Modelle in zwei Gruppen. Die großen, vollwertigen Modelle sind qwen/qwen3.8-max, moonshotai/kimi-k3, z-ai/glm-5.3 und deepseek/deepseek-v4-pro-0813. Die leichteren bzw. Flash-Modelle sind deepseek/deepseek-v4-flash-0731, qwen/qwen3.8-27b, meta/muse-glimmer-30b und google/gemma-4-31b-it. Alle Anfragen und Antworten werden über OpenRouter abgewickelt. Der Autor sagt, sein Hauptaugenmerk liege auf Open-Weight-Modellen, deren trainierte Parameter öffentlich verfügbar sind, weil sie Flexibilität beim Einsatz und Kosteneffizienz bieten und weil ihre Token-Kosten oft deutlich niedriger sind als die geschlossener Frontier-Modelle. Das ist wichtig für Automatisierungs-Workloads, bei denen ein Agent Dutzende Interaktionen benötigen kann, um eine einzige Aufgabe abzuschließen.

Ein Beispiellauf im Blogbeitrag startet das Testsystem auf zwei Hosts mit qwen/qwen3.8-max, der Aufgabe „Installiere die Open-Source-relationale Datenbank Version 9.7 Replikation mit verschlüsseltem Datenverkehr“, einem Maximum von 200 Schritten und unbeaufsichtigtem Modus. Das Modell ist dafür verantwortlich, die Anfrage zu interpretieren, Befehle auszuwählen, auf Fehler zu reagieren und zu entscheiden, wann die Aufgabe erledigt ist. In den Tests haben fast alle Modelle die Aufgaben erfolgreich ausgeführt, mit nur wenigen Ausnahmen. Auffällig ist, dass kleinere und günstigere Modelle oft genauso leistungsfähig sind wie deutlich größere Modelle; der Hauptunterschied liegt meist in der Anzahl der Schritte. Kleinere Modelle benötigen möglicherweise mehr Iterationen, um eine korrekte Konfiguration zu erreichen, aber ihre Gesamtkosten können trotzdem drastisch niedriger sein. In mehreren Tests erledigten kleinere Modelle dieselbe Arbeit zu etwa einem Zehntel der Kosten größerer Modelle.

Eine detaillierte Rangliste für eine Replikationsaufgabe zeigt dies deutlich. Die Aufgabe bestand darin, Perconas Distribution der Open-Source-relationalen Datenbank Version 8.4 auf zwei frisch aufgesetzten Servern zu installieren, eine Replikation einzurichten, bei der ein Primärserver Schreibzugriffe annimmt und ein Replikat folgt, den Replikationsverkehr über das private Netzwerk zu leiten und das Replikat so zu konfigurieren, dass es eigene Schreibzugriffe ablehnt. Die Ergebnisse: deepseek/deepseek-v4-flash-0731 erreichte 100 % saubere Ergebnisse in 35 Schritten für 0,0082 $; deepseek/deepseek-v4-pro-0813 erreichte 100 % in 27 Schritten für 0,2639 $; meta/muse-glimmer-30b erreichte 100 % in 74 Schritten für 0,0479 $; moonshotai/kimi-k3 erreichte 100 % in 17 Schritten für 0,2888 $; qwen/qwen3.8-max erreichte 100 % in 22 Schritten für 0,4200 $; z-ai/glm-5.3 erreichte 100 % in 20 Schritten für 0,2176 $; google/gemma-4-31b-it erreichte 94 % ohne sauberen Lauf nach 46 Schritten für 0,0289 $; und qwen/qwen3.8-27b lief in eine Zeitüberschreitung mit 0 % nach 78 Schritten für 0,5116 $. Der Kostenvergleich ist besonders aufschlussreich. meta/muse-glimmer-30b benötigte 74 Schritte, kostete aber nur 0,0479 $, während qwen/qwen3.8-max nur 22 Schritte brauchte, aber 0,4200 $ kostete, und deepseek-v4-flash in 35 Schritten nur 0,0082 $ kostete. Bei agentenbasierten Infrastruktur-Workloads ist das Modell mit den wenigsten Schritten nicht unbedingt das wirtschaftlichste.

Tkachenko testete auch, wie Modelle mit Anfragen umgehen, die nicht exakt erfüllt werden können. Als die Installation von Version 9.7 der Open-Source-relationalen Datenbank verlangt wurde, antwortete deepseek-v4-pro-0813, dass Version 8.4 dieser Datenbank verfügbar sei, nicht 9.7 wie angefordert, aber dass 8.4 das sei, was Ubuntu bereitstellt, und dass es daher diese Version verwenden würde, und installierte den Datenbankserver auf dem Primärknoten. Statt zu scheitern, interpretierte das Modell die Situation, wählte eine verfügbare Version und machte weiter. Ob dieses Verhalten wünschenswert ist, hängt vom Automatisierungsszenario ab, aber es zeigt, dass LLM-gesteuerte Infrastrukturautomatisierung operative Entscheidungen treffen kann, statt blind Anweisungen zu befolgen. Das macht Validierung und Schutzmechanismen besonders wichtig. In einem weiteren gezielten Test forderte der Autor die Modelle auf, Perconas Distribution der Open-Source-relationalen Datenbank Version 9.7.2 zu installieren, eine Version, die es nicht gibt. Die meisten Modelle entschieden sich, die nächstliegende verfügbare Version 9.7.1 zu installieren, während DeepSeek den Lauf ohne Installation abschloss. Diese Fälle zeigen, wie ein Modell mit Mehrdeutigkeit, nicht verfügbarer Software, widersprüchlichen Anforderungen und der Frage umgeht, ob es die Absicht des Benutzers ändern sollte.

Das Framework ist nicht auf eine relationale Datenbank beschränkt. Derselbe Ansatz kann für die Open-Source-relationale Datenbank, Perconas Distribution derselben Datenbank, die objektrelationale Datenbank, die dokumentenorientierte Datenbank und andere Datenbank- oder Linux-Administrationsaufgaben verwendet werden. In der Praxis testet das System, ob ein LLM als iterativer Systembetreiber agieren kann: planen, ausführen, beobachten, anpassen und verifizieren. Tkachenko erwartet, dass die Bewertung über den einfachen Aufgabenabschluss hinausgeht. Nützliche Dimensionen sind: Abschlussrate, Anzahl der Schritte, Gesamtinferenzkosten (die Kosten für die Generierung von Modellantworten), Ausführungszeit, Korrektheit der Endkonfiguration, Anzahl unnötiger Operationen, Erholung von Befehlsfehlern, Umgang mit mehrdeutigen und unmöglichen Anforderungen, Sicherheit der generierten Konfigurationen und ob das Endsystem tatsächlich der Absicht des Benutzers entspricht. Ein zweites Projekt, DBA AI Batch Runner, führt den Benchmark über mehrere Modelle und Konfigurationen hinweg aus; die Ergebnisse werden in einem GitHub-Repository unter Percona-Lab-results veröffentlicht.

Für Teams, die mit der Bewertung LLM-gesteuerter Datenbankautomatisierung beginnen, kann ein verwalteter Cloud- und Dateninfrastrukturanbieter wie AEU Data isolierte Testumgebungen, Überwachung und automatisierte Backups bereitstellen, die das Risiko verringern, wenn ein Modell eigenes Urteilsvermögen einsetzt, statt Anweisungen exakt zu befolgen.

Auch verfügbar in: EnglishItalianoShqip