拆解gpt-oss-20b-BF16-w4a16-llmcompressor的MoE架构：24层×32专家与滑动窗口注意力如何工作

本文带你从零看懂 gpt-oss-20b-BF16-w4a16-llmcompressor 的 MoE（Mixture of Experts，混合专家）架构：24 层 Transformer、每层 32 个专家、每 token 只激活 4 个专家，以及"滑动窗口 + 全注意力"交替的注意力设计如何兼顾速度与长上下文。该仓库是 AMD 用 LLM Compressor 对 gpt-oss-20b 做W4A16 四比特权重量化后的 CPU 推理版本，面向新手，不涉及复杂代码。

📦 项目速览：仓库里到底有什么？

这个仓库本质上是一个量化后的模型权重包，所有架构秘密都藏在配置文件里：

一句话概括：总参数约 210 亿（20B+），每个 token 只激活约 36 亿参数，量化后从 39 GiB 压到 12 GiB，可在 AMD EPYC CPU 上跑推理——这就是它"又大又省"的核心卖点。

🧩 MoE 架构拆解：24 层 × 32 专家如何分工

路由（Router）：每个 token 只选 4 个专家

在 config.json 中，这几个字段定义了 MoE 的骨架：

• num_hidden_layers: 24—— 模型共24 层
• num_local_experts: 32—— 每层内置32 个专家（每个专家是一个独立的 FFN 前馈网络）
• experts_per_token: 4—— 每个 token 只被路由到4 个专家（top-4 路由）

工作原理可以想象成一个"分诊台"：每个 token 经过一层时，该层有一个路由器（mlp.router，一个 2880→32 的小线性层）给它打分，只挑分数最高的 4 个专家处理这个 token。也就是说：

每层 32 个专家，每个 token 只用其中 12.5%（4/32），其余 28 个专家"休息"。

整个模型因此拥有24 × 32 = 768 个专家 FFN。每个专家的三个投影（gate_proj / up_proj / down_proj）宽度都是 2880（对应hidden_size: 2880与intermediate_size: 2880），单个专家约 2488 万参数。

参数规模：210 亿总参数，36 亿激活

• 总参数 ≈ 209 亿：仅专家部分就约 191 亿，加上注意力、词嵌入（vocab_size: 201088，接近 20 万的超大词表）和输出头
• 激活参数 ≈ 36 亿：每 token 每层走 4 个专家（96 个专家 × 2488 万 ≈ 23.9 亿），加上 24 层注意力

MoE 的关键价值：用接近 20B 大模型的"知识容量"，换取接近 3.6B 小模型的推理速度。专家越多，模型见过的模式越多样，但每个 token 的计算量几乎不变。

🪟 滑动窗口注意力：128 token 窗口与全注意力交替

24 层的"隔层交替"设计

打开 config.json 的layer_types数组，你会看到一个非常规律的排列：

sliding_attention → full_attention → sliding_attention → full_attention → …

• 12 层滑动注意力（第 0、2、4 … 22 层）：只看最近 128 个 token（sliding_window: 128）
• 12 层全注意力（第 1、3、5 … 23 层）：看整个上下文，最长 128K token

这种交替设计的逻辑很直白：

为什么更快？注意力计算量随上下文长度平方增长。全注意力层只有 12 层（占一半），另一半层被"128 token 窗口"截断——当上下文拉长到几万 token 时，这 12 个滑动层的成本依然恒定，整体注意力开销大幅下降，而长程信息仍由另外 12 个全注意力层负责，质量基本不牺牲。

128K 长上下文：YaRN 位置编码外推

gpt-oss 训练时的原始上下文只有 4096（initial_context_length: 4096），却能跑131072（128K）token的长文本。秘诀在rope_parameters字段：

• rope_type: "yarn"—— 使用YaRN（一种 RoPE 位置编码的插值外推方案）
• factor: 32—— 位置编码外推 32 倍：4096 × 32 = 131072
• rope_theta: 150000—— 提高旋转频率上限，缓解外推后的"位置模糊"

