huawei-cloud-cloudrobo-train

Windows / PowerShell: 例では bash 構文を使用しています。Windows PowerShell で実行するには、次のようにします。

• \ による行継続を1行にまとめるか、行末にバッククォートを付けます。
• export NAME="value" の代わりに $env:NAME="value" で環境変数を設定します。
• シングルクォートで囲んだ JSON '{"a":"b"}' はそのまま使用できます。

概要

CloudRobo のモデル学習タスクと SimRL タスクのライフサイクル全体を管理します。2つの学習モード （MODEL_TUNING / TRAIN_FROM_SCRATCH）と5つのメソッド（FFT/SFT/LORA/QLORA/DEEPSPEED）に対応しています。作成、 監視、診断、ドラフト、統計、再開、パイプラインのオーケストレーションを網羅します。

2つのタスク画面（--sim-rl で切り替え可能）：

画面	API プレフィックス	CLI スイッチ	SDK メソッド	再開
通常の学習	/v1/training/train-tasks	（デフォルト）	19 個の train_*	はい
SimRL	/v1/training/rl-tasks/simulation	--sim-rl	16 個の sim_rl_*	いいえ

シナリオ： ファインチューニング、事前学習、シミュレーション RL、ドラフトの保存・再送信、監視（ステージ／ リソース／イベント）、失敗の診断、統計。学習には数時間から数日かかるため、30～60秒間隔でポーリングします。

Agent → CLI (`cloudrobo train <command> [--sim-rl]`) or SDK (`TrainClient`)
      → cloudrobo-service (REST API)

すべての操作は cloudrobo-service を対象とし、workspace_id が必要です。モデル／データセットの検出では、 cloudrobo asset を介して cloudrobo-asset-manager を呼び出します。

前提条件

CLI のインストール、AK/SK 認証、ワークスペースの設定については、references/cli-installation-guide.md を参照してください。すべての学習操作には有効な workspace_id が必要です。

ワークスペースの自動解決：SDK と CLI は、次の順序で workspace_id を自動的に解決します。

1. 明示的に指定された --workspace-id パラメーター（指定されている場合）
2. 設定済みのデフォルトワークスペース（cloudrobo workspace use --workspace-id <id> で指定）
3. 自動照会：ワークスペースが設定されていない場合、SDK は cloudrobo workspace list を照会し、最初に見つかったワークスペースを デフォルトとして保存して使用します

自動照会に失敗した場合（ワークスペースが見つからない場合）、エラーメッセージでワークスペースの作成方法が案内されます。 デフォルトワークスペースを手動で設定するには、cloudrobo workspace use --workspace-id <id> を実行します。

ワークフロー

既存のタスクを基にタスクを作成する

シナリオ：ユーザーが「按照已有任务创建一个训练任务」、「复制之前的任务」、「create same task again」と言ったり、 既存のタスク名を挙げたりした場合です。タスク作成の全ワークフローを最初から実行しないでください。 代わりに、 既存タスクの設定をそのまま再利用します。

1. 既存のタスクを探す — ユーザーがタスク名（ID ではない）を指定した場合は、 cloudrobo train list-tasks を使用して名前で検索します。ユーザーが task_id を指定した場合は、ステップ 2 に進みます。
2. 既存タスクの設定を照会する — cloudrobo train show-task --task-id <id> → タスク設定全体（train_mode、train_method、algorithm、input_models、datasets、spec、cluster_id、worker_num、parameters、env、output_models）を抽出します。
3. 変更内容を確認する — 変更する内容（通常はタスク名のみ）を、1つの質問でユーザーに尋ねます。よくある変更項目：name、output_models[].model_name、parameters の値。
4. 競合を自動修正する — 同じ出力モデル名でタスクを作成する場合は、「输出模型已存在」エラーを避けるため、末尾にサフィックス （例：-2、-3、または日付）を追加します。必要に応じて list-tasks で確認します。
5. 新しい設定を作成する — 既存の設定をコピーし、ユーザーの変更を適用します。その他のフィールド （algorithm、datasets、spec、cluster_id など）はすべて同じにします。
6. 送信する — cloudrobo train create-task --config '<new-json>'（CLI を推奨）。 --verbose/-v を指定した場合は、最初にユーザー向けの概要を表示します。
7. ステータスをポーリングする — 終了状態になるまで30秒間隔でポーリングします。

重要な原則：ユーザーが既存のタスクに言及した場合、エージェントは必ず最初に show-task でそのタスクの 設定を照会し、再利用する必要があります。モデル／データセット／メソッドの選択を最初からやり直してはいけません。 ユーザーはすでにそれらを決定しており、同じ設定で新しいタスクを作成したいだけです。

タスク作成ワークフロー

ショートカット：ユーザーが既存のタスクに言及した場合（「按照已有任务创建」、「复制之前的任务」、 「create same task again」）、このワークフローはスキップし、代わりに既存のタスクに基づいてタスクを作成を使用してください。

この統合ワークフローでは、MODEL_TUNING と TRAIN_FROM_SCRATCH の両方のタスク作成を行います。エージェントは cloudrobo-asset / cloudrobo-resource を横断して情報を検索し、クラウドが実際にサポートしている内容に基づいて絞り込んだ選択肢を提示した後、確認を求めずに送信します（CLI 呼び出しに --verbose/-v を追加すると、最初にユーザー向けの概要を表示してから送信できます。はい／いいえの確認はありません）。

ステップ 1 — デフォルトのタスク名

• デフォルト：Train-{YYYYMMDD-HHMMSS}（例：Train-20260812-143000）
• エージェントはデフォルト名を提示します。ユーザーは名前を変更できます。ユーザーが「ok」と言った場合は、デフォルト名で続行します。

ステップ 2 — トレーニング方法の選択

質問は正確に 1 つだけしてください（AskUserQuestion の呼び出しは 1 回のみとし、決して重複させないでください）。

• A) モデル調整（MODEL_TUNING）— ベースモデルがあり、FFT/SFT/LORA/QLORA/DEEPSPEED を使ってファインチューニングします
• B) 基盤モデルなしのトレーニング（TRAIN_FROM_SCRATCH）— 3 つのサブパスがあります（ステップ 3b を参照）

質問を繰り返さないルール：このワークフローの各ステップでユーザーに質問できるのは最大 1 回です。同じトピックについて AskUserQuestion を並行して 2 回呼び出さないでください。1 つのステップで複数の入力（例：model_name + model_type）が必要な場合は、デフォルトの選択肢を含む 1 つの質問にまとめてください。

ステップ 3a — MODEL_TUNING サブフロー

