博客 / 詳情

返回

阿里雲 Tair KVCache 仿真分析：高精度的計算和緩存模擬設計與實現

導讀

在大模型推理邁向“智能體時代”的今天，KVCache 已從性能優化手段升級為系統級基礎設施，“顯存內緩存”模式在長上下文、多輪交互等場景下難以為繼，而“以存代算”的多級 KVCache 架構雖突破了容量瓶頸，卻引入了一個由模型結構、硬件平台、推理引擎與緩存策略等因素交織而成的高維配置空間。如何在滿足 SLO（如延遲、吞吐等服務等級目標）的前提下，找到“時延–吞吐–成本”的最優平衡點，成為規模化部署的核心挑戰。
為破解這一難題，阿里雲 Tair KVCache 團隊聯合服務器異構計算軟硬件結合團隊，推出Tair-KVCache-HiSim，這是首個面向分佈式多級 KVCache 管理的高保真 LLM 推理仿真分析工具。它通過全鏈路建模請求生命週期、多級 KVCache 行為與異構批處理執行，在通用 CPU 上以 39 萬倍成本優勢實現 <5% 誤差的端到端性能預測。更重要的是， Tair-KVCache-HiSim 能基於真實負載，在用户指定 SLO 約束下自動探索帕累託前沿，支撐三大關鍵決策：

  • 計算選型與優化配置：評估不同 GPU 型號、並行策略、量化方案及算子實現對 TTFT 與 TPOT 的影響，推薦最具性價比的組合；
  • 存儲層級與介質規劃：量化分析多級緩存架構的收益邊界，支持細粒度選擇每層存儲介質類型，並協同優化帶寬配置、容量分配、預取策略與驅逐算法，最大化緩存命中率與 I/O 效率；
  • 全局與本地調度策略協同：聯合分析全局路由策略與本地調度機制對排隊延遲、批構成與 GPU 利用率的影響，實現從集羣負載均衡到單機流水線效率的端到端調優。

本系列技術文章將系統性拆解面向智能體推理的 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. 引言

在當前大語言模型（LLM）推理服務快速落地與規模化部署的背景下，推理系統的性能表現直接決定了用户體驗、服務成本與資源效率。關鍵性能指標如首 Token 延遲（TTFT）、每輸出 Token 延遲（TPOT）以及系統級吞吐量，已成為評估推理引擎優劣的核心標準。在真實部署環境下，這些指標高度依賴於模型結構（如參數量、稀疏性）、硬件平台（如A100、H100等GPU的算力與顯存帶寬特性）、推理引擎實現（如vLLM、SGLang、TensorRT-LLM等的調度與KV緩存管理策略）及運行時配置（如量化方式、批處理策略、並行模式）等多種因素的複雜耦合。
為支撐高效、低成本的推理系統設計與優化，我們需要一種高保真、可擴展、易復現的性能評估手段。傳統依賴真實 GPU 集羣進行端到端壓測的方式，不僅硬件成本高昂、實驗週期長，且難以對海量配置組合進行系統性探索。在此背景下，對於 CPU 的推理性能模擬系統的需求應運而生：我們期望能通過回放採集自生產環境或代表性場景的真實推理Workload Trace，在通用 CPU 平台上，對不同模型、不同 GPU 目標、不同推理引擎及其配置下的 TTFT、TPOT、吞吐等關鍵性能指標進行快速、低成本、高精度的預測與對比。
進一步擴展到遠端 KVCache 的配置組合，包括所選存儲介質的吞吐與傳輸延遲（如 DDR4、HBM、NVMe SSD、CXL 內存池或遠程 GPU 顯存）、總容量上限、緩存淘汰策略（如 LRU、LFU、Clock 或基於請求優先級的自定義策略）、以及 TTL（Time-to-Live）過期與回收機制（如惰性清理、定時後台回收或基於內存壓力觸發的主動驅逐）共同構成了影響推理性能的關鍵因素。特別是在 Agent 應用需要推理卸載到遠端存儲場景下，當 KVCache 無法完全駐留於本地 GPU 顯存而被迫部分或全部遷移至遠端存儲時，其訪問延遲的 TPOT 與 TTFT會產生變化；而若淘汰策略與請求模式不匹配（如長上下文對話中頻繁驅逐高頻複用的早期層 KV 狀態），則會導致緩存命中率驟降，引發重複計算或額外 I/O 開銷；此外，不當的 TTL 設置可能造成過早失效（降低複用效率）或內存耗盡（擠佔後續請求資源）。因此，遠端 KVCache 的系統設計本質上是在容量–延遲–吞吐–成本四維約束下的精細權衡，我們需要通過推理性能模擬疊加緩存命中率和傳輸的模擬手段，量化評估不同 KVCache 配置組合對端到端推理 SLO（如 P99 延遲 ≤ 200ms、吞吐 ≥ 50 req/s）的敏感性，從而為異構推理架構下的緩存層級優化提供決策依據。

