Qwen2.5-7B 结构拆解

01先看全景:token 进去,logits 出来↑ 目录

整个模型分三段:查表变成向量 → 经过 28 个相同的 Decoder Layer → 投影回词表大小。 B 是 batch,S 是序列长度;数据流中只有最后一维会变。

02一层的骨架:两个分支挂在残差流上↑ 目录

28 层结构完全相同。中间的竖线是 残差流(residual stream), 维度始终是 [B, S, 3584];两个分支各自算完,再加回残差流。 "Pre-Norm" 指归一化放在分支入口,不在出口。

03每一步到底在乘什么↑ 目录

每层只有 7 次矩阵乘 + 1 次注意力核,其余都是逐元素运算。 上一节方框图里的每个框都是"一次矩阵乘"。这一节把它们逐个摊开: 输入形状、权重形状、输出形状和 FLOPs。

03.1先说清一个约定:权重存的是 [out, in]↑ 目录

safetensors 里 k_proj.weight 的形状是 [512, 3584], 和直觉的"3584 进、512 出"相反。原因是 PyTorch nn.Linear 的约定: 它算 y = x @ Wᵀ,所以权重按 [out_features, in_features] 存。

存储形状        [512, 3584]        ← safetensors 里看到的
数学上的乘法    [B,S,3584] @ [3584,512] → [B,S,512]
参数个数        512 × 3584 = 1,835,008     ← 两种写法数量相同

# 本文表格一律用「输入维 × 输出维」写,因为那才是数据流的方向

03.2三维张量怎么和二维权重相乘↑ 目录

[B, S, 3584] 是三维的,权重是二维的。实际执行时,batch 和序列两维先被压平:

[B, S, 3584]  --reshape-->  [B·S, 3584]     ← 把每个 token 当成独立的一行
                                  │
                            一次 GEMM:  [B·S, 3584] @ [3584, 3584]
                                  │
              [B·S, 3584]  --reshape-->  [B, S, 3584]

# 关键推论:token 之间在投影这一步【互不影响】。
# 唯一让 token 互相"看见"的地方,是注意力核里的那两次矩阵乘。

所以 batch "几乎免费":B·S 只让 GEMM 的一边变长, 权重那一边一个字节也没有多读。这是 continuous batching 的物理基础。

03.3一层里的全部矩阵乘↑ 目录

03.4「FLOPs = 2 × 参数量」是怎么来的↑ 目录

算 MFU 时会反复用到这条经验公式。下面从矩阵乘的定义推一遍:

# 矩阵乘的定义:C = A @ B,其中 A 是 [m,k],B 是 [k,n],C 是 [m,n]

C[i,j] = A[i,0]·B[0,j] + A[i,1]·B[1,j] + … + A[i,k−1]·B[k−1,j]
         └──────────────────── k 项相加 ────────────────────┘

# 也就是说:【每一个输出元素,都是一个长度为 k 的点积】

"每个输出元素乘一次加一次"的准确说法是: 「点积里每前进一项,就是一次乘 + 一次累加」:

算 C[i,j] 要做:
    k 次乘法        A[i,p] · B[p,j]        p = 0 … k−1
  k−1 次加法        把 k 个乘积加起来
  ─────────────────────────────────────
  = 2k − 1 次浮点运算

# 惯例上写成 2k —— 因为实现时累加器从 0 开始,第一项也做一次加法,
# 而且 k 一大,那个 −1 就无关紧要了(k=3584 时误差 0.014%)。

03.5一个能手算的例子↑ 目录

A = [1  2  3]      B = [ 7   8]        m=2, k=3, n=2
    [4  5  6]          [ 9  10]
      (2×3)            [11  12]
                         (3×2)

C[0,0] = 1·7 + 2·9 + 3·11 = 7 + 18 + 33 = 58    ← 3 乘 + 2 加 = 5 次运算
C[0,1] = 1·8 + 2·10 + 3·12 = 8 + 20 + 36 = 64   ← 5 次
C[1,0] = 4·7 + 5·9 + 6·11 = 28 + 45 + 66 = 139  ← 5 次
C[1,1] = 4·8 + 5·10 + 6·12 = 32 + 50 + 72 = 154 ← 5 次
                                                  ────
                                       真实次数 =  20

