ik_llama.cpp 中 THUDM GLM-4-MoE-100B-A10B 模型支持的技术评估与 MoE 架构实现指南【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp导读本文基于 github-data/issues/597 中提出的功能请求结合当前 ik_llama.cpp 仓库源码系统梳理 GLM-4 系列 MoE 架构在本项目中的支持现状、实现原理与量化实践。读者将掌握glm4moe架构的推理图构建细节、专家门控与共享专家配置方式以及如何将新 MoE 模型接入本项目的完整技术路径。一、问题背景一份针对 GLM-4-MoE-100B-A10B 的功能请求2025-07-10开发者ubergarm在 ik_llama.cpp 仓库提交了编号 #597 的功能请求核心诉求是为智谱 AITHUDM尚未正式发布的GLM-4-MoE-100B-A10B模型架构提前做准备。该 issue 的关键信息如下字段内容请求编号#597提出者ubergarm状态开放Open创建时间2025-07-10最后更新2025-07-14issue 中提到THUDM 开发者zRzRzRzRzRzRzR正在 vLLM 项目中为该新架构添加支持模型名称中的100B 代表总参数量、A10B 代表每次激活 10B 参数这是一个大而稀疏的 MoE 定位介于 32B 级别 GLM-4-0414 系列与更大规模模型之间。issue 发起人明确表示如果看起来有前景我会尝试在它准备好后为这个尺寸合适的 MoE 添加支持。社区成员arch-btw在 2025-07-14 补充提醒GLM-4-MoE-100B-A10B这一名称可能只是占位符并引用了 HuggingFace 上 THUDM 官方讨论区的截图佐证。这一提醒具有工程意义——在为未发布模型写死架构名与超参数之前需要确认命名稳定性。说明该 issue 目前仍处于开放状态仓库内尚无GLM-4-MoE-100B-A10B专属实现。但 GLM-4 系列 MoE 的核心架构在本项目中已有完整实现与落地这正是本文可以基于源码深入展开的部分。二、仓库中的 GLM-4 系列架构支持现状2.1 架构注册表glm4与glm4moe在 src/llama-arch.cpp 中本项目注册了完整的 GLM 系架构名称{ LLM_ARCH_CHATGLM, chatglm }, { LLM_ARCH_GLM4, glm4 }, { LLM_ARCH_GLM4_MOE, glm4moe },对应的枚举定义位于 src/llama-arch.h。这意味着glm4对应 GLM-4 / GLM-4-0414 系列稠密模型如 GLM-Z1-Rumination-32B-0414glm4moe对应 GLM-4 系 MoE 变体即本文讨论的 GLM-4-MoE-100B-A10B 在架构层面的归属。此外仓库还注册了glm-dsa、glm5next等更新架构见 src/llama-arch.cpp说明本项目对 GLM 生态保持着持续的跟进节奏。2.2 已有的 GLM-4-0414 支持历程在等待 100B MoE 的同时项目此前已通过 PR #333 和 #344 合入了对 GLM-4-0414 系列模型的支持。从 PR #333 的描述中可以确认以下事实该 PR 的目标是引入 piDack 在 llama.cpp 主线 PR#12957 中的改动以支持THUDM/glm-4-0414系列发起人当时的实践意图是对 GLM-Z1-Rumination-32B-0414 做 imatrix 与量化并尝试用余弦相似度逐层重要性评分来设计更低 PPL 的量化方案该 PR 明确标注在 CUDA 后端不工作在 CPU 后端可能工作最终处于 Closed 状态——说明 GLM-4 系架构的落地过程中后端兼容性是必须重点验证的一环。这条历史线索对 issue #597 的参考价值在于即便 GLM-4-MoE-100B-A10B 发布其支持工作也应沿用先验证转换脚本 → 再验证 CPU 后端 → 再扩展到 GPU 后端的渐进路线。三、glm4moe 架构的源码级实现剖析3.1 推理图构建build_glm4_moeGLM-4 MoE 的完整前向计算图位于 src/graphs/build_glm4.cpp 的llm_build_context::build_glm4_moe()函数。从源码结构看该实现包含以下关键环节1位置编码与 RoPE 缓存struct ggml_tensor * inp_pos build_inp_pos(); auto rope_cache model.split_mode ! LLAMA_SPLIT_MODE_GRAPH cparams.rope_cache (rope_type LLAMA_ROPE_TYPE_NEOX || rope_type LLAMA_ROPE_TYPE_NORM) ? ggml_rope_cache(...) : nullptr;当满足拆分模式、RoPE 缓存启用且类型为 NEOX/NORM 时预计算 RoPE 缓存以加速否则在逐层前向中调用ggml_rope_ext动态计算。2自注意力QKV 合并与多形态权重auto [Qcur, Kcur, Vcur] llm_build_mul_mat_qkv(gf, cur, model.layers[il].wqkv, model.layers[il].bqkv, model.layers[il].wqk, model.layers[il].bqk, model.layers[il].wq, model.layers[il].bq, ...);llm_build_mul_mat_qkv同时兼容合并 QKVwqkv、QK 合并wqk与分离 Q/K/V三种权重布局这是 GLM-4 系列不同代际权重组织方式并存所必需的。3前导稠密层与 MoE 层分区if ((uint32_t) il hparams.n_layer_dense_lead) { // dense FFN cur llm_build_ffn(..., LLM_FFN_SILU, LLM_FFN_PAR, ...); } else { cur llm_build_std_moe_ffn(ctx0, lctx, model.layers[il].ffn_norm, ffn_inp, model.layers[il].ffn_gate_inp, model.layers[il].ffn_gate_inp_b, model.layers[il].ffn_up_exps, model.layers[il].ffn_up_exps_b, ... n_expert, n_expert_used, LLM_FFN_SILU, hparams.expert_weights_norm, true, hparams.expert_weights_scale, (llm_expert_gating_func_type) hparams.expert_gating_func, LLM_FFN_SILU, cb, il, gf, true, model.layers[il].ffn_up_gate_exps); }这是整个glm4moe架构的核心特征模型前若干层n_layer_dense_lead使用稠密 FFN其余层切换为专家混合MoEFFN。llm_build_std_moe_ffn支持共享专家shared expertsffn_*_shexp与各专家独立的 up/gate/down 权重并透传门控函数类型。4MTPMulti-Token Prediction支持if (cparams.mtp_op_type ! MTP_OP_NONE) { ggml_tensor * hidden_states_from_main_model build_inp_mtp_states(hparams.n_embd); cur build_glm4_moe_mtp(mtp_layer, hidden_states_from_main_model, n_embd_head, gf, inp_pos, rope_cache); }当启用 MTP 时最后一层被保留给 NextN 预测头n_transformer_layers n_layer - hparams.nextn_predict_layers主模型只处理前n_transformer_layers层MTP 模块从主模型隐藏状态继续计算。3.2 超参数加载与门控函数默认值在 src/llama-hparams.cpp 中LLM_ARCH_GLM4_MOE分支加载以下关键超参数ml.get_key(LLM_KV_EXPERT_FEED_FORWARD_LENGTH, hparams.n_ff_exp); // 专家 FFN 维度 ml.get_key(LLM_KV_EXPERT_COUNT, hparams.n_expert); // 专家总数 ml.get_key(LLM_KV_EXPERT_USED_COUNT, hparams.n_expert_used); // 每 token 激活专家数 ml.get_key(LLM_KV_EXPERT_SHARED_COUNT, hparams.n_expert_shared); // 共享专家数 ml.get_key(LLM_KV_LEADING_DENSE_BLOCK_COUNT, hparams.n_layer_dense_lead); // 前导稠密层数 ml.get_key(LLM_KV_EXPERT_WEIGHTS_SCALE, hparams.expert_weights_scale); ml.get_key(LLM_KV_EXPERT_WEIGHTS_NORM, hparams.expert_weights_norm, false); ml.get_key(LLM_KV_EXPERT_GATING_FUNC, hparams.expert_gating_func, false); if (hparams.expert_gating_func 0) { hparams.expert_gating_func LLM_EXPERT_GATING_FUNC_SIGMOID; // GLM4_MOE 默认 sigmoid 门控 }源码注释明确指出GLM4_MOE uses sigmoid当 GGUF 未写入门控函数类型默认值 0时代码自动回退到LLM_EXPERT_GATING_FUNC_SIGMOID。这是 GLM-4 MoE 与多数使用 softmax 门控的 MoE 模型如 Mixtral、DeepSeek的重要区别加载模型时不可忽视。加载端在 src/llama-load-tensors.cpp 还做了防御性校验GGML_ASSERT(hparams.n_expert 0 n_expert must be 0 for GLM4_MOE MoE layers); GGML_ASSERT(hparams.n_expert_used 0 n_expert_used must be 0 for GLM4_MOE MoE layers);若 GGUF 中专家数或激活专家数为 0将直接触发断言失败避免带病进入前向计算。3.3 数值稳定性与 CUDA 图等特殊处理GLM4 与 GLM4_MOE 架构在项目中受到多处特殊照顾这些处理对量化与推理精度影响显著半精度累加器的数值问题在 src/llama-build-context.cpp、L1259-L1260、L2231-L2232 等多处源码注释均写明GLM4 and GLM4_MOE seem to have numerical issues with half-precision accumulators因此在构建上下文时对这两类架构强制使用全精度累加路径CUDA 图与 MTP 拆分GLM4_MOE与QWEN35一样被标记为可参与 MTP 的 CUDA 图拆分见 src/llama-load-tensors.cpp而 CUDA 图禁用条件中则明确排除了GLM4_MOE见 src/llama.cpp图拆分支持在 src/llama-model.cpp 的 MoE 张量并行拆分列表中LLM_ARCH_GLM4_MOE被列入支持集合。这些细节共同说明glm4moe不是能跑就行的移植而是针对该架构数值特性做了专项调优的成熟实现。四、从 issue #597 到落地新增 MoE 架构的接入路径虽然GLM-4-MoE-100B-A10B尚未发布但结合仓库现有结构与历史 PR可以梳理出一条经过验证的接入路径供后续支持工作参考第 1 步确认架构命名与张量映射llama-arch在 src/llama-arch.cpp 注册架构字符串与张量名映射。若 100B MoE 与现有glm4moe张量布局一致则可能无需新架构直接复用glm4moe若引入新权重如新的门控或偏置则需要扩展LLM_ARCH_*枚举与LLM_TENSOR_*映射。第 2 步验证 GGUF 转换脚本项目根目录的 convert_hf_to_gguf.py 是 HF → GGUF 的唯一入口。PR #333 的历史经验表明转换脚本的 Python 改动需与 C 加载端同步合入否则会出现模型能下载、无法加载的断档。转换时建议使用--outtype bf16并在大模型场景配合--split-max-size分片参考 PR #333 中--split-max-size 35G的用法。第 3 步校验超参数与门控函数对照 src/llama-hparams.cpp 确认n_expert、n_expert_used、n_expert_shared、n_layer_dense_lead等键在 GGUF 中存在确认门控函数默认回退 sigmoid 的语义是否适用于 100B MoE若官方采用不同门控需显式写入expert_gating_func元数据。第 4 步后端兼容性验证参考 PR #333 的教训——先验证 CPU 后端再扩展 CUDA。重点检查glm4moe的半精度累加规避逻辑src/llama-build-context.cpp与 CUDA 图禁用条件是否在新模型上正确触发。第 5 步imatrix 与量化GLM-4 系在 ik_llama.cpp 中的主要实践场景是量化。可复用项目自带的 scripts/get-pg.sh、scripts/qnt-all.sh 等工作流对 100B-A10B 这种总参大、激活小的模型量化收益将非常显著推理只接触 10B 激活参数对应的专家权重。五、GLM-4 MoE 的量化与部署要点基于上述架构特征针对 GLM-4-MoE-100B-A10B 这类模型在 ik_llama.cpp 中部署时建议重点关注关注点建议依据模型转换convert_hf_to_gguf.py --outtype bf16大模型加分片convert_hf_to_gguf.pyPR #333门控函数确认 GGUF 中expert_gating_func缺省按 sigmoid 处理src/llama-hparams.cpp前导稠密层关注n_layer_dense_lead稠密层占比影响量化策略src/graphs/build_glm4.cpp累加精度保持全精度累加路径勿用半精度累加器src/llama-build-context.cpp专家并行利用 MoE 张量并行与图拆分特性src/llama-model.cpp推理验证先 CPU 后 CUDA逐层比对输出PR #333 历史经验六、小结与展望issue #597 提出时GLM-4-MoE-100B-A10B尚处未发布状态模型命名也可能只是占位符。但通过对当前仓库源码的分析可以确认架构基础已就绪glm4moe架构的推理图、超参数加载、门控回退、数值稳定性处理均已在 src/graphs/build_glm4.cpp 与 src/llama-hparams.cpp 中实现GLM-4 系 MoE 的核心技术栈在本项目内是完整可用的接入路径清晰一旦模型正式发布若其张量布局与现有glm4moe兼容理论上只需更新转换脚本与超参数即可支持若不兼容则需扩展架构注册与张量映射量化价值明确100B 总参 / 10B 激活的 MoE 形态配合本项目对 GLM 系已有的量化实践见 scripts/qnt-all.sh是低资源部署大模型的理想目标。从该 issue 的演进可以看到开源 MoE 支持工作的一般节奏提前在 issue 中标记方向 → 模型发布后由转换脚本验证 → 逐步打通 CPU/CUDA 后端 → 最终沉淀为稳定的架构实现。对于关注 GLM 生态的开发者当前即可基于glm4moe架构熟悉推理路径与量化工作流待 100B-A10B 正式发布后快速落地。【免费下载链接】ik_llama.cppllama.cpp fork with additional SOTA quants and improved performance项目地址: https://gitcode.com/GitHub_Trending/ik/ik_llama.cpp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考