llama.cpp

llama.cpp 是一款用于大型语言模型的 C/C++ 推理引擎，由 Georgi Gerganov 创建并于 2023 年 3 月首次发布。最初，它只是为了在没有 GPU 的 MacBook 上运行 Meta 的 Llama 模型而花了一个晚上写出的黑客项目，如今却已成为几乎所有现有本地 LLM 工具的基础架构：Ollama、LM Studio、Jan 和 AnythingLLM 都使用 llama.cpp 作为其核心推理后端。该项目采用 MIT 许可证，在 GitHub 上拥有超过 108,000 颗星，并已发布了 5,000 多个版本构建。它支持在 Apple Silicon (Metal)、NVIDIA GPU (CUDA)、AMD GPU (HIP)、用于跨厂商 GPU 支持的 Vulkan，以及具有 AVX/AVX2/AVX512 指令集优化的纯 CPU 上运行。

该引擎支持 50 多种模型架构，包括 LLaMA 变体、Mistral、Mixtral、Gemma、Phi、DeepSeek 和 Qwen。它使用 Gerganov 在 2023 年 8 月推出的 GGUF 文件格式，该格式现已成为本地 LLM 分发的通用标准。量化选项从 1.5-bit 到 8-bit 不等，使得 70 亿参数的模型能够适配不到 4 GB 的 RAM。该项目提供了一个完全兼容 OpenAI 的 HTTP 服务器 (llama-server)、一个命令行聊天界面 (llama-cli)、基准测试工具，以及通过 2025 年 4 月添加的 libmtmd 库实现的多模态推理支持。安装占用空间不到 90 MB。它没有云端依赖，无需注册账户，且任何数据都不会离开运行它的机器。

llama.cpp 在 2026 年 5 月的实际功能

当前版本（b9012，2026 年 5 月 3 日）提供了一个完整的本地推理技术栈。对于大多数开发者来说，主要的入口点是 llama-server，只需一条命令即可在 localhost:8080 启动兼容 OpenAI 的 API。任何基于 OpenAI SDK 构建的客户端都无需修改即可运行，这意味着 llama.cpp 可以直接无缝接入 VS Code 插件、Python 脚本或任何使用 /v1/chat/completions 的应用程序。

量化是使 llama.cpp 能够在消费级硬件上运行的核心技术能力。GGUF 格式将量化模型、词汇表和架构配置打包在一个文件中。对于大多数用例，默认推荐使用 Q4_K_M（7B 模型约 4.5 GB），与全精度版本相比，其质量损失微乎其微，同时在配备 8 GB RAM 的 MacBook 上能以每秒 40+ 个 token 的速度运行。对于资源受限的设备，2026 年 4 月推出的 Q1_0 格式可将性能不错的模型压缩至 1 GB 以下。对于优先考虑质量的用户，可以选择 Q8_0 或 Q5_K_M。

硬件卸载是自动处理的。当模型超出可用的 GPU VRAM 时，llama.cpp 会将其拆分：适合的层分配给 GPU，剩余部分在 CPU RAM 上处理。性能会平滑下降，而不会直接崩溃。在 Apple Silicon 上，原生支持 Metal 加速。在配备 NVIDIA 硬件的 Linux 上，默认使用 CUDA。单个二进制文件可以编译为支持 Vulkan，从而在 AMD、Intel Arc 或任何支持 Vulkan 的 GPU 上运行，无需特定厂商的驱动程序。

2026 年 4 月的版本通过 NCCL 和 RCCL 添加了与后端无关的张量并行 (tensor parallelism)，它将单个操作同时拆分到多个 GPU 上，而不仅仅是划分模型层。对于多 GPU 配置，与旧的层划分方法相比，这带来了 3-4 倍的吞吐量提升，使得 llama.cpp 越来越适合小型生产部署，而不仅仅是个人使用。同月，发布了 Walsh-Hadamard KV 缓存旋转技术，将 Q4_0 量化下的 AIME25 推理基准分数从 0.0% 提升至 21.7%，这对于多步推理任务的量化推理来说是一个显著的改进。