1. モデルソース：具身广场-模型（Gallery、PUBLIC_MODEL_ASSET）／空间资产-模型（Workspace、CUSTOM_MODEL_ASSET）

   • CLI：cloudrobo asset list-publication-assets --type model（Gallery）／ cloudrobo asset list-assets --type model（Workspace）
   • 一覧にはモデル名とlatest_version_idを表示する必要があります（ユーザーはこの一覧から選択します）。
   • 重要：Workspace のモデルを一覧表示する際は、ユーザーに提示する前に、status == "DRAFT"で結果を絞り込んでください。使用可能なのはDRAFTステータスのモデルのみです。CREATINGステータスのモデルを使用すると、エラー"输入模型未就绪"でCREATE_FAILEDが発生します。DRAFTのモデルがない場合はユーザーに警告し、代わりに Gallery のモデルを使うよう提案してください。Gallery のモデルは通常すべて使用可能です。
   • Gallery モデル（デフォルトパス）：以下のステップ 2～5 を適用します。アルゴリズムはモデルのactions配列から取得します。
   • Workspace モデル（カスタムパス）：ステップ 2～5 をスキップします。アルゴリズム設定に必要なのはalgorithm_asset_idとalgorithm_version_idのみです（2 フィールド形式）。バックエンドがアルゴリズムアセットからエンジン／コマンドを自動解決します。トップレベルのinputs／outputs配列は必須です。以下のWorkspace モデルのサブフローを参照してください。

2. モデルを選択 → 選択したモデルの一覧エントリーからasset_idとlatest_version_idを抽出します。 バージョンをユーザーに再度尋ねないでください — latest_version_idを自動的に使用します。ユーザーが最新以外のバージョンを明示的に希望した場合にのみ尋ねます。

3. モデルバージョンの詳細を照会 GET /v1/assets/{asset_id}/versions/{version_id} → actions 配列を取得します。各アクションは{action, algorithm:{asset_id, version_id}, status}です。

4. 利用可能なトレーニングアクションのみを表示 — status == "ENABLE"かつ actionがトレーニング関連（例：「FFT」、「SFT」、「LORA」、「QLORA」、「DEEPSPEED」）のactionsを絞り込みます。「ONLINE_DEPLOYMENT」など、トレーニング以外のアクションは除外します。リクエスト本文のtrain_methodにはactionフィールドの値を使用します。モデルが提示していないアクションを選択肢として表示しないでください。

5. ユーザーが手法を選択 → 該当するアクションのaction値（これがtrain_methodです）と、 algorithm.asset_idおよびalgorithm.version_idを抽出します。アルゴリズムのバージョンをユーザーに尋ねないでください — アクションから直接取得します。自動的に抽出して処理を進めます。

6. アルゴリズムバージョンの詳細を照会 GET /v1/assets/{algo_asset_id}/versions/{algo_version_id} → ext_metadataを取得します。以下の正確なフィールドから抽出します。

   • ハイパーパラメーター：ext_metadata.hyperparams → [{name, default, constraint, description}]
   • 環境変数：ext_metadata.environment_variables → [{name, default, description}]
   • リソース制約：ext_metadata.resource → [{key, values, operator, constraints?}]
     • flavor_type.values：必須のフレーバータイプ（例：["Ascend"]）。プールのフレーバーと一致する必要があります。
     • device_distributed_mode.constraints：{step, range:[min, max], default} — ワーカーあたりの NPU カード数の最小値／最大値です。defaultは推奨カード数です。
     • host_distributed_mode.values："singular"（単一ホスト、worker_num=1）または"multiple"
   • 注：ext_metadata.envが存在する場合がありますが、非推奨です。必ずenvironment_variablesを使用してください。

7. 環境変数とハイパーパラメーターを表示 — 2 つの表を提示します。

   • ハイパーパラメーターの表：| パラメーター名 | デフォルト値 | 説明 | 制約 |
   • 環境変数の表：| 変数名 | デフォルト値 | 説明 | ユーザーは値を変更できます。parametersの JSON 文字列を構築します。各項目は {key, desc, value, constraint}です（必須かどうかにかかわらず、すべてのハイパーパラメーターを渡します）。environment_variablesからenvの JSON 文字列を構築します（空、または存在しない場合はデフォルト値"[]"）。

8. データセットの選択 — 3 つのソースがあり、それぞれ必須フィールドが異なります。

   • Gallery（具身广场）：source_type: "PUBLIC_DATASET_ASSET" + dataset_asset_id + version_id + dataset_name
   • Workspace（空间资产）：source_type: "CUSTOM_DATASET_ASSET" + dataset_asset_id + version_id + dataset_name。status == "DRAFT"で絞り込んでください — モデルと同様に、使用可能なのはDRAFTのデータセットのみです。
   • OBS（对象存储）：source_type: "OBS" + url_pathのみ（例： "obs://bucket-name/dataset/"）。dataset_asset_id／version_id／dataset_nameは不要です。

   Critical：ワークスペースのデータセットでは CUSTOM_DATASET_ASSET を使用します（DATASET ではありません）。誤った source_type を使用すると、2 分以内に exitCode 1 で RUN_FAILED になります。

9. リソースの選択 — プールを選択する前に、Gallery のソースタイプ（PUBLIC_MODEL_ASSET_OFFICIAL、 PUBLIC_MODEL_ASSET_COMMUNITY、PUBLIC_DATASET_ASSET）を使用するすべての入力アセット（モデルとデータセット）について、data_read 権限を確認します。

   cloudrobo asset check-permission --asset-id <id> --version-id <ver> --permissions data_read
   

   • いずれかのアセットが data_read: deny を返す場合 → DEDICATED プールでは "专属资源池需要输入资产的可读权限" で失敗します → SHARED プールを使用する必要があります
   • すべてのアセットが data_read: allow を返す場合 → DEDICATED プールと SHARED プールのどちらも使用できます
   • ワークスペースのアセット（CUSTOM_*）と OBS データセットでは、この確認は不要です

   次に、プールを照会します：cloudrobo resource list-pools --resource-type MODELARTS （注：環境によっては --usages MODEL_TRAINING フィルターが 504 プロキシタイムアウトを引き起こす場合があります。 失敗した場合はフィルターを省略し、usages 配列に MODEL_TRAINING が含まれるプールを手動で選択してください）。 各プールの config.flavor.ASCEND[] を読み取ります （"1 * SNT9B2 | 24 vCPUs | 192 GiB" のような仕様文字列のリストです）。Step 3a.6 の ext_metadata.resource 制約を使ってフレーバーを絞り込みます：

   • 各仕様から NPU 数を解析します（* の前の数値。例："2 * SNT9B2..." → 2）
   • NPU 数が device_distributed_mode.constraints.range[0]（最小値）以上、 range[1]（最大値）以下のフレーバーのみを表示します。例：range: [2, 8] の場合、 1 カードのフレーバーは除外されます。
   • デフォルト選択：constraints.default に一致するフレーバー（例：default: 2 → "2 * SNT9B2 | 48 vCPUs | 384 GiB"）。ユーザーは別の有効なフレーバーを選択できます。
   • worker_num：host_distributed_mode が "singular" の場合は 1、"multiple" の場合はユーザーに確認します。 → プールを選択 → cluster_id（pool- プレフィックス付き）。仕様：Ascend: <n> * <model> | <vCPUs> vCPUs | <GiB> GiB

