云GPU推理：拆分服务KV优化实操

很多团队租了云GPU跑大模型推理，看着卡在那里却利用率上不去。看着监控，SM利用率常常只有二三十，甚至更低，钱却一分没少花。这不是卡不够强，而是推理本身的特性在作怪。

推理分两段：prefill把长prompt或上下文一次性算完，生成KV cache；decode则一个token一个token往外吐。prefill偏计算密集，decode偏内存带宽。两者挤在同一张卡上，长prompt一来，decode就被饿着，并发一高，显存里KV cache直接爆炸。单请求Llama 3 70B在128K上下文下，光KV cache就能吃掉40多GB，模型权重再一占，并发空间几乎为零。多用户一上来，要么排队，要么OOM。

这几年大家慢慢摸出了路子。先从KV cache下手。

PagedAttention把KV当成虚拟内存，按小块按需分配，请求结束立刻释放。以前预留最大长度，实际用不到一半的空间白占着，现在利用率直接翻倍甚至四倍。vLLM默认就开，配上合适的max-model-len和gpu-memory-utilization就能用。

再量化。KV对精度没那么敏感，FP8直接砍半，NVFP4在新架构上还能再砍。70B模型32K上下文8并发，从80多GB掉到20GB左右很常见。质量损失在生产里大多可接受，尤其是非极致推理任务。CPU或NVMe offload当二级缓存也行，高峰时把冷block换出去，低优先级请求不至于直接拒。

这些还只是单机优化。真正拉开差距的是拆分服务。

把prefill和decode放到不同GPU池子里。prefill池专吃长上下文，算完把KV直接传给decode池继续生成。两边独立扩缩，互不干扰。长prompt不再拖累正在吐token的用户，decode池也能专门针对内存带宽优化。再加KV-aware路由：新请求优先打到已经缓存了相同前缀或历史的卡上，少重算。系统提示词、RAG文档、多轮对话历史这些共享部分，TTFT能从十几秒掉到一两秒。

有实操经验的人反馈，哪怕只拆成两张卡，配合缓存路由和offload，整体吞吐和首token速度也能明显提升三成左右。流量形状变了，planner还能动态调整prefill/decode比例，不用手调。

云端特别适合玩这套。本地买卡固定比例，流量一变就闲着。云上按需拉起不同规格实例，prefill用算力强的，decode用显存大或带宽高的，跑完释放。弹性调度让利用率从二三十往五六十甚至更高靠。训练集群饱和、推理却闲一半的情况，用autoscaling到零和分时复用也能压下去。

选平台时看网络。拆分服务依赖快速KV传输，InfiniBand或高带宽RoCE是标配，延迟一高收益就没了。存储也得跟上，方便做多级缓存。现在有一类专注GPU的云服务，硬件更新快、配置简单、按量计费，正好匹配这种动态拓扑。NexGpu这类平台提供灵活的GPU租赁和弹性扩展，正好能支撑你快速验证prefill/decode池子，再根据实际流量调整规模，不用一开始就锁死一堆卡。

实操步骤可以这样走。先单机vLLM跑起来，开PagedAttention、FP8 KV、prefix caching，测基准吞吐和延迟。监控内存带宽和SM利用率，确认是不是内存墙。然后上多卡，用框架把prefill和decode拆开，配置KV传输和路由。小流量先验证缓存命中率，再逐步加压。多轮agent或长上下文RAG场景收益最大，系统提示词一长，缓存命中直接省大头。

常见误区有几个。一是上来就全拆，小流量反而增加复杂度，先聚合模式测清楚再拆。二是忽略传输开销，网络不够快，拆了还不如不拆。三是只盯峰值，忘了日常波动，弹性策略没配好，还是浪费。四是量化没验证任务，某些推理链对精度敏感，先A/B。

价格波动也得考虑。GPU租赁价像石油一样跟着供需晃，短周期可能涨跌明显。拆分加缓存把同样算力压出更多token，单位成本就稳了。需求上来时弹性扩，闲时缩，比死守固定集群划算。NexGpu支持按需和灵活调度，正好帮中小团队在波动里卡准节奏，把优化落地到生产，而不是纸上谈兵。

落地时别贪大。先从两卡或四卡验证端到端延迟和缓存命中，数据出来再扩。工具链成熟了，vLLM、相关编排框架都能直接用，云端镜像一拉就有环境。监控别只看GPU利用率，加上TTFT、ITL、缓存命中率、每token成本，这些才是真正赚钱的指标。

推理已经占了大部分算力消耗，优化服务架构比单纯堆卡更有效。把prefill和decode拆开，把KV管好，同样的云GPU能服务更多用户、更长上下文、更复杂的多轮任务。试过的人都知道，一旦跑通，账单和体验都会不一样。接下来就看你怎么在自己的流量里把这些细节调到位了。