前几天帮一个朋友看他本地部署的推理服务，8G 显存的卡，模型权重放进去还剩一点余量，单条对话跑得好好的，结果他把并发调到 8，还没跑到第二轮就开始报显存不足。他把模型换小了一档，问题照旧；把max_tokens砍到 512，还是撑不住。最后我让他把上下文长度从 32K 降到 4K，瞬间就稳了。吃掉显存的不是权重，是 KV Cache——那个在你眼皮底下悄悄长大的缓存。
这篇东西我想把 KV Cache 从头到尾讲一遍：它到底缓存了什么、为什么只缓存 K 和 V、token 一个一个往外蹦的时候它在干什么、显存账本怎么算、GPU 在这件事上到底卡在算力还是带宽。写给谁看？写过一遍推理接口、被 OOM 折腾过、想搞清楚max_model_len和gpu_memory_utilization该怎么设的人。纯调 API 的也能看，至少以后不会再对着显存曲线发懵。
1. KV Cache 到底在解决什么问题
1.1 大模型吐字为什么是一个一个来的
自回归生成这件事，本质上是把"预测下一个词"这个动作重复执行。你给它一段 prompt，它输出第 1 个 token，然后把刚生成的这个 token 拼回输入，再去算第 2 个，如此往复直到遇到结束符或者撞上长度上限。这个流程决定了输出的串行性：第 n 个 token 必须等第 n-1 个算完才能开始。
这里有个很多人一开始会误解的点：prefill 和 decode 是两个性质完全不同的阶段。prefill 阶段处理你输入的整段 prompt，几百上千个 token 一次性喂进去，做的是大矩阵乘法，GPU 的算力单元跑得满满当当，这个阶段叫compute-bound。decode 阶段则完全相反，每一步只处理一个新 token，矩阵乘法退化成了矩阵-向量乘法（GEMV），算力单元大部分时间在发呆，真正忙的是显存控制器，这个阶段叫memory-bound。
这两个阶段的差异，直接决定了 KV Cache 的存在意义和它的代价。prefill 阶段我们关心的是算力和首 token 延迟（TTFT），decode 阶段我们关心的是显存带宽和单 token 输出速度（TPOT）。KV Cache 是为 decode 阶段服务的，也是 decode 阶段最大的显存开销来源。
1.2 不做缓存会发生什么
假设你在生成第 100 个 token。要算这个位置的注意力输出，需要拿当前位置的 Query 去和前面 99 个位置的 Key 做点积，得到权重后，再对前面 99 个位置的 Value 做加权求和。问题来了：前面 99 个位置的 K 和 V 是从哪来的？它们是由那 99 个位置的输入向量分别乘上各自的权重矩阵算出来的。
如果没有任何缓存，每一次生成新 token，你都得把前面所有 token 的 K 和 V 重新算一遍。第 1 步算 1 个，第 2 步算 2 个，第 3 步算 3 个……到第 n 步就要算 n 个。整个生成过程里，K/V 投影的总计算量是 O(n²)，而注意力矩阵的计算量累积起来是 O(n³)——因为第 t 步的注意力矩阵是 t×t 大小，所有步骤加起来就是三次方级别。
具体点说，生成 2048 个 token，不做缓存的话你要重复计算大约 200 万次 K/V 投影，而实际上只有 2048 个是"新"的。这个浪费是灾难性的，而且随着长度增长，浪费比例越来越大：长度翻倍，重复计算量翻四倍。所以 KV Cache 不是什么锦上添花的优化，它是自回归生成能不能实用的前提。
1.3 加上缓存之后复杂度降到哪一档
有了 KV Cache，每一步只需要给新来的那 1 个 token 算它的 K 和 V，然后追加到缓存里。K/V 投影的总计算量从 O(n²) 降到 O(n)。注意力部分，每步的 Query 只有 1 个（batch 内），它要和长度为 t 的 K 缓存做点积，所以每步 O(t)，累积 O(n²)。整体从 O(n³) 降到 O(n²)。
这个降幅在短序列上感觉不明显，长序列上是质变。我做过一个粗略的对比测试，同一个 7B 模型，生成 4096 个 token，不开缓存的话在 4090 上要跑十几分钟量级，开了缓存是几十秒量级——差距不是几倍，是两个数量级的体感差别（这个数字受具体实现影响，只是个数量级参考）。
不过缓存不是免费的。你省下了计算，代价是把显存当成了计算结果的暂存区。省下来的算力，换成了持续增长的显存占用。这就是后面所有显存问题的源头。
2. 从 Attention 公式拆解 KV Cache 缓存的具体对象
2.1 Q、K、V 三个矩阵各自在扮演什么角色
标准的缩放点积注意力可以写成一行公式：
Attention(Q, K, V) = softmax(Q @ K^T / sqrt(d_head)) @ V用信息检索的类比来理解最直观。你手里有一个查询词（Query），要去一个资料库里找匹配。资料库里的每份资料有两个属性：一个是索引标签（Key），用来跟你的查询词算相似度；一个是正文内容（Value），一旦相似度算出来，就按相似度加权把这些正文混合起来。
Query 和 Key 做点积，得到的是"这个查询跟每个位置有多相关"的分数矩阵，经过 softmax 归一化后变成权重，再乘上 Value 得到最终输出。三者都是输入序列经过不同的线性投影（W_q、W_k、W_v）得到的，形状都是[batch, seq_len, num_heads, head_dim]。
关键在于：这三个角色的时间特性完全不同。Query 描述的是"当前位置想要什么"，它只跟当前这个位置有关。Key 和 Value 描述的是"某个位置是什么"，它是位置的固有属性，只要这个位置的内容不变、模型权重不变，它算出来就不变。
2.2 为什么只缓存 K 和 V，不缓存 Q
这是理解 KV Cache 最核心的一问，我见过不少人卡在这。
生成第 t 个 token 的时候，你需要的 Query 只有 1 个（就是位置 t 的那个）。而你需要参与点积的 Key 有 t 个（位置 1 到 t），需要加权求和的 Value 也有 t 个。位置 t 的 K 和 V 是刚算的，位置 1 到 t-1 的 K 和 V 是之前每一步算过、以后每一步还要继续用的。
那 Query 呢？位置 t-1 的 Query 在第 t-1 步用完之后，第 t 步还需不需要它？不需要。第 t 步的注意力，是"位置 t 的 Query"去查"位置 1 到 t 的 Key"，旧 Query 已经完成了它的历史使命，再也不会被任何后续步骤引用。所以缓存 Q 是纯粹的浪费——存了也没人会读。
一句话总结：Q 是一次性消费品，K 和 V 是长期资产。缓存只存长期资产。
这里还有一个容易忽略的细节：在 prefill 阶段，输入的整段 prompt 里每个位置的 Q、K、V 都是要算的（因为 causal mask 之下，位置 i 的 Query 要和位置 1..i 的 Key 做注意力）。但只有 K 和 V 会被留下来给后面的 decode 用，Q 用完即弃。所以你会看到一个现象：prefill 结束的那一刻，KV Cache 的占用就已经等于"prompt 长度"那么多，而不是从 0 开始慢慢涨。这一点在排查显存曲线时会很有用。
2.3 缓存的张量长什么样、怎么增长
从实现角度看，KV Cache 通常是两块张量：一块存 Key，一块存 Value（也有实现把两者拼在一起成一个张量，减少一次内存分配）。逻辑形状是：
[num_layers, batch, num_kv_heads, max_seq_len, head_dim]注意这里的max_seq_len是预留长度，不是实际长度。绝大多数框架为了避开反复申请释放内存的开销，会在请求开始时就按最大可能长度预分配一块连续显存，然后用一个"当前长度"的计数器来标记有效区域。这就是为什么有时候你看到显存占用在请求一开始就跳到一个很高的值——那不是泄漏，是预留。
每生成一个 token，做的事情就是把新的 K、V 写入到current_len这个位置，然后current_len += 1。写入的位置是连续递增的，所以单条请求内部的追加操作非常轻量。
注意事项：预分配策略虽然避免了碎片，但它意味着单条请求的实际显存占用往往按
max_model_len算而不是按实际生成长度算。如果你把max_model_len设成 128K 但实际只用 2K，等于白白浪费了 98% 的预留空间。这是很多人配错参数字后并发上不去的隐藏原因。
3. 显存账本：KV Cache 到底吃掉多少显存
3.1 单个 token 的缓存字节数怎么算
这个公式值得记下来，我建议直接抄进笔记：
每 token 缓存字节数 = 2 × num_layers × num_kv_heads × head_dim × dtype_bytes拆开看每一项：
2：Key 和 Value 各一份。num_layers：每一层都有自己独立的 KV Cache，层与层之间不共享。num_kv_heads：注意是KV 头数，不是注意力头数。用了 GQA 的模型这两者不一样，差得还挺多。head_dim：每个头的维度，通常是hidden_size / num_heads，Llama 系是 128。dtype_bytes：fp16/bf16 是 2，fp8 是 1，int4 压到 0.5 左右（含 scale 开销会略高）。
如果要算一条完整序列的总占用，再乘上序列长度和 batch 大小：
总缓存字节 = 2 × L × H_kv × d_head × S × B × dtype_bytes其中S是序列长度（prompt + 生成），B是并发请求数。这两个乘数就是显存爆炸的放大器。
3.2 拿几个常见模型手算一遍
理论讲完不算数，算一遍才有感觉。下面这些都是按 fp16 算的（截图数据是我自己按公式推的，跟实测会有几个百分点的偏差，主要来自框架的预留和对齐）。
| 模型 | 层数 | KV 头数 | head_dim | 每 token 缓存 | 8K 上下文单条 |
|---|---|---|---|---|---|
| Llama-2-7B (MHA) | 32 | 32 | 128 | 512 KB | 4.0 GB |
| Llama-3-8B (GQA) | 32 | 8 | 128 | 128 KB | 1.0 GB |
| Qwen2.5-7B (GQA) | 28 | 4 | 128 | 56 KB | 0.44 GB |
| Qwen2.5-32B (GQA) | 64 | 8 | 128 | 256 KB | 2.0 GB |
Llama-2-7B 那一行很能说明问题：每 token 512 KB，一条 8K 的对话就要 4 GB，权重本身才 13 GB 左右（fp16）。如果并发 4 条，KV Cache 直接吃掉 16 GB，比权重还多。这就是老一代 MHA 模型在长上下文场景下特别吃显存的原因。
再看 Qwen2.5-7B，56 KB/token，同样 8K 上下文只要 0.44 GB。差了将近 10 倍，原因就是 KV 头数从 32 降到 4。模型结构上的一个改动，直接把显存账本改写了。
再算个极端点的：32B 模型跑 32K 上下文，256 KB × 32768 = 8 GB，单条请求。这时候权重是 64 GB，加 8 GB 缓存，再加激活值和框架开销，80G 卡上并发基本只能到 1-2。
3.3 为什么缓存比权重更容易成为爆点
权重的占用是固定且可预测的，加载完就定死了，你知道它占多少。KV Cache 是动态且乘性增长的：它随并发线性增长，随上下文长度线性增长，两个维度一乘，增长是双倍的。
而且 KV Cache 有一个讨厌的特性——它不能像权重那样被高效换出。权重是只读的，多个请求共享同一份；KV Cache 是每个请求私有的，读写频繁，换到主机内存再换回来，PCIe 的带宽和延迟会直接把 decode 速度拖垮。所以实际的显存规划里，权重只是下限，KV Cache 才是决定你能塞多少并发的那个变量。
我一般的粗略分配是这样的：先给权重留出参数量 × dtype_bytes，再给 CUDA 上下文和框架开销留 1-2 GB，剩下的显存乘个 0.8-0.9 就是 KV Cache 的可用池子。然后用池子大小 / (每 token 字节 × 平均序列长度)估算能同时跑几条。这个估算在调gpu_memory_utilization的时候非常好用。
4. GPU 侧的真实瓶颈：算力还是带宽
4.1 算术强度告诉你 decode 阶段卡在哪
判断一个 kernel 卡在算力还是带宽，看算术强度（Arithmetic Intensity），也就是每搬运 1 字节数据能换多少次浮点运算，单位是 FLOP/Byte。把它跟 GPU 的"拐点"比一下就有结论。
以 RTX 4090 为例，fp16 密集算力约 82 TFLOPS，显存带宽约 1008 GB/s，拐点大约在82e12 / 1008e9 ≈ 81 FLOP/Byte。也就是说，算术强度低于 81 的负载都是 memory-bound。
现在算 decode 阶段生成一个 token 的实际情况。以 8B 模型 fp16 为例，权重要完整读一遍 16 GB，假设 KV Cache 有 2 GB 也要读一遍，总共约 18 GB 的数据搬运。计算量大约是2 × 8e9 = 16 GFLOP（每个参数两次运算）。算术强度 =16e9 / 18e9 ≈ 0.89 FLOP/Byte。
跟拐点 81 差了将近90 倍。这意味着在 decode 阶段，GPU 的算力单元有超过 98% 的时间在空转，真正的时间全部花在把数据从显存搬到计算单元上。
用时间验证一下：搬运 18 GB 需要18 / 1008 ≈ 17.9 ms，计算 16 GFLOP 需要16e9 / 82e12 ≈ 0.2 ms。搬运是计算的 90 倍。这 17.9 ms 就对应理论上限约 56 token/s 的单条输出速度，实际还要打折。所以 decode 阶段的优化方向从来不是"算得更快"，而是"少搬点数据"或"搬得更有效率"。
4.2 带宽、碎片和 batch 之间的三角关系
既然瓶颈是带宽，那提高吞吐的路子就是用更多的计算来摊薄搬运成本。具体做法就是加大 batch：多条请求共享同一份权重读取，权重读一次，能服务 B 条请求。这时候算术强度乘以 B，当 B 足够大时，负载就从 memory-bound 往 compute-bound 迁移。
但 batch 一开大，KV Cache 的占用又跟着涨。这就形成了一个闭环约束：batch 受显存限制，显存被 KV Cache 占用，KV Cache 又正比于 batch 和序列长度。你能跑多大 batch，取决于你能省下多少 KV Cache 显存。
除了容量，还有两个隐形的敌人。一个是显存碎片：早期的实现给每条请求按最大长度预分配连续空间，实际用了 30% 的话，剩下 70% 就空着，谁也用不了。另一个是不规则长度：一批请求里，有的已经生成了 3000 token，有的才 50 token，按最长的对齐就会浪费大量空间。这两点加起来，在真实负载下显存的有效利用率可能只有 20%-40%。
4.3 分页管理是怎么把浪费压下去的
vLLM 提出的 PagedAttention 是这方面最出名的一个思路，核心灵感来自操作系统的虚拟内存分页。
做法是把 KV Cache 切成固定大小的block（常见是 16 个 token 一块），block 之间不要求物理连续。每个请求维护一张 block table，记录"我的第几个逻辑块存在哪个物理块里"。注意力计算时，kernel 按 block table 去非连续的位置取 K 和 V。
这样一来，显存分配从"按最大长度预留"变成了"按需一页一页地领"。请求生成到哪，就领到哪，最后一个块没用满也没关系，浪费的上限就是块内未使用的部分，平均一半的块大小。同时，块的物理位置灵活，碎片问题自然消失。公开的数据里，这种方案能把显存浪费从 60%-80% 压到 4% 以下，同一张卡上能跑的并发数因此翻好几倍。
另一个附带的好处是前缀共享。如果多条请求的 system prompt 完全一样，它们的 K 和 V 在前缀部分算出来是完全相同的，那就可以让这些请求的 block table 指向同一批物理块，只在分叉之后各自独立。多轮对话场景下这个收益非常大，因为历史对话在下一轮里就是"共同前缀"。我实测过一个带长 system prompt 的场景，开前缀缓存后首 token 延迟下降了大概 40%，显存占用也明显下来了。
5. 工程上的压缩与优化手段
5.1 从模型结构下手：MQA 和 GQA
最省事的优化是在训练阶段就做掉的，也就是减少 KV 头数。
MHA（多头注意力）里，Q、K、V 的头数一样多，KV Cache 最大。MQA（多查询注意力）把所有的 Q 头共享同一组 K 和 V，KV 头数降到 1，缓存直接砍到 1/N（N 是头数），代价是表达能力有损失，质量会掉一些。GQA（分组查询注意力）是折中：把 Q 头分成 G 组，每组共享一组 K/V，KV 头数从 N 降到 G。
Llama-3-8B 是 32 个 Q 头、8 个 KV 组，比例 4:1，缓存省了 75%。Qwen2.5-7B 更激进，28 个 Q 头配 4 个 KV 组，比例 7:1。这就是为什么新一代模型在长上下文上比老模型从容得多。
不过这个选择在你拿到模型权重的那一刻就固定了，推理侧改不了。你能做的只是在选模型时有意识地看这个指标。如果你要部署的场景是长上下文加高并发，num_kv_heads的重要性不比参数量低。有些模型在配置里写的num_key_value_heads参数，就是它。
5.2 KV Cache 量化：收益、代价和踩坑点
如果模型结构动不了，那就对缓存本身做量化。fp16 是 2 字节，量化到 int8 就是 1 字节，缓存减半；量化到 int4 理论上减到 0.5 字节，但通常要额外存 scale 和 zero_point，实际大约 0.55-0.65 字节每元素。
收益很直接：原来只能跑 4 并发的，现在能跑 7-8。代价是精度损失，而且 KV 量化的精度损失跟权重量化不一样，它影响的不是单个权重，而是注意力权重的分布。
我踩过的一个坑是：短序列上测不出问题，一上长上下文就开始胡言乱语。原因是 K 的数值分布会随着序列变长出现明显的离群通道（某些维度上的值特别大），per-tensor 量化会被这些离群值带偏，把正常值全部压到很窄的量化区间里。解决办法是用 per-channel 或者 per-token 的量化粒度，或者干脆只对 V 做量化、K 保持 fp16，因为 V 的分布通常温和得多。
实操建议：KV 量化不要一上来就上 int4。先在 int8 上跑一遍你的实际业务 prompt，对比输出质量，做个 A/B。int8 通常质量损失在可接受范围，int4 就要谨慎了，尤其是需要精确数值推理、代码生成这类任务。
5.3 前缀缓存、滑动窗口与驱逐策略
除了压缩，还有"少存"这条路。
滑动窗口注意力是让每个位置只关注最近 W 个 token。缓存就只需要保留最近 W 个位置的 K 和 V，超出的直接扔掉，显存占用从O(S)变成O(W)，是个常数。Mistral 早期版本用的就是这个，代价是对超长距离依赖的建模能力变弱。
驱逐策略是另一种思路：缓存满了，按某种规则淘汰一部分。常见的有 H2O 这类基于注意力分数的重要性评估——注意力权重长期很低的位置，说明它对后续输出影响小，可以优先扔掉。还有些实现会保留最开头的几个 token（所谓的 attention sink），因为实测发现丢掉序列开头的 token 会导致质量明显崩塌，哪怕它们的注意力分数不高。
前缀缓存前面提过，多请求共享相同前缀的 KV。这个在 API 服务里几乎是必开项，尤其是 system prompt 很长或者多轮对话的场景。
这几种手段可以叠加。我一般的选择顺序是：先确认模型本身用了 GQA，再开前缀缓存（零质量损失），然后开分页管理（零质量损失），最后才考虑量化和驱逐（有质量损失，需要评估）。
6. 实操：怎么测出真实的显存占用
6.1 观测工具与观测点
先解决"看得见"的问题。nvidia-smi是最基础的一层，但它给的是进程级的显存占用，看不到细分。想看细分得用 PyTorch 自己的接口：
import torch # 当前实际被张量占用的显存 print(torch.cuda.memory_allocated() / 1024**3, "GB") # 被缓存分配器持有、但当前没被张量使用的显存 print(torch.cuda.memory_reserved() / 1024**3, "GB") # 完整的分配快照，能看到各段占用 print(torch.cuda.memory_summary())这里有个关键区别要搞清楚：memory_allocated是真正被张量用掉的，memory_reserved是 PyTorch 缓存分配器向驱动申请下来、但可能暂时闲置的。OOM 往往发生在 reserved 已经很大、但 allocated 不大的时候——不是没内存，是内存被缓存分配器攥着不放。想释放可以调torch.cuda.empty_cache()，但只对 reserved 部分有效，且会带来性能抖动，生产环境慎用。
实际部署里我更习惯在服务启动后先打一次基线快照：加载完权重、还没接请求时的显存占用，这个数就是"底噪"。之后每接一批请求再打一次，两者一减就是 KV Cache 的实际开销。这个差值比任何理论公式都准。
6.2 参数调节的顺序和经验值
显存不够的时候，参数不能乱调。我摸索出来的顺序是这样的：
| 优先级 | 参数 | 调整方向 | 影响 |
|---|---|---|---|
| 1 | max_model_len | 降到业务实际需要 | 显存占用线性下降，无质量损失 |
| 2 | gpu_memory_utilization | 提到 0.90-0.95 | 提高可用池子，但要留余量 |
| 3 | max_num_seqs | 适当降低 | 直接限制并发，牺牲吞吐 |
| 4 | KV 量化 | int8 起步 | 缓存减半，需评估质量 |
| 5 | 换更小的模型 | 最后手段 | 质量下降明显 |
第一条为什么排最前？因为max_model_len是乘法因子，把它从 32K 降到 8K，KV Cache 直接少 75%，而且一点质量都不损失（只要你的业务确实用不到那么长）。我见过太多人为了"以防万一"设了个超长的上下文上限，结果把并发能力全吃掉了。
gpu_memory_utilization这个参数在 vLLM 里指的是"允许使用的显存比例"。设 0.9 意味着框架会在启动时就把 90% 的显存划走作为 KV Cache 池子。设太高（比如 0.98）有风险，因为推理过程中还有激活值、临时张量、CUDA kernel workspace 要分配，容易在某个瞬间撞上 OOM。我的经验是 0.85-0.92 之间比较安全，具体看模型和序列长度。
6.3 常见问题速查
| 现象 | 可能原因 | 排查动作 |
|---|---|---|
| 启动就 OOM | 权重 + 预分配 KV 池超出显存 | 降gpu_memory_utilization或max_model_len |
| 跑一阵才 OOM | 长序列请求累积，并发超出池子 | 看请求长度分布，降max_num_seqs |
| reserved 高但 allocated 低 | 缓存分配器碎片 | 检查是否有频繁变长张量分配 |
| 单条很快，并发一上就慢 | batch 增大导致带宽争抢 | 对比不同 batch 下的 TPOT |
| 显存够但吞吐上不去 | decode 阶段 memory-bound | 加大 batch 摊薄权重读取 |
| 长上下文输出质量突降 | KV 量化在长序列下失效 | 关量化对比，或改 per-channel |
这张表里的每一行我基本都实际遇到过。最典型的是第二行"跑一阵才 OOM"：启动正常，压测正常，上线跑了半小时开始报错。原因是短请求快速释放，长请求持续占用，池子被慢慢蚕食。解决办法不是加显存，而是给请求长度设上限，或者对超长请求做排队。
7. 我在实际部署里踩过的几个坑
说几个文档里一般不写的东西。
第一个坑是 prefill 阶段的显存尖峰。我一直以为显存是随 decode 平滑增长的，直到有一次看到显存曲线在请求刚进来的瞬间跳了一下。原因是 prefill 处理长 prompt 时，中间激活值（尤其是注意力分数矩阵）会临时占用一大块显存，长度是S²级别的。一个 8K 的 prompt，注意力矩阵如果全物化，尺寸相当可观。所以即使你的 KV Cache 池子留够了，也可能在 prefill 那一刻被顶爆。解决办法是开 chunked prefill，把长 prompt 切成小段处理，牺牲一点 TTFT 换平稳。
第二个坑是max_tokens和实际占用不匹配。有次我把max_tokens设为 4096，以为显存是按实际生成长度算的。实际上框架按max_model_len预留，max_tokens只是限制生成上限，不影响预留。所以你把max_tokens调小，对显存几乎没帮助——真正有用的是max_model_len。
第三个坑是并发测试的方法不对。用固定长度的请求压测，得出的并发上限偏乐观。真实负载里请求长度是长尾分布，几个超长请求就能把池子占满，其他请求只能排队。做容量规划时我会按 P95 甚至 P99 的长度去算，而不是平均值。经验公式是：可用并发 ≈ 池子大小 / (每 token 字节 × P95 长度)，再打个 0.8 的折。
第四个坑是忽略了 CUDA 上下文的固定开销。每个进程初始化 CUDA 上下文要占几百 MB，多进程部署时这个开销会累积。还有些框架会在启动时做一次显存探测，把整卡显存都摸一遍。所以"理论能装下"和"实际能跑起来"之间，永远要留 1-2 GB 的余量。
第五个坑有点反直觉：显存利用率高不等于性能好。我曾经把池子塞到 95%，结果 decode 速度反而下降了。原因是显存快满的时候，分配器的行为会变差，容易出现分配失败重试和碎片整理。留出 10% 左右的空闲，系统整体更稳。这个跟操作系统磁盘别占满是一个道理。
最后分享一个我常用的快速估算手法。拿到一个新模型，先算单 token 缓存字节数，公式前面给过。然后看你的卡剩多少显存给缓存，除以单 token 字节，得到"能缓存多少 token"。再用这个数除以你的目标上下文长度，就是大概能同时跑几条。这个心算过程只要三十秒，但能帮你在配置之前就判断出这个模型这张卡到底能不能干这个活，省下很多来回试错的时间。