按公式  2·m·k·n = 2·2·3·2 = 24          ← 高估 4 次(就是那 4 个 −1)
精确式  m·n·(2k−1) = 4·5  = 20

# k=3 时差 17%;k=3584 时差 0.014%。大模型里直接用 2·m·k·n。

03.6为什么一个 token 就是「2 × 权重数」↑ 目录

一个 token 的隐藏向量是【一行】:  x 形状 [1, 3584]     ← m = 1
q_proj 的权重:                    W 形状 [3584, 3584]   ← k=3584, n=3584

FLOPs = 2 · m · k · n
      = 2 · 1 · 3584 · 3584
      = 2 · (3584 × 3584)
      = 2 · 权重矩阵里的元素个数
      = 2 × 12,845,056 = 25.69 MFLOP

# m=1 把 m 从式子里消掉了,于是 k·n 恰好就是权重的参数量。
# 这就是「FLOPs = 2 × 参数量」的全部来历 —— 它只对【每个 token】成立,
# batch 或 prefill 有 S 个 token 时,要再乘 S。

03.7哪些运算【没有】被这条公式算进去↑ 目录

03.8整模型:14.14 GFLOP / token,以及它的两个前提↑ 目录

总参数                    7,615,616,512
− embed_tokens              544,997,376   查表,不是矩阵乘
                        ─────────────────
= 参与矩阵乘的参数        7,070,619,136   × 2 = 14.14 GFLOP / token

  其中拆开看:
    主干(28 层 + 末位 norm) 6,525,621,760   × 2 = 13.05 GFLOP / 每个 token 都要过
    lm_head                 544,997,376   × 2 =  1.09 GFLOP / 只有【需要 logits】的位置要过

# 前提一:norm / bias 那 33 万个参数(层内 norm 200,704 + qkv bias 129,024 + 末位 norm 3,584)
#         其实不是矩阵乘,混在里面误差 0.005%,可以不管。
# 前提二:prefill 时 lm_head 只在【最后一个位置】做 —— 中间 1023 个 token 不需要 logits。
#         这一条在下面的实测里会被验证出来。

03.9用实测的 FLOPs 计数器验一遍↑ 目录

Round 2 的压测给 vLLM 开了 --enable-mfu-metrics, 服务端把每次迭代实际执行的 FLOPs 累加进 /metrics。 下面用这个计数器核对上面的模型,负载是 1024 输入 / 256 输出:

预测每条请求:
  主干矩阵乘   1280 tok × 13.05 = 16,705.6 GFLOP     prefill 1024 + decode 256
  lm_head       257 次 ×  1.09 =    280.1 GFLOP     256 个输出 + prefill 末位 1 个
  注意力核 prefill(因果)        =    210.5 GFLOP     200,704 × 1024²
  注意力核 decode               =    118.3 GFLOP     401,408 × Σ(1024…1279)
  ──────────────────────────────────────────────
  合计 17,314.5 GFLOP ÷ 256 个输出 token = 67.63 GFLOP / 输出token

04注意力分支:四个矩阵,两种尺寸↑ 目录

四个矩阵不对称:q_proj 和 o_proj 是 3584 → 3584 的方阵, k_proj / v_proj 只输出 512, 因为 K/V 只有 4 个头:4 × 128 = 512。GQA 的原理全在这一步。

05注意力核内部:五步,两次矩阵乘↑ 目录

Attention 没有参数,切头(05.1)只是一次 reshape;之后它做五步:QKᵀ 打分 → 缩放 → 掩码 → softmax 归一 → 乘 V 加权求和。 只有第 1 步和第 5 步是矩阵乘,其余是逐元素或按行操作。

05.1切头:一次 reshape,不是 28 次矩阵乘↑ 目录

q_proj 出来        [B, S, 3584]
                        │  view(B, S, 28, 128)      ← 3584 = 28 × 128
                   [B, S, 28, 128]
                        │  transpose(1, 2)
                   [B, 28, S, 128]                  ← 头维提到前面当 batch
                        │
              28 个 [S,128] 的矩阵并行做上面五步

