大模型人工智能缓存【免费下载链接】unified-cache-managementUnified Cache Manager推理记忆数据管理器是一款以KV Cache为中心的推理加速套件其融合了多类型缓存加速算法工具分级管理并持久化推理过程中产生的KV Cache记忆数据扩大推理上下文窗口以实现高吞吐、低时延的推理体验降低每Token推理成本。项目地址https://gitcode.com/ModelEngine/unified-cache-management点击查看免费下载KV Cache 容量计算器KV Cache Size Calculator是 unified-cache-managementUCM随文档站点附带的一款纯浏览器端容量估算工具它根据模型架构参数、Token 数、批大小Batch Size与并行度TP配置直接推算出 KV Cache 的物理内存占用无需加载模型、无需启动推理引擎。本文将以该工具为核心完整讲解其使用场景、操作步骤、五类注意力架构的估算公式、正向/反向两种计算模式以及 Hybrid混合注意力模型的专用推导逻辑并结合仓库内 kv_cache_calculator.html、calculator.js 与 model-configs.js 的源码实现帮助你把它用于扩容前后的容量评估为 UCM 的 KV Cache 持久化与容量规划提供量化依据。一、为什么需要 KV Cache 容量计算器KV Cache 是 LLM 推理过程中为每个已生成 Token 保留的 Key/Value 张量缓存其内存开销随上下文长度、并发请求数线性增长是制约高并发、长上下文推理的首要瓶颈。UCM 的核心目标之一就是分级管理并持久化这些 KV 记忆数据因此在部署前精确回答“要预留多少显存给 KV Cache”就变得至关重要。该计算器适用的典型场景与官方文档一致扩容前预估在提高上下文长度或 Batch Size 之前估算需要为 KV Cache 预留的内存判断现有单卡/集群容量是否足够配置对比调整 KV 数据类型如 bfloat16 与 int8或 TP/DP 设置时对比页面公式下的单卡与集群 KV 容量差异反向推算已知可分配给 KV Cache 的内存预算时反算能容纳的 Token 总量为 max context / max concurrent requests 提供依据。它的设计目标决定了它运行在浏览器端、依赖模型config.json中的结构参数而非真实权重因此不会启动模型几秒钟即可完成一轮估算。二、页面整体工作流两个标签页 一个公式参考区工具页面kv_cache_calculator.html整体划分为三块Configuration 配置面板包含Standard Models与Hybrid Models两个标签页Results 结果面板展示 HBM Occupancy 与 UCM Dump 两项结果及逐步推导明细Current Model Formula Reference 公式参考区根据当前所选模型动态渲染其适用的估算公式卡片。页面通过 overrides/calculator.html 以 iframe 形式嵌入文档页而数据与逻辑分别来自两个脚本model-configs.js内嵌的预设模型参数通过getEmbeddedModelConfigs()返回与calculator.js全部计算逻辑与 UI 交互。文档正文docs/docs-site/docs/en/toolkit/kv-cache-calculator.md仅声明template: calculator.html实际可交互内容即由这套静态资源承载仓库内 docs/source/getting-started/kv_cache_calculator.md 是同一工具在旧版 Sphinx 文档中的嵌入形式。提示计算结果是基于页面所示模型公式的估算值部署前仍需核对推理引擎实际的 KV 布局以及 TP 分片/复制行为详见后文。三、核心公式体系五类注意力架构的 KV 内存模型calculator.js的formulaData对象定义了五类架构的估算公式其共同基本量是block_data_size——单个 TP rank 上、一个 vLLM block 的物理字节数vLLM block size 即 hash/分配粒度默认 128见 HTML 中block-size输入框的说明。架构公式block_data_size是否 ×2KV是否 ÷TP典型模型MHAMulti-Head Attention2 × num_hidden_layers × block_size × (num_kv_heads / TP) × head_dim × dtype_bytes是K、V 独立存储是KV 按 head 分片GPT-2、BERTMQAMulti-Query Attention2 × num_hidden_layers × block_size × (1 / TP) × head_dim × dtype_bytes是是kv_heads 1PaLMGQAGrouped-Query Attention2 × num_hidden_layers × block_size × (num_kv_heads / TP) × head_dim × dtype_bytes是是KV 按 head 分片Llama-3.1-70B、Qwen3-32B、Mistral-7B、GLM-4.5MLAMulti-head Latent Attentionnum_hidden_layers × block_size × (kv_lora_rank qk_rope_head_dim) × dtype_bytes否K/V 压缩进单一 latent否latent 跨 TP rank 复制UCM 只 dump TP0DeepSeek V3、DeepSeek R1、Kimi K2、GLM-4.7-FlashDSADeepSeek Sparse Attentionnum_hidden_layers × block_size × (kv_lora_rank qk_rope_head_dim index_head_dim) × dtype_bytes否否rank-sharedUCM 只 dump TP0DeepSeek V3.2、GLM-5、GLM-5.1几个要点dtype_bytesfloat16/bfloat16 2float32 4int8 1dtypeSizes映射表位于calculator.js的performCalculation中MHA/MQA/GQA 统一归属 GQA 家族detectArchitectureType()通过kv_heads attn_headsMHA、kv_heads 1MQA、其余GQA自动判别未知模型落入通用Standard公式MLA/DSA 的 rank-shared 语义latent 被压缩到低秩空间后在各 TP rank 间复制因此公式中不除以 TP且 UCM 侧只从 TP0 dumpTP 因子取 1而 GQA 家族 KV 按 head 分片每 rank 各存一份分片因此除以 TPUCM 侧每个 TP rank 都要 dumpDSA 在 MLA 基础上叠加 Lightning Indexer额外计入index_head_dim如 128。四、Standard Models正向计算 KV Cache 占用4.1 参数面板说明Standard 标签页输入项及默认值如下对应 HTML 中config-content-standard区块输入项默认值说明Model SourcePreset Models切换为 Custom Model 后可输入模型 URLSelect Model首个预设模型预设模型下拉框见下节列表Data Typefloat16 (2 bytes)可选 float16/bfloat162B、float324B、int81BNumber of Tokens4096单请求 Token 数最小 1Batch Size1并发请求数最小 1Tensor Parallelism (TP)1张量并行度最小 1vLLM Block Size128hash/分配粒度默认 1284.2 操作步骤选择预设模型或切换到 Custom Model 输入受支持的模型地址见第六节设置 Data Type、Token 数、Batch Size、TP 与 vLLM Block Size点击Calculate KV Cache按钮结果面板输出两个指标KV Cache HBM Occupancy单卡prefill 后hash_blocks_per_req × block_data_size其中hash_blocks_per_req ⌊tokens / block_size⌋乘以 Batch Size 得到总 hash block 数KV Cache UCM Dump跨全部 TP ranktotal_blocks × block_data_size × tpFactor其中total_blocks batch × ⌊tokens / block_size⌋tpFactor TPGQA 家族或1MLA/DSA。4.3 关键语义为什么只统计“带 hash 的完整 block”performCalculation()的实现明确区分了两个统计口径HBM Occupancy 只统计完整 blockprefill 后只有写满且有 hash的完整 block 才会被持久化保留末尾未写满的 partial block 没有 hash会被释放到 free_deque 队首并被立即复用不占驻留内存UCM Dump 体积按完整 block 计数vLLM 分配 N 个 blockUCM 就 dump N 个 block标准模型场景下 HBM 的 block_data_size 即等于 UCM dump 文件的 block-data-size。例如TP1、Block Size128、Batch1、Token4096 时⌊4096/128⌋ 32个完整 block若 Token4100则 32 个完整 block 1 个未写满 partial block不参与 HBM/UCM 统计。五、Maximum Tokens Calculator反向估算 Token 容量面板底部是独立的反向计算区输入Single-GPU Memory for KV Cache (GiB)默认 42指扣除模型权重、运行时开销与预留空间后真正可分配给 KV Cache 的内存点击Calculate Max Tokens即得单卡单请求可容纳的最大 Token 数。实现逻辑calculateMaxTokensForMemory()maxBlocks ⌊gpuMemoryGiB × 1024³ / block_data_size⌋ maxTokens maxBlocks × block_sizeblock_data_size 的推导与正向计算完全一致含 TP 分片或 rank-shared 处理输出同时给出max blocks × tokens/block的拆解明细便于反查瓶颈该值为单 GPU 上单请求的静态估算若输入的是 Hybrid 模型页面会弹出警示GQA 家族回退公式可能不准建议使用 Hybrid 标签页。六、自定义模型通过模型 URL 拉取真实 config当预设列表没有目标模型时可切换到 Custom Model输入模型主页 URL。fetchModelConfigFromUrl()calculator.js支持两个平台并自动解析出org/model标识HuggingFacehttps://huggingface.co/ORG/MODELModelScopehttps://www.modelscope.cn/models/ORG/MODEL。获取到config.json后工具提取hidden_size、num_attention_heads、num_hidden_layers、num_key_value_heads、kv_lora_rank、qk_rope_head_dim、head_dim、index_head_dim等字段并保留compress_ratios、sliding_window、layer_types、linear_attention*等 Hybrid 判定字段见fetchModelConfigFromUrl的transformedConfig构造。若拉取失败工具会回退检查本地内嵌配置。需要说明的是自定义 URL 拉取依赖浏览器直接访问模型平台若网络受限将提示Unable to fetch model configuration此时可直接使用预设模型或在 Hybrid 标签页中使用内嵌的 Hybrid 模型配置。七、Hybrid Models混合注意力架构的专用计算混合注意力模型含线性注意力层或稀疏注意力层无法用标准公式表达因此页面单设Hybrid Models标签页下拉内置 5 个模型DeepSeek-V4-Pro、DeepSeek-V4-Flash、Qwen3.6-35B-A3B、Qwen3.6-27B、Kimi-K3。该页输入项包括输入项说明Deployment MethodvLLMCUDA或 vLLM-Ascend昇腾Number of Tokens / Batch Size同标准页Tensor Parallelism (TP)同标准页Chunk Prefill Size默认 2048对应 vLLM 的--max-num-batched-tokens参数vLLM Block Size仅 DeepSeek V4Ascend 只支持 32/64/128CUDA 固定 256DS V4 MLA kernel 支持 256 及 256 的倍数MTP仅支持 MTP 的模型推测解码附加 1 层 MTP tuple7.1 线性注意力混合模型Qwen3.6 / Kimi-K3HLAderiveLinearHybridParams()从模型配置直接推导出引擎对齐后的 vLLM block_size、page_size 与 block_data_sizeblock_data_size num_tensors × page_size UCM dump (fa_blocks × fa_tp_factor mamba_blocks × TP) × block_data_size其中 block 数量0 命中 dump 场景fa_blocks batch × ⌈seq_len / block_size⌉mamba_blocks batch × num_chunks × num_mamba_groupsnum_chunks ⌈seq_len / actual_chunk⌉actual_chunk ⌊chunk_prefill / block_size⌋ × block_sizeTP dump 因子的核心差异Full AttentionFAKimi-K3 为 MLAlatent rank-sharedUCM 只 dump TP0×1Qwen3.6 为 GQAKV head 分片每个 TP rank 都 dump×TPMamba 线性状态无论哪类模型都是 head-sharded每个 TP rank 都 dump×TP。block_size 为引擎对齐结果而非用户设定Ascend 取128 × ⌈ssm_size / (128 × attn_single_token_k)⌉CUDA 取16 × ⌈mamba_total / (16 × attn_token)⌉。反向计算 Max Tokens 时还需扣除 BlockPool 保留的 null block1 个block_id0与 mamba 滚动窗口峰值2 × num_mamba_groupspre-copy 源 运行态。7.2 DeepSeek V4MLA Indexer SWA CompressorDeepSeek V4 的关键点是HBM block-data-size按 block_id与 UCM dump block-data-size按 hash block是两个不同口径页面分别计算hash_block_sizeAscend 为base_block_size × 432/64/128 → 128/256/512CUDA 固定 256HBM block-data-size每 block_idAscend 为num_layer_tuples × bs × 1154 ( bs×1024 if MTP)CUDA 为block_stride max(各 group page_size_sum)通常由 MLA groupbs256、fp8_ds_mla、584B/token、alignment576决定UCM dump每 hash blockAscendFA bs×(1154×num_c4a 32×num_c128a)、WA 131072×num_total 40960×num_c4aCUDAFA 45824×num_c4a 1168×num_c128a、WA 74752×num_total 40960×num_c4a两者均 round_up 到 4096TP dumpFA 与 WA 均为 TP-partitioned网络范围内每个 hash block 只 dump 一次×1预设模型分层V4 Pro 30 个 C4A 31 个 C128AV4 Flash 21 个 C4A 20 个 C128A 2 个 SWA-only。WA 的 dump 还有 block-wise每个 hash block 边界都 dump与 chunk-wise只在 chunk 末尾 dump每 chunk 1 次两种模式页面会同时给出两个结果。HBM 侧FA 组所有完整 block 都有 hash而 WA 组只有可触达reachable的段尾 block 才带 hashreachableHashCount()受 alignment_tokens 影响其余仅分配不缓存、立即释放复用。八、预设模型清单与数据来源model-configs.js内嵌了主流开源模型的架构参数getEmbeddedModelConfigs()返回按架构归类如下架构预设模型MLAdeepseek-ai/DeepSeek-V3、DeepSeek-R1、DeepSeek-V3.1-Terminus、zai-org/GLM-4.7-Flash、moonshot/Kimi-K2/K2.5/K2.6/K2.7-CodeDSAdeepseek-ai/DeepSeek-V3.2、zai-org/GLM-5、GLM-5.1、GLM-5.2GQAQwen/Qwen3-32B、Qwen3-235B-A22B、Qwen3-Coder-480B-A35B-Instruct、meta-llama/Llama-3.1-70B-Instruct、Llama-3.1-405B、zai-org/GLM-4.5、GLM-4.5-Air、GLM-4.7、minimax/MiniMax-M2/M2.1/M2.5/M2.7/M3HybridDS V4deepseek-ai/DeepSeek-V4-Pro、DeepSeek-V4-FlashHybridHLA 线性注意力Qwen/Qwen3.6-35B-A3B、Qwen3.6-27B、moonshot/Kimi-K3以 GQA 模型 Qwen3-32B 为例内嵌参数为hidden_size5120、num_attention_heads64、num_hidden_layers64、num_key_value_heads8、head_dim128以 MLA 模型 DeepSeek-V3 为例核心为kv_lora_rank512、qk_rope_head_dim64。这些真实参数可直接用于验证第二节公式的代入结果。九、结果解读与部署前核对区分两个结果口径绿色指标是单卡 HBM 驻留直接决定显存够不够蓝色指标是跨 TP rank 的 UCM dump 总量决定持久化存储与传输开销两者只有在 Batch1、TP1 时才数值一致TP 语义务必对照引擎实现核对页面假定 GQA 家族 KV 按 head 分片UCM dump 每个 rank、MLA/DSA latent rank-sharedUCM 只 dump TP0。若目标引擎的 KV 布局或 TP 复制策略不同结果需相应修正反向计算的输入口径Single-GPU Memory for KV Cache必须是扣除模型权重、运行时开销与预留空间后的净值而非整卡显存与实际部署联动UCM 侧的 dump 体积对应 KV Cache 持久化到分级存储如 DRAM/远端存储的数据量可结合 ucm_connector.py 与 request_hasher.py 理解 block hash 与 dump 的实际触发路径最终以真实环境的 KV 布局为准。十、源码参考想深入可以看哪里页面主体docs/docs-site/docs/assets/kv_cache_calculator.html计算逻辑公式数据、架构自动检测、正向/反向/Hybrid 计算docs/docs-site/docs/assets/calculator.js核心函数为performCalculationL687、calculateMaxTokensForMemoryL834、deriveLinearHybridParamsL958、deriveDSv4ParamsL1382、detectArchitectureTypeL527预设模型参数docs/docs-site/docs/assets/model-configs.js文档页嵌入方式docs/docs-site/overrides/calculator.html 与 docs/docs-site/docs/en/toolkit/kv-cache-calculator.md旧版 Sphinx 文档入口docs/source/getting-started/kv_cache_calculator.md总之KV Cache 容量计算器是 UCM 部署规划链路中“先算账、再扩容”的关键工具标准模型走五类架构公式混合注意力模型走引擎对齐的专用推导配合正向估算 KV 占用与反向反算 Token 容量两种模式即可在启动任何推理引擎之前完成 KV Cache 的容量论证。计算器给出的始终是基于模型公式的估算值最终部署务必回到真实引擎的 KV 布局与 TP 行为上做最终确认。赞分享大模型人工智能缓存【免费下载链接】unified-cache-managementUnified Cache Manager推理记忆数据管理器是一款以KV Cache为中心的推理加速套件其融合了多类型缓存加速算法工具分级管理并持久化推理过程中产生的KV Cache记忆数据扩大推理上下文窗口以实现高吞吐、低时延的推理体验降低每Token推理成本。项目地址https://gitcode.com/ModelEngine/unified-cache-management点击查看免费下载相关推荐磁盘、显存、内存如何估算GLM-5.3-Flash-W8A8部署资源规划与KV Cache容量计算磁盘、显存、内存如何估算GLM 5.3 Flash W8A8部署资源规划与KV Cache容量计算 部署 GLM 5.3 Flash W8A8GLM 5.3UCM Mooncake Store 实战指南基于 Mooncake 共享内存的 KV Cache 分层缓存配置与部署UCM Mooncake Store 实战指南基于 Mooncake 共享内存的 KV Cache 分层缓存配置与部署 Unified Cache Manag大模型人工智能缓存CANN ops-transformer 量化压缩算子 QuantCompressorHIFLOAT8 输入下的 KV Cache 压缩与反量化计算详解CANN ops transformer 量化压缩算子 QuantCompressorHIFLOAT8 输入下的 KV Cache 压缩与反量化计算详解 本文算子库人工智能大模型深度学习CANNAscend上一篇CefFlashBrowser完整指南如何在Windows上完美运行Flash游戏和存档管理下一篇终极Flash浏览器指南如何在Windows上完美运行经典Flash游戏创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考