2. 當前推理模擬實現的方式和優缺點

2.1推理引擎的整體架構

為構建有效的性能模擬器，必須首先準確建模真實推理引擎的執行邏輯。典型LLM推理服務系統（如vLLM、SGLang、TensorRT-LLM）普遍採用異步請求調度 + 連續/動態批處理的架構，動態聚合 Prefill 與 Decode 請求提升硬件利用率，其核心組件與流程如下：

2.1.1 請求處理流水線與生命週期

在 SGLang 等高性能 LLM 推理引擎中，單個請求從接收到完成並非串行執行，而是被嵌入一條深度流水化、異步協同的處理流水線中。該流水線通過 CPU-GPU 協同、多級緩存預取與動態批處理等機制，在保障低延遲的同時最大化吞吐效率。

LLM推理請求處理流水線與生命週期
以一個典型場景為例：用户提交一段 1K Token 的 prompt，期望生成 512 Token 的輸出，且其前 512 Token 與歷史對話前綴匹配（即 KV Cache 命中率為 50%）。該請求的完整生命週期如下：
1.請求接入與前端處理
請求首先經由負載均衡器路由至某一推理實例。服務端在 CPU 上完成文本分詞（Tokenization），並將token ID 序列送入調度系統。
2.前綴緩存匹配與狀態識別
引擎利用 Radix Tree 在 CPU 端快速檢索該 prompt 的歷史上下文。若發現前 512 Token 已存在於 KVCache 中，則標記該部分為“可複用”，僅需加載對應的 key/value 張量，避免重複計算。
3.異步緩存預取與零開銷調度

  • 第一階段預取（L3 → L2）：請求進入等待隊列後，系統立即啓動異步 I/O，將命中的 KV Cache 從 SSD（L3）遷移至 Host DRAM（L2）。此過程在 CPU 後台進行，不影響 GPU 推理。
  • 第二階段加載（L2 → L1）：當調度器決定將該請求納入下一批次時，會檢查其 L2 緩存是否就緒。若就緒，則啓動從 Host DRAM 到 GPU HBM（L1）的緩存加載。
  • 零開銷調度（Zero-Overhead Scheduling）：CPU 的調度決策邏輯與 GPU 上一個 batch 的執行重疊，從而避免因調度引入額外的流水線停頓，最大化 GPU 利用率與系統吞吐。
    4.動態批處理調度
    調度器綜合考慮顯存餘量、請求優先級及緩存就緒狀態，將多個就緒請求（可能包含 Prefill 新請求與Decode 進行中請求）組合成一個異構 batch 準備執行推理。
    5.分階段模型前向計算
    Prefill（預填充）階段：處理緩存未命中的剩餘 512 Token，輸入較長，計算密集，性能主要受模型並行度、量化和 GPU 算力影響；
    Decode（解碼）階段：逐Token生成，每次僅計算一個新 token，但需讀取全部歷史 KV Cache，受限於顯存帶寬
    6.後處理與流式返回 (Post-processing & Detokenization)
    輸出的 logits 經採樣得到 token ID，再由 detokenizer 轉換為文本。為優化用户體驗，結果以流式（streaming）方式實時返回。

2.1.2 請求調度策略介紹

由於 LLM 服務後端不斷接受新的推理請求，因此如何在每一次推理之前，決定請求的調度順序是框架核心考量要素之一。在 Prefill / Decode 請求調度策略上，可以分為以下四種：

  • Prefill 優先：以 SGLang 為代表，新請求到達時，暫停先前請求的 decode 過程，優先執行新請求的prefill 過程，執行完新請求後，與原有的 Decode 請求組成更大的 Batch 繼續後續的推理。如此可以最大化系統吞吐，但同時也會導致 TPOT 出現較大的波動。
  • Decode 優先：以 TensorRT-LLM 為代表，也稱為 inflight batching，指不暫停正在推理中的 decode 請求，如果將所有運行中請求調度進下一批次後仍有調度空間，則加入新請求，否則直至有資源空閒才會調度新請求做prefill。可以減緩 TPOT 抖動問題，主要用於短輸入場景。
  • ChunkPrefill：將一個長 prompt 的 prefill 過程拆分為若干個小塊，與其他 decode 請求同時進行批次推理， 緩解長 prompt 下 prefill 階段請求對 decode 階段請求的資源阻塞問題，保證 TTFT 的同時，提升整體吞吐（throughput）和 TPOT。主要用於長文檔摘要、多輪對話以及需要處理長序列且希望提高併發性的場景。
  • PD 分離：將 prefill 與 decode 階段解耦部署、獨立調度，避免 prefill 和 decode 階段對資源的需求不同導致的相互影響， 進一步在 TTFT 與 TPOT 之間尋求平衡。
    圖片

