kermt-setup

kermt-setup

KERMT エージェント環境をブートストラップします。新しいマシンで初めて実行するとき、または Dockerfile や environment.yml を変更した後に、ほかの kermt-* スキルを呼び出す前に一度実行してください。

ハードウェア要件

• GPU：ホストから少なくとも 1 台の CUDA 対応 NVIDIA GPU が認識できること。イメージは nvidia/cuda:12.6.3-cudnn-devel-ubuntu22.04 をベースとしているため、ホストドライバーは CUDA 12.6 に対応している必要があります。呼び出す前に、ホストの nvidia-smi で確認してください。
• ホストの Docker：Docker エンジンと nvidia-container-toolkit が必要です。ツールキットがないと、以下のワークフローのステップ 2 で docker run --gpus all が失敗します。
• ディスク：ビルドした kermt イメージ用に約 50 GB の空き容量が必要です（docker image inspect --format '{{.Size}}' では約 44 GB と表示されます。docker images の Size 列には、イメージ間で重複排除されて共有可能な buildx のアテステーションレイヤーが加算されるため、約 100 GB と表示されることがあります）。ディスク上で固有に使用するストレージとして約 50 GB を確保し、ビルドキャッシュも保持する場合は余裕を持たせてください。
• メモリー：ビルド中、conda 環境の依存関係解決時に RAM 使用量が最大約 4 GB になります。
• このスキル自体はトレーニング／推論ワークロードを実行しません。ワークフローごとのハードウェア要件（VRAM、GPU 数）は、それぞれの kermt-<workflow> スキルに記載されています。

呼び出すタイミング

• ユーザーから明示的に依頼された場合（/kermt-setup、「kermt をセットアップして」、「kermt イメージをビルドして」など）。
• または、別の kermt-* スキルがイメージの存在しないことを検出し、ここに誘導した場合。（ほとんどのほかのスキルは自分で kermt_ensure_image を呼び出すため、通常は初回セットアップ、デバッグ、または強制的な再ビルドの場合にのみ必要です。）

入力

このスキルに必須の引数はありません。省略可能なオーバーライドは、呼び出す前に環境変数で指定するか、ユーザーのシェルで設定できます。

• KERMT_IMAGE — ビルド／検証するイメージタグ（デフォルト：kermt:latest）。
• KERMT_REPO — kermt リポジトリのチェックアウト先のホストパス（デフォルト：スクリプトの場所から自動的に導出）。

ユーザーがリポジトリのパスを指定しておらず、現在の作業ディレクトリが kermt リポジトリのクローン内でない場合は、続行する前にリポジトリのパスを尋ねてください。

ワークフロー

すべての作業は agent/scripts/kermt_container.sh を通じて行います。このスクリプトのサブコマンドは、読み込みを行わずに直接呼び出せます。スキルで使用する場合は、この方法を推奨します。

HELPER=$KERMT_REPO/agent/scripts/kermt_container.sh とします。

1. docker がインストールされ、デーモンに接続できることを確認します。

   $HELPER check_docker
   

   終了コードが 0 の場合は続行します。0 以外の場合は、エラー（通常は「docker が PATH にない」または「デーモンに接続できない」）をユーザーに伝え、ステップ 2 を試さないでください。

2. GPU パススルーが機能することを確認します。

   $HELPER check_gpu
   

   これは docker run --rm --gpus all nvidia/cuda:12.6.3-base-ubuntu22.04 nvidia-smi を実行し、終了ステータスを確認します。0 以外の場合は、ホストに nvidia-container-toolkit をインストールし、CUDA 対応の NVIDIA GPU がホストから認識されることを確認するようユーザーに伝えてください（ホスト上の nvidia-smi も正常に動作する必要があります）。ここで停止してください。GPU パススルーがなければ kermt イメージはビルドできますが、ワークフローは実行できません。

3. kermt イメージをビルドするか、確認します。

   $HELPER ensure_image
   

   イメージがすでに存在する場合は、すぐに戻ります。それ以外の場合は $KERMT_REPO/Dockerfile からビルドします。実行する前にユーザーに警告してください。一般的なワークステーションでは初回のビルドに約 10～20 分かかり、ビルドログがコンソールに出力されます。バックグラウンドでは実行しないでください。ユーザーは進行状況を確認したいと考えており、ビルドエラーがあればすぐに表面化させる必要があります。

4. コンテナ内で GPU のスモークテストを行います。 python コマンド全体を 1 つの文字列として引用符で囲んでください。ヘルパーは引数を bash -c "$*" に渡すため、複数の単語からなるコマンドを引用符で囲まないと再解析され、埋め込まれた引用符がすべて取り除かれます。

   $HELPER run -- 'python -c "import torch; print(\"cuda_available:\", torch.cuda.is_available()); print(\"device_count:\", torch.cuda.device_count())"'
   

   期待される出力は cuda_available: True と、正の値の device_count です。ステップ 2 を通過したにもかかわらず cuda_available が False の場合は、コンテナの CUDA 接続に問題があります。出力全体をユーザーに伝えて停止してください。環境の準備ができたと宣言してはいけません。

5. ユーザーに概要を伝えます。 次の内容を報告してください。

   • イメージのタグと ID（docker image inspect $KERMT_IMAGE --format '{{.Id}}'）。
   • イメージのサイズ（docker image inspect $KERMT_IMAGE --format '{{.Size}}'）。
   • コンテナ内で検出された GPU の数。
   • 「準備完了」— ユーザーはこれで他の kermt-* スキルを呼び出せます。

厳守事項

• docker イメージをプルまたはプッシュしないでください。kermt イメージはローカルでのみビルドします。
• ユーザーの明示的な確認なしに、古い kermt:* タグを自動的に削除またはプルーニングしないでください。ユーザーが別のコンテナで、特定のタグに依存するファインチューニングや事前学習を実行している可能性があります。
• ホストの docker デーモン設定、daemon.json、またはユーザーグループのメンバーシップを変更しないでください。
• このスキルの一環として Dockerfile または environment.yml を変更しないでください。Dockerfile の問題でビルドに失敗した場合は、エラーを伝えて停止し、編集するかどうかはユーザーに委ねてください。
• イメージがすでに存在する場合、ユーザーが明示的に強制再ビルドを求めない限り、イメージを再ビルドしないでください（ensure_image に --no-cache または --pull フラグを渡さないでください）。

強制再ビルド

ユーザーが明示的に再ビルドを求めた場合（たとえば、Dockerfile または environment.yml の変更後）、まず古いイメージを削除し、その後 ensure_image を再実行するのが最も簡潔な方法です。

docker image rm $KERMT_IMAGE
$HELPER ensure_image

docker image rm を実行する前に、ユーザーに確認してください。