導讀

接着上一節內容，本文系統介紹了阿里雲 Tair KVCache 團隊與服務器研發存儲軟硬件結合團隊對 3FS（高性能 KVCache 底座）開展的全方位工程化升級實踐。
面向 AI 大模型推理中高吞吐、低延遲、強穩定性的核心訴求，團隊從性能調優、產品化增強與雲原生管理三大維度推進深度優化：
在性能層，通過 RDMA 流量均衡與小 I/O 參數調優，實現 4K 隨機讀 IOPS 提升 150%，並集成全用户態落盤引擎以降低資源開銷；
在產品層，解決 Mgmtd IP 漂移、存儲分配失衡等關鍵穩定性問題，新增 GDR 零拷貝與多租户隔離機制，支持 HBM 緩存與後端存儲的端到端高效協同；
在運維層，基於 Kubernetes Operator 構建雲原生管控體系，實現一鍵部署、故障自愈、彈性擴縮容與多集羣隔離，並配套可視化監控大盤，顯著降低 AI 基礎設施的運維複雜度與人力成本。
本實踐為高性能 KVCache 在企業級 AI 場景中的規模化落地提供了可複用的技術範式。
本系列技術文章將系統性拆解面向智能體推理的 KVCache 技術演進路徑：

1. 智能體式推理對 KVCache 的挑戰與 SGLang HiCache 技術深度剖析
2. 本文 | 3FS-KVCache 工程化落地：企業級部署、高可用運維與性能調優實踐
3. Hybrid Model Support：SGLang 對 Mamba-Transformer 等混合架構模型的支持方案
4. Tair KVCache Manager：企業級全局 KVCache 管理服務的架構設計與實現
5. KVCache 仿真分析：高精度的計算和緩存模擬工業級實踐
6. Hierarchical Sparse Attention：分層稀疏注意力框架下的 KV 分層管理與按需加載
7. 展望：KVCache驅動的軟硬結合演進

Tair KVCache 作為阿里雲數據庫Tair產品能力的延伸，本質是緩存範式的三次躍遷：
🔹 從 Redis 的 “緩存數據 → 減少 I/O”
🔹 到 GPU KVCache 的 “緩存計算中間態 → 減少重複計算”
🔹 再到 Tair KVCache 的 “規模化、智能化的注意力狀態管理 → 重構大模型推理成本模型” 它標誌着緩存正從輔助組件升級為AI 基礎設施層的核心能力——讓“狀態”可存儲、可共享、可調度，支撐智能體時代的規模化推理底座。

1.簡介

1.1 KVCache 簡介

在大語言模型的推理階段，生成式推理本質上遵循自迴歸範式：模型按順序逐個輸出 token，每一步的預測都依賴於此前已生成的所有內容。這種機制雖然有助於維持輸出的語義一致性，卻也引入了明顯的計算冗餘——尤其是在注意力機制中，Key（K）和 Value（V）向量的重複計算成為性能瓶頸。
具體來説，每當生成一個新的 token 時，模型需將其對應的 Query（Q）與所有歷史 token 的 K 和 V 進行點積操作，以計算注意力權重並聚合上下文信息。值得注意的是，歷史 token 的 K 和 V 在後續生成步驟中始終保持不變。若在每次解碼時都重新計算這些不變的向量，將導致大量無效計算。
為應對這一問題，業界普遍採用 KVCache 技術：即在首次生成每個 token 時，將其 K 和 V 向量緩存起來，並在後續自迴歸過程中直接複用，從而跳過重複的前向計算。這項優化大幅減少了推理延遲，顯著提升了吞吐能力，已成為現代大語言模型實現高效流式生成的核心手段之一。

1.2 L3 KVCache 需求和選型

隨着大語言模型（LLM）推理場景向長上下文、高併發、低延遲方向快速演進，尤其在多輪對話、RAG（檢索增強生成）等典型應用中，模型需頻繁訪問海量歷史上下文或外部知識，因此對於擴展KVCache 的存儲選型上我們看到以下特點：

