估存储这件老手艺换到推理侧照样管用

估存储这件老手艺，换到大模型上照样管用。做过后端的人每接一个需求都要算：数据库占多少、缓存占多少、多少并发配多大机器。KV Cache 就是同一件事在推理侧的版本：一条请求占多少，并发一上来会怎样。

公式先摆出来。KV Cache 等于 2 乘层数乘 d_model 乘序列长度乘字节数，那个 2 是 K 和 V 两份。

拿三个量级走一遍就清楚了。先用最小的玩具例子：fp32、2 层、d_model 等于 4，算下来每 token 64 字节，3 个 token 才 192 字节，小到可以忽略。换成 GPT-2 small，12 层、d_model 768、fp16，每 token 约 36 KiB，满 1024 上下文约 36 MiB 一条，还算温和。

真正吓人的是 Llama-2-7B 量级，32 层、d_model 4096、fp16，每 token 512 KiB，4096 上下文就是 2 GiB 一条。同时伺候 16 个用户，光缓存 32 GiB，比一张 24GB 的消费级显卡还大，而这还没算模型权重。

我的判断是这条比很多优化文章都实用。增长来自四个方向：模型侧的层数和 d_model，使用侧的序列长度和并发数。四项两两乘起来，任何一项翻倍都会把显存推着走。你没法改模型，但序列长度和并发握在自己手里。

这也解释了我之前看不懂的两件事。为什么长上下文服务那么贵，为什么高峰期限流。以前我只知道结果，现在能自己把账算出来了。我打算拿手头那套服务按这个公式估一遍，先看并发上限卡在显存的哪个位置。