同一个模型，在同事的电脑上唰唰地出字，在你的电脑上却一个字一个字往外挤。打开 ollama ps 一看，写着 35%/65% CPU/GPU。
这到底意味着什么？为什么只有三成放在 CPU 上，速度却掉了一大截？
要回答这些问题，得往 Ollama 的下面看一层。
学完这一节，你能做到：说清楚 Ollama、LM Studio 底下那个共同的引擎是什么；
用一个公式估算任何机器的速度上限；读懂 --verbose 的测速结果；
以及理解为什么模型一旦溢出显存，速度就会断崖式下跌。
一、Ollama底层：llama.cpp
1. 它是什么
llama.cpp 是一个用 C/C++ 写的大模型推理引擎，由 Georgi Gerganov 在 2023 年 3 月开源
截至 2026-11-01，它在 GitHub 上有约 13 万 star。
它做成了两件当时很难的事：
- 不依赖 Python 和庞大的深度学习框架，让普通笔记本的 CPU 也能跑大模型。
- 支持几乎所有硬件：NVIDIA 的 CUDA、苹果的 Metal、AMD 的 HIP、通用的 Vulkan，连华为昇腾的 CANN、摩尔线程的 MUSA 也在官方支持的后端列表里。
它还定义了 GGUF 文件格式：一个文件里装着权重、模型结构信息和分词器，拿到就能跑。从魔搭下载的 .gguf 文件就是这种格式，后面还会讲到格式转换和量化。
Ollama 的 README 里写明，它支持的后端就是 llama.cpp；
LM Studio 跑 GGUF 模型用的是 llama.cpp；Jan 也建立在 llama.cpp 之上。
同一个模型在这几个工具里速度差不多，原因就在这里。
2. 直接用一下
官方提供了一键安装脚本，macOS 和 Linux：
curl -LsSf https://llama.app/install.sh | shWindows（PowerShell）：
irm https://llama.app/install.ps1 | iex也可以去 GitHub 的 Releases 页面下载编译好的压缩包，按你的系统和显卡选对应的版本。
装好后，直接从 Hugging Face 下载一个模型并开始对话：
llama cli -hf ggml-org/Qwen3.5-0.8B-GGUF换成 serve，就是一个 OpenAI 兼容的服务：
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF服务默认只监听 127.0.0.1，端口 9931。调用它时，把 LLM_BASE_URL 改成 http://127.0.0.1:9931/v1，其余代码不用动。
你会在很多文档和压缩包里看到 llama-cli、llama-server 这种带连字符的名字，和上面的写法做的是同一件事。
国内下载 Hugging Face 慢的话，先从魔搭把 GGUF 文件下载到本地，再用 -m 文件路径 代替 -hf 模型名。
3.为什么还要了解llama.cpp
日常使用，Ollama 确实更省事。
llama.cpp 可以让你更加定制化，因为 OLlama 帮你做了一些决定，那些决定可能是你不需要的。
llama.cpp 会在后面反复出现：用自己的模型做 GGUF 转换和量化时要用它的工具；
比较推理服务器时，llama.cpp server 也是候选之一。
二、生成回答的两个阶段
1.预填充（prefill）
你按下回车之后，模型做了两件性质完全不同的事。
第一步是读题，叫预填充（prefill）。模型把你的整段提示词一次性读进去
提示词里的所有 token 可以并行处理，所以很快，一般每秒几百到几千个 token。它决定了你要等多久才看到第一个字，也就是首字延迟。
2.解码（decode）
第二步是答题，叫解码（decode）。模型一个 token 一个 token 地往外生成，每生成一个，都要依赖前面已经生成的所有内容，没法并行。
这一步慢得多，也是你感受到的"打字速度"。
打个比方：考试时读题，你可以一眼扫过一整段；写答案却只能一个字一个字写，而且每写一个字，都要把整本参考书从头到尾翻一遍。
最后那半句不是夸张。每生成一个 token，模型都要把全部权重从显存里读一遍。权重有 5GB，就要读 5GB。所以决定解码速度的，主要不是显卡算得多快，而是显存读得多快，也就是内存带宽
3.内存带宽
内存带宽，就是存储每秒能把多少数据送到计算单元手里，单位是 GB/s。
它和容量是两回事。16GB 说的是能装多少，288 GB/s 说的是每秒能搬多少。