Skip to content

Lidenburg/llama.cpp

BranchesTags
 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

9,627 Commits
.devops
.devops
 
 
.gemini
.gemini
 
 
.github
.github
 
 
.pi/gg
.pi/gg
 
 
app
app
 
 
benches
benches
 
 
ci
ci
 
 
cmake
cmake
 
 
common
common
 
 
conversion
conversion
 
 
docs
docs
 
 
examples
examples
 
 
ggml
ggml
 
 
gguf-py
gguf-py
 
 
grammars
grammars
 
 
include
include
 
 
licenses
licenses
 
 
media
media
 
 
models
models
 
 
pocs
pocs
 
 
requirements
requirements
 
 
scripts
scripts
 
 
src
src
 
 
tests
tests
 
 
tools
tools
 
 
vendor
vendor
 
 
.clang-format
.clang-format
 
 
.clang-tidy
.clang-tidy
 
 
.dockerignore
.dockerignore
 
 
.ecrc
.ecrc
 
 
.editorconfig
.editorconfig
 
 
.flake8
.flake8
 
 
.gitignore
.gitignore
 
 
.gitmodules
.gitmodules
 
 
.pre-commit-config.yaml
.pre-commit-config.yaml
 
 
AGENTS.md
AGENTS.md
 
 
AUTHORS
AUTHORS
 
 
CLAUDE.md
CLAUDE.md
 
 
CMakeLists.txt
CMakeLists.txt
 
 
CMakePresets.json
CMakePresets.json
 
 
CODEOWNERS
CODEOWNERS
 
 
CONTRIBUTING.md
CONTRIBUTING.md
 
 
LICENSE
LICENSE
 
 
Makefile
Makefile
 
 
README.md
README.md
 
 
SECURITY.md
SECURITY.md
 
 
build-xcframework.sh
build-xcframework.sh
 
 
convert_hf_to_gguf.py
convert_hf_to_gguf.py
 
 
convert_hf_to_gguf_update.py
convert_hf_to_gguf_update.py
 
 
convert_llama_ggml_to_gguf.py
convert_llama_ggml_to_gguf.py
 
 
convert_lora_to_gguf.py
convert_lora_to_gguf.py
 
 
flake.nix
flake.nix
 
 
mypy.ini
mypy.ini
 
 
pyproject.toml
pyproject.toml
 
 
pyrightconfig.json
pyrightconfig.json
 
 
requirements.txt
requirements.txt
 
 
ty.toml
ty.toml
 
 

Repository files navigation

MoE Expert Caching

This is a fork with a three-tier expert weight cache for Mixture-of-Experts (MoE) models. It adds a GPU/RAM/disk caching layer that keeps the most-used expert weights in VRAM, a larger set in pinned host RAM, and reads the rest on-demand from disk via O_DIRECT + io_uring, bypassing the Linux page cache. This allows running MoE models with the same VRAM usage as with the pre-existing --n-cpu-moe approach, but with higher performance. Or alternatively, the same performance you were already getting but with lower VRAM usage.

Warning: This is very much proof-of-concept code, but it has worked well during testing.

This code is optimized exclusively for generation throughput (t/s); no work has been put into optimizing prefill performance. This is why, for example, expert usage tracking only runs during generation.

Linux-only the current implementation depends on io_uring, madvise, and posix_memalign, which are Linux-specific. It has only been tested with an NVIDIA GPU, on a single-GPU system.

Tested on: RTX 5080 (PCIe Gen 4), Ryzen 3900X, 32 GB DDR4 RAM, and a decade old SATA SSD (~500 MB/s sequential read max). On this hardware the bottleneck for larger models is disk reads on cache misses, a fast NVMe SSD would likely allow running much larger models by reducing that bottleneck.

Not tested with MTP expert usage tracking only updates during generation (by checking if the token count is 1). During prefill (token count > 1), usage counts are skipped to avoid skewing the cache. With multi-token prediction (MTP), the token count during generation may exceed 1, breaking this assumption and causing usage tracking to not be updated properly, leading to the wrong experts being populated in the cache. If you decide to try with MTP enabled anyway, you will need to make sure the MTP layer is fully GPU resident by using an -ot parameter, otherwise the layer tracking that the input_cpy rewrite code depends on will become off. Likewise, the code has only been tested with 1 single request at a time, if multiple requests run and bounce between different layers then the last_layer static variable will become off and wrong things can probably happen. I haven't looked into this.

Configuration (environment variables):

