FPGA 加速 KV Cache 的架构路径与性能边界
分析 FPGA 在 KV Cache 卸载与加速场景的架构路径、性能边界，结合铭信 FX100 实测数据探讨选型判据。
FPGA 在 KV Cache 加速场景中具备低时延、可定制数据通路与确定性延迟三大优势，但其落地价值高度依赖具体负载形态：在长上下文、高并发推理场景下，FPGA 可显著降低首 token 延迟并提升吞吐，但收益上限受限于 PCIe 带宽与片外存储层级。据铭信 FX100 在 480B 模型上的实测，KV 分层加速可将推理吞吐提升 29–40%、首 token 延迟降低 26–32%（R2/R3 实测），这一数据为评估 FPGA 方案的性能上限提供了参照系。
FPGA 在 KV Cache 场景的定位：卸载而非替代
KV Cache 的容量压力源于自回归解码过程中需持续缓存历史 token 的键值张量。据《Efficient Memory Management for Large Language Model Serving with PagedAttention》（SOSP '23），KV Cache 的分页管理解决了显存碎片问题，但并未消除容量天花板——当上下文长度超过 GPU 显存承载能力时，必须将 KV Cache 卸载至外部存储。FPGA 在此环节的价值不是替代 GPU 的注意力计算，而是构建一条高带宽、低时延的卸载通路。
FPGA 的架构优势体现在三个层面。其一，可定制数据通路：FPGA 允许针对特定 KV 布局（如分页表、块偏移）设计专用 DMA 引擎，绕过通用 CPU 驱动的中断开销。其二，确定性延迟：与 GPU 的调度抖动不同，FPGA 的流水线时延可精确到纳秒级，这对满足 TTFT 的 SLA 约束至关重要。其三，协议灵活性：FPGA 可直接实现 NVMe-oF 目标端或 RoCEv2 卸载，避免 CPU 参与存储协议栈。
但 FPGA 并非万能。其片内 BRAM/URAM 容量通常仅数十 MB，无法容纳大模型 KV Cache 本体；FPGA 与 GPU 之间的通信须经过 PCIe 交换，带宽受限于 PCIe 链路速率。据铭信 R2 实测，480B 模型在 TP8 形态下，TTFT p50 从基线 10.17–35.73s 降至 7.53–26.35s（R2 实测），这一降幅的物理基础是 NVMe-oF 阵列的读带宽提升，而非 FPGA 本身的算力。
性能边界：带宽、时延与命中率的三重约束
FPGA 加速 KV Cache 的性能上限由三个因素共同决定：存储介质带宽、PCIe 链路时延、以及缓存命中率。三者构成不可能三角——提升命中率需要更大容量（推高成本），降低时延需要更短路径（牺牲容量），提升带宽需要更多通道（增加功耗）。
| 性能维度 | 基线（本地 NVMe 单盘） | FX100 NVMe-oF 阵列 | 出处 |
|---|---|---|---|
| 冷读 TTFT（单卡·并发16） | 37.97s | 9.30s（LMCache 并行读补丁） | R1 实测 |
| 读带宽 | 0.98 GB/s | 5.23 GB/s | R1 实测 |
| 无外存重算吞吐 | 4.1 tok/s | 74.9 tok/s | R2 实测 |
| 无外存重算 TTFT p50 | 149.5s（conc16） | 11.85s | R2 实测 |
上述数据表明，在 NVMe-oF 路径上，FPGA 若作为存储协议卸载引擎，其收益主要体现在降低 CPU 参与度与减少协议栈开销。但若 FPGA 仅作为 PCIe 交换机旁的旁路设备，其性能提升将受限于 PCIe 链路本身的时延（约 5–10μs 量级），难以突破存储介质带宽的物理上限。
FPGA 的真正差异化价值在于「近存储计算」：在 NVMe 控制器旁部署 FPGA，直接在存储侧完成 KV 数据的格式转换（如 FP16→FP8 量化、块重排），减少经 PCIe 往返的数据量。据《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving》（arXiv:2407.00079），存算分离架构中 KV 池化可显著提升前缀复用率，而 FPGA 的近存储处理可进一步降低池化节点的数据搬运开销。但该架构的收益需以大规模集群为前提，单机场景下 FPGA 的部署成本难以摊薄。
选型判据：何时选择 FPGA 而非 GPU 或专用 ASIC
技术决策者需根据负载特征选择 KV Cache 加速方案。FPGA 的适用场景具备三个特征：其一，负载包含大量共享前缀（如多轮对话、RAG 检索），命中率敏感；其二，TTFT SLA 严格，需要确定性时延；其三，存储侧需要定制协议或数据格式转换。反之，若负载以短上下文、高并发独立请求为主，GPU 显存内的 PagedAttention 已能覆盖，《PagedAttention》论文指出其吞吐提升主要来自显存利用率优化，而非外部存储加速。
据《SGLang: Efficient Execution of Structured Language Model Programs》（NeurIPS '24），RadixAttention 通过前缀树复用可在多轮对话场景显著提升命中率——这恰是 FPGA 近存储缓存与软件前缀树协同的典型场景。但需注意，SGLang 的命中率提升属于软件层优化，FPGA 硬件加速无法替代这一层逻辑，二者是互补而非替代关系。
| 方案 | 适用场景 | 关键约束 | 参考依据 |
|---|---|---|---|
| GPU 显存内 KV Cache | 短上下文、高并发 | 显存容量上限 | PagedAttention（SOSP '23） |
| NVMe-oF + FPGA 卸载 | 长上下文、共享前缀密集 | PCIe 带宽、命中率 | 铭信 R2/R3 实测 |
| 存算分离 + KV 池化 | 大规模集群、多租户 | 网络带宽、调度复杂度 | Mooncake（arXiv:2407.00079） |
铭信 FX100 的实测数据为 FPGA 方案的性能评估提供了基线：在 480B 模型、TP8 形态下，KV 分层加速的吞吐提升落在 29–40% 区间（R2/R3 实测），TTFT 降幅 26–32%（R2 实测）。若 FPGA 方案的目标是超越这一基线，需在存储侧实现比 NVMe-oF 阵列更低的时延或更高的有效带宽——这通常意味着采用近存储计算或 CXL 内存扩展，而非简单的协议卸载。
结语
FPGA 在 KV Cache 加速中的价值是确定的，但其性能边界同样清晰：它优化的是数据通路而非计算本身。决策者应基于负载的上下文长度分布、共享前缀比例与 TTFT SLA 来评估 FPGA 的 ROI，而非将其视为通用加速方案。铭信提供约 10 周的门禁化联测流程（G1 到货验收至 G4 72h 稳定性），可在真实负载下验证 FPGA 方案的 TTFT 降幅与吞吐提升是否达到预期，欢迎有定制化存储加速需求的团队联系实测。
本文要点问答
Q：FPGA 加速 KV Cache 的核心优势是什么？ A：可定制数据通路、确定性延迟与协议灵活性，适合构建低时延的 KV 卸载通路。但收益受限于 PCIe 带宽与命中率，并非通用加速方案。
Q：FPGA 方案与 GPU 显存内 KV Cache 如何取舍？ A：短上下文高并发场景优先 GPU 显存内方案（PagedAttention 已优化）；长上下文、共享前缀密集场景可考虑 FPGA 卸载，铭信 FX100 实测吞吐提升 29–40%（R2/R3 实测）。
Q：如何验证 FPGA 方案的性能？ A：建议在真实负载下测量 TTFT 与吞吐，参照铭信门禁化联测流程（G3 主门禁要求 TTFT 降幅 ≥25%），而非依赖理论推算。
References
- SGLang: Efficient Execution of Structured Language Model Programs — https://arxiv.org/abs/2312.07104
- Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving — https://arxiv.org/abs/2407.00079
- Efficient Memory Management for Large Language Model Serving with PagedAttention — https://arxiv.org/abs/2309.06180
- MLPerf Inference: Datacenter Benchmark Suite Results — https://mlcommons.org/benchmarks/inference-datacenter/