# "多头"不是 28 组不同的权重,而是【一个大矩阵的输出被切成 28 段】。
# q_proj 的 3584 个输出通道,前 128 个属于头 0,接下来 128 个属于头 1……

05.2GQA 的广播:K/V 只有 4 组,怎么配 28 个 Q 头↑ 目录

Q   [B, 28, S, 128]        28 个头,各不相同
K   [B,  4, S, 128]        只有 4 组
V   [B,  4, S, 128]

                 ↓  repeat_interleave(7, dim=1)   ← 每组复制 7 份

K'  [B, 28, S, 128]        头 0-6 用同一份 K,头 7-13 用下一份……
V'  [B, 28, S, 128]

# 关键:复制发生在【寄存器/共享内存里】,不是在 KV Cache 里。
# 缓存的永远是那 4 组,所以显存省 7 倍;
# 参与矩阵乘的是 28 组,所以 FLOPs 一分不省。

GQA 除了省显存,还有第二重收益:decode 受访存限制时, 同一份 K/V 留在 L2 里,7 个头只付一次带宽。 原因是 FlashAttention 这类 kernel 不做物理 repeat, 而是让 7 个 Q 头直接索引同一块 K/V,7 个头读的是同一段显存。

05.3RoPE:位置信息是"转"进去的,不是"加"进去的↑ 目录

RoPE 没有参数。它把 Q 和 K 的 128 维两两配对成 64 个复数, 第 i 对按角度 θᵢ · pos 旋转:

对第 i 对分量 (x₂ᵢ, x₂ᵢ₊₁),位置 pos:

  x'₂ᵢ   = x₂ᵢ·cos(θᵢ·pos) − x₂ᵢ₊₁·sin(θᵢ·pos)
  x'₂ᵢ₊₁ = x₂ᵢ·sin(θᵢ·pos) + x₂ᵢ₊₁·cos(θᵢ·pos)

  θᵢ = base^(−2i/128)        Qwen2.5-7B 的 base = 1,000,000

# 为什么这样设计:两个向量旋转后做点积,结果只依赖【相对位置差】,
# 与绝对位置无关 —— 这就是"相对位置编码"的由来。

05.4常数 200,704 是怎么算出来的↑ 目录

注意力核的五步里,只有第 ① 步和第 ⑤ 步是矩阵乘,其余(缩放、掩码、softmax)是逐元素或按行操作, 所以只数这两步。先算单个头、单层、序列长度 S:

# ① scores = Q @ Kᵀ
  [S, hd] @ [hd, S] → [S, S]
  按 2·m·k·n:  2 · S · hd · S  =  2·hd·S²

# ⑤ out = P @ V
  [S, S] @ [S, hd] → [S, hd]
  按 2·m·k·n:  2 · S · S · hd  =  2·hd·S²

# 两步相加
  单头单层(完整)  =  4·hd·S²  =  4 × 128 × S²  =  512·S²

再分三步放大或缩小:

① × h = 28 个 Query 头          512·S² × 28   =  14,336·S²

② 因果掩码,只算下三角  ÷ 2      14,336·S² ÷ 2 =   7,168·S²
   上三角的 scores 反正会被 −∞ 掩掉,kernel 直接跳过不算;
   PV 那一步 P 是下三角矩阵,第 i 行只需要累加 j ≤ i 的项,同样省一半。

③ × L = 28 层                  7,168·S² × 28 =  200,704·S²
                                                 ↑ 这就是那个常数

05.5decode 的常数是 401,408,正好是 2 倍↑ 目录

# decode:只有 1 个 query,但要看 T 个历史位置

  ① q[1, hd] @ Kᵀ[hd, T]  → [1, T]     2 · 1 · hd · T  = 2·hd·T
  ⑤ p[1, T]  @ V[T, hd]   → [1, hd]    2 · 1 · T · hd  = 2·hd·T
                                       ─────────────────────────
  单头单层 = 4·hd·T   × h=28 × L=28  =  401,408 · T

# 为什么恰好是 prefill 常数(200,704)的 2 倍?
# 因为 decode 【没有因果折半】—— 那唯一的 query 要看【全部】T 个历史位置,
# 一个都不能跳。少了 ÷2,常数就翻倍。

