导读
在大模型推理迈向“智能体时代”的今天，KVCache 已从性能优化手段升级为系统级基础设施。“显存内缓存”模式在长上下文、多轮交互等场景下难以为继；而“以存代算”的多级 KVCache 架构虽突破容量瓶颈，却引入由模型结构、硬件平台、推理引擎与缓存策略交织而成的高维配置空间。如何在满足服务等级目标（SLO）——如延迟、吞吐等前提下，实现“时延–吞吐–成本”的最优平衡，成为规模化部署的核心挑战。
为破解这一难题，阿里云 Tair KVCache 团队联合服务器异构计算软硬件团队，推出 Tair-KVCache-HiSim——首个面向分布式多级 KVCache 管理的高保真 LLM 推理仿真分析工具。该工具通过全链路建模请求生命周期、多级 KVCache 行为与异构批处理执行，在通用 CPU 上以 39 万倍成本优势实现 <5% 误差的端到端性能预测。更重要的是，它能基于真实负载，在用户指定 SLO 约束下自动探索帕累托前沿，支撑三大关键决策：
- 计算选型与优化配置：评估不同 GPU 型号、并行策略、量化方案及算子实现对 TTFT 与 TPOT 的影响，推荐最具性价比组合；
- 存储层级与介质规划：量化分析多级缓存架构收益边界，支持细粒度选择每层存储介质类型，并协同优化带宽配置、容量分配、预取策略与驱逐算法，最大化缓存命中率与 I/O 效率；
- 全局与本地调度策略协同：联合分析全局路由策略与本地调度机制对排队延迟、批构成与 GPU 利用率的影响，实现从集群负载均衡到单机流水线效率的端到端调优。
Tair KVCache 作为阿里云数据库 Tair 产品能力的延伸，本质是缓存范式的三次跃迁：
🔹 从 Redis 的“缓存数据 → 减少 I/O”；
🔹 到 GPU KVCache 的“缓存计算中间态 → 减少重复计算”；
🔹 再到 Tair KVCache 的“规模化、智能化的注意力状态管理 → 重构大模型推理成本模型”。
它标志着缓存正从辅助组件升级为 AI 基础设施层的核心能力——让“状态”可存储、可共享、可调度，支撑智能体时代的规模化推理底座。
一、引言
在大语言模型（LLM）推理服务快速落地与规模化部署背景下，推理系统性能直接决定用户体验、服务成本与资源效率。首 Token 延迟（TTFT）、每输出 Token 延迟（TPOT）及系统吞吐量已成为评估推理引擎的核心指标。这些指标高度依赖于模型结构（参数量、稀疏性）、硬件平台（A100/H100 显存带宽特性）、推理引擎（vLLM/SGLang/TensorRT-LLM 的调度与 KV 缓存策略）及运行时配置（量化方式、批处理策略、并行模式）的复杂耦合。
为支撑高效、低成本的推理系统设计与优化，亟需一种高保真、可扩展、易复现的性能评估手段。传统依赖真实 GPU 集群的端到端压测方式成本高昂、周期长，难以覆盖海量配置组合。因此，基于 CPU 的推理性能模拟系统应运而生：通过回放生产环境或代表性场景的真实 Workload Trace，在通用 CPU 平台上，快速、低成本、高精度地预测不同模型、GPU 目标、推理引擎及其配置下的 TTFT、TPOT、吞吐等关键指标。
进一步扩展至远端 KVCache 配置，所选存储介质（DDR4/HBM/NVMe SSD/CXL 内存池/远程 GPU 显存）的吞吐与延迟、总容量上限、缓存淘汰策略（LRU/LFU/Clock/优先级自定义）、TTL 过期与回收机制（惰性清理/定时后台回收/内存压力触发驱逐），共同构成影响推理性能的关键变量。尤其在 Agent 应用推理卸载至远端存储场景下，当 KVCache 无法完全驻留本地 GPU 显存时，其访问延迟将显著抬升 TTFT 与 TPOT；若淘汰策略与请求模式不匹配（如长上下文对话中高频复用早期层 KV 状态却被频繁驱逐），则导致缓存命中率骤降，引发重复计算或额外 I/O 开销；不当 TTL 设置亦可能造成过早失效（降低复用效率）或内存耗尽（挤占后续资源）。因此，远端 KVCache 设计本质是在容量–延迟–吞吐–成本四维约束下的精细权衡，需通过推理性能模拟叠加缓存命中率与传输模拟，量化评估不同配置组合对端到端推理 SLO（如 P99 延迟 ≤200ms、吞吐 ≥50 req/s）的敏感性，为异构推理架构下的缓存层级优化提供决策依据。
二、当前推理模拟实现的方式和优缺点
2.1 推理引擎的整体架构
构建有效性能模拟器，须准确建模真实推理引擎执行逻辑。典型 LLM 推理系统（如 vLLM、SGLang、TensorRT-LLM）普遍采用异步请求调度 + 动态批处理架构，通过动态聚合 Prefill 与 Decode 请求提升硬件利用率。其核心流程如下：
2.1.1 请求处理流水线与生命周期
以 SGLang 为例，单个请求从接入到完成被嵌入深度流水化、异步协同的处理流水线中，通过 CPU-GPU 协同、多级缓存预取与动态批处理，在保障低延迟的同时最大化吞吐效率。
LLM 推理请求处理流水线与生命周期
示例场景：用户提交一段 1K Token prompt，期望生成 512 Token 输出，其中前 512 Token 与历史对话前缀匹配（KV Cache 命中率 50%）：
- 请求接入与前端处理：请求经负载均衡器路由至推理实例，在 CPU 完成分词（Tokenization），送入调度系统；
- 前缀缓存匹配与状态识别：引擎利用 Radix Tree 在 CPU 端快速检索历史上下文，若命中则标记对应 key/value 张量可复用；
- 异步缓存预取与零开销调度：
- 第一阶段预取（L3 → L2）：请求入等待队列后，异步启动 I/O 将命中的 KV Cache 从 SSD（L3）迁移至 Host DRAM（L2），后台执行不影响 GPU；
- 第二阶段加载（L2 → L1）：调度器决定纳入批次时，检查 L2 缓存就绪状态，就绪则启动向 GPU HBM（L1）加载；
- 零开销调度：CPU 调度决策与 GPU 上一批次执行重叠，避免流水线停顿，最大化 GPU 利用率；
- 动态批处理调度：调度器综合显存余量、请求优先级及缓存就绪状态，将多个就绪请求（Prefill 新请求与 Decode 中请求）组合成异构 batch；
- 分阶段模型前向计算：
- Prefill 阶段：处理未命中部分（512 Token），输入长、计算密集，性能受并行度、量化与 GPU 算力影响；
- Decode 阶段：逐 Token 生成，每次仅计算一个新 token，但需读取全部历史 KV Cache，受限于显存带宽；
- 后处理与流式返回：logits 经采样得 token ID，detokenizer 转为文本，以流式方式实时返回。
2.1.2 请求调度策略介绍
LLM 服务持续接收新请求，调度顺序直接影响系统性能。主流 Prefill/Decode 调度策略包括：
- Prefill 优先（SGLang）：新请求到达即暂停当前 Decode，优先执行其 Prefill，再与原有请求组成更大 Batch。最大化吞吐，但 TPOT 波动大；
- Decode 优先（TensorRT-LLM）：不中断运行中 Decode 请求，仅当资源空闲时调度新 Prefill。缓解 TPOT 抖动，适用于短输入；
- ChunkPrefill：将长 prompt 的 Prefill 拆分为小块，与 Decode 请求同步批处理，缓解长 prompt 对 Decode 的阻塞，兼顾 TTFT 与整体吞吐（throughput）和 TPOT；
- PD 分离：Prefill 与 Decode 解耦部署、独立调度，避免资源需求差异相互干扰，平衡 TTFT 与 TPOT。
除上述策略外，系统还可叠加 FCFS（先来先服务）、长输出优先、Cache 感知的最长公共前缀优先等机制。
2.1.3 SGLang 请求调度逻辑
SGLang Prefill 优先调度逻辑包含五阶段事件循环：HTTP Server 获取请求 → 输入处理（入队、HiCache 预取排队）→ 请求调度 → LLM Step 推理 → 后处理。核心调度逻辑如下：
- 调度资源限制：是否进入调度执行，取决于最大 Chunk Size、Prefill 最大 Token 数、最大运行请求数、KV Cache Pool 容量，均可通过启动参数配置；
- 执行调度规则：优先调度上一轮被 Chunk 切分的请求，其余按优先级（如 FCFS）排序；根据当前 Batch 可剩余 Token 容量，动态决定是否切块；
- HiCache 预取判定：开启多级 KV Cache 时，依预取策略（
best_effort、wait_complete、timeout）判断是否执行调度；未达终止条件则继续预取，暂不调度。
SGLang 新请求默认调度逻辑
2.1.4 推理计算模型与框架实现差异
主流大语言模型（如 Qwen 系列）普遍采用 Decoder-Only Transformer 架构，其推理前向流程含以下关键组件：
- Embedding 层：token ID 映射为高维向量；
- 位置编码层：采用 Rotary Position Embedding（RoPE），支持序列长度外推；
- 堆叠 Decoder Block（N 层）：
- RMSNorm：高效归一化；
- Attention：建模全局依赖，形式多样（MHA/MQA/GQA/MLA/Linear/Sparse Attention）；
- 前馈网络（FFN）：MLP 或 MoE 结构；
- 输出层 RMSNorm：最终表示归一化，供采样使用。
Qwen3 模型结构图
尽管功能相似，实际推理性能显著受底层实现影响。相同模型结构在不同硬件与配置下，会触发不同 GPU Kernel 实现；同一算子的启动参数（block size、tile 配置）也随输入长度（prompt/cache 长度）动态调整。这些优化由算子调度器在编译期或运行时自动选择，以最大化硬件利用率。因此，GPU 执行阶段必须考虑不同算子实现对执行时间的影响。
不同硬件不同的算子后端实现
2.2 LLM 推理仿真的核心挑战
LLM 推理具有动态异构性、强状态依赖性及对毫秒级 SLO 的高度敏感性，使传统静态建模方法难以复现真实行为。具体挑战如下：
1. 请求全生命周期流程复杂且状态密集
LLM 请求经历多阶段、多队列、多缓存层级的动态流转：Tokenization → Waiting Queue → Prefill 执行 → 多轮 Decode 批处理 → Detokenization。请求在调度器管理下于 Waiting/Running/Swapped 队列间迁移，并伴随多级 KV Cache 加载与驱逐（如 Waiting 队列中触发 L3→L2 预取；Prefill 前完成 L2→L1 加载）。忽略中间状态转移或缓存交互的简化建模将导致显著偏差。
2. 系统组件强耦合导致仿真误差级联放大
调度器、KV Cache 管理器与 GPU 执行引擎存在紧密反馈环路：
- 调度决策影响 KVCache 与计算：调度策略决定请求在 Waiting Queue 驻留时间，从而影响 L3→L2 预取量；所形成 batch 构成（Prefill/Decode 比例、上下文长度分布）直接决定 GPU kernel 并行效率与内存访问模式，影响执行时延；
- 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 数；
- 批处理异构性：连续批处理机制使同一 batch 中各请求上下文长度与 cache 状态高度异构，GPU kernel 计算强度与内存访问模式剧烈波动。
面对快速演进的模型架构与硬件生态，对每种“模型–配置–硬件”组合进行全量实测既不经济也不可扩展。因此，如何在避免穷举测量前提下，构建既能精确刻画单步行为、又具备跨模型与跨平台泛化能力的时延预测机制，成为高保真仿真的核心挑战。
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.1 整体架构
为满足 LLM 推理全生命周期高保真建模需求，我们设计并实现 Tair-KVCache-HiSim——一个面向大模型推理服务的轻量级、高精度仿真工具。它无需实际部署模型至 GPU，即可通过注入合成或真实请求轨迹，高效预估 TTFT、TPOT 和吞吐量等关键性能指标。相较于现有方案，Tair-KVCache-HiSim 首次支持多级 KV Cache 存储层次仿真（基于 HiradixCache 架构），为用户在缓存资源配置与成本权衡方面提供关键决策依据。
Tair-KVCache-HiSim 架构图
Tair-KVCache-HiSim 采用模块化架构，由以下三个核心组件协同工作，完整复现从请求接入到结果返回的端到端推理流程：
3.2 组件介绍
Workload Generator：面向存储优化的用户负载生成器，模拟真实业务场景。
- 随机数据集生成（Random Dataset）：适用于缺乏原始 trace 场景，支持基于开源数据集或随机 Token 建模；除常规输入输出长度、请求速率、并发度参数外，针对 KVCache 需求激增场景引入更高阶变量，包括场景选择（多轮对话/Agent）、多轮对话建模（对话轮次、每轮新增 Prompt 长度、时间间隔分布）；
- 时间戳数据集回放（Timestamp Dataset）：支持导入带原始时间戳的真实用户负载，通过精确重放历史负载，为特定业务线提供定制化性能评估与配置优化建议。
Global Router Simulator：全局请求调度仿真器，负责根据算法将请求精确调度至最优计算实例（Worker），支持以下策略：
- random：从所有 worker 中随机选择；
- round_robin：按顺序循环分配请求；
- cache_aware：维护各 worker 的 radix tree，通过前缀匹配选择最高缓存复用的 worker；
- power_of_two：随机选择两个 worker，对比实时负载（活跃请求数 & 队列长度），选择负载较轻者；
- bucket：按 prompt 长度区间划分，不同长度请求定向至特定 worker，桶边界随集群负载动态伸缩。
Inference Engine Simulator：实例推理引擎仿真器，对单个推理实例内部行为进行细粒度建模，完整复刻真实推理框架核心行为：
- 将推理过程划分为 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 的实现方式
BatchRunnerEstimator 被设计为一个支持细粒度、多范式、可插拔的单步时延预测引擎，目标是在动态批处理场景下，准确刻画由批次内请求异构性（不同 prompt 长度、cache 复用程度）带来的非线性性能波动时延，并在面对新模型、新硬件或新配置时仍具备可靠泛化能力。
BatchRunnerEstimator 摒弃依赖粗粒度 batch 统计量的做法，转而采用请求级状态描述符作为基本单元。每个批次由请求列表构成，每个请求以 (cache_len, input_len) 二元组刻画其状态，前者表示可复用的历史 KV Cache 长度，后者表示本次需计算的新 token 数。
在此基础上，构建可插拔混合时延建模框架，支持多种预测策略以平衡精度与泛化能力：
- 基于采样的插值/回归模型：通过离线 Profiling 构建模型级时延映射函数，适用于已知硬件-模型组合；
- 基于算子时延的组合：为提升预测泛化性（如新硬件、新模型结构），对算子时延求和预估：
- 算子分类：计算类（gemm/moe-cache 无关/attention-cache 相关/elementwise/embedding）与通信类；
- Roofline 模型：估算算子理论性能上限。依据其所需浮点运算量（FLOPs）与内存访问量（Bytes），结合目标 GPU 的峰值计算能力（Peak FLOPS）与内存带宽（Memory Bandwidth），推导理论最短执行时延：
实际性能取计算密集型与访存密集型二者耗时更长者为下限； 通信算子时延主要由数据传输量与链路带宽决定，理论时延简化为： 
- 理论引导缩放回归：在 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 实际耗时；在仿真器中注入相同配置，调用 BatchRunnerEstimator 单独预测时延；比较仿真值 vs. 实测值，计算 MAPE（平均绝对百分比误差）； - SchedulerSimulator（调度行为）：通过“调度轨迹回放”验证——从真实推理引擎导出完整调度日志（请求到达/离开 waiting queue/进入 running queue 时间、被跳过原因等）及每次调度决策时的批次快照；在仿真器中冻结 KV Cache 和 Batch