Skip to content

NovNovikov/llama-cpp-turboquant-mtp

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

9,910 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

llama.cpp Fork

llama

License: MIT Release Server Docker Winget

Manifesto / ggml / ops

Upstream-first fork of ggml-org/llama.cpp with a small set of local runtime, speculative decoding, model support, and server patches kept on top of fresh upstream syncs.

Fork status

  • Default branch: feature/prefill-checkpoints
  • Archived TurboQuant branch: archive/turboquant-prefill
  • Base: regularly synced with upstream ggml-org/llama.cpp
  • Goal: stay close to upstream while keeping a few targeted fixes and experimental features that are useful in long-context server workloads

What is different in this fork

This fork is not a general rewrite of llama.cpp. The intent is to keep the default branch close to upstream and only carry changes that are either:

  • practical fixes for long-running server usage
  • local speculative decoding work that is not fully available upstream yet
  • model support that is useful locally but not in upstream master

Everything below this section remains the upstream llama.cpp README. The sections here document the fork-only behavior.

Local patches and features

1. Server prefill and chat-template fixes

  • Assistant prefill is preserved for chat completions when enable_thinking or similar chat-template flows would otherwise suppress it.
  • The server keeps behavior closer to "final rendered prompt goes in, model sees it unchanged" instead of locally dropping assistant-prefill text during request assembly.
  • This is mainly relevant for OpenAI-compatible /v1/chat/completions workloads using Jinja/chat templates.

2. Restored broad checkpoint scheduling for long contexts

This fork keeps a more aggressive and more practical checkpoint strategy for long prompts, especially for SWA / hybrid / recurrent-style models where tail-only checkpoints are often useless.

Local behavior includes:

  • restored periodic prompt checkpoint scheduling via -cpent, --checkpoint-every-n-tokens
  • checkpoint spacing control via --checkpoint-min-step
  • retention logic that prefers keeping useful anchor checkpoints instead of only the newest tail checkpoints
  • safer checkpoint invalidation after restore, bounded by actual prompt divergence instead of blindly wiping everything after the restored point
  • post-midpoint checkpoint spacing adjustments intended to reduce checkpoint churn during very long prefills

Relevant server options exposed by this fork:

  • -ctxcp, --ctx-checkpoints, --swa-checkpoints
  • -cpent, --checkpoint-every-n-tokens
  • --checkpoint-min-step

3. Draft-MTP / speculative stability fixes

The default branch keeps a set of local speculative-decoding fixes on top of upstream:

  • speculative draft/MTP contexts do not export embeddings or pooling state unnecessarily
  • draft-mtp avoids exporting target nextn state where that caused instability
  • draft-mtp state is persisted across checkpoint restore
  • local server/CLI fixes were kept to make current Qwen / Gemma speculative paths less brittle in checkpointed and resumed sessions

These changes are practical runtime fixes, not a promise that every upstream or third-party draft model format is supported.

4. DSpark speculative decoding support

This fork carries local DSpark support beyond upstream master.

Current state:

  • dspark architecture is present in the runtime
  • speculative decoding path for DSpark is implemented locally
  • Qwen-side conversion support exists for standalone DSpark draft checkpoints
  • DSpark block-size metadata handling from the upstream PR line is included

Important limitation:

  • current DSpark support in this fork still follows the "separate draft model" design
  • embedded DeepSeek-V4-Flash-DSpark packaged inside a single target model is not fully supported yet

In other words: DSpark is present here, but the "DeepSeek model with DSpark baked into the same checkpoint" path still needs dedicated work.

5. DeepSeek4 / DSV4 performance work

The fork carries a sizable set of local DeepSeek4-specific runtime changes aimed at reducing prompt-processing cost and making DSV4 paths actually usable.

Highlights:

  • GGML_OP_LIGHTNING_INDEXER support in the runtime
  • CUDA kernel for LIGHTNING_INDEXER
  • local DeepSeek4 wiring for lightning indexer usage
  • restored top-k mask shortcut path
  • fused HC ops for DeepSeek4 CUDA path
  • flash-attention mask trimming / cast cleanup and prompt-tail rebalancing
  • several reserve / scheduling / graph-shape adjustments around DeepSeek4 prefill behavior

This area is the most experimental part of the default branch. It is useful, but it is also the place where local performance tuning and upstream churn most often meet.

6. Laguna model support

This fork adds local Laguna support that is not in plain upstream master:

  • Laguna architecture runtime support
  • Laguna converter support
  • Laguna chat template support
  • Laguna GGUF tensor mapping / metadata handling
  • mixed-RoPE / SWA-related runtime pieces needed by that model family

Relevant files include:

  • src/models/laguna.cpp
  • conversion/laguna.py
  • models/templates/poolside-Laguna.jinja

7. Extra server debug logging

This fork keeps a local generated-output logging feature in addition to upstream prompt logging:

  • --log-generated-output [PATH]

Behavior:

  • appends one JSONL record per chat/completion request
  • defaults to ./output.log when the path is omitted
  • intended for debugging rendered-output issues without changing generation behavior

This exists alongside upstream --log-prompts-dir, not instead of it.

8. Additional low-level fixes carried by the fork

The branch also carries a few targeted runtime/backend fixes that were valuable locally when they were not yet available in the chosen base revision:

  • CUDA top_k / argsort chunking to reduce temporary memory pressure
  • KQ-mask stride overflow / truncation fixes in flash-attention-related CUDA code
  • tensor-parallel plus --n-cpu-moe crash fix on MoE models
  • universal CUDA launch bounds for MoE MMVQ kernels

Some of these may later disappear from the fork as they land upstream and the branch is rebased or merged forward.

What is intentionally not on the default branch anymore

TurboQuant-specific KV and weight quantization support is no longer part of the default branch.

That work is kept in:

  • archive/turboquant-prefill

Reason:

  • it made the branch diverge too far from upstream
  • it complicated merges and speculative/runtime work
  • the current default branch is intentionally "upstream plus targeted fixes", not "everything ever experimented with"

Stability notes

Not every local feature has the same maturity level.

Generally:

  • checkpointing and prefill fixes are part of the expected default-branch behavior
  • generated-output logging is debug-only
  • Laguna support is functional model support
  • DeepSeek4 and DSpark changes are the most actively tuned and therefore the most likely to change between syncs

If you need the most upstream-like behavior, use this branch with fork-specific options disabled where possible. If you need the historical TurboQuant line, use the archived branch instead of expecting it from the default branch.

Why this fork exists

Upstream llama.cpp moves fast. Some locally important fixes are too niche, too experimental, or too timing-sensitive to wait for clean upstream landing.

This fork exists to keep:

  • fresh upstream llama.cpp
  • practical long-context server fixes
  • local speculative-decoding work
  • a few model families and runtime paths that are useful here but not fully covered upstream yet

without permanently turning the project into an unrelated downstream.

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

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/

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

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

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)

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

Fresh llama.cpp fork with TurboQuant, assistant-prefill and long-context checkpoint fixes, plus llama-server prompt/output debug logging.

Resources

License

Contributing

Security policy

Stars

0 stars

Watchers

0 watching

Forks

Packages

 
 
 

Contributors