配合注意力中保留的sinks（attention sink 向量，在量化配置中被明确排除在量化之外），模型在超长上下文下也能保持 KV cache 稳定——这是 gpt-oss 系列支持长文输入的关键机制之一。

另外，注意力头配置为64 个 Q 头 + 8 个 KV 头（num_key_value_heads: 8），即GQA（分组查询注意力）8:1，进一步压缩 KV cache 内存——对 CPU 推理场景尤其重要，因为内存带宽往往是瓶颈。

⚡ W4A16 量化：39 GiB 压到 12 GiB

这个仓库名字里的w4a16就是量化方案：权重 4-bit（W4）、激活 16-bit BF16（A16）。在 config.json 的quantization_config与 recipe.yaml 中可以看到细节：

• 方法：GPTQ 算法（由 LLM Compressor 执行，quant_method: "compressed-tensors"）
• 精度：INT4、对称量化、group_size = 64（每 64 个权重共享一组缩放因子）
• 为什么不是 W4A16 预设默认的 128？因为 gpt-oss 层宽 2880 不能被 128 整除，只能显式指定 64
• 校准数据：128 条 ultrachat 200k 样本，最长 2048 token，用于补偿舍入误差

哪些参数被量化、哪些被保护？量化器量化了 24 层全部 32 个专家（共 1536 个融合专家张量）和所有注意力投影，但刻意保留 BF16 的包括：

• 每层的MoE 路由器（mlp.router）—— 它是"选专家"的决策者，4-bit 舍入误差可能翻转 top-4 选择，直接改变模型行为，所以绝不量化
• 词嵌入、输出头lm_head、LayerNorm、注意力 sinks 和所有 bias

效果：磁盘占用从 39.0 GiB 降到12.0 GiB（约减少 69%），一台 16GB 内存的 EPYC 机器也能装下整个模型。

🚀 快速跑起来：CPU 推理环境搭建

按 README.md 的要求，这套模型专为AMD EPYC CPU 推理优化（通过 ZenDNN / ZenTorch），不面向 GPU：

1. 安装依赖（版本是锁定组合，混用版本可能加载失败）：torch==2.13.0.0、zentorch==2.13.0.0、vllm==0.28.0、llmcompressor==0.13.0
2. 设置 OpenMP：启动前用LD_PRELOAD指定libomp.so或libiomp5.so，让多线程算子正确分发
3. 用 vLLM 加载：以dtype="bfloat16"加载本仓库模型，12 GiB 权重即可开始生成

如果需要把 fuse_for_vllm.py 重排专家张量布局，其用法是python fuse_for_vllm.py SRC_DIR DST_DIR——它会把每个专家的 gate/up 投影拼接成w13融合张量，适配 vLLM 的流式专家加载路径（仅限 TP=1）。

📊 量化后精度如何：GSM8K 98.88% 恢复率

按 README.md 的评测（lm-evaluation-harness + vLLM），与 BF16 原版基线对比：

代价约 1 个百分点的 GSM8K 精度，换来 69% 的内存压缩——GPTQ 的校准补偿让 4-bit 的精度损失控制得很好，对日常对话、文本生成类任务几乎无感。

📁 总结：架构一图流

最后用一张表把 gpt-oss-20b 的核心设计收束起来（字段均出自 config.json）：

给新手的三句话总结：

1. gpt-oss-20b 的 MoE 本质是"24 层 × 32 专家，每 token 只挑 4 个"——容量像 20B，速度像 3.6B
2. 注意力"隔层滑动窗口（128）+ 全注意力"交替，是它在 CPU 上跑得动的关键之一
3. W4A16 量化把内存砍掉 69%，路由器等敏感部分精确保留 BF16，精度只损失约 1%

想动手验证？直接加载本仓库权重，跑一句"Hello, how are you?"试试它的长文本与推理能力吧。