llama.cpp

LLM inference in C/C++

manifesto / ggml / ops / maintainer PRs / compile times / lib llama API / llama-server REST API

Quick start

A few options to get llama.cpp installed on your machine:

• Visit https://llama.app and follow the instructions
• Run with Docker - see our Docker documentation
• Download pre-built binaries from the releases page
• Build from source by cloning this repository - check out our build guide

Once installed:

# Download and run a model directly from Hugging Face
llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF

# Launch OpenAI-compatible API server
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

VLM session with llama cli

Built-in web UI against llama serve

Description

The main goal of llama.cpp is to enable LLM (and VLM) 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 build on top of the ggml library.

Supported backends

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

Documentation

Tools

• cli
• completion
• server
• GBNF grammars

Development

• How to build
• Running on Docker
• Build on Android
• Multi-GPU usage
• Performance troubleshooting
• GGML tips & tricks
• XCFramework
• Completions
• Models
• Release process

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!
• Read the CONTRIBUTING.md for more information

Acknowledgements

• 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

Branches

• master https://github.com/zhouwg/ggml-hexagon/tree/master, track upstream llama.cpp project.

• self-build-jz https://github.com/zhouwg/ggml-hexagon/tree/self-build-jz, the default branch, Qualcomm's ggml-hexagon & jz(jeff zhou)'s ggml-hexagon can be found in this branch.

Why jz's ggml-hexagon backend is still meaningful?

• The implementation of the prebuilt libggmldsp-skel.so is complicated&dirty: last year I built a closed-source version by porting a full ggml-core to Qualcomm's DSP/NPU side (supporting fully quantized & non-quantized mulmat op, theoretically supporting all ggml ops). The open-source code of libggmldsp-skel.so can now be found in JZ's ggml-hexagon at ggml/src/ggml-hexagon/kernels/ - including the FastRPC entry point (entry.c) and session context (dsp-ctx.h).
• The data path in Qualcomm's official ggml-hexaon backend is completely/exactly similar to my implementation in this forked llama.cpp project or my PR in the upstream llama.cpp project.
• Qualcomm's official ggml-hexagon backend uses a Qualcomm dedicated technology dspqueue to exchange data between ARM AP side and DSP(cDSP or HTP or NPU, these are different names for the same thing in Qualcomm's tech world) side. we know that the so-called async dspqueue framework is a highlevel wrapper of the native FastRPC mechanism and LLM inference is essentially synchronous and ION share memory is a same DDR region which can be "seen" by OS in AP side and OS in NPU side at the same time, so we can implement a concise&efficient solution for purose of offload multiple op(or a fully single cgraph) to Hexagon NPU based on the native/pure FastRPC mechanism, this concise solution will also reduce FastRPC overhead observably.
• On Snapdargon 8 Elite(aka 8Gen4) phones, PP and TG performance in JZ's ggml-hexagon surpasses Qualcomm’s official ggml-hexagon since 07/21/2026 #18 (comment) code is available on GitHub.
• AI large model company can use the self-build-jz branch for real testing instead of just running benchmarks if any AI large model company thinks their AI model is really good.

How to build the jz's ggml-hexagon backend for Snapdragon-based Android device

Pls refer to about ggml-hexagon

How to do performance comparison of PP and TG between Qualcomm's ggml-hexagon and JZ's ggml-hexagon

Pls refer to about ggml-hexagon

RFC 26227: Introduce JZ's ggml-hexagon

Pls refer to RFC 26227: Introduce JZ's ggml-hexagon