Baseten: KI-generierte Inferenz-Engine schlägt vLLM beim Qwen-Decoding um bis zu 90 Prozent

Eine von einem KI-Agenten erzeugte Inferenz-Engine hat vLLM 0.25.1 bei der Single-Stream-Decodiergeschwindigkeit für Qwen-3.6-35B-A3B in NVFP4-Präzision auf einer einzelnen B200 um bis zu 90 Prozent übertroffen. Das teilt Baseten mit. Die Engine mit dem Namen VibeQwen lieferte demnach außerdem eine 2,33-mal schnellere Time to First Token.
- Basetens agentengenerierte Engine VibeQwen schlug vLLM 0.25.1 beim Single-Stream-Decoding für Qwen-3.6-35B-A3B in NVFP4 auf einer B200 um bis zu 90 Prozent.
- VibeQwen erreichte 1.792 TPS gegenüber 943 TPS bei vLLM und einen ersten Token nach 12 ms statt 28 ms.
- Bei einer Parallelität von 32 lieferte sie 10.307 Ausgabe-TPS gegenüber 6.030, ein Plus von 71 Prozent.
- Der Lauf nutzte Claude Code mit Fable 5, rund 1,7 Milliarden Token und etwa 200 B200-Stunden über ungefähr eine Woche.
- Baseten betont, dass klar definierte Randbedingungen einschließlich Genauigkeitsprüfungen unerlässlich sind, damit Agenten das Ziel nicht austricksen.
Vom Forschungspapier zum einwöchigen Agentenlauf
Das Experiment begann in einem internen Slack-Kanal von Baseten, wo ein Paper mit dem Titel MetaInfer: A Knowledge Only LLM Inference Engine Generator SKILL Toolbox die Aufmerksamkeit des Autors des Beitrags erregte. Die Autoren beschreiben darin ein reines Skills-Framework, mit dem sich maßgeschneiderte Inferenz-Engines von Grund auf bauen lassen. „Skills-only“ bedeutet: kein Post-Training des Modells und keine spezialisierten Harnesses. Nach Angaben der Autoren schlagen ihre Ergebnisse offene Lösungen wie vLLM bei Kennzahlen wie der Zeit pro Ausgabetoken (TPOT).
Der Autor sagt, er sei skeptisch gewesen, habe das bereitgestellte Repository aber an einem populären Modell ausprobiert. Er gab Claude Code mit Fable 5 Zugriff auf das Paper, das MetaInfer-Repository und eine NVIDIA-B200-Workstation per SSH. Zusätzlich stellte er die NVFP4-quantisierten Gewichte für Qwen-3.6-35B-A3B bereit sowie die ursprünglichen Gewichte in voller Präzision, die als Genauigkeitsorakel dienten. Der Agent konnte außerdem Engine-Kandidaten bei Baseten bereitstellen und AIPerf-Profile gegen den bereitgestellten Endpunkt laufen lassen.
Das vorgegebene Ziel lautete, vLLM bei allen Leistungskennzahlen um 20 Prozent zu schlagen, ohne Genauigkeitsverlust gegenüber der NVFP4-Baseline. Laut Baseten arbeitete Claude etwa eine Woche lang größtenteils autonom. Gelegentlich griffen Menschen steuernd ein, damit sich der Agent nicht zu sehr auf ein einzelnes Traffic-Muster fixierte und sich auf die Produktionsleistung statt auf isolierte Engine-Benchmarks konzentrierte.
Die Ergebnisse im Vergleich zu vLLM
Der Agent verbrauchte rund 1,7 Milliarden Token, überwiegend gecachte Eingabetoken, und etwa 200 B200-Stunden. Schon in den ersten Tagen erreichte er Gleichstand mit vLLM, doch der Autor ließ ihn weiterlaufen. Am Ende übertraf VibeQwen vLLM nach Angaben von Baseten bei allen getesteten Traffic-Mustern.
- Single-Stream-Decoding: 1.792 Token pro Sekunde bei speculator-freundlichem Text (repetitiv und strukturiert), gegenüber 943 TPS bei einem gut abgestimmten vLLM-Deployment, eine Verbesserung um 90 Prozent.
- Latenz bis zum ersten Token: 12 ms auf dem getesteten Korpus gegenüber 28 ms mit vLLM, eine Verbesserung um den Faktor 2,3.
- Durchsatz bei einer Parallelität von 32 (einzelne Replik): 10.307 Ausgabe-TPS gegenüber 6.030 bei vLLM, ein Plus von 71 Prozent.
Baseten zufolge eröffnet das für das Modell Anwendungsfälle mit extrem niedriger Latenz, die bisher nicht praktikabel waren.
Warum sich Inferenz für automatisierte Optimierung eignet
Baseten verweist auf mehrere zusammenlaufende Trends. Modelle werden bei Aufgaben mit langem Planungshorizont besser, der Beitrag nennt hier Anthropics Mythos 5 und Fable 5. Zudem werden Funktionen zur Agentenkoordination in gängige Harnesses integriert, darunter „Goals“ in Claude Code und Codex, die Modelle über lange Zeiträume auf messbare Ziele hinarbeiten lassen. Gleichzeitig wächst die Nachfrage nach Inferenz weiter, was Kosten und Leistung unter Druck setzt.
Der Autor argumentiert, Inferenzleistung sei ein ideales Feld für diesen Ansatz. Kennzahlen wie TTFT, TPOT, Durchsatz pro Chip und benötigter Speicher seien quantifizierbar, und die Korrektheit lasse sich numerisch gegen Referenzimplementierungen in voller Präzision prüfen. Hinzu komme ein großer Suchraum, vom Schreiben von CUDA-Kernels bis zu Techniken auf der Serving-Ebene wie dynamischem Batching, sowie eine große Lücke zwischen dem aktuellen Stand der Technik und dem theoretischen Maximum.
Randbedingungen sind entscheidend, und Baseten änderte den Aufbau
Der Beitrag warnt, dass Agenten versuchen werden, ein Ziel auszutricksen. Ohne Randbedingungen, die die Genauigkeit sichern, könnte ein Modell in einer Schleife enden, die den Buchstaben „a“ ausgibt. Das würde bei TTFT und TPOT extrem gut abschneiden, wäre aber nutzlos. Das Spiel so zu gestalten, dass der Erfolg des Agenten den tatsächlichen Anforderungen entspricht, sei Aufgabe des Ingenieurs, schreibt der Autor.
Die Prämisse von MetaInfer lautet, dass eine hochspezialisierte Engine für ein Modell, einen Beschleuniger und eine Workload allgemeine Engines wie vLLM, SGLang und TensorRT-LLM schlagen kann, die Spitzenoptimierung gegen Breite und Benutzerfreundlichkeit eintauschen. Baseten wich von der experimentellen Reinheit des Papers ab: Die Agenten durften offene Lösungen als Referenz heranziehen, darunter vorab optimierte Kernels aus vLLM und TensorRT-LLM, und schrieben eigene Kernels nur bei Bedarf. Der Umfang erfasste zudem den gesamten Serving-Stack, gemessen an bereitgestellten Multi-Replika-Diensten hinter einem Load Balancer mit AIPerf.
Bei der Genauigkeit erlaubte der Autor leicht abweichende numerische Ausgaben gegenüber der NVFP4-Referenzimplementierung, solange die Genauigkeit gegenüber der BF16-Baseline mindestens genauso gut war. Jeder Lauf liefert zwei Ergebnisse: die Engine und wiederverwendbare Erweiterungen der Wissensbasis für spätere Läufe.
Was das bedeutet
Für Teams, die ein festes Modell auf fester Hardware betreiben, legt Basetens Ergebnis nahe, dass agentengenerierte, eng spezialisierte Engines allgemeine Lösungen schlagen können, wenn Ziel und Genauigkeitsvorgaben klar definiert sind. Die Zahlen stammen aus Basetens eigenen Tests mit einem Modell und einem GPU-Typ und sind daher als einzelne Fallstudie zu verstehen, nicht als allgemeiner Benchmark.
Baseten: Agentic inference optimization: 50-90% faster engines


