KV 不是比喻，是一张容量账本

这次我们用一张独立的教学配置卡，不把它假装成刚才 MoE 的同一个真实模型。每一层，每个 token 留下八组 key 和八组 value，每组一百二十八个数，每个数用 BF16 保存，占两个字节。先不急着背多头注意力名称，直接数图上可见对象：八组，乘一百二十八，乘 K 和 V 两份，再乘两个字节，得到四千零九十六字节。这是一层里一个 token 的缓存，不是整个请求。

模型有三十二层，再乘三十二，得到十三万一千零七十二字节，也就是每 token 一百二十八 KiB。这里的 KiB 是一千零二十四字节。接着乘八千一百九十二个 token，恰好是一 GiB。两个看起来相同的二不能混在一起：一个来自 K 和 V 有两份，一个来自每个数占两字节。图旁保留完整乘法，课后不需要靠记忆猜。长度如果变成三万二千七百六十八，其他条件不变，缓存就是四 GiB。这是容量的线性增长关系：模型配置和精度固定时，长度翻四倍，KV 就翻四倍；注意力所需的计算怎样增长，则是另一项账。

现在有八个互不共享的请求，每个都已经缓存八千一百九十二 token，合起来就是八 GiB。模型权重可以由这些请求共用，但各自的历史状态不同，通常不能随便共用 KV。每多生成一个新 token，缓存还会继续增长。这里用的是二进制 GiB，前面的十六 GB 权重用十进制，两者不要直接当同一个单位相加。我们也还没算页内空位、运行缓冲和其他开销。容量账本告诉我们并发不能只看权重能否装下。接下来，一个请求已经结束，空出来的位置能不能立刻给另一个请求用？