想象你是一家大型仓储公司的新任主管，仓库（GPU显存）里堆满了对话记录。每一次大模型“说话”，都会把整场会议的所有关键备忘（键和值）复制一份，整整齐齐码进仓库。一开始很轻松，可当对话拉长、并发请求变多，仓库很快爆仓——这就是KV Cache占满显存的真实困境。幸运的是，仓库管理员找到了一套“压缩打包”的绝技：把每个货箱从铺满防震泡沫的精装包装（FP16），换成标签清晰的硬纸箱（INT8），再换成真空压缩袋（INT4）。货物还在，存取速度更快，只是取出时略有形变。这套“打包术”就是KV Cache量化压缩。本文用仓库打包的视角，带你亲手做一次显存优化实战。

岗位关联

掌握KV Cache量化压缩，是服务端推理工程师降低单请求显存、提升并发吞吐最实用的杠杆技能，也是MLOps同学优化大模型部署成本的必修课。

目录
  1. 可视化演示
  2. KV Cache显存危机
  3. 量化编码原理
  4. 量化布局变体
  5. 精度吞吐权衡
  6. 框架配置实战
  7. 数值稳定处理
  8. 性能测评调优
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

\u53ef\u89c6\u5316\u5c55\u793aKV Cache\u4eceFP16\u5230INT8/INT4\u7684\u91cf\u5316\u8fc7\u7a0b\uff0c\u5bf9\u6bd4\u4e0d\u540c\u7cbe\u5ea6\u7ea7\u522b\u7684\u663e\u5b58\u538b\u7f29\u4e0e\u7cbe\u5ea6\u635f\u5931\uff0c\u5c55\u793a\u6027\u80fd\u52a0\u901f\u6bd4\u4e0e\u63a8\u7406\u4f18\u5316\u6548\u679c\u3002

本节配有交互动效（进入视口后自动加载，约 3KB）。

KV Cache\u91cf\u5316\u538b\u7f29\u6d41\u7a0b FP16\u6743\u91cd\u538b\u7f29\u4e3aINT8\u51cf\u534a\u663e\u5b58 INT4\u91cf\u5316\u53ef\u8282\u770175%\u663e\u5b58 FP16 \u2192 INT8 \u2192 INT4 \u70b9\u51fb\u5207\u6362\u67e5\u770b\u7cbe\u5ea6\u5bf9\u6bd4

KV Cache显存危机

仓库爆仓的根源，得从大模型“逐词说话”的方式说起。当你让模型读一篇文章摘要时，它每生成一个新词，都要重新回顾一遍整篇对话的历史信息。这份回顾并不把原文重新读一遍，而是把每一层的“货架标签”（Key）和“货架上的货物”（Value）提前打包存放在仓库里，随取随用。这些临时存放的货箱，就是KV Cache。

仓库里的货箱越来越高的原因很直观：每生成一个词，就要往每层每头追加一行新的Key和Value。假如对话长了、批次里来了更多用户，备货速度远超清货速度。更麻烦的是，模型动辄几十层、几十个注意力头，每一层每个头都要独立存一份。于是同样的对话长度，仓库需求量被层数和头数成倍放大。

KV Cache的峰值占用可以这样估算：每一层每个头的 K 和 V 各存一份，每份元素占若干字节，总数量与序列长度成正比。

所以破解爆仓有两条路：要么少囤货（调低序列长度或批次），要么把每个货箱压扁——后者正是本节主角。仓库还是那个仓库，但每个箱子都换成了更紧凑的规格，能放的货自然更多。

KV Cache 字节数≈2×L×Nhead×dhead×seq_len×bytes_per_element\text{KV Cache 字节数} \approx 2 \times L \times N_{\text{head}} \times d_{\text{head}} \times \text{seq\_len} \times \text{bytes\_per\_element}
公式中的 2 是因为 K 和 V 两个货架区；层数 L、注意力头数 N_head 都是放大倍率。对话越长，仓库越满。
  1. 因子 2（K 与 V 双份）每组注意力状态都要保留 Key 与 Value 两套货架，所以首先乘以 2。
    22
  2. 层数放大模型有多少层 Transformer，仓库就要复制多少层货架，乘以层数 L。
    ×L\times L
  3. 注意力头数放大多头注意力中每个头各有独立的 K、V 货架，再乘以 N_{\text{head}}。
    ×Nhead\times N_{\text{head}}
  4. 每头维度每个注意力头存的向量长度为 d_{\text{head}}。
    ×dhead\times d_{\text{head}}
  5. 序列长度已生成的词数越多，每个头需要保留的历史条目越多，乘以 seq\_len。
    ×seq_len\times \text{seq\_len}
  6. 元素字节数FP16 下每个值占 2 字节，换 INT8 就只占 1 字节，这是压缩的关键抓手。
    ×bytes_per_element\times \text{bytes\_per\_element}

