Quail und Magnitude greifen die Inferenzkosten von den entgegengesetzten Enden des Stacks an

Das Versprechen von Modal und dem Full Stack Data Lab der Carnegie Mellon University ist konkret. Quail, der QUery-Aware Inference Layer, erreichte auf einer Multi-Join-Abfrage über eine Milliarde verarbeitete Token pro Minute pro H100-GPU, schrieb das Team am 30. September. Das sei mehr als 10x schneller als die eigene vLLM-Basislinie auf derselben Hardware. In der Cloud von Modal sind das weniger als 6 Cent pro Milliarde Token.

Die Zahl ist groß genug, um wie ein Tippfehler auszusehen.

Sie ist keine Aussage über ein neues Modell oder einen neuen Chip. Sie ist eine Aussage über die Reihenfolge.

Was Quail tatsächlich tut

AI-SQL erweitert SQL um Funktionen, die pro Zeile ein Sprachmodell aufrufen. Ein Filter braucht einen Modellaufruf pro Zeile. Ein naiver Join braucht einen Aufruf für jedes Zeilenpaar zweier Tabellen. Der Blog des Full Stack Data Lab, veröffentlicht am 24. September und von Modal erneut gepostet, führt durch eine Benchmark-Abfrage namens BIO-4: 5.000 medizinische Berichte, zweimal verknüpft mit 4.144 Reaktionsbegriffen. Die Rechnung des Labors setzt die theoretische Untergrenze für diese Abfrage bei 894,37 Sekunden an, also 14,91 Minuten. Sie nimmt Spitzen-Durchsatz der GPU an, vollständige Überlappung von CPU und GPU und unbegrenzten Platz für vorgehaltenen KV-Cache. vLLM 0.26.0 mit Qwen3 4B FP8 auf einer H100 brauchte 6,84 Stunden, das 27,55-fache dieser Untergrenze. Der Blog führt die Lücke auf zwei Dinge zurück: Host-Overhead, bei dem die CPU Anfragen plant, während die H100 stillsteht, und das, was er KV-Regret nennt, wenn vLLM Key-Value-Cache verwirft, den es später wieder braucht. Bei BIO-4 mit Skalierungsfaktor 1.0 habe vLLM 174.600.000 verarbeitet, und an dieser Stelle bricht der Satz in dem uns vorliegenden Text ab.

Quails Lösung besteht darin, die Struktur der Abfrage selbst als Signal für die Planung zu nutzen. Kennt die Engine den Plan, kann sie Anfragen so ordnen, dass Cache wiederverwendet und gezielt verworfen wird, statt nur zu reagieren. Der Beitrag von Modal beschreibt das als leichte Abwandlung der Cascade-Attention im Stil von Hydragen und würdigt die Zusammenarbeit zwischen Inferenzforschern bei Modal und Datenbankforschern an der CMU.

Über einen neu veröffentlichten AI-SQL-Benchmark läuft Quail geometrisch über die Aufgaben gemittelt 1,84x schneller als vLLM, ein deutlich kleinerer Wert als die Schlagzeile mit der Milliarde Token. Der Beitrag von Modal schreibt, der Benchmark enthalte zwei Abfragen, die zeigen sollen, wo die AI-SQL-Inferenz noch Arbeit braucht. Das ist eine nützliche Offenlegung: Die 10x sind ein Bestfall bei einer einzigen Abfrage, keine allgemeine Beschleunigung.

Magnitude geht den anderen Weg

Magnitude, ein Unternehmen aus dem Y-Combinator-Batch S25, stellte sein Repository am 30. September mit einem anderen Argument online. Seine Inferenz-Engine kompiliert und optimiert Kernel auf dem tatsächlichen Gerät, bevor ein Modell läuft, statt Kernel vorkompiliert für breite Hardwareklassen auszuliefern. Das README behauptet bis zu 2x schneller als llama.cpp, mit 92 Prozent schnellerem Decode auf Metal und 19 Prozent auf CUDA. Außerdem nennt es 27 Prozent weniger Speicher pro Agent.

Die unterstützte Hardware ist bewusst breit: Apple Silicon, NVIDIA, AMD oder allein eine CPU. Das Projekt schreibt, es gebe kein festes Minimum, und kleinere Maschinen führten kleinere Modelle aus. Es erscheint als Desktop-App mit CLI, verbindet sich mit Pi, OpenCode, Hermes, OpenClaw, Codex, Claude Code, Oh My Pi und Cline und bietet für alles andere eine OpenAI-kompatible API. Es steht unter Apache 2.0 und läuft lokal.

