llama.cpp 引入 FP8 KV Cache，降低本地推理显存占用

摘要：llama.cpp 社区新增 FP8 KV Cache 支持，目标是压缩自回归推理中随上下文长度增长的键值缓存。该方案以 8 位浮点保存 K/V 状态，可降低长上下文和高并发场景的显存压力，但实际收益取决于硬件是否支持高效 FP8 转换，以及量化误差对模型质量、延迟和缓存管理的影响。当前采集信息仅确认存在对应 GitHub Pull Request，具体实现、基准结果与合并状态仍需结合代码和复测确认。

---

核心变更

llama.cpp 新增 FP8 KV Cache 相关实现。KV Cache 保存注意力机制在生成过程中复用的键值状态，其内存开销通常随批大小、上下文长度和层数近似线性增长。对长上下文或多并发本地部署而言，压缩缓存格式往往比继续压缩模型权重更有机会释放可用显存。

这项变更的实体归属明确：llama.cpp 属于 ggml-org，FP8 KV Cache 是该推理引擎内部能力，不涉及模型厂商发布新模型。

为什么压缩 KV Cache

标准自回归推理需要反复读取历史 Token 的 K/V 状态，避免每次生成都重新计算完整前缀。对常规 Transformer，单层缓存的近似空间开销可写成：

M_KV = 2 × B × L × H_kv × S × d_head

其中，B 为批大小或并发序列数，L 为层数，H_kv 为 KV 头数量，S 为序列长度，d_head 为头维度。系数 2 分别对应 K 和 V；当使用 GQA 时，H_kv 小于注意力头数量，因此缓存比完整注意力激活轻得多。

若 KV 状态从 BF16/FP16 转为 FP8，在其他维度不变且忽略元数据与对齐开销时，理论缓存体积可接近减半。这一空间可进一步用于增加上下文、并发序列或批处理规模，缓解 KV Cache 成为显存瓶颈的问题。

FP8 的收益与误差边界

FP8 相比 INT8 具有更宽的动态范围和更直接的浮点语义，适合数值分布不均匀的注意力状态。不过，“位宽减半”不等于“系统耗时自动减半”：

• 权重通常在生成前加载，KV Cache 则在每个解码步持续读写。
• 若 CPU、CUDA 或 Metal 后端没有原生 FP8 路径，运行时转换可能抵消带宽和容量收益。
• 注意力中的 K/V 误差会通过 Softmax 概率和后续值加权聚合传播，尤其可能影响长上下文检索、代码生成和严格推理任务。
• 实际质量取决于缩放策略、统计粒度、量化误差累积方式，以及缓存分块或迁移过程中是否发生额外舍入。

因此，更合理的验收方式不是只比较显存占用，而是同时测量首 Token 延迟、持续解码吞吐、批处理规模、峰值显存和任务准确率。

对不同部署路径的影响

对于消费级 GPU，本地运行此前受限于显存时，FP8 KV Cache 可能允许用户保留更长的上下文，或同时运行多个会话。对于多 GPU 张量并行部署，KV Cache 若按层或按设备分片，压缩也能降低分片间的容量压力，但收益仍取决于缓存放置策略和显存碎片情况。

在纯 CPU 推理中，FP8 的主要价值可能只是减少内存占用；如果后端会频繁在 FP8、FP16 与 BF16 之间转换，内存压缩可能被转换开销抵消。对 Apple Silicon 和 Metal 后端，则应检查具体 FP8 指令路径、数据对齐和 kernel fusion 情况，不能仅依据理论位宽推断速度。

开发者落地建议

1. 等待 PR 合并并核对 llama.cpp 的实际命令行参数和后端支持矩阵。
2. 在同一模型、同一上下文和同一硬件上比较默认 KV 格式与 FP8 KV Cache。
3. 记录峰值显存、预填充耗时、首 Token 延迟、生成 Token/s，以及不同 batch size 下的吞吐变化。
4. 使用代码、长上下文检索和多轮对话测试质量退化，避免只看通用 perplexity。
5. 保留 BF16/FP16 KV Cache 作为回退方案；高精度任务若出现明显漂移，不宜仅为节省显存强制启用 FP8。

当前信息边界

采集页面只提供了标题、提交者和 GitHub PR 链接，没有提供 PR 描述、代码差异、测试数据、支持硬件或合并状态。因此，目前可以确认的是 llama.cpp 社区正在推进 FP8 KV Cache 支持，不能据此断言具体加速比例或无损量化效果。实际生产采用前应直接审查 PR，并以固定工作负载完成端到端复测。

---

消息来源：Reddit r/LocalLLaMA (2026-11-11)

—— 完 ——

主题标签： #llama.cpp 关注 #FP8 关注 #KV Cache 关注 #本地推理 关注 #显存优化 关注