人工智能大模型模型优化模型量化模型压缩【免费下载链接】Model-OptimizerA unified library of SOTA model optimization techniques like quantization, distillation, pruning, neural architecture search, speculative decoding, etc. It compresses deep learning models for downstream deployment frameworks like TensorRT-LLM, TensorRT, vLLM, etc. to optimize inference speed.项目地址https://gitcode.com/GitHub_Trending/te/Model-Optimizer点击查看免费下载本文围绕 Model-Optimizer 开源仓库中modelopt_recipes/model_type/这一配方recipe层级展开系统讲解架构级配方的定位、目录组织、运行时加载机制与内容共享方式。读完本文你将掌握如何在 checkpoint 级、架构级与通用级三层配方之间做出正确选择如何用--recipe model_type/model_type/task/recipe一键驱动 PTQ 量化以及如何通过# modelopt-schema:snippet 与$import机制复用配方片段为特定模型架构编写合规、可维护的优化配置。一、什么是架构级配方Model-Optimizer 将模型优化流程后训练量化 PTQ、投机解码训练、扩散模型蒸馏等封装为声明式 YAML 配方——一个配方文件就是一份模型如何被优化的版本化单一事实来源算法、逐层数值格式、校准方式全部用数据而非代码表达从而使优化流程可复现、可 diff、可按名称查找见 modelopt_recipes/README.md。同一份 YAML 可被三种入口消费Python APIload_recipe、示例 CLI 的--recipe参数、以及内置的*_CFG常量。配方的存放位置有明确分层层级目录定位适用粒度general/模型无关的通用配方任意模型的最优起点model_type/model_type/架构级配方某一 HFmodel_type下的所有 checkpointtimm/architecture/timm 架构级配方timm 模型models/org/model_id/checkpoint 级配方某一个已发布 checkpoint其中model_type/层存放的配方其行为与特定的 Hugging Facemodel_type即模型架构绑定一个配方覆盖该架构下的每一个 checkpoint。而针对某个已发布 checkpoint单独调优的配方则归入相邻的models/层。二、三层配方选择策略model_type/README.md给出的选配规则是选最具体的那一层按优先级从高到低model_type/的兄弟层models/——若存在与你的确切发布 checkpoint对应的条目以其模型仓库路径为键优先使用。它镜像了经过验证的、逐 checkpoint 的量化方案。model_type/model_type/——按目标模型的 HFmodel_type选取架构级配方适用于该model_type的每一个 checkpoint。某架构在这里存在目录即意味着该架构有推荐配方。回退到general/——若没有适用的model_type/目录通用配方就是任意模型的良好起点也是尚未拥有专属条目的模型架构的推荐起点。该选配逻辑在modelopt_recipes/README.md中被复述并扩展为四层查找先查models/org/model_id/再查model_type/model_type/或timm/architecture/都无匹配再回退general/。这套优先级背后的事实是checkpoint 级配方最精准但覆盖最窄架构级配方覆盖广但只表达与通用模板的差异通用配方最宽松。配方放置位置本身就是一种信号——目录的存在即代表推荐。三、目录结构与命名规范配方按 HFmodel_type字符串分类目录结构为modelopt_recipes/model_type/ model_type/ task/ recipe.yaml [recipe.aux.yaml] # 可选 snippet 辅助片段见下文 [README.md] # 可选描述模型特定之处task是配方所针对的优化工作流例如ptq后训练量化。当前仓库中model_type/下已覆盖的架构包括diffusion_gemma、gemma、gemma4、minimax_m3_vl、mpt、nemotron_llama、nemotron_vl、qwen3_5、qwen3_5_moe、qwen3_6_moe、qwen3_vl、step3p7、vit另有models/子层存放 checkpoint 级条目见 目录清单。运行时选择配方时使用相对modelopt_recipes/的路径例如--recipe model_type/model_type/task/recipe注意model_type/层还有一个历史沿革它此前叫huggingface/。旧的huggingface/model_type/...配方路径仍可解析源码树里有符号链接加载器里有前缀别名但model_type/才是规范位置——新增配方、配置与--recipe参数都应使用新前缀。这一兼容逻辑可以从加载器源码得到印证modelopt/recipe/loader.py中的_resolve_recipe_path会调用_alias_builtin_recipe_prefix重写旧前缀并针对 pip 安装符号链接不随 wheel 分发的场景发出FutureWarning提示迁移见 loader.py。四、如何验证模型的model_type配方目录名必须使用精确的model_type字符串——即模型config.json顶层model_type字段的值多模态配置则取内部语言模型的text_config.model_type。判断依据有两个权威来源Hugging Face Hub 上发布 checkpoint 的config.json即org/model/raw/main/config.json的内容transformers库中各模型专属的configuration_name.py——这些文件内部硬编码了model_type字符串。文档明确要求放置配方前必须对照上述来源确认不要猜测。目录名写错model_type会导致配方在运行时匹配不到任何模块——一个典型的后果就是ptq.md中记录 Step-3.7 的例子由于 Step 把 MoE 块命名为moe、把稠密兄弟块命名为share_expert通用配方的*.experts.*、*block_sparse_moe*、*mlp*通配符在路由专家上匹配不到任何模块最终导出quant_algo: null的 checkpoint。这正是以config.json为准这条纪律的实战意义。五、运行时加载机制--recipe与load_recipe配方路径可通过 CLI 或 Python API 传入。examples/hf_ptq/hf_ptq.py的--recipe参数支持不含后缀的配方名例如model_type/qwen3_5/ptq/w4a16_nvfp4-fp8_attn-kv_fp8_cast内部通过load_recipe(recipe)加载见 hf_ptq.py。参数说明还揭示了不同配方类型的 KV 缓存行为差异PTQ 配方在quant_cfg中配置 KV cache 并忽略--kv_cache_qformat权重 AutoQuantize 配方使用自身的kv_cache设置KV-cache AutoQuantize 配方则逐层从candidate_formats中挑选 K/V 格式。Python 侧的用法见 loader.pyfrom modelopt.recipe import load_recipe cfg load_recipe(model_type/gemma/ptq/w4a8_awq-kv_fp8_cast)加载器的路径解析有明确的优先级先探文件系统用户本地同名配方树优先于内置配方再查内置配方库后缀.yml/.yaml可省略自动探测。这意味着你可以把一份本地调优过的配方放在同名路径下覆盖内置版本。加载器还会按配方类型强制校验必需主体段——PTQ 配方必须有quantizeAutoQuantize 必须有auto_quantize投机解码配方必须有eagle/dflash/medusa见 loader.py避免用户在缺失字段时面对晦涩的 pydantic 报错。六、内容共享# modelopt-schema:snippet 与$import当同一段配置被多个配方复用例如一个配方适用于多个model_type或多个配方共享某个子块时标准做法是把复用部分抽取到兄弟 snippet 文件中文件带# modelopt-schema:头各配方通过$import引用它。配方包装文件保持轻量共享主体只存一处。snippet 的命名要一看就不是可运行的配方——惯例是把 snippet 所代表的字段名作为次级后缀如recipe.field.yaml。snippet 放在其自然主家配方旁边其他引用方以modelopt_recipes/下的同一相对路径引用。以gemma架构的 W4A8 AWQ 配方为例完整内容见 w4a8_awq-kv_fp8_cast.yaml# modelopt-schema: modelopt.recipe.config.ModelOptPTQRecipe imports: base_disable_all: configs/ptq/units/base_disable_all default_disabled_quantizers: configs/ptq/units/default_disabled_quantizers fp8: configs/numerics/fp8 int4_per_block: configs/numerics/int4_per_block kv_fp8_cast: configs/ptq/units/kv_fp8_cast quantize: algorithm: method: awq_lite alpha_step: 1 quant_cfg: - $import: base_disable_all - quantizer_name: *weight_quantizer cfg: - $import: int4_per_block - $import: fp8 - quantizer_name: *input_quantizer cfg: $import: fp8 - $import: kv_fp8_cast - $import: default_disabled_quantizers这个配方充分展示了 snippet 复用模式数值格式单元int4_per_block、fp8、KV-cache 单元kv_fp8_cast与禁用量化器清单base_disable_all、default_disabled_quantizers全部来自共享的configs/层配方自身只表达模型特定增量。底层的$import解析逻辑位于modelopt/torch/opt/config_loader.py_IMPORT_KEY $importL300解析器递归处理配置树中的$import标记——字典上下文中的$import做导入并合并、内联键覆盖导入值这正是 alias 配方只覆盖 metadata、继承 quantize的机制列表上下文中的$import则按类型化列表 schema 拼接条目见 config_loader.py。若$import引用了未声明的名字或 schema 不匹配会给出带上下文提示的报错。snippet 还有一个硬性要求被其他文件导入的配方必须携带# modelopt-schema:注释——因为$import解析需要用声明的 schema 校验被导入的载荷不被导入的配方则无需此注释。这解释了为什么每个可导入片段都带 schema 头而纯终端配方如 alias 包装可以没有。七、checkpoint 级配方什么时候不放model_type/model_type/README.md划定了一条明确边界若某个配方是为单一已发布 checkpoint 调优的而不是为该model_type的所有 checkpoint 调优它不属于这里应放顶层models/层以 checkpoint 的模型仓库路径org/model_id为键。该层的完整约定见models/README.md其中包括两种条目形态Mirror镜像手工逐层/逐组件映射的混合精度方案复刻某个发布的量化 checkpoint一般配方无法表达Alias别名某个发布 checkpoint 的方案恰好能被现有通用/架构配方表达则该条目只是薄薄一层记录整体$import那个配方并仅覆盖metadataimports: base: general/ptq/nvfp4_default-kv_fp8_cast $import: base metadata: description: - meta-llama/Llama-3.1-8B-Instruct quantized with the general NVFP4 scheme and an FP8 KV cache in cast mode, as published in nvidia/Llama-3.1-8B-Instruct-NVFP4.写哪种的决策原则是先假定写 alias只有当确认没有任何可移植配方能表达该发布的方案对比发布的hf_quant_config.json与候选配方quant_cfg的产物时才写 body——因为从通用配方复制 body 是维护负担会失去对源配方的追踪。此外只有描述后训练量化方案的模型卡才回填条目描述 PTQ 后量化感知蒸馏QAD的模型卡刻意不入库因为没有 PTQ 配方能复现那种 checkpoint。若你找某个 NVIDIA 发布 checkpoint 未果通常是这个原因。八、每目录 README描述模型特定增量model_type/下每个task/目录可能附带简短README.md精确说明每个配方的模型特定之处——算法覆盖、禁用量化器模式等——让审查者与使用者无需 diff YAML 与通用预设即可理解意图。这是model_type/层的基本纪律数值与标准排除项尽量继承自configs/模型目录只记录增量。ptq.md见 modelopt_recipes/ptq.md把架构级/checkpoint 级配方的模型特定偏差归纳为四类正好与model_type/下的实际目录一一对应1. 架构感知quant_cfgminimax_m3_vl、qwen3_vl、qwen3_5、qwen3_5_moe、qwen3_6_moe、vit、nemotron_llama单条通配符方案无法表达的逐子模块格式选择。例如qwen3_5/ptq/w4a16_nvfp4-fp8_attn-kv_fp8_cast是通用 body 无法覆盖的混合方案MLP/专家投影权重与lm_head用 NVFP4 W4A16自注意力与大型线性注意力投影in_proj_qkv、in_proj_z、out_proj用 FP8KV cache 用 FP8 cast并禁用linear_attn.in_proj_a/b、conv1d及visual/mtp等参考配方之外的子模块。其原因是这些模型是线性注意力 softmax 注意力混合架构。2. 算法覆盖gemma、gemma4、mpt数值与作用域同通用配方仅quantize.algorithm不同。gemma/ptq/w4a8_awq-kv_fp8_cast用awq_litealpha_step: 1替代默认 AWQ 搜索——默认搜索在 TRT-LLM 内核上对 Gemma 溢出粗粒度扫描避免溢出且精度无明显损失gemma/ptq/int8_sq-kv_fp8_cast则将 SmoothQuantalpha从默认1.0改为0.5Gemma 7B 在alpha1时回归。mpt与gemma4沿用同一 AWQ 覆盖见 mpt/ptq/README.md。3. 额外排除nemotron_vl、diffusion_gemma数值与通用配方完全相同特殊之处是模型本地的disabled_quantizers.yaml单元扩展了标准排除项让非语言分支保持全精度nemotron_vl含 Nemotron-Parse在通用nvfp4_default-kv_fp8_cast数值基础上追加*vision*、*image*、*radio*、*visual*、*encoder*、*model_encoder*只量化语言解码器见 nvfp4-kv_fp8_cast.yaml其中后两个模式是 Nemotron-Parse 所必需diffusion_gemmaGemma4 MoE 骨干上的块扩散编码器-解码器文本 LLM追加*self_conditioning*排除——自条件网络是纯文本的标准 PTQ 校准数据不会驱动它其TensorQuantizerobserver 看不到输入导出时_export_quantized_weight会因缺失_amax崩溃见 diffusion_gemma/ptq/README.md。4. Checkpoint 镜像models/org/checkpoint逐字复刻单一发布 checkpoint 的量化配置多为跨组件甚至逐层的 FP8 NVFP4 混合精度映射。例如models/nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-BF16/ptq/nvfp4-mse镜像 Mamba-MoE 混合架构的逐组件方案MoE 路由专家 NVFP4 W4A4group_size 16、静态权重缩放共享专家与 Mambain/out_projFP8 逐张量KV cache FP8注意力 q/k/v、MTP 头、lm_head、潜在 MoE、Mamba conv1d 保持 BF16。九、新增配方与命名建议modelopt_recipes/README.md给出往哪里放的决策树任意模型的新组合→ 加入general/ptq/通过组合configs/单元实现遵循formats-scope-kv-mode[-algorithm]命名例如nvfp4_experts_only-kv_fp8_cast为 HF 架构调优→model_type/model_type/task/并写README.md说明与通用预设的差异放置前务必对照 checkpoint 的config.json验证精确model_type为 timm 架构调优→timm/architecture/task/镜像特定发布 checkpoint→models/org/model_id/其模型仓库路径复用主体一律抽成# modelopt-schema:标记的 snippet 并$import保持配方包装轻量。ptq.md还给出了 PTQ 配方的选型路线先按硬件匹配格式FP8 面向 HopperNVFP4 面向 Blackwellweight-only 用于低风险压缩或缺乏 NVFP4 内核的场景低并发部署从 weight-only 起步高并发服务从最窄的激活量化作用域起步MoE 用nvfp4_experts_only、稠密用nvfp4_mlp_only再按需放宽出现回归时先换校准max→mse再退作用域KV cache 以kv_fp8_cast为安全默认。十、小结modelopt_recipes/model_type/是 Model-Optimizer 配方库的架构层中枢它以 HFmodel_type为键组织配方通过目录存在即推荐的约定提供架构级默认方案通过$import snippet 机制与共享configs/层保持只存增量、不复制主体的可维护性并通过models/兄弟层承接 checkpoint 级镜像与别名。理解这一层的目录纪律、加载机制与偏差分类是正确选用乃至编写 Model-Optimizer 优化配方的关键一步——下一步建议阅读 modelopt_recipes/ptq.md 掌握全部 PTQ 方案的数值细节并在 examples/hf_ptq/hf_ptq.py 中把--recipe model_type/model_type/ptq/recipe落到实际量化流程上。赞分享人工智能大模型模型优化模型量化模型压缩【免费下载链接】Model-OptimizerA unified library of SOTA model optimization techniques like quantization, distillation, pruning, neural architecture search, speculative decoding, etc. It compresses deep learning models for downstream deployment frameworks like TensorRT-LLM, TensorRT, vLLM, etc. to optimize inference speed.项目地址https://gitcode.com/GitHub_Trending/te/Model-Optimizer点击查看免费下载相关推荐Model Optimizer 实战从 NVIDIA Hugging Face Model Hub 一键部署 FP8 量化模型到 TensorRT-LLM、vLLM 与 SGLangModel Optimizer 实战从 NVIDIA Hugging Face Model Hub 一键部署 FP8 量化模型到 TensorRT LLM、v人工智能大模型模型优化模型量化模型压缩使用 TensorRT-LLM 部署 Model-Optimizer 量化模型统一 Hugging Face Checkpoint 工作流使用 TensorRT LLM 部署 Model Optimizer 量化模型统一 Hugging Face Checkpoint 工作流 Model Opt人工智能大模型模型优化模型量化模型压缩Model-Optimizer 模型下载 Agent 实战指南Day 0 工作区中的 Hugging Face 模型获取与交接规范Model Optimizer 模型下载 Agent 实战指南Day 0 工作区中的 Hugging Face 模型获取与交接规范 本篇技术指南聚焦 NVID人工智能大模型模型优化模型量化模型压缩创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