量化编码原理

压缩打包的核心，是给每个货箱贴上“净重换算表”。仓库管理员发现，FP16 精装箱里虽然每个数值都能精确读到小数点后很多位，但实际货物重量分布往往集中在某个范围内。于是他决定：把连续变化的重量（浮点数）折算成刻度更稀的整数标签（如 0 到 127），同时记下“每一格刻度等于多少公斤”（缩放因子）。取货时，用标签乘以缩放因子，就能还原出大致重量。

这套流程在数学上叫量化和反量化。管理员先扫描整箱货物找最重的一件（绝对最大值），用它决定整个换算表的量程；再把每件货除以量程刻度高度后四舍五入，压成一个整数；取货时整数乘以缩放因子即近似还原。

量化编码把原本连续浮点世界的“精细称重”变成了“统一规格的打包称重”。换来的是每个货箱体积骤减：FP16 变 INT8 省一半，变 INT4 再省一倍。代价是开箱时读出的重量与实际有微小偏差——只要偏差不影响模型的回答质量，这笔交易就相当划算。

s=max⁡(∣x∣)qmax⁡,q=round(xs),x^=q×ss = \frac{\max(|x|)}{q_{\max}}, \qquad q = \text{round}\left(\frac{x}{s}\right), \qquad \hat{x} = q \times s
s 是缩放因子（每格刻度对应的数值跨度），q_{\max} 是整数刻度最大值，x 是原始值，\hat{x} 是还原值。整个流程就是“用整数价格标签 + 牌价表”重新入库和出库。
  1. 找最重货物并定量程对容器内所有原始值求绝对值最大者，记为 \max(|x|)，它决定换算表的总跨度。
    max⁡(∣x∣)\max(|x|)
  2. 计算刻度高度把跨度除以整数刻度的上限 q_{\max}（INT8 时为 127），得到 s，即每格刻度代表多大的数值。
    s=max⁡(∣x∣)qmax⁡s = \frac{\max(|x|)}{q_{\max}}
  3. 取整离散化每个原始值除以 s 后四舍五入，得到整数标签 q。这一步会损失刻度之间的尾数信息。
    q=round(xs)q = \text{round}\left(\frac{x}{s}\right)
  4. 查表还原出库时用标签 q 乘以 s，得到 \hat{x}，与原始 x 存在微小偏差，这就是“压箱造成的形变”。
    x^=q×s\hat{x} = q \times s

量化布局变体

同样的压缩打包，不同货物的脾气不一样。有的货箱里正负货物均衡分布（例如数值以 0 为中心），管理员可以用“对称压缩袋”：直接把区间映射到正负整数范围内。有的货箱里货物普遍偏一侧（例如全是正值），再用对称压缩袋就会浪费很多刻度，这时要用“非对称包装”，额外记录一个零点偏移，让刻度恰好覆盖真实区间。

更精细的打包法叫分组量化。管理员不再给整面货架贴一张换算表，而是每隔一小段货架就贴一张换算表。这是因为一段数据里通常相邻数值波动不大，分组后每组都能获得贴合自己的换算表，误差大幅下降。

对称量化适合分布居中、零附近集中 的数据（一般注意力缓存近似满足）；非对称量化通过零点偏移覆盖任意分布；分组量化在 INT4 场景下几乎是标配——因为压得越狠，越需要“贴身定制”的换算表来保精度。实战中选哪种，取决于你仓库里货物数值分布的脾气。

sg=max⁡(∣xg∣)qmax⁡,g=1,2,…,Gs_g = \frac{\max(|x_g|)}{q_{\max}}, \quad g = 1, 2, \dots, G
这里的 x_g 表示第 g 组内的数值集合，每组有自己的缩放因子 s_g。分组越细，每组越贴合，代价是多记几张换算表。
  1. 分组切分把整列数据按块大小切成 G 组，第 g 组记为 x_g。
    x1,x2,…,xGx_1, x_2, \dots, x_G
  2. 逐组求量程对每一组分别求绝对最大值 \max(|x_g|)。
    max⁡(∣xg∣)\max(|x_g|)
  3. 逐组算刻度分别除以 q_{\max}，得到该组专属缩放因子 s_g。
    sg=max⁡(∣xg∣)qmax⁡s_g = \frac{\max(|x_g|)}{q_{\max}}

