Wem gehört der KI-Motor? llama.cpp, SGLang und vLLM gehen drei verschiedene Wege

Darum geht es

Ein heruntergeladenes Sprachmodell ist zunächst nur eine große Datei. Damit es antwortet, braucht es eine Inferenz-Engine, also das Programm, das das Modell lädt und Wort für Wort die Antwort berechnet. Bei offenen Modellen läuft das fast immer über eines von drei Projekten:

• llama.cpp für Laptop, Mac und Gaming-PC. Es steckt auch in Ollama und LM Studio.
• vLLM für Server und Rechenzentren.
• SGLang, ebenfalls für große Server-Installationen. LMSYS gibt an, dass es auf „Hunderttausenden GPUs“ läuft, unabhängig geprüft ist die Zahl nicht.

Innerhalb von zwei Tagen hat sich bei zwei dieser drei Projekte die Machtfrage neu geordnet. Am 12. November gründete die gemeinnützige Organisation LMSYS auf dem ersten SGLang Summit in San Francisco ein Konsortium mit acht Firmen. Am 13. November erschien llama.cpp v1.0.0, herausgegeben vom Team, das inzwischen bei Hugging Face arbeitet. vLLM gehört schon seit 2025 zur PyTorch Foundation. Wir stellen gegenüber, wer bei welchem Projekt bestimmt, wer bezahlt und was die Chiphersteller davon haben. Außerdem gehen wir einer zweiten Frage nach, die bisher kaum jemand stellt: Wie viel des Codes in diesen Engines schreiben inzwischen KI-Agenten?

Drei Projekte, drei Machtmodelle

SGLang: Konsortium mit Beratungsrecht. Laut LMSYS-Blog sind die Gründungsmitglieder Nvidia, AMD, Intel, Google, Meta, Cloudflare, Modal und RadixArk. Jedes Mitglied benennt einen technischen Vertreter und nimmt an zwei Roadmap-Treffen im Jahr teil. Zwischen den Treffen können Arbeitsgruppen weiterarbeiten. Die Mitglieder steuern Ingenieursarbeit, Erfahrungen aus dem Betrieb, Testhardware oder gemeinsame Entwicklung bei. Geld wird nirgends erwähnt. Entscheidend ist dieser Satz: Die SGLang-Maintainer bleiben für technische Entscheidungen und für die Annahme von Code verantwortlich. Maintainer sind die Betreuer des Projekts, die Änderungen freigeben. Igor'sLab fasst es so zusammen: Das Konsortium erhält „keine automatische Kontrolle“. Inhaltlich geht es um Unterstützung neuer Spitzenmodelle, Reasoning, multimodale Anwendungen, verteilte Inferenz und Hardware-Optimierung. Termine oder Benchmarks wurden nicht genannt.

vLLM: neutrale Stiftung. Die UC Berkeley hat vLLM im Mai 2025 an die PyTorch Foundation übergeben, die unter dem Dach der Linux Foundation steht. Nach der Governance-Seite planen elf namentlich genannte Kern-Maintainer das Projekt in wöchentlichen Treffen. Sie veröffentlichen vierteljährliche Roadmaps als GitHub-Issues und bilden zugleich das technische Lenkungsgremium. Bei Streit entscheiden fünf Lead-Maintainer, darunter Woosuk Kwon und Simon Mo. Ausdrücklich heißt es: Der Committer-Status, also das Recht, Code ins Projekt zu übernehmen, gehört Personen und nicht Firmen. Hardware- und Modellhersteller sitzen nur in einem informellen Beirat.

llama.cpp: ein Unternehmen als Arbeitgeber. Im Februar 2026 wechselte das Team von ggml.ai um Georgi Gerganov zu Hugging Face. ggml ist die Rechenbibliothek unter llama.cpp. Die Projekte liegen weiter in der GitHub-Organisation ggml-org und bleiben Open Source. Eine formale Governance beschreibt der v1-Blogpost nicht. Er verweist nur auf die CODEOWNERS-Datei, in der steht, wer welchen Codebereich verantwortet. Simon Willison schrieb zur Übernahme, er vertraue Hugging Face als Verwalter, weil es mit Transformers gute Arbeit geleistet habe.

Wer bezahlt? Hinter jedem Projekt steht eine Firma

Die drei Wege sehen sehr verschieden aus, doch eines haben sie gemeinsam: Hinter jeder Engine steht inzwischen kommerzielles Geld.