10. 出力モデル — save_mode を一度だけ確認します：

    • NEW_MODEL：model_name と model_type を一つの質問で確認します。version_name は "0.0.1" として 自動生成します（ユーザーは変更できます）。各フィールドを個別に尋ねないでください。 フィールド：save_mode + model_name + version_name + model_type + strict:false
    • NEW_VERSION：既存のモデルと version_name を一つの質問で確認します。最新バージョンとともに既存モデルを 一覧表示し、ユーザーにモデルを選択して新しい version_name を指定してもらいます。 フィールド：save_mode + model_asset_id + model_name + version_id + version_name + model_type
    • NOT_SAVE：残りの出力モデルのフィールドは省略します。 フィールド：save_mode のみ — {"save_mode": "NOT_SAVE"}
    • クローン／複製タスクに関する警告：既存のタスクに「基づいてタスクを作成」「前のタスクを複製」 または「同じタスクをもう一度作成」するようユーザーから依頼された場合、出力モデル名は元のタスクと必ず 異なる名前にします。送信前に list-tasks または show-task で既存の出力モデル名を確認します。 名前が競合する場合は、ユーザーに新しい名前を指定してもらいます。 競合時のエラー："输出模型已存在，请更换模型名称"（出力モデルはすでに存在します。モデル名を変更してください）。

11. 送信 — cloudrobo train create-task --config '<json>'（CLI）または client.create_train_task(req)（SDK）。 デフォルトではサイレント送信（出力なし）です。--verbose/-v を指定すると、最初にユーザー向けの概要を表示します。 生の JSON やコードは絶対に表示しないでください。 その後、yes/no の確認なしで直接送信します。

12. ステータスのポーリング — 30 秒間隔で、終端状態になるまで状態の変化を報告します

13. 完了時： FINISHED → エクスポート／デプロイを提案します。FAILED/RUN_FAILED/CREATE_FAILED → 診断用のログ／イベントを提示します

ステップ 3a-WS — ワークスペースモデルのサブフロー（空間资产模型）

ステップ 3a.1 でユーザーがワークスペースモデル（CUSTOM_MODEL_ASSET）を選択した場合、アルゴリズムをモデルの actions 配列から解決することはできません。代わりに、ワークスペースモデルのアルゴリズムメタデータから完全に設定する必要があります。このサブフローは、ギャラリーパスのステップ 2～5 を置き換えます。ステップ 6～13（ext_metadata、ハイパーパラメーター、データセット、リソース、出力モデル、送信、ポーリング）は共通です。

1. ワークスペースモデルを選択する → リスト項目から asset_id と latest_version_id を抽出します。 バージョンを再度ユーザーに尋ねないでください。

   重要：ワークスペースモデルの status は == "DRAFT" である必要があります。CREATING 状態のモデルは入力として使用できず、エラー "输入模型未就绪" により CREATE_FAILED になります。 ワークスペースに DRAFT モデルが存在しない場合は、ユーザーにその旨を伝え、代わりにギャラリーモデルを使用するよう提案してください。

2. モデルバージョンの詳細を照会する → アルゴリズム設定（エンジン、イメージ、code_dir、 コマンドなど）の ext_metadata を取得します。ワークスペースモデルのアルゴリズム情報は、別個のアルゴリズムアセットの actions 配列ではなく、モデル自体に埋め込まれています。

3. アルゴリズム設定を構築する — 必要なフィールドは 2 つだけです。バックエンドがアルゴリズムアセットからエンジン／コマンドを自動的に解決します。algorithm_source_type、engine、code_dir、command、image_asset_id、image_version_id は含めないでください。

   {
     "algorithm_asset_id": "<algo-asset-id>",
     "algorithm_version_id": "<algo-version-id>"
   }
   

4. input_models を構築する — source_type: "PUBLIC_MODEL_ASSET" ではなく、source_type: "CUSTOM_MODEL_ASSET" を使用します。

   [{"source_type": "CUSTOM_MODEL_ASSET", "model_asset_id": "...", "version_id": "...", ...}]
   

5. inputs/outputs 配列を構築する — ワークスペースモデルではトップレベルの inputs と outputs が必要です。

   inputs の形式（各項目のフィールドは source_type によって異なります）：

   "inputs": [{
     "name": "<display-name>",
     "url_path": "obs://bucket/path/",
     "source_type": "CUSTOM_MODEL_ASSET",
     "access_method": "env",
     "local_dir": "<name>=/home/ma-user/cloudrobo/inputs/<name>_0"
   }]
   

   • access_method："env"（環境変数）または "parameter"（ハイパーパラメーター）
   • local_dir：env モード → "<name>=<container-path>"、parameter モード → "--<name>=<container-path>"

   outputs の形式（よりシンプルです — source_type は不要で、常に OBS パスを使用します）：

   "outputs": [{
     "name": "<output-name>",
     "url_path": "obs://bucket/output-path/",
     "access_method": "parameter",
     "local_dir": "--<name>=/home/ma-user/cloudrobo/outputs/<name>_0"
   }]
   

6. ギャラリーパスのステップ 6～13（ext_metadata のハイパーパラメーター、環境変数、リソース制約、データセットの選択、リソースの選択、出力モデル、送信、ポーリング）を続けます。MODEL_TUNING では log_path は任意です。

ギャラリーモデルとの主な違い：ワークスペースモデルでは CUSTOM_MODEL_ASSET の source_type を使用し、2 フィールド形式のアルゴリズム（ギャラリーモデルと同じ）を使用し、トップレベルの inputs/outputs 配列が必要です。 ギャラリーモデルでは PUBLIC_MODEL_ASSET を使用し、inputs/outputs 配列は必要ありません。

ステップ 3b — TRAIN_FROM_SCRATCH サブフロー

どのサブパスを使用するか確認します：

• A）预制算法（ギャラリーアルゴリズム）
• B）空间资产-算法（ワークスペースアルゴリズム）
• C）现配置算法（カスタム設定、プリセットアルゴリズムなし）

共通の手順（すべてのサブパス）：

• データセットの選択（ステップ 3a.8 と同じ）
• リソースの選択（ステップ 3a.9 と同じ。ext_metadata.resource の制約を使用。カスタムの場合は制約なしですべてのフレーバーを表示）
• ハイパーパラメーター（ステップ 3a.7 と同じ。カスタムの場合はスクラッチから設定し、デフォルト値なし。何もない場合は "[]" を作成）
• 出力モデル（ステップ 3a.10 と同じ。NEW_MODEL に必要なのは 4 つのフィールドのみ：save_mode、model_name、version_name、model_type）
• リクエストボディを作成：name（一意になるようにタイムスタンプを追加）、train_mode: "TRAIN_FROM_SCRATCH"、datasets、spec、worker_num、cluster_id、parameters、env（デフォルトは "[]"）、output_models、log_path（任意）、enable_jupyter（任意、DEDICATED のみ）
• 送信（cloudrobo train create-task --config '<json>'。--verbose を指定すると概要を表示）。終端状態になるまで 30 秒間隔でポーリングします