上述介紹的是 Prefill/Decode 階段的調度優先級策略，實際上系統對新到達請求（Prefill 階段）內部還可以疊加其他調度機制，如廣泛使用的先來先服務（First-Come-First-Served, FCFS）策略；除此之外還有長輸出優先，Cache 感知的最長公共前綴優先等。

2.1.3 SGLang請求調度邏輯

如圖為 SGLang Prefill 優先的調度邏輯，LLM 推理的一個完整事件循環主要分為五部分：從 HTTP Server 獲取新請求，處理輸入請求（請求入隊等待調度、Hicache預取排隊），請求調度，LLM Step 推理，後處理。在這裏我們主要關注其中的調度邏輯：

  • 調度資源限制：請求能否從排隊隊列中進入調度執行，主要受到四個資源的限制，分別為最大 Chunk Size，Prefill 最大 Token 數，最大運行請求數，KV Cache Pool 容量，以上參數都可以通過啓動參數直接或間接進行配置。
  • 執行調度時，優先調度上一輪被 Chunk 切分的請求，剩下的請求則根據優先級（如 FCFS）進行排序選擇；通過會根據當前 Batch 可剩餘 Token 容量，決定是否對進行進行切塊（Chunk）。
  • 當開啓 HiCache 多級 KV Cache 存儲時，請求是否進行調度，根據設定的預取策略（best_effort, wait_complete, timeout）進行判定。當預取未達到終止條件時，將不執行調度，繼續 KV Cache 的預取。
    圖片
    SGLang 新請求默認調度邏輯

2.1.4 推理計算模型與框架實現差異

圖片
Qwen3 模型結構圖
當前主流大語言模型（如 Qwen 系列）普遍採用 Decoder-Only 的 Transformer 架構，其推理過程由一系列結構化模塊依次處理輸入 token 序列。以 Qwen3 為例（結構示意如圖 X 所示），典型前向流程包含以下關鍵組件：

  • Embedding 層：將離散的 token ID 映射為連續高維向量，作為網絡輸入；
  • 位置編碼層：採用 Rotary Position Embedding（RoPE），通過旋轉矩陣將位置信息融入注意力計算，支持序列長度外推；

  • 堆疊的 Decoder Block（共 N 層）：每層包含：

    • RMSNorm：高效歸一化操作，替代傳統 LayerNorm；
    • Attention ：建模全局上下文依賴，具體實現形式多樣，包括 MHA、MQA、GQA、MLA、Linear Attention、Sparse Attention 等；
    • 前饋網絡（FFN）：通常為 MLP 或 MoE 結構，用於擬合非線性變換；
  • 輸出層 RMSNorm：對最終表示進行歸一化，供後續採樣使用。
    圖片
    不同硬件不同的算子後端實現
    儘管不同 LLM 在功能上高度相似，但其實際推理性能卻顯著受制於底層實現細節。以 SGLang 等主流推理框架為例，相同的模型結構在不同硬件，不同配置下，會觸發完全不同的 GPU Kernel 實現。更關鍵的是，即使同一算子，其啓動參數（如 block size、tile 配置）也會隨輸入長度（prompt 長度、cache 長度）動態調整。這些優化通常在編譯期或運行時由算子調度器自動選擇，以最大化硬件利用率。因此在 GPU 執行推理階段，需要考慮不同算子實現對於執行時間的影響。

2.2 LLM 推理仿真的核心挑戰