Bei SGLang ist die Lage besonders verflochten. RadixArk wurde laut Tech Funding News 2025 von Ying Sheng und Banghua Zhu gegründet. Sheng ist Mitautorin des ursprünglichen SGLang-Papers. Unter den Geldgebern sind Nvidias Investmentarm NVentures, AMD und MediaTek, als Privatinvestoren außerdem die Chefs von Intel und Broadcom. RadixArk will SGLang frei halten und mit gehosteten Diensten Geld verdienen. Auf dem Summit sprach Sheng für das „SGLang-Team“. RadixArk ist also zugleich Gründungsmitglied des Konsortiums, das die Maintainer berät, und Arbeitgeber zentraler Entwickler. Wie viele Maintainer bei RadixArk angestellt sind, nennt keine der Quellen. Ähnlich ist es bei vLLM: Inferact gründeten laut SiliconANGLE und Caproasia unter anderem Simon Mo, Woosuk Kwon, Kaichao You und Roger Wang. Alle vier stehen auf der Maintainer-Liste.

Was haben Nvidia, AMD und Intel davon?

Nvidia-Manager Ian Buck begründet die Mitgliedschaft ohne Umschweife: „Bessere Software hilft Entwicklern, mehr Leistung aus Nvidia-Rechenleistung zu holen.“ Ein Leserkommentar unter einer Analyse auf DEV Community bringt eine andere Erklärung: Die Mitgliedschaft sei für Chiphersteller eher Pflicht als Großzügigkeit. Wer keine passenden Rechenbausteine (Kernels) in der führenden Engine hat, falle bei der Auswahl durch große Cloud-Anbieter womöglich durch. Ein Autor schreibt dort, das Konsortium zähle nur, „wenn die Day-0-Unterstützung wirklich kommt“. Gemeint ist Unterstützung neuer Modelle schon am Tag ihrer Veröffentlichung.

Der Stand bei der Hardware zeigt, dass AMD und Intel längst auf allen drei Engines vertreten sind:

• SGLang nennt im README AMD Instinct MI300X bis MI355X, Intel Arc und Xeon, Google TPU, Apple Silicon und Huawei Ascend.
• vLLM unterstützt Nvidia-, AMD- und Intel-GPUs direkt, dazu kommen Plugins für TPU, Gaudi, Ascend und weitere Chips.
• llama.cpp hat Backends für CUDA, HIP (AMD), SYCL (Intel), Vulkan, Metal und viele mehr.

AMD veröffentlicht seine „Day-0“-Anleitungen für neue Modelle regelmäßig sowohl für SGLang als auch für vLLM. Unsere Einschätzung: Das Konsortium bringt AMD und Intel keinen neuen Zugang, sondern einen festen Platz am Tisch, wenn über die Prioritäten entschieden wird. Für Nutzer wird sich das, wenn überhaupt, erst später zeigen. Igor'sLab weist darauf hin, dass die Mitgliedschaft nicht bedeutet, dass alle Beschleuniger dieselben Funktionen oder dieselbe Leistung bekommen.

Stabilität: llama.cpp verspricht Regeln, nicht Stillstand

Für Endnutzer ist llama.cpp v1 die greifbarste Neuerung. Ab jetzt gilt semantische Versionierung, ein verbreitetes Nummernschema für Software. Eine neue Hauptversion bedeutet, dass sich die öffentliche C-Schnittstelle inkompatibel geändert hat. Eine Unterversion bringt neue Funktionen und Modelle, eine Patch-Version nur Fehlerkorrekturen. Der Einstieg ist allerdings selbst ein Bruch. Computingforgeeks hat nachgemessen: 36 Funktionen sind aus der C-Schnittstelle entfernt, die Zahl der exportierten Funktionen sinkt von 255 auf 237, und die Bibliothek heißt jetzt libllama.so.1. Der Startparameter --defrag-thold führt nun zum Abbruch statt nur zu einer Warnung. Server mit Tools auf offenen Netzwerkadressen starten nur noch mit API-Schlüssel. Wer llama.cpp über Ollama oder LM Studio nutzt, bekommt davon wenig mit. Wer eigene Skripte oder Bindings, also Anbindungen für andere Programmiersprachen, pflegt, muss sie anpassen.

Die zweite These: Agenten schreiben mit

Auf HuggingNews stand die Überschrift, SGLangs „neue v1.0-Engine“ sei zu „95 Prozent“ von KI-Agenten geschrieben. Im Text werden 200.000 umgebaute Codezeilen, 328 PRs und ein 2,1-mal schnellerer „Megakernel“ genannt, das ist ein zu einem großen Block verschmolzener GPU-Rechenschritt. Die Zahlen gehen auf einen einzigen Post auf X von @superalesha zurück. Die 95 Prozent tauchen nur in der Überschrift auf. Eine SGLang-Version 1.0 gibt es laut GitHub nicht: Aktuell ist v0.5.23 vom 2. November mit „1007 PRs von 257 Beitragenden“.