L3 層 SSD KVCache 存儲方案解決共享容量及成本上的問題，但是目前常用的分佈式文件存儲都有其自身的侷限性。傳統的閉源解決方案如 GPFS 雖然性能強大，但其高昂的使用成本和複雜的後續維護優化工作成為企業部署的主要阻礙。而主流的開源分佈式文件系統常聚焦於通用存儲的場景，但在 KVCache 的應用場景下仍存在明顯的侷限性：以 Ceph 為例，其作為通用文件存儲系統被廣泛採用，但在 KVCache 這一特殊場景中，其設計無法滿足高帶寬和低延遲的核心性能要求；JuiceFS 提供了靈活的架構設計，但其和後端對象存儲依賴過深使得性能受限，高耦合度也增加了系統運維的複雜性和潛在風險。
3FS 作為 DeepSeek 開源的高性能分佈式文件系統，憑藉其高吞吐、低延遲、大容量共享存儲特性，為 AI 訓練與推理提供了極具競爭力的存儲底座。

1.3 3FS 介紹

3FS（Fire-Flyer File System）是開源的高性能分佈式文件系統，它利用 SSD 和 RDMA 網絡來提供共享存儲層以簡化分佈式應用的開發。3FS 旨在應對人工智能訓練和推理工作負載的挑戰，提供比基於 DRAM 的緩存更具成本效益的替代方案，具備高吞吐量和大容量的特性。
3FS 核心組件包含 Fuse、Meta、Mgmtd 和 Storage，所有組件通過 RDMA 網絡連接，各組件之間的交互關係如下圖所示：

圖1 3FS架構圖
（1）Mgmtd：管控服務，採用主備策略保證自身高可用，當主節點失效，另一個 Mgmtd 副本會被選為新的主節點。Mgmtd 管理集羣的配置，所有 Meta 組件、Storage 組件以及 Fuse 客户端均通過週期性的心跳機制維持其在線狀態，同時，各組件會週期性地從 Mgmtd 獲取集羣的最新狀態（如集羣拓撲、ChainTable 信息等）。
（2）Meta：元數據服務（如 open/close 文件），實現了文件系統語義。Meta 是無狀態服務，將元數據信息持久化到事務性KV數據庫 FoundationDB，支持多個 Meta 服務擴展，客户端可以連接到任意一個元數據服務，同時 Meta 會根據 InodeId 轉發請求。
（3）Storage：存儲服務基於本地文件系統管理 SSD 存儲資源，Storage 所管理的每塊 SSD 上，會被抽象出若干個邏輯存儲單元 Target，不同 Storage 的 Target 之間組成一條 Chain，副本之間通過鏈式複製協議（CRAQ）來確保強一致性，讀文件會隨機選擇 Chain 上的一個 Target 讀取，寫文件則寫 Chain 的 Head Target，然後通過 CRAQ 協議鏈式寫同步副本數據。CRAQ 的這種“寫全部、讀任一”機制有助於充分發揮 SSD 和 RDMA 網絡的吞吐能力，尤其對讀帶寬十分友好。
（4）Client：FUSE 是 Linux 內核提供的一種用户態文件系統接口，允許用户通過標準的 POSIX 文件操作語義訪問非內核實現的文件系統。3FS 通過 FUSE 服務，使用户能夠以熟悉的文件系統方式透明地操作 3FS 集羣中的文件，適用於大多數對兼容性要求較高的應用場景。

圖2 文件Chunk分佈

圖3 3FS客户端
此外，3FS 還提供了 USRBIO 客户端接口， 該接口是一套用户態、異步、零拷貝 API，使用時需要業務代碼進行一定程度的適配和修改。其元數據操作仍然依賴於 Fuse ，但每個讀寫請求可以直接從用户進程發送給 FUSE Daemon，消除了系統調用上下文切換和數據拷貝開銷，實現了更高的性能。

1.3.1 3FS 在 KVCache 場景的核心優勢

