Der Inference-Anbieter Baseten hat am 2. Oktober einen technischen Blogbeitrag veröffentlicht: Mit Claude Code als Steuerung für Fable 5 ließ das Unternehmen einen Agenten von Grund auf eine Inference-Engine schreiben, die nur ein einzelnes Modell bedient – und die in sämtlichen getesteten Traffic-Mustern besser abschnitt als vLLM.
Die Engine heißt VibeQwen und ist speziell auf Alibabas Qwen-3.6-35B-A3B zugeschnitten. Autor Shawn Rushefsky schreibt dazu:
"the generated engine, called VibeQwen, outperformed vLLM across all tested traffic patterns, and by very large margins in some cases"
(Die erzeugte Engine namens VibeQwen übertraf vLLM in allen getesteten Traffic-Mustern, in manchen Fällen mit sehr großem Abstand.)
Woher die Zahlen kommen
Getestet wurde auf Nvidia B200, als Vergleich diente vLLM 0.25.1, Lasttests liefen über AIPerf. Einige Ergebnisse:
- Single-Stream-Decoding bei 1792 TPS gegenüber 943 TPS bei vLLM, rund 90 % schneller;
- Latenz bis zum ersten Token sinkt von 28 auf 12 Millisekunden, etwa das 2,3-Fache;
- Bei 32-facher Parallelität liegt der Durchsatz 71 % höher.
Beim Aufwand brauchte VibeQwen etwa eine Woche, verbrauchte rund 1,7 Milliarden Tokens (größtenteils aus dem Cache), etwa 200 B200-Stunden, Gesamtkosten im Bereich einiger Tausend Dollar.
Dieselbe Methode testete Baseten auch bei der Bildsegmentierung. Das zweite Ergebnis heißt Sammie, bedient Metas SAM 3.1 und läuft auf H100 – fertig in wenigen Tagen, für einige Hundert Dollar und rund 200 Millionen Tokens. Bei 32-facher Parallelität liegt der Durchsatz 50 % über Metas offiziellem Referenzserver, bei 91 Bildern pro Sekunde.
Was der Agent dabei wirklich getan hat
Baseten erweiterte sein eigenes Framework MetaInfer zu einem vollständigen Serving-Stack und überließ dem Agenten, ihn auszufüllen. Der Agent konnte bestehende Open-Source-Lösungen als Referenz heranziehen, maß nach jeder Änderungsrunde mit AIPerf nach und entschied anhand der Zahlen über den nächsten Schritt.
Eine Vorgabe ist sehr konkret formuliert: Bei jeder Änderung, die die Ausgabegenauigkeit beeinflussen könnte, musste der Agent anhalten und eine menschliche Freigabe einholen. Feine numerische Abweichungen sind in Inference-Engines am schwersten zu entdecken; geht Geschwindigkeit zulasten der Genauigkeit, zeigt sich das in keiner Benchmark-Tabelle – genau das soll diese Schranke verhindern.
Der Blogbeitrag zieht selbst klare Grenzen. VibeQwen und Sammie sind beide noch Experimente und haben noch keinen Produktionsverkehr bedient. Der Vergleich bei Sammie ist zudem gröber – der Autor räumt ein, dass diese Zahlen nur als "Indizien" gelten: unterschiedliche Architekturen, unterschiedliche Beschleuniger, kein kontrollierter Test.
Was das für Teams in China bedeutet
VibeQwen zielt auf das Open-Source-Modell Qwen, und viele Produktionsdienste in China laufen zufällig ebenfalls auf der Kombination aus Qwen und vLLM oder SGLang – diese Zahlen betreffen also direkt den Alltag nicht wenige Teams.
Man kann die Wirtschaftlichkeit beider Ansätze gegenüberstellen. Eine Universal-Engine muss Hunderte Modellarchitekturen bedienen, weshalb viele aggressive Optimierungen für eine einzelne Architektur nicht umsetzbar sind; eine dedizierte Engine zielt nur auf ein Modell und kann Attention-Kernel, MoE-Routing und Scheduling-Strategie vollständig auf die Form von 35B-A3B zuschneiden. Früher brauchte ein Team Monate, um eine dedizierte Engine zu schreiben – Baseten hat das jetzt auf eine Woche und einige Tausend Dollar verdichtet, grob gerechnet günstiger als ein Monatsgehalt eines Inference-Ingenieurs.
Die Grenzen sind ebenso deutlich:
- Die Engine ist fest an das Modell gebunden. Ändert sich bei einem Qwen-Upgrade die Architektur, muss die Engine wahrscheinlich neu generiert werden.
- Getestet wurde nur auf B200. Die in China verfügbaren GPU-Modelle unterscheiden sich stark, und ob sich derselbe Prozess auf anderen Beschleunigern reproduzieren lässt, dazu liefert der Blogbeitrag keine Daten.
- Langzeitstabilität bei Ausreißern, Speicherfragmentierung und der Umgang mit fehlerhaften Anfragen, die der Produktionsbetrieb braucht, werden durch Benchmarks nicht unbedingt abgedeckt.
Trotzdem hat der Ansatz "jedes zentrale Modell bekommt eine automatisch erzeugte, dedizierte Engine" nun ein nachprüfbares Beispiel. Ob sich die Rolle von vLLM dadurch von der "tragenden Säule im Betrieb" zur "Baseline und Rückfalllösung" verschiebt, hängt davon ab, ob Teams solche Engines tatsächlich in die Produktion bringen und über Monate öffentlich Daten dazu veröffentlichen.
Quellen: Baseten-Engineering-Blog, CocoLoop; TPS, Latenz bis zum ersten Token, Durchsatz bei Parallelität, Token-Verbrauch und GPU-Stunden wurden über den Baseten-Blog verifiziert.