【免费下载链接】altar-1项目地址https://ai.gitcode.com/hf_mirrors/AikidoSec/altar-1点击查看免费下载Altar-1 是 Aikido 基于 GLM-5.3 发布的 504B 参数 MoE 专家剪枝模型。本文带你彻底搞懂它的核心选择标准——massmax168 准则为什么它比保留全局使用频率最高专家的剪枝方式更能保住模型在各领域的能力以及新手如何快速读懂仓库里的剪枝计划与配置文件。1分钟速览massmax168 三个词拆开看massmax168 这个名字其实是一句压缩过的技术说明拆开就是三个部分组成含义mass路由权重下的专家激活量Router-weighted Expert Activation即每个专家实际承接了多大量的路由工作max不取平均值而是取该专家在任意单一领域内占比的最大值168每层保留 168 个专家原模型每层有 256 个一句话总结先给每个专家算它在各领域里的份额再挑它表现最强的那个领域份额打分每层留下分数最高的 168 个。这个打分依据来自 REAPRouter-weighted Expert Activation Pruning方法在网络安全流量、编码、工具调用、推理和英文语料上完成校准并额外加入了多语言 Wikipedia 文章——这也是后面保住领域专才的关键。为什么全局频率剪枝会误伤模型最直觉的剪枝思路是全局频率剪枝统计校准语料中每个专家被路由到的总次数保留被用得最多的 168 个。听起来很合理但问题在于——频率统计只看总量不看是谁在用它。想象一家综合医院骨科专家全年门诊量很高而罕见病专家全年只接诊几十例。如果按总门诊量排名裁人罕见病专家第一个被裁——可一旦遇到罕见病这家医院就彻底瘫痪了。MoE 模型里的专家也是一样。以 Altar-1 的校准数据为例代码专家主要在处理编码任务时被激活小语种专家只处理多语言文本结构化输出专家只在生成 JSON 类内容时出现。这些领域专才的整体激活频率往往排不进前 168 名按全局频率剪枝就会把他们删掉模型随即在对应领域明显退化。massmax168 的max正是针对这一点一个专家哪怕全年只在 5% 的 token 上被用到只要在这 5% 里它是该领域的主力占路由工作量的大头它的 max 分数就会很高就能留在 168 名额内反过来一个什么都沾一点的高频杂工专家如果没有任何一个领域是它挑大梁的max 分数反而不突出。结果每一层、每一个领域都保留了自己的专科医生而不再只留下一屋子全科常客。Altar-1 是如何执行 massmax168 剪枝的整个过程不需要重新训练直接对 GLM-5.3 的 AWQ-INT4 版本做外科手术校准打分在真实流量网络安全、编码、工具调用、推理、多语言上收集路由行为按 massmax168 给每层 256 个专家打分逐层删除每层删掉最末位的 88 个专家256 → 168删掉约 34%路由逻辑不动每个 token 依然从剩余 168 个专家里选 8 个激活参数量保持在约 40B与原模型一致精度混合配置只有路由专家压到 INT4W4A16compressed-tensors/AWQ注意力、共享专家、稠密层和输出头保持 BF16。剪枝结果固化在 reap_prune_plan.json 中打开就能看到核心字段{keep: 168, criterion: massmax168, layers: {3: [0, 1, 2, 4, ...], ...}}criterion: massmax168即本文主角layers列出第 3 层到第 78 层共76 个稀疏层各自保留的专家编号每层恰好 168 个前 3 层是稠密dense层没有可剪的专家与 config.json 中first_k_dense_replace: 3的设置吻合文件末尾还有一个mtp_ranking字段针对 MTP多 token 预测层改用权重幅度排序属于该准则的一个特例。在 config.json 里也能直接验证剪枝后的架构参数参数值说明n_routed_experts168剪枝后的每层路由专家数num_experts_per_tok8每个 token 激活 8 个专家未变n_shared_experts1保留 1 个共享专家BF16 不量化num_hidden_layers78层数未变quantization_configint4 / group_size 32路由专家的 W4A16 量化配置效果如何0.506 nats 的 KL 散度说明什么衡量剪枝后模型和原模型差多少项目采用KL 散度Kullback–Leibler divergence数值越小越接近原模型0 表示完全一致对比项KL 散度25 条密封提示词、154k 完整词表Altar-1INT4 vs 完整 BF16 GLM-5.30.506 nats同剪枝方案的 EXL3 版本 vs 完整 BF160.511 nats两个细节值得注意同一份 168 专家剪枝方案下INT4 与 EXL3 两种量化格式只差 0.005——说明在 4-bit 档位上量化格式几乎不影响结果真正决定保真度的是留哪 168 个专家这正是 massmax168 的价值所在README 中明确提到该方案与频率剪枝做过正面对比head-to-head结论是 massmax168 保留的领域专才让剪枝后的输出分布更贴近原模型。剪枝前后参数对照表维度原 GLM-5.3Altar-1总参数量753B504B减少约 34%每层路由专家256168每 token 激活专家88不变激活参数量约 40B约 40B不变权重精度BF16路由专家 INT4 其余 BF16权重体积远超单机能力328 GB4× H200 即可部署是否重新训练—不需要纯剪枝 量化对推理侧来说328 GB 权重摊到 4 张 H200 上后仍有余量支撑 128k 上下文的 KV cache生产批量下vLLM 会自动选择 Marlin MoE kernel。部署 Altar-1 的 vLLM 启动命令官方推荐的部署方式是一行 vLLM 命令要求 Hopper 架构H100/H200vllm serve aikido/altar-1 --tensor-parallel-size 4 --trust-remote-code --max-model-len 131072生成参数见 generation_config.jsontemperature 1.0、top_p 0.95、采样开启与 GLM 系列原模型的推荐设置一致。文件导航去哪里查 massmax168 的细节文件看什么README.md模型总览、校准语料、KL 散度数据、vLLM 部署命令reap_prune_plan.json剪枝计划本体criterion: massmax168 每层保留的 168 个专家编号config.json架构与量化配置n_routed_experts、W4A16 量化组、BF16 白名单generation_config.json采样参数temperature / top_p / eos 等model.safetensors.index.json39 个权重分片model-00001 ~ model-00039.safetensors的张量索引chat_template.jinja对话模板接入服务时渲染提示词用总结massmax168 给 MoE 剪枝留下的启示频率不是价值全局频率剪枝把低频但不可替代的领域专才当垃圾清掉了max 才是关键massmax168 用在任一领域的最大份额打分让每一层、每个领域都留下自己的主力专家无需重训、代价可控删掉 34% 的专家后KL 散度仅 0.506 nats激活计算量保持约 40B 不变753B 的模型直接瘦身成 4×H200 就能跑的 504B 版本。如果你的场景是多领域混合服务代码 安全 多语言、硬件又跑不动完整 753B 模型Altar-1 这套massmax168 INT4的组合就是一个开箱即用的答案。赞分享【免费下载链接】altar-1项目地址https://ai.gitcode.com/hf_mirrors/AikidoSec/altar-1点击查看免费下载相关推荐为什么简洁是react-content-loader的终极设计原则打造高效骨架屏的完整指南为什么简洁是react content loader的终极设计原则打造高效骨架屏的完整指南 react content loader是一个基于SVG的组件专前端UI组件metube前端框架选择为什么是Angularmetube前端框架选择为什么是Angular 你是否曾在开源项目中纠结过前端框架的选择当metube一个自托管的视频下载器为视频下载工具提供Web界后端前端视频Deepagents自动化测试确保AI代理的质量与稳定性Deepagents自动化测试确保AI代理的质量与稳定性 Deepagents是基于langchain和langgraph构建的AI代理框架通过规划工具、文人工智能AI AgentAgent 框架工具调用代码智能体创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考