3FS 作為專為並行計算環境設計的分佈式文件系統，在 KVCache 場景中的優勢：
容量和成本：3FS 充分考慮到 KVCache 對大容量存儲空間的基本需求，對大量存儲節點上的SSD資源進行統一池化管理，提供PB級的存儲池，有效支撐大規模數據處理需求，同時在性能和成本之間實現了理想的平衡。
寬帶和延遲：3FS 採用全鏈路端到端的 RDMA 傳輸，保證數據傳輸的高帶寬、低延遲，同時 USRBIO 客户端零拷貝機制優化數據傳輸路徑，減少用户態和內核態上下文切換開銷，進一步降低 I/O 延遲。根據 3FS 官方公佈的數據，在一個包含 180 個存儲節點的集羣中，讀帶寬達到約 6.6TiB/s。
讀優先策略：考慮到 KVCache 典型的讀多寫少訪問模式，3FS 在設計時特別優化了讀取路徑的效率。基於 Chain Replication with Apportioned Queries (CRAQ) 協議，讀操作可隨機選擇副本，在面對大規模讀取請求時仍能保持卓越的性能表現，充分適應了 KVCache 場景中讀取密集型的工作負載特徵。

圖4 3FS官方性能數據

1.3.2 開源 3FS 的侷限性與優化挑戰

同時開源的 3FS 有以下不足：

• 多組件協同複雜性問題：在雲原生異構環境中，在 GPU/HBM 計算單元、RDMA 網絡架構與 NVMe 存儲介質構成的異構體系中，缺乏統一的跨層協同機制；IP 地址漂移引發組件狀態不一致問題，形成分佈式孤島效應，難以滿足高併發AI推理場景下多模型並行、多階段流水線的動態彈性調度需求。
• 資源利用率低等問題，I/O側：小 I/O 密集型負載（如 KVCache 檢索、Attention 緩存落盤）下傳統內核旁路方案仍存在 CPU 綁核競爭與內存拷貝瓶頸，HBM → DRAM → SSD 多級落盤鏈路延遲高、帶寬利用率不足 40%；計算側：缺乏 GDR（GPU Direct RDMA）支持時，數據需經 Host 內存中轉，GPU 顯存與存儲間帶寬浪費顯著；調度側：存儲資源分配不合理，隨着集羣規模增長，存在存儲容量/帶寬熱點問題，無法隨數據量增長保持負載均衡。
• 雲原生運維能力薄弱：部署與生命週期管理依賴人工腳本，缺乏聲明式 API 與狀態自省能力；故障恢復依賴人工介入（如 Storage 故障後需要手動重建）；監控體系缺少可視化方案，運維複雜並難以滿足 SLO 驅動的 AIOps 需求。

因此，阿里雲 Tair 團隊和服務器研發存儲軟硬件結合團隊以 3FS 為基礎，通過系統級改造適配及產品化能力提升，為 Tair KVCache 產品提供 L3 級 KVcache 能力並開源至 SGLang、vLLM 等推理引擎社區中。通過該方案實現了全局 KVCache 的高效複用，在降低顯存壓力的同時，進一步提升推理效率與資源利用水平。

2. 3FS 進化之路

阿里雲服務器研發存儲軟硬件結合團隊從性能調優、產品化增強、雲原生化管理等維度對 3FS 進行了系統性升級：

• 性能突破：通過 RDMA 流量均衡優化與小 I/O 場景參數調優，將 4K 隨機讀 IOPS 提升 150%，並引入 全用户態落盤引擎進一步降低資源消耗；
• 產品力增強：攻克 Mgmtd IP 漂移、存儲分配不均等穩定性問題，新增 GDR 零拷貝與多租隔離能力，實現 HBM 到存儲的端到端高效協同；
• 雲原生管理：基於 Kubernetes Operator 實現一鍵部署、故障自愈、多集羣隔離，結合彈性擴容與監控大盤，顯著降低 AI 基礎設施的運維門檻。

圖5 3FS產品圖

2.1 性能優化

我們使用物理存儲服務器對 3FS 進行了本地部署驗證和性能調優，實驗環境的關鍵硬件配置及集羣拓撲結構概覽如下：

（1）大 I/O 場景下的 RDMA 網絡配置與 I/O 併發配置調優

3FS 在大塊 I/O 讀帶寬方面表現優異，但隨着客户端數量增加，總讀帶寬未線性增長，反而因客户端間 I/O 干擾而下降。進一步分析發現 RDMA 網絡流量分佈嚴重不均，部分網卡利用率低於 40%，而另一些已接近 100% 飽和，主要原因是 RDMA 隊列對（QP）數量不足。通過調整相關的 QP 配置參數，網卡端口流量均衡分佈，總讀帶寬隨客户端數線性提升， 3FS 在大規模分佈式場景下的良好可擴展性。
針對寫帶寬的瓶頸，增加了 I/O 鏈路上的併發配置，在上述優化後，單 USRBIO 客户端對 4M I/O 的讀寫帶寬從之前的 29.5GB/s、5312MB/s 提升到 40.2GB/s、31.4GB/s。

