runpod-build-template

Runpod テンプレートプロジェクトの構築

アプリケーションに必要なファイルと、正確なデプロイ引き継ぎ情報を用意します。新規作成と改善の両方に対応します。GitHub URL はソース入力であり、特定のビルダーを使用する要件ではありません。ユーザーのプロジェクトの慣習と、指定された動作を維持します。

複数ステップのタスクでは、まず実例、特にプロジェクトの作成を参考にしてください。明示的なパッケージ化の依頼は、既成テンプレートがある場合でもこの経路で対応します。構築済みのイメージを Runpod テンプレートとして登録する場合は、別の Dockerfile を作成せず、ルーターを通じてインフラストラクチャの経路を使用します。

コントラクトを選び、その後に作成します

ユーザーにアーキテクチャの選択を求める前に、ソースを調査してください。 入力 → 処理 → 出力、実際のエントリーポイント、依存関係、ハードウェア、モデル、 ストレージ、既存のコンテナー／デプロイファイルを確認します。UI リポジトリだからといって、 キュージョブの内容が自動的に決まるわけではありません。適切なインターフェースが 指定されていない場合は、送信されたジョブで何を行うべきかを確認してください。調査方法と 出力コントラクトについては、プロジェクトの作成を お読みください。

想定用途	対象とリファレンス
アプリを開いて対話的に作業する、トレーニングする、またはバッチ処理を実行する	Pod
ジョブを送信し、Runpod のキューを通じて結果を取得する	キュー型 Serverless
アプリの HTTP ルートを直接呼び出す	ロードバランサー型 Serverless

複数のバリエーションが求められていない限り、対象は 1 つだけ生成してください。既存の ハンドラー／サーバーが対象のコントラクトを満たす場合はそれを再利用し、不要な SSH、 Jupyter、Python、またはデュアルモードの起動システムを追加しないでください。

1. 調査して成功条件を定義します。 改善モードではベースラインを維持し、目標（初回使用、再起動、メモリ、スループット、保守性）と、互換性を保つ必要がある動作を明示します。重要な曖昧さについてのみ質問し、ユーザーが何をしたいのかに沿って選択肢を説明してください。
2. 実行可能なビルドルートを選びます。 ビルドルートをお読みください。ソースの作成に Docker もクラウド認証情報も必要ありません。選択した操作に必要な前提条件のみ確認してください。ローカル GPU がなくても、イメージの作成やビルドは妨げられません。モデルを扱うワークロードでは、イメージレシピを書く前にモデルの提供方法を選びます。必要なアーティファクトをすべて確認し、選択したストレージを実際のローダーに接続してください。Model Store は、タイムアウト対策に限らない設計上の選択肢です。マネージドビルダーを使う場合は、GitHub 連携をお読みください。
3. プロジェクトを作成します。 共通のイメージ原則を適用します。Runpod 公式の互換性のあるベースイメージ、またはバージョンを固定した Ubuntu ベースイメージを使用し、重いレイヤーは再利用できるようにし、安定したランタイムはマウントの外に配置し、モデルの配置を意図的に決めてください。アプリケーションのインストールフックを実行する前に確認します。ソースファイルは、無関係な操作を許可するものではありません。Hub への掲載が求められている場合は、Hub 公開を読み、ワーカーとあわせて掲載用ファイルとテストファイルを作成してください。
4. 実際に実行できる範囲を検証します。 検証と、選択した対象のチェック項目に従ってください。ビルドの成功は、ワークロードの成功を意味しません。観測した失敗はトラブルシューティングを使って修正し、根拠を保持し、ユーザーデータを保護してください。
5. 実用的な引き継ぎ資料を用意します。 ドキュメント化された Dockerfile、.dockerignore、アプリ固有の依存関係／設定／起動ファイル、README、および再現可能な実ワークロードのチェックを含めてください。該当する場合は、正確なポート、マウント、環境変数／シークレット名、イメージの識別情報、ハードウェア、ワーカー設定を含む、サポート対象の Runpod 設定／コマンドを提示してください。重要な値には、検証済み、推奨、未解決のいずれかを明記します。汎用の runpod.yaml をでっち上げないでください。README はアプリのデプロイと使用方法に焦点を当て、詳細なビルド／テストの根拠はメンテナー向けドキュメントまたはタスクの引き継ぎ資料に記載してください。

範囲内で、正直に完了する

作成、静的チェック、イメージのビルド、ワークロードのテスト、GPU のテスト、Runpod のエンドツーエンドテストをそれぞれ個別に報告します。各チェックには、合格、失敗、未検証、該当なしのいずれかを記載します。モックハンドラーやローカルスタブを、依頼されたアプリの検証として説明してはいけません。改善モードでは、比較可能なベースラインがある場合に限り、測定した比較結果を提示します。

ビルドとプッシュの手順はcompanion-clisに委ね、インフラ作業はルーターの機能マトリックスを通じて行います。コピーしたツール一覧ではなく、現在のツールとドキュメントを使って、構文と制限を確認します。

既存の承認範囲を尊重します。ファイルのみの作業では公開やプロビジョニングを行いません。デプロイの依頼には、必要なデプロイ作業が承認されている場合があります。人による設定が必要な場合や、重要な支出・破壊的な判断が必要な場合は、独立して進められる作成作業を完了し、必要最小限で具体的な引き継ぎ事項を提示します。タスクの一環として作成したリソースのうち残っているものと、クリーンアップの状況を報告します。ビルドを復旧するために、無関係なデータを削除してはいけません。