第一章 Llama C++ 简介
聊 Llama C++ 之前，咱们先说说它从哪冒出来的。
2023 年初，Meta 开源了 Llama 1 模型。那会儿大家都在琢磨怎么在本地跑起来。可惜原版是 Python + PyTorch，显存要求高，推理慢。我第一回在笔记本上试，风扇直接起飞，程序跑了十分钟就崩了——内存溢出。
后来有个叫 Gerganov 的老哥，写了个 ggml 张量库。他嫌 Python 太重，干脆用 C++ 重写了一套推理引擎，这就是 llama.cpp 的雏形。说实话，这项目刚出来时看着挺糙的，就几个 .cpp 文件，连 README 都很简短。但跑起来的那一刻，我确实被震住了：一个 7B 模型居然能在 16GB 内存的 MacBook 上流畅运行。
1.1 项目的起源
llama.cpp 的根，扎在 ggml 这个库上。ggml 是个轻量级张量计算框架，支持多精度量化、异构计算。说白了，它就是个给大模型量身定做的数学库。
为什么不用 PyTorch？你想想看，PyTorch 为了灵活性，做了大量抽象，模型加载慢，显存还收不住。而 ggml 要的就是极致简洁：
- 零外部依赖——不需要 Python、CUDA、cuDNN，甚至不需要 OpenBLAS
- 内存可控——申请多少用多少，不给你打肿脸充胖子
- 支持量化——4-bit / 5-bit / 8-bit，按需压缩模型
我记得在 2023 年 4 月，Gerganov 把 llama.cpp 合并进了主仓库。社区一下就炸了。Issue 里全是「能跑 LLaMA 65B 了吗」「Windows 上怎么编译」。到 2024 年底，项目已经积累了 60k+ Star，衍生出上百个生态项目。
核心里程碑：
- 2023.02 — 首个 commit，支持 LLaMA 7B 推理
- 2023.03 — 加入 quantization 量化支持
- 2023.06 — 推出 server 模式，首次暴露 HTTP API
- 2024.01 — API 兼容 OpenAI 格式，彻底出圈
1.2 代码仓库结构
项目根目录看着东西挺多，但真正核心的就几个。我经常跟新人说：别怕，认准这四个文件夹和三个 .h 文件就够用了。
| 目录 / 文件 | 作用 |
|---|---|
llama.cpp |
推理核心代码，负责加载模型、前向推理、采样 |
ggml/ |
张量计算引擎，包含 CPU / Metal / CUDA 后端 |
common/ |
工具函数：分词、参数解析、日志、KV cache 管理 |
examples/ |
示例程序，包括 main（命令行对话）、server（HTTP 服务）、embedding 等 |
llama.h |
对外头文件，API 都在这里声明 |
ggml.h / ggml-alloc.h |
ggml 底层接口，做资源分配和计算图管理 |
别慌，你不需要把每个文件夹都啃透。我们做 API 实战时，主要跟 llama.h 和 examples/server/ 打交道。
llama.h 看，只要这个头文件不变，上层应用基本不用改。
1.3 核心设计理念
说到底，llama.cpp 的设计思路就三个词：轻、快、可控。
1. 纯 C/C++ 实现，零依赖
不依赖 GPU 厂商的 SDK？那矩阵乘法怎么写？答案是手写 SIMD 指令。你在 ggml/src/ggml.c 里能看到大量 AVX2、NEON、Metal 的汇编片段。这很硬核，但也保证了跨平台移植性。
我曾经在树莓派上试过，编译只需要两三分钟，跑一个 1.5B 的 Qwen 模型，每秒能吐六七个 token。换 PyTorch ？根本启动不了。
2. 分片加载，一行代码从未变过
大模型动辄几十 G，全量加载太耗内存。llama.cpp 支持分片加载：把模型从磁盘按层逐一读到内存。你甚至可以在 8GB 内存的机器上跑 7B 模型，代价就是慢一点。
我自己写过一个避坑指南：
分片加载需要提前指定 --host 和 --port，否则 server 模式会默认阻塞等待所有片加载完才开始监听。如果你用 Docker 部署，务必加上 -p 映射端口时就把参数配好。
3. 量化优先，精度换性能
原版 LLaMA 7B 模型权重约 13GB（FP16）。量化到 4-bit 后只有 3.9GB，推理速度反而更快——因为内存搬移少了。llama.cpp 内置了十几种量化方案：
- q4_0 / q4_1：4-bit 量化的两种变体，质量损失可控
- q5_0 / q5_1：5-bit 量化，比 4-bit 精度高，文件稍大
- q8_0：8-bit 量化，几乎无损，适合做 baseline
- f16：半精度，不做压缩，但需要 GPU 才能跑快
你可能会问：「选哪种最好？」我的经验是：
做聊天机器人用 q4_0 就够了，模型小、速度能接受。做代码补全或 RAG 场景，建议上 q5_1 或 q8_0，精度敏感时更稳定。
4. 内存即显存，CPU 当 GPU 用
llama.cpp 不要求你有独立显卡。它利用 CPU 的内存带宽 + SIMD 指令做推理。道理很简单：显存贵，内存便宜。你把模型塞进 DDR5，一样能推理，带宽够用就行。
我出差时经常在轻薄本上跑 7B 模型，虽然每秒只有 3-4 token，但至少能离线用。你想想看，这要是换成 GPU 方案，一本笔记本电脑根本带不动。
这张图梳理了 llama.cpp 内部的工作流：从模型加载 → 量化选择 → 上下文管理 → 推理执行 → 输出采样 → 暴露为 OpenAI 兼容的 HTTP API。你看，最下面还垫着 ggml 引擎，负责跟硬件打交道。
1.4 为什么选它做 API 实战
市面上推理框架不少，比如 vLLM、TGI、Ollama。为什么我偏拿 llama.cpp 来讲？说实话，因为它最简单。
- 编译快——
make一行搞定，不用折腾 CUDA 版本匹配 - 部署灵活——单个可执行文件 + 模型文件，tar 一下就能丢服务器上跑
- API 标准——/v1/chat/completions 接口跟 OpenAI 完全一致，迁移成本为零
- 资源友好——你甚至可以在 OCI 的免费 ARM 实例上跑 7B 模型
我去年接了个客户，要求在他们内网部署一个离线问答系统。客户机是 8 核 16GB 的 Ubuntu，没显卡。试了一圈，只有 llama.cpp 能跑起来。
一句话总结：llama.cpp 不是最快的推理框架，也不是功能最全的。但它是最容易在个人硬件上跑起来、最贴近 OpenAI 接口、最省心的方案。
嗯，第一章就先说到这。咱们从背景到结构，把 llama.cpp 的底子铺了一遍。后面几章会一步步搭起一个完整的 API 服务，从编译、量化、启动到调优。放心，不会让你空手而归的。