Die beiden Projekte sind keine Konkurrenten. Quail zielt auf die analytische SQL-Schicht, in der ein Abfrageplan Millionen kleiner, strukturierter Modellaufrufe erzeugt. Magnitude zielt auf den Laptop des Entwicklers, auf dem ein Agent gegen ein Modell läuft und die Grenze Speicher und Decode-Geschwindigkeit ist. Doch sie zeigen aus entgegengesetzten Richtungen auf dasselbe Kostenproblem: Inferenz ist teuer, weil Allzweck-Engines nicht wissen, was die Arbeitslast als Nächstes tut.

Was die Preisdaten sagen

Der September-Preisindex von AICostBudget, eingefroren mit Stichtag 30. September UTC über 81 öffentliche Datensätze von 11 Anbietern, liefert den Marktkontext. Über 69 Datensätze mit einem aktuellen Skalar für Input-Token reichen die Preise von $0,10 bis $30 pro 1M Token. Die Output-Preise reichen von $0,10 bis $180. Der mediane Input-Preis liegt bei $1,32, der mediane Output-Preis bei $6, und das mediane Verhältnis von Output zu Input beträgt 5,0x.

Der Index macht einen Punkt, der in einem Ranking nach dem billigsten Modell leicht untergeht. Über 58 vergleichbare Datensätze liegt der mediane Rabatt auf gecachten Input bei 90 Prozent. Über 44 batchfähige Datensätze liegt der mediane Batch-Rabatt bei 50 Prozent. Ein Arbeitslastvergleich, der einen dieser Modi ignoriert, vergleicht Listenpreise, die niemand zahlt.

Die Anbietermediane im Index, die laut Methodik nicht nach Nutzung oder Marktanteil gewichtet sind: Google Gemini bei $0,75 Input und $4,125 Output über 14 bepreiste Datensätze, Mistral AI bei $0,20 und $0,60 über 7, DeepSeek bei $0,30 und $1,20 über 3, OpenAI bei $2 und $11 über 18, xAI bei $1,25 und $2,50 über 9, Cohere bei $1,50 und $5,75 über 2, Anthropic bei $5 und $25 über 13 und Moonshot AI bei $0,95 und $4 über 3. AWS, Azure und Google Cloud steuern je einen Datensatz ohne numerischen Wert bei.

Die Hardwareseite

An der Hardware-Effizienz wird parallel gearbeitet. EnerTune, ein am 28. September in den SOSP-'26-Proceedings veröffentlichtes Paper, argumentiert, dass die Optimierung von GPU-Clustern allein auf Auslastung den Energieverbrauch erhöhen kann. Die Autoren Prasoon Sinha, Dimitrios Liakopoulos, Nathan Lemma und Neeraja J. Yadwadkar schlagen analytische Modelle für Leistung und Verbrauch pro Modell vor, dazu die Leistungsaufnahme gemeinsam platzierter Modelle auf geteilten GPUs. Diese Modelle speisen einen energiebewussten Bin-Packing-Algorithmus. Die Autoren berichten, dass sie Leistungs-SLOs einhalten und dabei Energie um den Faktor 1,4 bis 2,3 und die Leistungsaufnahme um den Faktor 1,3 bis 2,6 gegenüber dem Stand der Technik senken.

Das ist ein anderer Hebel als bei Quail, und es gilt derselbe Vorbehalt: Benchmark-Ergebnisse, keine Produktivumgebungen. Das Paper merkt ausdrücklich an, dass das Profiling jedes Modells unter Hunderten von Konfigurationen im großen Maßstab unverhältnismäßig teuer ist, weshalb es analytische Modelle verwendet.

Unterdessen ist die Erfahrung von Pinecone mit dem eigenen Preiskalkulator, beschrieben von Gkogan am 30. September, eine Erinnerung daran, dass Kostenverwirrung nicht nur ein Rechenproblem ist. Das Unternehmen entfernte den Kalkulator, nachdem ein A/B-Test ergab, dass Besucher, die ihn nicht sahen, sich 16 Prozent wahrscheinlicher anmeldeten und 90 Prozent wahrscheinlicher Kontakt aufnahmen, ohne Zunahme der Support-Tickets zum Thema Preise. Sieben von zehn Mitarbeitern hatten vorhergesagt, die Version mit Kalkulator würde gewinnen.

Der gemeinsame Faden bei Quail, Magnitude und EnerTune ist, dass die größten Gewinne daher kommen, mehr über die Arbeitslast zu wissen, sei es ein Abfrageplan, ein bestimmter Chip oder ein Muster der gemeinsamen Platzierung. Allzweck-Engines lassen diese Information liegen. Was keines der drei bisher belegt, ist, ob die Gewinne den Kontakt mit unruhigem Produktivverkehr überstehen, und nur Magnitude liefert etwas, das ein Entwickler heute installieren kann.