Who controls the AI engine? llama.cpp, SGLang and vLLM take three different paths

What's going on

A downloaded language model is, at first, just a big file. To get it to answer, you need an inference engine: the program that loads the model and computes the response token by token. For open models, that almost always means one of three projects:

• llama.cpp for laptops, Macs and gaming PCs. It also powers Ollama and LM Studio.
• vLLM for servers and data centers.
• SGLang, also for large server deployments. LMSYS says it runs on “hundreds of thousands of GPUs,” a figure that hasn't been independently verified.

Within two days, the balance of power shifted at two of these three projects. On November 12, the nonprofit LMSYS founded a consortium of eight companies at the first SGLang Summit in San Francisco. On November 13, llama.cpp v1.0.0 shipped, released by the team that now works at Hugging Face. vLLM has been part of the PyTorch Foundation since 2025. We compare who calls the shots at each project, who pays, and what the chipmakers get out of it. We also look at a second question hardly anyone is asking yet: how much of the code in these engines is now written by AI agents?

Three projects, three power structures

SGLang: a consortium with an advisory role. According to the LMSYS blog, the founding members are Nvidia, AMD, Intel, Google, Meta, Cloudflare, Modal and RadixArk. Each member appoints a technical representative and attends two roadmap meetings a year. Working groups can continue between meetings. Members contribute engineering time, production experience, test hardware or joint development. Money isn't mentioned anywhere. The key sentence: the SGLang maintainers remain responsible for technical decisions and for accepting code. Maintainers are the project's stewards who approve changes. Igor'sLab sums it up: the consortium gets “no automatic control.” The focus areas are support for new frontier models, reasoning, multimodal applications, distributed inference and hardware optimization. No dates or benchmarks were announced.

vLLM: a neutral foundation. UC Berkeley handed vLLM over to the PyTorch Foundation, which sits under the Linux Foundation umbrella, in May 2025. According to the governance page, eleven named core maintainers plan the project in weekly meetings. They publish quarterly roadmaps as GitHub issues and also serve as the technical steering committee. Disputes are settled by five lead maintainers, including Woosuk Kwon and Simon Mo. The page states explicitly that committer status, the right to merge code into the project, belongs to individuals, not companies. Hardware and model vendors sit only on an informal advisory board.

llama.cpp: a company as employer. In February 2026, Georgi Gerganov's ggml.ai team moved to Hugging Face. ggml is the compute library underneath llama.cpp. The projects remain in the ggml-org GitHub organization and stay open source. The v1 blog post doesn't describe any formal governance. It only points to the CODEOWNERS file, which lists who is responsible for which part of the code. Commenting on the move, Simon Willison wrote that he trusts Hugging Face as a steward because of the good job it has done with Transformers.

Who pays? There's a company behind every project

The three paths look very different, but they share one thing: each engine now has commercial money behind it.

SGLang's situation is especially entangled. According to Tech Funding News, RadixArk was founded in 2025 by Ying Sheng and Banghua Zhu. Sheng is a co-author of the original SGLang paper. Its backers include Nvidia's venture arm NVentures, AMD and MediaTek, plus the CEOs of Intel and Broadcom as angel investors. RadixArk plans to keep SGLang free and make money from hosted services. At the summit, Sheng spoke on behalf of the “SGLang team.” So RadixArk is both a founding member of the consortium that advises the maintainers and the employer of key developers. None of the sources say how many maintainers RadixArk employs. vLLM looks similar: according to SiliconANGLE and Caproasia, Inferact's founders include Simon Mo, Woosuk Kwon, Kaichao You and Roger Wang. All four are on the maintainer list.

What's in it for Nvidia, AMD and Intel?

Nvidia executive Ian Buck is blunt about why the company joined: “Better software helps developers get more performance out of Nvidia compute.” A reader comment under an analysis on DEV Community offers another explanation: for chipmakers, membership is more obligation than generosity. If you don't have the right compute routines (kernels) in the leading engine, you may get cut when big cloud providers pick their hardware. One author there writes that the consortium only matters “if the day-0 support actually shows up,” meaning support for new models on the day they're released.

The current hardware picture shows that AMD and Intel are already present in all three engines:

• SGLang lists AMD Instinct MI300X through MI355X, Intel Arc and Xeon, Google TPU, Apple Silicon and Huawei Ascend in its README.
• vLLM supports Nvidia, AMD and Intel GPUs natively, with plugins for TPU, Gaudi, Ascend and other chips.
• llama.cpp has backends for CUDA, HIP (AMD), SYCL (Intel), Vulkan, Metal and many more.