アルゴリズム設定の違い：

サブパス	アルゴリズム形式	検出方法
ギャラリー（预制）	2 つのフィールド：algorithm_asset_id + algorithm_version_id。バックエンドがエンジン／イメージを自動解決します。	list-publication-assets --type algorithm → algorithm_asset_id + latest_version_id を抽出します。ハイパーパラメーター／環境／リソースについて ext_metadata を照会します。
ワークスペース（空间资产）	7 つのフィールド：engine.image_url + image_asset_id + image_version_id + code_dir + command + algorithm_asset_id + algorithm_version_id。	list-assets --type algorithm → algorithm_asset_id + latest_version_id を抽出します。エンジン／コマンド／code_dir とハイパーパラメーター／環境／リソースについて ext_metadata を照会します。
カスタム（现配置）	4 つのフィールド：image_asset_id + image_version_id + command + algorithm_source_type: "TEMP_CONFIGURE_ALGORITHM"。algorithm_asset_id はありません。	ユーザーがイメージアセット、起動コマンド、ローカルのコードディレクトリを指定します。ext_metadata は利用できません。

注：

• ギャラリー／ワークスペースでは algorithm_source_type は不要です（algorithm_asset_id から自動判定されます）。カスタムの場合（asset_id がない場合）のみ必要です。
• ワークスペースアルゴリズムでは、トップレベルの inputs／outputs 配列も必要です（ステップ 3a-WS と同じ形式）。
• カスタム設定では inputs／outputs 配列が必要です。inputs では 4 つの source_type 値を使用できます：PUBLIC_DATASET_ASSET、CUSTOM_DATASET_ASSET、OBS、CUSTOM_MODEL_ASSET。形式についてはステップ 3a-WS を参照してください。
• 失敗した場合（2 分以内に exitCode 1 で RUN_FAILED となり、ログファイルがない場合）、データセット形式の互換性に問題がある可能性があります。source_type とアルゴリズムの互換性を確認してください。

SimRL ワークフロー（シミュレーション強化学習）

SimRL タスクでは、通常のトレーニングタスクとは異なる設定スキーマを使用します。algorithm + parameters の代わりに、config_mode + task_set + simple_params／rl_config_content を使用します。SimRL タスクは --sim-rl フラグを使って、同じ CLI コマンド体系を共有します。SimRL では resume は利用できません。

ステップ 1 — モデルの検索

モデルのソースを確認します。

• 具身广场模型（ギャラリー）：cloudrobo asset list-publication-assets --type model --action-status ENABLE --actions LIBERO_SPATIAL,LIBERO_OBJECT,LIBERO_GOAL,LIBERO_10 --actions-operator OR → モデルを選択 → model_asset_id と latest_version_id を抽出します。source_type: "PUBLIC_MODEL_ASSET"。 バージョンを再度ユーザーに確認しないでください。latest_version_id を自動的に使用します。 重要：--actions と --action-status のフィルターは必須です。これらがない場合、クエリは SimRL と互換性のあるモデルだけでなく、ギャラリーの全モデルを返します。SimRL タスクで使用できるのは、LIBERO_* アクションが有効になっているモデルのみです。
• 空间资产模型（ワークスペース）：cloudrobo asset list-assets --type model → モデルを選択 → model_asset_id と latest_version_id を抽出します。source_type: "CUSTOM_MODEL_ASSET"。

モデルバージョンの詳細 GET /v1/assets/{asset_id}/versions/{version_id} をクエリして、actions 配列を取得します。各アクションはタスクセット（例：LIBERO_SPATIAL、LIBERO_GOAL）を表します。

ステップ 2 — タスクセットの選択

actions 配列から、利用可能なタスクセットをユーザーに表示します。action フィールドの値 （例："LIBERO_SPATIAL"）を抽出し、リクエストボディの task_set に設定します。

選択したタスクセットの詳細（アクションの詳細）をクエリして、以下を取得します。

• ext_metadata.hyperparams → SIMPLE モードのパラメーターのデフォルト値
• ext_metadata.environment_variables → SIMPLE モードの環境変数
• ext_metadata.yaml_config → ADVANCED モードの YAML 設定テンプレート全体
• ext_metadata.resource → リソース制約（フレーバーの種類、NPU カード数）

ステップ 3 — 設定モードの選択

使用するパラメーター設定モードをユーザーに確認します。

• 快速配置（SIMPLE）：config_mode: "SIMPLE"。simple_params（JSON 文字列配列）を使用します。 ext_metadata.hyperparams のハイパーパラメーターテーブルを表示し、ユーザーが値を変更できるようにします。 RL_ALGO のデフォルト値は ppo です。

  "simple_params": "[{\"key\":\"RL_ALGO\",\"value\":\"ppo\",\"desc\":\"强化学习算法\"},{\"key\":\"MAX_EPOCHS\",\"value\":\"100\",\"desc\":\"训练轮数\"},...]"
  

  各項目は {key, value, desc} です。simple_params は JSON 文字列または配列を受け付けます。SDK が配列を JSON 文字列に自動シリアライズします。

• YAML配置（ADVANCED）：config_mode: "ADVANCED"。rl_config_content（YAML 文字列全体）を使用します。 ext_metadata.yaml_config の内容を事前に入力し、ユーザーが調整できるようにします。

  "rl_config_content": "runner:\n  task_type: embodied\n  max_epochs: 100\n  ..."
  

ステップ 4 — リソースプールの選択

ステップ 3a.9 と同じ権限確認（ギャラリーのアセットには data_read）およびプールのクエリを行います。 ext_metadata.resource の制約に従ってフレーバーを絞り込みます。SimRL 固有のルールは次のとおりです。

• SHARED（共有）プール：enable_jupyter は false にする必要があります（JupyterLab はサポートされていません）
• DEDICATED（専用）プール：enable_jupyter は true または false に設定できます（ユーザーが選択します）
• spec の形式："ASCEND: <n> * <model> | <vCPUs> vCPUs | <GiB> GiB"（ASCEND は大文字）

ステップ 5 — 出力モデル

save_mode を確認します。

• NEW_MODEL（新しいモデル）：7 フィールド：

  {"save_mode": "NEW_MODEL", "model_name": "<name>", "version_name": "0.0.1", "model_type": "vla",
   "model_asset_id": null, "version_id": null, "strict": false, "skills": []}
  

• NEW_VERSION（既存モデルの新バージョン）：8 フィールド以上：

  {"save_mode": "NEW_VERSION", "model_name": "<existing-model-name>", "version_name": "<new-version>",
   "model_type": "vla", "model_asset_id": "<existing-model-asset-id>", "version_id": "",
   "strict": false, "skills": [{"name": "<skill-name>", "prompt": "<skill-prompt>"}]}
  

  version_id は空文字列 ""（null ではありません）です。skills 配列にはスキル定義を含めることができます。

