1. 为什么值得花时间读懂 Qwen3 的 MoE 结构Qwen3 系列里真正让工程同学纠结的往往不是 Dense 版本而是那两个 MoE 模型Qwen3-235B-A22B 和 Qwen3-30B-A3B。名字里的 A22B、A3B 指的是激活参数不是总参数。也就是说30B-A3B 这个模型总参数约 300 亿但每个 token 实际只走 30 亿左右的参数。这个机制决定了它的显存占用、推理速度和微调策略跟同尺寸 Dense 模型完全不是一回事。如果你只是拿AutoModelForCausalLM.from_pretrained()加载然后generate()确实能跑起来。但一旦你要做下面这些事就必须把结构拆开看微调时想只训练路由网络或部分专家得知道gate和experts挂在哪一层部署时想估算显存得知道num_experts、num_experts_per_tok、moe_intermediate_size怎么影响权重体积排查输出异常时要确认专家路由是否真的按预期激活而不是所有 token 都挤到同一个专家想改注意力窗口或位置编码得先搞清楚Qwen3MoeDecoderLayer里各子模块的调用顺序。这篇就按「先看 config 字段 → 再逐层打印 → 最后验证路由和注意力形状」的顺序走一遍。所有代码都可以直接复制运行模型用小的 Qwen3-30B-A3B 或 4B 版本做演示都行结构逻辑一致。需要说明的是Qwen3 的 MoE 实现和 DeepSeekMoE 有两个明显差异一是没有 shared expert二是 MLP 结构做了调整封装成Qwen3MoeSparseMoeBlock。这两点后面会结合代码细说。2. 前置准备环境、模型文件与 TaoToken 接入在拆结构之前先把运行环境搭好。我用的组合是 Python 3.10 torch 2.3.0 transformers 4.55.0这个版本已经包含qwen3_moe的建模代码。如果你本地 transformers 低于 4.51Qwen3MoeConfig可能还不存在先升级pip3 install -U transformers4.55.0 pip3 install accelerate safetensors模型文件可以从 Hugging Face 或 ModelScope 拉取。以 Qwen3-30B-A3B 为例下载后目录里会有config.json、model.safetensors.index.json和多个分片权重。这里不展开下载命令重点放在结构解析上。如果你本地显存不够或者想先用 API 方式验证 Qwen3 的行为再决定要不要下载全量权重可以走 TaoToken 的模型对话入口。它的 Base URL 是https://taotoken.net/api兼容 OpenAI 风格的/v1/chat/completions。先拿一个 Key到 https://taotoken.net/api-keys 创建一个 API Key复制出来备用。然后可以用一行 curl 验证 Qwen3 是否可用curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: Qwen3-30B-A3B, messages: [{role: user, content: 用一句话解释 MoE 路由}] }返回里能看到choices[0].message.content就说明链路通了。这一步的意义在于你可以先用 API 快速验证 prompt 和输出格式再决定本地加载哪个尺寸的模型做结构分析。模型对话入口在 https://taotoken.net/model-chat 接入文档在 https://taotoken.net/doc 里面有完整的参数说明。本地加载时device_mapauto会自动把不同层分配到可用设备。MoE 模型的专家层权重很大如果显存吃紧可以用load_in_4bit或load_in_8bit量化加载但量化后打印形状不受影响结构解析照样能做。3. 可复制配置config.json 关键字段逐项对照Qwen3 MoE 的行为几乎全部由config.json决定。下面这张表是我从 Qwen3-30B-A3B 的配置文件里整理出来的核心字段每个都标注了它对结构的影响。字段名示例值作用影响的结构model_typeqwen3_moe告诉 transformers 用哪套建模代码决定加载modeling_qwen3_moe.pyhidden_size2048隐藏层维度embed、attention、MLP 的输入输出宽度num_hidden_layers48解码器层数self.layers的长度num_attention_heads32注意力头数Q/K/V 投影后的头维度 hidden_size / headsnum_key_value_heads4KV 头数GQAKV cache 体积比 MHA 小很多head_dim128每个头的维度注意力分数矩阵形状num_experts128专家总数self.experts的长度num_experts_per_tok8每 token 激活专家数top-k 的 k 值moe_intermediate_size768单个专家的中间维度每个专家 MLP 的参数量shared_expert_intermediate_size0共享专家维度Qwen3 MoE 为 0即无共享专家norm_topk_probtrue是否归一化 top-k 权重影响路由权重计算router_aux_loss_coef0.001路由辅助损失系数训练时专家负载均衡max_position_embeddings40960最大位置数RoPE 缓存长度rope_theta1000000RoPE 基频长上下文外推能力rms_norm_eps1e-6RMSNorm 数值稳定项每层归一化sliding_windownull滑动窗口大小为 null 时用标准因果掩码tie_word_embeddingsfalse是否共享输入输出嵌入影响 embed_tokens 和 lm_head几个容易踩坑的点num_experts_per_tok是 8不是 2。这意味着每个 token 会同时走 8 个专家计算量比只走 1 个专家大但比走全部 128 个小得多。这也是 A3B 里「3B 激活」的来源。shared_expert_intermediate_size为 0说明 Qwen3 MoE 没有 DeepSeek 那种「共享专家 路由专家」的双轨设计。所有专家都是路由专家靠 gate 动态选择。norm_topk_prob为 true 时top-k 权重会再做一次归一化保证加权和稳定。如果你自己改路由逻辑这个字段要留意。sliding_window为 null所以Qwen3MoeModel.forward里走的是create_causal_mask不是滑动窗口掩码。如果你要改成长上下文优化这里可以设成具体窗口值。把这份 config 存成config.json后面打印脚本会直接读它。4. 逐层打印脚本验证专家路由与注意力形状光看 config 还不够得实际加载模型把每一层的形状打出来确认和预期一致。下面这个脚本会做三件事加载模型、打印顶层结构、逐层检查 attention 和 MoE 的形状。import torch from transformers import AutoModelForCausalLM, AutoTokenizer, AutoConfig model_path ./Qwen3-30B-A3B # 换成你的本地路径 config AutoConfig.from_pretrained(model_path) print(model_type:, config.model_type) print(num_hidden_layers:, config.num_hidden_layers) print(num_experts:, config.num_experts) print(num_experts_per_tok:, config.num_experts_per_tok) print(moe_intermediate_size:, config.moe_intermediate_size) model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypeauto, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(model_path) # 打印顶层模块 print(\n 顶层结构 ) for name, module in model.named_children(): print(name, type(module).__name__) # 打印第 0 层解码器的子模块 layer0 model.model.layers[0] print(\n DecoderLayer 0 子模块 ) for name, module in layer0.named_children(): print(name, type(module).__name__) # 检查 attention 形状 attn layer0.self_attn print(\n Attention 形状 ) print(q_proj:, attn.q_proj.weight.shape) print(k_proj:, attn.k_proj.weight.shape) print(v_proj:, attn.v_proj.weight.shape) print(o_proj:, attn.o_proj.weight.shape) print(num_heads:, attn.num_heads) print(num_key_value_heads:, attn.num_key_value_heads) print(head_dim:, attn.head_dim) # 检查 MoE 块 moe layer0.mlp print(\n MoE 块 ) print(gate:, moe.gate.weight.shape) print(num_experts:, len(moe.experts)) print(expert0 gate_proj:, moe.experts[0].gate_proj.weight.shape) print(expert0 up_proj:, moe.experts[0].up_proj.weight.shape) print(expert0 down_proj:, moe.experts[0].down_proj.weight.shape)跑完之后你应该看到类似这样的输出 Attention 形状 q_proj: torch.Size([4096, 2048]) k_proj: torch.Size([512, 2048]) v_proj: torch.Size([512, 2048]) o_proj: torch.Size([2048, 4096]) num_heads: 32 num_key_value_heads: 4 head_dim: 128 MoE 块 gate: torch.Size([128, 2048]) num_experts: 128 expert0 gate_proj: torch.Size([768, 2048]) expert0 up_proj: torch.Size([768, 2048]) expert0 down_proj: torch.Size([2048, 768])这里有几个验证点q_proj输出是 4096因为 32 个头 × 128 维 4096。k_proj和v_proj只有 512因为 4 个 KV 头 × 128 512。这就是 GQA 的效果KV cache 比 MHA 小 8 倍。gate的形状是[128, 2048]输入 hidden_size 2048输出 128 个专家的 logits。这个线性层没有 bias和代码里nn.Linear(self.hidden_size, self.num_experts, biasFalse)一致。每个专家的gate_proj是[768, 2048]对应moe_intermediate_size768。三个投影加起来单个专家参数量约 768×2048×3 ≈ 470 万128 个专家就是 6 亿左右再加上 attention 和其他层总参数到 300 亿量级。接下来验证路由是否真的按 top-8 激活。写一个 hook 抓取 gate 输出import torch.nn.functional as F captured {} def gate_hook(module, input, output): captured[logits] output.detach() handle model.model.layers[0].mlp.gate.register_forward_hook(gate_hook) prompt 解释一下混合专家模型的路由机制 messages [{role: user, content: prompt}] text tokenizer.apply_chat_template(messages, tokenizeFalse, add_generation_promptTrue) inputs tokenizer([text], return_tensorspt).to(model.device) with torch.no_grad(): model(**inputs) handle.remove() logits captured[logits] # [batch, seq_len, num_experts] print(gate logits shape:, logits.shape) # 取最后一个 token 的 top-8 last_logits logits[0, -1] topk_weights, topk_indices torch.topk(last_logits, config.num_experts_per_tok) print(top-8 expert indices:, topk_indices.tolist()) print(top-8 raw weights:, topk_weights.tolist()) print(after softmax:, F.softmax(topk_weights, dim-1).tolist())如果topk_indices里出现了 8 个不同的专家编号且 softmax 后权重和接近 1说明路由工作正常。如果所有 token 都选同一批专家可能是权重加载有问题或者norm_topk_prob配置没生效。5. 常见报错排查401、local proxy failed、reading choices、OAuth拆结构的过程中报错基本集中在加载和请求两个环节。下面按真实遇到的顺序列出来。401 Unauthorized如果你用 API 方式验证 Qwen3返回 401 通常是 Key 没带对。检查Authorization: Bearer后面有没有多余空格Key 是否过期。TaoToken 的 Key 在 https://taotoken.net/api-keys 管理重新生成一个再试。本地加载模型不会出现这个错。local proxy failed / connection error这个报错一般出现在from_pretrained去远程拉 config 或权重时。如果你已经把模型下载到本地确保model_path指向的是包含config.json的目录而不是上一级。另外HF_HUB_OFFLINE1可以强制离线加载避免它去连网。reading choices / KeyError choices用 API 时如果返回体里没有choices字段多半是请求体格式不对。检查messages是不是数组model字段是否拼写正确。有些兼容层要求stream: false显式写出否则返回的是 SSE 流解析时会找不到choices。OAuth / token 失效如果你用 CLI 工具登录过 Hugging Face本地缓存了 token换账号后可能报 OAuth 相关错误。清掉~/.cache/huggingface/token再重新登录或者直接用local_files_onlyTrue加载本地权重。形状不匹配 / size mismatch加载权重时报某个参数形状对不上通常是你把 Dense 版的 config 和 MoE 版的权重混用了。确认model_type是qwen3_moe且num_experts和权重文件里的专家数一致。显存不足 OOMMoE 模型虽然激活参数少但总参数大加载时全部权重都要进显存。30B-A3B 用 fp16 加载大约需要 60GB 以上。可以用device_mapauto分到多卡或者用 4bit 量化。量化后gate和experts的形状不变结构分析不受影响。top-k 权重和不为 1如果打印出来 softmax 后和明显偏离 1检查norm_topk_prob是否为 true。为 false 时权重不归一化这是设计行为不是 bug。6. 从结构到落地微调与部署的下一步把结构拆清楚之后微调和部署的决策会清晰很多。微调方面如果你想省显存可以只训练gate和部分专家冻结 attention 和 embed。因为 MoE 的参数量主要集中在 experts冻结大部分专家能显著降低优化器状态占用。具体做法是遍历named_parameters()对包含experts且索引不在目标范围内的参数设requires_gradFalse。部署方面num_experts_per_tok8意味着每个 token 要过 8 个专家的 MLP计算量比 Dense 模型大。但专家是并行计算的实际延迟取决于 batch size 和专家并行策略。如果做高并发服务可以考虑把专家分布到不同设备上用 all-to-all 通信做路由分发。如果你还在选型阶段想先对比 Qwen3-30B-A3B 和 Qwen3-4B 在实际任务上的表现可以用 TaoToken 的模型对话快速跑几组 prompt不用本地下载全量权重。长期做编码或 Agent 任务的话Coding Plan 入口在 https://taotoken.net/coding-plan 里面有按量计费的说明。接入文档在 https://taotoken.net/doc API Keys 在 https://taotoken.net/api-keys 。最后留一个实用技巧打印结构时用model.named_modules()配合正则过滤可以快速定位所有 MoE 层不用一层层手点。比如[n for n, m in model.named_modules() if mlp.gate in n]能直接列出所有 gate 的路径。这个在写微调脚本时特别省事。
大模型 | QWen3 结构解析：从 MoE 路由到 transformers 配置逐层拆解
1. 为什么值得花时间读懂 Qwen3 的 MoE 结构Qwen3 系列里真正让工程同学纠结的往往不是 Dense 版本而是那两个 MoE 模型Qwen3-235B-A22B 和 Qwen3-30B-A3B。名字里的 A22B、A3B 指的是激活参数不是总参数。也就是说30B-A3B 这个模型总参数约 300 亿但每个 token 实际只走 30 亿左右的参数。这个机制决定了它的显存占用、推理速度和微调策略跟同尺寸 Dense 模型完全不是一回事。如果你只是拿AutoModelForCausalLM.from_pretrained()加载然后generate()确实能跑起来。但一旦你要做下面这些事就必须把结构拆开看微调时想只训练路由网络或部分专家得知道gate和experts挂在哪一层部署时想估算显存得知道num_experts、num_experts_per_tok、moe_intermediate_size怎么影响权重体积排查输出异常时要确认专家路由是否真的按预期激活而不是所有 token 都挤到同一个专家想改注意力窗口或位置编码得先搞清楚Qwen3MoeDecoderLayer里各子模块的调用顺序。这篇就按「先看 config 字段 → 再逐层打印 → 最后验证路由和注意力形状」的顺序走一遍。所有代码都可以直接复制运行模型用小的 Qwen3-30B-A3B 或 4B 版本做演示都行结构逻辑一致。需要说明的是Qwen3 的 MoE 实现和 DeepSeekMoE 有两个明显差异一是没有 shared expert二是 MLP 结构做了调整封装成Qwen3MoeSparseMoeBlock。这两点后面会结合代码细说。2. 前置准备环境、模型文件与 TaoToken 接入在拆结构之前先把运行环境搭好。我用的组合是 Python 3.10 torch 2.3.0 transformers 4.55.0这个版本已经包含qwen3_moe的建模代码。如果你本地 transformers 低于 4.51Qwen3MoeConfig可能还不存在先升级pip3 install -U transformers4.55.0 pip3 install accelerate safetensors模型文件可以从 Hugging Face 或 ModelScope 拉取。以 Qwen3-30B-A3B 为例下载后目录里会有config.json、model.safetensors.index.json和多个分片权重。这里不展开下载命令重点放在结构解析上。如果你本地显存不够或者想先用 API 方式验证 Qwen3 的行为再决定要不要下载全量权重可以走 TaoToken 的模型对话入口。它的 Base URL 是https://taotoken.net/api兼容 OpenAI 风格的/v1/chat/completions。先拿一个 Key到 https://taotoken.net/api-keys 创建一个 API Key复制出来备用。然后可以用一行 curl 验证 Qwen3 是否可用curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: Qwen3-30B-A3B, messages: [{role: user, content: 用一句话解释 MoE 路由}] }返回里能看到choices[0].message.content就说明链路通了。这一步的意义在于你可以先用 API 快速验证 prompt 和输出格式再决定本地加载哪个尺寸的模型做结构分析。模型对话入口在 https://taotoken.net/model-chat 接入文档在 https://taotoken.net/doc 里面有完整的参数说明。本地加载时device_mapauto会自动把不同层分配到可用设备。MoE 模型的专家层权重很大如果显存吃紧可以用load_in_4bit或load_in_8bit量化加载但量化后打印形状不受影响结构解析照样能做。3. 可复制配置config.json 关键字段逐项对照Qwen3 MoE 的行为几乎全部由config.json决定。下面这张表是我从 Qwen3-30B-A3B 的配置文件里整理出来的核心字段每个都标注了它对结构的影响。字段名示例值作用影响的结构model_typeqwen3_moe告诉 transformers 用哪套建模代码决定加载modeling_qwen3_moe.pyhidden_size2048隐藏层维度embed、attention、MLP 的输入输出宽度num_hidden_layers48解码器层数self.layers的长度num_attention_heads32注意力头数Q/K/V 投影后的头维度 hidden_size / headsnum_key_value_heads4KV 头数GQAKV cache 体积比 MHA 小很多head_dim128每个头的维度注意力分数矩阵形状num_experts128专家总数self.experts的长度num_experts_per_tok8每 token 激活专家数top-k 的 k 值moe_intermediate_size768单个专家的中间维度每个专家 MLP 的参数量shared_expert_intermediate_size0共享专家维度Qwen3 MoE 为 0即无共享专家norm_topk_probtrue是否归一化 top-k 权重影响路由权重计算router_aux_loss_coef0.001路由辅助损失系数训练时专家负载均衡max_position_embeddings40960最大位置数RoPE 缓存长度rope_theta1000000RoPE 基频长上下文外推能力rms_norm_eps1e-6RMSNorm 数值稳定项每层归一化sliding_windownull滑动窗口大小为 null 时用标准因果掩码tie_word_embeddingsfalse是否共享输入输出嵌入影响 embed_tokens 和 lm_head几个容易踩坑的点num_experts_per_tok是 8不是 2。这意味着每个 token 会同时走 8 个专家计算量比只走 1 个专家大但比走全部 128 个小得多。这也是 A3B 里「3B 激活」的来源。shared_expert_intermediate_size为 0说明 Qwen3 MoE 没有 DeepSeek 那种「共享专家 路由专家」的双轨设计。所有专家都是路由专家靠 gate 动态选择。norm_topk_prob为 true 时top-k 权重会再做一次归一化保证加权和稳定。如果你自己改路由逻辑这个字段要留意。sliding_window为 null所以Qwen3MoeModel.forward里走的是create_causal_mask不是滑动窗口掩码。如果你要改成长上下文优化这里可以设成具体窗口值。把这份 config 存成config.json后面打印脚本会直接读它。4. 逐层打印脚本验证专家路由与注意力形状光看 config 还不够得实际加载模型把每一层的形状打出来确认和预期一致。下面这个脚本会做三件事加载模型、打印顶层结构、逐层检查 attention 和 MoE 的形状。import torch from transformers import AutoModelForCausalLM, AutoTokenizer, AutoConfig model_path ./Qwen3-30B-A3B # 换成你的本地路径 config AutoConfig.from_pretrained(model_path) print(model_type:, config.model_type) print(num_hidden_layers:, config.num_hidden_layers) print(num_experts:, config.num_experts) print(num_experts_per_tok:, config.num_experts_per_tok) print(moe_intermediate_size:, config.moe_intermediate_size) model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypeauto, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(model_path) # 打印顶层模块 print(\n 顶层结构 ) for name, module in model.named_children(): print(name, type(module).__name__) # 打印第 0 层解码器的子模块 layer0 model.model.layers[0] print(\n DecoderLayer 0 子模块 ) for name, module in layer0.named_children(): print(name, type(module).__name__) # 检查 attention 形状 attn layer0.self_attn print(\n Attention 形状 ) print(q_proj:, attn.q_proj.weight.shape) print(k_proj:, attn.k_proj.weight.shape) print(v_proj:, attn.v_proj.weight.shape) print(o_proj:, attn.o_proj.weight.shape) print(num_heads:, attn.num_heads) print(num_key_value_heads:, attn.num_key_value_heads) print(head_dim:, attn.head_dim) # 检查 MoE 块 moe layer0.mlp print(\n MoE 块 ) print(gate:, moe.gate.weight.shape) print(num_experts:, len(moe.experts)) print(expert0 gate_proj:, moe.experts[0].gate_proj.weight.shape) print(expert0 up_proj:, moe.experts[0].up_proj.weight.shape) print(expert0 down_proj:, moe.experts[0].down_proj.weight.shape)跑完之后你应该看到类似这样的输出 Attention 形状 q_proj: torch.Size([4096, 2048]) k_proj: torch.Size([512, 2048]) v_proj: torch.Size([512, 2048]) o_proj: torch.Size([2048, 4096]) num_heads: 32 num_key_value_heads: 4 head_dim: 128 MoE 块 gate: torch.Size([128, 2048]) num_experts: 128 expert0 gate_proj: torch.Size([768, 2048]) expert0 up_proj: torch.Size([768, 2048]) expert0 down_proj: torch.Size([2048, 768])这里有几个验证点q_proj输出是 4096因为 32 个头 × 128 维 4096。k_proj和v_proj只有 512因为 4 个 KV 头 × 128 512。这就是 GQA 的效果KV cache 比 MHA 小 8 倍。gate的形状是[128, 2048]输入 hidden_size 2048输出 128 个专家的 logits。这个线性层没有 bias和代码里nn.Linear(self.hidden_size, self.num_experts, biasFalse)一致。每个专家的gate_proj是[768, 2048]对应moe_intermediate_size768。三个投影加起来单个专家参数量约 768×2048×3 ≈ 470 万128 个专家就是 6 亿左右再加上 attention 和其他层总参数到 300 亿量级。接下来验证路由是否真的按 top-8 激活。写一个 hook 抓取 gate 输出import torch.nn.functional as F captured {} def gate_hook(module, input, output): captured[logits] output.detach() handle model.model.layers[0].mlp.gate.register_forward_hook(gate_hook) prompt 解释一下混合专家模型的路由机制 messages [{role: user, content: prompt}] text tokenizer.apply_chat_template(messages, tokenizeFalse, add_generation_promptTrue) inputs tokenizer([text], return_tensorspt).to(model.device) with torch.no_grad(): model(**inputs) handle.remove() logits captured[logits] # [batch, seq_len, num_experts] print(gate logits shape:, logits.shape) # 取最后一个 token 的 top-8 last_logits logits[0, -1] topk_weights, topk_indices torch.topk(last_logits, config.num_experts_per_tok) print(top-8 expert indices:, topk_indices.tolist()) print(top-8 raw weights:, topk_weights.tolist()) print(after softmax:, F.softmax(topk_weights, dim-1).tolist())如果topk_indices里出现了 8 个不同的专家编号且 softmax 后权重和接近 1说明路由工作正常。如果所有 token 都选同一批专家可能是权重加载有问题或者norm_topk_prob配置没生效。5. 常见报错排查401、local proxy failed、reading choices、OAuth拆结构的过程中报错基本集中在加载和请求两个环节。下面按真实遇到的顺序列出来。401 Unauthorized如果你用 API 方式验证 Qwen3返回 401 通常是 Key 没带对。检查Authorization: Bearer后面有没有多余空格Key 是否过期。TaoToken 的 Key 在 https://taotoken.net/api-keys 管理重新生成一个再试。本地加载模型不会出现这个错。local proxy failed / connection error这个报错一般出现在from_pretrained去远程拉 config 或权重时。如果你已经把模型下载到本地确保model_path指向的是包含config.json的目录而不是上一级。另外HF_HUB_OFFLINE1可以强制离线加载避免它去连网。reading choices / KeyError choices用 API 时如果返回体里没有choices字段多半是请求体格式不对。检查messages是不是数组model字段是否拼写正确。有些兼容层要求stream: false显式写出否则返回的是 SSE 流解析时会找不到choices。OAuth / token 失效如果你用 CLI 工具登录过 Hugging Face本地缓存了 token换账号后可能报 OAuth 相关错误。清掉~/.cache/huggingface/token再重新登录或者直接用local_files_onlyTrue加载本地权重。形状不匹配 / size mismatch加载权重时报某个参数形状对不上通常是你把 Dense 版的 config 和 MoE 版的权重混用了。确认model_type是qwen3_moe且num_experts和权重文件里的专家数一致。显存不足 OOMMoE 模型虽然激活参数少但总参数大加载时全部权重都要进显存。30B-A3B 用 fp16 加载大约需要 60GB 以上。可以用device_mapauto分到多卡或者用 4bit 量化。量化后gate和experts的形状不变结构分析不受影响。top-k 权重和不为 1如果打印出来 softmax 后和明显偏离 1检查norm_topk_prob是否为 true。为 false 时权重不归一化这是设计行为不是 bug。6. 从结构到落地微调与部署的下一步把结构拆清楚之后微调和部署的决策会清晰很多。微调方面如果你想省显存可以只训练gate和部分专家冻结 attention 和 embed。因为 MoE 的参数量主要集中在 experts冻结大部分专家能显著降低优化器状态占用。具体做法是遍历named_parameters()对包含experts且索引不在目标范围内的参数设requires_gradFalse。部署方面num_experts_per_tok8意味着每个 token 要过 8 个专家的 MLP计算量比 Dense 模型大。但专家是并行计算的实际延迟取决于 batch size 和专家并行策略。如果做高并发服务可以考虑把专家分布到不同设备上用 all-to-all 通信做路由分发。如果你还在选型阶段想先对比 Qwen3-30B-A3B 和 Qwen3-4B 在实际任务上的表现可以用 TaoToken 的模型对话快速跑几组 prompt不用本地下载全量权重。长期做编码或 Agent 任务的话Coding Plan 入口在 https://taotoken.net/coding-plan 里面有按量计费的说明。接入文档在 https://taotoken.net/doc API Keys 在 https://taotoken.net/api-keys 。最后留一个实用技巧打印结构时用model.named_modules()配合正则过滤可以快速定位所有 MoE 层不用一层层手点。比如[n for n, m in model.named_modules() if mlp.gate in n]能直接列出所有 gate 的路径。这个在写微调脚本时特别省事。