GLM-5 模型 KV Cache 容量规划报告

基于真实业务场景和 LMCache 容量分层调度模型，本文档针对 GLM-5 模型的显存与各级存储（CPU 内存、NVMe 固态硬盘）的容量需求进行了详细推演。

1. 核心参数提取

构建 LMCache 分层存储（显存-内存-NVMe）的容量水位模型，需要精确锚定三个核心变量：决定物理存储下限的模型量化精度、界定冷热数据边界的真实业务并发规模，以及影响最终实际物理分配的缓存命中率与系统碎片冗余。这三个维度的交织直接推导出支撑超长上下文所需的硬件成本底线。

1.1 模型物理参数

物理量化精度是整个容量推演的基石乘数。在 GLM-5 极大的上下文窗口下，INT4 量化将每个 Token 的状态体积极限压缩至 30 KB，相较于标准 FP8 方案实现了约 50% 的显存减负，这使得在单节点物理机上承载 128K 长文本的高并发会话成为可能。

  • 单 Token KV Cache 容量：
    • INT4 部署（当前配置）：单 Token 约 30 KB (30,732 B)
    • FP8 上限（常规推荐）：单 Token 约 60 KB (61,464 B) 本次测算我们基于极致显存优化的 INT4 量化精度（30 KB / Token）作为基准，相比 FP8 减少了约 50% 的物理存储占用。

1.2 业务负载参数

业务侧的并发形态直接定义了 LMCache 分层架构的数据驻留分布：正在执行 Decode/Prefill 的“活跃 Session”决定了 GPU 显存的峰值刚需，而处于轮询等待的“休眠 Session”及其携带的 64K-128K 超长上下文，则将作为温/冷数据引发 CPU 内存与 NVMe 磁盘的海量 Offload 压力。

  • 总用户数：200 人
  • 单用户 Session 数：10 个（总 Session = 2,000）
  • 单用户活跃 Session 数：2 个（总活跃 Session = 400，总休眠 Session = 1,600）
  • 上下文长度：
    • 平均长度：64K
    • 最大长度：128K

1.3 缓存复用与冗余策略

纯理论的线性乘法无法反映真实的系统开销。在实际的生产推演中，一方面必须扣除 System Prompt 等共享前缀带来的 Prefix Cache 命中红利（约 30% 物理空间免除），另一方面则需预留由于 PagedAttention 机制产生的非连续内存块碎片及 LMCache 调度产生的元数据开销（约 10% 冗余水位）。

  • Prefix Cache 命中/去重率：30%（即实际物理存储需打 7 折）
  • 内存碎片与元数据冗余（如 PagedAttention）：需预留约 10%

2. 容量需求测算

根据容量分层调度模型：热数据（活跃并发）决定 GPU 显存，温数据（短时休眠）决定 CPU 内存，冷数据（长尾及历史）决定 NVMe 容量。

为了确保系统稳定性，我们统一按照最大上下文（128K）来进行峰值容量的极限规划（Peak Capacity Planning）。

基础单 Session 物理占用计算（按最大 128K 长度）：

  • 单个 128K Session 的原始 KV 体积 = $128,000 \times 30 \text{ KB} \approx 3.84 \text{ GB}$
  • 考虑 30% Prefix 命中共享后，单 Session 实际新增占用 = $3.84 \text{ GB} \times (1 - 0.3) \approx 2.69 \text{ GB}$

2.1 热数据层：GPU 显存需求 (GPU VRAM)

GPU 显存主要用于承载当前正在发生 Decode 或 Prefill 的活跃 Session。

  • 活跃 Session 总数：200 用户 $\times$ 2 = 400 个
  • 活跃请求纯 KV 占用：$400 \times 2.69 \text{ GB} = 1,076 \text{ GB}$
  • 叠加 10% 的显存碎片与 PagedAttention 冗余：$1,076 \times 1.1 \approx \mathbf{1,184 \text{ GB}}$

评估：仅支撑 400 并发活跃请求的 KV Cache 需要约 1.18 TB 的纯显存，相比 FP8 方案大幅降低了算力设备的物理挂载压力（可省下近一半显卡）。

2.2 温/冷数据层：CPU 内存与 NVMe 存储需求

剩余的 1,600 个休眠 Session（总 2,000 - 活跃 400）的 KV Cache 将被 Offload 到下层的廉价存储中。具体在 Host 内存（CPU RAM）和 NVMe 固态硬盘之间的分配，取决于 LMCache 的冷热驱逐模型 (TTL 策略) 以及底层写入机制。

总容量盘子（活跃 + 休眠）：

  • 单 Session 实际占用：$2.69 \text{ GB}$
  • 2,000 个全量 Session 纯 KV 占用：$2,000 \times 2.69 \text{ GB} = 5,380 \text{ GB} \approx 5.38 \text{ TB}$
  • 叠加 10% 碎片冗余：$5,380 \times 1.1 \approx \mathbf{5,918 \text{ GB (约 5.92 TB)}}$

休眠 Session 的温数据容量盘子（CPU 内存承载部分）：

  • 休眠状态纯 KV 占用：$1,600 \times 2.69 \text{ GB} = 4,304 \text{ GB} \approx 4.3 \text{ TB}$
  • 叠加 10% 碎片冗余：$4,304 \times 1.1 \approx \mathbf{4,734 \text{ GB (约 4.73 TB)}}$

分层配比建议：

  1. CPU 内存 (Host RAM) 需求： 假设最近 1 小时内交互过的温数据保留在 CPU 内存中。如果以 30% 温数据来估算：
    • 需求量：$4.73 \text{ TB} \times 30\% \approx \mathbf{1.42 \text{ TB}}$
    • （注意：还需额外预留约数十 GB 用于 LMCache 维护全局 Radix Tree 映射表的元数据开销）。
  2. NVMe 固态硬盘需求 (基于 Write-all 策略)： 需要特别注意的是，LMCache 当前默认采用 write-all 策略（即将所有生成的 KV Cache 全量异步落盘以保证持久化和容灾），而不是仅存储冷数据。这意味着除非触发容量上限淘汰，NVMe 盘上将保存所有 2,000 个 Session 的全量副本。
    • 需求量：即全量数据的极限容量 $\approx \mathbf{5.92 \text{ TB}}$

3. 最终容量规划总结表

基于 GLM-5 (INT4 KV Cache, 30KB/Token)，在支持 200 人并发、峰值 128K 上下文、30% Prefix Cache 共享，且 LMCache 开启 write-all 策略的场景下，分层架构容量需求如下：

存储介质层级 承载对象 计算口径 (峰值 128K) 规划容量需求 备注
GPU 显存 400 个活跃 Session 400 $\times$ 2.69G $\times$ 1.1 ~1.18 TB 纯 KV 占用，未计入模型权重。
CPU 内存 约 480 个温 Session 4.73 TB $\times$ 30% ~1.42 TB 需额外预留空间供 LMCache 元数据调度。
NVMe 磁盘 全部 2000 个 Session 5.38 TB $\times$ 1.1 ~5.92 TB LMCache Write-all 策略下，保存全量副本，建议采用 PCIe 4.0/5.0 NVMe。

极限保守测算 (如果退化为 BF16 部署)： 如果因为精度问题无法使用 fp8_ds_mla，而是采用标准的 BF16（约 97.8 KB/Token），相比 INT4 基准，上述所有容量需求（GPU/内存/NVMe）将激增约 3.26 倍。此时 CPU 内存需求将逼近 4.63 TB，这在单台物理机上极难实现，因此对于 GLM-5 这种超长上下文模型，KV Cache 压缩与分层 Offloading 缺一不可。