（2）小 I/O 場景下的參數調優及落盤引擎升級

在性能測試中，3FS 的小塊（4K~64K）隨機讀 IOPS 較低，單個 Storage 節點的 4K 隨機讀 IOPS 僅200K 左右，經分析確認，性能瓶頸主要源於在小 I/O 讀場景下 Storage 的監聽線程資源耗盡。針對這一問題，我們對 Storage 組件的多項參數進行了調優，包括監聽線程數、I/O 工作線程數、隊列深度等。經過優化配置，在相同測試條件下，4K 隨機讀 IOPS 提升至約 500K，性能提升約 150%。
基於上述優化，考慮到塊存儲相比文件存儲在隨機小 I/O 場景更具優勢，我們以全用户態存儲引擎替換原有的本地文件系統作為 3FS 的落盤引擎（如下圖所示）。測試結果顯示，在上述參數調優的基礎上，使用全用户態存儲引擎後，系統資源消耗明顯降低：CPU使用率下降約 27%。

圖6 全用户態存儲引擎

2.2 功能擴展

隨着 3FS 在不同環境下的規模化應用，其在集羣穩定性、存儲資源利用率及性能表現方面面臨多重挑戰。為攻克這些技術難關，我們從多維度對 3FS 進行系統性增強：

• 高可用架構加固：通過 DNS 解耦與多網卡探測機制，實現 Mgmtd 服務的無縫切主與跨集羣容錯；
• 存儲資源精細化管理：重構 ChainTable 生成規則與文件的 Chain 分配策略，消除容量分配不均與資源浪費；
• 端到端性能突破：使能 GPU Direct RDMA（GDR）技術，消除 HBM 到內存的冗餘拷貝；
• 安全與擴展性升級：引入多租户隔離能力，支持租户級訪問控制與數據物理隔離。

（1）Mgmtd IP 變化導致集羣不可用

Mgmtd 組件負責維護 3FS 集羣的全局拓撲信息和各組件的狀態，一旦其他組件無法連接到 Mgmtd Primary 服務，就無法獲取最新的集羣狀態，從而導致整個 3FS 集羣處於不可用狀態。
為了簡化 3FS 的部署流程，我們採用了容器化部署方式。然而，在實際運行中，當 Mgmtd Pod 因進程OOM、Pod 被驅逐或節點下線等原因發生重啓或遷移時，其對外暴露的 IP 地址會發生變化，導致其他組件無法重新建立與 Mgmtd 的連接，進而影響集羣穩定性。
為了解決這一問題，我們在 Mgmtd Client 中引入了 DNS 解析機制，通過使用 DNS 名稱替代硬編碼的 Mgmtd IP 地址列表，實現對 Mgmtd 服務的高可用訪問。在 Kubernetes 環境中，我們基於 Headless Service 實現該機制，使得即使 Mgmtd Pod 發生變更，其他組件也能通過固定規則的 DNS 名稱自動發現並重新連接到當前的主節點，從而提升系統的容錯能力與可用性。

圖7 DNS 解析機制

（2）文件容量分配不均勻，無法充分利用後端存儲空間

3FS 創建文件時，會按照循環的方式為文件分配 ChainTable 中連續 stripe size 數目的 Chain，實現Chain 維度的“負載均衡”，然而 ChainTable 默認的生成規則會將各個節點上相同 disk index 的盤排布在同一條 Chain 上，且這些相同盤位的 Chain 在 ChainTable 中相鄰。當 stripe size 較小，Target 數目較多時，會出現文件只能使用少部分盤容量的情況，導致單文件的容量上限存在瓶頸，無法完全利用所有存儲節點的空間。
為此，我們對 ChainTable 創建的分配策略進行了優化，在生成 ChainTable 的時候隨機打散各個存儲節點上的 Target 排布，並設置滿足上述條件的最小 stripe size，使每個 3FS 文件能夠充分利用後端存儲空間。

圖8 ChainTable生成規則優化

