nemotron-customize

nemotron-customize

重要：nemotron-customize、Nemotron のカスタマイズ、Curator によるキュレーション、翻訳、SFT、PEFT、RL、変換、最適化、チェックポイント、既存またはホストされたエンドポイントの評価、あるいは複数ステップのパイプラインに関するリクエストに回答する前に、このファイルを読んでください。ユーザーが単一のステップを指定している場合も、複数のステップをパイプラインとして組み合わせるよう求めている場合も対象です。

学習を伴わない場合でも、評価に関するリクエストは対象です。既存またはホストされたエンドポイント、API／モデル ID、デプロイ済みモデルの「評価」「ベンチマーク」「スモークテスト」「スコアリング」は、すべて eval/model_eval に振り分けられます。こうしたリクエストにも、このスキルを読んでください。

目的

モデルのカスタマイズに関するリクエストを、リポジトリ固有の Nemotron ステップパイプラインに変換します。DAG を計画し、アーティファクトの接続を検証して、既存のステップを実行するために必要な YAML／設定ファイルのみを作成します。

このスキルは、既存の Nemotron ステップや複数ステップの学習／カスタマイズパイプラインの調査、設定、検証、実行、送信にのみ使用してください。フロントエンド、ダッシュボード、可視化、一般的な ML のアドバイス、請求／アクセス、または無関係なコーディングタスクの場合は、対象外であることを簡潔に伝えて、そのターンではステップカタログを調べたり、ファイルを編集したりしないでください。

前提条件

• src/nemotron/steps/ が存在する Nemotron リポジトリのチェックアウト。リポジトリのルートから実行してください。
• uv run nemotron steps ... の実行に使える uv。
• リモート実行の場合：選択したステップに一致するセクションを含む環境プロファイル TOML（NEMOTRON_ENV_FILE または env*.toml）。
• ホスト型サービス（翻訳、ホスト型評価）の場合：ステップが必要とする認証用環境変数（例：NVIDIA_API_KEY）を環境にエクスポートしてください。コマンドに直接書き込んだり、コミットしたりしないでください。
• コマンドを実行可能なものとして提示する前に、ユーザーから具体的な値（モデル／チェックポイント、データパス、出力ディレクトリ、ハードウェア／GPU 数）を提示してもらう必要があります。

制限事項

• カタログにないステップを作り出しません。既存のステップ、ランナー、レシピ、CLI、設定ではリクエストに対応できない場合は、ステップを捏造するのではなく、不足しているものを Explorer モードで示します。
• 既存のステップ向けの YAML／設定を作成します。新しい Python／シェルコードの作成は対象外です。ただし、不足点の解消が承認された後の Explorer モードは除きます。
• デプロイのみ／サービング、フロントエンド、ダッシュボード、一般的な ML のアドバイス、または Nemotron と無関係なタスクには対応しません。
• 具体的な値（パス、モデル ID、GPU 数、プロファイル）を推測しません。不足している場合は質問するか、Blocked を返します。

基本ルール

まず同梱のリファレンスを使用してください。ルーティング、アーティファクト、パターン、ハードウェアのヒューリスティクス、コマンド形式を判断する際は、references/ フォルダーを最初に確認します。正確な現在の設定フィールド、マニフェスト、ランナーのインポート、または同梱リファレンスにない詳細が必要な場合に限り、src/nemotron/steps/... を実際の状態を確認するためのフォールバック情報源として使用してください。

情報源の内容が食い違う場合：

1. 実行内容の正確性については、確認済みのリポジトリ内ファイルを優先します。
2. 初期のルーティングと計画については、同梱リファレンスを優先します。
3. 上流のドキュメント／コンテキストパックは、例外的なコード生成やライブラリ API の詳細に限って使用します。

開始する前に

• リポジトリのソースファイルを開く前に、この SKILL.md のワークフローと、関連する同梱リファレンスを読んでください。
• リポジトリ全体を広く調べる前に、references/CATALOG.md と references/ARTIFACTS.md を起点にしてください。 起点が決まったら、回答に必要な選択済みのライブのステップ／設定／環境変数ファイルのみを確認してください。
• 架空のパス、仮のモデル ID、推測したタスク ID、推測したバッチプロファイル、またはデフォルトの認証変数名を、事実として示すコマンドを出力しないでください。 具体的な値が不足している場合は確認するか、Blocked の引き継ぎを返してください。
• 設定または実行コマンドを確定する前に、信頼できるチェックリストとして references/COMMANDS.md を使用してください。
• パイプラインに関する依頼では、編集前に計画を立ててください。 DAG、成果物の接続、必須入力、検証チェックを提示して承認を得るまで、ファイルを作成または変更しないでください。
• 単発コマンドに関する依頼では、必要な入力が揃っている場合に限り、説明文を調査目的で長くするより、パラメーターをすべて含むコマンドを一度の回答で提示してください。 ユーザーが必要な値をすでに提示しており、コマンドのみを求めている場合は、コマンドを先に回答し、説明は最小限にしてください。
• 出力の節度（回答を簡潔に保つため）：ステップごとにコマンドブロックを1つ出力し、そのステップで実際に定義されているフラグのみを含め、推測や創作によるフラグは追加しないでください。 説明は数行にとどめ、コマンドと必要な安全性／プロファイル上の注意点のみを記載してください。ユーザーが求めていないリファレンスの内容を繰り返さないでください。
• 単発コマンドの検索にサブエージェントを起動しないでください。 同梱のコマンドリファレンスを直接使用し、必要に応じて選択済みのステップのみ確認してください。

