模型架构

从哪里来

8B 只说明参数量的约数

第 1 章把一次执行写成容量、运算量和读取量。数字从哪里来？“一个 8B 模型”只给出参数规模的数量级，没有说明每个 token 用哪些参数、上下文保存在哪、哪些工作必须先后发生。

计算图用节点表示运算、用边表示数据依赖。节点决定 F，边上的张量决定传递的字节，边的方向决定谁必须等谁。权重在请求之间保持不变，KV 随生成追加，中间激活往往用完即弃——三种数据的生命周期不同，优化手段也不同。

Prefill 能并行，decode 被自己的输出卡住

RNN 在同一层等待前一个 token。因果 Transformer 不同：只要上一层的前缀已经算完，同一层里已知的输入 token 可以一起算。深度方向仍有依赖——第 l+1 层要用第 l 层的结果。

生成新 token 又多了一条依赖：下一步的输入就是这一步的输出。所以 prefill 处理已知输入，decode 逐步吐出新词。缓存把“重新计算旧 token 的投影和 FFN”变成“保存并读取它们的 K、V”。旧的查询已经完成任务，下一步用新的 Q 去打已经存下来的上下文。

MHA、GQA、MQA、MLA

多头注意力若为每个查询头都存一份 KV，容量按头数线性涨。分组查询注意力（GQA）让若干查询头共享一组 KV：Qwen3-8B 是 32 个 Q 头配 8 个 KV 头，相对于 MHA 省 4 倍状态。MQA 让全部查询共享一组，再省 8 倍，但表达力更差。MLA 把 KV 压进低秩潜空间，用计算换容量——DeepSeek 系列走这条路，8K 上下文大约只有 GQA 的一半。

权重、上下文、临时数据要分开记账。Qwen3-8B 的 BF16 权重约 16.38 GB，驻留后供所有请求反复使用；一步 decode 的主要权重读取约 15.14 GB（词嵌入按行查找，不必整表扫过）。8K 上下文约 1.125 GiB。当 batch 增大，各请求的 KV 读取会在某一点超过权重读取：H=8192 时大约 B=13，H=2048 时大约 B=51。上下文越长，权重复用的红利越早被独立状态吃掉。