精度吞吐权衡

压箱省了空间，必然要付出形变的代价。管理员发现，压缩率越高，取出货物的重量偏差越大。INT8 在绝大多数场景下误差小到可以忽略，INT4 则可能让注意力分数产生明显偏移。但反过来看，省下的空间意味着同一时刻可以接待更多用户的对话——仓库能放更多货，吞吐自然上去。

这里存在一个直观的收益公式。设 KV Cache 占显存比例为 \beta，压缩率为 c（例如 INT8 时 c=2），则整体可容纳的请求量近似提升为：

降级策略也因此有了依据：短对话、追求速度的场景，大胆上 INT4；长上下文、严谨问答场景，用 INT8 或对 K 缓存单独提高精度。压缩档位不是越省越好，而是“货损可接受前提下的最省打包法”。

Speedup≈11−β+β/c\text{Speedup} \approx \frac{1}{1 - \beta + \beta / c}
如果 KV Cache 占显存 40%，改用 INT8（c=2），吞吐约提升 1.25 倍；改用 INT4（c=4）约提升 1.37 倍。KV Cache 占比越高，这一招的甜头越大。
  1. KV 占显存比例\beta 表示 KV Cache 在整个显存预算中的占比，例如 0.4 表示四成。
    β\beta
  2. 压缩率c 是压缩前后每元素字节数之比，FP16 换 INT8 时 c=2。
    c=2c = 2
  3. 剩余占比非 KV 部分（权重、激活、中间态）不压缩，仍占 1 - \beta；KV 部分压缩后占 \beta / c。
    1−β+β/c1 - \beta + \beta / c
  4. 取倒数得加速比显存能承载的并发请求近似与总占用成反比，故取倒数。
    11−β+β/c\frac{1}{1 - \beta + \beta / c}

框架配置实战

理论讲完，管理员该去真正的仓库动手了。目前主流推理框架大多内置了 KV Cache 量化开关。以 vLLM 为例，启动服务时加上缓存精度参数，就能把货箱从原始 FP16 换成 FP8 或 INT8/INT4 规格，而不必重训模型——这是纯部署侧的优化。

配置时需要注意三件事：一是缓存精度类型，二是最大序列长度，三是量化后必须做回归验证。以 vLLM 为例：

不同版本的 vLLM 支持的缓存类型不同，有些支持 fp8_e5m2（动态范围大但精度略低），有些支持 int8 或 fp8 的自选。配置前务必查阅对应版本文档。启用后，仓库的货架占用应显著下降；若服务崩溃或回答质量明显下滑，就要回退档位或开启异常值处理。

配置本身只是一行参数，真正的工程挑战在于：确认你的模型、芯片与框架版本都支持该缓存类型，并在上线前用典型 prompt 集做一次“开箱验货”——这正是下一节数值稳定处理要解决的问题。

bash4 行
vllm serve meta-llama/Llama-3.1-8B-Instruct \    --kv-cache-dtype fp8_e4m3 \    --max-model-len 32768 \    --gpu-memory-utilization 0.95

数值稳定处理

压箱之后，最怕遇到“超重钉子户”。当某些隐藏层的注意力数值出现特别大的极端值时，整张换算表会被它拉伸，导致普通货物的刻度精度被挤占。管理员的应对方法有三招。

第一招是剪裁（Clipping）：对超出合理范围的极端值做截断，不让个别极端货物霸占整个量程。第二招是预缩放（Pre-scale）：把缩放因子提前乘进注意力计算的某个环节，省去每次读箱时重复换算的开销，同时减少中间步骤的数值误差。第三招是分级精度：因为注意力打分对 Key 的取值更敏感，对 Key 货箱用更高精度（如 INT8），对 Value 货箱用更低精度（如 INT4），各取所需。

这几招相当于在压缩打包流程里加入质检环节：剪裁是“超大件禁止托运”，预缩放是“把换标签的动作提前在工地做完”，分级精度则是“易碎品用厚箱、普通品用薄箱”。数值稳定处理后，量化的最坏情况被兜住，模型行为更可预期。

