MHA/GQA/MQA模型

kv cache采用BF16存储时，每个token KV cache大小：

layer_num * 2 * head_num * head_dim *size_of_dtype

第一个2是key和value两个张量.

值得注意的是，早期的模型key和value的head num和dim是完全一样的，因此上面的计算方式没有问题。

不过现在新的一些模型存在key和value cache的head_dim不一样的情况。比如xiaomi-mimo

  "head_dim": 192,
  "swa_head_dim": 192,
  "swa_v_head_dim": 128,
  "v_head_dim": 128,

也就是这里默认(key) head_dim是192，但是v_head_dim只有128。

这样kv cache计算方式为：

layer_num * head_num *  (k_head_dim + v_head_dim ) * size_of_dtype

DeepSeek V3.1架构MLA

DeepSeek V3.1架构模型包括DeepSeek V3.1, Kimi-k2全系列，如kimi-k2.5, Kimi-k2.6, k2-thinking等。

kv cache采用BF16存储时，每个token KV cache大小：

layer_num*(512+64)*2

例如DeepSeek V3.1：

61*(512+64)*2 = 68.625 K

Kimi-k2.5/Kimi-k2.6与DeepSeek层数都是61层，区别是MOE部分，因此kv cache容量相同。

DeepSeek V3.2架构MLA + topk indexer

DeepSeek V3.2架构模型包括DeepSeek V3.1，GLM5系列，如GLM5.1.

DeepSeek V3.2与V3.1的区别，除了增加了一个2048 topk的indexer模块，还对kv cache采用了FP8量化，但是不是所有部分都进行了FP8量化，这使得kv cache计算稍微复杂了一些。当然V32也可以采用BF16存储kv cache，只是对推理decode能达到的batch不利。

每个token KV cache大小:  layer_num * (656 + (128+4)) = layer_num *788

解释：

FP8量化按128分块，每个分块需要一个FP32的缩放系数，所以每个128对应128xFP8+1xFP32。

head_dim是512+64，512的部分采用FP8，大小是512(FP8) + 512/128*4，而64的部分BF16不量化。indexer部分128采用FP8，大小为128+4。

所以总大小为：512(FP8) + 512/128*4 + 64(BF16)*2 + (128+4)

DeepSeek V3.2的FP8 kv cache大小为：

61*(656 + (128+4)) = 46.942 K

GLM5 架构与v32基本一样，但是模型层数为78层，因此kv cache每个token大小为

78*(656 + (128+4)) = 60 K

to do: 

SWA/hybrid-SWA模型，例如gpt-oss, MiMo-V2.5

token压缩+SWA：deepseek v4

3:1混合sparse attention，包括MHA+linear， MLA+linear