ステップ 6 — SimRL 設定の作成

以下を含む JSON を作成します。

• name：一意のタスク名
• description：省略可能
• workspace_id：SDK によって自動挿入されます
• input_models：[{source_type, model_asset_id, model_name, version_id, version_name}] （ギャラリーは PUBLIC_MODEL_ASSET、ワークスペースは CUSTOM_MODEL_ASSET）
• task_set：ステップ 2 の値（例："LIBERO_SPATIAL"）
• config_mode：ステップ 3 の "SIMPLE" または "ADVANCED"
• simple_params：JSON 文字列（SIMPLE モードのみ）
• rl_config_content：YAML 文字列（ADVANCED モードのみ）
• spec："ASCEND: <n> * <model> | <vCPUs> vCPUs | <GiB> GiB"
• cluster_id：pool- 接頭辞が付いたプール ID
• worker_num：通常は 1
• output_models：ステップ 5 の値
• enable_jupyter：SHARED プールでは false、DEDICATED プールでは true または false

注：SimRL では algorithm、datasets、parameters、env、log_path フィールドは使用しません。

ステップ 7 — 送信とモニタリング

1. SimRL タスクを作成する — train create-task --config '<json>' --sim-rl（または、先にドラフトを保存する場合は save-draft --sim-rl）。SDK：client.create_sim_rl_task(req)。
2. ステータスを確認する — train show-task --task-id <id> --sim-rl または train list-tasks --sim-rl
3. モニタリングする — get-resource-usage --metric ... --start ... --end ... --sim-rl、get-events --start-time ... --end-time ... --sim-rl、get-logs --sim-rl、get-signed-url --file-source ... --file-name ... --sim-rl
4. ライフサイクル — stop-task --sim-rl、restart-task --sim-rl、clone-task、delete-tasks --sim-rl（ID ごとの DELETE）、update-task --sim-rl
5. 統計情報 — train stats --workspace-id <id> --sim-rl

ドラフトのワークフロー（保存して再送信）

シナリオ：ユーザーはタスク設定をすぐに実行せずに保存し、後から編集して送信したいと考えています。

1. タスク設定を準備する — ドラフトに必要なのは name と workspace_id のみです。algorithm／spec は任意です。
2. ドラフトを保存する — train save-draft --config '<draft-json>'（SimRL のドラフトの場合は --sim-rl）→ task_id を返し、タスクステータスは DRAFT になります。
3. 後から設定を編集して再送信する：
   • SDK（ドラフト送信に推奨）：完全な TrainTaskDto 本文を指定して restart_train_task(task_id, req) を実行します。再起動エンドポイントがタスクを編集して再送信します。
   • CLI：train restart-task --task-id <draft-id> は既存の設定で再送信します。編集した設定を渡すには SDK を使用してください。SimRL の場合、restart-task --sim-rl で再送信します。
4. 再送信後、タスクは DRAFT 状態を離れ、CREATING → WAITING → RUNNING → 終了状態へと進みます。

推論に関する注意：save-draft（POST /train-tasks/draft）は、ステータスが DRAFT の task_id を返します。restart（POST /train-tasks/{id}/restart）は完全な TrainTaskDto 本文を受け取り、タスクを編集して再送信します。

モニタリングのワークフロー（進行中のタスク）

シナリオ：タスクが RUNNING で、進捗とリソース使用状況を追跡します。

1. ステータスを確認する — show-task --task-id <id>（30 秒間隔）
2. 実行ステージを照会する — get-stages --task-id <id> → SCHEDULING → PREPARING → RUNNING → END と、サブステージおよびタイムスタンプを返します。
3. リソース使用状況を照会する — get-resource-usage --task-id <id> --metric <m> --start <ts> --end <ts> → CPU／GPU／NPU の使用率とサンプルポイント
4. イベントを照会する — get-events --task-id <id> --start-time <ts> --end-time <ts> → タイムスタンプ付きの INFO／WARNING／ERROR／DEBUG イベント
5. 進捗をユーザーに報告する。WARNING／ERROR イベントが発生した場合は、先回りして通知します。

診断ワークフロー（失敗診断）

シナリオ：タスクが FAILED / RUN_FAILED / CREATE_FAILED → 自動分析、原因の特定、修正方法の提案。

1. タスクの詳細を取得して、失敗ステータス、失敗ステージ、終了コードを確認します
2. 実行ステージを取得して、どのステージで失敗したかを特定します（SCHEDULING/PREPARING/RUNNING/END）
3. イベントを取得し、level=Error で絞り込んでエラーイベントを確認します
4. ログを取得します。複数の方法を試します（タスクがすぐに失敗した場合、ログを取得できないことがあります）：
   • get-logs --task-id <id>（CLI）
   • SDK：list_observations(task_id) で利用可能なログファイルを一覧表示します
   • SDK：get_log_signed_url(task_id, file_source, file_name) でダウンロード URL を取得します
   • すべての方法で空の結果または 500 が返る場合：ログが生成される前にタスクが失敗した可能性があります
5. 主なエラーパターンを分析します：
   • CREATE_FAILED → spec の形式、cluster_id、リソースの利用状況、入力モデルのステータスを確認します
   • 入力モデルの準備未完了 → エラー：「入力モデルの準備ができていません」（input model not ready）。input_models[].source_type が CUSTOM_MODEL_ASSET で、モデルの status が DRAFT ではなく CREATING の場合に発生します。修正方法：モデルのステータスが DRAFT になるまで待つか、代わりに Gallery モデル（PUBLIC_MODEL_ASSET）を使用します。cloudrobo asset show-asset --asset-id <id> でモデルのステータスを確認します
   • タスク名の競合 → エラー：「リソースはすでに存在します」（409 Conflict）。修正方法：一意のタスク名を使用します（Train-YYYYMMDD-HHMMSS のようにタイムスタンプのサフィックスを追加します）
   • リソースのスケジューリング失敗 → spec と worker_num、クラスターの容量を確認します
   • イメージのプル失敗 → algorithm.image_url（MODEL_TUNING の場合）またはアルゴリズムアセットの設定（TRAIN_FROM_SCRATCH の場合）を確認します
   • データセットへのアクセス拒否 → datasets[].dataset_asset_id とワークスペースの権限を確認します
   • データセット形式の非互換 → 2 分未満で exitCode 1 の RUN_FAILED となり、ログファイルがありません。データセットの形式がアルゴリズムの要件と一致しない場合（例：LeRobot アルゴリズムが特定のデータセット形式を要求する場合）、または source_type が誤っている場合（CUSTOM_DATASET_ASSET ではなく DATASET を使用している場合）に発生します。修正方法：データセットの source_type が正しいことを確認します（ワークスペースの場合は CUSTOM_DATASET_ASSET を使用し、DATASET は使用しません）。代わりに Gallery データセット（PUBLIC_DATASET_ASSET）を試します。必要なデータセット形式について、アルゴリズムのドキュメントを確認します
   • OOM → spec のメモリ、worker_num を確認し、パラメーターの batch_size を減らします
   • アルゴリズムエラー → algorithm.command、boot_file、parameters を確認します
   • 出力モデルが存在する → エラー：「出力モデルはすでに存在します。モデル名を変更してください」。クローン／再起動の場合、SDK はアセットサービスに最新バージョンを問い合わせて、version_name を自動的にインクリメントします。create-task の場合は、一意のモデル名を使用します（-2、-3、またはタイムスタンプのようなサフィックスを追加します）
   • 専用プールのアセット権限 → エラー：「専用リソースプールでは、入力アセットへの読み取り権限が必要です」。適切なアセット権限がないまま DEDICATED プールを使用した場合に発生します。修正方法：SHARED プールに切り替えるか、関連するすべてのアセット（input_models、algorithm、datasets）に対して、読み取り／書き込み／使用の権限を付与します
   • ログを利用できない（API が 500 または空のリストを返す）：タスクが早すぎる段階で失敗し、ログが生成されていません。イベントからタスクの実行時間と終了コードを確認します。exitCode 1 で実行時間が 2 分未満の場合は、データセット形式またはトレーニングスクリプトのエラーである可能性が高いです。別のデータセットを試すか、必要なデータセット形式についてアルゴリズムのドキュメントを確認するよう提案します。