LLM 推理具有顯著的動態異構性、強狀態依賴性以及對毫秒級服務等級目標（SLO, Service Level Objective）的高度敏感性。這些特性使得傳統靜態性能建模方法難以有效復現真實系統行為。具體而言，當前 LLM 推理仿真面臨以下四類關鍵挑戰：
1.推理請求全生命週期流程高度複雜且狀態密集
LLM 推理請求在其生命週期中經歷多階段、多隊列、多緩存層級的動態流轉。如前文所述，一個典型請求需依次經過 Tokenization → 調度入隊（Waiting Queue）→ Prefill 執行 → 多輪 Decode 批處理（RunBatch）→ Detokenization 等環節。在此過程中，請求在調度器管理下於 Waiting、Running、Swapped 等隊列間遷移，並伴隨多級 KV Cache 的加載與驅逐行為（例如：在 Waiting 隊列中觸發 L3→L2 的預取；在被調度執行 Prefill 前完成 L2→L1 的 Cache 傳輸）。這種端到端的狀態變遷路徑與緩存-計算-調度的深度耦合，使得任何忽略中間狀態轉移或緩存交互的簡化建模都將導致顯著偏差。
2.系統組件強耦合導致仿真誤差級聯放大
LLM 推理系統的各核心組件：調度器（Scheduler）、KV Cache 管理器與 GPU 執行引擎，存在緊密的反饋環路。例如：
調度決策影響 KVCache 與計算：
調度策略決定請求何時進入執行隊列，直接影響其在 Waiting Queue 的駐留時間，從而決定 L3→L2 緩存預取的數據量；同時，調度所形成的 batch 構成（如 Prefill/Decode 混合比例、上下文長度分佈）直接決定 GPU kernel 的並行效率與內存訪問模式，進而影響實際執行時延。
KVCache 狀態反作用於調度與計算：
KVCache 的命中率決定了 Prefill 階段需重算的 token 數量，直接影響計算量與時延；而需重算長度又約束了 batch 的 token 預算分配，進而影響調度器對新請求的接納與切分決策。
Batch 執行時延預估影響調度與緩存行為：
Batch 時延會影響下一批次調度時新增到達請求的數量，影響調度器判斷是否插入/插入多少新 Prefill 請求；同時也決定了 KVCache 加載窗口的大小與 TTL 設置。
這種多向依賴關係導致任一組件的建模偏差會通過系統鏈路級聯傳播並放大，使得端到端延遲預測嚴重失真。
3.單步時延受狀態、配置與硬件的非線性耦合影響，缺乏可泛化的細粒度建模方法
LLM 推理中 batch 時延並非由 batch size、input length 等粗粒度參數單獨決定，而是受到多維度因素的非線性耦合影響：

  • 模型層面：層數、注意力頭數、是否啓用 FlashAttention 或 PagedAttention 等算子優化；
  • 系統配置：張量/流水/數據/專家並行度（TP/PP/DP/EP）、量化方案（如 INT4、FP8）；
  • 硬件平台：GPU 型號、顯存帶寬、節點間互聯拓撲；
  • 動態請求狀態：每個請求的 prompt 長度、已生成 token 數、KV Cache 佔用block數；
  • 批處理異構性：由於連續批處理（continuous batching）機制，同一 batch 中各請求的上下文長度與 cache 狀態高度異構，GPU kernel 的計算強度與內存訪問模式劇烈波動。
    與此同時，面對快速演進的模型架構與硬件生態，對每種“模型–配置–硬件”組合進行全量實測既不經濟也不可擴展。因此，如何在避免窮舉測量的前提下，構建一個既能精確刻畫單步執行行為、又具備跨模型與跨平台泛化能力的時延預測機制，成為高保真 LLM 推理仿真的核心挑戰。
    4.高維配置空間下最優解搜索效率瓶頸
    即使構建出高保真仿真器，其在實際部署調優中的價值仍受限於配置搜索效率。典型部署配置空間涵蓋並行度、批大小、緩存策略、量化位寬等多個維度，組合爆炸問題顯著。若單次仿真耗時 1 分鐘，窮舉搜索可能需數天，遠超用户可接受的調優週期。因此，如何高效探索，在滿足 SLO 約束的前提下，成本-延遲-吞吐的帕累託前沿，成為仿真器實用化的關鍵瓶頸。

2.3 以KVCache為中心的LLM推理仿真器的關鍵需求