Variable Default Description
GGML_EXPERT_CACHE_MAX 110 Max experts per tensor kept in GPU VRAM
GGML_EXPERT_RAM_CACHE_MAX 300 Max experts per tensor kept in pinned host RAM
GGML_OP_OFFLOAD_MIN_BATCH - Must be set to 1 for the expert cache to work

Any remaining experts not in GPU or RAM cache are loaded on demand from disk via io_uring + O_DIRECT. Use --mmap (not --no-mmap) to avoid keeping all weights in RAM, since the expert cache uses madvise(MADV_DONTNEED) to release mmap'd pages after pre-populating the RAM cache. The code only uses the mmap'd weights as a hacky way to get the offset for a given weight from the file to avoid having to parse the GGUF. This is done so that all changes can fit into ggml-backend.cpp. If running with GGML_EXPERT_CACHE but not GGML_EXPERT_RAM_CACHE, you should also use --mmap instead of --no-mmap. In this mode all expert weights are stored in RAM (there is no disk tier).

Example usage:

GGML_EXPERT_CACHE_MAX=90 GGML_EXPERT_RAM_CACHE_MAX=166 GGML_OP_OFFLOAD_MIN_BATCH=1 ./build/bin/llama-server -fa on -ctk q8_0 -ctv q8_0 -m ~/Qwen3.6-35B-A3B-UD-Q4_K_M.gguf -c 256000 --jinja --mmap -ngl 99 --cpu-moe -t 11 -lv 4

How it works:

  • GPU tier: Hottest experts live in a pre-allocated VRAM buffer. When all active experts are cached, input_cpy is remapped to point directly at cache slots (zero-copy). When only some active experts are in GPU cache, cached experts are copied from the GPU cache buffer while uncached ones are fetched from RAM or disk.
  • RAM tier: A cudaHostRegister'd pinned staging buffer holds additional experts. Transfers to GPU are asynchronous over PCIe. When evicting VRAM experts with GGML_EXPERT_RAM_CACHE enabled, evicted expert weights are copied from GPU back into RAM rather than re-read from disk. This was found to be fastest on the test hardware, but with a fast NVMe SSD it may be faster to just re-read from disk. This has not been tested.
  • Disk tier: Remaining experts are read on demand from the GGUF file via io_uring with O_DIRECT. Sibling tensors (gate/up/down) of the same layer are read at the same time to minize wasted time.
  • Eviction: The cache eviction strategy is currently "LFU with aging". When the max usage count exceeds 128, all counts are halved to prevent stale entries from locking the cache. This was the best cache approach I found during initial testing, though it could be worth revisiting different caching strategies again.
  • Next-layer prefetch (disabled): There is code to speculatively prefetch the top-used disk-resident experts for upcoming layers (N+1 through N+DEPTH) while the current layer is being processed. However, this only achieved a ~1% hit rate. Expert selection patterns aren't predictable enough across layers to make it worthwhile, atleast not in a naive implementation. The code remains behind the ENABLE_PREFETCH compile-time define (set to 0 by default).
  • Stats: A background thread prints GPU/RAM/disk hit rates every 10 seconds. On exit, a llama_expert_usage.txt file is written with per-layer expert usage details.

Expert Caching Comparisons

System usage @ idle: VRAM ~400 MiB, RAM 1–2 GB.

Qwen3.6-35B-A3B-UD-Q4_K_M.gguf is the unsloth MTP variant, but MTP wasn't used for any of the tests.