6. 診断結果と修正方法を出力します
7. ユーザーの確認後、設定を修正し、restart-task を実行するか、save-draft + create-task を実行します

長時間実行タスクのワークフロー

1. トレーニングタスクは数時間から数日かかる場合があります。作成後は、適切なポーリング間隔（60 秒以上）を設定します
2. ポーリングのたびに、現在のステータス、現在のステージ、経過時間、最新のイベントを報告します
3. タイムアウト時（ユーザー指定）、現在のステータスを出力し、続行／ログの表示／リソース使用状況の確認／停止を提案します

CLI コマンド形式

cloudrobo train <command> [OPTIONS] [--sim-rl]

• サブコマンド：kebab-case（create-task、list-tasks、get-stages など）
• --sim-rl は SimRL API サーフェスにルーティングします。--workspace-id <id> は stats の値を上書きします
• JSON パラメーターは --config '<json>' で指定します。必要に応じて --config-file からファイルを指定できます
• 出力：標準出力に JSON を出力します

CloudRobo CLI は独自に開発された Click ベースのツールです（hcloud／KooCLI ではありません）。SDK は 33 個のメソッドを公開します （train_* が 12 個、sim_rl_* が 15 個、接頭辞なしが 6 個）。CLI が公開するコマンドは 20 個です。list_observations は SDK 専用であり、resume とチェックポイント関連のメソッドは学習専用です。対応範囲の一覧については、 references/task-config-catalog.md を参照してください。

主要コマンド

CLI を優先：SDK を直接呼び出すより、CLI コマンド（cloudrobo train <command>）を常に優先してください。 Python SDK（TrainClient）を使用するのは、次の場合に限ります。（a）CLI が必要な操作に対応していない場合（例： list_observations は SDK 専用）、（b）パッケージをまたぐクエリの場合（例：アセットサービス経由でのアセットバージョン詳細の照会）、 （c）動的な JSON を組み立てるために CLI のフォールバックが必要な場合。SDK の完全なテンプレートについては、 SDK クイックスタートを参照してください。

workspace_id の自動解決：workspace_id が必要なすべてのコマンド（create-task、 save-draft、restart-task、list-tasks、stats）では、次の優先順位で自動的に解決されます。（1）明示的に指定した --workspace-id パラメーター、（2）設定済みのデフォルトワークスペース（cloudrobo workspace use）、（3）自動クエリ。 --config の JSON 本体に workspace_id を含める必要はありません。SDK が自動的に挿入します。

SDK レベルの検証：SDK メソッド（create_train_task、create_sim_rl_task、save_draft、 create_sim_rl_task_draft、restart_train_task、restart_sim_rl_task、copy_sim_rl_task、 register_train_checkpoint）は、HTTP 呼び出しを行う前に必須フィールドを検証します。必須フィールドがない場合は ValueError が発生します。CLI はこれらをユーザー向けのわかりやすい click.UsageError メッセージに自動変換します。 プログラムによるエラー処理が必要な場合は、SDK を直接使用してください。

タスクの作成

学習モード（ファインチューニングの MODEL_TUNING と事前学習の TRAIN_FROM_SCRATCH）、手法 （FFT／SFT／LORA／QLORA／DEEPSPEED）、ベースモデル、データセット、仕様はすべて --config の JSON 本体で指定します。専用の finetune／pretrain サブコマンドはありません。

ファインチューニングタスクを送信する（MODEL_TUNING）

cloudrobo train create-task --config '<task-json>'

• SDK： client.create_train_task(req) — req の形式についてはステップ 3aを参照してください
• API： POST /v1/training/train-tasks

事前学習タスクを送信する（TRAIN_FROM_SCRATCH）

cloudrobo train create-task --config '<task-json>'

• SDK： client.create_train_task(req) — req の形式についてはステップ 3bを参照してください
• API： POST /v1/training/train-tasks
  • log_path：任意の OBS パス — ユーザーがログパスを指定しない場合は省略できます
  • enable_jupyter：任意のブール値 — 学習中に JupyterLab にアクセスする場合は true を設定します
  • workspace_id：SDK によって自動挿入されます

完全な JSON 設定からタスクを作成する（train または SimRL）

cloudrobo train create-task --config '<task-json>' [--sim-rl]

• SDK： client.create_train_task(req)／client.create_sim_rl_task(req)
• API： POST /v1/training/train-tasks／POST /v1/training/rl-tasks/simulation

ドラフトタスクを保存する（train または SimRL）

cloudrobo train save-draft --config '<draft-json>' [--sim-rl]

• SDK： client.save_draft(req)／client.create_sim_rl_task_draft(req)
• API： POST /v1/training/train-tasks/draft／POST /v1/training/rl-tasks/simulation/draft

タスク管理

すべてのコマンドで --sim-rl を受け付けます（resume-task、clone-task を除く。これらは SimRL 専用です）。API プレフィックス： /v1/training/train-tasks（train）／/v1/training/rl-tasks/simulation（SimRL）。

コマンド	CLI 構文	SDK メソッド	API サフィックス
タスク一覧	list-tasks [--train-mode] [--status] [--offset] [--limit]	list_train_tasks / list_sim_rl_tasks	GET /
タスク詳細表示	show-task --task-id <id>	show_train_task / show_sim_rl_task	GET /{task_id}
タスク更新	update-task --task-id <id> --config '<json>'	update_train_task / update_sim_rl_task	PATCH /{task_id}
タスク削除	delete-tasks --task-id <id> [--task-id <id>...]	batch_delete_train_tasks(execution_ids) / delete_sim_rl_task(task_id)	POST /batch-delete（train）／DELETE /{task_id}（SimRL）