xclipped=clip(xs, −qmax⁡, qmax⁡),xpre′=q×sdheadx_{\text{clipped}} = \text{clip}\left(\frac{x}{s},\ -q_{\max},\ q_{\max}\right),\quad x'_{\text{pre}} = \frac{q \times s}{\sqrt{d_{\text{head}}}}
剪裁把缩放后的值夹在整数刻度范围内；预缩放则把换算结果直接代入注意力软最大化之前的缩放项，减少重复运算与精度抖动。
  1. 缩放并剪裁原始值先除以 s，再把结果夹在 [-q_{\max}, q_{\max}] 内，防止异常值越界。
    clip(x/s, −qmax⁡, qmax⁡)\text{clip}(x/s,\ -q_{\max},\ q_{\max})
  2. 预缩放代入注意力公式将反量化后的 \hat{x} = q \times s 直接除 \sqrt{d_{\text{head}}}，提前完成注意力缩放。
    (q×s)/dhead(q \times s) / \sqrt{d_{\text{head}}}
  3. 分级配置K 缓存采用较高精度，V 缓存可采用较低精度，在显存与精度间找平衡。

性能测评调优

打包方法改造完，管理员要拿出数据说话。性能测评通常围绕三个指标展开：峰值显存占用、端到端吞吐量、回答质量（精度损失）。

显存测评很简单：在相同批次与序列长度下，对比开/关量化缓存后 nvidia-smi 读到的峰值占用。吞吐测评则跑固定数量请求，计算每秒完成多少个请求（throughput）以及每请求平均延迟。精度消融则取一批多样化的 prompt，比较量化前后的困惑度（PPL）变化，或者用下游任务（摘要、问答）的打分差衡量。

| 配置 | 峰值显存 (GB) | 吞吐 (req/s) | PPL 变化 |

| --- | --- | --- | --- |

| FP16 KV Cache | 18.2 | 12.4 | 基线 |

| INT8 KV Cache | 13.8 | 15.1 | +0.02 |

| INT4 KV Cache | 11.5 | 16.8 | +0.18 |

调优建议：从 INT8 起步，验证无显著退化后再尝试 INT4；若 INT4 精度下滑明显，优先开启剪裁与 K/V 分级精度，而不是直接放弃量化。仓库的每个货位都要精打细算，量化的价值从来不只是“省显存”三个字，而是让同样的硬件服务更多用户、承载更长对话。

AI 应用场景

在线对话服务高并发部署

阶段：推理服务部署与优化

解决的问题：高并发聊天机器人同时接待大量用户时，每路对话的 KV Cache 独立占用显存。传统 FP16 缓存容易在 4k 上下文时把单卡显存打满，导致排队和超时。通过 INT8 KV Cache 量化，单请求显存减半，单卡可同时服务的会话数翻倍。

具体案例：某 SaaS 客服平台将 70B 模型部署在 A100 上，启用 --kv-cache-dtype fp8_e4m3 后，单卡并发从 12 路提升到 20 路，平均首字延迟基本不变，PPL 变化可忽略。

长文档问答的显存救急

阶段：长上下文推理优化

解决的问题：RAG 场景中，把几十页文档塞进上下文后，KV Cache 占用随 token 数线性膨胀，很容易 OOM。对 KV Cache 做 INT4 分组量化，注意缓存清零，可以在一张 24GB 消费级显卡上运行 32k token 的长文档问答。

具体案例：法律文书问答系统在 Llama-3.1-8B 上把 max-model-len 从 8k 提到 24k，KV Cache 量化后首次成功跑通完整合同审核流程，而无需更换更大显存卡。

Python 演示

