llama.cpp

一句话定位

llama.cpp 是以 CPU/Mac/边缘设备为一等公民的 LLM 推理引擎，也是 GGUF 量化生态的核心运行时。

它主要负责什么

  • 加载和执行 GGUF 模型文件。
  • 提供 Q/K/I 系列量化格式的 kernel 和反量化路径。
  • 支持 GPU offload（Metal/CUDA/Vulkan），但设计起点是本地硬件。
  • 内置简单 HTTP server 能力。

它不负责什么

  • 不定义量化格式标准本身（格式由 GGUF 社区规范承载）。
  • 不做高并发 serving 平台的请求路由、autoscaling、多模型管理。
  • 不替代 Ollama 的模型管理/API 层。

在系统中的位置

1
2
3
4
5
GGUF 文件
 ↓
llama.cpp（推理引擎）
 ↓
CPU / Metal / CUDA

与类似工具比较

工具 定位 主要区别
Ollama 本地模型平台 底层常用 llama.cpp，增加模型管理/API
vLLM GPU 高并发 serving PagedAttention、Continuous Batching 是核心；GGUF 非主要生态

一次生成经过什么

1
2
3
4
5
GGUF metadata + tensors
→ tokenizer / prompt template
→ quantized matmul 与 attention
→ KV cache、采样和 stop 条件
→ CPU/GPU/Metal backend 输出 token

llama.cpp 的强项是把模型带到本地异构硬件；代价是不同 backend、量化格式、context 和 offload 组合会改变结果。比较版本时固定模型文件、线程、GPU layers、batch、context 和采样参数，否则“换引擎更快/更慢”没有可解释性。需要管理层与本地 API 时再看 Ollama。

本地执行时最容易被忽略的三个旋钮

第一是 offload 边界。n_gpu_layers 增大通常能减少 CPU↔GPU 传输，但会消耗 VRAM；当只剩很小的余量时，workspace、KV Cache 或 Metal/CUDA 临时 buffer 可能触发退化，结果比少 offload 还慢。第二是 batch/context。prompt 处理阶段需要较大的 batch 才能填满矩阵乘法，而 decode 阶段更受权重和 KV 搬运影响；一个适合短 prompt 的 -b 不一定适合长上下文。第三是线程和亲和性：CPU 推理的线程数超过物理核心或与系统后台任务争抢时，tokens/s 可能下降且尾延迟变差。

量化文件不是性能结论

同样写着 Q4 的文件，可能因 K-quant/I-quant、重要性矩阵、embedding/output 层是否保高精度而有不同大小和质量。加载成功只说明 GGUF metadata 与 tensor 能被解析，不说明 chat template、RoPE scaling、special token 或量化质量正确。最小回归应固定一组短问答、长上下文、代码和结构化输出，比较任务得分、首 token、decode tokens/s、峰值 RSS/VRAM 及生成是否提前停止。

一个可复现的本地 benchmark

1
2
3
4
5
固定 commit + GGUF checksum + prompt 文件
→ 记录 backend、n_gpu_layers、threads、batch、context
→ warmup 后分别测 prompt eval 与 generation
→ 重复短/长 prompt、1/4/8 并发
→ 保存首 token、生成速度、峰值内存和错误日志

这套记录能区分“模型变小了”与“模型真的跑快了”。如果需要多租户路由、自动扩缩容或跨节点 GPU 池化，问题已经超出 llama.cpp 的核心边界，应把它放到 serving platform，而不是继续堆本地参数。

对应的底层概念