同样写着“512 维潜变量加 64 维位置分支”，有人算出 6.75 KiB/Token，有人算出 67.5 KiB/Token。两者相差十倍，通常不是算法突然进步了，而是层数漏了一位。容量规划里，最危险的错误往往发生在单位和统计范围上。
MLA 以低维潜在状态保存注意力所需的信息，是 DeepSeek-V2 已提出的设计，并非 2026 年 10 月才出现的新概念。DeepSeek-V2 原论文
先写公式，再填配置
以一种简化 MLA 缓存布局为例，每层为每个 Token 保存潜变量与独立 RoPE Key 分支。若层数为 L，两个维度分别为 dc、dr，每元素占 b 字节，未分片的缓存为：
KV_bytes = L × (dc + dr) × b × sequence_length × concurrent_sequences
这是教学模型的存储公式。它没有包括页表、对齐、量化缩放因子、额外状态或共享层。真实引擎可能使用不同布局，模型配置也不保证所有层完全相同。
取 L=60、dc=512、dr=64、FP16 每元素 2 字节：单层单 Token 为 1152 B，全层为 69120 B，也就是 67.5 KiB；128 KiToken 的单序列全层缓存为 8.4375 GiB。这里明确使用 1 Ki=1024、1 GiB=1024³ B，避免把十进制 GB 与二进制 GiB 混在一张表里。
把计算器写成可检查的代码
下面的维度是人为指定的算术样例，不代表某个现役模型的完整配置，也不是实测显存。保存后用 Python 3 运行。
from fractions import Fraction def mla_bytes(layers, dc, dr, element_bytes, tokens, sequences=1): args = (layers, dc, element_bytes, tokens, sequences) if any(x <= 0 for x in args) or dr < 0: raise ValueError("invalid dimension") return layers * (dc + dr) * element_bytes * tokens * sequences per_token = mla_bytes(60, 512, 64, 2, 1) full = mla_bytes(60, 512, 64, 2, 128 * 1024) assert per_token == 69120 assert Fraction(full, 1024 ** 3) == Fraction(135, 16) # 仅比较两个假设向量的元素数，不是模型能力对比。 saved = 1 - Fraction(576, 8192) print("bytes/token:", per_token) print("GiB/sequence:", float(Fraction(full, 1024 ** 3))) print("element reduction %:", float(saved * 100))最后一行得到约 92.97%，不是 85.9%。但“8192 个元素变成 576 个元素”只是一组给定维度的比较，不能直接拿来宣称某个模型相对另一个模型省了同样比例，更不能据此证明精度无损。比较完整 MHA/GQA 缓存时，还要把 Key、Value、KV 头数和 head_dim 一起写出来。
TP=8 不等于一律除以八
一种缓存可能按头分片，另一种潜在状态可能被复制。还有流水线按层分配、跨层共享以及不同 Attention 后端的差别。没有读引擎布局与分配日志之前，直接把总量除以 TP 数，会得到一个看似精确、实际无法使用的单卡容量。
应当分别记录逻辑全局字节数、每张卡实际保存的状态、物理块取整后的分配量。权重、激活、CUDA Graph 和通信缓冲区另外列账，不能把“KV 放得下”写成“模型可以运行”。
10 月 7 日 vLLM 对 DeepSeek-V4.1-Flash 的说明已经涉及压缩状态、窗口状态及跨层共享。它提醒我们：旧版 MLA 的简化公式不能自动覆盖新模型的全部缓存。vLLM 官方工程说明
这份计算器只验证整数与单位，未调用 GPU、未加载模型。落地时应从目标 checkpoint 的配置和实际后端入手，再用分配日志核对公式。容量数字可以精确到字节，前提是每个因子都有明确含义。