delete-tasks の動作：通常のトレーニングタスクでは、CLI は一括削除を呼び出す前に、指定された task_id から show-task を使って execution_id を自動的に取得します。ユーザーはタスク ID を 直接指定できるため、execution_id を手動で調べる必要はありません。SimRL では task_id を直接使用します。

| タスク停止 | stop-task --task-id <id> | stop_train_task / stop_sim_rl_task | POST /{task_id}/stop | | タスク再起動 | restart-task --task-id <id> [--config '<json>'] [--config-file <path>] [--sim-rl] | restart_train_task(task_id, req=None) / restart_sim_rl_task(task_id, req=None, task_detail=None) | POST /{task_id}/restart | | タスク複製 | clone-task --task-id <id> [--config '<json>'] [--config-file <path>]（SimRL 専用） | copy_sim_rl_task(task_id, req=None, task_detail=None) | POST /rl-tasks/simulation/{task_id}/copy | | タスク再開 | resume-task --task-id <id>（train 専用） | resume_train_task | POST /{task_id}/resume | | 統計 | stats --workspace-id <id> [--user-id] | count_train_tasks_by_status / count_sim_rl_tasks_by_status | GET /stats |

再起動 ＝ 編集して再送信します。CLI では --config／--config-file を使って元のタスクのフィールドを 上書きできます。SDK の req パラメーターも同じ動作をします。DRAFT 以外の train タスクでは name／train_mode／ train_method を変更できません。SimRL の再起動には DRAFT ステータスが必要です。SDK の task_detail パラメーターを 指定すると、自動の show 呼び出しを省略できます。SDK は input_models／output_models を自動的にクリーンアップし （ランタイムフィールドを除去）、save_mode=NEW_MODEL|NEW_VERSION の場合は version_name を自動的にインクリメントし （アセットサービスに問い合わせて最新バージョンを取得）、simple_params／rl_config_content を配列／辞書から JSON 文字列に自動シリアライズします。 複製 は SimRL 専用です（train のコピー API は削除されました）。SDK は、req に明示的な name が指定されていない限り、 -copy-{4hex} サフィックスを付けて新しい名前を自動生成します（例：my-task-copy-a1b2）。再開 は train 専用です。

タスクのモニタリング

コマンド	必須パラメーター	SDK メソッド	戻り値
get-stages --task-id <id>	--task-id	list_train_stages	4 つのステージ：SCHEDULING→PREPARING→RUNNING→END
get-resource-usage --task-id <id> --metric <m> --start <s> --end <e>	--metric --start（秒）--end（秒）	show_resource_usage / show_sim_rl_task_resource_usage	CPU/GPU/NPU の使用率
get-logs --task-id <id> [--file-name] [--log-name-pre]	--task-id	get_log_content / show_sim_rl_task_observations_content	ログ内容（--file-path ではなく --file-name）
get-signed-url --task-id <id> --file-source <s> --file-name <n>	--file-source --file-name	get_log_signed_url / show_sim_rl_task_observations_signed_url	OBS の一時ダウンロード URL
get-events --task-id <id> --start-time <ms> --end-time <ms>	--start-time（ミリ秒）--end-time（ミリ秒）	list_events / list_sim_rl_task_events	INFO/WARNING/ERROR/DEBUG イベント
（SDK 専用）list_observations	--task-id	list_observations / list_sim_rl_task_observations	ファイル一覧（CLI の get-logs で内容を取得できます）

すべて --sim-rl を受け付けます。get-events はミリ秒（13 桁）、get-resource-usage は秒（10 桁）を使用します。

チェックポイントの管理（train のみ、--sim-rl なし）

cloudrobo train list-checkpoints --task-id <id> [--status] [--name] [--offset] [--limit] [--order]
cloudrobo train register-checkpoint --task-id <id> --checkpoint-name <name> [--save-mode NEW_VERSION|NEW_MODEL] [--version-name] [--model-name]

コマンド	SDK メソッド	API
list-checkpoints	list_train_checkpoints(task_id, **params)	GET /{task_id}/checkpoints
register-checkpoint	register_train_checkpoint(task_id, req)	POST /{task_id}/checkpoints/register

register-checkpoint：NEW_VERSION（デフォルト）は既存モデルに追加し、NEW_MODEL は新しいモデルを作成します （--model-name が必要です）。戻り値は WAITING で、非同期に処理されます。

アルゴリズムの検索

利用可能なアルゴリズムを一覧表示する

cloudrobo asset list-publication-assets --type algorithm [--name <fuzzy-name>] [--limit 20]

• SDK（パッケージ横断）： asset_client.list_publication_assets(type="algorithm", limit=20)
• API： パッケージ横断です。train サービスを直接呼び出すのではなく、asset サービスを呼び出します。

各アルゴリズムには、事前学習タスクの作成に必要な engine.image_url、command、boot_file を含む ext_metadata があります。

アセットのバージョン詳細を照会する（モデル／アルゴリズム／データセット）

• API： GET /v1/assets/{asset_id}/versions/{version_id}（cloudrobo-asset-manager サービス）
• モデルのバージョン詳細では、actions 配列が返されます。各アクションには {action, algorithm:{asset_id, version_id}, status} が含まれます。action フィールド（例：FFT、LORA、ONLINE_DEPLOYMENT）は train_method になります。トレーニング関連のアクションは status=="ENABLE" で絞り込みます（ONLINE_DEPLOYMENT などは除外します）。
• アルゴリズムのバージョン詳細では、ext_metadata.hyperparams（デフォルトのハイパーパラメーター）、 ext_metadata.environment_variables（[{name, default, description}] 形式の環境変数）、 ext_metadata.engine.image_url、ext_metadata.command、ext_metadata.inputs／outputs、 ext_metadata.resource（NPU カードの制約。Step 3a.6 を参照）が返されます。
• 使い方： ファインチューニングでは、モデルのアクションからアルゴリズムを取得し、アルゴリズムのバージョン詳細を照会してハイパーパラメーターを取得します。事前学習では、アルゴリズムのアセットのバージョン詳細を直接照会し、ハイパーパラメーターと ext_metadata 全体を取得します。

送信の動作と確認

デフォルトでは確認なしで送信します。 作成コマンド（create-task／restart-task／ register-checkpoint／save-draft）は、確認を求めずに送信します。エージェントは生の JSON やコードを出力してはいけません。--verbose/-v を指定した場合は、ユーザー向けに整理した概要（表／リスト）を提示してから、そのまま送信します。はい／いいえの確認は行いません。

破壊的操作（stop-task／delete-tasks／resume-task）：エージェントは実行前に task_id を確認します。 restart-task：設定を編集した場合は、差分を簡潔に表示してから送信します。編集していない場合は、確認なしで送信します。 update-task：PATCH の前に、変更するフィールドを確認します。

