从 p50 到 p99：推理延迟分位数背后的存储行为

发布2026/7/26KV Cache存储加速LMCachevLLM

在大模型推理服务中，p50（中位数）与 p99（第 99 百分位）延迟的差异并非简单的统计波动，而是反映了存储系统在长上下文负载下的行为差异。KV Cache 的访问模式——尤其是冷恢复场景下的随机读和带宽瓶颈——会导致尾延迟显著升高。实测表明，通过存储加速优化，如铭信 FX100 全闪 NVMe-oF 阵列，可将 p99 延迟从数十秒级降至秒级，显著改善服务稳定性和用户体验。

为什么 p50 和 p99 延迟会显著不同？

在推理服务中，p50 延迟代表大多数请求的典型响应时间，而 p99 延迟则反映最慢的 1% 请求的表现。两者的差距通常源于存储系统的非均匀行为。以长上下文冷恢复为例，当模型需要从外部存储加载大量 KV Cache 时，存储的随机读性能直接影响延迟分布。

在 R2 实测中，480B 模型（TP8 三档并发）的 TTFT（首 token 延迟）p50 范围为 7.53–26.35 秒（使用铭信 FX100），而 p99 延迟则显著更高。对比无外存重算的基线（基线为本地 NVMe 单盘），p50 延迟从 149.5 秒降至 11.85 秒，加速倍数达 12.6×。这种差异的根本原因在于：存储系统的随机读带宽和延迟抖动会放大尾部请求的等待时间。LMCache 等缓存机制虽能缓解部分压力，但在高并发（如并发 16 档）下，存储的 I/O 瓶颈仍会导致 p99 延迟上升。

存储加速如何改善 p99 延迟？

存储加速的核心在于降低 KV Cache 的访问延迟和带宽瓶颈。铭信 FX100 通过全闪 NVMe-oF 阵列和 RoCEv2 网络，实现了 5.23 GB/s 的并行读带宽（相比基线的 0.98 GB/s，提升 5.3×），这直接压缩了 p99 延迟的尾部。

在 R2 实测中，对比无外存重算的基线，FX100 将 p99 延迟从 149.5 秒降至 11.85 秒，加速倍数达 12.6×。这一改善不仅源于带宽提升，还在于存储的随机读性能优化。对于生产部署，p99 延迟的降低意味着服务更少出现超时或降级，尤其在高并发场景下（如并发 16 档），存储加速能将尾延迟从分钟级降至秒级，提升用户体验。

存储行为对延迟分布的影响机制

推理延迟的分布受存储系统的 I/O 行为直接影响。在长上下文冷恢复中，KV Cache 的访问模式是随机读，且数据量巨大（480B 模型的 KV Cache 可能达数百 GB）。存储系统的随机读性能（IOPS 和延迟）决定了 p50 和 p99 的差距。

实测中，FX100 的 16M IOPS（PCIe 3.0 接口）和 100 GbE 网络带宽，使得随机读延迟稳定在毫秒级，从而压缩了尾部延迟。相比之下，传统 NFS 或本地 NVMe 在随机读场景下，延迟抖动更大，导致 p99 延迟显著高于 p50。这一机制解释了为何存储加速能同时优化 p50 和 p99，但后者的改善幅度更明显——因为尾延迟对存储瓶颈更敏感。

结语

从 p50 到 p99 的延迟差异，本质上是存储系统在 KV Cache 访问中的行为映射。通过全闪存储加速，如铭信 FX100，可将 p99 延迟从分钟级降至秒级，提升推理服务的稳定性。铭信科技在存储加速领域提供从硬件到软件的全栈方案，支持约 10 周门禁化联测，欢迎算力服务商与模型厂商联系验证。