プールの仕組み
レシピのWarmPool ヘルパーは、設定された数のサンドボックスを起動し、
それぞれで準備完了チェックを実行します。各サンドボックスのメインプロセスは、コマンドの合間も実行されたままです。
定期的な ping は必要ありません。
各ワークロードが準備完了のサンドボックスを 1 つクレームすると、それをトリガーとして代わりのサンドボックスの準備が始まります。
クレームしたサンドボックス内で実行される exec() はすべて、同じサンドボックスとファイルを共有します。
ワークロードが終了または失敗すると、ヘルパーはそのサンドボックスを停止します。後続のワークロードには
別のサンドボックスが割り当てられるため、以前のワークロードのローカル状態が引き継がれることはありません。
レシピを実行する
Python 3.11 以降、uv、
およびサーバーレスのアクセス権と認証情報が必要です。
-
レシピのリポジトリをダウンロードまたはクローンし、
recipes/warm-poolを開きます。依存関係をインストールし、環境ファイルを作成します。 -
.envとdemo.pyの冒頭付近で認証情報を設定します。- Forge APIキー
- CoreWeave API アクセストークン
Forge APIキーを.envに追加します。demo.pyに次のインポートを追加し、既存のAUTHの代入を置き換えます。このコードはFORGE_API_KEYを明示的に読み取り、SDK がサポートする認証ヘッダーを使用します。ヘッダー名とストラテジー名は互換性のための識別子であり、実際に使用する認証情報は Forge APIキーです。オプションのwandb依存関係をインストールする必要はありません。 -
比較を実行します。
ワークロードに合わせてプールを調整する
demo.py 内の定数を編集します。
demo.py 内の WORKLOAD を独自のコードに置き換えます。共通のセットアップ処理は warm_pool.py の prepare() に追加し、
アプリケーションに適した準備完了チェックを使用してください。非同期のワークロードハンドラ内で
複数のコマンドを実行する場合は、レシピのクレームコンテキストを使用します。
プールを稼働させ続ける
リクエストを受け付けている間は、プールとそれを囲むSession コンテキストを開いたままにしてください。
各 Python プロセスはそれぞれ個別のプールを所有します。デモでは比較の完了後に両方を閉じます。
ヘルパーは、アイドル状態が 5 分続いたサンドボックスを置き換えます。各サンドボックスの有効期間は 10 分です。
プールは、コンテキストが開いている間は補充を続けます。これらのデフォルト設定では、ジョブが 5 分を十分に下回るようにしてください。
サンドボックスをクレームしても、その期限はリセットされません。より長いジョブ向けの設定や、中断された run の後のクリーンアップについては、
レシピを参照してください。
準備が一時的に失敗した場合は、最大 3 回まで試行されます。すべての試行が失敗した場合、
または準備中に再試行できないエラーが発生した場合は、準備完了のサンドボックスが残っていても、以降のクレームはすべて失敗します。
プールと Session コンテキストを終了してクリーンアップし、
根本的な問題が解決してから新しいプールを作成してください。
補充時間を短縮するには、安定した依存関係をイメージにビルドしておくか、
ファイルシステムスナップショットから準備済みのワークスペースファイルをリストアします。
スナップショットが取得するのは、設定済みのマウント内のファイルです。アプリケーションプロセスは別途
起動する必要があります。サンドボックステンプレート
に、共有イメージとスナップショットの設定を保存できます。