Model Target Expert Cache Experts (VRAM/RAM/Disk) VRAM RAM Speed Improvement
Qwen3.6 35B (Qwen3.6-35B-A3B-UD-Q4_K_M.gguf) @ 256k max ctx 32 GB RAM + 16 GB VRAM Yes 120/136/0 15,253 MiB 12 GB ~80 t/s +60%
Qwen3.6 35B (Qwen3.6-35B-A3B-UD-Q4_K_M.gguf) @ 256k max ctx 32 GB RAM + 16 GB VRAM No -ncmoe 21 15,766 MiB 12.5 GB ~50 t/s —
Qwen3.6 35B (Qwen3.6-35B-A3B-UD-Q4_K_M.gguf) @ 256k max ctx 16 GB RAM + 12 GB VRAM Yes 70/186/0 11,643 MiB ~16 GB ~66 t/s +65%
Qwen3.6 35B (Qwen3.6-35B-A3B-UD-Q4_K_M.gguf) @ 256k max ctx 16 GB RAM + 12 GB VRAM No -ncmoe 30 11,580 MiB 16.5 GB ~40 t/s —
Qwen3-Coder-Next (Qwen3-Coder-Next-UD-IQ4_XS.gguf) @ 256k max ctx 32 GB RAM + 16 GB VRAM Yes 110/402/0 14,732 MiB 28.7 GB ~50 t/s +66%
Qwen3-Coder-Next (Qwen3-Coder-Next-UD-IQ4_XS.gguf) @ 256k max ctx 32 GB RAM + 16 GB VRAM No -ncmoe 37 15,091 MiB 28.4 GB ~30 t/s —
Qwen3-Coder-Next (Qwen3-Coder-Next-UD-IQ4_XS.gguf) @ 256k max ctx 32 GB RAM + 12 GB VRAM Yes 55/402/55 10,988 MiB 28.7 GB ~27 t/s +58%
Qwen3-Coder-Next (Qwen3-Coder-Next-UD-IQ4_XS.gguf) @ 256k max ctx 32 GB RAM + 12 GB VRAM No -ncmoe 41 12,162 MiB ~2 GB ~17 t/s —

All tests were run with llama-cli -fa on -ctk q8_0 -ctv q8_0 -m <model.gguf> -c 256000 --jinja --no-mmap -ngl 99 --n-cpu-moe XX -t 11 -n 1000 -f test-prompt.txt --perf --single-turn for the non expert cache runs. And GGML_EXPERT_CACHE_MAX=XXX GGML_EXPERT_RAM_CACHE_MAX=YYY GGML_OP_OFFLOAD_MIN_BATCH=1 llama-cli -fa on -ctk q8_0 -ctv q8_0 -m <model.gguf> -c 256000 --jinja --mmap -ngl 99 --cpu-moe -t 11 -n 1000 -f test-prompt.txt --perf --single-turn for the expert cache runs.

test-prompt.txt contains: Create a python script that prints the size in bytes of all the expert weights in a gguf file.

Original README

llama.cpp

llama

License: MIT Release Server Docker Winget

Manifesto / ggml / ops

LLM inference in C/C++

Recent API changes

Hot topics

Quick start

Getting started with llama.cpp is straightforward. Here are several ways to install it on your machine:

Once installed, you'll need a model to work with. Head to the Obtaining and quantizing models section to learn more.

Example command:

# Use a local model file
llama-cli -m my_model.gguf

# Or download and run a model directly from Hugging Face
llama-cli -hf ggml-org/gemma-3-1b-it-GGUF

# Launch OpenAI-compatible API server
llama-server -hf ggml-org/gemma-3-1b-it-GGUF

Description

The main goal of llama.cpp is to enable LLM inference with minimal setup and state-of-the-art performance on a wide range of hardware - locally and in the cloud.

  • Plain C/C++ implementation without any dependencies
  • Apple silicon is a first-class citizen - optimized via ARM NEON, Accelerate and Metal frameworks
  • AVX, AVX2, AVX512 and AMX support for x86 architectures
  • RVV, ZVFH, ZFH, ZICBOP and ZIHINTPAUSE support for RISC-V architectures
  • 1.5-bit, 2-bit, 3-bit, 4-bit, 5-bit, 6-bit, and 8-bit integer quantization for faster inference and reduced memory use
  • Custom CUDA kernels for running LLMs on NVIDIA GPUs (support for AMD GPUs via HIP and Moore Threads GPUs via MUSA)
  • Vulkan and SYCL backend support
  • CPU+GPU hybrid inference to partially accelerate models larger than the total VRAM capacity

The llama.cpp project is the main playground for developing new features for the ggml library.

Models

Typically finetunes of the base models below are supported as well.

Instructions for adding support for new models: HOWTO-add-model.md

Text-only

Multimodal

Bindings
UIs

(to have a project listed here, it should clearly state that it depends on llama.cpp)

Tools
  • akx/ggify – download PyTorch models from Hugging Face Hub and convert them to GGML
  • akx/ollama-dl – download models from the Ollama library to be used directly with llama.cpp
  • crashr/gppm – launch llama.cpp instances utilizing NVIDIA Tesla P40 or P100 GPUs with reduced idle power consumption
  • gpustack/gguf-parser - review/check the GGUF file and estimate the memory usage
  • Styled Lines (proprietary licensed, async wrapper of inference part for game development in Unity3d with pre-built Mobile and Web platform wrappers and a model example)
  • unslothai/unsloth – 🦥 exports/saves fine-tuned and trained models to GGUF (Apache-2.0)
