本地跑大模型前，先问这两个问题：装得下吗？真的快吗？

为什么你的本地大模型总是翻车

很多人第一次尝试在本地跑大模型时，会栽在同一个坑里：要么硬件根本装不下模型加上上下文所需的内存，要么轻信了一个在完全不同条件下测出来的 tokens/s 数字。这不是某个产品的推销，而是一套经过反复验证的检查清单，以及一个因为懒得反复做算术而写的小工具。

问题的根源在于，人们把「内存是否装得下」和「速度到底多快」混为一谈，而这两件事需要完全不同的证据。

本地大模型运行前的两个关键问题

一、内存装得下吗？这是你自己就能算的算术题

权重、KV 缓存与余量

内存适配是一个你可以亲手计算的算术问题。从量化权重的存储大小开始，加上你实际需要的上下文对应的 KV 缓存，然后为运行时、驱动和桌面环境留出余量。一个 70B 模型在 Q4 量化下大约是 40 GB 的权重，这还没算上任何其他开销。所以「它在 24 GB 显卡上能跑」通常意味着配置会卸载到系统内存，然后运行得非常慢。

这个计算不需要任何基准测试，只需要诚实面对自己的硬件。先算清楚，再决定要不要下单。

KV 缓存是理解内存适配时最容易被忽略的部分。Transformer 在自回归生成时，每一层都要缓存此前所有 token 的键（Key）与值（Value）向量，以免重复计算，这部分显存/内存占用正比于「层数 × 2 × 隐藏维度 × 上下文长度 × 批大小 × 数据类型字节数」。它随上下文线性增长：同一个模型在 2k 上下文下可能只需几 GB，到 32k 就可能翻十几倍。这也是为什么「模型装得下」不等于「长上下文也装得下」——权重是固定开销，KV 缓存则是随你使用方式膨胀的变量。估算时通常还需为计算图、临时激活值和碎片化预留 10%–20% 余量。

量化指用更低比特的数值类型存储权重，常见格式有 GGUF（llama.cpp 生态）、GPTQ、AWQ 以及 MLX 的 4bit/8bit 方案。Q4 大致表示每权重约 4 比特，70B 参数即约 35–40 GB，还包括部分未量化的层和元数据开销。量化越低越省内存，但精度损失、是否支持特定运行时、是否支持 GPU 加速都因格式而异，这也是「同一模型、不同量化」速度与效果不能直接比较的原因。

二、速度是测量出来的，但必须带上条件

一个数字背后的七件事

速度是一个测量值，只有在附带条件时才有意义：确切的硬件、确切的检查点、量化方式、运行时及其版本、上下文和提示长度、并发数，以及这个数字是如何产生的（prefill / TTFT / decode）。单流的 decode 数字不等于八个并发请求下的吞吐量。厂商的宣传声明不等于测量结果。如果来源没有列全这些信息，诚实的答案是「未知」，而不是打一个绿色的勾。

尤其要注意：prefill 时间和 tokens/s 不能互换。如果你只有 TTFT，你看到的是一个推导出来的 prefill 估计值，应该被如此标注。

prefill、TTFT 与 decode 是描述推理性能时最常被混淆的三个指标。prefill 指模型一次性处理你输入的整个提示（prompt）的阶段，属于高度并行的矩阵运算，通常很快，其耗时决定TTFT（Time To First Token，首 token 延迟）。decode 指逐 token 自回归生成的阶段，每步只算一个 token，受内存带宽限制，是决定持续生成速度（tokens/s）的主要环节。所以「tokens/s」一般指 decode 吞吐，而「TTFT」反映的是 prefill 加排队延迟。若只给出 TTFT，你只能反推 prefill 速度，无法据此推断 decode 有多快——两者描述的是完全不同的负载特性，混用会让容量规划严重失真。

三、先选运行时，再考虑买什么

运行时决定了什么是可能的。CUDA、ROCm、Metal、Vulkan、CPU 和 NPU 是各自独立的车道，有着各自独立的下限，一条车道上存在的特性并不能证明另一条车道也有。

在 Apple Silicon 上，MLX 是原生路径；在 NVIDIA 服务器上，vLLM 或 SGLang 是吞吐路径；在 CPU+GPU 混合的机器上，面向混合专家模型的卸载运行时又是另一种权衡。先确定运行时，再去看硬件，顺序反了就容易白花钱。

把 Apple Silicon 变成 OpenAI 兼容端点

如果你用 MLX，有一个值得知道的细节：mlx-lm 自带 mlx_lm.server，一个兼容 OpenAI 的 HTTP 服务器。它暴露 /v1/chat/completions、/v1/completions 和 /v1/models，默认监听 127.0.0.1:8080，接受 --model 以及 --host / --port 参数。对于把现有 OpenAI 客户端指向你的 Mac 来说，这很方便。

重要的警告来自上游自己的说明：mlx_lm.server 只实现了基本的安全检查，不建议用于生产环境。除非你在前面加上认证和网络控制，否则请保持绑定在 localhost。单用户本地设置没问题；任何对外暴露的场景都不行。

四、把条件写下来

无论你测量了什么，都要把条件记录在数字旁边。六周之后，「42 tok/s」如果没有「M5 Max、Q4、8k 上下文、单流、mlx-lm x.y」这些信息，对你自己毫无用处，对别人则是误导。

如果你想要一个起点，有一个持续维护的参考资源把内存适配、实用上下文、实测速度、厂商声明和未知项分开呈现，并且每个数字都链接到它的来源：LocalForge。它是一个决策指南，而不是基准测试实验室——它不发布自己的数字。

常见问题

为什么 24GB 显卡跑 70B 模型会很慢？

因为 70B 模型在 Q4 量化下权重就约 40 GB，远超 24 GB 显存，必须卸载到系统内存，速度会大幅下降。

tokens/s 数字可以直接比较吗？

不能。必须确认硬件、量化方式、运行时版本、上下文长度和并发数是否一致，否则数字之间没有可比性。

mlx_lm.server 能用于生产吗？

上游明确不建议。它只实现了基本安全检查，应保持绑定 localhost，或在前端增加认证与网络控制。

背景补充

MLX 是苹果专为 Apple Silicon 统一内存架构设计的数组计算框架，能直接利用 CPU 与 GPU 共享的内存，无需显式拷贝，因此在 Mac 上往往比通用方案更高效。vLLM 与 SGLang 则是面向服务端的推理引擎，核心是 PagedAttention、连续批处理（continuous batching）等优化，把 KV 缓存分页管理以提升多请求并发下的吞吐，适合 NVIDIA 服务器场景。llama.cpp/GGUF 生态擅长 CPU 与 GPU 混合卸载，尤其适合显存不足时把部分层放到系统内存。运行时的差异不仅体现在速度，还体现在支持的量化格式、并发能力和硬件特性上，这正是「先定运行时再选硬件」的底层原因。