python59 行
import numpy as np  def symmetric_quantize(x, bits=8):    qmax = float(2 ** (bits - 1) - 1)    scale = np.abs(x).max() / qmax    q = np.round(x / scale).astype(np.int8)    return q, scale  def symmetric_dequantize(q, scale):    return q.astype(np.float32) * scale  def group_quantize(x, bits=4, group_size=32, scale_dtype=np.float32):    orig_shape = x.shape    flat = x.reshape(-1, group_size)    qmax = float(2 ** (bits - 1) - 1)    scales = np.abs(flat).max(axis=1, keepdims=True) / qmax    q = np.round(flat / scales / qmax * qmax).astype(np.int8)    deq = q.astype(scale_dtype) * scales    return flat, dequant_to_shape(deq, orig_shape)  def dequant_to_shape(deq, orig_shape):    return deq.reshape(orig_shape)  def kv_cache_memory(kv_cache, quantize=False):    if not quantize:        return kv_cache.nbytes    return kv_cache.shape[0] * kv_cache.shape[1] * kv_cache.shape[2]  def main():    rng = np.random.default_rng(42)    seq_len, num_heads, head_dim = 4096, 32, 128     kv_cache_fp16 = rng.standard_normal(        (seq_len, num_heads, head_dim)    ).astype(np.float16)     q8, scale8 = symmetric_quantize(        kv_cache_fp16.astype(np.float32), bits=8    )    deq8 = symmetric_dequantize(q8, scale8)     mse8 = np.mean((kv_cache_fp16.astype(np.float32) - deq8) ** 2)    mem_fp16 = kv_cache.nbytes_if_fp16(kv_cache_fp16)    mem_q8 = kv_cache_memory(kv_cache_fp16, quantize=True)     print("FP16 KV Cache 内存:", mem_fp16, "bytes")    print("INT8 KV Cache 内存:", mem_q8, "bytes")    print("显存节省:", 1 - mem_q8 / mem_fp16)    print("INT8 反量化 MSE:", mse8)  if __name__ == "__main__":    main()
目的：手把手模拟 KV Cache 的 FP16 到 INT8 对称量化流程，并对比显存占用和反量化误差。
  1. symmetric_quantize(x, bits=8)求出缩放因子并取整，得到整数缓存。
  2. symmetric_dequantize(q, scale)用标签乘以缩放因子还原数值。
  3. group_quantize按组计算独立缩放因子，适合 INT4 场景。
  4. kv_cache_memory按形状估算量化后缓存占用（每元素 1 字节）。
  5. kv_cache_fp16.astype(np.float32)先把 FP16 提精度再量化，避免累积误差。
  6. np.abs(x).max() / qmax这是对称量化中最核心的缩放因子公式。

常见误区

误区“模型文件里不是已经存了权重吗？KV Cache 应该不需要额外占显存吧？”

正解KV Cache 是推理过程中动态生成的临时缓存，和模型权重完全不同。权重是“仓库的建筑图纸”，KV Cache 是“每次对话现场打包的货箱”。两者都占显存，但 KV Cache 随对话实时增长，是长上下文场景下显存的主要变量。

为何常见：初学者容易把所有“模型相关占用”都归因于权重，忽视了 Transformer 自回归解码时 K/V 缓存的动态累积机制。

误区“既然注意力分数是 O(n²) 的，KV Cache 肯定也是二次方增长，量化也救不回来。”

正解注意力计算量是 O(n²)，但 KV Cache 存储量是 O(n)：每生成一个新 token，只追加一行 K 和一行 V，总占用随序列长度线性增长。之所以让人觉得“爆仓很快”，是因为线性增长的斜率很大（层数×头数×维度），而不是增长阶数高。

为何常见：把“计算复杂度”与“缓存存储增长”混为一谈，忽略了 KV Cache 是追加式写入而非全量重算。

误区“省一半空间肯定要废掉一半效果，不敢在生产环境开量化。”

正解实际工程中，INT8 对称量化对多数模型的影响极小（PPL 变化常小于 0.05），INT4 配合分组量化也能在许多场景下保持可用质量。关键在于检验分布：KV Cache 数值通常集中在零附近，适合量化。配合剪裁与分级精度，INT4 也能站住脚。

为何常见：把量化想象成“粗暴截断所有小数”，而忽略了缩放因子与分组建模对误差的补偿能力。

误区“装好 vLLM 就自动量化 KV Cache 了，不用配任何参数。”

正解绝大多数框架默认使用原始缓存格式，量化必须显式配置且依赖框架版本支持。例如 vLLM 需要手动指定 --kv-cache-dtype，并确认选项与模型、硬件的兼容性。默认开启的通常只是权重加载优化，而非缓存量化。

为何常见：把“框架很智能”等价于“默认启用所有优化”，忽略了工程上线前需要逐项确认配置参数。

面试题

Q1. KV Cache 在推理时主要缓存了什么数据？

单选题 · easy

  • A.模型权重和偏置参数
  • B.每一层的键和值缓存← 正确答案
  • C.每一层的查询和向量
  • D.注意力分数历史矩阵

答案：B。KV Cache 缓存的是每一层注意力机制中的 K（键）和 V（值），供后续生成 token 时复用。Q 是当前 token 新产生的，不需要缓存；权重是静态的，不属于 KV Cache。

Q2. 将缓存从 FP16 换成 INT8，每个元素占用从 2 字节变为 1 字节，显存节省多少？

单选题 · easy

  • A.完全没有节省空间
  • B.大约节省两倍空间← 正确答案
  • C.大约节省四倍空间
  • D.大约节省八倍空间

