在 vLLM 与 llama.cpp 之外，SGLang 是 2026 年生产环境里增长最快的开源推理引擎之一：8 月版本 0.5.17 发布，先后为 Qwen3.8（8 月 12 日）、Qwen3.8-Flash-Next（8 月 26 日）提供 day-0 支持，还把全套特性搬到了 Google TPU 上。它的核心武器是 RadixAttention——用一棵基数树自动跨请求复用 KV cache。这套机制在 Agent 时代突然变得关键，原因值得讲清楚。
一次对话里藏着多少重复 prefill
传统推理引擎把每个请求当成独立任务：用户每多发一轮，系统提示、工具描述、历史对话都要重新算一遍 prefill。一个十轮的 Agent 会话，系统提示可能被完整计算十次。
RadixAttention 的做法是：把每个请求的 token 前缀组织成基数树（radix tree），树上每个节点对应一段连续 token 的 KV cache。两个请求共享同一个前缀，就直接复用同一块 GPU 显存里的 KV，跳过重复计算。多轮对话、RAG 的固定系统提示、Agent 重复挂载的工具清单——这些天然共享前缀的场景，命中之后 prefill 成本直接归零。
2026 年的进化：从全注意力到混合架构
SGLang 今年的两次升级更说明方向。4 月支持 DeepSeek-V4 时提出 ShadowRadix：混合注意力（滑动窗口 + 压缩状态）下，用虚拟全 token 坐标系统一把 KV 与循环状态都索引进基数树。8 月支持 Qwen3.8 时又推出 Unified Radix Cache，同时管理全注意力 KV 与 Mamba/GDN 递归状态。HiCache/HiRadixTree 进一步把冷数据卸到主机内存。
换句话说，前缀缓存已经从「标准 Transformer 的优化项」变成「任何新架构上线时必须先解决的一等公民问题」。
工程上怎么用
部署上只要打开前缀缓存开关，SGLang 会自动复用；真正决定收益的是你的提示结构——把不变的系统提示放在最前面、工具描述顺序固定、少在前缀里塞时间戳，命中率就能上去。对跑多租户 Agent 平台的团队，这是少写代码、立刻省钱的一项。
反过来，如果你发现缓存命中率上不去，先别怀疑引擎，去看日志里每个请求的前缀是不是被随机注入了会话编号、当前时间或用户名。这些看似无害的动态内容，会把本该共享的前缀彻底打散，让基数树退化成一棵棵孤儿节点。
去论坛讨论
这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：SGLang 前缀缓存