大模型推理的账本上，有一笔隐形开销很少被公开讨论。同一批上下文被反复计算，像餐厅后厨每天重新切同一筐土豆——不是技术做不到保鲜，而是系统没设计好流转。
重复计算正在吃掉你的推理预算
当前生产环境的痛点并非算力不足，而是算力错配。三个主流架构路线各自应对：独立副本横向扩展，接受冗余；共享缓存加智能路由，保留计算结果；或者把大模型拆分到多卡运行。选型关键不在规模，而在一个被低估的变量——请求之间的上下文复用率。
复用率低，KV缓存只是锦上添花；复用率高，它直接决定架构成败。这个判断标准正在重塑开源推理系统的设计优先级。
架构一：独立副本，用冗余换简单
最直白的方案是堆机器。每个请求独占一份模型实例，上下文来了从头算，走了就扔。部署简单，故障隔离干净，适合上下文高度分散的场景。
代价也赤裸：相同前缀被重复编码成百上千次。某头部厂商的内部数据显示，对话类应用中系统提示词（system prompt）的重复计算可占推理开销的20%-40%。这笔钱花得冤枉，但架构上确实省事。
架构二：共享缓存，用复杂度换效率
vLLM和SGLang代表的路线更激进：把KV缓存从GPU显存里解放出来，变成可寻址、可复用的资源。请求到来时先查"有没有算过这段"，命中直接跳过前缀计算。
这要求系统在三个层面协同：缓存存储层管理显存和内存的层级置换；路由层把相似请求导向同一实例；调度层处理前缀匹配的粒度——字符级、token级还是语义级。每一层都增加工程复杂度，但收益在对话、RAG、Agent等多轮场景里立竿见影。
架构三：模型并行，先解决能跑起来的问题
第三条路暂时搁置复用问题，专注把超大模型塞进现有硬件。张量并行、流水线并行把层和块拆开分布，让单卡显存不再成为瓶颈。
这类方案通常假设上下文相对独立，或者复用收益不足以抵消通信开销。但当模型大到一定规模，"能跑"和"跑得快"的优先级自然分层——先解决存在性问题，再谈优化。
选型没有标准答案，只有上下文指纹
三类架构并非互斥，实际部署常混合使用。关键判断依据是业务的请求模式：用户对话占比多少？系统提示词多长且固定？是否存在大量模板化输入？
一个未被充分讨论的细节是，KV缓存复用对延迟分布的影响。缓存命中时首token时间（Time To First Token, TTFT）断崖式下降，但缓存未命中时可能因存储竞争而更差。这种长尾抖动对实时性敏感的产品可能是致命伤。
开源社区正在用代码投票。vLLM的PagedAttention把KV缓存块化管理，SGLang引入RadixAttention实现树状复用，Mooncake把分离式架构推到极端。每条路线都在回答同一个问题：当上下文成为比参数更重的负载，推理系统该如何重新组织？
你的业务里，有多少计算是在重复加热昨天的剩菜？
热门跟贴