Nemotron Customize

NVIDIAOfficialCreated by NVIDIA Nemotron Team

Skill
Tool integration
Agent tooling
Apache-2.0
Medium risk

From the author

Plan, configure, and chain repo-native Nemotron customization steps into single-step or multi-step pipelines: curation, translation, SFT/PEFT (AutoModel or Megatron-Bridge), pretraining/CPT, RL alignment (DPO/RLVR/GRPO/RLHF), BYOB/MCQ benchmarks, checkpoint conversion, ModelOpt optimization, env profiles, and evaluation of trained checkpoints or existing/hosted endpoints. Use when a request names a Nemotron step or workflow, or asks to clean, translate, train, fine-tune, align, convert, optimize, evaluate, or compose these into a pipeline. Do NOT use for frontend/dashboard/visualization work, generic ML advice, billing/access, or non-Nemotron coding tasks.

— the description by NVIDIA Nemotron Team

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The nemotron-customize skill provides a structured approach to planning and executing model customization pipelines within the Nemotron repository. It enables users to chain specific steps such as curation, translation, SFT/PEFT, pretraining, RL alignment, and evaluation. The skill emphasizes artifact-based composition, ensuring that data outputs from one step correctly feed into the next. It requires users to provide concrete values like model paths and hardware configurations, and it enforces safety by requiring environment profiles for remote execution and preventing the exposure of sensitive credentials.

What it does

Plans multi-step DAGs for model customization based on artifact compatibility.
Configures existing Nemotron steps by creating new YAML files in the step's config directory.
Validates artifact wiring between pipeline stages.
Provides commands for running single-step or multi-step training and evaluation workflows.
Enforces safety by requiring environment profiles and redacting sensitive information.
Routes requests to appropriate catalog steps based on the user's end goal.

When to use it

When you need to fine-tune, pretrain, or align a Nemotron model.
When you need to curate or translate training data using repository-native tools.
When you need to evaluate or benchmark a model endpoint.
When you need to convert checkpoints between Hugging Face and Megatron formats.
When you need to compose multiple customization steps into a single pipeline.

Advantages

Ensures pipeline consistency by using artifact-based composition.
Maintains repository integrity by requiring new configs instead of modifying existing ones.
Provides a clear, reproducible workflow for complex training tasks.
Reduces errors by validating hardware and configuration constraints before execution.

Usage examples

“I need to fine-tune a Hugging Face model using LoRA on 2 GPUs.”: The agent will route the request to peft/automodel, collect the necessary paths and parameters, and provide a command to run the fine-tuning process.
“Create a pipeline for data preparation and SFT for a Super3 model.”: The agent will plan a DAG consisting of data_prep/sft_packing followed by sft/megatron_bridge, verify the artifact chain, and guide you through creating the required configs.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/nvidia/nemotron-customize/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip nemotron-customize.zip -d .agents/skills

Documentation by NVIDIA Nemotron Team

nemotron-customize

IMPORTANT: Read this file before answering any nemotron-customize, Nemotron customization, Curator curation, translation, SFT, PEFT, RL, conversion, optimization, checkpoint or existing/hosted-endpoint evaluation, or multi-step pipeline request. This applies whether the user names one step or asks you to compose several steps into a pipeline.

Evaluation requests count even when no training is involved: "evaluate", "benchmark", "smoke test", or "score" an existing/hosted endpoint, an API/model ID, or a deployed model all route to eval/model_eval. Read this skill for those too.

Purpose

Turn a model-customization request into a repo-native Nemotron step pipeline. Plan the DAG, validate artifact wiring, and create only the YAML/config files needed to run existing steps.

Use this skill only for inspecting, configuring, validating, running, or submitting existing Nemotron steps or multi-step training/customization pipelines. For frontend, dashboard, visualization, generic ML advice, billing/access, or unrelated coding tasks, stop with a short scope note and do not inspect the step catalog or edit files in that turn.

Prerequisites