安全性

Bash の使用は、uv run nemotron steps ...、対象を絞ったテスト、git status/diff、設定の検証など、リポジトリの安全を保つコマンドに限定してください。 環境変数の一覧表示（env、printenv、広範な export）や、シークレットの値を漏えいさせるコマンドは絶対に実行しないでください。 リモートへの送信、破壊的な変更、またはコストのかかる実行を行う前に、確認を取ってください。

環境変数／設定ファイルを調べる際は、シークレットが含まれている可能性のあるファイル全体を出力しないでください。 対象を絞って読み取り、セクション名と環境変数名のみを報告してください。 token、key、secret、password、credential、auth を含むフィールドの値は伏せてください。

リファレンスマップ

質問	まず読むもの	ライブのフォールバック／検証
どのステップまたはカテゴリが適切ですか？	references/CATALOG.md	uv run nemotron steps list/show、次に選択した step.toml
成果物は連鎖しますか？	references/ARTIFACTS.md	src/nemotron/steps/types.toml
どのような実行形式を提示すべきですか？	references/COMMANDS.md	チェックイン済みの設定 YAML と有効なプロファイル TOML
リモートプロファイルの生成または選択	references/COMMANDS.md	有効な NEMOTRON_ENV_FILE、env.toml、または env.*.toml
どのハードウェア／バックエンドを推奨すべきですか？	references/HARDWARE.md	選択したステップの [[models]] と [[strategies]]
ステップ間で適用されるガードレールはどれですか？	references/PATTERNS.md	src/nemotron/steps/patterns/<id>.md
ワークフロー全体を実行するには？	references/WORKFLOW.md	選択したステップの設定、step.py、ランナー
生成コードで使用すべき上流ライブラリの API はどれですか？	references/context/index.toml -> 一致するパック	選択した step.py、_runners/、上流ドキュメント
新規プロジェクトのスキャフォールド（既存リポジトリのコードでは依頼に対応できない場合のみ）	references/act/PROJECT.md	既存リポジトリのプロジェクト／レシピの構成
ステージごとのコードルール（既存リポジトリのコードでは依頼に対応できない場合のみ）	references/act/STAGE.md	選択した step.py と共有ランナー

一般的な判断では、カテゴリの README や step.toml を最初に読まないでください。 同梱リファレンスから候補を選び、設定や最終的なコマンドを書く前に、ライブ環境で正確な詳細を確認してください。

ルーティング

ステップの選択とルート固有のファストパスについては、references/CATALOG.md を正とする参照元として使用してください。カタログでルートが絞り込まれた後に、アーティファクト、ステップ間、またはハードウェアの制約を解決する場合に限り、ARTIFACTS.md、PATTERNS.md、HARDWARE.md を使用してください。

各ステップは独立しており、ステップをつなぎ合わせるのはあなたの役割です。ユーザーの最終目標に合わせてアーティファクトを照合し、パイプラインを構成してください。次のステップが、上流のどのステップも生成しない種類のアーティファクトを消費する場合に限り、そのステップを連結してください。固定された名前付きのステップの組み合わせに頼らないでください。

手順

依頼に合ったフロー（推奨／計画、単一ステップのコマンド、または複数ステップのパイプライン）に従ってください。いずれの場合も、まず同梱の参照資料を確認してルートを決定し、必要な入力を集め、選択した稼働中のステップを検証してから、実行可能なものとして提示してください。

推奨の回答

計画の回答には、次の形式を使用してください。

Decision、Why、Required inputs、Config/command、Avoid、Next step。 ユーザーの制約に照らして適さない場合は、避けるべきスタックを明示してください。

ホスト型サービスまたはリモート実行に触れるコマンドを回答に含める場合は、回答内で次の点も伝えてください。

• 認証用環境変数の名前と、その値は環境にエクスポートする必要があり、コマンドに直接記述したりコミットしたりしてはならないこと（値は決して表示しないでください）。
• --batch／--run の場合、環境用 TOML プロファイルが必要であること。プロファイルがない場合は、コマンドを Blocked とするか、ローカルの --dry-run の形式を提示してください。