逐 token 累加   Σ 401,408 · t   (t = 0 … S−1)
              = 401,408 · S(S−1)/2
              ≈ 200,704 · S²          ← 和 prefill 公式一模一样

S = 8,192 实算:  1.3467e13  vs  1.3469e13   比值 0.9999

05.6算一笔账:注意力核在 prefill 里占多少↑ 目录

# 分母口径:prefill 时 lm_head 只在【最后一个位置】跑一次,不是每个 token 都跑
权重矩阵乘  =  13.05·S + 1.09   GFLOP        主干 13.05/token + lm_head 一次
注意力核    =  200,704 · S²     FLOPs        因果

交叉点:  13.05e9 · S = 200,704 · S²   →   S = 65,021

结论:6.5 万 token 以内,Transformer 的算力大头始终是那 7 个权重矩阵乘, 不是常说的"注意力平方复杂度"。 Qwen2.5-7B 的 max_model_len 上限是 32768, 所以在这个模型的整个可用范围内,注意力核最多只占三分之一。 在短上下文场景优化注意力核,收益很小。

# softmax:对每一行做数值稳定版归一,逐元素数是 5 次
  ① 找本行最大值        max          1 次/元素
  ② 减去最大值          x − max      1 次/元素   防 exp 溢出
  ③ 取指数              exp(·)       1 次/元素
  ④ 累加求和            Σ            1 次/元素
  ⑤ 除以和              ÷ Σ          1 次/元素
                                    ──────────
                                     5 次/元素

  因果只有下三角 → 元素数 = S²/2
  5 × (S²/2) × h=28 × L=28  =  5 × 784 ÷ 2 · S²  =  1,960 · S²

# 缩放 ÷√128:每个元素就 1 次乘法
  1 × (S²/2) × 28 × 28      =      784 ÷ 2 · S²  =    392 · S²

# 和注意力核的两次矩阵乘比
  softmax   1,960 ÷ 200,704 = 0.98%
  缩放        392 ÷ 200,704 = 0.20%       两者都可以忽略

06GQA:28 个 Query 头,只配 4 组 K/V↑ 目录

GQA 让 7 个 Q 头共用同一组 K/V;Multi-Head Attention 里每个 Q 头配一个自己的 K/V 头。 两者相比,计算量几乎不变(K/V 广播复制到 28 份参与运算),但GQA 需要缓存的 K/V 只有 MHA 的 1/7。

07MLP 分支:参数的大头在这里↑ 目录

一层 MLP 的参数抵得上 7 层注意力。SwiGLU 用三个矩阵,传统 FFN 只用两个; 中间维度 18944 是 hidden 的 5.29 倍, 每个矩阵都有 6790 万参数。

07.1门控在"门"什么↑ 目录

传统 FFN 是 out = W₂ · σ(W₁·x) —— 一个线性层、一个激活函数、再一个线性层。 SwiGLU 把中间那步拆成两条并行的投影:一条当"内容",一条当"闸门",两条逐元素相乘:

gate = x @ W_gate        [B,S,3584] @ [3584,18944] → [B,S,18944]
up   = x @ W_up          [B,S,3584] @ [3584,18944] → [B,S,18944]

h    = SiLU(gate) ⊙ up   ← ⊙ 是逐元素乘,不是矩阵乘
out  = h @ W_down        [B,S,18944] @ [18944,3584] → [B,S,3584]

SiLU(z) = z · sigmoid(z) = z / (1 + e^−z)

07.2为什么值得多花一个矩阵↑ 目录

• 线性层做不出乘法交互。 σ(W₁x) 后再做线性变换, 整体仍是"逐通道非线性 + 线性混合";SiLU(W_g x) ⊙ (W_u x) 则含有 两个输入特征的乘积项。传统 FFN 要用相当多的神经元才能近似一个乘法。
• 开关是学出来的,并且逐 token 变化。 ReLU 的"关"只取决于该通道自己的值; SwiGLU 的"关"由一路独立的投影决定。所以网络能学出 "输入含有特征 A 时,关掉通道 k"这种条件逻辑。
• 软门比硬门好训练。 ReLU 在负半轴梯度恒为 0(死神经元); SiLU 处处可导,负半轴梯度也不为零,配合门控结构收敛更稳。