為應對上述挑戰，一個面向生產級 LLM 推理系統的仿真器必須超越傳統性能模型的侷限，構建一套分層解耦、高保真、可驗證且高效優化的仿真框架。基於前述分析，我們提出以下四項核心需求：
支持端到端推理流程的分層抽象
仿真器應能夠完整復現真實推理引擎中請求從接入到響應的全生命週期行為，包括請求生成、調度決策、狀態遷移、批處理執行與結果返回等階段。具體需滿足：

  • 能夠模擬具有真實分佈特徵的用户請求負載；
  • 支持多節點部署場景下的請求路由與跨節點協作行為建模；
  • 對推理實例內部各處理階段（如 tokenization、調度、KV Cache 管理、批推理執行、detokenization）進行模塊化抽象，並保持其執行順序與依賴關係與真實系統一致。
    該能力確保仿真結果在宏觀行為與微觀時序上均與實際系統對齊。
    實現組件級高保真、可獨立驗證的延遲建模
    為抑制系統組件間耦合導致的誤差級聯，仿真器必須對核心功能模塊進行解耦建模，並保證各模塊行為的準確性與可驗證性：
  • 調度行為建模：準確還原調度策略對請求狀態的影響，以及其對 batch 構成和執行時機的決策邏輯
  • KV Cache 行為建模：支持對緩存命中/缺失、數據預取、驅逐及跨存儲層級遷移等操作的時延與資源消耗建模；
  • 批推理執行建模：能夠基於 batch 內各請求的動態狀態（如上下文長度、生成進度）預測整體執行時延；
  • 全局時序一致性：維護統一的時間模型，以正確反映 CPU 調度、GPU 計算、內存傳輸等操作間的重疊與依賴關係。所有模塊應支持獨立校驗，確保局部誤差可控、端到端偏差可追溯。
    提供細粒度、泛化性強的單步時延預測能力
    針對單次推理時延高度依賴批次組成與請求prompt&cache長度的問題，仿真器需具備對執行時延進行細粒度刻畫的能力：
  • 能夠針對同一批次中的不同請求在計算與通信分別建模
  • 支持將時延預測建立在請求級狀態特徵之上，而非僅依賴粗粒度的 batch 統計量
  • 在面對未見過的模型結構、硬件平台或系統配置時，仍能提供合理且可靠的時延估計，避免對全量實測數據的依賴該能力是實現高精度、低成本仿真的基礎。
    支持 SLO 約束下的高效配置空間探索
    為支撐實際部署決策，仿真器應實現對部署配置空間的高效探索能力
    避免對高維配置空間進行窮舉評估，顯著降低調優時間開銷；能在用户指定的服務等級目標（SLO）約束下，快速識別可行配置
    支持多目標優化（如成本、延遲、吞吐之間的權衡），並輸出帕累托最優解集供用户選擇
    該能力使仿真器從被動性能評估工具轉變為面向生產部署的主動決策輔助系統。
    為系統性應對上述需求與挑戰，下文將詳細介紹 Tair-KVCache-HiSim 的整體架構設計與關鍵技術實現路徑。

3. Tair-KVCache-HiSim仿真器架構與特性

3.1 整體架構

為滿足對 LLM 推理全生命週期的高保真建模需求，我們設計並實現了 Tair-KVCache-HiSim — 一個面向大模型推理服務的輕量級、高精度仿真工具。Tair-KVCache-HiSim無需實際部署模型至 GPU，即可通過注入合成或真實請求軌跡，高效預估關鍵性能指標，包括首 Token 延遲（TTFT）、平均輸出 Token 延遲（TPOT）和系統吞吐量（Throughput）等。相較於現有仿真方案，Tair-KVCache-HiSim 首次支持 多級 KV Cache 存儲層次仿真（基於 HiradixCache 架構），為用户在緩存資源配置與成本權衡方面提供關鍵決策依據。
如圖所示，Tair-KVCache-HiSim 採用模塊化架構，由以下三個核心組件協同工作，完整復現從請求接入到結果返回的端到端推理流程：
圖片
Tair-KVCache-HiSim 架構圖

3.2 組件介紹

Tair-KVCache-HiSim 仿真工具包含以下幾個關鍵組件：
Workload Generator：面向存儲優化的用户負載生成器，模擬真實業務場景。
該模塊支持兩種靈活的負載注入模式，以適配不同數據可用性條件下的仿真需求：

  1. 隨機數據集生成（Random Dataset）：適用於缺乏原始trace的場景，支持基於開源數據集或隨機 Token 的建模。除了常規的輸入輸出長度、請求速率和併發度參數外，針對 KVCache 需求激增的場景，引入更高階的變量，場景選擇：支持多輪對話及 Agent 等複雜場景；多輪對話建模：支持對話輪次、每輪新增 Prompt 長度及多輪次的時間間隔分佈等變量，更好的還原真實業務場景。
  2. 時間戳數據集回放（Timestamp Dataset）：支持導入帶有原始時間戳的真實用户負載。通過精確重放歷史負載，為特定業務線提供定製化的性能評估與配置優化建議。

Global Router Simulator：全局請求調度仿真器
負責根據特定算法將待處理請求精確調度至最優的計算實例（Worker），支持下列調度策略

  • random：隨機策略，從所有worker中隨機選擇一個；
  • round_robin: 輪詢分配策略，按順序循環分配請求到每個 worker；
  • cache_aware: 智能緩存路由策略，維護每個 worker 的 radix tree，通過前綴匹配選擇最高緩存複用的worker；
  • power_of_two: 最短隊列策略，隨機選擇兩個 worker，對比實時負載（活躍請求數&隊列長度），選擇負載較輕的一個；
  • bucket：長度分桶策略，根據請求prompt長度做區間劃分，不同長度範圍的請求定向到特定的worker，桶邊界會隨集羣整體負載波動動態伸縮。