単一ステップのコマンドフロー

1. リポジトリのルートに pyproject.toml と src/nemotron/steps/ があることを確認します。
2. references/CATALOG.md と、選択したセクションの references/COMMANDS.md を読みます。
3. 利用可能な場合は uv run nemotron steps show <step_id> を実行し、利用できない場合は選択した step.toml を確認して、選択した稼働中のステップを検証します。
4. コマンドを提示する前に、指定されたチェックイン済みの設定ファイルまたはユーザーのオーバーレイを読みます。
5. リモート実行の場合は、NEMOTRON_ENV_FILE またはリポジトリルートの env*.toml を読み、ステップに適合する実在のセクションを選択します。
6. 出典の区分を付けて、完全なコマンドを1回の回答で提示します。 Verified、Repo-grounded、Reference-grounded、または Blocked。

標準的なコマンド形式は references/COMMANDS.md にあります。

パイプラインのワークフロー

2つ以上のステージからなるパイプラインでは、Orient -> Plan -> Act -> Verify に従ってください。 各フェーズのチェックリストについては、references/WORKFLOW.md を読んでください。

• 同梱の参照資料とユーザーの制約をもとに全体像を把握します。
• アーティファクトの種類、設定、パターン、検証チェックを含む DAG を計画します。
• 設定ファイルやコードを書き始める前に、承認を待ちます。
• 既存のステップで依頼を満たせる場合は、YAML／設定ファイルのみを変更して実行します。
• 完了を報告する前に、生成した YAML、アーティファクトの接続、コマンド、README のコマンドをすべて検証します。

カタログモード

依頼が既存のステップに対応する場合に使用します。ファストパスは次のとおりです。

references/CATALOG.md -> references/ARTIFACTS.md -> references/COMMANDS.md -> 選択した稼働中のマニフェスト／設定／プロファイルを検証 -> 選択したステップの config/ ディレクトリに名前付きの設定ファイルを新規追加

カスタマイズできる範囲

• カスタマイズは必ず src/nemotron/steps/ 配下のステップカタログを通じて行ってください。src/nemotron/cli/commands/super3/ や .../nano3/ などの代替レシピ CLI に迂回してはいけません。Super3／Nano3 の作業であっても同様です。こうした CLI が必要に見える依頼は、対応するカタログ内のステップ（例：sft/megatron_bridge）に当てはめてください。
• カスタマイズは、選択したステップの src/nemotron/steps/<cat>/<step>/config/ ディレクトリ内に新しい設定ファイルとして作成してください。たとえば、src/nemotron/steps/sft/megatron_bridge/config/my_super3.yaml のようにします。
• チェックイン済みの default.yaml、tiny.yaml、その他の同梱設定ファイル、step.toml、step.py、共有ランナーを編集してはいけません。それらの隣に新しい設定ファイルを追加する方法のみが想定されています。
• 新しい設定ファイルは、チェックイン済みの default.yaml のスキーマを基にしてください（読み込んで必要なフィールドをコピーし、依頼に必要な項目だけを上書きします）。

エクスプローラーモード

既存のステップ、ランナー、レシピ、CLI、または YAML 設定サーフェスでリクエストを満たせないことを確認した後にのみ使用してください。手順の詳細は references/WORKFLOW.md に記載されています。

設定の整合性

コマンドや設定の書き込みの前に、以下の制約を提示してください:

• SFT のパッキング pack_size、Megatron-Bridge の seq_length、パックされたシーケンスサイズ、トークナイザー、チャットテンプレートは一致している必要があります。
• 準備済みの packed_parquet と binidx はトークナイザーに固定されています。トークナイザー、チャットテンプレート、シーケンス長、分割、またはブレンドを変更した後は再ビルドしてください。
• Megatron-Bridge のグローバルバッチサイズはデータ並列サイズで割り切れる必要があります。分散検証はマイクロバッチサイズ 1 から開始してください。
• TP/PP/CP/EP の選択は、GPU 数、メモリ、トポロジー、モデルの分割可能性に適合している必要があります。
• LoRA マージには、アダプターのトレーニング時に使用した正確なベースチェックポイント/モデルとトークナイザーが必要です。
• Megatron チェックポイントの変換/評価は、親の実行ディレクトリではなく、具体的な iter_* チェックポイントを指すようにしてください。
• ホステッド評価と翻訳の設定には、認証用環境変数の名前のみを保存し、値は保存しないでください。

運用上のニュアンス