A checkout of the Nemotron repo with src/nemotron/steps/ present; run from the repo root.
uv available to invoke uv run nemotron steps ....
For remote execution: an env profile TOML (NEMOTRON_ENV_FILE or env*.toml) with a section matching the selected step.
For hosted services (translation, hosted eval): the auth environment variable expected by the step (for example NVIDIA_API_KEY), exported in the environment — never inlined or committed.
User-provided concrete values (model/checkpoint, data paths, output dir, hardware/GPU count) before any command is presented as runnable.

Limitations

Does not invent new catalog steps. When no existing step, runner, recipe, CLI, or config can satisfy the request, it names the gap (Explorer mode) instead of fabricating a step.
Produces YAML/config for existing steps; new Python/shell is out of scope except in Explorer mode after the gap is approved.
Not for deployment-only/serving, frontend, dashboards, generic ML advice, or non-Nemotron tasks.
Does not guess concrete values (paths, model IDs, GPU counts, profiles); it asks or returns Blocked when they are missing.

Core Rule

Use bundled references first. The references/ folder is the first decision surface for routing, artifacts, patterns, hardware heuristics, and command shape. Use src/nemotron/steps/... only as a live verification/fallback source when you need exact current config fields, manifests, runner imports, or details missing from bundled references.

If sources disagree:

Checked live repo files win for exact execution.
Bundled references win for initial routing and planning.
Upstream docs/context packs are used only for exceptional code generation or library API details.

Before You Begin

Read this SKILL.md workflow and the relevant bundled reference before opening repo source files.
Route from references/CATALOG.md and references/ARTIFACTS.md before any broad repo exploration. Once a route is determined, verify only the selected live step/config/env files needed for the answer.
Do not emit commands with fake paths, placeholder model IDs, guessed task IDs, guessed batch profiles, or default auth variable names presented as facts. Ask for missing concrete values or return a Blocked handoff.
Use references/COMMANDS.md as the authoritative checklist before finalizing configs or execution commands.
For pipeline requests, plan before editing. Do not create or modify files until the DAG, artifact edges, required inputs, and validation checks are stated and approved.
For one-shot command requests, prefer a complete parameterized command in one response over exploratory prose, but only after required inputs are known. If the user already provides the needed values and asks for only a command, answer with the command first and keep explanation minimal.
Output discipline (keeps responses tight): emit one command block per step, include only flags the step actually defines, and add no speculative or invented flags. Keep narrative to a few lines — the command plus the required safety/profile callouts, not a tutorial. Do not restate reference content the user did not ask for.
Do not spawn subagents for one-shot command lookup. Use the bundled command reference directly; verify only the selected step if needed.

Safety

Keep Bash scoped to repo-safe commands such as uv run nemotron steps ..., targeted tests, git status/diff, and config validation. Never run environment dumps (env, printenv, broad export) or commands that expose secret values. For remote submissions, destructive changes, or expensive launches, confirm before execution.

When inspecting env/config files, avoid printing whole files that may contain secrets. Use targeted reads, report only section names and env-var names, and redact values for fields containing token, key, secret, password, credential, or auth.

Reference Map

Question	Read first	Live fallback / verification
Which step or category fits?	`references/CATALOG.md`	`uv run nemotron steps list/show`, then selected `step.toml`
Do artifacts chain?	`references/ARTIFACTS.md`	`src/nemotron/steps/types.toml`
What run shape should I emit?	`references/COMMANDS.md`	checked-in config YAML plus active profile TOML
Remote profile generation or selection	`references/COMMANDS.md`	active `NEMOTRON_ENV_FILE`, `env.toml`, or `env.*.toml`
What hardware/backend should I recommend?	`references/HARDWARE.md`	selected step `[[models]]` and `[[strategies]]`
Which cross-step guardrails apply?	`references/PATTERNS.md`	`src/nemotron/steps/patterns/<id>.md`
How do I run the full workflow?	`references/WORKFLOW.md`	selected step configs, `step.py`, and runners
Which upstream library API should generated code use?	`references/context/index.toml` -> matching pack	selected `step.py`, `_runners/`, upstream docs
New project scaffold, only when existing repo code cannot support the request	`references/act/PROJECT.md`	existing repo project/recipe shape
Per-stage code rules, only when existing repo code cannot support the request	`references/act/STAGE.md`	selected `step.py` and shared runner