0876 亿参数,都堆在哪儿↑ 目录

09KV Cache:决定并发上限的那块内存↑ 目录

权重是死的,KV Cache 是活的。每来一个 token,28 层各存一份 K 和一份 V。 存下来的东西下一步还要用,所以生成第 1000 个 token 不需要重算前 999 个。

09.1decode 时,KV Cache 里发生了什么↑ 目录

上面那句"存下来的东西下一步还要用"是结论。下面展开讲机制, 它回答三个问题:cache 里存什么、每步怎么变、为什么旧的永远不用重算。

第 t 步走一遍↑ 目录

# 已经生成到第 t 个 token,cache 里躺着 t 行 K 和 t 行 V(每层各一份)

① 新 token 的隐藏向量 h  [1, 3584]
      │
      ├─▶ q = h @ W_q  →  [1, 128] × 28 头     ← 只有 1 行,这就是"query 只有一个 token"
      ├─▶ k = h @ W_k  →  [1, 128] ×  4 头     ← 追加进 cache,变成第 t+1 行
      └─▶ v = h @ W_v  →  [1, 128] ×  4 头     ← 同上

② 注意力:q 和 cache 里【全部 t+1 行】算
      scores = q[1,128] @ Kᵀ[128, t+1]  →  [1, t+1]
      out    = P[1,t+1] @ V[t+1,128]    →  [1, 128]

③ 拼头 → o_proj → MLP → lm_head → 采样  →  第 t+2 个 token

# 下一步重复 ①~③,cache 再长一行。

⚠️ 上面出现了两个"K":一个是权重,一个是缓存↑ 目录

第 ① 步的 W_k 和第 ② 步的 K 名字相近,却是完全不同的两个东西, 只是都存放在显存里。读这段流程时最容易把两者混淆,所以单独拆开讲。

━━━ 静态权重 · 训练出来的 · 加载时定死 · 所有请求共用同一份 ━━━━━━━━

  h [1,3584] ──@ W_q [3584,3584] ──▶  q [1,3584]  ──▶ 用完即弃
             ──@ W_k [3584, 512] ──▶  k [1, 512]  ──┐
             ──@ W_v [3584, 512] ──▶  v [1, 512]  ──┤ 追加一行
                                                  ▼
━━━ 动态缓存 · 运行时算出来 · 每请求私有 · 只增不改 ━━━━━━━━━━━━━━

       K cache [t+1, 512]          V cache [t+1, 512]
                        │
             q 和整个 cache做注意力(第 ② 步)

# W_k 是"怎么把 h 变成 k"的规则;K cache 是"历史上所有 h 变出来的 k 攒在一起"。
# 前者是函数,后者是这个函数的输出记录。

prefill  H [1024,3584] @ W_k → [1024,512]   一次写入 1024 行
decode   h [   1,3584] @ W_k → [   1,512]   每步追加    1 行
         ↑ 同一个 W_k,同一块 cache,只是一次喂几行不同

但进 cache 的只有 K 和 V 两样↑ 目录

一步 decode 算出很多东西,但绝大部分算完就丢:

严格说,缓存的不是"中间结果",而是"后续每一步都要反复读取的那两个张量"。 Q 和 K/V 的这种不对称,是 KV Cache 设计的起点。

因果掩码 ⇒ 位置 i 的隐藏状态 h_i 只依赖位置 ≤ i 的输入
         ⇒ 在末尾追加 token t+1,【不会改变】任何 h_i (i ≤ t)
         ⇒ K_i = W_k · h_i  和  V_i = W_v · h_i  恒定
         ⇒ 算过一次,就可以永久复用

省下多少↑ 目录

# T = 1152 时,生成下一个 token 要花多少 FLOP

有 cache   13.05e9(主干矩阵乘) + 401,408 × 1152(注意力)  =  1.35e10
无 cache   1152 × 13.05e9 + 200,704 × 1152²              =  1.53e13
           ↑ 每生成一个 token 都要把前面 1152 个重新 prefill 一遍
                                                      ─────────────
                                                      省 1,132 倍

# 代价是显存:每请求 T × 56 KiB,并且【不能丢】——丢了就得重算。
# 这就是为什么 KV 池是并发上限的硬约束,而不是权重。