• スモーク設定 (tiny.yaml、tiny_chat.yaml) は配線テストであり、品質の証拠ではありません。
• ${art:...} 参照はレシピに基づく設定に属します。スタンドアロンの YAML ではプレーンなパスを使用してください。
• 事前学習用の bin/idx データと blend.json は同じ実行/リリースのものを使用してください。
• カスタマイズした設定は、そのステップの src/nemotron/steps/<cat>/<step>/config/ ディレクトリ内に新しいファイルとして作成してください。チェックイン済みの default.yaml やその他の同梱設定は決して変更しないでください。
• LoRA の場合、後続のマージ/評価に必要な正確なベースチェックポイントとトークナイザー/テンプレートのメタデータを保持してください。
• 翻訳とホステッド評価では、認証用環境変数の名前のみを記載し、値は決して記載しないでください。

境界

すること:

• 常に src/nemotron/steps/ 配下のステップカタログを経由してください。代替のレシピ CLI (src/nemotron/cli/commands/super3|nano3/...) は決して使用しないでください。
• リポジトリの CLI、ランナー、レシピ、ステップ、チェックイン済みの設定をまず再利用してください。
• カスタマイズは、そのステップの config/ ディレクトリに新しい設定を追加して行ってください。盲目的にコピーするのではなく、default.yaml をベースにしてください。
• アーティファクトのエッジを検証し、計画を変更したパターンを引用してください。
• ハードウェア/データ/バックエンド/出力パスが不足している場合は確認してください。
• AutoModel と Megatron-Bridge、フル SFT と LoRA などのトレードオフを提示してください。

しないこと:

• カタログのステップが適合する場合に、ステップをでっち上げること。
• 2 つ以上のステージを持つパイプラインで Plan を省略すること。
• YAML で十分な場合に Python やシェルを生成すること。
• 求められない限りモニタリング/W&B を追加すること。
• GPU 数、環境プロファイル、エンドポイントタイプ、タスク ID、または認証値を仮定すること。
• リクエストがデプロイのスキャフォールディングを明示的に必要としない限り、Slurm/Airflow/Kubeflow ラッパーを生成すること。
• チェックイン済みのステップファイル (default.yaml/tiny.yaml、その他の同梱設定、step.toml、step.py、ランナー) を編集すること。それらの横に新しい設定を追加するだけにしてください。
• SKILL.md 内のすべてのステップごとのルールを繰り返し記載すること。バンドルされた参照とソースへのフォールバックを使用してください。

例

単一ステップのルーティング（小規模な環境でのLoRA）。 ユーザー：「2台のGPUでHFモデルをLoRAファインチューニングしてください。」CATALOG.mdに従ってルーティングします -> peft/automodel（HFベース＋少数のGPU）。Megatron-Bridgeは提示しません。ベースモデル、JSONLデータのパス、出力ディレクトリ、LoRAのランク／アルファを確認し、次にuv run nemotron steps run peft/automodel -c <config> --dry-run ...コマンドを1つ出力します。

マルチステップパイプライン（Super3 SFT）。 ユーザー：「Super3向けのデータ準備＋SFT。」これは2つのステージで構成されるため、まず計画します：Super3でのSFT -> Megatron-Bridge。Megatron-Bridgeはpacked_parquetを使用するため、上流にdata_prep/sft_packingが必要です。DAG（sft_packing -> sft/megatron_bridge）を提示し、pack_size／seq_length／トークナイザーを調整し、承認を待ってから、src/nemotron/steps/<step>/config/<name>.yamlの下に新しい設定ファイルを追加します。Super3にはリモートプロファイルが必要です。環境TOMLの前提条件を明示するか、Blockedと記載します。

ホスト型エンドポイントの評価（トレーニングなし）。 ユーザー：「ホスト型モデルのエンドポイントをベンチマークしてください。」eval/model_evalに-c tiny_chatを指定してルーティングします。エンドポイントURL、モデルID、タスクID、認証用環境変数名を確認します（値は環境変数としてエクスポートし、インラインでは記述しません）。references/COMMANDS.mdの「Evaluation Examples」を参照してください。

トラブルシューティング

状況	対応
成果物の型が連結できない	references/ARTIFACTS.mdを再確認します。設定ファイルを作成する前に、変換器を追加するかDAGを変更してください。
リモートプロファイルまたは--batchが不明確	有効な環境TOMLを読み込みます。プロファイル名を推測してはいけません。
設定キーが不明確	編集前に、選択したチェックイン済み設定ファイル、step.py、共有ランナーを確認します。
戦略で指定されたコンテキストパックが見つからない	パックをスキップし、カタログ／パターンの説明を使用して、WARNING: <topic> docs unavailableを付けて計画に注記します。
ハードウェアが小さすぎるように見える	references/HARDWARE.mdを参照します。より小さなモデル、AutoModel、次にLoRAを提案してから、完全なMegatron-Bridgeを検討します。
Actによる2回の試行が失敗する	中止し、試した内容と失敗した内容を説明して、次の進め方を尋ねます。
既存のリポジトリパスに一致するものがない	references/context/index.tomlと選択したソースのフォールバックを確認します。不足点を明示してから、Explorerモードのみを使用します。