Inference Engine Simulator：實例推理引擎仿真器
該模塊對單個推理實例內部行為進行細粒度建模，完整復刻真實推理框架的核心行為

  • 將推理過程劃分為一系列離散的執行步驟（steps），包括 tokenization、調度入隊、Prefill/Decode 批處理、KV Cache 加載/驅逐、detokenization 等；
  • 模擬請求在 waiting queue、running queue 與 swapped queue 之間的狀態遷移；
  • 支持 CPU 調度與 GPU 執行的時序重疊建模，確保微觀時序保真；
  • 自動採集每個請求在各階段的耗時（請求從到達系統、進入等待隊列，到被調度至執行隊列，最終完成推理並返回輸出結果），並聚合生成 TTFT、TPOT、吞吐量等端到端性能指標。

通過上述三層協同仿真，Tair-KVCache-HiSim 在宏觀負載特徵與微觀執行時序兩個層面均與真實系統高度對齊，為後續性能分析與配置優化奠定堅實基礎。

3.3 Inference Engine Simulator：高保真仿真核心

Inference Engine Simulator 是 Tair-KVCache-HiSim 實現端到端推理行為仿真的核心模塊。它通過解耦建模調度、緩存管理與批執行三大子系統，並引入統一全局時鐘機制，確保各組件行為高保真且可獨立驗證。整體架構如圖所示，包含以下三個協同工作的子模塊。
圖片
Inference Engine Simulator結構圖

3.3.1 SchedulerSimulator：調度行為高保真復現

SchedulerSimulator 精確復刻主流 LLM 推理框架（如SGLang，vLLM）的調度邏輯，維護請求在其生命週期中的狀態流轉。整體流程與第二章介紹的調度流程保持一致，實現上系統顯式建模四個關鍵隊列：

  • Waiting Queue：新到達請求的初始駐留隊列；
  • Prefetch Queue：正在進行 KV Cache 預取的請求；
  • Running Queue：推理執行中的請求；
  • Swapped Queue：因顯存不足被換出至主機內存的請求。
    調度器支持第二章介紹過的多種調度策略，這裏不再贅述。此外，SchedulerSimulator 與 KVCacheManagerSimulator 緊密交互：在決策是否將請求從 Waiting Queue 調入 Running Queue 前，會查詢其 KV Cache 預取狀態，並根據預取策略（best_effort、wait_complete、timeout）決定是否阻塞調度。該機制確保仿真結果準確反映真實系統中“緩存預取量”對調度延遲的影響。

3.3.2 KVCacheManagerSimulator：多級分佈式緩存行為建模

圖片
Scheduler和KVCacheManager的交互流程圖
KVCacheManagerSimulator 首次在開源仿真器中實現對三級 KV Cache 存儲層次（L3/L2/L1）的完整建模，支持異構存儲介質（如 SSD、Host DRAM、GPU HBM）在容量、帶寬與成本上的差異化配置。
其核心流程如下：

  • 請求進入 Waiting Queue 前，通過前綴匹配查詢，確定各級緩存池中的命中情況；
  • 若 L3（如 SSD）中命中情況滿足條件，如長度超過觸發閾值，則啓動 L3 → L2（Host DRAM）的異步預取；
  • 當調度器準備執行該請求的 Prefill 階段時，根據預取策略決定是否等待預取完成；
  • 一旦進入 Running Queue，在上一批次 GPU 執行期間，利用 CPU-GPU 時間重疊窗口，將命中的 KV Cache 從 L2 遷移至 L1（GPU 顯存）；
  • 僅當 L1 緩存加載完成後，才啓動模型前向計算。
    通過在仿真器中實現多級緩存前綴樹，以及對各層緩存內存池的建模與異步策略的模擬，該模塊能夠在不進行實際內存分配、數據搬運的情況下，模擬實際執行流程輸出精確的緩存命中率、各級 I/O 傳輸量及時延，為調度與性能預測提供關鍵輸入。同時，HiCache 驅逐策略（如 LRU、LFU）和 Radix Tree 結構的模擬確保緩存管理行為與真實系統一致。

3.3.3 BatchRunnerEstimator：細粒度、泛化性強的單步時延預測

圖片
BatchRunnerEstimator的實現方式為滿足對 LLM 推理時延進行高精度、低成本仿真的核心需求，BatchRunnerEstimator 被設計為一個支持細粒度、多範式、可插拔的單步時延預測引擎。其核心目標是：在動態批處理場景下，準確刻畫由批次內請求異構性（如不同 prompt 長度、cache 複用程度）帶來的非線性性能波動的時延，並在面對新模型、新硬件或新配置時仍具備可靠泛化能力。

