OPEN SOURCE DEEP DIVE
llama.cpp：17 个后端、1.5 到 8 比特量化，把 LLM 推理带到任何有编译器的地方
MIT 许可、构建在 ggml 上的纯 C/C++ 推理实现，无任何依赖。17 个后端覆盖 CUDA/Metal/HIP/Vulkan/SYCL/WebGPU/CANN/Hexagon/MUSA/zDNN/ZenDNN；1.5-8 比特整数量化；CPU+GPU 混合推理让超出显存的模型也能跑；GGUF 是它输出的事实标准权重格式，连 vLLM 都直接吃。llama cli / llama serve 两行起一个 OpenAI 兼容服务。
没有依赖的 C/C++：把推理从数据中心搬回笔记本
llama.cpp 是 MIT 许可的纯 C/C++ LLM（与 VLM）推理实现，构建在 ggml 张量库之上，README 的第一条自我描述就是「没有任何依赖的纯 C/C++ 实现」。这个选择的代价是放弃了 PyTorch 生态的现成算子，收益是它可以被编译到几乎任何有编译器的地方——从数据中心 GPU 到手机、树莓派、浏览器和 IBM 大型机。它也是 GGUF 权重格式的事实标准出处，vLLM 把 GGUF 列入支持的量化格式，等于承认了这个格式已经越过项目边界。
它的主要目标写得很清楚：以最少的安装步骤，在尽可能宽的硬件上拿到尽可能好的性能，本地和云端都算。上手路径也确实是四选一：llama.app 引导安装、Docker、releases 页的预编译二进制、或克隆源码自行构建。装好之后两行命令就能跑：
llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF # 直接从 Hugging Face 拉模型跑对话
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF # 起一个 OpenAI 兼容的 API server17 个后端：覆盖面是它的核心资产
后端列表是这个项目最值得逐行读的部分，因为它等于一张「AI 推理能在什么硬件上发生」的地图：
| 后端 | 目标设备 |
|---|---|
| CUDA | NVIDIA GPU（自研 CUDA 核） |
| Metal | Apple Silicon（一等公民，走 ARM NEON、Accelerate 与 Metal） |
| HIP | AMD GPU |
| Vulkan / OpenCL / WebGPU | 通用 GPU、Adreno GPU、浏览器与任意支持 WebGPU 的设备 |
| SYCL / OpenVINO（开发中） | Intel GPU、Intel CPU/GPU/NPU |
| CANN | 华为昇腾 NPU |
| Hexagon | 高通 Snapdragon |
| MUSA | 摩尔线程 GPU |
| IBM zDNN | IBM Z 与 LinuxONE 大型机 |
| ZenDNN | AMD CPU |
| BLAS / BLIS / VirtGPU / RPC | 通用 CPU 与跨进程/跨机分工 |
CPU 侧的指令集支持同样铺得很宽：x86 的 AVX、AVX2、AVX512 与 AMX，RISC-V 的 RVV、ZVFH、ZFH、ZICBOP、ZIHINTPAUSE。AMX 在列意味着它认真考虑了在服务器 CPU 上做矩阵乘，而不只是把 CPU 当成 GPU 的配角。
低比特量化与 CPU+GPU 混合推理
量化档位给到 1.5、2、3、4、5、6、8 比特整数量化。1.5 比特这一档是 llama.cpp 社区最有辨识度的贡献之一：它用混合精度把部分权重压到平均每参数 1.5 比特附近，让原本不可能在消费级内存里驻留的模型变得可以跑，代价是明显的质量退化——这是拿智力换可达性的极端案例，本站把它归入 llm 域正是因为「换掉它，每 token 成本和模型智力都会变」。
另一项同样重要的是 CPU+GPU 混合推理：模型大于总显存时，把部分层放在内存里由 CPU 算，其余交给 GPU。这让「一张消费级显卡跑一个远超显存的模型」从不可能变成慢但可用。它不是性能特性，是可达性特性——扩大的是能跑起来的机器集合，而不是让已经能跑的机器更快。
工具面与它在栈里的位置
仓库自带的工具是 cli（交互对话，支持 VLM 会话）、completion、server（OpenAI 兼容 REST API，并内置一套 Web UI），语法约束走 GBNF 文法。文档里另有 Android 构建、多 GPU 使用与 token 生成性能排查指南。
定位上说清楚一件事：llama.cpp 不是集群服务引擎，它和 vLLM / SGLang 不在同一个岗位上竞争。后两者优化的是多请求并发下的聚合吞吐与每 token 成本；llama.cpp 优化的是单用户、单机、尽可能少的依赖下能不能跑起来、跑得多顺。所以本地开发者工具链（Ollama、LM Studio、Jan 等）几乎都把它当底层，而生产服务栈通常选 vLLM 或 SGLang。同一个模型经常两边都要部署：开发期在本地 GGUF 上迭代，上线换成服务端引擎跑 FP8 或 NVFP4。
版本节奏是持续的 nightly（releases 页用 b* 标签发夜间构建，v* 发正式版），这也是它和学术出身项目的差别：它按工具的节奏发布，不按论文的节奏。