Do not start by reading category READMEs or step.toml for ordinary decisions. Select candidates from bundled references, then verify exact live details before writing configs or final commands.

Routing

Use references/CATALOG.md as the authoritative home for step selection and route-specific fast paths. Use ARTIFACTS.md, PATTERNS.md, and HARDWARE.md only to resolve artifact, cross-step, or hardware constraints after the catalog narrows the route.

Each step is independent and stitching steps together is your job. Compose any pipeline by artifact matching from the user's end goal: chain a step only when the next step consumes an artifact type nothing upstream already produces. Do not rely on fixed, named step combinations.

Instructions

Follow the flow that matches the request: a recommendation/plan, a single-step command, or a multi-step pipeline. In all cases, route from the bundled references first, gather required inputs, and verify the selected live step before presenting anything as runnable.

Recommendation Response

Use this shape for planning answers:

Decision, Why, Required inputs, Config/command, Avoid, and Next step. Call out the stack to avoid when the user's constraints make it a poor fit.

Whenever the answer includes a command that touches a hosted service or remote execution, also state, in the answer:

The auth env-var name and that its value must be exported in the environment, never inlined or committed (never print the value).
For --batch/--run, the env TOML profile prerequisite; if no profile exists, mark the command Blocked or give the local --dry-run shape.

Single-Step Command Flow

Confirm repo root has pyproject.toml and src/nemotron/steps/.
Read references/CATALOG.md and the selected section of references/COMMANDS.md.
Verify the selected live step with uv run nemotron steps show <step_id> when available, or the selected step.toml when the CLI is unavailable.
Read the requested checked-in config or user overlay before emitting the command.
For remote execution, read NEMOTRON_ENV_FILE or repo-root env*.toml and pick an actual section whose profile matches the step.
Emit the full command in one reply with the source tier: Verified, Repo-grounded, Reference-grounded, or Blocked.

Canonical command shapes live in references/COMMANDS.md.

Pipeline Workflow

For pipelines with two or more stages, use Orient -> Plan -> Act -> Verify. Read references/WORKFLOW.md for the phase checklist.

Orient from bundled references and user constraints.
Plan a DAG with artifact types, configs, patterns, and validation checks.
Wait for approval before writing configs or code.
Act with YAML/config-only changes whenever an existing step can satisfy the request.
Verify every generated YAML, artifact edge, command, and README command before reporting completion.

Catalog Mode

Use when the request maps to existing steps. Fast path:

references/CATALOG.md -> references/ARTIFACTS.md -> references/COMMANDS.md -> verify selected live manifest/config/profile -> add a new named config under the selected step's config/ directory.

Customization Surface

Always customize through the step catalog under src/nemotron/steps/. Never divert to alternate recipe CLIs such as src/nemotron/cli/commands/super3/ or .../nano3/, even for Super3/Nano3 work. If a request seems to need those, map it back to the equivalent catalog step (e.g. sft/megatron_bridge).
Make customizations as NEW config files inside the selected step's src/nemotron/steps/<cat>/<step>/config/ directory, for example src/nemotron/steps/sft/megatron_bridge/config/my_super3.yaml.
Never edit the checked-in default.yaml, tiny.yaml, other shipped configs, step.toml, step.py, or shared runners. Adding a new config file beside them is the expected and only customization write.
Base new configs on the checked-in default.yaml schema (read it, copy the needed fields), then override only what the request requires.

Explorer Mode

Use only after confirming no existing step, runner, recipe, CLI, or YAML config surface can satisfy the request. Full procedure lives in references/WORKFLOW.md.

Configuration Alignment

Surface these constraints before commands or config writes:

SFT packing pack_size, Megatron-Bridge seq_length, packed sequence size, tokenizer, and chat template must match.
Prepared packed_parquet and binidx are tokenizer-locked; rebuild after tokenizer, chat-template, sequence-length, split, or blend changes.
Megatron-Bridge global batch size must be divisible by data-parallel size; start distributed validation with micro batch size 1.
TP/PP/CP/EP choices must fit GPU count, memory, topology, and model divisibility.
LoRA merge requires the exact base checkpoint/model and tokenizer used during adapter training.
Conversion/eval of Megatron checkpoints should point at a concrete iter_* checkpoint, not a parent run directory.
Hosted eval and translation configs store auth env-var names only, not values.

Operational Nuances

Smoke configs (tiny.yaml, tiny_chat.yaml) are wiring tests, not quality evidence.
${art:...} references belong in recipe-backed configs; standalone YAML uses plain paths.
Keep pretraining bin/idx data and blend.json from the same run/release.
Write customized configs as new files in the step's src/nemotron/steps/<cat>/<step>/config/ directory; never modify the checked-in default.yaml or other shipped configs.
For LoRA, preserve the exact base checkpoint and tokenizer/template metadata needed by later merge/eval.
For translation and hosted eval, mention auth environment variable names only, never values.

Boundaries

Do:

Always route through the step catalog under src/nemotron/steps/; never use alternate recipe CLIs (src/nemotron/cli/commands/super3|nano3/...).
Reuse repo CLIs, runners, recipes, steps, and checked-in configs first.
Customize by adding a new config under the step's config/ directory; base it on default.yaml rather than copying it blindly.
Validate artifact edges and cite patterns that changed the plan.
Ask about hardware/data/backend/output path when missing.
Surface tradeoffs such as AutoModel vs Megatron-Bridge and full SFT vs LoRA.

Do not:

Invent steps when a catalog step fits.
Skip Plan for pipelines with two or more stages.
Generate Python or shell when YAML is enough.
Add monitoring/W&B unless asked.
Assume GPU count, env profile, endpoint type, task ID, or auth value.
Generate Slurm/Airflow/Kubeflow wrappers unless the request explicitly needs deployment scaffolding.
Edit checked-in step files (default.yaml/tiny.yaml, other shipped configs, step.toml, step.py, runners); only add a new config beside them.
Restate all per-step rules in SKILL.md; use bundled references and source fallback.

Examples

Single-step routing (LoRA on a small box). User: "LoRA fine-tune a HF model on 2 GPUs." Route per CATALOG.md -> peft/automodel (HF base + small GPU count); do not offer Megatron-Bridge. Collect base model, JSONL data path, output dir, LoRA rank/alpha, then emit one uv run nemotron steps run peft/automodel -c <config> --dry-run ... command.

Multi-step pipeline (Super3 SFT). User: "data prep + SFT for Super3." This is two stages, so plan first: SFT on Super3 -> Megatron-Bridge, which consumes packed_parquet, so data_prep/sft_packing is required upstream. Present the DAG (sft_packing -> sft/megatron_bridge), align pack_size/seq_length/ tokenizer, wait for approval, then add new configs under src/nemotron/steps/<step>/config/<name>.yaml. Super3 needs a remote profile; state the env TOML prerequisite or mark Blocked.

Hosted-endpoint evaluation (no training). User: "benchmark my hosted model endpoint." Route to eval/model_eval with -c tiny_chat. Collect endpoint URL, model id, task IDs, and the auth env-var name (value exported, never inlined). See references/COMMANDS.md Evaluation Examples.

Troubleshooting

Situation	Action
Artifact types do not chain	Recheck `references/ARTIFACTS.md`; insert a converter or change the DAG before writing configs.
Remote profile or `--batch` is unclear	Read active env TOML; do not guess profile names.
Config key is unclear	Verify selected checked-in config, `step.py`, and shared runner before editing.
Strategy points to a missing context pack	Skip the pack, use catalog/pattern text, and flag the plan with `WARNING: <topic> docs unavailable`.
Hardware looks too small	Use `references/HARDWARE.md`; suggest smaller model, AutoModel, then LoRA before full Megatron-Bridge.
Two Act attempts fail	Stop, explain what was tried and failed, and ask how to proceed.
No existing repo path matches	Check `references/context/index.toml` and selected source fallback; use Explorer mode only after naming the gap.