（3）擴容時存儲空間使用不均衡，導致部分文件不可用

在 3FS 擴容過程中，由於文件創建時隨機選擇 Chain 列表，導致擴容前的 SSD 使用率過高，而擴容後的 SSD 存儲空間使用率低，導致部分文件創建後由於後端存儲佔滿而無法寫入數據。
針對此問題，我們調整了文件分佈算法，採用了基於存儲使用量為優先級的分配策略，實現了更均勻的存儲負載均衡，確保擴容後新創建的文件能夠優先分配使用率更低的存儲節點，正常讀寫。

（4）多網卡環境下 Mgmtd Primary 故障後，組件無法正常連接新的 Primary 節點

在多網卡環境下，當 Mgmtd Primary 節點故障導致切主時，對於新選舉的 Mgmtd Primary 節點，其餘組件始終無法正常連接到新的 Mgmtd Primary 節點，導致整個集羣處於不可用狀態。
經過定位，我們發現在 Mgmtd 切主後，其餘組件會嘗試對舊Primary節點的多個網卡進行探測，但僅會重試一次，導致陷入對舊 Primary 探測的循環，始終無法無法探測新的 Mgmtd Primary。基於上述分析，我們增加了重試和探測機制，使得其他組件能正常探測到新的 Primary 節點，保證了集羣的可用性。

（5）節點故障時 IO 歸零

多副本情況下，單個 Storage 節點故障後，出現 I/O 歸零 60s，最後出現出現 I/O ERROR；I/O的寫入是按照 Target 順序逐次寫入 Storage，寫完所有返回成功，如果某個 Storage 節點發生故障，則會不停重試，此時 I/O 歸零，當達到重試上限時，則會上報 I/O ERROR；

圖9 探活storage
Fuse 發現單個 I/O 超時後，向 Mgmtd 發起探測請求，Mgmtd 將對故障的 Storage 節點進行存活探測。如果確認 Storage 節點已失活，則修改Mgmtd中緩存的路由信息，把失活 Storage 對應的 Target 狀態更新為 OFFLINE，並將其持久化至 FDB 中。之後將更新的路由信息以廣播的方式推送給各個節點，並把探測結果返回至 Fuse，Fuse 將根據修復後的 I/O 路徑進行 I/O 重試。

圖10 故障修復後I/O路徑

（6）GPU Direct RDMA（GDR）使能

KVCache 數據會在計算完成後緩存在 HBM 中，將 KVCache 數據寫入 3FS 需要先將 HBM 中的數據拷貝到內存中，然後再調用 USRBIO 或者 POSIX 接口將數據寫入 3FS 中。HBM 到內存的拷貝往往會成為鏈路上的瓶頸，需要將內存 pin 住和使用專用 kernel 來解決，這無疑產生了 GPU 和 CPU 的額外開銷。
因此，我們在3FS USRBIO接口中使能了 3FS 的 GDR 能力，消除了多餘的內存拷貝，降低了 GPU 和CPU 的開銷。如上所述，使用 3FS USRBIO 的用户進程會和 3FS Fuse Daemon 共享兩個內存文件，iov和ior。其中，iov 用於保存數據塊，ior 用於保存命令塊。我們將 iov 中保存的數據塊由真實的數據修改為HBM 的 IPC 地址，從而使得 3FS Fuse Daemon 也可以讀寫同一塊 HBM 物理地址。
另外，由於 IBVerbs 接口的限制，我們還需要將用户進程側的 PD 和 MR 等 IB Context 也共享給 3FS Fuse Daemon，整體實現了 3FS GDR 能力的支持。

圖11 3FS GDR數據交互設計

（7）多租隔離

提供租户權限管理能力，支持訪問控制隔離，租户僅可訪問/顯示/修改本租户文件，Meta 和 I/O 訪問路徑增加租户訪問鑑權，禁止非法訪問。

圖12 3FS 多租隔離

2.3 雲原生化集羣管理

