单卡部署：权重、显存与上下文预算

“能在单卡上跑”可能只是权重勉强加载，也可能是借助 CPU 卸载完成短请求，或是在所需上下文长度下达到交互速度。判断配置是否实用，要看任务需要多少内存、多长的上下文，以及能接受多大的延迟。交互式编程和夜间批处理，对速度的要求并不相同。

本页解决容量问题：设备中需要放下什么，上下文和并发增加后会发生什么。带日期的候选模型清单只放在编码模型选型；数值格式和速度分析分别见模型量化与推理性能。

先算显存预算

原始权重的显存占用大致为：

$$\text{weight bytes}\approx\frac{\text{parameter count}\times\text{bits per weight}}{8}.$$

以 27B 参数量的模型为例，4-bit 量化后权重本身约需 12.6 GiB。但这还没算量化元数据、高精度张量、运行时工作区以及 KV 缓存。如果已有现成的量化文件，直接看文件大小比单纯计算参数量更准确。

对于传统的 MHA 或 GQA 架构，单个序列的 KV 缓存占用约为：

$$2\times L\times S\times d_{kv}\times b,$$

其中系数 2 指 Key 和 Value 各存一份，$L$ 是层数，$S$ 是保留的序列长度，$d_{kv}$ 是每层的键/值宽度，$b$ 是每个元素的字节数。

代入 Llama 3 8B 的形状：32 层，每层 8 个键值头、每头 128 维，键值宽度是 1024；每个数用 BF16 存，占 2 字节。一个 token 要存 2×32×1024×2 = 131,072 字节，也就是 128 KiB。上下文到 32K 个 token 时是 4 GiB，到 128K 时是 16 GiB，和这个模型全部 BF16 权重（80 亿×2 字节 = 16 GB）差不多大。所以公布的上下文上限，不意味着整个窗口能塞进单张 GPU、运行迅速或保持足够的任务质量。更多算例见 KV 缓存笔记。

公式里的 $b$ 是自己能改的。Ollama 用 OLLAMA_KV_CACHE_TYPE 设缓存精度，文档说 q8_0 约占默认 f16 的一半内存，q4_0 约占四分之一，前提是开着 Flash Attention。上面 128K 的 16 GiB 缓存，换成 q8_0 约是 8 GiB；q4_0 省得更多，质量损失也更大。

MLA 等其他注意力机制的缓存布局不同。批量大小和多并行序列会成倍增加显存需求。

还要给输出 token、临时缓冲区、显示驱动和运行时波动留空间。如果配置在跑完一个提示词后显存几乎耗尽，那它还不是一个可靠的容量规划方案。

可以从哪里开始

下表按 4-bit 权重、单条序列、8K 左右的上下文估算。架构、量化格式、后端、缓存精度和 GPU 支持都会挪动边界；换了格式或拉长上下文，就回到上面的公式重算。型号名不能代替这一步：Mistral 的 Small 4 有 119B 参数，“Small” 并不说明它装得进一张消费级显卡。

可用显存	首选尝试	主要瓶颈
8 GB	3–4B 量化模型；部分 7–8B 模型（短上下文）	权重、上下文及 CPU 卸载
12 GB	7–8B 量化模型；谨慎尝试更大模型	KV 缓存和运行时工作区
16 GB	舒适量化的 12–14B 模型，或紧凑适配的 20–27B 文件	上下文、并发及余量
24 GB	带更多缓存空间的 20–27B 量化模型；部分更大或 MoE 文件	长上下文和多序列

Mac 的统一内存是同一笔预算

Apple Silicon 没有单独的显存。MLX 文档的说法是，CPU 和 GPU 直接访问同一个内存池，所以权重不用在两者之间来回拷贝。代价是这笔内存要和系统、浏览器、编辑器共用：一台 16 GB 的 Mac，能留给模型的远少于 16 GB。

GPU 能用多少，Metal 会给一个参考值。recommendedMaxWorkingSetSize 是 GPU 在不影响运行性能的前提下大约能分配的字节数，资源总量留在它以下，GPU 才能保持速度。mlx-lm 提醒，相对整机内存太大的模型会很慢。模型装得下时，可以在 macOS 15 及以上用 sudo sysctl iogpu.wired_limit_mb=N 提高可锁定的内存上限，N 要大于模型的 MB 数、小于整机内存。

速度还要看内存带宽。按苹果的 MacBook Pro 规格页，16 GB 的 M6 内存带宽是 153 GB/s。M5 Pro 是 307 GB/s，40 核 GPU 的 M5 Max 是 614 GB/s。同一个 4-bit 文件在这三台机器上逐字生成，速度上限大致按带宽比例拉开；算法见推理性能。

下表沿用上一张表的口径，已扣掉系统和常用软件的占用：

统一内存	大致相当于	主要瓶颈
16 GB	8–12 GB 显卡：7–8B 量化模型，短上下文	系统和其他应用挤占内存
24–32 GB	16 GB 显卡：12–14B 模型，或紧凑的 20–27B 文件	上下文和余量
48–64 GB	24 GB 显卡以上：20–32B 模型配长上下文，部分 MoE	带宽决定速度
128 GB	较大的 MoE 或 70B 级量化文件	带宽和预填充时间

在 Mac 上，同一个模型常有 GGUF 和 MLX 两种文件，量化方式不同，大小和速度也不同，选哪个运行时见运行时选型。

CPU offload 能换来容量，也会拖慢速度

通过 CPU 或系统内存卸载可以让更大模型跑起来，但数据需经过更慢的路径，解码速度可能大幅下降。慢多少没有统一的“每秒 token 数”断崖点，要看模型、卸载层数、内存带宽、PCIe 等互联、后端、提示词长度和批量大小。同一项卸载优化换一台机器，收益可能差几倍。ExLlamaV3 在 10 月的几个版本里接连加快了 CPU 卸载，升级或换机器后都要用自己的负载重测。

对于延迟敏感的工作，全驻留 GPU 是理想状态，但这并非所有负载的硬性规则。夜间批处理任务可能容忍那些会让交互式编程循环变得卡顿的卸载方案。

实测顺序

动手部署前，先明确任务目标、预期并发数、输入长度、输出预留空间以及可接受的响应延迟，然后选定具体的模型文件、对话模板和推理运行时。实测时先从短上下文和单路序列起步，记下 GPU 与系统内存峰值、卸载情况、首字延迟、解码速度和实际任务表现。

短序列摸底完成后，再分别拉高上下文长度和并发度，以免两个变量混在一起掩盖真正瓶颈；长上下文测试还要覆盖真实任务所需的最长信息依赖链，不能只靠填充无意义文本充数。最后留出稳定余量，把经过实际验证的配置完整记录下来。

在工具调用循环中，较小的驻留模型可能胜过较大的卸载模型。更大的上下文也可能让系统变慢，却未必能更好地找到关键证据。请使用 本地评估协议 基于任务而非参数量来做决定。

Accelerate 的模型内存估算指南 演示如何不加载全部权重，就估算不同数值类型的参数内存。先与本文的权重计算对照，再单独测量完整运行时；缓存、激活和临时缓冲区仍要另外留预算。

我的阅读