ik_llama.cpp — performance-oriented
A fork that trades some upstream compatibility for extra quantization types and speed-focused work, popular in the community specifically for squeezing more tokens/sec out of the same hardware than a stock build manages.
TurboQuant — a smaller KV cache at near-lossless quality
TurboLLM's own fork, built around turbo2/turbo3/turbo4
KV-cache formats. The concrete proof: on the same RTX 5070 Ti, Qwen3.6-27B ran 2.2×
faster with TurboQuant's turbo4 KV than the quality-matched
q8_0 KV setting in a tool that can't load the fork — see the measured numbers on
the Qwen3.6 guide.
KoboldCpp — built for creative writing and roleplay
A single-executable fork with context-management features (World Info, Author's Note, Memory) general-purpose chat tools don't have, plus triple API compatibility (KoboldAI, OpenAI, and Ollama-shaped endpoints). The community standard for long-form fiction and roleplay use.
llamafile — one file, zero install
Packages an engine and a model's weights into a single portable executable — the "no dependencies, no install step" end of the spectrum, useful when portability matters more than squeezing out the last bit of performance.
Model-specific research forks
Sometimes a genuinely new quantization scheme only exists in one narrow fork built by the model's own research team, with no path upstream yet. Ternary-Bonsai-27B's 1.7-bit ternary kernels are a real example — they only run on PrismML's fork, and nowhere else. See the Ternary-Bonsai-27B guide for the exact fork and the numbers it unlocks.
Historically, the reason most people stuck to a stock build or a tool with one blessed runtime: using a fork meant cloning it, installing a compiler and CUDA toolkit, and building it yourself. TurboLLM's "Add via git repo" flow takes any fork's URL and does this for you — a one-click "Build it for me" on Windows and Linux, no manual cmake.
FAQ
Is it safe to run a random fork?
Treat it like any other software from a source you don't personally control: prefer forks with real activity, a clear reason to exist, and a visible community using them, and be more cautious with a brand-new one-person repo. TurboLLM's engines catalog surfaces the well-known ones directly; for anything else, the same judgment you'd apply to installing any tool from GitHub applies here too.
Do forks stay compatible with GGUF?
Almost always yes for the base format — forks build on llama.cpp's GGUF loader rather than replacing it. Where a fork adds something new (a custom quant scheme, a novel KV-cache format, kernels for an architecture upstream doesn't support yet), that specific feature is fork-only, but ordinary GGUF models still load normally.
Can I go back to stock llama.cpp?
Yes, any time — engines are interchangeable per model in TurboLLM. Swap back to the auto-provisioned stock build whenever a model doesn't need whatever the fork adds, with no reinstall or reconfiguration beyond picking a different engine.
Try any of them without compiling
See the engines catalog for what's built in, or paste any fork's git URL to build one yourself.