Gemma 2 9B 在 L4 上的 FP8 量化实测：Prefill 代价与显存红利

一位开发者在 Reddit r/MachineLearning 发布了针对自托管 Gemma 2 9B 的量化基准测试报告。他使用 vLLM 在单张 NVIDIA L4 GPU 上，分别对未量化版本与 FP8 量化版本进行端到端延迟、首 token 时间（TTFT）与显存占用的实测，测试场景为简历生成平台的冷邮件撰写与上下文改写。数据集与结果已在 Hugging Face 公开。

核心发现：FP8 在 Prefill 阶段反而更慢

FP8 量化的主流叙事是「更快、更省」，但作者抓取的客户端与服务端遥测数据显示，在交互式、流式输出的场景下，TTFT 才是用户感知速度的唯一指标。

• 在长上下文、高复杂度输入下，未量化模型首 token 返回时间为 866.93 ms，而 FP8 版本飙升至 1372.12 ms，prefill 阶段额外承担约 58% 的延迟开销。
• 作者还在 FP8 短上下文测试中观察到一次 1740.34 ms 的 TTFT 尖峰，推测与 vLLM 调度中的冷 prefill 或上下文块换入有关，反映真实生产环境的波动。

解码阶段：FP8 的真正收益

Prefill 是计算密集阶段，量化的反量化开销在显存带宽受限的解码阶段转化为收益。

• 权重精度从 16 位降至 8 位，GPU 显存总线上的数据量大致减半。
• 中等长度生成序列下，客户端总耗时由 12290.2 ms 降至 11526.2 ms。
• 对于中等或较短上下文、异步或批量任务，FP8 提供了稳定且可预期的基础设施收益。

质量评估：9B 参数未明显失守

作者将原始与 FP8 输出的文本在公开数据集上做对比：

• 模式与人设一致性：在针对固定个人资料的短任务上，9B 架构在格式与角色语气上与前沿模型表现接近。
• 语义漂移：在领域内窄任务上，FP8 引入的语义偏差几乎可忽略，模型仍能区分面向工程师的冷邮件与正式求职信的语调差异。

工程取舍与 KV 缓存红利

作者的最终结论并非简单地「用或不用 FP8」，而是按工作负载区分：

• 交互式、低并发、长输入：建议保留未量化权重或采用更激进的 prefill 策略，避免 UI 抖动。
• 异步、短到中等上下文：FP8 几乎是必选项。
• 真正的价值在于显存释放：模型占用降低后，KV 缓存可占用更大空间。作者称在重负载下仍维持 92.7% 的 KV 缓存利用率，并发未触发 OOM。

完整配置与缓存分配策略已发布在作者 Substack 专栏，三套测试数据集也已上传至 Hugging Face，读者可自行复现。