人工智能大模型模型优化模型量化模型压缩【免费下载链接】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点击查看免费下载本指南以仓库内置的 GPQA Diamond 任务参考 为核心讲解如何在 Model-Optimizer 项目的 NELNeMo Evaluator Launcher评估体系中将 GPQA DiamondAA 4-choice MCQ 版本作为evaluation.tasks列表中的一个任务接入完成从 YAML 配置、dry-run → canary → 全量运行到从 MLflow 中提取gpqa_pass_at_1分数的完整闭环。读完本文你将掌握ns_gpqa任务的参数语义num_repeats、prompt_config、其与example_eval.yaml模板的拼接方式以及如何在量化/基线模型对比中正确提取并验证该指标。GPQA Diamond 任务是什么GPQAGraduate-Level Google-Proof QADiamond 是面向研究生级别科学问题的多项选择题基准Diamond 子集是其最高难度分层。在 Model-Optimizer 的评估技能体系中该任务被封装为 nemo-skills harness 下的ns_gpqa任务并采用Artificial AnalysisAAIndex v2 的 4 选 1 多选题提示prompt模板运行即任务参考中明确写明的参数组合harnessnemo-skills ns_gpqa提示模板AA 4-choice MCQprompt_configeval/aai/mcq-4choices重复次数num_repeats: 16需要说明的是任务参考中标注的 Reference 指向 NVIDIA NeMo Evaluator 官方基准文档外链此处不展开本文内容均以仓库内实际文件为准。从源码结构看该任务是 AA Index v2 套件 的组成部分——当用户请求 AA / Artificial Analysis 评估时技能会按 SKILL.md 中的 AA 规则把recipes/tasks/aa/下的多个任务合并生成一个多任务配置GPQA Diamond 是该套件中面向短上下文、模型计算密集型model-bound的代表任务。运行前提与 .env 配置ns_gpqa属于 nemo-skills 任务对运行环境有明确要求对应 SKILL.md 的 Step 1 与 env.exampleNEL 已安装执行nel --version检查缺失时pip install nemo-evaluator-launcher。工作区.env文件从技能目录的模板复制到工作区根目录即运行nel的目录不要放在技能目录内cp $SKILL_DIR/recipes/env.example .env set -a source .env set a必填键HF_TOKEN模型/数据集下载必需DUMMY_API_KEYdummynemo-skills 任务的硬性要求——nemo-skills 任务硬性要求服务端点的api_key_name环境变量在评测容器内有值见 example_eval.yaml 中evaluation.env_vars.DUMMY_API_KEY: lit:dummy的注释说明NEMO_EVALUATOR_TRUST_PRE_CMD1允许pre_cmd执行。需要注意GPQA Diamond 是符号判分任务symbolic grading不依赖 judge 端点因此与 HLE、AA-LCR 等 judge 型任务不同INFERENCE_API_KEY/INFERENCE_JUDGE_URL并非必需参考 env.example 中对各键用途的区分。在 evaluation.tasks 中接入 ns_gpqa任务参考给出的 YAML 片段是接入的核心。将它放在顶层evaluation.tasks列表中- name: ns_gpqa container: nvcr.io/nvidia/eval-factory/nemo-skills:26.03 nemo_evaluator_config: config: params: extra: num_repeats: 16 args: prompt_configeval/aai/mcq-4choices各字段语义如下字段含义name任务名ns_gpqanemo-skills 前缀ns_标识其 harnesscontainer评测容器镜像nvcr.io/nvidia/eval-factory/nemo-skills:26.03pyxis 加载时需要registry#path:tag形式非 DockerHub 镜像见 launcher-workflow.md 的配置放置注意事项nemo_evaluator_config.config.params.extra.num_repeats每个问题的采样重复次数本任务固定为16直接决定最终指标中的avg-of-N的 N 值extra.args传给 harness 的 Hydra 风格覆写prompt_configeval/aai/mcq-4choices即强制使用 AA 的 4 选 1 MCQ 提示模板在完整模板中拼接仓库的 example_eval.yaml 已经内置了完全相同的ns_gpqa任务块含num_repeats: 16与mcq-4choices提示并把它作为 AA 对齐模板的默认单任务起点。该模板同时定义了配套的部署与运行约定例如部署统一放在deployment.command的vllm serve /checkpoint字符串中--served-model-name必填否则 vLLM 以/checkpoint为模型名提供服务和评测请求会 404优先使用集群上已有的checkpoint_path而非hf_model_handle后者在当前 NEL 中不能可靠挂载到/checkpoint会触发HFValidationError采样参数temperature: 1.0、top_p: 0.95、max_new_tokens: 65536推理模型非推理模型用 16384取自模型卡execution.auto_export.destinations: [mlflow]是自动导出到 MLflow 的必需触发器缺失则运行结果不会被上传。关键参数深入num_repeats 与 avg-of-Nnum_repeats: 16不是随意取值它与指标的聚合方式直接绑定。任务参考的分数提取一节明确指出最终指标为gpqa_pass_at_1_avg-of-N_symbolic_correct其中N 即重复次数因此本任务实际上报的是gpqa_pass_at_1_avg-of-16_symbolic_correctpass_at_1单次采样即答对k1 的 passk 口径avg-of-N对同一问题重复采样 N 次后的正确率取平均用多次采样抑制单次采样方差得到更稳定的任务级正确率symbolic_correct采用符号/规则判分比对标准答案与 judge 判分LLM 判官相对这也是该任务无需配置 judge 端点、完全离线自洽的原因。任务参考同时给出兜底规则如果重复次数未知就使用 MLflow 中可用的最高avg-of-N指标。因此num_repeats一旦在配置中改变提取指标名必须同步改变例如改为 8 则应读取gpqa_pass_at_1_avg-of-8_symbolic_correct否则会把错误口径的分数当作结果。分数提取从 MLflow 读取任务参考定义的规范分数提取方式0-100 分制如下Result (0-100):gpqa_pass_at_1_avg-of-N_symbolic_correct操作要点结合 launcher-workflow.md 的 shortcut 路径说明与 example_eval.yaml 的 export 块确保自动导出生效execution.auto_export.destinations: [mlflow]必须存在且需设置execution.cpu_partition自动导出是独立的纯 CPU sbatchGPU 分区会以Cannot find GPU specification拒绝它导致导出被静默丢弃。export.mlflow 块使用字面量experiment_name/description/tags不得使用${deployment.*}/${evaluation.*}交叉引用自动导出在提交时解析作用域不含这些节点会报Interpolation key not found。其中temperature/top_p/max_new_tokens标签是 MLflow 中采样配置的唯一可查询记录NEL 不把它们记为 run params必须与顶层params保持一致并在同一处编辑同步更新。读取分数从对应 MLflow run 中读取gpqa_pass_at_1_avg-of-16_symbolic_correct字段数值已在 0-100 区间内可直接用于基线 vs 量化模型的对比对比请使用compare-results技能。运行流程dry-run → canary → 全量ns_gpqa遵循 NEL 的标准三阶段门控SKILL.md 与 launcher-workflow.md建议严格按序执行# 1. dry-run校验配置、部署命令与任务列表 nel run --config recipes/examples/example_eval.yaml --dry-run \ -o deployment.checkpoint_path/path/to/quantized/checkpoint \ -o deployment.served_model_namemy-model-nvfp4 \ -o execution.hostnameslurm_host \ -o execution.accountslurm_account \ -o execution.output_dir/path/to/output # 2. canary用极少量样本验证日志与并行度2 samples nel run --config ... \ -o evaluation.nemo_evaluator_config.config.params.limit_samples2 # 3. 全量正式评分运行 nel run --config ... -t ns_gpqa其中-t ns_gpqa可只运行该单任务。canary 阶段应检查服务端是否成功加载 checkpoint、评测日志有无Traceback/OOM/timeout、样本是否全部完成打分。并行度调优要点GPQA Diamond 在 AA 套件中属于短上下文、模型/GPU 计算瓶颈型model-bound任务参考 parallelism.md 的套件维度建议顶层parallelism每个 benchmark 客户端保持的在途请求数按该任务可无抢占的 KV 容量设置即可无需像 AA-LCR 那样降低覆盖--max-num-seqs单副本同时解码的序列数需按所有任务中的最大 parallelism反算max-num-seqs ceil(max parallelism across tasks / DP)因为部署必须能服务最繁忙的任务8×B200 的示例参考dense 9B NVFP4 模型在num_repeats1198 个请求请求受限时设parallelism256, max-num-seqs32num_repeats16时请求量约 3168容量受限应从较低值起调仅在Preempted N为 0 时上调拓扑遵循“最小 TP、最大 DP”原则单卡能放下就用TP1, DPGMoE 模型需加--enable-expert-parallel。运行后验证不要只看分数在报告任何分数之前需按 run-validation.md 完成运行验证——不能因为存在results.yml就认定运行有效扫描 client/server/SLURM/judge/代码执行日志中的Traceback、Exception、ERROR、FAILED、OOM、Killed、timeout、rate limit等关键字核对样本账目期望样本数/重复数 vs 实际完成并打分的样本数确认无意外丢弃/跳过/失败的样本对每个任务完成Timeout 与 Output-Limit 记账finish_reason: length之类终止元数据区分输出上限、上下文耗尽与 agent 步数/总 token 限制覆盖率、超时、输出上限各列需要明确的分母推理模型运行需确认 reasoning 痕迹在打分前被正确剥离且use_reasoning: true与模型类型匹配推理模型开、instruct 模型关见 example_eval.yaml 中 adapter_config 注释SLURM walltime 超时属于预期的续跑事件NEL 通过依赖作业链从缓存续跑不要一看到超时就判定运行失败。对于基线 vs 量化模型对比还需执行External Baseline Sanity Check在模型卡或 Artificial Analysis 上查找同一精确模型同变体、同基准/版本/指标/推理模式/采样协议的公开分数双方换算到 0-100 后绝对差 ≈ 5 个百分点以内才视为通过验证不匹配的分数不得视为可比。与其他 AA 任务的取舍ns_gpqa常与 AA 套件中的其他任务合并成多任务配置完整任务参考见 recipes/tasks/aa/它们在配置形态与瓶颈特征上差异明显合并前应逐个阅读对应参考任务判分方式关键配置差异并行度特征ns_gpqaGPQA Diamond符号判分symbolic_correct仅需num_repeatsmcq-4choices提示短上下文可用顶层默认ns_ifbench提示遵循宽松正确率prompt_loose_accuracy仅需num_repeats: 5短上下文模型瓶颈ns_hle_aaHLEjudge 判分judge_correct需配置 judgemodel_id/url/api_keyhle_strict_judge: truejudge 端点限流优先ns_aa_lcrAA-LCRjudge 判分equality checker部署需--max-model-len 196608以上parallelism必须设低于顶层长上下文~120K 输入KV 受限 judge 受限ns_scicode沙箱代码执行需要多次提交取均值沙箱槽位受限要点GPQA Diamond 是 AA 套件中唯一既无 judge 依赖又短上下文的符号判分任务因此它最适合作为端到端验证量化模型部署正确性的“第一块试金石”——配置最简、无外部端点、指标口径固定。但需注意 AA 套件生成的聚合结果不包含 GDPVal与官方公开的 AA Index含 GDPVal不可直接对比应逐任务报告分数SKILL.md。小结GPQA Diamond 在 Model-Optimizer 评估体系中的接入路径非常清晰以 gpqa_diamond.md 的任务参考为基准在 example_eval.yaml 模板的evaluation.tasks列表中放置ns_gpqa任务块num_repeats: 16 AA 4-choice 提示经 dry-run → canary → 全量三段门控运行最终从 MLflow 提取gpqa_pass_at_1_avg-of-16_symbolic_correct。在整个过程中num_repeats决定指标口径avg-of-N 的 N、符号判分决定其无需 judge 端点、短上下文决定其并行度可沿用顶层默认值——这三条特征共同构成了该任务“配置最简、最适合作为量化模型评估起点”的定位。赞分享人工智能大模型模型优化模型量化模型压缩【免费下载链接】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 实战基于 nemo-evaluator-launcher 的 LLM 评估全流程指南运行 / 监控 / 调试 / 分析Model Optimizer 实战基于 nemo evaluator launcher 的 LLM 评估全流程指南运行 / 监控 / 调试 / 分析 本人工智能大模型模型优化模型量化模型压缩Model-Optimizer 评估运行指南基于 nemo-evaluator-launcher 的 INPUT → EXPLORE → ACT 三阶段实践Model Optimizer 评估运行指南基于 nemo evaluator launcher 的 INPUT → EXPLORE → ACT 三阶段实践人工智能大模型模型优化模型量化模型压缩Garnet 集群复制Replication完全指南Attach/Sync 工作流、分片 AOF 与读一致性协议Garnet 集群复制Replication完全指南Attach/Sync 工作流、分片 AOF 与读一致性协议 本篇文章系统讲解 Microsoft G人工智能大模型模型优化模型量化模型压缩上一篇CANN/asc-devkit Mins矢量计算下一篇Zig语言服务器ZLS常见问题解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考