存 K,V(GQA kv=4)   2 × 4 × 128 × 2 =  2 KiB / 层 / token   → 28 层 56 KiB
存 h(hidden 3584)  3584 × 2        =  7 KiB / 层 / token   → 28 层 196 KiB
                                        GQA 下存 K/V 省 3.5 倍

若换成 MHA(kv=28)  2 × 28 × 128 × 2 = 14 KiB / 层        → 反而比存 h 大 2 倍

每一步的账↑ 目录

每步新增   56 KiB              恒定 —— 与 T 无关、与 batch 无关
每步读取   T × 56 KiB          随上下文线性增长

  T =  1,152  →  0.066 GB   占权重 14.14 GB 的   0.47%
  T =  8,192  →  0.470 GB   占                   3.32%
  T = 32,768  →  1.879 GB   占                  13.29%

# 短上下文时 KV 读取可以忽略(这就是单流分析只看权重的依据);
# 到 32k 就占了一成三 —— 长上下文场景 decode 会明显变慢,慢在这里。

本轮压测形状(1024 输入 / 256 输出)一条请求的 cache:
  开始解码时  T=1,024  →  56.0 MiB
  解码到一半  T=1,152  →  63.0 MiB
  解码结束时  T=1,280  →  70.0 MiB

下一小节要用最后那个 70 MiB: KV 池 ÷ 单请求峰值占用 = 能同时跑的请求数。

09.2换算成 4090 上的并发上限↑ 目录

手算和服务端实测差得比预想大。下面先手算,再对照实测。

# 手算(乐观估计)
显存总量                     24 GiB
--gpu-memory-utilization 0.9  → 21.6 GiB 可用
  − 权重                       14.18 GiB
  − CUDA context / 激活 / 碎片  ≈ 0.5 GiB
  ────────────────────────────────────────
  KV Cache 池                 ≈ 6.9 GiB  →  约 129,000 token

# 服务端启动日志实测(同一张卡、同样 0.9)
Available KV cache memory: 4.64 GiB
GPU KV cache size: 86,896 tokens
Maximum concurrency for 8,192 tokens per request: 10.61x
  Actual usage: 15.49 GiB 权重+non-torch,1.04 GiB 激活峰值,0.34 GiB CUDA graph

# 手算高估了 49% —— 杂项那一项实际是 ~2.8 GiB 而不是 0.5
#   (21.6 − 权重 14.18 − KV 4.64 = 2.78;上面日志三项 15.49+1.04+0.34 也对得上)

86,896 token ÷ 平均上下文长度 = 能开的并发
  平均 1,280 token / 请求  →  约 67 并发   (1024 输入 + 256 输出)
  平均 2,048 token / 请求  →  约 42 并发
  平均 4,096 token / 请求  →  约 21 并发

10MoE:把这一块 MLP 换成 64 块,每次只用 8 块↑ 目录

MoE(Mixture of Experts)只改 MLP 这一块:注意力分支、残差流、RMSNorm、KV Cache 全部原样不动, 只把每层 203.7 M 的 SwiGLU 换成"一堆小 SwiGLU + 一个路由器"。 第 07 节算过,MLP 占全模型 74.9% 的参数。

10.1共享专家的 20480 从哪里来↑ 目录

20480 不是从 18944 或 2560 推算出来的,而是 config.json 里一个独立的字段。 Qwen2-57B-A14B 的 MoE 层一共写了三个不同的中间维,很容易看混:

不过这几个数不是随便定的。20480 和 2560 之间有一个简洁的关系:

  moe_intermediate_size  ×  num_experts_per_tok
        2560             ×          8            =  20480
                                                     ↑ 正好是 shared_expert_intermediate_size

# 换句话说:共享专家一个人,就有那 8 个被选中的路由专家加起来那么宽。

所以一个 token 走完一层 MoE,经过的 FFN 宽度是 路由部分 20480 + 共享部分 20480 = 40960,两部分各占一半。 图 12 底部那行"8 专家 220.2 M + 共享 220.2 M"两个数相同,原因就在这里: 不是巧合,是 2560 × 8 = 20480 直接导致的。

