mcpField
P
physicalai-train-exporting-and-validating

physicalai-train-exporting-and-validating

github.com/open-edge-platform開発14680 回インストール今日更新
リポジトリ

physicalai-train-exporting-and-validating について

physicalai-train-exporting-and-validating は、physicalai ポリシーを扱う開発者向けのエクスポートと検証のスキルです。Python API と CLI の手順を扱い、成果物の構造、数値の一致、Runtime の読み込み互換性を重視します。

主な機能

  1. 01ONNX、OpenVINO、Torch、ExecuTorch へエクスポート
  2. 02Python API と CLI のワークフロー
  3. 03成果物の構造とメタデータを確認
  4. 04Torch 経路との数値出力を比較
  5. 05Runtime の読み込みを検証

活用シーン

  1. 01デプロイ用ポリシーモデルのエクスポート
  2. 02API と CLI の成果物の一致確認
  3. 03Torch と異なる出力の調査
  4. 04ランタイム読み込みとバックエンド依存関係の確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/open-edge-platform/physical-ai-studio --skill physicalai-train-exporting-and-validating

インストール後、Claude Code で/physicalai-train-exporting-and-validatingを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
executorch.md
export-contract.md
onnx.md
openvino.md
torch.md

詳細

Studio ポリシーのエクスポートと検証

エクスポート関連の実装は library/src/physicalai/export/ にあります。backends.py には ExportBackend 列挙型（onnx、openvino、torch、executorch）と、バックエンドごとのパラメータークラスがあります。mixin_policy.py の ExportablePolicyMixin は、ポリシーに export(output_dir, backend=...) を提供します。Python API はライブラリの主要な動作です。CLI エントリーポイントの library/src/physicalai/cli/export.py も、同じアーティファクトの契約を維持する必要があります。エクスポートは Studio が担当し、読み込みは Runtime が担当します。

ワークフロー

  1. 入力を特定します：ソースのポリシークラス（例：physicalai.policies.ACT）、.ckpt のパス、対象バックエンド、およびそのバックエンドで想定される Runtime のローダー動作を確認します。
    • 完了条件：コードに手を加える前に、4 項目すべてを確定します。
  2. 方法を選び、両方で一貫性を保ちます。どちらも同じアーティファクトを生成する必要があります。
    • Python：policy.export(output_dir, backend=ExportBackend.ONNX)。
    • CLI：physicalai export --policy physicalai.policies.ACT --ckpt_path model.ckpt --backend onnx --output_dir ./export。
  3. 汎用コードを編集する前に、バックエンドの制約を確認します。 対象バックエンドのリファレンス（references/<backend>.md）を参照してください。各バックエンドを確認せずに、修正をすべてのバックエンドに一般化しないでください。
  4. エクスポート後、代表的な入力を使って Torch ポリシーの処理経路との数値的なパリティを検証します。 パリティによって正しさを確認できます。
    • 完了条件：サンプル入力の最大絶対差／相対差がモデルファミリーの許容範囲内であるか、差異の原因を把握して文書化していること。
  5. references/export-contract.md に照らして、アーティファクトの構造とメタデータを検証します。
    • 完了条件：想定されるモデルファイルとメタデータファイルが存在し、入力／出力／特徴量の名前が Runtime の前処理と一致していること。
  6. Runtime の処理経路を確認します。 デプロイ用アーティファクトについては、Runtime が拡張子から自動検出できるか、または InferenceModel(...) を介してバックエンドを明示的に読み込めるかを検証します。

検証ループ

エクスポート → 検証 → 修正 → 繰り返しの順に、パリティと構造の両方が合格するまで実行します。

# from library/
physicalai export --policy <ClassPath> --ckpt_path <model.ckpt> --backend <backend> --output_dir ./export
uv run pytest tests/unit/export -k <backend>

API 向けの変更では、チェックポイントを読み込み、policy.export("./export-api", backend=ExportBackend.<BACKEND>) を呼び出し、アーティファクトのメタデータを CLI の出力と比較する同等の Python スクリプト／テストを追加または実行します。

パリティ（正しさ）とレイテンシー／ウォームアップ（デプロイの実現可能性）は別々に確認します。一方に合格しても、もう一方への合格を意味するものではありません。

バックエンドに関する注意事項

  • onnx／openvino — デプロイ向けです。Runtime コアにアダプターが含まれているため、依存関係がインストールされていればアーティファクトを読み込めます。
  • torch — 開発／デバッグ向けです。対応する Runtime アダプターがインストールされ、文書化されている場合に限り、デプロイ対応をうたってください。
  • executorch — オプションで、依存関係の影響を受けるエッジ／モバイル向けです。このパッケージの Runtime コアにはアダプターが含まれていません。文書化されたコンパニオン配布物がある場合に限り、利用可能として扱ってください。

必須の確認事項

  • エクスポートディレクトリに、想定されるバックエンドのモデルファイルとメタデータファイルが含まれていること。
  • メタデータ内の入力／出力／特徴量の名前が、Runtime の前処理およびアクションチャンクのセマンティクスと一貫していること。
  • Python API と CLI のエクスポートで、同等のアーティファクト構造とメタデータが生成されること。
  • バックエンド固有の依存関係は遅延インポートするか、明確なインストール方法とともにガードすること。
  • Runtime がパッケージ内、または文書化されたコンパニオン経由で読み込めないバックエンドを、ユーザー向けドキュメントに追加しないこと。
  • CLI のドキュメント（library/docs/how-to/export/）と Python API の例が一貫していること。

リファレンス

  • references/export-contract.md — Runtime と共有するアーティファクト要件（同期を維持し、不一致があれば CI で失敗するようにします）。
  • references/onnx.md、references/openvino.md、references/torch.md、references/executorch.md — バックエンドごとの制約。

コメント

Markdown 対応