GLM-5.2 推理数据流——70 亿行代码里发生了什么？
·
副标题： GLM-5.2（744B / 40B 激活）已 MIT 开源。当你给这个模型发一个 token，它在 GPU 上经历了哪些算子、占了多大显存、需要多少算力和带宽？本文从 config.json 出发，逐层拆解 GLM-5.2 的推理数据流。
一、一张图看懂 GLM-5.2
GLM-5.2 是智谱 AI 于 2026 年 6 月发布的 MoE 模型，MIT 协议开源，权重在 HuggingFace 可下载。
核心配置
架构： GlmMoeDsaForCausalLM（MoE + DeepSeek Sparse Attention）
层数： 78 层（前 3 层 Dense MLP + 后 75 层 MoE）
隐藏维度： hidden_size = 6144
总参数量： ~744B（FP8 权重 ~744GB）
激活参数量： ~40B / token
上下文： 1,048,576 tokens
开源协议： MIT（HuggingFace: zai-org/GLM-5.2）
config.json 关键参数
| 参数 | 值 | 含义 |
|---|---|---|
num_hidden_layers |
78 | 总层数 |
first_k_dense_replace |
3 | 前 3 层为 Dense MLP |
hidden_size |
6144 | 隐藏层维度 |
intermediate_size |
12288 | Dense FFN 中间维度 |
num_attention_heads |
64 | 注意力头数 |
num_key_value_heads |
64 | KV 头数（全量，非 GQA） |
q_lora_rank |
2048 | Q 低秩压缩维度 |
kv_lora_rank |
512 | KV 低秩压缩维度 |
head_dim |
192 (+64 RoPE) = 256 | 每头维度 |
n_routed_experts |
256 | 路由专家数 |
n_shared_experts |
1 | 共享专家数 |
num_experts_per_tok |
8 | 每 token 激活专家数 |
moe_intermediate_size |
2048 | 专家 FFN 中间维度 |
index_n_heads |
32 | 稀疏注意力索引头数 |
index_head_dim |
128 | 索引头维度 |
index_topk |
2048 | 稀疏注意力 top-k |
二、三个关键组件
2.1 MLA（Multi-head Latent Attention）
MLA 不是标准 MHA，它对 Q 和 KV 做了低秩压缩：
标准 MHA: Q/K/V 各投影到 64 × 256 = 16384 维
MLA: Q 先降到 2048 维（q_lora_rank），再展开到 64 × 256
KV 先降到 512 维（kv_lora_rank），再展开到 64 × 256
这意味着 KV Cache 大幅缩小：
- 标准 MHA 下每层 KV Cache = 2 × 64 × 256 × seq_len
- MLA 下每层 KV Cache = 2 × 512 × seq_len（只存压缩后的 latent）
- 压缩比 = (2 × 64 × 256) / (2 × 512) = 16 倍
2.2 DSA（DeepSeek Sparse Attention）+ IndexShare
GLM-5.2 不用 dense attention 处理 1M 上下文——它用稀疏注意力。
每个 token 不是 attend 到所有前面的 token，而是只 attend top-2048 个位置：
1M 上下文 → 标准 attention: O(n²) ≈ 10¹² 次操作
1M 上下文 → DSA: O(n × k) ≈ 2 × 10⁹ 次操作（k=2048）
IndexShare 是 GLM-5.2 进一步优化的关键——不是每层都重新计算 attention 的位置索引。78 层中只有 21 层有完整的 indexer，其余 57 层共享最近一个全量 indexer 的结果。
Indexer 分布模式：
第 0-2 层： 全量 indexer（3层）
第 3-5 层： 共享 indexer
第 6 层： 全量 indexer
第 7-9 层： 共享 indexer
第 10 层： 全量 indexer
... （每 4 层一个全量，其余 3 层共享）
这个模式将稀疏注意力的计算量再降低 2.9 倍（1M 上下文下）。
2.3 MoE FFN：256 专家 + 1 共享专家
GLM-5.2 的 FFN 部分（75 层）使用 MoE：
- 256 个路由专家：每个 token 通过 Router 选择 top-8
- 1 个共享专家：始终激活
- 每层共 9 个专家被激活（8 路由 + 1 共享）
每个专家内部是 SwiGLU 结构：
输入(6144) → Gate(→2048) → SiLU → ×
→ Up(→2048) → → Down(→6144) → 输出
前 3 层（Dense MLP）则使用更大的 intermediate_size=12288：
输入(6144) → Gate(→12288) → SiLU → ×
→ Up(→12288) → → Down(→6144) → 输出
三、推理数据流：逐层追踪一个 token
这是博客的核心。一个 token 在 GLM-5.2 中经历的完整算子链。
Stage 0：Embedding
算子： Embedding lookup
输入： token_id（整数）
输出： 6144 维向量
计算量： 忽略（查表）
参数量： vocab_size × hidden_size = 154880 × 6144 ≈ 0.95B
Stage 1-3：Dense 层（前 3 层）
每层包含：
Step 1: LayerNorm → 输入归一化
compute: 6144 个元素 → 计算量可忽略
Step 2: MLA Q 投影
输入(6144) × W_Q(6144→2048) → Q_latent(2048)
计算量: 6144 × 2048 = 12.6M MACs
Step 3: MLA KV 投影 + RoPE
输入(6144) × W_KV(6144→512) → KV_latent(512)
计算量: 6144 × 512 = 3.1M MACs
+ RoPE 旋转（qk_rope_head_dim = 64 部分的旋转）
Step 4: Attention（DSA 模式）
- 如果是全量 indexer 层：计算 indexer，选择 top-2048 位置
- 如果是共享 indexer 层：复用上层的索引
- 计算 attention scores: Q(2048) × K(2048×256) → scores(2048)
- Softmax → V 加权求和
计算量：O(seq_len × k)，k=2048
Step 5: MLA 输出投影
Attention 输出(2048) × W_O(2048→6144)
计算量: 2048 × 6144 = 12.6M MACs
Step 6: Dense FFN（SwiGLU）
输入(6144) × W_gate(6144→12288) → gate 分支
输入(6144) × W_up(6144→12288) → up 分支
gate = SiLU(gate)
hidden = gate × up → (12288)
hidden × W_down(12288→6144) → 输出
计算量: 3 × 6144 × 12288 = 226M MACs
Step 7: 残差连接 + LayerNorm
output = input + ffn_output
Stage 4-78：MoE 层（第 4-78 层，共 75 层）
与 Dense 层的前 5 步相同（MLA + DSA），但 Step 6 替换为 MoE FFN：
Step 6 (MoE): MoE FFN
子步骤 6a: Router（门控网络）
输入(6144) × W_gate(6144→256) → logits(256)
Top-8 选择（取 logits 最高的 8 个 expert）
计算量: 6144 × 256 = 1.6M MACs（可忽略）
子步骤 6b: 8 个路由专家（并行）
每个专家：
输入(6144) × W_gate(6144→2048) → gate分支
输入(6144) × W_up(6144→2048) → up分支
gate = SiLU(gate)
hidden = gate × up → (2048)
hidden × W_down(2048→6144) → 输出(6144)
专家输出 × Router 权重 加权求和
每个专家计算量: 3 × 6144 × 2048 = 37.7M MACs
8 个专家总计: 37.7M × 8 = 302M MACs
子步骤 6c: 共享专家（始终激活）
同 8 个路由专家一样结构（intermediate=2048）
计算量: 37.7M MACs（和单个路由专家一样）
子步骤 6d: 合并
输出 = sum(路由专家输出) + 共享专家输出
MoE 层 vs Dense 层计算量对比
| 阶段 | Dense 前 3 层 | MoE 后 75 层 |
|---|---|---|
| MLA（Steps 1-5） | ~28M MACs | ~28M MACs（相同） |
| FFN（Step 6） | 226M MACs | ~340M MACs（9 个 expert） |
| 总计 / 层 | ~254M MACs | ~368M MACs |
关键发现： 单个 MoE 层的计算量反而比 Dense 层大（因为 9 个 expert 合计的 intermediate_size 是 9×2048=18432，超过了 Dense 的 12288）。MoE 的"省钱"不在于单层计算量少，而在于总参数量虽然大但只激活一小部分。
Stage 79：MTP（Multi-Token Prediction）Head
一个额外的预测头，用于推测解码（speculative decoding）：
输入(6144) × W_mtp → 预测下一个 token 的隐藏状态
Stage N：LM Head
输出(6144) × lm_head(6144→154880) → logits(154880)
计算量: 6144 × 154880 = 951M MACs（这是单 token 推理中最大的矩阵乘！）
四、算力评估
Prefill 阶段（计算密集）
Prefill 处理的是用户的 prompt（一次处理 N 个 token）。
每 token 的计算量（以 FP8 估算，乘法累加计为 2 FLOPs/MAC）：
| 组件 | MACs / token | FLOPs / token |
|---|---|---|
| Embedding | 忽略 | 忽略 |
| 3 × Dense Layer（MLA + FFN） | 3 × 254M = 762M | 1.5 GFLOPS |
| 75 × MoE Layer（MLA + MoE FFN） | 75 × 368M = 27.6B | 55.2 GFLOPS |
| LM Head | 951M | 1.9 GFLOPS |
| 总计 / token | ~29.3B MACs | ~58.6 GFLOPS |
对于 1K 的 prompt：
- 总计算量 ≈ 58.6 TFLOPs
- 在 H100（FP8 TFLOPS ≈ 3958）上：约 15ms 纯计算时间
- 但由于注意力是 O(n²)（即使是 DSA，也是 O(n×k)），实际 prefill 时间受 KV Cache 读写的带宽影响
Decode 阶段（带宽密集）
Decode 每次生成 1 个 token。瓶颈不在计算，在从 HBM 加载权重。
首先，MLA 的权重远不止「一两个投影」——它包含 6 个投影矩阵（W_dq, W_uq, W_dkv, W_uk, W_uv, W_kr）外加一个 W_o：
每层 MLA 权重拆解（隐藏层 6144 → 多头 64×256=16384）:
W_dq: 6144 × 2048 = 12.6M
W_uq: 2048 × 16384 = 33.6M
W_dkv: 6144 × 512 = 3.1M
W_uk: 512 × 12288 (64×192) = 6.3M
W_uv: 512 × 16384 (64×256) = 8.4M
W_kr: 6144 × 4096 (64×64) = 25.2M
W_o: 16384 × 6144 = 100.7M
──────────────────────────────────
每层 MLA 总计 ≈ 190M
有了这个基准，再来算完整的激活参数量（每 token 需要加载的权重）：
| 组件 | 计算过程 | 参数量 |
|---|---|---|
| 75 × MoE 层（MLA） | 75 × 190M | 14.25B |
| 75 × MoE FFN（9 experts: 8路由+1共享） | 75 × 9 × 3 × (6144×2048) | 25.4B |
| 75 × MoE Router | 75 × (6144×256) | 0.12B |
| 3 × Dense 层（MLA） | 3 × 190M | 0.57B |
| 3 × Dense FFN | 3 × 3 × (6144×12288) | 0.68B |
| LM Head | 6144 × 154880 | 0.95B |
| Embedding（通常权值共享，不重复计算） | — | — |
| 总计（FP8 ≈ 1 byte/param） | ~42B ≈ 42GB |
去掉一些零头（LayerNorm、bias 等），恰好就是 ~40B 激活参数，~40GB 加载量。之前我漏算了 MLA 的绝大部分权重——W_dq/W_uq/W_dkv/W_uk/W_uv/W_kr/W_o 合计 ~190M/层，而不是 ~25M。修正后就和 40B 对上了。
不同 GPU 的解码延迟估算：
| GPU | 带宽 | 40GB 加载时间 | 理论 tok/s |
|---|---|---|---|
| A100 80GB | 2.0 TB/s | ~20.0 ms | ~50 tok/s |
| H100 80GB | 3.35 TB/s | ~11.9 ms | ~84 tok/s |
| H200 141GB | 4.8 TB/s | ~8.3 ms | ~120 tok/s |
| B200 192GB | 8.0 TB/s | ~5.0 ms | ~200 tok/s |
这与实测数据基本吻合：API 上 GLM-5.2 输出速度约 99 tok/s（非推理模式），接近 H100 的理论上限。
KV Cache 占用
MLA 的 KV Cache 比标准 MHA 小得多：
每层 KV Cache Size = 2 × kv_lora_rank × seq_len × dtype_bytes
= 2 × 512 × seq_len × 1 (FP8)
= 1024 × seq_len bytes
上下文长度 KV Cache（MLA） 对比标准 MHA
128K ~131 MB ~2.1 GB（16x）
512K ~524 MB ~8.4 GB
1M ~1.05 GB ~16.8 GB
全 78 层总计：
128K ~10.2 GB ~164 GB
1M ~82 GB ~1.3 TB
这就是为什么 GLM-5.2 能支持 1M 上下文——MLA 把 KV Cache 压缩到了可管理的范围。
五、完整推理显存占用
对于一个使用 FP8 权重的 GLM-5.2 推理部署：
| 项目 | 128K 上下文 | 1M 上下文 |
|---|---|---|
| 权重（FP8） | ~744 GB | ~744 GB |
| KV Cache | ~10 GB | ~82 GB |
| 激活值（估算） | ~5 GB | ~10 GB |
| 其他（CUDA context 等） | ~5 GB | ~5 GB |
| 总计 | ~764 GB | ~841 GB |
硬件需求：
- 最低配置（128K 上下文）：8 × H100 80GB（可用 640GB，加上 CPU offload）
- 推荐配置（1M 上下文）：8 × H200 141GB（可用 1128GB，充裕）
- 最佳配置：8 × B200 192GB（可用 1536GB，可批量推理）
六、总结
关键数据回顾
| 维度 | 数据 |
|---|---|
| 激活参数量 | ~40B / token |
| Prefill 计算量 | ~58.6 GFLOPS / token |
| Decode 带宽需求 | ~40GB / token（权重加载） |
| KV Cache（1M 上下文） | ~82 GB（MLA 压缩 16 倍） |
| 推理瓶颈 | 解码：带宽密集；预填充：计算密集 |
| 推荐硬件 | 8 × H200 或 8 × B200 |
GLM-5.2 推理架构的独特之处
- MLA + DSA + IndexShare 三层减负：MLA 把 KV Cache 压到 1/16，DSA 把 attention 从 O(n²) 降到 O(nk)，IndexShare 再省 2.9 倍计算
- 前 3 层 Dense + 后 75 层 MoE 的混合设计：前 3 层用大 FFN（intermediate=12288）做通用特征提取，后 75 层用 256 专家分工
- SwiGLU + Top-8 + 共享专家的三重 FFN 结构：每个 token 实际经过 9 个专家的计算
对部署者的启示
- MoE decode 的本质是内存带宽游戏——激活参数量只影响加载量，不影响总参存储。40GB 的权重加载决定了单卡 decode 的上限
- 量化是第一步：BF16（1.5TB）→ FP8（~750GB）→ INT4（~370GB），每降一档都是 HBM 需求的减半
- 批量推理放大 KV Cache 压力：batching 下 KV Cache 线性增长，1M 上下文 + batch=8 时 KV Cache 需要 656GB——这解释了为什么长上下文模型通常用小 batch
数据来源：HuggingFace config.json（zai-org/GLM-5.2）、NVIDIA NeMo AutoModel docs、GLM-5.2 0.8B 参考实现、Vultr 部署文档
更多推荐
5
0- 0
已为社区贡献12条内容
所有评论(0)