AI-Infra学习之旅-Qwen2.5-7B：从模型结构到推理代价

很多人看模型卡片，第一反应是记参数：7B、28 层、3584 hidden、28 个 attention heads、4 个 KV heads。背下来当然有用，但如果只能停在“配置表识别”这一层，到了推理和部署场景里，信息就断了。

真正有价值的问题是另一类：

为什么 28 个 attention heads 搭配 4 个 KV heads 很关键？
为什么同样是 7B 模型，真正影响 decode 吞吐的往往不是“参数量”三个字，而是 KV Cache 的体积和访存模式？
为什么一个模型结构配置，最后会变成显存占用、带宽压力、批处理能力和服务形态的问题？

Qwen2.5-7B 很适合拿来回答这些问题。它既是一个足够主流、足够典型的开源模型，又在结构上包含了很多推理工程里真正重要的点：decoder-only、RoPE、RMSNorm、SwiGLU、GQA、KV Cache。

这篇文章不打算做一份参数摘录，而是想把一条主线讲清楚：从 Qwen2.5-7B 的结构参数出发，看到这些参数如何一步步决定推理代价。

先把结论说在前面

如果只用一句话概括 Qwen2.5-7B 的推理特征，我会这样说：

它是一个典型的 decoder-only Transformer，但真正影响部署体验的，不只是“7B”这个规模，而是它使用了 GQA，也就是 28 个 Query 头配 4 个 KV 头，这直接降低了 KV Cache 体积和 decode 阶段的带宽压力。

这句话里最重要的不是“典型”两个字，而是后半句。因为工程里真正昂贵的，往往不是纸面参数，而是参数如何转化成显存和访存行为。

先看结构，不然后面的工程分析没有落点

从整体上看，Qwen2.5-7B 仍然是非常标准的 decoder-only LLM。你可以把它简化成下面这条链路：

input tokens
  -> embedding
  -> 28 x decoder block
       -> RMSNorm
       -> self-attention
       -> residual
       -> RMSNorm
       -> SwiGLU MLP
       -> residual
  -> final RMSNorm
  -> lm head
  -> logits
  -> sampling / greedy
  -> next token

如果只看单层 block，它的逻辑并不复杂：

1 2	h1 = x + Attention(RMSNorm(x)) h2 = h1 + MLP(RMSNorm(h1))

这说明 Qwen2.5-7B 在结构上没有故作复杂，它依然沿着今天主流 LLM 的路线在走。但“主流”不等于“没有差异”，真正值得你盯住的是几个关键配置项。

这些参数不要只背，要知道它们在推理里意味着什么

围绕 Qwen2.5-7B，最值得记住的结构信息大致是这些：

num_hidden_layers = 28
hidden_size = 3584
num_attention_heads = 28
num_key_value_heads = 4
intermediate_size = 18944
RMSNorm
RoPE
SwiGLU
use_cache = true

先做两个最基本、但面试里很常见的推导。

每个 attention head 的维度

1
2
3

head_dim = hidden_size / num_attention_heads
         = 3584 / 28
         = 128

这意味着每个 head 的表示维度是 128。

GQA 下每组 KV 服务多少个 Query 头

1
2
3

group_size = num_attention_heads / num_key_value_heads
           = 28 / 4
           = 7

也就是说，28 个 Query 头并不是各自拥有独立的 K/V，而是 7 个 Query 头共享一组 K/V。

这正是 Qwen2.5-7B 在推理上最值得拿出来讲的点。它不是普通 MHA，也不是最极端的 MQA，而是 GQA。

为什么 GQA 这么重要

如果你只从论文术语看，GQA 像是一个“注意力结构变体”；但如果你站到推理工程里看，GQA 其实是在直接改 KV Cache 的体积。

先回忆一件事：在 decode 阶段，每生成一个新 token，模型都要读取历史的 K/V。上下文越长，读的数据越多，显存带宽压力也越大。

所以问题不只是“模型在不在算”，而是“模型为了算这一步，要从显存里搬多少历史状态出来”。

如果是标准 MHA，每个 Query 头都有自己的 K/V，那么缓存会更大；如果是 MQA，所有 Query 头共用一组 K/V，缓存最小，但表达能力压得更狠。GQA 落在两者之间，用结构上的折中，换来更好的推理效率。

对 Qwen2.5-7B 来说：

Query 头数是 28
KV 头数是 4

这意味着它在保留足够 Query 分辨率的同时，把 K/V 的缓存成本压得比较低。这个设计不会直接写成“吞吐更高”，但它确实在根上影响了 decode 的代价。

