人工智能大模型模型优化模型量化模型压缩【免费下载链接】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点击查看免费下载ModelOpt Launcher位于本仓库tools/launcher/是一套面向大规模模型优化实验量化、训练、评估、投机解码等的作业提交框架它以 YAML 声明多任务流水线基于 NeMo Runnemo_run封装 Slurm 集群提交与本地 Docker 执行并在容器内通过 bind-mount 将本地modelopt/源码直接映射到预装位置实现改代码即生效、无需重建镜像的开发闭环。读完本文你将掌握 Launcher 的共享核心core.py分层设计、代码打包PatternPackager、ModelOpt 挂载与符号链接机制、工厂系统_factory_、全局变量插值以及类型化任务Typed Task的扩展方式并能据此编写或调试自己的流水线 YAML。Shared Corecore.py与launch.py的分层设计架构文档将 Launcher 明确划分为共享核心与入口层两层。所有与提交逻辑相关的核心能力都集中在 core.py而 launch.py 只负责装配与入口core.py ├── Dataclasses: SandboxTask, SandboxPipeline, GlobalVariables ├── Executor builders: build_slurm_executor(), build_docker_executor() ├── Job runner: run_jobs() ├── Version reporter: report_versions() ├── Factory registry: register_factory(), set_slurm_config_type() └── Default env: get_default_env() launch.py ├── imports core.py ├── slurm_config.py (env-var driven) ├── registers: slurm_factory ├── packager (LAUNCHER_DIR relative) └── launch() entrypoint对照源码可以逐项印证各组件职责数据模型层SandboxTaskcore.py#L110-L131描述单个任务字段包括script脚本路径、inline内联命令与script互斥、reqs/reqs_file容器内预装依赖、args、environment、slurm_config与skipSandboxPipelinecore.py#L233-L253聚合global_vars与task_0task_4五个任务槽位并支持allow_to_fail、note、test_level等流水线级控制GlobalVariablescore.py#L213-L230持有hf_model、hf_data、hf_local、output_dir、draft_model等共享变量。为了兼容 nemo_run 的 CLI 解析还派生出了SandboxTask0SandboxTask4五个具名槽位类core.py#L134-L157。执行器构建层build_slurm_executor()core.py#L490-L587负责把SlurmConfig翻译成run.SlurmExecutor处理容器挂载、segment拓扑块参数与requeue重排队build_docker_executor()core.py#L590-L639构造本地 Docker 执行器默认以宿主 uid:gid 运行容器并支持docker_userroot读取 root 权限路径。作业运行层run_jobs()core.py#L737-L899按顺序遍历 job_table 中的流水线任务之间通过 nemo_run 的dependencies形成串行依赖task_1在task_0结束后才启动并负责test_level过滤、默认环境变量注入、reqs的 pip 预装前缀拼接以及实验元数据落盘。版本上报层report_versions()core.py#L710-L729递归读取 git 提交哈希与分支打印 Launcher 本体及modules/下各子模块版本便于 CI 复现实验。工厂注册层register_factory()core.py#L100-L102与set_slurm_config_type()core.py#L81-L97共同支撑 YAML 中_factory_的解析后者还会把具体的SlurmConfig类型回填到各任务 dataclass让 nemo_run 的 CLI 解析器识别到真实字段类型。默认环境层get_default_env()core.py#L42-L72返回 Slurm 与本地两套默认环境变量包括TRITON_CACHE_DIR、HF_HOME、HF_TOKEN、MLM_SKIP_INSTALL1、LAUNCH_SCRIPTpython以及 specdec_bench 上传所需的 S3 凭据转发SPECDEC_BENCH_S3_*凭据不落盘进 YAML仅透传环境。入口层launch.py在模块加载时即完成装配调用set_slurm_config_type(SlurmConfig)与register_factory(slurm_factory, slurm_factory)launch.py#L49-L50随后按LAUNCHER_DIR相对路径组装打包器。launch()函数launch.py#L124-L177是唯一入口支持--yaml、hf_local、user、identity、detach、clean等参数本地 Docker 模式传入hf_local下作业目录自动切换到local_experiments/。Code PackagingPatternPackager如何把工作区送上集群Launcher 通过run.PatternPackager将源代码打包为 tar.gz 并 rsync 到集群随后解包为code/目录——这个目录严格镜像 Launcher 自身的目录结构code/ ├── modules/ │ ├── Megatron-LM/megatron/... │ └── Model-Optimizer/modelopt/... └── common/ ├── megatron_lm/quantize/quantize.sh ├── tensorrt_llm/query.sh ├── vllm/query.sh ├── eagle3/ └── query.py在launch.py中可以看到打包内容的精确装配逻辑launch.py#L100-L114始终打包examples/与common/两个目录在开发模式检测到modelopt/源码存在下还会追加modules/Megatron-LM/megatron、modules/Megatron-LM/examples、modules/Model-Optimizer/modelopt、modelopt_recipes与examples。_relative_path统一取LAUNCHER_DIR作为 tar 根目录保证解包后code/内的相对布局与本地tools/launcher/完全一致——这正是任务脚本能用modules/Megatron-LM/examples/post_training/modelopt/quantize.sh这类相对路径调用依赖的根本原因。打包器基于find遍历目录因此会跟随符号链接见下文 Symlink 一节这保证了modules/Model-Optimizer/这一符号链接指向的完整源码树能被一并打包。ModelOpt 挂载机制本地改动即时生效无需重建镜像这是 Launcher 最具特色的机制容器镜像内已预装 ModelOpt但 Launcher 会将你本地的modelopt/目录bind-mount 覆盖到容器内的 ModelOpt 安装路径上。这样开发者修改本地源码后提交的作业立即使用新代码不必为每次改动重新构建容器镜像。挂载目标由SlurmConfig.modelopt_install_path指定默认值为/usr/local/lib/python3.12/dist-packages/modeloptslurm_config.py#L44也可在 YAML 中按容器覆盖slurm_config: modelopt_install_path: /usr/local/lib/python3.12/dist-packages/modelopt运行时两种执行后端的具体挂载源不同源码中都有明确实现Slurmbuild_slurm_executor()将{job_dir}/{experiment_title}/{exp_id}/{task}/code/modules/Model-Optimizer/modelopt挂载到{modelopt_install_path}同时把相邻的modelopt_recipes目录也挂载到安装路径的兄弟目录core.py#L510-L527Dockerbuild_docker_executor()默认使用{LAUNCHER_DIR}/modules/Model-Optimizer/modelopt作为挂载源同样附带modelopt_recipescore.py#L610-L624。若不确定某个容器镜像中 ModelOpt 装在哪里可以直接在镜像里查询 Python 包的安装路径docker run --rm image python3 -c import modelopt; print(modelopt.__file__)拿到输出后把该路径写进对应任务的slurm_config.modelopt_install_path即可让挂载精准命中。modules/Model-Optimizer 符号链接避免递归嵌套的巧妙设计tools/launcher/modules/Model-Optimizer是一个指向../../..即 Model-Optimizer 仓库根目录的符号链接而非 git submodule。这样设计是为了避免launcher 位于仓库内部、却又以子模块方式嵌套整个仓库造成的递归嵌套问题Git 原生跟踪符号链接git clone后即保留无需额外初始化launch.py在开发模式下检测到链接缺失时会自动创建os.symlink(os.path.relpath(MODELOPT_ROOT, ...), _mo_symlink)launch.py#L70-L76首次运行即自愈打包器的find遍历会跟随符号链接因此打包出的code/modules/Model-Optimizer/modelopt就是完整源码树--clean参数配合该链接可对链接指向的examples/目录执行git clean -xdf清理构建产物launch.py#L139-L148。工厂系统_factory_与register_factory的解耦设计YAML 中的每个任务通过_factory_键按名称引用一个工厂由工厂负责把slurm_config段解析成具体的执行配置slurm_config: _factory_: slurm_factory nodes: 1工厂在模块导入时通过register_factory()注册到全局注册表_FACTORY_REGISTRY见 core.py#L100-L102。当前仓库提交的入口模块 launch.py 中注册的是环境变量驱动的通用工厂slurm_factory架构文档还描述了另一种入口形态在slurm.py中按SLURM_CLUSTER环境变量解析到集群特定的工厂实现该入口被 claude_code.md 与多个示例 YAML 注释引用例如uv run slurm.py --yaml ...典型调用方式为SLURM_CLUSTERcw_dfw uv run slurm.py --yaml config.yaml --yesslurm_factory本身定义在 slurm_config.py#L67-L109标注了run.cli.factory与run.autoconvert其参数全部可从环境变量注入SLURM_HOST、SLURM_ACCOUNT、SLURM_PARTITION、SLURM_QOS、SLURM_MEM、SLURM_HF_LOCAL。它返回的SlurmConfigslurm_config.py#L30-L64)是集群无关的纯数据类常用字段及其含义如下字段默认值说明host/portNone / 22Slurm 登录节点与 SSH 端口None 时按本地主机处理account/partition/qosNone /batch/ None计费账户、分区与服务质量containerTensorRT-LLM 镜像作业容器镜像modelopt_install_path/usr/local/lib/python3.12/dist-packages/modeloptModelOpt 挂载目标nodes/ntasks_per_node/gpus_per_node1 / 1 / 1节点数、每节点任务数、每节点 GPU 数time/mem04:00:00/0作业时限与内存限制srun_args[--no-container-mount-home]透传给 srun 的附加参数array/requeueNone / False数组作业与失败重排队segmentNoneSlurm--segmentN将节点钉在同一拓扑块如 GB200 NVL72 的单个 NVLink 域docker_user/localNone / FalseDocker 专用容器用户root 可读 root 权限路径与本地执行标记值得一提的是SandboxPipeline.__post_init__中有一段防御性回填逻辑core.py#L267-L303当 nemo_run 直接按 YAML 字典构造SlurmConfig时_factory_键会被静默丢弃、host保持 None导致远程连接失败。Launcher 会检测host为空的任务重新以注册的slurm_factory为基底、叠加 YAML 中显式出现的字段从而修复这一类配置丢失问题——这解释了为什么_factory_与host的配合如此关键。全局变量插值global_vars.X跨任务共享流水线 YAML 支持global_vars.X插值语法让多个任务共享同一个路径或参数避免重复维护pipeline: global_vars: hf_local: /hf-local/ task_0: environment: - HF_MODEL_CKPT: global_vars.hf_localQwen/Qwen3-8B该插值在SandboxPipeline.__post_init__中通过正则替换完成core.py#L313-L343正则global_vars\.(\w)命中时用global_vars中非 None 的字段值替换未定义的键保持原样便于排查。替换作用于任务的environmentlist 或 dict 两种形态、args、inline、reqs与reqs_file全部字段。GlobalVariablesdataclasscore.py#L213-L230定义了可用的插值键hf_model、hf_data、hf_local、output_dir、draft_model。其中draft_model的引入有明确工程背景speculative-decoding 的 MTP/EAGLE3/DFLASH 父 YAML 需要同时在定性评测与throughput_32k两个任务中引用草稿模型路径集中为一个全局变量即可单点维护避免出现YAML 引用了 schema 中不存在的键而被拒绝的断链问题。类型化任务从 YAML 到 script/args/environment 的转换基础SandboxTask是通用容器script/args/environment 三件套。类型化任务Typed Task在其上叠加结构化配置派生类持有config字段__post_init__中把 config 展开为底层的script/args/environment。架构文档给出了MegatronLMQuantizeTask的范式dataclass class MegatronLMQuantizeConfig: model: str Qwen/Qwen3-8B quant_cfg: str NVFP4_DEFAULT_CFG tp: int 4 hf_local: str /hf-local/ dataclass class MegatronLMQuantizeTask(SandboxTask): config: MegatronLMQuantizeConfig None def __post_init__(self): if self.config: self.script common/megatron_lm/quantize/quantize.sh self.args [f--calib-size {self.config.calib_size}, ...] self.environment [{TP: str(self.config.tp)}, ...]仓库中 task.py 是该范式的完整实现MegatronLMQuantizeConfigtask.py#L64-L94提供model、quant_cfg、tp/pp/ep/etp、extra_args、calib_dataset、calib_size、calib_max_sequence_length、mmlu_dataset、mmlu_fraction、mmlu_lower_bound、hf_local等带默认值的字段MegatronLMQuantizeTasktask.py#L97-L145通过幂等的materialize_from_config()把 config 展开为quantize.sh脚本、--calib-dataset-path-or-name等参数以及MLM_MODEL_CFG、QUANT_CFG、TP、PP、EP、ETP、MMLU_LOWER_BOUND等环境变量。对应 YAML 形态为task_0: _target_: common.megatron_lm.quantize.task.MegatronLMQuantizeTask config: model: Qwen/Qwen3-8B tp: 4 slurm_config: _factory_: slurm_factory需要如实说明的是在当前仓库快照中该类型化任务尚未接入SandboxPipeline。task.py的 docstring 明确指出由于 nemo_run/Fiddle 加载 YAML 时 dataclass 的__post_init__先于嵌套字段填充执行config在此时仍为 None而原先的materialize_from_config()钩子被移除以保持core.py精简因此_target_形态的 typed-config YAML 目前不会真正展开task.py#L18-L27。官方示例 megatron_lm_ptq.yaml 因此采用 raw 的script/args/environment写法并注明 typed 类保留以待重新启用。这是文档未来结构与当前源码之间一个重要的差异点使用时应以 raw 形式为准。如何新增一个类型化任务按架构文档的指引新增流程如下在common/workflow/task.py中新建任务类与 shell 脚本同目录定义 config dataclass声明可调参数与默认值继承SandboxTask在__post_init__中把 config 转换为script/args/environment在 YAML 中通过_target_引用。规划中的目录结构common/ ├── megatron_lm/quantize/task.py # MegatronLMQuantizeTask ├── megatron_lm/train/task.py # MegatronLMTrainTask (future) ├── eagle3/task.py # Eagle3OfflineTask (future) └── tensorrt_llm/task.py # TRTLLMQueryTask (future)元数据每个实验的metadata.json每次实验运行结束后Launcher 会把元数据写入experiments/title/id/metadata.json供下游工具消费CI 汇总、看板、回归追踪等。写入逻辑位于run_jobs()末尾core.py#L889-L899内容示例{ experiment_id: cicd_1773420387, job_name: Qwen3-8B_NVFP4_DEFAULT_CFG, allow_to_fail: false, note: }其中experiment_id由 nemo_run 生成job_name即 YAML 顶层的作业名allow_to_fail与note直接透传流水线级配置。实战串联一条 Megatron-LM PTQ 流水线如何跑起来以 megatron_lm_ptq.yaml 为例可以看到上述机制在真实流水线中的协同三步串行任务task_0用NVFP4_DEFAULT_CFG量化task_1用FP8_DEFAULT_CFG量化task_2对导出检查点做 TRT-LLM 的 MMLU 评估每个任务通过environment注入MLM_MODEL_CFG、HF_MODEL_CKPT、TP/PP/EP/ETP与MMLU_LOWER_BOUND提交命令一行完成本地 Docker 单卡用megatron_lm_ptq_local.yaml变体# 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这些环境变量最终被 quantize.sh 消费脚本按QUANT_CFG调用modules/Megatron-LM/examples/post_training/modelopt/quantize.sh随后可选地执行 MMLU 评估RUN_MMLU与 HF 导出RUN_EXPORT并将量化检查点持久化到/cicd/megatron-lm/${MLM_MODEL_CFG}供后续实验复用——从 YAML、环境变量到脚本的整条调用链正是工厂解析、默认环境注入与code/打包三个机制共同作用的结果。Launcher 的单元测试如 test_core_extended.py 覆盖run_jobs的环境变量合并与test_level过滤test_docker_execution.py 验证 Docker 执行路径、modelopt 挂载与 metadata 写入也为这套架构的稳定性提供了回归保障。进一步阅读architecture.md本文主题文档、configuration.mdYAML 格式、CLI 覆盖与hf_local存储约定core.py、launch.py、slurm_config.py类型化任务参考实现 task.py配套脚本 quantize.sh更多真实流水线示例见 examplesQwen3-8B、Kimi-K2.5、NVIDIA-Nemotron 系列等启动步骤见 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点击查看免费下载相关推荐ModelOpt Launcher 完整指南用 Slurm 与 Docker 统一提交量化、训练与评估任务ModelOpt Launcher 完整指南用 Slurm 与 Docker 统一提交量化、训练与评估任务 ModelOpt Launcher 是 Model人工智能大模型模型优化模型量化模型压缩Model-Optimizer ModelOpt Launcher 实战指南用 YAML 一键将量化、训练与评测任务提交到 Slurm 或本地 DockerModel Optimizer ModelOpt Launcher 实战指南用 YAML 一键将量化、训练与评测任务提交到 Slurm 或本地 Docker人工智能大模型模型优化模型量化模型压缩ModelOpt Launcher 实战指南用 SLURM / Docker 一键批量执行 HF PTQ 量化任务ModelOpt Launcher 实战指南用 SLURM / Docker 一键批量执行 HF PTQ 量化任务 本指南围绕 Model Optimizer人工智能大模型模型优化模型量化模型压缩创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考