DeepSeek-V4-Flash 长上下文显存分析

针对 dsv4_h200_max_context_length 实验结果（8×H200，TP=8，output_len=1，concurrency=1）的显存复盘。

1. 关键模型参数

参数	数值
总参数量	~158B（safetensors 汇总）
Checkpoint 大小	~149 GiB（fp8 权重 + scale）
层数 `num_hidden_layers`	43
Hidden size	4096
Attention heads	64
KV heads	1
每层 KV `head_dim`	512
KV cache dtype	fp8
每层压缩比	2 层不压缩，21 层 4:1，20 层 128:1
`max_position_embeddings`	1,048,576
H200 单卡显存	143 GiB

2. 理论显存估算

2.1 权重

149 GiB / 8 (TP) ≈ 18.6 GiB / GPU

vLLM 实际启动日志：Model loading took 20.07 GiB memory，与理论值基本吻合（包含少量加载开销）。

2.2 KV cache

按压缩后的平均每层 KV 大小估算：

不压缩的 2 层：512 bytes/token
4:1 压缩的 21 层：128 bytes/token
128:1 压缩的 20 层：4 bytes/token

平均每层 = (2×512 + 21×128 + 20×4) / 43 ≈ 88 bytes/token
43 层 ≈ 3.8 KiB/token

再考虑 indexer、alignment 等辅助缓存，vLLM 实际日志给出的数字是：

Available KV cache memory: 101.39 GiB
GPU KV cache size:         14,668,151 tokens
=> 约 7.0 KiB / token / GPU

因此 1M 上下文的 KV cache 约为：

1,048,576 × 7.0 KiB ≈ 7.0 GiB / GPU

2.3 1M 上下文单卡总占用

组件	估算
权重	~20 GiB
KV cache（1M tokens）	~7 GiB
CUDA graph / 启动开销	~1 GiB
激活 / 临时 buffer	数 GiB（prefill 峰值）
合计	~30 GiB / GPU

vLLM 可用显存按 --gpu-memory-utilization 0.90 计算：

143 GiB × 0.9 ≈ 128.7 GiB

显存完全够用。

3. 与实测结果对比

实测 target_len	max_model_len	结果
917,504	918,528	✅ 通过
1,048,576	1,049,600	❌ server failed to start

vLLM 1M 失败日志的关键信息：

User-specified max_model_len (1049600) is greater than the derived max_model_len
(max_position_embeddings=1048576 or model_max_length=None in model's config.json).

这说明：

917,504 通过是合理的：此时 KV cache 约 6.1 GiB/GPU，加上权重和开销远不到显存上限。
1,048,576 失败是合理的：实验里 max_model_len = input_len + 1024 pad = 1,049,600，超过了模型 config 声明的 max_position_embeddings=1,048,576。这是位置编码/配置上限，不是显存上限。
实验报告的最大长度 917,504 是偏保守的：理论上在 output_len=1 时，最大 input length 可以接近 1,048,575（只要 max_model_len ≤ 1,048,576）。实验因为采用了固定步长并加了 1024 的 pad，没有测到这个边界。

4. 结论

从显存角度看，1M 上下文在 8×H200 上完全可以放下：单卡约 30 GiB，仅占可用显存的 1/4 左右。
真正限制到不了 1M 的是 max_position_embeddings=1048576，而不是显存。
dsv4_h200_max_context_length 的结果与理论估算一致；测出的 917,504 是“该实验配置下能跑通的最大值”，但不是“硬件/显存能支持的最大值”。

3.2 KiB Raw Blame History Unescape Escape