Amazon LLM：KV Cache 缓存什么，怎样估算内存与 Decode 成本？

题目重点：区分prefill/decode、K/V与Q，计算GQA缓存规模并核位置、版本和前缀复用。

题意与假设

这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。

prefill处理已知输入序列，各层历史token投影K/V保存；decode新token生成自己的Q/K/V，把新K/V追加后用当前Q读历史K/V。历史Q无需供未来attention，缓存它不是核心节省。
无cache每次重算整个前缀的历史投影与层激活；cache复用这些不变值，仍需当前query与历史keys的score和V加权，生成依然逐token，不能宣称所有未来token并行或每步不再读T长度。
基础容量bytes=2·B·L·T·Hkv·dh·b。使用KV头数而非Q头数，K与V均计；分配页、对齐、元数据/碎片与其他模型张量另外加，不把公式值当整卡峰值。
RoPE/position处理保持绝对位置offset，已经旋转的cached K不能重复旋转。模型权重、adapter、tokenizer、attention mask、position/scaling和dtype合同一致才可复用前缀；相同文本不一定相同token/hidden states。
量化KV可降内存/带宽但要测误差对长序列与检索的影响；GQA改变模型结构/训练合同，不是随手在现有MHA checkpoint删几个head就等价。
批服务要管不同长度、sequence结束释放、分页与共享前缀引用计数；每步整段cat复制会导致额外O(T)数据搬运，预分配/分页更新更合适。全局共享需命中完整配置键和实际可复用前缀。

自拟B1,L32,T4096,Hkv8,dh128,BF16每元素2字节，基础KV=536,870,912字节=512MiB；同配置Hkv32为2GiB。额外batch8且同长度约4GiB，但共享前缀/不同长度会改实际占用，不能直接把其他模型状态排除。

每decode层attention读/计算约O(Hq·T·dh)，缓存容量O(BLTHkv dh)；新token投影/FFN另计。prefill dense attention O(T²)，cache不会改变其所有对主项。