自托管 Gemma 2 9B 与前沿 API 基准测试：NVIDIA L4 上的 FP8 量化预填充代价与显存现实 [P]

在评估将生产级 LLM 工作负载从商业云 API 迁移时，讨论通常会被过度简化为质量与基础设施成本之间的权衡。为了超越干净、孤立的平均值，我使用真实工作负载构建了一个可重复的评估矩阵：为我的简历生成平台进行冷启动外联和上下文概要重新工程。我将在单个商用 NVIDIA L4 GPU 上通过 vLLM 服务的未量化 Gemma 2 9B 与优化的 FP8 变体进行了基准测试。该数据集评估了跨不同收件人角色、不同复杂度区间（短上下文到长上下文）以及严格整数形式参数的动态文本生成。我捕获了客户端和服务器端遥测数据，以审计 FP8 压缩如何改变运行时现实。基础评估集公开位于 rsher60/resume-gen-benchmark。以下是我发现的原始遥测数据和基础设施权衡。 1. 首个令牌生成时间（TTFT）：量化的隐藏预填充代价 主流的开源说法是 FP8 量化使一切更快。然而，如果你的应用程序高度交互并流式传输到 UI，TTFT 是决定感知用户速度的唯一指标。我的遥测揭示了一个经典的硬件-软件权衡：预填充惩罚：对于针对高复杂度角色的复杂、长上下文提示，未量化模型在 866.93ms 内向服务器返回令牌。FP8 变体飙升至 1372.12ms——初始预填充延迟增加了 58%。原因：量化减少了令牌生成（解码阶段）期间的内存带宽瓶颈。然而，在计算能力有限的商用硬件（如 L4）上，计算密集的预填充阶段的矩阵乘法反量化开销对长输入令牌引入了显著的代价。生产边缘情况：我在短上下文运行中捕获了 FP8 模型的一个巨大 TTFT 峰值，达到 1,740.34ms。这反映了 vLLM 调度下的实时基础设施现实——例如冷预填充或上下文块交换。它证明你不能纯粹根据干净、孤立的平均值来评估架构。 2. 端到端延迟：FP8 在生成战中获胜的地方 虽然 FP8 强制你在预填充上付出代价，但在稳态解码循环中，它积极赚回价值，此时 LLM 严重受限于内存带宽。通过将权重精度降至 8 位整数，流经 GPU 内存总线的数据量大约减半。对于中等长度的生成序列，平均客户端总时间从 12,290.2ms 降至 11,526.2ms。如果你的应用程序处理中等至短上下文大小，或者完全运行异步/批量任务，FP8 提供了一个干净、确定性的基础设施胜利。 3. 质量分类账：9B 参数是否守住了底线？我验证了原始未量化运行生成的输出与 FP8 模型输出（rsher60/resume-gen-benchmark-results）。模式与角色遵循：对于有针对性的单轮任务，例如根据固定个人档案定制文本，精心设计的系统提示确保 9B 架构以与前沿模型几乎相同的格式和角色保真度执行。语义漂移：对于狭窄的领域特定任务，FP8 量化引入了几乎可以忽略的语义漂移。模型成功保留了复杂的上下文键——匹配针对工程师的冷启动外联与正式申请信的语气——同时在显著更低的内存占用下执行。 战略性架构要点 交互式/低批处理/长输入：可能需要未量化权重或高度激进的、非分块的预填充策略来保护你的 TTFT 并防止用户界面摩擦。异步/流式/短至中等上下文：FP8 是绝对必要的。在 L4 上运行 FP8 的真正原因不仅仅是节省几百毫秒的总延迟——而是显存解放。缩小模型占用量释放了大量内存用于 KV 缓存，使你能够在不出内存溢出（OOM）异常的情况下扩展并发性。我整理了完整分析，包括我用于在重度并发负载下维持 92.7% KV 缓存利用率的即将推出的 vLLM 配置和缓存分配策略，详见完整文章：https://billionars.substack.com/p/benchmarking-my-self-hosted-gemma HF 数据集： https://huggingface.co/datasets/rsher60/resume-gen-benchmark https://huggingface.co/datasets/rsher60/resume-gen-benchmark-results https://huggingface.co/datasets/rsher60/resume-gen-benchmark-results-optimised