# 共享专家内部就是一个普通的 SwiGLU,只是宽度用 20480
  gate = x @ Wg[3584, 20480]        →  73,400,320
  up   = x @ Wu[3584, 20480]        →  73,400,320
  out  = h @ Wd[20480, 3584]        →  73,400,320
                                       ──────────
                        3 × 3584 × 20480 = 220,200,960
  gate = sigmoid(x @ W_sg[3584, 1]) →       3,584   共享专家自己的开关
                                       ──────────
                                       220,204,544   ← 表里"共享专家/层"那一行

# 对照被激活的 8 个路由专家(它们没有各自的开关,权重由 router 给)
                      8 × 3 × 3584 × 2560 = 220,200,960

# 再加上 router 本身(3584 × 64,不管选谁都要跑一遍)
                               3584 × 64 =         229,376
                                       ──────────
                    每 token 的 FFN 激活 = 440,634,880   ← 表里"FFN 激活/层"那一行

上面那个"共享专家自己的开关"是什么↑ 目录

它是一个独立的、只有一列的小线性层 W_sg,形状 [3584, 1],无 bias,所以参数量正好是 3,584 个。 它给每个 token 算出一个标量,经 sigmoid 压到 (0, 1), 再用这个标量整体缩放共享专家的输出:

  y_shared = SharedExpert(x)              [3584]   共享专家算出来的向量
  g        = sigmoid(x @ W_sg)            标量     范围 (0, 1)
  y_shared = g · y_shared                 [3584]   整条向量同乘一个数

  out = Σ wᵢ · Expert_idx[i](x)  +  y_shared
        └── 路由部分,权重来自 router ──┘     └ 共享部分,幅度由 g 控制

它是共享专家的"音量旋钮": 模型逐 token 决定,这个 token 多依赖通用能力,还是多依赖被选中的那 8 个专家。 g 靠近 1 就是"多听共享专家的",靠近 0 就是"几乎只听路由专家的"。

⚠️ 一个 MoE 层里有三样东西都叫"门",别混↑ 目录

  激活宽度   20480 + 20480 = 40960   ÷ 18944 = 2.16×   ← FFN 激活/层
  全量宽度   2560×64 + 20480 = 184320  ÷ 18944 = 9.73×   ← FFN 块合计/层

10.2路由这一步在算什么↑ 目录

# 输入:一个 token 的隐藏向量 x,形状 [3584]

logits  = x @ W_router          [3584] @ [3584, 64] → [64]
probs   = softmax(logits)                            → [64]  和为 1
idx, w  = topk(probs, k=8)                           → 8 个专家 id + 8 个权重

# Qwen2 的 norm_topk_prob = false → 直接用原始的 8 个概率当权重(和 < 1)
# Qwen3 的 norm_topk_prob = true  → 把这 8 个重新归一化成和为 1

y = Σ  wᵢ · Expert_idx[i](x)        i = 1..8
  + SharedExpert(x) · sigmoid(x @ W_sg)   ← Qwen2 特有

# 每个 Expert 内部就是上一节那个 SwiGLU,只是 ffn 从 18944 缩到 2560:
#   gate = x @ Wg[3584,2560] ;  up = x @ Wu[3584,2560]
#   h    = SiLU(gate) ⊙ up
#   out  = h @ Wd[2560,3584]

那个 Σ 和 + 号:9 路结果就是简单按位相加↑ 目录

式子里的求和就是逐元素加法:不拼接,不再过融合矩阵,也不重新归一化。 展开写:

  E₁(x) · w₁      [3584]
  E₂(x) · w₂      [3584]
     ...
  E₈(x) · w₈      [3584]
━━━━━━━━━━━━━━━━━━━━━━━━━  逐位相加(8 路)
  routed          [3584]
  shared · g      [3584]
━━━━━━━━━━━━━━━━━━━━━━━━━  再逐位相加一次
  y               [3584]   ← MoE 块的输出

# 也就是 9 个 [3584] 向量的一次线性组合,系数是 w₁..w₈ 和 g。

  x = x + Attention(RMSNorm(x))
  x = x + MoE(RMSNorm(x))
          └─ 这里面已经是 8 路由 + 1 共享 的和了

10.3参数账:57.41 B 总量,14.25 B 激活↑ 目录

