moonshotai/Kimi-K2.7-Code を使用します。ただし、DeepSWE と Sandboxes の利用にこのプロバイダーは必須ではありません。提供されるレシピでは、Forge のエンドポイントと認証情報の処理が固定されています。--model オプションを使用すると、同じエンドポイント上の別のモデルを選択できます。別のプロバイダーを使用する場合は、レシピのモデルの設定と認証を変更する必要があります。
非公開のテストファイルは検証用サンドボックスにのみ渡されます。レシピは、両方のサンドボックスを外向きのネットワークアクセスを拒否した状態で作成します。サンドボックスと推論の認証情報は、ローカルマシンの外に送信されることはありません。
このガイドは、小規模なサンプルでインテグレーションを検証するためのものです。ホスト側のエージェントアダプターと run の制限は、公式の DeepSWE リーダーボードのセットアップとは異なります。2 つのタスクの結果から、ベンチマーク全体でのパフォーマンスを推定することはできません。
前提条件
開始する前に、次の前提条件を満たしていることを確認してください。- Python 3.12 以降、Git、および
uvパッケージマネージャー。 - サーバーレスサンドボックスが有効になっている組織で Sandbox User ロールが付与された CoreWeave API アクセストークン。
- Serverless Inference 上のサンプルモデルにアクセスできる Forge APIキー。
- ローカルマシンから Sandboxes API および
https://api.inference.wandb.ai/v1へのネットワークアクセス。
storage_mb 設定は強制しません。
サンドボックスの使用料金がどのアカウントに請求されるかと推論の料金を確認してください。ステップ数と時間制限は実行の範囲を制限するものであり、支出の上限ではありません。
レシピをインストールする
recipes リポジトリをクローンし、ロックされた依存関係をインストールします。mini-swe-agent 2.2.6、cwsandbox 1.14.2 のバージョンが固定されています。以降のコマンドは recipes/deepswe ディレクトリで実行してください。
タスクのイメージと検証器のレイアウトをアダプターと一致させるため、テスト済みの DeepSWE リビジョンを取得します。
サンプルモデルと認証情報を設定する
レシピを実行するターミナルで、両方の認証情報を設定します。[API-ACCESS-TOKEN] を CoreWeave API アクセストークンに、[FORGE-API-KEY] を Forge APIキーに置き換えるか、シークレットマネージャーからエクスポートしてください：
FORGE_API_KEY 変数を自動的には認識しないため、推論時に FORGE_API_KEY を読み取るようにローカルコピーを設定してください。
run.py で、parse_args() 内の認証情報チェックを次のコードに置き換えます。
host_agent.py で、HostMiniSweAgent.run() の冒頭にある推論キーの割り当て部分を次のコードに置き換えます。
OPENAI_API_KEY は、この OpenAI 互換エンドポイントで LiteLLM が使用する変数です。これにより、認証情報はシリアライズされたモデルの設定ではなく、プロセスのメモリ内に保持されます。レシピはプロセスの環境変数から値を読み取るため、project の .env ファイルは自動では読み込まれません。
サンドボックスを作成する前に、モデルにアクセスできることを検証します。
OK などの短い応答が返されます。サンプルを開始する前に、認証、モデルへのアクセス、クレジットに関するエラーがあれば解決してください。
サンプルを実行する
インテグレーションの初回確認として、Python タスクを 1 つ実行します。HEAD リファレンスの差分を抽出します。変更を送信するパッチに含めるには、エージェントが変更をコミットする必要があります。コミットされていない編集は収集されません。
新しく run を実行する場合は、新しいジョブ名を使用してください。Pier は既存のジョブディレクトリを再開できるため、kimi-sample というジョブ名を再利用しても、クリーンな状態から再実行されるわけではありません。決定論的なランダムサンプリングやその他のレシピオプションについては、レシピの README を参照してください。
同時実行数と再試行を設定する
Pier はレシピの試行キューを管理します。--concurrency を使用して、同時に実行する試行の最大数を設定します。デフォルトは 1 です。まずこの設定でワークフロー全体を検証してください。その後、推論プロバイダーの利用枠の範囲内で、同時実行数を段階的に増やします。この利用枠には、同じアカウントを使用する他のジョブからのリクエストも含まれます。モデルへのアクセスチェックに成功しても、同時リクエストを処理できるキャパシティがあることの確認にはなりません。
レシピのデフォルトは --max-retries 2 です。RateLimitError、APIConnectionError、または ServiceUnavailableError が発生した場合、Pier は試行を最大 2 回まで再開できます。1 回目の再試行の前には 30 秒、2 回目の前には 60 秒待機します。
再試行のたびにエージェントの新しい試みが開始されるため、追加料金が発生する可能性があります。ステップ数とエージェント時間の制限は、実行ごとに個別に適用されます。また、再試行のたびに新しいサンドボックスが作成されるため、作成されるサンドボックスの総数が同時試行数の上限を超えることがあります。
認証エラー、SandboxFailedError などのサンドボックスの起動失敗、上記以外の例外、および検証器のスコアが低い場合は、自動再試行はトリガーされません。試行の再試行を無効にするには、--max-retries 0 を設定します。
レシピは、Pier が試行ディレクトリを置き換える前に、失敗した試みを jobs/[JOB-NAME]/failed-attempts/[TRIAL-NAME]/[ATTEMPT-ID]/ に保存します。通常の試行ディレクトリとジョブの概要には、最後の実行の結果が格納されます。並列実行用のコマンドについては、レシピの同時実行数と再試行の設定を参照してください。
推論のスロットリングに対処する
rate_limit_exceeded と concurrency limit reached for requests を含む HTTP 429 応答は、推論プロバイダーがモデルリクエストを拒否したことを示します。Forge は project 単位およびユーザー単位で制限を適用します。--concurrency の値を下げ、同じ推論アカウントを使用している他のジョブからの同時モデルリクエストも減らしてください。制限の引き上げが必要な場合は、推論の制限に関するドキュメントの案内に従ってサポートに問い合わせてください。
この例の MSWEA_MODEL_RETRY_STOP_AFTER_ATTEMPT=3 設定では、mini-swe-agent は失敗したモデルクエリごとに、初回を含めて最大 3 回まで試みます。リクエストが成功すれば、これらの再試行では同じ会話がそのまま継続されます。また、モデルクライアントが 1 回の試みの中で再試行を行う場合もあります。対象となる例外によってリクエストの再試行回数を使い切った場合は、Pier が試行の再試行ポリシーを適用します。
Pier 0.3.1 が制限するのは試行全体の数です。このレシピには、推論リクエスト専用の同時実行制限や、同時実行数を自動で調整する機能はありません。再試行回数を増やすだけでは、持続的な過負荷は解消されません。
1 つのジョブの中で、スロットリングされた試行の一部は回復し、残りは再試行を使い切るということもあります。再試行を使い切った試行には最終的な例外が記録され、レシピはゼロ以外のステータスで終了します。これらの試行が何の通知もなくスキップされることはありません。
持続的なスロットリングを解消したら、影響を受けたタスクだけを、同時実行数を下げて新しいジョブ名で再実行してください。再試行が別のエラーで終了した場合は、failed-attempts/ ディレクトリもあわせて確認してください。推論のスロットリングとサンドボックスの起動失敗は、それぞれ切り分けて診断する必要があります。具体的なコマンドや、Pier に組み込まれているエラーでフィルタリングしたジョブ復旧の方法については、レシピのスロットリングからの復旧手順を参照してください。
結果を確認する
以下の例では、2 タスクのジョブを確認します。1 タスクの run を確認する場合は、kimi-sample を kimi-smoke に置き換えてください。まず、ジョブの概要を読み取ります。
stats.n_completed_trials は、エラーになったものも含めて完了した試行の数をカウントします。stats.n_retries がカウントするのは追加で実行された試行の数であり、追加のベンチマークサンプル数ではありません。回復した試行では、最終結果に例外がなくても、アーカイブ済みのエラーが残っている場合があります。
ジョブの集計スコアを解釈する前に、stats.n_errored_trials と、各試行の最終的な exception_info および verifier_result を確認してください。検証の開始に失敗し、パッチが 1 件も採点されなかった場合、集計平均が 0 になることがあります。
検証器の二値報酬が 0 または 1 で、例外が発生していない試行は、ワークフローを完了しています。報酬 1 は、必須チェックにすべて合格したことを意味します。報酬 0 は、パッチが必須チェックの一部を満たさなかったことを意味します。例外、報酬の欠落、または報酬 -1 は run エラーです。run エラーはモデル性能とは切り離して調査してください。
jobs/kimi-sample/ 配下の各試行ディレクトリには、以下のファイルが含まれます。
エージェントが自身のテストに合格したと報告していても、非公開のテストの結果を必ず確認してください。
reward.json では、f2p_passed と f2p_total が新しい動作に対するチェックの数を、p2p_passed と p2p_total が既存のチェックの数をカウントします。必須チェックが 1 つでも失敗すると、partial スコアが高くても二値の reward が 0 になることがあります。
保存済みのトークン数は不完全な場合があります。このアダプターでは、ツール呼び出しがないために拒否された応答は、トークンを消費しても、その使用量が軌跡に記録されないことがあります。これらの数値から算出したコストはあくまで部分的な見積もりとして扱い、実際の料金はプロバイダーの請求で確認してください。事前確認のリクエストとサンドボックスの料金は別途発生します。
エージェントがパッチを送信したものの検証器の起動に失敗した場合は、artifacts/model.patch と元のエラー結果を保持してください。このレシピには、検証器のみを再試行するためのサポートされたコマンドはありません。モデルを新たに run すると新しい試行として扱われ、保存済みパッチの再採点にはなりません。別途再採点を行う場合は、変更していないパッチと、それに対応するタスクリビジョンを使用し、その結果を個別に保持する必要があります。
検証器を単独で確認するには、レシピの no-edit および reference-solution コントロールの手順に従ってください。これらのコントロールはモデルを呼び出さないため、モデルの結果とは分けて扱う必要があります。
クリーンアップ
Pier は、正常完了時およびエラー発生時のクリーンアップ中に、エージェント用と検証用のサンドボックスを停止します。また、各サンドボックスには 90 分の最大ライフタイムが設定されています。パッチ、軌跡、またはテストレポートが必要な場合は、ジョブディレクトリを削除せずに残しておいてください。 クリーンアップが完了する前にローカルの評価プロセスが強制終了された場合は、残っているサンドボックスを停止してください。[SANDBOX-ID] は、run のログに記載されているサンドボックス ID に置き換えてください。
トラブルシューティング
次のステップ
詳細については、次のリソースを参照してください。- 評価の概要: 評価ワークフローを選択し、モデルの推論とベンチマークの実行を分離します。
- DeepSWE レシピ: アダプター、テスト、サンプリングオプションを確認します。
- SWE-bench による評価: 別のベンチマークで既存のパッチを評価します。
- クリーンアップパターン: 独自のアプリケーションでサンドボックスのライフサイクルを管理します。