MLOps 推理优化批处理与 KV Cache 复用实战一、推理成本的两个大头大模型推理贵主要贵在两处。一是 GPU 算力被请求打散利用率上不去。二是每轮生成都重算历史 token 的注意力浪费显存与算力。这两处都有成熟解法。批处理batching把并发请求合并摊薄固定开销。KV Cache 复用避免重复计算历史键值。两者叠加吞吐可提升数倍。本文探讨在模型服务化中落地这两项优化。目标是同样的硬件扛住更多请求。二、批处理与缓存的协作机制传统逐请求推理GPU 常处于等数据的空转。连续批处理continuous batching按 token 步调度。哪个请求产出一个 token就立刻补一个新请求进来。KV Cache 则缓存每步算出的键值向量。同一次会话的后续 token 直接读取不再重算。跨请求若共享系统前缀如 system prompt也可复用。下面是连续批处理的调度flowchart TD A[请求队列] -- B[调度器按 token 步聚合] B -- C[GPU 一步并行解码多个序列] C -- D{序列结束?} D --|否| E[读 KV Cache 续算下一 token] D --|是| F[移出批次回收显存] E -- B F -- B style C fill:#e1f5fe style E fill:#fff3e0关键在 KV Cache 的显存管理。缓存随序列增长需预分配并复用块。否则显存碎片会限制并发上限。三、生产级推理实现下面用代码描述带缓存的推理封装。from typing import Optional from dataclasses import dataclass, field dataclass class Sequence: 单个生成序列持有已算出的 KV 缓存块 prompt: str token_ids: list[int] field(default_factorylist) kv_blocks: list[object] field(default_factorylist) finished: bool False class BatchedScheduler: def __init__(self, max_batch: int 8): self.max_batch max_batch self.queue: list[Sequence] [] self.running: list[Sequence] [] def submit(self, seq: Sequence) - None: self.queue.append(seq) def step(self) - list[Sequence]: 每步从队列补位保持批次满载提升 GPU 利用率 while self.running and len(self.running) self.max_batch: if not self.queue: break self.running.append(self.queue.pop(0)) # 真实引擎在此调用模型复用各序列的 kv_blocks done [s for s in self.running if s.finished] for s in done: self.running.remove(s) return done def running_count(self) - int: return len(self.running) if __name__ __main__: sched BatchedScheduler() sched.submit(Sequence(解释注意力机制)) sched.step() print(f在跑序列数: {sched.running_count()})真实系统会用 PagedAttention 管理 KV 块。像操作系统分页一样分配显存显著降低碎片。这是高并发推理服务的标配。四、边界分析与架构权衡两项优化收益大但约束明确。延迟与吞吐的权衡。批处理提升吞吐却增加单请求首 token 延迟。实时对话场景要限制批次大小保延迟。离线批处理则可拉满换最大吞吐。KV Cache 的显存上限。缓存越大并发越高显存越紧。需设最大序列长度与并发上限超限排队而非 OOM。前缀复用的风险。共享 system prompt 的 KV 可复用但一旦前缀因用户而异复用失效。应统计前缀重合度只对高重合场景启用。实现复杂度。连续批处理与分页缓存实现门槛高。自建成本高优先考虑 vLLM、TGI 等成熟引擎。推理优化的成本归因要落到账上。批处理与缓存提升吞吐但 GPU 卡时与显存都在烧钱必须能算清每次请求的推理成本。建议埋点采集 token 数、耗时、显存峰值按业务线分摊让优化收益可量化。另一个常被忽略的是输出长度失控模型啰嗦会拖垮 KV Cache 与延迟应在服务端设最大生成长度并裁剪冗余。最后优化要针对真实流量形态离线压测的分布若和线上不符调出的参数上线就失效务必用生产流量回放做验证。五、总结MLOps 推理优化本质是在吞吐与延迟间找平衡点。机制上靠连续批处理填满 GPU靠 KV Cache 复用省算力。工程上优先用成熟推理引擎而非自建。落地路线先上连续批处理提升利用率再引分页 KV 缓存管理显存按场景调批次与上限最后用现成引擎兜底复杂度。同样的卡能服务的请求数往往差出好几倍。