如何避免重復 Prefill:完整講解)
SGLang 前綴緩存RadixAttention如何避免重復 Prefill完整講解【免費下載鏈接】sglangSGLang is a high-performance serving framework for large language models and multimodal models.項目地址: https://gitcode.com/GitHub_Trending/sg/sglang做客服機器人時你會發(fā)現(xiàn)一天幾萬個請求幾乎都從同一段 2000 token 的系統(tǒng)提示詞開頭。不做前綴復用每個請求都要老老實實把這 2000 個 token 的注意力 prefill 跑一遍算力消耗隨 QPS 線性上漲。SGLang 的前綴緩存RadixAttention就是針對這種浪費首個請求把計算結果寫進緩存后續(xù)同前綴請求直接復用現(xiàn)成的 KV只補算自己多出來的尾巴。一句話原理給公共前綴建一份預制品可以把它類比成中央廚房的半成品第一單客人點菜時廚師把前奏部分系統(tǒng)提示詞做熟裝進保鮮盒后面凡是同款前奏的訂單直接開盒接著炒自己的配菜不用再從生料做起。SGLang 里這份保鮮盒就是掛在基數(shù)樹radix tree一種按前綴共享組織的樹結構上的 KV cache鍵值緩存索引實現(xiàn)位于 python/sglang/srt/mem_cache/radix_cache.py。省下的時間不是來自更快的算子而是來自這部分根本不用算。SGLang 處理一次請求的流程命中是怎么發(fā)生的把視角放在一個請求從進來到離開整個過程分四步匹配match請求 tokenize 后從樹根開始逐段比對找到當前序列已緩存的最長前綴。若匹配終點落在某個節(jié)點段中間會自動執(zhí)行節(jié)點分裂split node把邊界切干凈——這不復制數(shù)據(jù)只是重排結構。只算增量模型前向只處理沒命中的那部分 token。命中 80% 的請求prefill 計算量就只剩 20%。寫回insert新算出的 KV 索引掛到樹上對應位置供下一個同前綴請求命中。釋放與回收每個節(jié)點帶lock_ref引用計數(shù)請求在飛期間前綴被鎖住不受淘汰影響請求結束后鎖釋放節(jié)點回到可淘汰evictable集合。內存吃緊時淘汰器用堆按策略默認 LRU彈出最老的葉子釋放被鎖節(jié)點自動跳過。匹配用頁page做對齊當page_size 1時命中長度會向下取整到頁的整數(shù)倍這同時是內存對齊和碎片控制的抓手。啟用 SGLang 前綴緩存的 3 個常用啟動參數(shù)前綴緩存默認開啟什么都不用改就已經在工作。下面 3 個參數(shù)覆蓋了大多數(shù)調優(yōu)場景python -m sglang.launch_server \ --model-path 模型路徑 \ --page-size 16 \ --radix-eviction-policy lru # 對比實驗時可顯式關閉緩存 python -m sglang.launch_server --model-path 模型路徑 --disable-radix-cache參數(shù)默認值作用--disable-radix-cacheFalse布爾開關關掉前綴緩存做 A/B 對比--page-size視后端而定頁大小匹配/插入/淘汰的對齊粒度建議 16 這類 2 的冪--radix-eviction-policylru淘汰策略可選lru/lfu/slru/priority命中率不用翻日志服務加--enable-metrics后指標接口會暴露緩存命中率、evictable_size可回收量與protected_size被鎖保護量等直接接 Prometheus 即可實現(xiàn)見 python/sglang/srt/observability/metrics_collector.py。性能數(shù)據(jù)前綴緩存能省多少場景基線無復用RadixAttention變化幅度多輪對話1.0x3.2x220%批量提示工程1.0x4.8x380%代碼補全1.0x2.7x170%文檔摘要1.0x5.1x410%數(shù)據(jù)口徑說明以上為參考文章復述的對比數(shù)據(jù)以無緩存 prefill 耗時為基線做相對加速比實際數(shù)值取決于模型、序列長度與前綴重疊率規(guī)律是共享前綴占比越高收益越大四舍五入后量級約為 5 倍封頂。進階速覽分塊前綴緩存與 HiCache 分層分塊前綴緩存Chunked Prefix Cache長序列請求被切成多個 chunk 分塊 prefill普通模式下整條前綴要等第一個請求算完才可共享。該特性讓邊算邊共享成為可能目前面向 DeepSeek 等長序列模型短序列場景若覺得有額外開銷可用--disable-chunked-prefix-cache關閉相關閾值由環(huán)境變量SGLANG_CHUNKED_PREFIX_CACHE_THRESHOLD控制。HiCache 混合緩存把 KV 從 GPU 顯存擴展到主機內存形成設備端 主機端兩級。設備端未命中時會先去主機端撈而不是直接重算。關鍵參數(shù)是--hicache-ratio主機池/設備池比值cache 模式默認 2.0和--hicache-write-policy可選write_back/write_through/write_through_selective。對前綴很長、復現(xiàn)間隔長到會被 LRU 淘汰的負載這一層是命中率兜底。避坑與調優(yōu)命中率、鎖和命名空間隔離現(xiàn)象原因處理KV 池緊張但緩存遲遲不釋放在飛請求持有l(wèi)ock_ref被鎖節(jié)點計入protected_size淘汰器會跳過先查 protected 占比縮短單請求上下文或降低并發(fā)熱前綴多時換slru/priority策略保活長序列首個請求耗時內緩存遲遲不可復用chunked prefill 下 KV 分塊寫入整條前綴寫完才完整可共享長序列場景依賴分塊前綴緩存特性短序列負載用--disable-chunked-prefix-cache省掉開銷換了 LoRA 或采樣 salt 后命中率驟降RadixKey支持extra_key命名空間不同命名空間的 token 序列故意不共享節(jié)點這是設計特性而非 bug想共享就保持命名空間一致想隔離不同 adapter、不同 RAG 上下文則正該這樣用高頻疑問前綴緩存是默認開啟的嗎是。disable_radix_cache默認 False起服務即生效。想關閉只需要加--disable-radix-cache。命中率怎么查--enable-metrics啟動后拉/metrics關注前綴緩存命中率以及evictable_size、protected_size兩個量。命中率長期偏低且 evictable 接近 0通常說明緩存容量小于工作集考慮擴顯存預算或上 HiCache。淘汰策略怎么選默認lru對多輪對話夠用請求模式高度重復少數(shù)超熱前綴可試lfu想給關鍵租戶的前綴更高存活率用priority按優(yōu)先級淘汰。節(jié)點分裂會不會造成 KV 重復拷貝不會。分裂只調整樹上節(jié)點的邊界與指針KV 索引按段切分引用不重復搬運顯存數(shù)據(jù)。寫在最后SGLang 的前綴緩存把重復 prefill 同一前綴從默認行為變成了可感知、可度量、可淘汰的一等公民基數(shù)樹負責找前綴引用鎖負責保安全頁對齊負責控碎片策略化淘汰負責省顯存。理解了這條鏈路你就有了在真實負載下調命中率和內存水位的全部抓手。接下來值得關注的是跨實例的緩存共享與量化格式 KV 的落地前綴復用正從單服務內優(yōu)化走向集群級基礎設施?!久赓M下載鏈接】sglangSGLang is a high-performance serving framework for large language models and multimodal models.項目地址: https://gitcode.com/GitHub_Trending/sg/sglang創(chuàng)作聲明:本文部分內容由AI輔助生成(AIGC),僅供參考