两个总数精确对上了模型名里的 57B 和 A14B(A 指 activated)。 稀疏率 14.25 / 57.41 = 24.8%, 即每个 token 只用到全模型四分之一的参数。

10.4⚠️ 工程上最容易踩的坑:激活量只在 batch=1 时成立↑ 目录

"只激活 14B 参数"对单个 token成立。 但服务端按批处理:batch 里不同的 token 会路由到不同的专家, 并集越大,要读进来的专家权重就越多。

10.5另外两件必须知道的事↑ 目录

• 全部专家都必须常驻显存。 不能只加载 8 个,因为下一个 token 可能路由到另外 8 个。 所以 57.41 B × 2 B = 114.8 GB 的权重一个字节都省不掉, 单张 4090 装不下。MoE 省的是算力和带宽,不是容量。
• 负载不均会直接变成延迟长尾。 真实路由不会完全均匀。 某个专家被大量 token 选中时,那一步要等它算完。 多卡部署时,专家分散在不同卡上(expert parallelism), 负载不均还会变成卡间等待。这是 MoE 服务最主要的工程难点。

10.6Qwen3 那一代把设计改了什么↑ 目录

11换个模型怎么套↑ 目录

拿到 config.json,用下面两个公式就能算出权重体积和 KV Cache 单价:

d  = hidden_size          L  = num_hidden_layers
h  = num_attention_heads  kv = num_key_value_heads
f  = intermediate_size    V  = vocab_size
hd = d / h                                    ← head_dim

参数量
  attn/层  = d·d  +  2·d·(kv·hd)  +  d·d          Qwen2.5-7B → 29,360,128
  qkv bias = d + 2·(kv·hd)                                 →       4,608   Qwen2/2.5 有,多数模型没有
  mlp /层  = 3·d·f            (SwiGLU;传统 FFN 是 2·d·f)  → 203,685,888
  norm/层  = 2·d                                          →       7,168
  ──────────────────────────────────────────────────────────────────────
  总       = L·(attn + bias + mlp + norm) + (1 或 2)·V·d + d → 7,615,616,512
                                     ↑ tie_word_embeddings 决定 1 还是 2

  权重体积 = 参数量 × dtype_bytes    fp16=2  fp8=1  int4≈0.5

KV Cache
  每 token = 2 · L · kv · hd · dtype_bytes         → 57,344 B = 56 KiB
  可容纳   = KV池字节数 ÷ 每token字节数            → 本机实测 86,896 token
             ↑ KV 池大小从启动日志读,不要手算(手算会高估约 50%)

压测前先算出这两个数当基准。实测吞吐接近 带宽 ÷ 每步读取字节,说明硬件已打满; 实测并发接近 KV 池 ÷ 每 token,说明该调 --max-num-seqs 或换量化了。

单流上限 = 1008 GB/s ÷ 14.14 GB = 71.3 tok/s
           而不是 1008 ÷ 15.23 = 66.2

实测反证:C=1 实测 61.9 tok/s
  按 15.23 GB 反推 → 943 GB/s   超过实测的 887 GB/s,不可能
  按 14.14 GB 反推 → 875 GB/s   与实测差 1.3% ✓

11.1如果 config 里有 num_experts,再套这三条↑ 目录

e  = num_experts          k  = num_experts_per_tok
mf = moe_intermediate_size          sf = shared_expert_intermediate_size(没有就当 0)

MoE 块/层
  router   = d·e
  专家全量 = e·3·d·mf
  共享     = 3·d·sf + d          (有共享专家才算,末尾的 d 是它的门)
  ────────────────────────────────────────────────
  参数     = d·e + e·3·d·mf + 3·d·sf + d
  激活     = d·e + k·3·d·mf + 3·d·sf + d

FLOPs/token = 2 × 激活参数量        ← 与 batch 无关,恒定

一个解码步真正要读的权重(batch = B,均匀路由假设)
  触及专家数 ≈ e · (1 − (1 − k/e)^B)
  权重字节   ≈ (常驻部分 + 触及专家) × dtype_bytes
             B 大到 e·(1−(1−k/e)^B) → e 时,访存优势归零

KV Cache    与 MoE 【完全无关】,仍是 2·L·kv·hd·dtype_bytes