推理成本的隐形主角：KV Cache、显存和数据中心网络

大模型的推理速度，常被简单理解成“GPU 算得够不够快”。但一次请求真正经过的是一条很长的流水线：输入要被读进显存，多个 Transformer 层要反复访问权重和缓存，生成出的 token 还要通过网络返回用户。模型越大、上下文越长，计算之外的搬运成本越难忽略。

数据中心服务器与网络设备

一次生成分成两个不同阶段

用户把一段提示词发来后，系统通常先进入 Prefill 阶段：并行处理已有上下文，建立中间状态。随后进入 Decode 阶段：每次生成一个新 token，再把它接回上下文，循环直到结束。

Prefill 更像“批量读题”，适合并行计算；Decode 更像“边想边写”，每一步都要等待前一步的结果，对单步延迟、显存访问和调度更敏感。一个系统如果只看平均吞吐，可能把 Decode 的首 token 延迟和用户逐字等待体验掩盖掉。

KV Cache 为什么既救了速度又吃掉显存

Transformer 在生成新 token 时，需要回看之前 token 的注意力键和值。如果每生成一个 token 都重新计算全部历史内容，长上下文会越来越慢。KV Cache 把历史 token 在每一层算过的 Key 和 Value 保存起来，下一步只计算新增部分。

它的代价是缓存大小会随“层数、头数、每个头的维度、上下文长度和并发请求数”增长。也就是说，单个请求的上下文越长，同时活跃的请求越多，显存越容易被 KV Cache 占满。此时 GPU 可能还有算力空闲，却因为缓存放不下而无法继续接更多请求。

所以推理系统要管理的并不只有模型权重，还包括：哪些请求正在生成、每个请求的缓存在哪张卡、缓存是否可以分页、请求被抢占后能否恢复，以及长时间不活跃的缓存何时淘汰。

为什么 GPU 之间的网络也会变成瓶颈

大模型通常需要多张加速卡共同工作。模型并行会让卡之间交换激活值、梯度或中间结果；如果跨卡通信跟不上，某些 GPU 就会等待其他 GPU，昂贵的算力被浪费在同步上。

这解释了为什么 AI 数据中心开始强调专用 GPU 网络、RDMA、分层网络和存储系统。网络不是“把请求送到服务器”这么简单，它还负责在一组加速卡之间搬运模型执行所需的中间状态。Google Cloud 的 AI Hypercomputer 资料把 GPU 到 GPU 的通信、主机与存储流量拆成不同的数据平面，目的就是避免管理流量和高带宽计算流量互相争抢。

Prefill 和 Decode 为什么有时要拆开

Prefill 计算密集，Decode 更容易受内存带宽和逐步调度影响。如果把两者混在同一批请求里，长输入的 Prefill 可能阻塞正在等待下一个 token 的 Decode 请求。于是一些推理系统会考虑 Prefill/Decode 分离：前一组机器负责吃掉输入并生成初始缓存，后一组机器接管缓存继续生成。

这样做能改善不同请求之间的隔离，却需要在机器之间传输 KV Cache，还要面对缓存格式、网络带宽、故障恢复和调度复杂度。它不是免费的“开关”，而是用网络和系统复杂度换取更稳定的延迟。