答案：B。2 字节变 1 字节，同等元素数量下占用减半，即节省一半显存。INT8 只是压缩率 c=2，不是 4 倍或 8 倍；INT4 才能实现 c=4 的压缩。

Q3. 对称量化中，缩放因子 s 通常如何计算？

单选题 · mid

  • A.所有数值的平方均值
  • B.绝对最大值的对应的最大整数比← 正确答案
  • C.数据标准差的一半
  • D.最小值和最大值的均值

答案：B。对称量化以零为中心，先把所有值取绝对值找最大峰值，再除以整数刻度上限（如 127），得到每格刻度代表的数值跨度。平方均值、标准差和均值都不符合对称量化量程的定义。

Q4. 在 KV Cache 中，K 与 V 对注意力分数的影响通常有何差异？

单选题 · mid

  • A.K 更敏感，建议保留更高精度← 正确答案
  • B.V 更敏感，建议保留更高精度
  • C.K 和 V 的敏感度完全相同
  • D.两者都不影响注意力分数

答案：A。注意力分数由 Q 与 K 的点积产生，K 的误差会直接乘进 softmax 的输入，因此 K 的数值扰动更影响打分质量。V 主要参与加权求和，耐受性相对更强，实践中常对 K 用高精度、V 用低精度。

Q5. 下列哪项属于 KV Cache 量化能直接改进的指标？

单选题 · mid

  • A.模型参数量减少
  • B.显存峰值下降← 正确答案
  • C.训练收敛速度提升
  • D.数据集质量提升

答案：B。量化压缩的是缓存存储格式，直接降低推理时的显存峰值，进而提升并发吞吐。模型参数量在部署时已固定，量化不影响参数规模，也不涉及训练与数据。

Q6. 反量化过程的数学本质是什么？

单选题 · mid

  • A.对整数标签做插值补全原始小数位
  • B.将整数标签乘上缩放因子近似还原← 正确答案
  • C.恢复出完全无损的原始数值序列
  • D.将浮点数转换为另一个整数

答案：B。反量化就是 \hat{x} = q × s，用一个缩放因子把整数标签映射回连续值域。由于取整环节已丢弃尾数，反量化只能近似还原，不能做到无损恢复。插值补全并不是标准反量化流程。

Q7. 为什么分组量化比全局量化能降低 INT4 场景的精度损失？

单选题 · hard

  • A.分组后每组拥有贴合自己的缩放因子← 正确答案
  • B.分组后每组自动变为更高精度
  • C.分组量化不再需要反量化步骤
  • D.分组量化减少参与运算的参数总量

答案：A。数据分布在不同区间波动各异，全局一个缩放因子会被极端段拉宽量程。分组量化按块为单位计算缩放因子，每组量程更贴合局部数据，因此 INT4 巨大压缩下的相对误差更小。

Q8. 以下哪些手段能有效降低 KV Cache 带来的显存压力？

多选题 · mid

  • A.启用 KV Cache 量化压缩← 正确答案
  • B.使用前缀缓存复用公共前缀← 正确答案
  • C.增大单批次批量大小
  • D.限制最大序列长度← 正确答案

答案：ABD。量化减少每元素存储字节数，前缀缓存让公共前缀只存一次，限制序列长度减少缓存条目，三者都直接降低 KV Cache 显存。增大 batch 会增加并发，但每个请求的 KV Cache 仍按原样累积，只会加剧显存消耗。

Q9. vLLM 中启用 FP8 KV Cache 量化的典型启动参数是什么？

单选题 · mid

  • A.--dtype fp32
  • B.--kv-cache-dtype fp8_e4m3← 正确答案
  • C.--trust-remote-code
  • D.--max-model-len 8192

答案：B。--kv-cache-dtype 是专用于设置缓存精度类型的参数，fp8_e4m3 是适配 KV Cache 的高效 8 位浮点格式。--dtype 控制模型权重精度，--trust-remote-code 控制代码信任策略，--max-model-len 控制序列长度。

Q10. KV Cache 量化后，哪些风险需要部署工程师重点验证？

多选题 · hard

  • A.长上下文下注意力分数数值漂移← 正确答案
  • B.极端异常值拉宽量程压缩精度← 正确答案
  • C.推理吞吐量必然成倍下降
  • D.不同层对量化敏感度不一致← 正确答案

答案：ABD。量化后 K 缓存误差可能造成注意力分数偏移；个别异常值会拉伸缩放因子导致普通值精度变差；某些层敏感度高，需按层差异化处理。正确配置后吞吐通常上升而非下降，因此 C 错误。