Files

.claude-plugin/plugin.json639 B
ATTRIBUTION.mdAdded by AutoGineer926 B
BENCHMARK.md3.7 KiB
LICENSELicence file added by AutoGineer11.2 KiB
SKILL.md16.1 KiB
evals/evals.json9.7 KiB
references/ARTIFACTS.md4.8 KiB
references/CATALOG.md13.0 KiB
references/COMMANDS.md9.3 KiB
references/HARDWARE.md3.1 KiB
references/PATTERNS.md4.0 KiB
references/WORKFLOW.md5.2 KiB
references/act/PROJECT.md7.2 KiB
references/act/STAGE.md8.9 KiB
references/context/README.md1.6 KiB
references/context/automodel-launcher-executor-modes.txt2.4 KiB
references/context/automodel-pretrain.txt6.0 KiB
references/context/automodel-sft-peft-core.txt2.1 KiB
references/context/byob-benchmark-curator-translation.txt4.9 KiB
references/context/checkpoint-conversion.txt1.8 KiB
references/context/curator-data-acquisition.txt2.3 KiB
references/context/curator-processing-language-quality.txt1.7 KiB
references/context/curator-translation-faith.txt4.8 KiB
references/context/data-designer-sdg.txt4.6 KiB
references/context/eval-deploy-formats.txt1.7 KiB
references/context/eval-sovereign-benchmarks.txt2.0 KiB
references/context/eval-standard-nlu.txt1.7 KiB
references/context/index.toml7.4 KiB
references/context/mbridge-parallelism-performance.txt2.0 KiB
references/context/mbridge-pretrain.txt1.8 KiB
references/context/mbridge-sft.txt1.8 KiB
references/context/modelopt-optimization.txt8.3 KiB
references/context/nemo-rl-alignment.txt5.7 KiB
references/context/nemotron-data-prep.txt6.1 KiB
references/examples/CALIBRATION.md2.5 KiB
skill-card.md4.1 KiB
skill.oms.sig11.9 KiB

references/context/modelopt-optimization.txt

# Model Optimization Context

Use this pack when generating stage code for any of:

- `optimize/modelopt/quantize` — PTQ quantization (FP8/NVFP4/INT)
- `optimize/modelopt/prune`    — structured pruning
- `optimize/modelopt/distill`  — teacher-student distillation

These wrap NVIDIA Model Optimizer through Megatron-Bridge. The wrappers stay
generic; algorithm-specific knobs go in YAML under `args:`. **Don't fork
upstream scripts into generated projects** unless the user explicitly needs
custom algorithm code.

## Live Repo Verification

Read `../CATALOG.md`, `../ARTIFACTS.md`, and `../COMMANDS.md` before this pack.
After the bundled references select a ModelOpt step, verify:

- Manifests: `src/nemotron/steps/optimize/modelopt/<algo>/step.toml`
- Per-step README: `src/nemotron/steps/optimize/modelopt/<algo>/README.md`
- Category README: `src/nemotron/steps/optimize/modelopt/README.md`
- Shared runner: `src/nemotron/steps/_runners/modelopt.py`
- Configs: `src/nemotron/steps/optimize/modelopt/<algo>/config/default.yaml`
  plus `tiny.yaml`; quantize also ships `fp8.yaml` and `nvfp4.yaml`.

## Folder choice

Use `optimize/modelopt` as the umbrella — broader than `quantize` because
distillation can be a quality-recovery or transfer stage, not only a
compression stage. `compression` would be too narrow.

## Shared wrapper pattern

All three steps drive `torchrun` against an upstream script with three YAML
sections:

```yaml
script:
  path: null              # null = use container default
  flag_style: hyphen      # quantize uses hyphen; prune & distill use underscore
args:
  # Upstream script args go here. Forwarded as --<key> <value>.
torchrun:
  nproc_per_node: 8
extra_args: []            # literal escape hatch for new upstream flags
```

Generated `run.py` should:

1. Load YAML.
2. Resolve hydra-style CLI overrides.
3. Build a `torchrun ... <upstream_script> ...` command.
4. Print the command.
5. `os.execvp` it.

Don't hardcode model-specific config in Python. Put ModelOpt controls under
`args:`; keep Python a launcher only.

## Quantization (`optimize/modelopt/quantize`)

Step.toml contract:
- Consumes: `checkpoint_hf` (required).
- Produces: `checkpoint_megatron` (export to HF afterward if needed).

Manifest defaults:
- `args.export_quant_cfg = "fp8"`  (also: `int8_sq`, `fp8_blockwise`,
  `int4_awq`, `w4a8_awq`, `nvfp4` per the manifest description).
- `args.calib_size = 512`.
- `extra_args = []`.

Strategies (from step.toml):
- Hopper / H100 → start with `config/fp8.yaml`, `args.export_quant_cfg=fp8`.
- Blackwell / B200 → start with `config/nvfp4.yaml`, `args.export_quant_cfg=nvfp4`.
- Need HF output → run `/opt/Megatron-Bridge/examples/quantization/export.py` after.

Default config (`default.yaml`) shape (truncated):

```yaml
script:
  path: null
  flag_style: hyphen
args:
  hf_model_id: nvidia/NVIDIA-Nemotron-3-Nano-30B-A3B-Base-BF16
  trust_remote_code: true
  export_quant_cfg: fp8
  megatron_save_path: ${oc.env:NEMO_RUN_DIR,${oc.env:PWD}/output}/optimize/quantize/<run-tag>
  calib_size: 512
torchrun:
  nproc_per_node: 8
extra_args: []
```

The pre-built `fp8.yaml` and `nvfp4.yaml` set `export_quant_cfg` and
`calib_size` (NVFP4 typically uses ~2000 calibration samples vs ~512 for FP8).

Calibration guidance:
- Smoke tests → lower `calib_size`, keep the same command shape.
- FP8 PTQ flows commonly use ≈256–512 calibration samples.
- NVFP4 / QAD-oriented flows commonly use ~2000 calibration samples and
  longer context.

Output: Megatron distributed checkpoint. If the next stage needs HF format,
add an explicit conversion via the upstream `export.py`.

## Pruning (`optimize/modelopt/prune`)

Step.toml contract:
- Consumes: `checkpoint_hf` (required).
- Produces: `checkpoint_hf` (pruned).

Manifest defaults:
- `args.prune_target_params = 6e9`.
- `args.prune_export_config` (manual architecture dict; leave unset to use search).
- `args.hparams_to_skip` (e.g. `num_attention_heads`).
- `extra_args = []`.

Strategies:
- Target search: set `args.prune_target_params`, leave `args.prune_export_config: null`.
- Fixed architecture: set `args.prune_export_config`, set `args.prune_target_params: null`.
- Layer count not divisible by PP size: use `args.num_layers_in_first_pipeline_stage`
  / `args.num_layers_in_last_pipeline_stage` for uneven PP.

Default config shape:

```yaml
script:
  path: null
  flag_style: underscore
args:
  hf_model_name_or_path: Qwen/Qwen3-8B
  output_hf_path: ${oc.env:NEMO_RUN_DIR,${oc.env:PWD}/output}/optimize/prune/pruned-hf
  pp_size: 2
  prune_target_params: 6e9
  prune_export_config: null
  hparams_to_skip: null
torchrun:
  nproc_per_node: 2
extra_args: []
```

Common fields for `prune_export_config`: `hidden_size`, `ffn_hidden_size`,
`num_layers`, `num_attention_heads`, `num_query_groups`.

Output: pruned HF checkpoint. Distillation usually follows when quality needs
recovery — chain `optimize/modelopt/distill` with the original BF16 as teacher
and the pruned checkpoint as student.

## Distillation (`optimize/modelopt/distill`)

Step.toml contract:
- Consumes: `checkpoint_hf` (required, teacher + student) + `binidx` (optional, real-data runs).
- Produces: `checkpoint_megatron`.