BatchRunnerEstimator 摒棄傳統仿真器依賴粗粒度 batch 統計量（如平均輸入長度）的做法，轉而採用請求級狀態描述符作為時延預測的基本單元。每個批次由請求列表構成，每個請求以 (cache_len, input_len) 二元組刻畫其狀態，前者表示可複用的歷史 KV Cache 長度，後者表示本次需計算的新 token 數。
在此基礎上，我們構建了一個可插拔的混合時延建模框架，支持多種預測策略以平衡精度與泛化能力：

  • 基於採樣的插值/迴歸模型：通過離線 Profiling 構建模型級的時延映射函數，適用於已知硬件-模型組合；

  • 基於算子時延的組合：為了提升預測泛化性，例如針對不可直接測量的場景（如新硬件、新模型結構），可以對算子時延求和進行預估：

    • 首先將算子分為幾類：計算類和通信類；計算類算子主要被劃分為 gemm，moe-cache 無關，attention-cache 相關，elementwise，embedding等；
    • Roofline 模型：用於估算算子在特定硬件平台上的理論性能上限。其核心思想是：GPU 的性能受限於兩個關鍵硬件指標：峯值計算能力（Peak FLOPS，單位：FLOP/s）和內存帶寬（Memory Bandwidth，單位：Byte/s）。對於任意計算算子，可依據其執行所需的浮點運算量（FLOPs）和內存訪問量（Bytes），結合目標 GPU 的上述硬件參數，推導出其理論最短執行時延：T {\small roofline} ​ =max( \frac{FLOPs}{Peak FLOPS} , \frac{Bytes}{Memory BW} )，算子的實際性能要麼受計算吞吐限制（計算密集型），要麼受內存帶寬限制（訪存密集型），取兩者中耗時更長者作為下限；對於通信算子，其時延主要由數據傳輸量與鏈路帶寬決定，理論時延簡化為：T {\small roofline} ​ =\frac{Bytes}{BW} ​
    • ；基於採樣的插值/迴歸模型：通過離線 Profiling 構建算子級的時延映射函數；理論引導縮放回歸：在 Roofline 基礎上，通過少量實測數據學習 scale 因子，得到更貼近實際的估計式T{\small est} =T{\small roofline} ×Scale ；
    • 集成多種 batch 時延預測工具，比如 aiconfigurator 等。

用户可根據場景需求（如追求極致精度 vs. 快速泛化至新模型）動態切換預測後端。該設計使 Tair-KVCache-HiSim 在無需全量 Profiling 的前提下，仍能對未見模型、量化格式或並行配置提供可靠時延估計。

3.3.4 全局時鐘與事件驅動時序模型

為準確刻畫 CPU 調度、GPU 計算、KV Cache 傳輸等異步操作之間的重疊性與依賴關係，Tair-KVCache-HiSim  引入一個統一的虛擬全局時鐘作為所有模塊的時間基準，並採用離散事件模擬驅動整個仿真流程。

3.4 獨立驗證的延遲建模

為確保仿真誤差不級聯放大，Tair-KVCache-HiSim 為每個核心模塊設計了隔離式驗證接口，使其可在脱離其他組件的情況下，與真實系統行為進行端到端對比。具體策略如下：

  • BatchRunnerEstimator（批推理執行）的準確性預測可以通過Micro-benchmark 對比：首先，在真實 GPU 上運行固定 batch（指定 (cache_len, input_len) 列表），記錄 Prefill/Decode 實際耗時；其次在仿真器中注入相同 batch 配置，調用 BatchRunnerEstimator 單獨預測時延；最後比較仿真值 vs. 實測值，計算 MAPE（平均絕對百分比誤差）。
  • SchedulerSimulator（調度行為）的準確性可以通過“調度軌跡回放”驗證：從真實推理引擎導出完整調度日誌，包含每個請求的到達時間、離開 waiting queue 時間、進入 running queue 時間、被跳過原因等；以及每次調度決策時的批次快照（各隊列中的請求 ID 及狀態），隨後在仿真器中凍結 KV Cache 和 BatchRunner 行為（例如強制所有請求 cache miss = 0，batch 時延 = 固定值），僅啓用 SchedulerSimulator，注入相同請求序列，重放調度過程；最後驗證指標：調度順序是否一致，請求在各隊列的駐留時間偏差，被跳過/延遲調度的請求集合是否匹配。

  • KVCacheManagerSimulator（緩存管理）的準確性可以通過“緩存事件追蹤”驗證：通過注入我們生成的多輪對話workload，在真實系統中運行，通過 profiling 工具捕獲：初始請求到達時的各級緩存（L1/L2/L3）的命中/缺失次數；waiting queue中L3→L2的數據傳輸量與時延；準備執行prefill之前的L2→L1 的數據傳輸量與時延；以及最終在batch推理時的L1緩存命中率；同樣在仿真器中，凍結調度器（固定調度順序）和 BatchRunner（固定時延），僅運行 KVCacheManagerSimulator，查看輸入相同請求序列，比對其輸出的緩存事件流；初始驗證各級緩存命中率誤差；預取數據量偏差；驅逐策略觸發條件是否一致

    詳細的實驗數據會在第四章展示

