• 大模型
• 模型量化
• 多模态

GLM5.3-Flash-E256-DGX-Spark是面向 Blackwell 平台（DGX Spark 集群、单卡 B200）的 GLM-5.3-Flash 压缩版模型：通过神经架构搜索（NAS）在 288 个路由专家中保留 256 个，专家层采用 NVFP4 量化，每 token 激活 18B 参数，并附带即用型 MTP 投机解码草稿。如果你的场景是多轮 Agent / 长链路工具调用，本文用 BFCL v4 实测数据告诉你该选 E256 还是 E224。

30 秒结论（先看这里）🎯

一句话："跑 Agent 选 E224，跑单轮能力选 E256"。

E256 和 E224 到底是什么关系？

两者都源自 zai-org/GLM-5.3-Flash 基座，区别只在 NAS 剪枝后保留的专家数量：

• 本仓库的专家数可在 config.json 中确认："n_routed_experts": 256、"num_experts_per_tok": 8；
• 量化方案（NVFP4 + FP8 KV）定义在 hf_quant_config.json，quant_algo: "NVFP4"、kv_cache_quant_algo: "FP8"；
• 家族中 E256 是最大架构，中文、代码、视觉得分最高（见 README.md 对比表）。

💡 直觉理解：专家越多，"知识面"越广（代码/中文/视觉更强）；但多轮 Agent 更考验指令跟随与状态保持，剪枝策略不同导致两者表现分化——这正是实测数据要回答的问题。

核心数据：BFCL v4 多轮 Agent 实测对比

BFCL v4 是当前主流的工具调用（function calling）评测基准，其中Multi-Turn Base子集（200 题）专门考察多轮工具调用的能力。两者均在同一台 B200、同一 vLLM 评测框架下测得，结果如下：

📌 这就是标题答案的直接依据：

"For multi-turn agent workloads, prefer E224: it scores about 5 points higher on Multi-Turn Base." —— 引自 README.md

为什么多轮差距明显？多轮 Agent 中，模型需要在几十步工具调用间持续维护上下文、纠正中间错误。E256 多出的 32 个专家让单轮"知识密度"更高，但多轮状态保持能力反而落后约 5 个百分点——对生产 Agent 来说，这个差距意味着失败轨迹率显著不同。

E256 单轮工具调用的细分表现（BFCL v4，AST 匹配）：

可以看到 Java 工具调用和"无关工具识别"仍是两者的共同弱项（详见 README.md 完整分类表）。

其他能力：E256 全面占优的地方 📊

多轮 Agent 选 E224，不代表 E256 弱。单轮知识类任务 E256 是家族最强：

⚡ 注：GPQA 数字是reasoning_effort=low的快速自检，非最高分；家族在reasoning_effort=max下可达90.9 %（E224 实测）。MoE 解码非比特级确定，±2~3 分视为噪声，GPQA/AIME 上两者实际打平。

部署差异：显存预算决定你的选择

单卡 B200 / GB200（已验证），E256 的启动方式（66K 上下文）：

export VLLM_USE_DEEP_GEMM=0 vllm serve autotrust/GLM5.3-Flash-E256-DGX-Spark \ --served-model-name glm53-flash-e256 \ --max-model-len 66560 --max-num-seqs 16 --max-num-batched-tokens 8192 \ --gpu-memory-utilization 0.97 \ --tool-call-parser glm47 --enable-auto-tool-choice --reasoning-parser glm45

• 加载 159.1 GiB 权重后仅剩 6.5 GiB FP8 KV（约 532K token，或 8 路 66K 并发）——偏紧；
• 需要reasoning_effort=max（约 172K 上下文）时，单张 180 GB 卡不够，建议双卡 / B300 /改用 E224。

2× DGX Spark（未验证）：TP=2 下 E256 每节点约 80 GiB 权重（E224 为 71 GiB），KV 池明显更小，官方明确建议两卡 Spark 场景优先 E224。

彩蛋：E256 仓库内置 MTP 加速草稿 🚀

本仓库自带 6.95 GB 的 NVFP4 MTP 投机解码草稿 mtp-nvfp4/（完整配置见 mtp-nvfp4/config.json），单流解码提速1.84×（3 draft token 时 1.94×），且无损——目标模型会逐 token 验证草稿，质量不受影响：

启用方式是在vllm serve中加一段--speculative-config指向本仓库的mtp-nvfp4目录，同时需先应用补丁 scripts/vllm_glm5next_standalone_mtp_draft.patch（让 vLLM 按草稿自身 config 构建 MTP 层）。提示词建议：交互/低并发场景开启 MTP，高并发批量服务时关闭。

⚠️ 选型提醒：MTP 加速属于"部署层"收益，与 E256/E224 的能力选择无关，但草稿会额外占用约 4 GiB 显存并压缩 KV 池——在本来就紧张的 E256 单卡部署中要权衡。

选型清单：照着勾选即可 ✅

• 多轮 Agent、长链路工具调用、长 trace 可靠性优先→ 选E224（Multi-Turn Base 80% vs 73~75%）
• 代码生成 / 中文知识 / 图文理解为主的单轮服务→ 选E256（HumanEval 97.6%、C-Eval 89.4%、MMMU 76.1%）
• 单卡 B200 且想开reasoning_effort=max深度推理→ 选E224（显存更宽裕）
• 双卡 DGX Spark→ 选E224（E256 未验证且 KV 池小）
• 想要 MTP 投机解码开箱即用→ 本仓库mtp-nvfp4草稿对 E192/E224/E256通用，E256 用户还可用 scripts/export_mtp_nvfp4.py 重新导出

延伸阅读（本仓库关键文件）

• 完整基准与部署说明：README.md
• 模型结构（256 专家、45 层、FP8 KV 声明）：config.json
• NVFP4 量化清单：hf_quant_config.json
• MTP 草稿完整模型：mtp-nvfp4/
• vLLM MTP 独立草稿支持补丁：scripts/vllm_glm5next_standalone_mtp_draft.patch
• 采样默认值（temperature=1.0 / top_p=0.95）：generation_config.json

⚠️ 本仓库为非官方衍生版本，未获 Z.ai 或 NVIDIA 背书；多轮工具调用能力弱于 E224、单卡 180 GB 显存偏紧均为已知限制。生产部署前请在自己的真实负载上先行评测。

• 大模型
• 模型量化
• 多模态