Infrastructure
  • Paddler - Open-source LLMOps platform for hosting and scaling AI in your own infrastructure
  • GPUStack - Manage GPU clusters for running LLMs
  • llama_cpp_canister - llama.cpp as a smart contract on the Internet Computer, using WebAssembly
  • llama-swap - transparent proxy that adds automatic model switching with llama-server
  • Kalavai - Crowdsource end to end LLM deployment at any scale
  • llmaz - ☸️ Easy, advanced inference platform for large language models on Kubernetes.
  • LLMKube - Kubernetes operator for llama.cpp with multi-GPU and Apple Silicon Metal support"
Games
  • Lucy's Labyrinth - A simple maze game where agents controlled by an AI model will try to trick you.

Supported backends

Backend Target devices
Metal Apple Silicon
BLAS All
BLIS All
SYCL Intel GPU
OpenVINO [In Progress] Intel CPUs, GPUs, and NPUs
MUSA Moore Threads GPU
CUDA Nvidia GPU
HIP AMD GPU
ZenDNN AMD CPU
Vulkan GPU
CANN Ascend NPU
OpenCL Adreno GPU
IBM zDNN IBM Z & LinuxONE
WebGPU All
RPC All
Hexagon [In Progress] Snapdragon
VirtGPU VirtGPU APIR

Obtaining and quantizing models

The Hugging Face platform hosts a number of LLMs compatible with llama.cpp:

You can either manually download the GGUF file or directly use any llama.cpp-compatible models from Hugging Face or other model hosting sites, by using this CLI argument: -hf <user>/<model>[:quant]. For example:

llama-cli -hf ggml-org/gemma-3-1b-it-GGUF

By default, the CLI would download from Hugging Face, you can switch to other options with the environment variable MODEL_ENDPOINT. The MODEL_ENDPOINT must point to a Hugging Face compatible API endpoint.

After downloading a model, use the CLI tools to run it locally - see below.

llama.cpp requires the model to be stored in the GGUF file format. Models in other data formats can be converted to GGUF using the convert_*.py Python scripts in this repo.

The Hugging Face platform provides a variety of online tools for converting, quantizing and hosting models with llama.cpp:

To learn more about model quantization, read this documentation

llama-cli

A CLI tool for accessing and experimenting with most of llama.cpp's functionality.

  • Run in conversation mode

    Models with a built-in chat template will automatically activate conversation mode. If this doesn't occur, you can manually enable it by adding -cnv and specifying a suitable chat template with --chat-template NAME

    llama-cli -m model.gguf

# > hi, who are you?
# Hi there! I'm your helpful assistant! I'm an AI-powered chatbot designed to assist and provide information to users like you. I'm here to help answer your questions, provide guidance, and offer support on a wide range of topics. I'm a friendly and knowledgeable AI, and I'm always happy to help with anything you need. What's on your mind, and how can I assist you today?
#
# > what is 1+1?
# Easy peasy! The answer to 1+1 is... 2!
  • Run in conversation mode with custom chat template 
    # use the "chatml" template (use -h to see the list of supported templates)
llama-cli -m model.gguf -cnv --chat-template chatml

# use a custom template
llama-cli -m model.gguf -cnv --in-prefix 'User: ' --reverse-prompt 'User:'
  • Constrain the output with a custom grammar 
    llama-cli -m model.gguf -n 256 --grammar-file grammars/json.gbnf -p 'Request: schedule a call at 8pm; Command:'

# {"appointmentTime": "8pm", "appointmentDetails": "schedule a a call"}

    The grammars/ folder contains a handful of sample grammars. To write your own, check out the GBNF Guide.

    For authoring more complex JSON grammars, check out https://grammar.intrinsiclabs.ai/

llama-server

A lightweight, OpenAI API compatible, HTTP server for serving LLMs.

  • Start a local HTTP server with default configuration on port 8080 
    llama-server -m model.gguf --port 8080

# Basic web UI can be accessed via browser: http://localhost:8080
# Chat completion endpoint: http://localhost:8080/v1/chat/completions
  • Support multiple-users and parallel decoding 
    # up to 4 concurrent requests, each with 4096 max context
llama-server -m model.gguf -c 16384 -np 4
  • Enable speculative decoding 
    # the draft.gguf model should be a small variant of the target model.gguf