詳細表示形式

グループ化されたテーブル／リストを使用し、生の JSON は絶対に表示しません。セクション：【基本信息】【算法配置】【基础模型】（MODEL_TUNING のみ）【超参】（テーブル）【环境变量】（テーブル）【数据集】【资源配置】【训练产物】。該当しないセクションは省略します。環境変数が空の場合は「（无）」と表示します。restart-task --verbose の場合は、task_id と変更されたフィールドを差分形式で表示します。

必須パラメーター（デフォルト値なし）

コマンド	必須パラメーター	備考
get-resource-usage	--metric --start --end	秒（10 桁）
get-events	--start-time --end-time	ミリ秒（13 桁）
get-signed-url	--file-source --file-name	file_source は 8 値の列挙型から指定
stats	--workspace-id	—
finetune	--method	大文字：FFT/SFT/LORA/QLORA/DEEPSPEED
pretrain/finetune	--spec	Ascend: N * Model | vCPUs vCPUs | GiB GiB

参考ドキュメント

• CLI インストールガイド — cloudrobo CLI のインストールと設定
• IAM ポリシー — 最小権限の認証情報モデル
• 検証方法 — 検証方法の詳細
• データフロー図 — Mermaid のデータフロー図
• 受け入れ基準 — 受け入れ基準
• タスク設定リファレンス — TrainTaskDto のフィールド、アルゴリズムマッピング、spec 形式、ステータス列挙型、ステージ／イベント構造、3 層カバレッジマトリックス
• SDK クイックスタート — 完全な Python SDK 呼び出しテンプレート：初期化、finetune/pretrain/SimRL の完全なリクエスト本文の例、ドラフトワークフロー、ポーリングと監視、パッケージをまたいだクエリ
• API パス — SDK ソースの行番号を含む全エンドポイント一覧

エッジケース

シナリオ	対応方法
workspace_id がない	すべてのコマンドで設定から自動解決するか、自動照会します。cloudrobo workspace use を実行してデフォルトを設定してください
タスクが終端状態ではない	30～60 秒間隔でポーリングしてください。トレーニングには数時間から数日かかることがあります
spec の形式	JSON ではなく、文字列 Ascend: <n> * <model> | <vCPUs> vCPUs | <GiB> GiB です。ext_metadata.resource の制約でフィルタリングしてください
train_method / train_mode	大文字の列挙値：FFT/SFT/LORA/QLORA/DEEPSPEED、MODEL_TUNING/TRAIN_FROM_SCRATCH
CREATE_FAILED	spec の形式、cluster_id、リソースの利用可否、タスク名の一意性（409 Conflict）、入力モデルのステータス（ワークスペースのモデルでは DRAFT が必要）を確認してください
RUN_FAILED	ログ／イベントを確認してください。よくある原因：OOM、イメージのプル失敗、データセットへのアクセス拒否、データセット形式の不整合（2 分未満で exitCode 1、ログなし）
リソースのスケジューリング失敗	spec、worker_num、クラスターの容量、ext_metadata.resource の最小 NPU 制約を確認してください
停止済みタスク	再送信には restart-task を使用してください。サポート対象のトレーニングのみのケースでは resume-task を使用してください
SimRL の再開	サポートされていません。resume-task では --sim-rl を指定できません
CLI からの Draft の送信	restart-task は --config／--config-file をサポートしており、再送信前にフィールドを編集できます
必須フィールドがない	SDK は HTTP 呼び出し前に検証します。CLI は不足しているフィールドの一覧を click.UsageError で表示します
AK/SK が設定されていない	HTTP 署名の段階で操作に失敗します。HUAWEI_CLOUD_AK／HUAWEI_CLOUD_SK を設定してください
配列サイズの上限	datasets、input_models、output_models はそれぞれ最大 1 項目です
parameters の形式	JSON 文字列です。各項目は key+desc+value+constraint です。すべてのハイパーパラメーターを渡してください
env の形式	JSON 文字列です。カスタム環境変数がない場合は "[]" を渡してください
cluster_id	pool- プレフィックスのプール ID（例：pool-6872b4ac-...）です。プールタイプは SHARED または DEDICATED です。SHARED プールでは完全な pool_id（pool- で始まるもの）が必要です。DEDICATED プールでは cluster_id を直接使用します。DEDICATED プールを使用するには、アセットの読み取り権限が必要です
タスクのステータス	status は 10 個の値：CREATING/RUNNING/FAILED/WAITING/DRAFT/FINISHED/STOPPING/DELETING/ABNORMAL。detail_status は 15 個の値（CREATE_FAILED/RUN_FAILED/STOP_FAILED/NOT_EXIST/UNKNONW を追加）。終端ステータス：FINISHED/FAILED/STOPPED/ABNORMAL
タスクの削除	元に戻せません。CLI の delete-tasks --task-id <id> は、通常のトレーニングタスクでは task_id から execution_id を自動解決するため、手動での検索は不要です
アルゴリズム情報	ext_metadata から動的に取得します。asset_ids をハードコードしないでください
オブジェクトストレージ	obs:// プロトコルを使用する必要があります。s3:// は使用できません
スキル間の連携	他のスキルは呼び出しません。データ処理には cloudrobo-dataset、デプロイには cloudrobo-infer を使用してください
--sim-rl フラグ	14 個のコマンドで使用できます。pretrain／finetune／resume-task／list-checkpoints／register-checkpoint では使用できません
get-logs のファイル選択	--file-path ではなく --file-name を使用してください。--log-name-pre はプレフィックスで照合します
クローンタスク名の競合	SDK は {original-name}-copy-{4hex} という名前を自動生成します。上書きするには --config '{"name":"custom-name"}' を渡してください

検証とベストプラクティス

• テスト：bash scripts/test-cli-commands.sh（CLI/SDK/API）。網羅的なテストについては templates/test-vars.json を参照してください
• ポーリング：30～60 秒間隔で実行し、ステータスとステージの変化を報告します。FINISHED の場合はエクスポート／デプロイを提案し、FAILED の場合はログ／イベントを提示します
• ドラフトのワークフロー：save-draft → DRAFT であることを確認 → restart-task → DRAFT のままであることを確認 → 終端状態になるまでポーリング
• モニタリング：get-stages（4 ステージのフロー）、get-resource-usage（CPU/GPU/NPU）、get-events（--level Error でフィルタリング）
• SimRL：--sim-rl を指定してモニタリングを繰り返します（SimRL にはステージエンドポイントがないため、get-stages は使用しません）。resume-task が --sim-rl を拒否することを確認します
• ドライラン：この CLI ではサポートされていません。create-task で送信する前に、save-draft と show-task でパラメーターを検証します
• ドラフト：編集した設定で送信するには、SDK の restart_train_task(task_id, req) を使用します（CLI では設定本文を受け付けません）
• 統計：ステータス分布の概要を確認するには、stats --workspace-id <id> を使用します