3FS 開源後受到業界廣泛關注，其優越的性能和高可用性吸引了大量 AI 初創企業的眼光。但是 3FS 由多個關鍵組件構成，組件之間依賴關係複雜，傳統部署方式需要手動配置各組件狀態、協調組件通信，故障場景高度依賴人工干預進行恢復，導致部署流程複雜、維護成本高、系統穩定性難以保障。如何幫助這些企業更高效地部署、管理和維護 3FS，是我們在開發過程中的核心考量。
為了解決這些問題，我們開源了kvc-3fs-operator (https://github.com/aliyun/kvc-3fs-operator) 項目，支持客户物理機自建 K8s集羣/阿里雲ACK/ASI 等多種環境的靈活部署。3FS Operator 基於 Kubernetes 容器編排系統，提供聲明式API和自動化運維能力，實現了 3FS 的一鍵部署、故障自愈等能力，顯著提升了部署效率和系統穩定性。

（1）支持集羣一鍵快速拉起能力，包括 Clickhouse/Monitor/FDB/Meta/Mgmtd/Storage 組件

Kubernetes Operator 是基於 Kubernetes 的一種擴展模式，通過結合自定義資源定義（CRD）與自定義控制器（Controller），實現了對複雜應用系統的自動化部署與生命週期管理。
在 3FS Operator 中，定義了一個名為 ThreeFsCluster 的 CRD 資源，用於描述 3FS 集羣的配置和期望狀態。Operator 通過監聽該 CRD 的變更事件，驅動控制循環（Reconcile Loop），持續對比當前集羣狀態與目標狀態之間的差異，並自動執行相應的操作（如創建Workload、調整配置、處理故障等），以確保系統始終運行在用户所期望的狀態下。

圖13 3FS Operator原理

（2）基於 Webhook 機制，實現 Fuse Sidecar 動態注入業務 Pod，對用户完全透明

Kubernetes Webhook 是一種通過 HTTP 接口與 Kubernetes ApiServer 交互的機制，允許用户在集羣中實現自定義的准入控制（Admission Control）或其他自動化操作。
如下圖所示，在 3FS Operator 中註冊了一個 Mutating Admission Webhook（變更型） 服務。當用户創建帶有指定標籤的 Pod 時，該 Webhook 會被觸發作為 Hook 調用，自動向 Pod 注入一個 3FS Fuse 容器作為 Sidecar。
同時，基於容器掛載卷的雙向傳播機制，Sidecar 容器中的 3FS 掛載路徑會被傳播到業務容器中。整個注入和掛載過程對用户完全透明。Pod 啓動後，用户即可在其配置的目錄中直接使用 3FS 存儲，無需額外配置或修改應用代碼。

圖14 3FS Fuse動態注入原理

（3）FDB/Mgmtd/Meta/Storage故障自愈能力

3FS Operator 會持續監控各組件的狀態信息。當檢測到某個組件發生故障時，會記錄其首次故障時間，並在故障持續時間達到用户預設的閾值後，判定該組件失效。此時，Operator 將啓動一個新的副本替換故障副本，實現系統的自動恢復和高可用保障。

（4）集羣存儲彈性擴容能力

3FS Operator 支持存儲彈性擴容能力，允許用户根據業務負載變化，按需定義擴容步長並動態擴展存儲容量。結合我們對 3FS 文件創建時數據分佈規則的優化改造，可以實現將數據均衡分佈至新加入的節點上。

（5）集羣滾動升級

通過更新各組件的鏡像信息，可以實現對 3FS 集羣的滾動升級。Operator 按照組件維度，以單個進程為粒度逐步替換舊版本鏡像，確保在升級過程中始終保留足夠的可用副本。這種方式有效降低了升級過程對集羣整體可用性的影響，提升了系統的穩定性和運維效率。

（6）多實例支持

支持在同一 Kubernetes 集羣中部署多套 3FS 集羣，結合阿里雲網絡隔離能力（如 VPC 子網劃分、安全組策略等）實現集羣間隔離，提升資源利用率並降低基礎設施成本，確保不同業務場景下的數據安全性與服務隔離性。系統預置二級備用節點池，可動態支持故障替換及擴容需求，保障服務的高可用性。此外，用户可通過 ECS、ACK、ASI 等環境自動化部署 3FS 客户端，實現跨集羣數據訪問與資源調度。

圖15 3FS 多實例部署形態

（7）監控大盤接入

3FS 採用 ClickHouse 作為時序數據庫，存儲採集的監控指標。通過 Grafana 的 ClickHouse 插件，我們構建了統一的可視化監控大盤，實現對管控組件與數據鏈路組件的關鍵性能指標的集中展示，基於I/O分段時延高效定位系統的性能瓶頸。

圖16 3FS監控大盤

3. 構建高效 KVCache 存儲通路：3FS 集成實踐

3.1 推理引擎集成 3FS

（1）3FS USRBIO性能優化

在 SGLang 與 3FS USRBIO 的對接驗證階段，初期測試中因客户端併發度不足（單線程請求）且 I/O 提交粒度較小，導致讀寫帶寬僅有 ~200MB/s，遠低於 EGS 環境 160Gb/s 的帶寬上限。為突破這一瓶頸，我們採取了以下優化策略：

1. 多線程並行化改造：提高客户端併發數，每個線程獨立維護私有 IOR/IOV結構，避免線程間競爭；
2. I/O 聚合優化：增大 Page Size 聚合 I/O，同時增大 I/O 隊列深度，通過批量提交機制提升 RDMA 網絡帶寬利用率；

經過上述優化，SGlang 的讀寫帶寬成功達到網絡理論上限 ~ 20GB/s，較原始方案顯著提升，充分驗證了 3FS USRBIO 接入方案的技術可行性和有效性。

（2）3FS 接入 SGlang/vLLM 方案

當前，我們在 SGLang 社區 & vLLM 完成了 3FS KVStore 的集成，具體設計如下：

• 3FS Hicache Backend && V1 Connector：基於 3FS 的存儲後端連接器，依託 libusrbio 高性能 I/O 庫，實現對 3FS 存儲系統的高吞吐、低延遲訪問
• Global Metadata Manager：提供分佈式文件系統（FS）的元數據統一管理服務，具備高效的元數據組織、查詢與協調能力，為全局 KVCache 提供一致性管理
• 3FS Global Storage：3FS 高性能分佈式存儲引擎

圖17 推理引擎接入3FS示意圖

（3）3FS 接入推理框架性能表現

我們測試了 SGLang 在一個長上下文 QA 場景數據集的性能表現：

• 數據集：Loogle Dataset，包含近 100 組 system prompts， 21KB 前綴、20 queries/per group
• 測試模型：DeepSeek R1，H20-3e * 8卡
• 測試場景：l1、l1 + l2 host、l1 + l2 + l3 3fs、3fs 冷啓動加速

• 性能提升：

  • L3 Vs L1: TTFT 相比 L1 下降 78%，推理吞吐提升 520%
  • L3 助力冷啓動：TTFT 相比冷啓動重算下降 84%，推理吞吐相比冷啓動重算提升 830%
• 詳情可參考：https://lmsys.org/blog/2025-09-10-sglang-hicache/

圖18 SGlang接入3FS性能數據

3.2 Tair KVCache Manager 集成 3FS

Tair KVCache Manager（以下簡稱 KVCM）是阿里研發的全局外部 KVCache 管理組件，旨在為推理服務提供高效、可靠的 KVCache 管理服務。
KVCM 基於 HTTP/gRPC 協議對外提供服務接口，支持接入包括 3FS 在內的多種存儲系統（如 KV 存儲、文件系統、內存池、塊存儲等），並通過統一的接口層對異構存儲系統進行抽象和封裝，顯著降低了不同存儲介質接入的複雜度與開發成本。
KVCM 在系統架構中扮演關鍵角色，其與推理服務、3FS 等組件的交互關係如下圖所示，KVCM 實現了 KVCache 與 3FS 文件數據物理位置的動態映射，推理服務通過 KVCM 的統一接口訪問 KVCache 數據的存放位置並通過掛載的 3FS Fuse 服務訪問數據，減少其直接管理底層存儲系統的複雜性。

圖19 KVCM接入3FS示意圖
在 KVCM 與 3FS Backend 的對接中，KVCM 對 3FS 文件的操作依賴於 3FS Fuse 的掛載，且強依賴 RDMA 環境。然而，在跨集羣部署場景下，這種強耦合關係顯著限制了 KVCM 部署的靈活性和擴展性。與此同時，傳統基於海量小文件的分配方式雖易於實現，但頻繁的元數據操作導致後端元數據服務訪問壓力加大，進而引發系統吞吐能力下降與性能瓶頸。為此，我們針對上述挑戰提出了以下優化方案：

（1）KVCM 與 3FS Fuse 解耦設計

為提升 KVCM 在非 RDMA 環境中部署的靈活性，我們在 3FS Operator 中引入了輕量級的 3FS Master 組件。該組件是無狀態服務，採用多實例部署模式，通過 HTTP 接口對外提供 POSIX 兼容的 create/delete 等基礎語義，有效解耦了 KVCM 與 3FS Fuse 的依賴關係。

（2）3FS 元數據優化策略

為降低 3FS 元數據操作的開銷，我們採用大文件 + 支持多種 Block Size 的 Slab 細粒度分配器策略：客户端僅需打開少量大文件並緩存文件信息，避免頻繁訪問後端存儲的元數據服務；通過 Slab 分配器實現細粒度內存管理，減少文件創建/刪除操作的頻率，降低對後端存儲元數據服務的壓力，提升系統整體吞吐能力。

圖20 KVCM 3FS Allocator設計
關於 KVCM 的更多設計細節、使用場景及配置指南，將在後續技術文章中詳細展開。

4. Future Work

4.1 3FS產品化能力持續建設

展望未來，3FS 將始終以 KVCache 為核心的高性能存儲需求為導向，在多個技術維度持續深化創新。系統將從智能化運維管理、企業級多租户安全、KV語義原生支持、極致高可用保障以及軟硬協同優化等關鍵領域入手，構建專為 KVCache 場景量身定製的技術體系。
（1）持續增強 3FS Operator 的 CRD 配置能力與部署靈活性：通過增強 3FS Operator 的自定義資源定義的配置能力，系統將具備更為精細化的資源配置和管理功能，能夠根據不同的業務負載特徵和性能要求進行智能化調整。同時，擴展 3FS Operator 的能力邊界，使其能夠在更豐富的業務場景中更靈活地支持客户自定義部署需求。
（2）QoS：構建完善的多租户支持體系，結合現有的用户鑑權機制，引入 QoS 保障機制，能夠根據租户的業務優先級和資源配額進行動態資源調度和性能保障，避免租户間的資源爭用和性能干擾，為雲原生環境下的共享存儲需求提供企業級的安全性和穩定性保障。
（3）客户端形態升級與 KV 語義原生支持：對現有客户端架構進行全面升級，原生支持鍵值（KV）語義操作。通過提供簡潔高效的 KV API 接口，降低應用開發的複雜性，為構建高性能的 KVCache 系統提供更加便捷的技術基礎。
（4）產品力持續強化與故障自愈能力提升：持續加強 3FS 的產品力，通過引入動態副本遷移重構等機制，進一步降低故障場景下對上層業務可用性的影響，最大程度地保障業務連續性，為關鍵業務場景提供企業級的高可用性保障。
（5）落盤引擎優化與硬件協同深度融合：持續優化 3FS 落盤引擎的性能表現，深度結合阿里雲服務器自研的 AliFlash SSD 和 AliSCM 等新型存儲硬件的特性和優勢。通過軟硬協同的深度優化，充分發揮新型硬件的性能潛力，提供軟硬件結合的解決方案，為用户提供極致的存儲性能體驗。

4.2 服務器硬件能力持續升級

隨着AI應用場景的多樣化與複雜化需求持續增長，阿里雲服務器團隊自研的 AI SSD 及磐久存儲服務器平台將持續迭代優化，以精準適配AI業務的動態需求。我們致力於為AI推理場景打造以 KVCache 為核心的一體化端到端基礎設施，通過軟硬協同的深度優化，構建高效、智能的AI技術底座。
（1）存儲硬件優化：匹配 GPU 算力，計算網絡帶寬，存儲提供高低延遲，高 IOPS，高帶寬能力的 AI SSD
（2）計算存儲優化：GPU 直通存儲存儲降低延遲，消除內存牆影響，存儲KV接入模式優化
（3）存儲系統優化：以 KVCache 管理系統為中心數據 placement 策略，提供專屬存儲引擎，降低文件系統開銷
（4）增值能力優化：數據壓縮，分層淘汰，數據感知及任務調度，任務隊列預取，熱數據pin/unpin等能力加強

圖21 面向KVCache的端到端方案