llama-server -m model.gguf -md draft.gguf
  • Serve an embedding model 
    # use the /embedding endpoint
llama-server -m model.gguf --embedding --pooling cls -ub 8192
  • Serve a reranking model 
    # use the /reranking endpoint
llama-server -m model.gguf --reranking
  • Constrain all outputs with a grammar 
    # custom grammar
llama-server -m model.gguf --grammar-file grammar.gbnf

# JSON
llama-server -m model.gguf --grammar-file grammars/json.gbnf

llama-perplexity

A tool for measuring the perplexity 1 (and other quality metrics) of a model over a given text.

  • Measure the perplexity over a text file 
    llama-perplexity -m model.gguf -f file.txt

# [1]15.2701,[2]5.4007,[3]5.3073,[4]6.2965,[5]5.8940,[6]5.6096,[7]5.7942,[8]4.9297, ...
# Final estimate: PPL = 5.4007 +/- 0.67339
  • Measure KL divergence 
    # TODO

llama-bench

Benchmark the performance of the inference for various parameters.

  • Run default benchmark 
    llama-bench -m model.gguf

# Output:
# | model               |       size |     params | backend    | threads |          test |                  t/s |
# | ------------------- | ---------: | ---------: | ---------- | ------: | ------------: | -------------------: |
# | qwen2 1.5B Q4_0     | 885.97 MiB |     1.54 B | Metal,BLAS |      16 |         pp512 |      5765.41 ± 20.55 |
# | qwen2 1.5B Q4_0     | 885.97 MiB |     1.54 B | Metal,BLAS |      16 |         tg128 |        197.71 ± 0.81 |
#
# build: 3e0ba0e60 (4229)

llama-simple

A minimal example for implementing apps with llama.cpp. Useful for developers.

  • Basic text completion 
    llama-simple -m model.gguf

# Hello my name is Kaitlyn and I am a 16 year old girl. I am a junior in high school and I am currently taking a class called "The Art of

Contributing

  • Contributors can open PRs
  • Collaborators will be invited based on contributions
  • Maintainers can push to branches in the llama.cpp repo and merge PRs into the master branch
  • Any help with managing issues, PRs and projects is very appreciated!
  • See good first issues for tasks suitable for first contributions
  • Read the CONTRIBUTING.md for more information
  • Make sure to read this: Inference at the edge
  • A bit of backstory for those who are interested: Changelog podcast

Other documentation

Development documentation

Seminal papers and background on the models

If your issue is with model generation quality, then please at least scan the following links and papers to understand the limitations of LLaMA models. This is especially important when choosing an appropriate model size and appreciating both the significant and subtle differences between LLaMA models and ChatGPT:

XCFramework

The XCFramework is a precompiled version of the library for iOS, visionOS, tvOS, and macOS. It can be used in Swift projects without the need to compile the library from source. For example:

// swift-tools-version: 5.10
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "MyLlamaPackage",
    targets: [
        .executableTarget(
            name: "MyLlamaPackage",
            dependencies: [
                "LlamaFramework"
            ]),
        .binaryTarget(
            name: "LlamaFramework",
            url: "https://github.com/ggml-org/llama.cpp/releases/download/b5046/llama-b5046-xcframework.zip",
            checksum: "c19be78b5f00d8d29a25da41042cb7afa094cbf6280a225abe614b03b20029ab"
        )
    ]
)

The above example is using an intermediate build b5046 of the library. This can be modified to use a different version by changing the URL and checksum.

Completions

Command-line completion is available for some environments.

Bash Completion

$ build/bin/llama-cli --completion-bash > ~/.llama-completion.bash
$ source ~/.llama-completion.bash

Optionally this can be added to your .bashrc or .bash_profile to load it automatically. For example:

$ echo "source ~/.llama-completion.bash" >> ~/.bashrc

Dependencies

  • yhirose/cpp-httplib - Single-header HTTP server, used by llama-server - MIT license
  • stb-image - Single-header image format decoder, used by multimodal subsystem - Public domain
  • nlohmann/json - Single-header JSON library, used by various tools/examples - MIT License
  • miniaudio.h - Single-header audio format decoder, used by multimodal subsystem - Public domain
  • subprocess.h - Single-header process launching solution for C and C++ - Public domain

Footnotes

  1. https://huggingface.co/docs/transformers/perplexity ↩

About

LLM inference in C/C++

llama.app

Resources

Readme
MIT license

Contributing

Contributing

Security policy

Security policy
Activity

Stars

7 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors

Languages