如何看懂 UCM 请求生命周期KV Cache 加载与保存的完整时间线5步详解【免费下载链接】unified-cache-managementUnified Cache Manager推理记忆数据管理器是一款以KV Cache为中心的推理加速套件其融合了多类型缓存加速算法工具分级管理并持久化推理过程中产生的KV Cache记忆数据扩大推理上下文窗口以实现高吞吐、低时延的推理体验降低每Token推理成本。项目地址: https://gitcode.com/ModelEngine/unified-cache-managementUnified Cache ManagerUCM是一款以KV Cache为中心的推理加速套件它将推理过程中产生的 KV Cache 记忆数据分级管理并持久化到外部存储从而扩大上下文窗口、降低每 Token 推理成本。本文将跟随一条真实的 vLLM 前缀缓存请求按时间顺序拆解 KV Cache 完成加载与保存的完整生命周期——从调度器查询可复用前缀到请求结束后缓存缓冲释放共 5 个关键阶段。为什么 KV Cache 需要被外部管理推理引擎通常只把活跃请求的 KV Cache 留在设备内存中进程一退出之前算过的前缀全部失忆下一次相同提示词只能从头重算。UCM 的做法是把这些算好的 KV 块持久化到外部存储NFS、3FS、Mooncake 等让新请求查得到、读得回在 UCM 的整体分层中请求生命周期主要发生在Integration引擎集成层与Store存储层之间完整时间线5步走完 KV Cache 的加载与保存下面按时间顺序拆解一次成功复用 保存的标准路径。源码入口在 ucm_connector.pyScheduler 侧和 Worker 侧各自持有一个UCMConnector它们不共享同一个请求对象只通过引擎传递的元数据协作。第1步Scheduler 查询可复用的前缀查引擎先检查自己内存里的缓存然后调用get_num_new_matched_tokens()询问 UCMConnector 把 token 序列按缓存粒度生成链式块标识块标识包含前缀关系相同文本在不同上下文中不会互相复用查询引擎已计算部分之后的外部块返回额外还能复用多少 token注意查到块 ≠ 数据可用真正的数据搬运发生在下一步之后。这一步决定了本次请求的计算预算——能复用多少 token就少算多少 Prefill。第2步调度结果转换为 Worker 元数据交接引擎分配好目标 KV 块后build_connector_meta()读取本轮新请求、缓存请求和引擎块编号生成UCMConnectorMetadata元数据内容作用加载记录UCM 块标识 → 引擎块位置Worker 据此找到目标设备地址保存记录标记哪些新算出的完整块需要写回外部存储本轮工作描述只是计划不代表数据已经搬运新请求可能同时需要加载已有块和保存新块被抢占后恢复的请求则需重新考虑加载。第3步Worker 加载Attention 按需等待读start_load_kv()使用元数据和启动时注册的 KV 布局向 Store 提交加载任务。这里有两条路径direct 路径start_load_kv()会直接等待本轮加载完成后续wait_for_layer_load()不再逐层等待layerwise 路径只提交首层加载每层 Attention 前由wait_for_layer_load()等待该层就绪再提交下一层加载——下一层的传输可以与当前层的计算重叠这是压低时延的关键技巧。失败的加载会通过无效块反馈给引擎避免把查询命中直接当成可用数据。第4步保存新块并跟踪异步任务写引擎算完未命中部分后Connector 把完整的新 KV 块提交给 Storelayerwise 路径在save_kv_layer()逐层提交direct 路径在wait_for_save()提交整块保存提交时会附带设备同步事件和源缓冲地址保证 GPU 数据真正算完才可读取关键点wait_for_save()返回 ≠ 所有外部写入结束待完成任务仍由 Connector 持续跟踪Store 的check()和wait()负责最终确认。Store 侧的层级关系Pipeline 可组合 Cache、Posix、Compress 等阶段如下图所示第5步请求结束与缓存缓冲释放收尾Scheduler 调用request_finished()时Connector 会检查该请求是否还挂着异步保存任务返回True→ 请求引擎延迟释放对应 KV 块等保存真正完成后再回收资源Worker 通过get_finished()等待相关待完成保存并向引擎报告可回收的请求集合⚠️ 资源可释放 ≠ 缓存已正确写入要确认持久化复用成功还需结合指标验证见下一节。一图看懂三个完成条件互不相同事件含义对应阶段查到块Scheduler 查询命中第1步加载完成Worker 拿到可用数据第3步保存结束Store 确认写入外部存储第4-5步查询、计算、存储各有完成条件把三者混为一谈是理解 KV Cache 复用最常见的误区。如何验证 KV Cache 真的被复用了验证方法很简单保留外部数据重启进程后重放同一提示词。重启可以清空引擎内存缓存如果新进程仍能快速命中说明复用确实来自外部存储。观察以下信号组合ucm:ucm_hit_tokens_total在本次运行中增加 → 查询发现可复用 token加载任务完成且无对应加载错误 → Worker 取得数据输出内容与基线一致 → 缓存重放正确性通过。完整步骤见 verify-cache.md指标口径见 metrics-reference.md。延伸阅读资料说明request-lifecycle.md请求生命周期官方文档本文底稿capability-principles.md块标识、分层缓存搬运原理ucm_connector.pyvLLM 连接器源码入口UCMDirectConnector/UCMLayerWiseConnectorucmstore_v1.pyStore 查询与任务接口定义【免费下载链接】unified-cache-managementUnified Cache Manager推理记忆数据管理器是一款以KV Cache为中心的推理加速套件其融合了多类型缓存加速算法工具分级管理并持久化推理过程中产生的KV Cache记忆数据扩大推理上下文窗口以实现高吞吐、低时延的推理体验降低每Token推理成本。项目地址: https://gitcode.com/ModelEngine/unified-cache-management创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何看懂 UCM 请求生命周期：KV Cache 加载与保存的完整时间线（5步详解）
如何看懂 UCM 请求生命周期KV Cache 加载与保存的完整时间线5步详解【免费下载链接】unified-cache-managementUnified Cache Manager推理记忆数据管理器是一款以KV Cache为中心的推理加速套件其融合了多类型缓存加速算法工具分级管理并持久化推理过程中产生的KV Cache记忆数据扩大推理上下文窗口以实现高吞吐、低时延的推理体验降低每Token推理成本。项目地址: https://gitcode.com/ModelEngine/unified-cache-managementUnified Cache ManagerUCM是一款以KV Cache为中心的推理加速套件它将推理过程中产生的 KV Cache 记忆数据分级管理并持久化到外部存储从而扩大上下文窗口、降低每 Token 推理成本。本文将跟随一条真实的 vLLM 前缀缓存请求按时间顺序拆解 KV Cache 完成加载与保存的完整生命周期——从调度器查询可复用前缀到请求结束后缓存缓冲释放共 5 个关键阶段。为什么 KV Cache 需要被外部管理推理引擎通常只把活跃请求的 KV Cache 留在设备内存中进程一退出之前算过的前缀全部失忆下一次相同提示词只能从头重算。UCM 的做法是把这些算好的 KV 块持久化到外部存储NFS、3FS、Mooncake 等让新请求查得到、读得回在 UCM 的整体分层中请求生命周期主要发生在Integration引擎集成层与Store存储层之间完整时间线5步走完 KV Cache 的加载与保存下面按时间顺序拆解一次成功复用 保存的标准路径。源码入口在 ucm_connector.pyScheduler 侧和 Worker 侧各自持有一个UCMConnector它们不共享同一个请求对象只通过引擎传递的元数据协作。第1步Scheduler 查询可复用的前缀查引擎先检查自己内存里的缓存然后调用get_num_new_matched_tokens()询问 UCMConnector 把 token 序列按缓存粒度生成链式块标识块标识包含前缀关系相同文本在不同上下文中不会互相复用查询引擎已计算部分之后的外部块返回额外还能复用多少 token注意查到块 ≠ 数据可用真正的数据搬运发生在下一步之后。这一步决定了本次请求的计算预算——能复用多少 token就少算多少 Prefill。第2步调度结果转换为 Worker 元数据交接引擎分配好目标 KV 块后build_connector_meta()读取本轮新请求、缓存请求和引擎块编号生成UCMConnectorMetadata元数据内容作用加载记录UCM 块标识 → 引擎块位置Worker 据此找到目标设备地址保存记录标记哪些新算出的完整块需要写回外部存储本轮工作描述只是计划不代表数据已经搬运新请求可能同时需要加载已有块和保存新块被抢占后恢复的请求则需重新考虑加载。第3步Worker 加载Attention 按需等待读start_load_kv()使用元数据和启动时注册的 KV 布局向 Store 提交加载任务。这里有两条路径direct 路径start_load_kv()会直接等待本轮加载完成后续wait_for_layer_load()不再逐层等待layerwise 路径只提交首层加载每层 Attention 前由wait_for_layer_load()等待该层就绪再提交下一层加载——下一层的传输可以与当前层的计算重叠这是压低时延的关键技巧。失败的加载会通过无效块反馈给引擎避免把查询命中直接当成可用数据。第4步保存新块并跟踪异步任务写引擎算完未命中部分后Connector 把完整的新 KV 块提交给 Storelayerwise 路径在save_kv_layer()逐层提交direct 路径在wait_for_save()提交整块保存提交时会附带设备同步事件和源缓冲地址保证 GPU 数据真正算完才可读取关键点wait_for_save()返回 ≠ 所有外部写入结束待完成任务仍由 Connector 持续跟踪Store 的check()和wait()负责最终确认。Store 侧的层级关系Pipeline 可组合 Cache、Posix、Compress 等阶段如下图所示第5步请求结束与缓存缓冲释放收尾Scheduler 调用request_finished()时Connector 会检查该请求是否还挂着异步保存任务返回True→ 请求引擎延迟释放对应 KV 块等保存真正完成后再回收资源Worker 通过get_finished()等待相关待完成保存并向引擎报告可回收的请求集合⚠️ 资源可释放 ≠ 缓存已正确写入要确认持久化复用成功还需结合指标验证见下一节。一图看懂三个完成条件互不相同事件含义对应阶段查到块Scheduler 查询命中第1步加载完成Worker 拿到可用数据第3步保存结束Store 确认写入外部存储第4-5步查询、计算、存储各有完成条件把三者混为一谈是理解 KV Cache 复用最常见的误区。如何验证 KV Cache 真的被复用了验证方法很简单保留外部数据重启进程后重放同一提示词。重启可以清空引擎内存缓存如果新进程仍能快速命中说明复用确实来自外部存储。观察以下信号组合ucm:ucm_hit_tokens_total在本次运行中增加 → 查询发现可复用 token加载任务完成且无对应加载错误 → Worker 取得数据输出内容与基线一致 → 缓存重放正确性通过。完整步骤见 verify-cache.md指标口径见 metrics-reference.md。延伸阅读资料说明request-lifecycle.md请求生命周期官方文档本文底稿capability-principles.md块标识、分层缓存搬运原理ucm_connector.pyvLLM 连接器源码入口UCMDirectConnector/UCMLayerWiseConnectorucmstore_v1.pyStore 查询与任务接口定义【免费下载链接】unified-cache-managementUnified Cache Manager推理记忆数据管理器是一款以KV Cache为中心的推理加速套件其融合了多类型缓存加速算法工具分级管理并持久化推理过程中产生的KV Cache记忆数据扩大推理上下文窗口以实现高吞吐、低时延的推理体验降低每Token推理成本。项目地址: https://gitcode.com/ModelEngine/unified-cache-management创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考