Manifest defaults:
- `args.teacher_hf_path` / `args.student_hf_path` — required.
- `args.data_paths` — Megatron blend `[weight, prefix, ...]`.
- `args.use_mock_data = false`.
- `extra_args = []`.

Strategies:
- Quality recovery after pruning/quantization → teacher = original BF16/HF
  checkpoint, student = optimized checkpoint.
- Smoke test → `args.use_mock_data=true`, `args.seq_length=512`,
  `args.train_iters=100`, small `args.eval_iters`.
- Need HF output → set `args.hf_export_path` and `args.student_hf_model`,
  or convert a saved Megatron iteration later.

Default config shape:

```yaml
script:
  path: null
  flag_style: underscore
args:
  teacher_hf_path: Qwen/Qwen3-8B
  student_hf_path: Qwen/Qwen3-4B
  tp_size: 8
  data_paths: null
  use_mock_data: false
  seq_length: 8192
  mbs: 1
  gbs: 768
  train_iters: 15000
  output_dir: ${oc.env:NEMO_RUN_DIR,${oc.env:PWD}/output}/optimize/distill/run
torchrun:
  nproc_per_node: 8
extra_args: []
```

Real-data runs expect Megatron bin/idx prefixes:

```yaml
args:
  data_paths:
    - 1.0
    - /data/tokenized/domain_text_document
```

Use `data_prep/pretrain_prep` first when data starts as HF/local text.
`use_mock_data: true` is **plumbing only**, not a quality signal.

Distillation patterns:
- Pruned student: teacher = original BF16/HF, student = pruned HF.
- Quantized recovery: teacher = original BF16/HF, student = optimized checkpoint.
- Standalone small model: teacher = larger model, student = smaller HF model.

Output: Megatron checkpoint under `output_dir` (or HF if inline export
configured).

## Pipeline placement

Common chains:

```
sft/automodel        → optimize/modelopt/quantize → eval/model_eval
sft/automodel        → optimize/modelopt/prune    → optimize/modelopt/distill → eval/model_eval
data_prep/pretrain_prep   → optimize/modelopt/distill  → eval/model_eval
```

Artifact rules:
- Quantize:  `checkpoint_hf` → `checkpoint_megatron`.
- Prune:     `checkpoint_hf` → `checkpoint_hf`.
- Distill:   `checkpoint_hf` (+ optional `binidx`) → `checkpoint_megatron`.
- Insert `convert/*` whenever crossing HF / Megatron format boundaries.

## Patterns to cite

- `convert-checkpoint-safety` in `../PATTERNS.md` — quantize / prune / distill from a clean checkpoint, not from training-state files.
- `eval-before-and-after-training` in `../PATTERNS.md` — measure quantized / pruned / distilled quality against the unoptimized baseline.
- `byob-benchmark-design` in `../PATTERNS.md` — calibration and quality claims should be scored on a representative held-out benchmark, not on calibration loss alone.
- `peft-adapter-merge-discipline` in `../PATTERNS.md` — when the optimization input is a LoRA-adapter checkpoint, merge first.

## Staleness checks

When this pack drifts:

- Refresh defaults from each algo's `step.toml` and `config/default.yaml`.
- Verify the upstream scripts still exist in the container image
  (`/opt/Megatron-Bridge/examples/quantization/quantize.py`,
  `/opt/Model-Optimizer/examples/megatron_bridge/prune_minitron.py`,
  `/opt/Model-Optimizer/examples/megatron_bridge/distill.py`).
- Check `flag_style` per algo: quantize uses **hyphen**, prune and distill
  examples use **underscore**.
- Ensure manifest `[reference]` URLs are intact.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an API key, Needs Python

Security

What our scanner noticed· Medium risk

Large base64-encoded blobs
Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by

NVIDIA Nemotron Team

Publisher

NVIDIA (Official)

Source

NVIDIA/skills · skills/nemotron-customize · commit fce3cca

Licence

Apache License 2.0 (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE-APACHE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

AutoGineer is not affiliated with or endorsed by NVIDIA Nemotron Team or NVIDIA.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download nemotron-customize.zip