Wir haben deshalb selbst nachgezählt. Über die Commit-Suche von GitHub haben wir für den Zeitraum vom 16. August bis 14. November 2026 alle Commits im Hauptzweig gezählt, die eine Co-Autor-Zeile von Anthropic tragen („Co-authored-by: Claude …“). Pull Requests (PRs) sind Änderungsvorschläge. Da die Projekte gemergte PRs meist zu einem Commit zusammenfassen, entspricht ein Commit dort etwa einem PR.

Dazu kommen bei vLLM 253 Commits mit einem Co-Autor „Codex“ von OpenAI. Ein Teil davon dürfte sich mit den Claude-Commits überschneiden. Bei SGLang waren es nur 4 bis 5. In unseren Stichproben stehen Modelle wie „Claude Opus 5.5“ und „Codex (GPT-6)“, teils beide im selben Commit.

So belastbar sind die Zahlen: Die Co-Autor-Zeile ist eine Untergrenze. vLLM schreibt die Offenlegung per Commit-Zeile vor, das treibt seinen Wert nach oben. llama.cpp verbietet KI-geschriebene Commit-Nachrichten und fasst PRs selbst zusammen. Der niedrige Wert beweist dort also nicht, dass kaum KI im Spiel ist. Er zeigt aber eine klare Haltung: Laut AGENTS.md dürfen vollautonome Agenten gar nicht beitragen. Wer KI nutzt, ohne es offenzulegen, riskiert einen dauerhaften Ausschluss. vLLM verbietet „reine Agenten-PRs“, ein Mensch muss jede geänderte Zeile geprüft haben. SGLang wiederum bezahlt langjährigen Beitragenden laut README Abos für Cursor, Claude Code oder Codex.

Unsere Einschätzung: Die 95 Prozent lassen sich für das Gesamtprojekt nicht belegen. Gemessen liegt SGLang bei knapp einem Fünftel. Belegt ist dagegen eine starke Zunahme: Bei vLLM hat sich der Anteil binnen eines halben Jahres mehr als versechsfacht. Gleichzeitig hat sich die Zahl der Commits bei SGLang fast verdoppelt, bei vLLM ebenfalls.

Was das fürs Prüfen heißt

LMSYS selbst warnte schon im Juli in einem Blogbeitrag, Agenten erzeugten „mehr Änderungen, die plausibel aussehen und trotzdem sorgfältig geprüft werden müssen“. Die Autoren nennen auch „Benchmark-Reward-Hacking“: Agenten ändern dann den Test statt den Code oder lassen ungünstige Fälle weg. Dass das kein theoretisches Problem ist, zeigt der Linux-Kernel. Dort gab Entwickler Lorenzo Stoakes diese Woche Reviewer-Rollen ab, weil er mindestens die Hälfte der eingereichten Patches für „KI-Slop“ hält. Bei Inferenz-Engines kommt hinzu, dass ein fehlerhafter Kernel nicht abstürzt, sondern leise falsche Zahlen liefert. Und der eingebaute Server von llama.cpp musste in v1 gerade erst gegen SSRF- und DNS-Rebinding-Angriffe abgesichert werden. Bei diesen Angriffen wird der Server dazu gebracht, Anfragen an interne Adressen zu schicken.

Einordnung

Die offene Inferenz-Schicht wird gerade erwachsen, und zwar auf drei Arten: vLLM setzt auf eine Stiftung, SGLang auf ein Konsortium, llama.cpp auf ein Unternehmen als Arbeitgeber. Allen dreien gemeinsam ist, dass formal die Maintainer entscheiden. In der Praxis arbeiten viele dieser Maintainer bei Firmen mit Hunderten Millionen Dollar Risikokapital, an denen teils dieselben Chiphersteller beteiligt sind. Unsere Einschätzung: Die Struktur des SGLang-Konsortiums klingt sauber, ist aber vor allem ein Versprechen. Eine Analyse auf DEV Community spricht von einem „Versprechen von Koordination, nicht dem Beweis dafür“. Die Hersteller haben bisher weder ein Release noch einen Benchmark oder Geldzusagen vorgelegt. Für Nutzer zählt kurzfristig vor allem llama.cpp v1 mit seinen verlässlicheren Versionsregeln. Langfristig wichtiger ist die Frage, wer den rasant wachsenden Anteil an Agenten-Code prüft. Hier gehen die Projekte am weitesten auseinander: llama.cpp bremst, vLLM verlangt Offenlegung, SGLang fördert den Einsatz aktiv. Welche Strategie mehr Fehler verhindert, ist offen.