人工智能大模型模型优化模型量化模型压缩【免费下载链接】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 仓库中tools/launcher子工具ModelOpt Launcher的配置体系系统讲解其环境变量、四种 YAML 任务格式typed task / raw SandboxTask / inline 命令 / reqs 预装依赖、多任务流水线编排、--yaml与pipeline两种入口、命令行覆盖机制以及hf_local模型与数据存储约定。读完本文你将能够独立编写、调试并提交一套量化、剪枝或推理评估的 Slurm/本地 Docker 作业管线并能借助--dryrun、--to-yaml等工具快速验证配置正确性。一、Launcher 是什么一条命令把 ModelOpt 作业提交到 Slurm 或本地 DockerModelOpt Launcher 位于 tools/launcher基于 NVIDIA 的 NeMo-Run 构建用于把 Model-Optimizer 的量化PTQ/QAT、剪枝、蒸馏与评估等作业提交到 Slurm 集群或在本机通过 Docker 直接运行。它把“跑什么脚本、用什么容器、申请多少 GPU、挂载哪些模型权重”等所有要素收敛到一份 YAML 文件里并通过命令行参数与点号路径实现逐字段覆盖。核心入口在 launch.pylaunch()函数接收job_name、job_dir、pipelineSandboxPipeline 对象、hf_local、user、identity、detach、clean等参数随后调用 core.py 中的run_jobs()完成真正的执行编排。run_jobs()内部会遍历job_table中的每个 pipeline为每个 task 构建 SlurmExecutor 或 DockerExecutor见 build_slurm_executor 与 build_docker_executor并以依赖链方式串行提交任务。快速体验方式来自 README# 本地 Docker单卡运行 PTQ 示例 cd Model-Optimizer/tools/launcher uv run launch.py --yaml examples/Qwen/Qwen3-8B/megatron_lm_ptq_local.yaml hf_local/mnt/hf-local --yes # Slurm 集群4 卡 export SLURM_HOSTlogin-node.example.com export SLURM_ACCOUNTmy_account export SLURM_HF_LOCAL/mnt/hf-local export SLURM_JOB_DIR/shared/experiments uv run launch.py --yaml examples/Qwen/Qwen3-8B/megatron_lm_ptq.yaml --yes本地与集群的差异megatron_lm_ptq.yaml面向 Slurm可配多卡/多节点而megatron_lm_ptq_local.yaml面向单卡本地 Docker 运行两者通过是否传入hf_local区分执行路径。二、环境变量远程 Slurm 提交的必选项与可选项变量说明是否必需SLURM_HOSTSlurm 登录节点主机名远程提交必需SLURM_ACCOUNT计费用的 Slurm 账号远程提交必需SLURM_JOB_DIR远端作业产物目录远程提交必需SLURM_HF_LOCAL集群上 HuggingFace 模型缓存的路径远程提交必需HF_TOKENHuggingFace API Token可选NEMORUN_HOMENeMo Run 主目录默认取当前工作目录可选这些环境变量在 slurm_config.py 的slurm_factory中被读取并作为SlurmConfig的默认值SLURM_HOST对应host、SLURM_ACCOUNT对应account、SLURM_PARTITION对应partition默认batch、SLURM_QOS对应qos、SLURM_MEM对应mem。因此远程提交时即使 YAML 里不写 host/account只要环境变量就位slurm_factory也会自动填上。此外core.py 的get_default_env()会为每个作业注入默认环境Slurm 与本地 Docker 作业都会带上TRITON_CACHE_DIR、HF_HOME、HF_TOKEN、MLM_SKIP_INSTALL1Slurm 作业额外注入LAUNCH_SCRIPTpython供 inline 命令引用见下文第四节若设置了SPECDEC_BENCH_S3_*系列变量则透传给 specdec_bench 的上传步骤避免把密钥写进 YAML。值得注意的是launch.py 在NEMORUN_HOME未设置时会打印警告并默认到当前工作目录而SLURM_USER未设置时使用本机登录用户名getpass.getuser()。三、YAML 配置格式之一Typed Task Config推荐范式Launcher 推荐把任务抽象成“有名字、有文档、有默认值”的 typed task 类。以 Megatron-LM 量化任务为例common/megatron_lm/quantize/task.py 定义了MegatronLMQuantizeConfig与MegatronLMQuantizeTaskMegatronLMQuantizeConfig提供model默认Qwen/Qwen3-8B、quant_cfg默认NVFP4_DEFAULT_CFG、tp/pp/ep/etp张量/流水/专家/专家张量并行度、calib_dataset默认abisee/cnn_dailymail、calib_size默认 32、calib_max_sequence_length默认 512、mmlu_dataset默认cais/mmlu、mmlu_fraction、mmlu_lower_bound默认 0.38、hf_local默认/hf-local/等字段MegatronLMQuantizeTask继承SandboxTask在materialize_from_config()中把 typed config 展开为script、args、environment三个普通字段。Typed 写法对应的 YAML 形如原文档示例slurm_config通过_factory_引用工厂job_name: Qwen3-8B_NVFP4_DEFAULT_CFG pipeline: task_0: _target_: common.megatron_lm.quantize.task.MegatronLMQuantizeTask config: model: Qwen/Qwen3-8B quant_cfg: NVFP4_DEFAULT_CFG tp: 4 calib_size: 32 hf_local: /hf-local/ slurm_config: _factory_: slurm_factory nodes: 1 ntasks_per_node: 4 gpus_per_node: 4重要现状提示task.py 的模块 docstring 明确说明——由于 nemo_run/Fiddle 加载 YAML 时 dataclass 的__post_init__先于嵌套字段config的填充执行MegatronLMQuantizeTask目前并未接入 SandboxPipelinetyped 形态暂时停用仓库内示例如 megatron_lm_ptq.yaml均使用下文第四节介绍的 rawscript/args/environment写法。该 typed 类被有意保留作为未来重新启用时的参考实现这正是「typed task 优于裸字段」这一设计意图的体现。四、YAML 配置格式之二Raw SandboxTask当前推荐当没有对应的 typed task 类、或需要完全掌控每个字段时使用裸的SandboxTask形态。SandboxTask的核心字段定义在 core.pyscript、inline、reqs、reqs_file、slurm_config、args、environment、yaml_file、skip。job_name: Qwen3-8B_NVFP4_DEFAULT_CFG pipeline: task_0: script: common/megatron_lm/quantize/quantize.sh args: - --calib-dataset-path-or-name /hf-local/abisee/cnn_dailymail - --calib-size 32 environment: - MLM_MODEL_CFG: Qwen/Qwen3-8B - QUANT_CFG: NVFP4_DEFAULT_CFG - TP: 4 slurm_config: _factory_: slurm_factory nodes: 1 ntasks_per_node: 4 gpus_per_node: 4environment支持「列表-单键字典」如上例nemo_run 风格和「扁平字典」两种写法tests/test_yaml_formats.py 对两种形态都有覆盖。args保持 launcher 的 shell 分词约定一个--flag value字符串在传给脚本时会展开成两个参数--flag与value与run.Script的行为一致见 core.py 的注释。实际仓库示例中megatron_lm_ptq.yaml 用同一quantize.sh跑出两条量化任务task_0 用NVFP4_DEFAULT_CFGMMLU_LOWER_BOUND0.68task_1 用FP8_DEFAULT_CFGMMLU_LOWER_BOUND0.75再由 task_2 调用 common/tensorrt_llm/eval.sh 对导出的全部 checkpoint 做 TRT-LLM 端 MMLU 评测——这是「量化 → MMLU 门槛 → 导出 → TRT-LLM 评估」三段式管线的真实写照。五、YAML 配置格式之三Inline Command免包装脚本的一行式任务除了script:指向包装.sh任务还可以直接携带inlineshell 命令适合 Megatron-Bridge 的torchrun这类单行作业。规则要点inline中支持解析global_vars.X占位符inline与args互斥——同时给非空args会触发ValueErrorcore.py 中有明确校验打包后的仓库位于运行目录下的modules/Model-Optimizer/...且运行目录是 CWD本地 launcher 用torchrun、Slurm 上改用pythonsrun必须引用$LAUNCH_SCRIPT注意写$VAR不要写${...}否则会与配置加载器的语法冲突并在environment中给它的本地取值Slurm 端 launcher 会把它覆盖为python因此ntasks_per_node必须等于gpus_per_node。inline必须是单行——CLI 层会拒绝多行值。因此 YAML 里要用折叠标量-而不是字面块|或\续行多条命令用串联。原文档给出了一个基于prune_minitron.py的剪枝示例job_name: Qwen3-8B_mbridge_prune pipeline: global_vars: output_dir: /cicd/megatron-bridge task_0: environment: - LAUNCH_SCRIPT: torchrun --nproc_per_node 2 inline: - $LAUNCH_SCRIPT modules/Model-Optimizer/examples/megatron_bridge/prune_minitron.py --hf_model_name_or_path Qwen/Qwen3-8B --pp_size 2 --prune_target_params 6e9 --output_hf_path global_vars.output_dir/Qwen3-8B-Pruned-6B slurm_config: _factory_: slurm_factory container: nvcr.io/nvidia/nemo:26.08 modelopt_install_path: /opt/venv/lib/python3.12/site-packages/modelopt nodes: 1 ntasks_per_node: 2 gpus_per_node: 2仓库中真实使用的完整 inline 示例见 mbridge_prune.yamltask_0 用$LAUNCH_SCRIPTtorchrun --nproc_per_node 4驱动prune_minitron.py完成 Nemotron-3-Nano-30B-A3B 的 MoE 剪枝含--prune_target_active_params 3e9、--score_lower_bound 0.50等剪枝门槛task_1 再用python modules/Model-Optimizer/examples/megatron_bridge/generate_vllm.py对剪枝后 checkpoint 做 vLLM 生成验证——注意该文件把slurm_config用 YAML 锚点sc与合并键: *sc复用这也是编排多任务时避免重复的实用技巧。global_vars.X的解析实现在 core.py 的SandboxPipeline.__post_init__中对environment、args、inline、reqs、reqs_file全部做正则替换未定义的变量原样保留tests/test_core.py与 test_yaml_formats.py 均有对应单测验证包括「未解析变量透传」的边界行为。六、YAML 配置格式之四任务内预装 pip 依赖reqs/reqs_file一个任务可以在容器内、命令执行之前完成 pip 安装等价于pip install [-r reqs_file] [reqs] commandreqs—— 一段原始的pip install参数串。规格符不用加引号launcher 会对每个 token 做 shell 引用因此是安全的reqs_file—— 指向requirements.txt的路径相对于运行目录即modules/Model-Optimizer/...之下。task_0: reqs: transformers5 # 或 transformers5 fire 装多个包 inline: - python .../prune_minitron.py ... task_2: reqs_file: modules/Model-Optimizer/examples/llm_eval/requirements.txt inline: - python .../lm_eval_hf.py ...两者对inline和script任务都生效也都支持global_vars.X解析。Slurm 上安装只会在每个节点的 local rank 0 执行一次背后是「以 job/step/node ID 键控的文件系统屏障」rank 0 安装并touch标记文件其余 rank 轮询等待最多 600 秒超时未出现标记则失败——这样既支持多节点任务又避免同一节点上的并发 pip 相互污染。这段屏障逻辑实现在 core.pytests/test_core_extended.py::test_reqs_inline_barrier断言了最终生成命令里包含python -m pip install transformers5 fire与[ ${SLURM_LOCALID:-0} -eq 0 ]等关键片段。真实用法可参考 mbridge_prune.yaml剪枝任务声明reqs: transformers5因为 pruned-HF 保存依赖transformers5而容器镜像版本nvcr.io/nvidia/nemo:26.04的选择也与该约束强相关注释说明 26.06 会移除transformers5。七、多任务流水线顺序执行与global_vars共享Pipeline 内任务严格串行——task_1只有在task_0完成后才开始依赖链通过 run_jobs 的dependencies[dependency]实现。若某个任务设置了skip: true或test_level高于命令行给定的test_level则会被跳过见 core.py。job_name: Qwen3-8B_quantize_export pipeline: global_vars: hf_model: /hf-local/Qwen/Qwen3-8B task_0: script: common/megatron_lm/quantize/quantize.sh environment: - HF_MODEL_CKPT: global_vars.hf_model slurm_config: _factory_: slurm_factory nodes: 1 task_1: script: common/megatron_lm/export/export.sh environment: - HF_MODEL_CKPT: global_vars.hf_model slurm_config: _factory_: slurm_factory nodes: 1global_vars.X语法让同一值在多任务间共享。GlobalVariablesdataclass 定义在 core.py内置hf_model、hf_data、hf_local、output_dir、draft_model五个字段其中draft_model用于投机解码场景SPEED-bench 的 MTP/EAGLE3/DRAFT_TARGET/DFLASH 父 YAML 通过它在--draft_model_dir处引用草稿模型路径。上述示例为示意性质注释说明导出脚本可能尚不存在仓库中更完整的「剪枝 → vLLM 生成」两段式真实样例见第六节提到的 mbridge_prune.yaml。八、两种提交入口--yaml与pipeline--yaml config.yaml推荐顶层键直接映射为launch()函数参数配置内包含job_name与pipelineuv run launch.py --yaml examples/Qwen/Qwen3-8B/megatron_lm_ptq.yaml --yespipelineconfig.yaml裸的SandboxPipeline没有job_name包裹需在命令行补上uv run launch.py pipelinebare_pipeline.yaml job_namemy_job --yes两种格式在 tests/test_yaml_formats.py 中都有结构验证--yaml格式要求job_namepipeline内含task_0、environment、slurm_configpipeline格式则直接把task_0/task_1/allow_to_fail/skip等平铺在顶层。除这两种之外SandboxPipeline还支持task_configs: [worker.yaml, ...]列表形态——每个文件是一份独立的script slurm_config含_factory_在__post_init__中通过工厂注册表解析成任务对象见 core.py 的create_task_from_yaml与测试 test_yaml_formats.py。九、CLI Overrides点号路径逐字段覆盖任何参数都可在命令行覆盖路径即 YAML 的层级嵌套# 改节点数 uv run launch.py --yaml config.yaml pipeline.task_0.slurm_config.nodes2 --yes # 换容器镜像 uv run launch.py --yaml config.yaml \ pipeline.task_0.slurm_config.containernvcr.io/nvidia/tensorrt-llm/release:1.2.0 --yes # 改 typed config 字段 uv run launch.py --yaml config.yaml pipeline.task_0.config.tp1 --yes覆盖机制的底层launch.py注册slurm_factorylaunch.py并调用set_slurm_config_type(SlurmConfig)launch.py后者把SandboxTask及各SandboxTask0..4子类的slurm_config字段类型运行时替换为具体的SlurmConfig使 nemo-run 的 CLI 解析器能正确理解嵌套字段core.py。SlurmConfigslurm_config.py字段包括host、port默认 22、account、partition默认batch、qos、container、modelopt_install_path默认/usr/local/lib/python3.12/dist-packages/modelopt、container_mounts、srun_args、array、requeue、nodes、ntasks_per_node、gpus_per_node、time默认04:00:00、mem、local、segment等。其中docker_user仅本地 Docker 生效默认uid:gid避免产物归 root 所有设为root可读取镜像内 root 专属路径如 NeMo 的/opt/Megatron-Bridgegpus_per_node为None时不写 GRES兼容没有 GPU GRES 暴露的集群否则合法作业会因--gpus-per-node失败segment--segmentN用于把作业节点钉在单个拓扑块内如 GB200 NVL72 的一个 NVLink 域None表示交给调度器自由放置requeue: true会同时把 executor 的 retries 抬到至少 3scontrol requeue依赖TORCHX_MAX_RETRIES SLURM_RESTART_COUNT见 core.py。此外SandboxPipeline.__post_init__core.py还内置了一重防御当 nemo_run 直接由 YAML 构造SlurmConfig时_factory_键会被静默丢弃、导致hostNone连接崩溃launcher 会检测host为空并重新调用slurm_factory作为基底再用「YAML 中显式出现的键」覆盖默认值。十、常用 Flags 速查Flag说明--yes/-y跳过确认提示-v冗长输出--dryrun只打印解析后的配置不真正执行--to-yaml output.yaml把解析后的配置 dump 到文件detachtrue提交后立即返回不阻塞等待这些 Flag 由 nemo_run 的 CLI 层提供launch.py通过run.cli.entrypoint装饰launch()见 launch.py。--dryrun与--to-yaml组合是调试配置的标准姿势先 dryrun 检查解析结果再 dump 成 YAML 存档或给同事评审。另外两个实用参数hf_local/path本地 Docker 运行时显式指定模型根目录会自动把job_dir改到local_experiments见 launch.py--clean仅限 dev checkout对 symlink 指向的examples目录执行git clean -xdf。十一、模型与数据存储hf_local目录约定所有 pipeline YAML 都把hf_local当作模型权重与数据集的路径前缀它应当是一个自管理的、镜像 HuggingFace Hub 层级结构的目录/hf-local/ ├── Qwen/Qwen3-8B/ ├── meta-llama/Llama-3.1-8B/ ├── abisee/cnn_dailymail/ └── cais/mmlu/使用专用目录优于默认的 HuggingFace 缓存~/.cache/huggingface核心原因在文档与代码中均有体现多作业并发写同一个共享缓存容易引发缓存损坏core.py的默认环境把HF_HOME指到共享挂载/{title}/hf-cache并注释说明共享缓存归 CI 账号所有、会阻塞其他用户的缓存锁。三种典型操作# 填充目录 huggingface-cli download Qwen/Qwen3-8B --local-dir /hf-local/Qwen/Qwen3-8B # 命令行覆盖挂载路径 uv run launch.py --yaml config.yaml pipeline.task_0.config.hf_local/mnt/models/ --yes # 直接从 Hub 下载不走本地缓存 uv run launch.py --yaml config.yaml pipeline.task_0.config.hf_local --yes容器侧的挂载路径由slurm_factory的默认container_mounts决定{SLURM_HF_LOCAL:-/hf-local}:/hf-localslurm_config.py。本地 Docker 场景由build_docker_executor无条件追加{hf_local}:/hf-local卷core.pySlurm 场景则由build_slurm_executor在默认挂载之外追加三个关键卷作业产物目录挂到/scratchspace、实验目录挂到/{experiment_title}以及把打包进code/的本地modelopt与modelopt_recipes源码分别 bind-mount 到modelopt_install_path及其同级的modelopt_recipescore.py。这就是「容器内置 ModelOpt但本地改动无需重建镜像即可生效」的 mount 机制——在 architecture.md 中有完整说明查找镜像内安装路径可用docker run --rm image python3 -c import modelopt; print(modelopt.__file__)。十二、配置实战从 dryrun 到提交的完整流程综合以上各节一套标准的配置验证与提交流程为改配置编辑tools/launcher/examples/下的 YAML或新建自己的确定job_name、pipeline.global_vars与各task_N的script/inline、environment、slurm_configdryrun 验证uv run launch.py --yaml your_config.yaml --dryrun确认解析结果与预期一致--to-yaml resolved.yaml存档本地冒烟小规模先跑本地 Docker如uv run launch.py --yaml your_config.yaml hf_local/mnt/hf-local --yes远程提交导出SLURM_HOST、SLURM_ACCOUNT、SLURM_JOB_DIR、SLURM_HF_LOCAL再uv run launch.py --yaml your_config.yaml --yes需要立即返回时加detachtrue结果确认每个 experiment 会在experiments/title/id/下写入metadata.json含experiment_id、job_name、allow_to_fail、note见 core.py 与 architecture.md供下游工具消费。整个tools/launcher的测试套件tests/ 共 64 个单元测试可作为配置正确性的权威参照test_yaml_formats.py覆盖四种 YAML 形态与global_vars解析test_slurm_config.py覆盖环境变量驱动的工厂逻辑test_core_extended.py覆盖 inline/reqs 屏障等运行时行为。若需进一步了解 Launcher 的架构设计shared core、PatternPackager 打包、ModelOpt symlink、factory 系统可继续阅读 tools/launcher/docs/architecture.md--yaml与pipeline两种入口的快速起步示例见 tools/launcher/README.md。赞分享人工智能大模型模型优化模型量化模型压缩【免费下载链接】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 Launcher 实战指南用 YAML 一键将量化、训练与评测任务提交到 Slurm 或本地 DockerModel Optimizer ModelOpt Launcher 实战指南用 YAML 一键将量化、训练与评测任务提交到 Slurm 或本地 Docker人工智能大模型模型优化模型量化模型压缩Model-Optimizer 集群实战基于 SLURM 的容器化作业提交、监控与镜像认证完整指南Model Optimizer 集群实战基于 SLURM 的容器化作业提交、监控与镜像认证完整指南 导读 本文是 NVIDIA Model Optimizer人工智能大模型模型优化模型量化模型压缩ZenML Hydra 配置管理实战以 YAML 与 CLI 覆盖驱动 FashionMNIST 训练管线ZenML Hydra 配置管理实战以 YAML 与 CLI 覆盖驱动 FashionMNIST 训练管线 Hydra 负责「WHAT」超参数、模型架构MLOps机器学习后端工作流自动化AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
