SGLang 的 radix 缓存驱逐策略lru/lfu/slru/priority怎么选【免费下载链接】sglangSGLang is a high-performance serving framework for large language models and multimodal models.项目地址: https://gitcode.com/GitHub_Trending/sg/sglang当 SGLang 服务在 KV cache 池被打满时需要回收空间radix cache 会驱逐已缓存的前缀--radix-eviction-policy决定哪个前缀先被丢弃。默认值是lru对大多数负载来说它就是正确选择lfu、slru、priority则分别把最近使用换成命中频率复用历史请求优先级来打分。本文给出每种策略的适用条件、启动命令和参数配置方式以及切换策略后如何验证是否真的更优。驱逐机制策略只决定先丢谁理解策略差异前先明确驱逐的基本规则来自 radix_eviction_policy 文档只有可驱逐叶子会进入候选集KV 存在、未被在途请求锁住、且没有被仍持有 KV 的子节点遮蔽的节点。根节点永不可驱逐。策略对每个候选打分分数最低的先被驱逐。一个叶子被驱逐后它的父节点可能变成叶子重新进入候选集所以驱逐是沿着分支从叶向根推进的。策略只负责打分不负责决定释放多少空间也无法把 KV 钉在内存里——即使某节点受策略保护只要回收其他部分不够腾出空间它一样会被驱逐。所有策略在分数打平时都退回 LRU 顺序。这个不能钉住 KV的边界很重要如果你期望某个前缀永不消失任何驱逐策略都给不了这个保证。四种策略的适用条件通过--radix-eviction-policy选择其一默认lru文档给出的适用判断如下策略先驱逐谁什么时候用lru默认最久未被使用的前缀通用服务场景符合前缀复用时问随时间衰减的规律lfu命中次数最少的前缀同频者取最久未用一小撮 prompt 被复用得远比其他多你希望它们在一次性的突发流量冲击中存活下来slru仍在 probationary 段的前缀段内取最久未用类似lfu但你希望给一次性前缀最多能挤掉多少已验证热前缀设一个硬性下限见下文slru参数priority属于最低优先级请求的前缀再按最久未用你正在使用 priority scheduling希望缓存保留顺序与准入排序保持一致打分输入有两个需要注意的细节命中计数lfu、slru使用统计的是节点被后续请求命中的次数。它不会在 chunked-prefill 分片步骤、已被驱逐的节点、或 write-back 模式的 HiCache 下递增——如果你的部署启用了这些特性lfu/slru看到的频率信号会比直觉中弱。请求优先级priority使用取插入该前缀的请求的priority字段被多个请求到达的节点保留其中最高优先级。没有开启 priority scheduling 时所有节点的优先级都是0此时priority策略等价于lru。策略注册表里其实还有fifo、mru、filo但它们不通过命令行提供只能由树外扩展策略列表的代码访问到属于实验用途而非正式服务选项本文不展开。启动服务并选择策略策略直接作为启动参数传入。lru是默认值不传即生效换成其他策略只需改这一个参数python3 -m sglang.launch_server \ --model-path MODEL_PATH \ --radix-eviction-policy lfu命令中MODEL_PATH需要替换为你实际加载的模型路径。server_arguments 文档中该参数的默认值同样标注为lru可选值为lru、lfu、slru、priority。给策略传参数--radix-eviction-policy-config部分策略接受调优参数以 JSON 对象形式传给--radix-eviction-policy-config键就是策略自己的参数名因此只对当前选中的策略有效。文档给出的示例是slrupython3 -m sglang.launch_server \ --model-path MODEL_PATH \ --radix-eviction-policy slru \ --radix-eviction-policy-config {protected_threshold: 4}不传该 flag 即接受全部默认值。两个硬性约束lru、lfu、priority目前不接受任何参数对它们传该 flag 时任何键都会报错无法识别的键不是被忽略而是启动时直接失败例如把protected_threshold拼错为protected_treshold会报TypeError: SLRUStrategy.__init__() got an unexpected keyword argument protected_treshold使用实验性 Rust 树核SGLANG_UNIFIED_RADIX_TREE_CORE_BACKENDrust时--radix-eviction-policy-config不被支持——该后端只根据策略名构建策略同时传两个参数会在启动时失败。slru参数protected_thresholdslru是唯一带参数的策略。它把缓存分成probationary考察段和protected保护段前缀先进入考察段命中次数足够后被提升到保护段驱逐时考察段的内容先于保护段全部处理完。键类型默认值含义protected_thresholdint2前缀被提升到保护段的命中次数调大它会让提升更难保护集更小、更贴近真正热的前缀例如阈值设为4时命中 3 次的前缀仍在考察段默认2时它已被保护。降到1则任何复用过一次的前缀都会被保护行为接近带一次命中宽限的lru。文档给出的4只是示例取值实际取值应结合命中率指标调整而不是照抄。用priority策略的前置条件priority策略依赖 priority scheduling。按 server_arguments 文档需要额外开启--enable-priority-scheduling布尔 flag默认Falsepython3 -m sglang.launch_server \ --model-path MODEL_PATH \ --enable-priority-scheduling \ --radix-eviction-policy priority不开 priority scheduling 时所有节点优先级为0priority策略就退化为lru传它没有意义。如何判断该不该换策略文档的选型建议非常直接从lru开始只有在拿到实测缓存命中率后才换。命中率计数器通过--enable-metrics暴露因此对比实验的正确做法是用默认lru跑一段真实流量开--enable-metrics记录缓存命中率换目标策略如lfu或带protected_threshold的slru重复同样的流量对比指标命中率没有改善就没有理由承担策略切换的代价。文档同时指出了lfu/slru会变差的场景前缀热度随时间漂移时命中次数高的前缀即使已经不再有用也凭借历史计数继续享受保留优势。换句话说lfu/slru赌的是热集合稳定你的流量不满足这个前提时它们比lru更糟。边界与限制小结驱逐策略不控制释放量也不能阻止任何节点最终被驱逐--radix-eviction-policy-config只对slru有效对其他策略或拼错的键都会在启动时报错而不是静默忽略SGLANG_UNIFIED_RADIX_TREE_CORE_BACKENDrust下不支持 config 参数两者同传启动失败lfu/slru的命中计数在 chunked-prefill、已驱逐节点和 write-back HiCache 下不递增priority策略在未开 priority scheduling 时等价于lru。更多参数细节如 priority scheduling 相关的--abort-on-priority-when-disabled、--priority-scheduling-preemption-threshold等可继续查阅 server_arguments 文档驱逐策略的完整说明见 radix_eviction_policy 文档。【免费下载链接】sglangSGLang is a high-performance serving framework for large language models and multimodal models.项目地址: https://gitcode.com/GitHub_Trending/sg/sglang创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考