AMD regularly publishes its “day-0” guides for new models for both SGLang and vLLM. Our take: the consortium doesn't give AMD and Intel new access. It gives them a permanent seat at the table when priorities get decided. For users, any effect will only show up later, if at all. Igor'sLab notes that membership doesn't mean every accelerator gets the same features or the same performance.

Stability: llama.cpp promises rules, not a freeze

For end users, llama.cpp v1 is the most tangible change. From now on, it follows semantic versioning, a widely used numbering scheme for software. A new major version means the public C API has changed in an incompatible way. A minor version brings new features and models, a patch version only bug fixes. The transition itself is a break, though. Computingforgeeks checked: 36 functions have been removed from the C API, the number of exported functions drops from 255 to 237, and the library is now called libllama.so.1. The --defrag-thold startup flag now causes an abort instead of just a warning. Servers with tools on open network addresses now only start with an API key. If you use llama.cpp through Ollama or LM Studio, you'll barely notice. If you maintain your own scripts or bindings (interfaces for other programming languages), you'll have to update them.

The second claim: agents are writing the code

A headline on HuggingNews claimed that SGLang's “new v1.0 engine” was “95 percent” written by AI agents. The article cites 200,000 rewritten lines of code, 328 PRs and a “megakernel” that's 2.1 times faster (a megakernel fuses many GPU compute steps into one large block). The figures trace back to a single post on X by @superalesha. The 95 percent appears only in the headline. According to GitHub, there is no SGLang version 1.0: the current release is v0.5.23 from November 2, with “1007 PRs from 257 contributors.”

So we counted for ourselves. Using GitHub's commit search, we counted all commits on the main branch between August 16 and November 14, 2026, that carry an Anthropic co-author line (“Co-authored-by: Claude …”). Pull requests (PRs) are proposed changes. Since these projects usually squash merged PRs into a single commit, one commit roughly equals one PR.

On top of that, vLLM has 253 commits with OpenAI's “Codex” as co-author. Some of these likely overlap with the Claude commits. SGLang had only 4 to 5. In our samples, models such as “Claude Opus 5.5” and “Codex (GPT-6)” appear, sometimes both in the same commit.

Here's how solid these numbers are: the co-author line is a lower bound. vLLM requires disclosure via a commit line, which pushes its figure up. llama.cpp bans AI-written commit messages and squashes PRs itself. So its low figure doesn't prove AI is barely involved. It does reflect a clear stance, though: according to AGENTS.md, fully autonomous agents aren't allowed to contribute at all. Anyone who uses AI without disclosing it risks a permanent ban. vLLM bans “pure agent PRs”; a human must have reviewed every changed line. SGLang, by contrast, pays for Cursor, Claude Code or Codex subscriptions for long-time contributors, according to its README.

Our take: the 95 percent figure can't be backed up for the project as a whole. By our measurement, SGLang is at just under one fifth. What is documented is a sharp increase: at vLLM, the share grew more than sixfold in six months. At the same time, the number of commits nearly doubled at SGLang, and at vLLM as well.

What this means for code review

Back in July, LMSYS itself warned in a blog post that agents produce “more changes that look plausible but still need careful review.” The authors also cite “benchmark reward hacking,” where agents change the test instead of the code or drop inconvenient cases. The Linux kernel shows this isn't just a theoretical problem. This week, developer Lorenzo Stoakes stepped back from reviewer roles because he considers at least half of submitted patches to be “AI slop.” With inference engines, there's an added twist: a buggy kernel doesn't crash, it quietly returns wrong numbers. And llama.cpp's built-in server only just had to be hardened in v1 against SSRF and DNS rebinding attacks, which trick the server into sending requests to internal addresses.

The big picture

The open inference layer is growing up, in three different ways: vLLM relies on a foundation, SGLang on a consortium, llama.cpp on a company as employer. All three have in common that the maintainers formally make the decisions. In practice, many of those maintainers work for companies with hundreds of millions of dollars in venture capital, some of it from the same chipmakers. Our take: the SGLang consortium's structure sounds clean, but for now it's mostly a promise. An analysis on DEV Community calls it a “promise of coordination, not proof of it.” So far, the vendors have delivered no release, no benchmark and no financial commitments. For users, the short-term win is llama.cpp v1 and its more reliable versioning rules. The bigger long-term question is who reviews the rapidly growing share of agent-written code. This is where the projects diverge most: llama.cpp is pumping the brakes, vLLM demands disclosure, and SGLang actively encourages agent use. Which strategy prevents more bugs remains to be seen.