阿里云 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 协同、多级缓存预取与动态批处理等机制，在保障低延迟的同时最大化吞吐效率。

1

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 利用率与系统吞吐。
  1. 动态批处理调度
    调度器综合考虑显存余量、请求优先级及缓存就绪状态，将多个就绪请求（可能包含 Prefill 新请求与Decode 进行中请求）组合成一个异构 batch 准备执行推理。
  2. 分阶段模型前向计算
    • Prefill（预填充）阶段：处理缓存未命中的剩余 512 Token，输入较长，计算密集，性能主要受模型并行度、量化和 GPU 算力影响；
    • Decode（解码）阶段：逐Token生成，每次仅计算一个新 token，但需读取全部历史 KV Cache，受限于显存带宽
  1. 后处理与流式返回 (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 之间寻求平衡。

2

上述介绍的是 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 的预取。

3

SGLang 新请求默认调度逻辑

2.1.4 推理计算模型与框架实现差异

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：对最终表示进行归一化，供后续采样使用。

5

不同硬件不同的算子后端实现

尽管不同 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 设置。

这种多向依赖关系导致任一组件的建模偏差会通过系统链路级联传播并放大，使得端到端延迟预测严重失真。

  1. 单步时延受状态、配置与硬件的非线性耦合影响，缺乏可泛化的细粒度建模方法

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 采用模块化架构，由以下三个核心组件协同工作，完整复现从请求接入到结果返回的端到端推理流程：

6

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 实现端到端推理行为仿真的核心模块。它通过解耦建模调度、缓存管理与批执行三大子系统，并引入统一全局时钟机制，确保各组件行为高保真且可独立验证。整体架构如图所示，包含以下三个协同工作的子模块。

7

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： 多级分布式缓存行为建模

8

Scheduler和KVCacheManager的交互流程图

KVCacheManagerSimulator 首次在开源仿真器中实现对三级 KV Cache 存储层次（L3/L2/L1）的完整建模，支持异构存储介质（如 SSD、Host DRAM、GPU HBM）在容量、带宽与成本上的差异化配置。

其核心流程如下：

  1. 请求进入 Waiting Queue 前，通过前缀匹配查询，确定各级缓存池中的命中情况；
  2. 若 L3（如 SSD）中命中情况满足条件，如长度超过触发阈值，则启动 L3 → L2（Host DRAM）的异步预取；
  3. 当调度器准备执行该请求的 Prefill 阶段时，根据预取策略决定是否等待预取完成；
  4. 一旦进入 Running Queue，在上一批次 GPU 执行期间，利用 CPU-GPU 时间重叠窗口，将命中的 KV Cache 从 L2 迁移至 L1（GPU 显存）；
  5. 仅当 L1 缓存加载完成后，才启动模型前向计算。

通过在仿真器中实现多级缓存前缀树，以及对各层缓存内存池的建模与异步策略的模拟，该模块能够在不进行实际内存分配、数据搬运的情况下，模拟实际执行流程输出精确的缓存命中率、各级 I/O 传输量及时延，为调度与性能预测提供关键输入。同时，HiCache 驱逐策略（如 LRU、LFU）和 Radix Tree 结构的模拟确保缓存管理行为与真实系统一致。

3.3.3 BatchRunnerEstimator：细粒度、泛化性强的单步时延预测

9

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 的上述硬件参数，推导出其理论最短执行时延：image.png )，算子的实际性能要么受计算吞吐限制（计算密集型），要么受内存带宽限制（访存密集型），取两者中耗时更长者作为下限；对于通信算子，其时延主要由数据传输量与链路带宽决定，理论时延简化为：image.png；
    • 基于采样的插值/回归模型： 通过离线 Profiling 构建算子级的时延映射函数；
    • 理论引导缩放回归： 在 Roofline 基础上，通过少量实测数据学习 scale 因子，得到更贴近实际的估计式image.png；
    • 集成多种 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 万倍

以一个典型生产场景为例：

10

成本节省为原来的 1/390,106，同时将评估周期从数天缩短至分钟级，极大加速了 LLM 服务的部署调优与容量规划流程。

4.2 准确度：高精度预测，端到端误差可控

我们从两个层面验证仿真器的准确性：

4.2.1 BatchRunnerEstimator：单步时延预测精度

针对动态批处理场景，我们通过profiling工具，对真实部署的推理服务中抓取 958 个批次的异构请求组合（batch size 范围 1–28），对比实测时延与仿真预测值。结果显示平均时延误差仅为 4.24% 。

11

图中阴影表示所有样本点覆盖范围

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）

仿真结果与实测数据对比如下：

12
13

Tair-KVCache-HiSim 在保持端到端高保真（平均误差 <5%） 的同时，将 LLM 推理性能评估的成本与时间开销降低五个数量级。

5. 未来展望

KVCache 仿真分析的价值不仅在于对现有系统的优化，更在于为未来 AI 基础设施的演进提供前瞻性指导。通过支持多样化的 Workload 模式与异构硬件资源的全流程仿真，我们能够快速响应业务变化，精准识别计算或存储侧的性能瓶颈，并基于当前确定的模型与硬件平台，自动生成满足 SLO（如延迟、吞吐）约束的最优配置方案与调优建议。

面向大模型快速迭代的趋势，包括新型架构（如 Mamba、混合注意力）、稀疏化策略、推测解码等优化算法的持续演进，传统的“先建硬件、再适配软件”模式已难以为继。未来的基础设施设计必须转向 “软硬协同、以负载驱动” 的新范式：即在服务器形态、内存层次、互联拓扑乃至超节点规模等维度上，同步规划计算能力与 KVCache 存储体系的演进路径，确保在满足 SLO 的前提下实现吞吐最大化与成本最优化。

这一愿景的实现，离不开 KVCache 作为核心状态载体的深度参与。缓存不再只是辅助组件，而是连接算法、系统与硬件的关键枢纽。而高保真仿真，正是实现科学决策的核心引擎。我们将在后续的《KVCache 驱动的软硬结合演进》中详细探讨。

6. 了解更多

欢迎搜索钉钉群号：109765011301入群与技术专家交流！

posted @ 2026-01-07 15:56  数据库知识分享者小北  阅读(3)  评论(0)    收藏  举报