模型下载直接与 Hugging Face 和 Docker Hub 集成。将 Hugging Face 模型 ID 传递给 llama-server 即可拉取 GGUF 文件并启动服务器。由于 Hugging Face 原生索引 GGUF 文件，这适用于数千个社区量化的模型，无需任何转换步骤。

"我成功在单台 8G 内存的 Pi4 上运行了 13B 数据集……这就是目前在家中利用现有设备实现可复现 LLM 的现实。" - cameron_b，Hacker News，2023 年 9 月

llama.cpp 与 vLLM 和 MLX 的定位对比

llama.cpp vs. vLLM： 这两个工具服务于部署领域的不同极端，很少在同一用例中竞争。vLLM 是一个基于 Python、专注于 GPU 服务器的推理框架，围绕连续批处理 (continuous batching) 和 PagedAttention（一种在页面级别管理 KV 缓存内存的机制）构建。在峰值负载下的 NVIDIA H200 上，与 llama.cpp 相比，vLLM 的请求吞吐量提高了 35 倍，每秒 token 输出提高了 44 倍，但这种比较仅在企业级硬件上有 10 个以上并发用户时才成立。对于单用户或低并发工作负载，llama.cpp 的 token 间延迟要低得多，因为它不批处理请求。vLLM 需要 CUDA，并且无法在消费级硬件、Windows 桌面或 Apple Silicon 上有效运行。而 llama.cpp 可以在任何地方运行。如果您要在具有 5 个以上并发用户的专用 GPU 服务器上部署生产 API，请比较 vLLM；对于其他所有情况，llama.cpp 才是正确的选择。

llama.cpp vs. MLX： MLX 是 Apple 自己的机器学习框架，针对 Apple Silicon 芯片的统一内存架构进行了优化。由于 CPU 和 GPU 在 Apple Silicon 上共享相同的物理内存，MLX 实现了零拷贝张量操作，消除了 llama.cpp 在 Metal 着色器之间移动数据时产生的数据传输开销。在运行 Llama 3.1 8B (Q4_K_M) 的 M2 Pro 上，MLX 达到约每秒 45-58 个 token，而 llama.cpp 为 38-48 个。对于仅限 Mac 的开发工作流来说，这种差距很重要。MLX 还支持原生的 LoRA 和 QLoRA 微调，而 llama.cpp 不支持。关键的限制在于：MLX 仅支持 Apple Silicon。它不能在 Windows、Linux 或 Android 上运行。它还需要从 GGUF 格式进行模型转换，而社区模型通常首先以 GGUF 格式出现，MLX 转换会滞后数小时或数天。llama.cpp 在发布首日即可支持社区的新版本，并在任何硬件上运行。

"刚从 ollama 切换过来，token 生成速度和效率的提升非常显著。" - 用户评论，itsfoss.com，2025 年

日常推理工作流是怎样的

运行模型的最简路径只需三步：从 Hugging Face 下载 GGUF 文件，运行 llama-server -m model.gguf，然后访问 localhost:8080/v1/chat/completions。在快速存储设备上，服务器启动时间不到 5 秒。停止并使用不同模型重新启动所需的时间相同。没有守护进程管理，没有模型注册表，也没有在空闲时消耗资源的后台服务。

对于交互式使用，llama-cli -m model.gguf --interactive 会打开一个终端聊天会话。语法约束允许您强制输出 JSON 或将响应限制为定义的模式 (schema)，这对于结构化数据提取管道非常有用。上下文窗口长度可通过命令行标志进行配置，受限于可用 RAM。

2024 年引入的 Web UI 提供了一个由 llama-server 托管的基于浏览器的聊天界面。它支持多轮对话、系统提示词配置和参数调整，而无需接触命令行。它不如 LM Studio 的界面那么精美，但它可以在任何浏览器中运行，并且除了服务器二进制文件之外无需任何安装。