3.5 高效配置空間探索

為支持 SLO 約束下的高效部署決策，Tair-KVCache-HiSim 設計了一套分層、漸進式的配置空間探索機制。首先，針對用户指定的 TTFT 與 TPOT 要求，系統利用高保真的 BatchRunnerEstimator 對模型執行層的關鍵配置（如張量並行度、量化方案、算子優化）進行快速篩選，通過自適應二分查找，在單步時延預測模型上高效定位滿足 SLO 的配置邊界，初步構建低維帕累託候選集；其次，針對該候選集，協同評估多種全局路由策略（如 cache_aware、power_of_two、bucket）對請求排隊延遲、負載均衡及緩存複用率的影響；最後，在可行配置基礎上，進一步優化 KV Cache 的多級存儲結構，包括存儲層級（HBM/DRAM/DISK）、容量分配、預取策略與驅逐算法。該三階段流程將高維組合爆炸問題分解為可管理的子任務，在數百次仿真內即可輸出 (延遲，吞吐，成本) 三維帕累託前沿，真正實現從被動性能評估到主動部署推薦的能力升級。

4. 仿真性能

我們在真實生產級負載下對其仿真速度與準確性進行了全面評估。

4.1 速度：極致成本優勢，仿真開銷降低超 39 萬倍

以一個典型生產場景為例：
圖片
成本節省為原來的 1/390,106，同時將評估週期從數天縮短至分鐘級，極大加速了 LLM 服務的部署調優與容量規劃流程。

4.2 準確度：高精度預測，端到端誤差可控

我們從兩個層面驗證仿真器的準確性：

4.2.1 BatchRunnerEstimator：單步時延預測精度

針對動態批處理場景，我們通過profiling工具，對真實部署的推理服務中抓取 958 個批次的異構請求組合（batch size 範圍 1–28），對比實測時延與仿真預測值。結果顯示平均時延誤差僅為 4.24%。
圖片
圖中陰影表示所有樣本點覆蓋範圍

4.2.2 InferenceEngineSimulator：端到端系統指標精度

我們在 A100-SXM4-80GB 上，基於 SGLang v0.5.6 推理引擎，使用ShareGPT 數據集構造多輪對話負載，對 Qwen3-8B 模型在四種 KV Cache 配置下進行測試：

  • IDLE：未啓用 Radix Cache
  • DEVICE：僅使用 GPU HBM 作為 KV Cache 存儲
  • HOST：啓用兩級存儲（HBM + Host DRAM）
  • DISK：啓用三級存儲（HBM + DRAM + DISK）
    仿真結果與實測數據對比如下：
    圖片

圖片
Tair-KVCache-HiSim 在保持端到端高保真（平均誤差 <5%）的同時，將 LLM 推理性能評估的成本與時間開銷降低五個數量級。

5. 未來展望

KVCache 仿真分析的價值不僅在於對現有系統的優化，更在於為未來 AI 基礎設施的演進提供前瞻性指導。通過支持多樣化的 Workload 模式與異構硬件資源的全流程仿真，我們能夠快速響應業務變化，精準識別計算或存儲側的性能瓶頸，並基於當前確定的模型與硬件平台，自動生成滿足 SLO（如延遲、吞吐）約束的最優配置方案與調優建議。
面向大模型快速迭代的趨勢，包括新型架構（如 Mamba、混合注意力）、稀疏化策略、推測解碼等優化算法的持續演進，傳統的“先建硬件、再適配軟件”模式已難以為繼。未來的基礎設施設計必須轉向 “軟硬協同、以負載驅動” 的新範式：即在服務器形態、內存層次、互聯拓撲乃至超節點規模等維度上，同步規劃計算能力與 KVCache 存儲體系的演進路徑，確保在滿足 SLO 的前提下實現吞吐最大化與成本最優化。
這一願景的實現，離不開 KVCache 作為核心狀態載體的深度參與。緩存不再只是輔助組件，而是連接算法、系統與硬件的關鍵樞紐。而高保真仿真，正是實現科學決策的核心引擎。我們將在後續的《KVCache 驅動的軟硬結合演進》中詳細探討。

6. 瞭解更多

歡迎搜索釘釘羣號：109765011301入羣與技術專家交流！

阿里巴巴 , nosql , 教程 , 阿里雲 , SQL
user avatar
0 位用戶收藏了這個故事！

發佈 評論

Some HTML is okay.