我把模型跑在自己的机器上，而人们总在问同一件事：我能不能本地运行 LLM，这事儿值不值得？诚实的答案比宣传口径要窄，但比犬儒更有用。本地 LLM 在硬核推理上比不过前沿模型——但那从来不是重点。重点是，有相当一部分真实工作压根不需要前沿模型，而这部分工作可以在你已经拥有的硬件上跑：离线、没有按 token 计费的账单，也没有任何数据离开这台机器。
决定它能不能成的，不是参数量——而是量化、内存和工具链，就按这个顺序。
真正的约束是内存带宽和 VRAM，而不是参数量
当人们说「我这台笔记本跑不了这个」时，他们说的通常是内存。有两个彼此独立的限制在起作用，而且两者都比单独的参数量更诚实。
第一个是容量：模型能不能塞进 VRAM（显存），或者退一步，塞进系统内存？塞进显存，生成就快。溢出到系统内存，它还能跑，但 GPU 会在总线上空等。哪里都塞不下，它就得换页到磁盘，于是彻底不可用。
第二个限制，是人们常忽略的那个：内存带宽。推理一次只生成一个 token，而每个 token 都需要把整套模型权重读一遍。所以每秒 token 数大致等于内存带宽除以模型的字节数。这就是为什么一个模型明明塞进了内存，却依然慢得让人难受：CPU 从系统内存里每秒读几十 GB，会远远落后于每秒读几百 GB 的 GPU。这也是为什么统一内存的 Mac 能越级发挥——CPU 和 GPU 共用同一个高速内存池，于是更大的模型既能装下，又能一次性流式读取。
参数量告诉你权重有多大，也就划定了门槛。带宽决定你能否快速跨过这道门槛。容量和带宽合起来，才决定什么真正跑得起来——问题不是「我的机器能不能跑 70B」，而是「我的机器能不能既装下它，又以我能忍受的速度把它流起来」。
量化：Q4 和 Q8 到底意味着什么
几乎没人用原生精度跑模型。量化把每个权重用更少的比特来存，用一点质量换取大量的体积和速度。
- FP16 / BF16——每个权重 16 比特，是参照基准。质量最高，内存翻倍。
- Q8_0——8 比特。对大多数任务来说，和基准几乎无法区分，体积却只有一半。内存不紧张时，这是稳妥的选择。
- Q5_K_M / Q4_K_M——大约 4–5 比特，用了更聪明的舍入。这是通常的默认值：明显更小，而对摘要、抽取和代码补全来说，质量损失很难察觉。
- Q3 及以下——激进。如果它是唯一能塞下的办法，那也行，但质量会肉眼可见地下降，尤其是在推理和长输出上。
有两点值得直说。第一，量化不是免费的，但在高端很便宜：Q8 和 Q5 几乎不损失什么，越往下走，损伤越会叠加。第二，那些字母很重要。朴素的 Q4_0 和 Q4_K_M 都叫「4 比特」，但表现不一样——K-quant 用了更好的方案，也是我优先选的。当一个模型有多个量化版本时，先试 Q5_K_M；如果塞不下，降到 Q4_K_M，而不是直接跳到 Q3。
还有一笔人们常忘的内存税：KV cache。你保留的每一个上下文 token，都会在内存里留下 key/value 张量，而它随上下文长度和并发数增长。一个在 4k 上下文下「塞得下」的模型，到 32k 就可能撑爆显存。量化 KV cache 有帮助；把上下文限制在你真正需要的长度，同样有帮助。
工具链：llama.cpp、Ollama、MLX 和 vLLM
四个工具几乎能覆盖一切，怎么选取决于你的硬件和耐心，而不是品牌忠诚。
llama.cpp 是其余许多工具之下的地基。它在 CPU 和 GPU 上跑 GGUF 量化模型，支持范围极广的硬件，并把最原始的旋钮交给你——卸载多少层、上下文多大、批大小多少。如果你想搞明白到底发生了什么，或者你的硬件比较少见，那就用它。代价是学习曲线。
Ollama 把那套引擎包进了大多数人想要的体验里：一个模型仓库、一条命令就能拉取并运行、一个说通用格式的本地 HTTP API。旋钮更少，默认值合理，量化模型自动替你取好。这是我会在第一天交给同事的东西；代价是控制力。
MLX 是苹果为 Apple silicon 打造的框架，在 Mac 上它是正确答案。它能正确地利用统一内存，在它所支持的模型上，往往也是 M 系列硬件上最快的选项。它的生态比 GGUF 小，所以模型可用性会滞后一些。
vLLM 是另一个极端：一个为吞吐打造的推理服务引擎，靠连续批处理让大量并发请求高效共享 GPU。一次只服务一个用户时，它是杀鸡用牛刀；服务一个团队，或跑一个批量任务时，它才让 GPU 赚回本。
大致规则是：图省事用 Ollama，要控制用 llama.cpp，Mac 上用 MLX，多人或并发请求打过来时用 vLLM。 它们不是对手；其中三个还共享着同一套底层技术。
本地 LLM 适合做什么——以及不适合做什么
规律是一致的：本地模型擅长高频、低风险、边界清晰的活，而不擅长低频、高风险、开放的活。
它今天确实能做好这些：
- 摘要与抽取。 把一份长文档、一堆笔记或一段嘈杂日志，变成一段摘要或一组字段。任务受限，来源就在手边，中等体量的量化模型能做得不错。
- 代码补全与小改动。 自动补全、样板代码、由 docstring 生成一个函数、跨文件重命名一个概念。这里延迟比聪明更重要，而本地在延迟上占优。
- embeddings。 向量检索、去重、聚类、本地 RAG 索引。embedding 模型很小，即使在 CPU 上也快，而且隐私上的收益是实打实的。这往往是最值得先跑起来的本地工作负载。
- 隐私敏感的数据。 任何你不愿发给第三方的东西——内部文档、医疗或法律文本、客户数据。在本地跑，本身就是全部意义。
它做不好的：
- 前沿推理。 硬核数学、微妙的多步逻辑、那些模型必须正确而你又难以核查的任务。差距你立刻就感觉得到。
- 长 agentic 循环。 那些要规划、调工具、从错误中恢复、连续跑几十步的 agent，需要一个能守住计划并自我纠正的模型。小的本地模型会跑偏、会打转。这是 API 仍然胜出的场景——原因可以读我怎样运行编码 agent。
- 随叫随到的广博世界知识。 更小的本地模型记住的东西就是更少。如果任务是「什么都答」，你要的是你能触达的最大的模型，而那通常意味着一颗 API。
诚实的框架是：本地是一个过滤器，不是替代品。它接下那些从来不需要前沿模型的大部分调用，好让你把 API 预算花在真正需要的那一小部分上。
一条估算显存的经验法则
内存就是门槛。大致算法：
- 权重 ≈ 4 比特下每十亿参数 0.6 GB，≈ 8 比特下每十亿参数 1.1 GB；
- 再加上 KV cache 和运行开销的空间——几个 GB 是个不错的底线，上下文长时还要更多；
- 把总量压在你的 VRAM 之下，否则就接受 CPU 速度的生成。
| 模型规模 | Q4_K_M 权重 | Q8_0 权重 | 舒适运行的位置 |
|---|---|---|---|
| 1–3B | ~1–2 GB | ~2–4 GB | 纯 CPU；抽取、分类 |
| 7–8B | ~5–6 GB | ~9–10 GB | 8–12 GB 显卡；有耐心可纯 CPU |
| 13–14B | ~9–11 GB | ~16–18 GB | 12–16 GB 显卡，或 32 GB+ 的 Mac |
| 30–34B | ~20–24 GB | ~36–40 GB | 24 GB 显卡跑 Q4；否则靠统一内存 |
| 70B+ | ~40–48 GB | ~75 GB+ | 多卡，或 64 GB+ 统一内存 |
这些数字都是近似值，会随上下文长度、KV cache 设置和具体量化版本而变——去量你自己的机器，别信表格，包括这一张。
两条命令让它更具体。用 Ollama，一切只是一个模型名：
ollama run llama3.1:8b # 拉取 + 运行；量化版本替你选好了
ollama pull nomic-embed-text # 一个小的 embedding 模型，用于本地 RAG用 llama.cpp，你精确指定你要什么：
cmake -B build && cmake --build build -j
# 直接跑一个 GGUF 量化模型；按你的显存调卸载层数。
./build/bin/llama-server \
-hf <user>/<model>-GGUF:Q4_K_M \
--n-gpu-layers 99 \
-c 8192 \
--port 8080那个改变一切的关键参数是 --n-gpu-layers。设太高会爆显存；设太低，生成就慢得像爬。针对你的卡调一次，然后就别再动了。
和 API 相比，诚实的成本账
「本地跑，免费」那帮人跳过的一点是：本地并不免费。它只是另一张账单。
API 的账单是钱。它随 token 伸缩，不需要硬件、不需要调驱动、不用做量化实验。量小的时候，它比任何硬件都便宜得多，而且你拿到的是当下最好的模型。
本地的账单是硬件加时间。你要为一张显卡或一台 Mac 一次性付费，加上电费，再加上花在构建、驱动、以及那个悄悄让一切变慢的参数上的许多小时。只有当你用得足够多时，那台硬件才「更便宜」——而「足够多」完全取决于你的用量。一天几次摘要，API 在成本上完胜，没有二话。可如果是一条持续的 embedding 流、批量分类，或者一个每敲一次键就触发的补全循环，本地在成本和延迟上都会赢。
然后还有一些东西是你根本无法从 API 买到的：绝不允许离开这台机器的数据、断网时依然可用，以及没有速率限制或按席位计费的条款横在你和你自己的工作之间。对隐私敏感的工作来说，本地根本不是一道经济选择题——它是唯一能满足要求的选项。
我的诚实立场是：两个都跑。把本地 LLM 留给私密的、高频的、需要随时可用的场景；留一个 API key 给前沿推理和长 agentic 循环。错误在于把它当成二选一。它也只是一整套设置里的一部分——其余我跑的东西都在我自托管了什么里。
我遵循的规则
- 按内存和带宽定尺寸，不按参数量。
- 从 Q4_K_M 或 Q5_K_M 起步；万不得已才往下走，并且预期会有损失。
- 预算里要算上 KV cache，而不只是权重。
- 起步用 Ollama，调优用 llama.cpp，Apple silicon 上用 MLX，服务多人时用 vLLM。
- 私密的、批量的、离线的交给本地；前沿推理和长循环交给 API。
- 在你自己的机器上实测——每一张表，包括我这张，都只是一个起点。
以上就是完整的诚实版本。你今天就能本地运行 LLM 并从中拿到真实价值——只要你选对模型、把量化做得合理，并且诚实地面对哪些活本就不该交给它。