KV Cache 到底有多大，最好现场能算出来

这一步非常值得会。因为一旦你能从结构参数直接估算 KV Cache，你对模型推理的理解就不再停留在抽象层。

假设：

KV heads = 4
head_dim = 128
K 和 V 都要存
权重精度用 bf16，每个元素 2 bytes

那么单层、单 token 的 KV Cache 大小是：

2 (K 和 V)
x 4 (KV heads)
x 128 (head_dim)
x 2 bytes
= 2048 bytes
= 2 KB

Qwen2.5-7B 一共有 28 层，所以全模型、单 token 的 KV Cache 大小大约是：

1	28 x 2 KB = 56 KB

这已经足够说明问题了。一个 token 的缓存不算夸张，但如果上下文拉到几千甚至上万 token，再叠加 batch，显存压力会非常快地放大。

所以当你说“KV Cache 很重要”时，最好不要停在概念层。更好的表达是：

KV Cache 的成本和层数、KV 头数、head_dim、上下文长度以及 batch 一起增长，Qwen2.5-7B 因为用了 GQA，所以在同类结构里能明显减轻缓存体积和 decode 读带宽压力。

Prefill 和 Decode，Qwen2.5-7B 在两个阶段像两种问题

理解模型推理，不能只说“做前向”。真正的系统行为，是按阶段分裂的。

Prefill：更像一次大矩阵计算

当用户给出一长段 prompt 时，系统会先把这段 prompt 整体编码一遍。在这个阶段：

序列长度长
并行度高
Attention 和 GEMM 更吃计算效率

所以 Prefill 更偏向计算密集型问题。你会更关心算子性能、kernel 效率、吞吐和批处理能力。

Decode：更像反复读取历史缓存

进入生成阶段后，每步只新增一个 token，但每层都要依赖完整的历史 K/V。于是这时的矛盾不再只是 FLOPs，而变成了：

历史 KV 读得快不快
缓存布局规不规整
显存带宽够不够
多请求情况下 cache 管理是不是高效

所以 Decode 常见的真实瓶颈是 memory-bound，而不是单纯 compute-bound。

这也是为什么在推理系统里，大家会反复讨论：

KV Cache
PagedAttention
continuous batching
prefix caching
显存碎片

这些都不是“模型之外的花活”，而是模型结构延伸出来的工程问题。

Qwen2.5-7B 为什么适合部署和实验

这篇文章不是做选型指南，但仍然可以给一个很实用的判断。

Qwen2.5-7B 适合在工程里被反复拿来讲，是因为它卡在一个很好的中间位置：

足够典型，能代表主流 decoder-only LLM 的基本结构
足够主流，生态里支持它的框架和工具链比较全
足够有工程味，GQA、RoPE、RMSNorm、SwiGLU 都是真实部署里会遇到的东西
规模又没有大到一上来就把实验门槛抬得过高

如果你想练“如何把模型结构翻译成推理代价”，这类模型非常合适。因为它既不是极端简化版玩具，也不是大到只能谈集群调度的超大模型。

如果面试里问“Qwen2.5-7B 有什么值得说的”，可以怎么答

我会建议把答案收敛成下面这条逻辑线：

先给结构定位：它是标准 decoder-only Transformer。
再说单层结构：RMSNorm、Self-Attention、SwiGLU MLP、残差连接。
然后点出真正关键的工程特征：28 个 Query 头，4 个 KV 头，采用 GQA。
最后把结构和推理代价连起来：GQA 直接影响 KV Cache 体积、显存占用和 decode 阶段的带宽压力。

如果还想再往前一步，可以补一句：

所以理解 Qwen2.5-7B，重点不在于把参数表背出来，而在于能从这些参数直接看出部署代价和性能瓶颈在哪里。

这句话会让你的回答从“模型知识”转到“工程理解”。

写在最后

学模型结构，最容易犯的一个错误，就是把每个参数当成孤立知识点。比如知道 hidden size 是 3584，知道 attention heads 是 28，知道 KV heads 是 4，但这些数字彼此之间没有连起来。

更好的理解方式是反过来：

先问推理为什么慢。
再问显存为什么吃紧。
再问 Decode 为什么容易被 KV Cache 拖住。
最后回到结构上，看是哪些设计在决定这些代价。

从这个角度看，Qwen2.5-7B 不是一份参数表，而是一个很标准的练习对象。你越能把它讲成“结构如何变成推理代价”，就越说明你真的在用 AI Infra 的视角看模型。