对于在 llama.cpp 之上构建应用程序的用户，VS Code 和 Vim/Neovim 插件作为项目的一部分提供，通过本地 llama-server 端点路由代码补全请求。OpenAI 兼容层意味着任何接受自定义基础 URL 的工具（如 AnythingLLM 或 Continue.dev）都无需更改配置即可连接。

llama.cpp 是为谁构建的

llama.cpp 面向希望完全控制其推理技术栈，并愿意花 30-60 分钟进行初始设置的开发者和技术用户，以避免云端依赖、按 token 计费的成本或高级工具添加的抽象层。无法或不愿将数据发送到外部 API 的注重隐私的用户依赖于它。在消费级硬件上运行实验的研究人员使用它来访问云提供商提供的相同模型权重，且每次查询的边际成本为零。嵌入式和边缘开发者将其编译用于 Raspberry Pi、Android（自 2026 年 4 月起通过 Qualcomm Hexagon 提供原生加速）和 ChromeOS 设备。

其在生态系统中的重要性怎么强调都不为过：即使是从未直接接触过 llama.cpp 的用户，如果他们使用任何本地 LLM 前端工具，也很可能正在运行它。了解 llama.cpp 是什么有助于用户理解他们的推理实际发生在哪里，为什么某些 GGUF 量化级别在他们的硬件上运行得更好，以及如何调试他们的 GUI 包装器未暴露的性能问题。

将 llama.cpp 直接与 Meta 的 Llama 模型 搭配使用的用户将获得最全面的兼容性，因为该项目最初是为 Llama 构建的，并且两者在支持新架构方面保持高度一致。Hugging Face 上的社区模型生态系统（每个主要的开放权重版本都有数千个 GGUF 量化版本）实际上使 llama.cpp 成为任何新模型发布后数小时内的首选入口。

llama.cpp 不是什么

llama.cpp 不是一个图形化应用程序。期望通过点击来管理模型的用户会发现 CLI 难以适应。LM Studio 和 Jan 的存在正是为了在 llama.cpp 的推理引擎之上添加 GUI 层。

它不是一个大规模的多用户推理服务器。该引擎按顺序处理请求。在 5 个或更多并发用户时，队列延迟呈指数级增长。对于具有实际并发需求的生产 API 服务，vLLM 或托管端点更为合适。

它不是一个微调工具。没有训练循环，没有 LoRA 实现，也没有数据集管道。如果您需要微调模型，这项工作需要在 Python 框架（PyTorch、MLX、Axolotl）中进行，然后将生成的权重转换为 GGUF 以进行推理。

它不是一个模型中心或发现工具。llama.cpp 不负责整理或推荐模型。用户在 Hugging Face 或通过 r/LocalLLaMA 等社区资源寻找模型，然后直接下载 GGUF 文件。

在生态系统中明确归属问题也很重要。许多 Ollama 或 LM Studio 的用户并未意识到这些工具的推理依赖于 llama.cpp。社区中一直存在一种不满情绪（在 GitHub issue #3185 中浮出水面，并在 Hacker News 上被反复讨论），即 Ollama 没有在其文档或面向用户的界面中明确归功于 llama.cpp。这一点很重要，因为性能问题、量化行为和支持的模型架构都是 llama.cpp 的属性，而不是包装工具的属性。了解 llama.cpp 是实际的引擎，能为用户提供用于调试和优化的有意义的词汇。

实际意义在于：如果您直接在 Ollama 和 llama.cpp 之间做出选择，您并不是在不同的推理引擎之间进行选择。您是在同一推理引擎的不同抽象级别之间进行选择。对于大多数用户来说，Ollama 的简单性胜出。对于需要调整参数、构建自定义管道或运行 Ollama 注册表中没有的模型的开发者来说，直接访问 llama.cpp 才是合适的工作层级。