SWE-bench

CoreWeave のサンドボックスを使用して、SWE-bench の評価を並列実行します。このガイドは、言語モデルによるコード修正のパフォーマンスを大規模に評価したい機械学習の実務者や研究者を対象としています。読み終える頃には、CoreWeave の多数のサンドボックスで SWE-bench の評価を同時に実行し、分析用の結果をローカルに書き出せる環境が整います。

この機能

SWE-bench は、言語モデルが実際のリポジトリ内の実際のバグを修正できるかどうかをテストします。各タスクはパッチを適用し、テストスイートを実行して、修正が機能するかどうかを確認します。 Docker を使用してローカルで SWE-bench を実行できますが、マシンのリソースによって制限されます。CoreWeave のサンドボックスを使用すると、CoreWeave インフラストラクチャー上で大規模に評価を実行できます。自分で管理することなく、数十または数百のサンドボックスを同時に起動できます。各サンドボックスは、GitHub Container Registry (GHCR) 上の Epoch AI のレジストリにあるビルド済みのイメージから起動します。イメージをプルするのはお使いのマシンではなくサンドボックスプラットフォームなので、Docker もローカルでのビルド手順も必要ありません。

セットアップ

評価を実行する前に、次の手順に従って必要なツールをインストールし、認証を設定します。

Python 仮想環境を準備し、SDK と評価用の依存関係をインストールします。
uv pip install cwsandbox swebench datasets
サンプルの評価スクリプトを含むリポジトリをクローンします。
git clone https://github.com/coreweave/cwsandbox-client.git cd cwsandbox-client

評価用サンドボックスを所有するアカウントの認証情報を選択します。各認証情報の取得方法については、認証情報の選択と取得を参照してください。

Forge API キー
CoreWeave API アクセストークン

W&B インテグレーションをインストールし、Forge APIキーをエクスポートします。

uv pip install 'cwsandbox[wandb]>=1.14.2'
export WANDB_API_KEY="[WANDB-API-KEY]"

examples/swebench/run_evaluation.py で、cwsandbox からのインポートに AuthStrategy を追加し、既存の SandboxDefaults(...) 呼び出しに auth=AuthStrategy.WANDB を追加します。これにより、CWSANDBOX_API_KEY も設定されている場合でも、評価セッション内のすべてのサンドボックスで W&B 認証が使用されます。

CoreWeave トークンをエクスポートします。

export CWSANDBOX_API_KEY="[API-ACCESS-TOKEN]"

評価スクリプトはデフォルトで CoreWeave 認証を使用します。これを明示的に指定するには、examples/swebench/run_evaluation.py で cwsandbox からのインポートに AuthStrategy を追加し、既存の SandboxDefaults(...) 呼び出しに auth=AuthStrategy.COREWEAVE_API_KEY を追加します。

どちらの方法でも、デフォルトではサーバーレスキャパシティが使用されます。独自の CKS キャパシティで実行するには、CoreWeave トークンを選択してランナーを有効化し、同じ SandboxDefaults(...) 呼び出しに placement_mode="cks" を追加します。

クイックスタート

規模を拡大する前に、単一インスタンスの run から始めて、環境と認証情報が正常に機能すること、およびサンドボックスが GHCR のイメージから起動できることを確認してください。gold オプションは、データセット内の正しいことが確認済みの修正を使用します。

uv run python examples/swebench/run_evaluation.py \
    --predictions-path gold \
    --instance-ids astropy__astropy-12907 \
    --run-id test

この run は成功します。これにより、サンドボックスがそのイメージから起動し、パッチを適用して、テストスイートをエンドツーエンドで実行できることを確認できます。

並列で実行

複数のインスタンスを同時に実行します。

uv run python examples/swebench/run_evaluation.py \
    --predictions-path gold \
    --instance-ids \
        astropy__astropy-12907 \
        django__django-11039 \
        django__django-11099 \
        django__django-11283 \
        matplotlib__matplotlib-23476 \
        scikit-learn__scikit-learn-13142 \
        sympy__sympy-13031 \
        sympy__sympy-13647 \
    --run-id parallel-test \
    --max-workers 8

このコマンドは 8 個のサンドボックスを起動し、それらを並列で実行します。すべてがパスするのは、gold パッチが正しい修正であるためです。

モデルの予測を評価する

カスタムモデル出力をテストするには:

uv run python examples/swebench/run_evaluation.py \
    --predictions-path predictions.json \
    --instance-ids django__django-11039 scikit-learn__scikit-learn-13142 \
    --run-id eval-run-1 \
    --max-workers 10

予測ファイルはインスタンス ID をパッチに対応付けます。

[
  {
    "instance_id": "django__django-11039",
    "model_name_or_path": "gpt-4",
    "model_patch": "diff --git a/..."
  }
]

オプション

オプション	デフォルト	説明
`--predictions-path`	必須	予測 JSON へのパス、または gold パッチの場合は `gold`
`--instance-ids`	必須	スペース区切りのインスタンス ID
`--run-id`	必須	この run の識別子
`--max-workers`	10	最大並列サンドボックス数
`--timeout`	1800	インスタンスごとのタイムアウト (秒単位、30 分)
`--output-dir`	`logs/swebench`	ログと report を書き込む場所
`--dataset`	`princeton-nlp/SWE-bench_Lite`	Hugging Face データセット名
`--force`	false	report.json が存在する場合でもインスタンスを再実行する

リソースを調整する

デフォルトはサンドボックスあたり CPU 2 個と 4Gi のメモリです。run_evaluation.py でこれを変更します：

defaults = SandboxDefaults(
    tags=(f"swebench-{run_id}",),
    resources={"cpu": "4", "memory": "8Gi"},
)

仕組み

このセクションでは、スクリプトの背後にある仕組みを説明します。これにより、ご自身の評価ワークフローに適応させることができます。

コンテナーイメージ

Epoch AI は、ビルド済みのイメージを GHCR でホストしています。インスタンスごとに専用のイメージが用意されており、リポジトリは該当するコミットでチェックアウト済み、依存関係もインストール済みで、テスト環境もすぐに使える状態になっています。イメージ名の形式は次のとおりです: ghcr.io/epoch-research/swe-bench.eval.{arch}.{instance_id.lower()}:latest スクリプトは、インスタンス ID を小文字に変換してイメージ名に使用します。arch はテスト仕様の arch 属性から取得します。この属性がない場合、スクリプトは x86_64 を使用します。サンドボックスプラットフォームは、サンドボックスの起動時に各イメージを GHCR からプルします。独自の CKS キャパシティを使用する場合は、クラスターのノードがプルを実行します。お使いのマシンから ghcr.io にアクセスする必要はなく、ローカルでビルドする必要もありません。

評価フロー

各インスタンスは次のステップで処理されます。

ステップ	場所	処理内容
1. データセットを読み込む	ローカル	Hugging Face からインスタンスのメタデータを取得
2. サンドボックスを作成	サンドボックス	インスタンスのイメージでサンドボックスを起動
3. パッチを書き込む	サンドボックス	パッチを `/tmp/patch.diff` に書き込み
4. パッチを適用	サンドボックス	`git apply` を実行 (必要に応じて `patch` にフォールバック)
5. テストを実行	サンドボックス	`/root/eval.sh` を実行
6. 結果を採点	ローカル	`swebench.harness.grading` で出力を解析
7. report を書き出す	ローカル	結果を `logs/swebench/` に保存
8. クリーンアップ	サンドボックス	サンドボックスを停止

ステップ 2～5 と 8 はリモートで実行され、ステップ 1、6、7 はローカルマシン上で実行されます。

並列実行

このスクリプトは ThreadPoolExecutor を使用してインスタンスのワークフローを並行して実行します。各スレッドが 1 つのインスタンスを担当し、そのワークフローを進めます。あるインスタンスがテストを実行している間に、別のインスタンスはパッチの適用、さらに別のインスタンスはローカルでの採点や起動を進められます。このように処理を同時に進めることで、高速化を実現します。結果は、ワークフローが完了するたびに as_completed() を通じて返されます。

クリーンアップ

スクリプトはサンドボックス Session を使用してサンドボックスをトラッキングします。セッションが終了すると (正常終了、例外、または Ctrl+C の場合)、セッションはすべてのサンドボックスをクリーンアップします。

with cwsandbox.Session(defaults=defaults) as session:
    with ThreadPoolExecutor(max_workers=max_workers) as executor:
        # セッションの終了時に、ここで作成されたサンドボックスはクリーンアップされます

出力

結果は {output-dir}/{run-id}/{model-name}/{instance-id}/ に保存されます：

ファイル	内容
`report.json`	解決済みステータス、サンドボックス ID、期間、およびエラーが発生したインスタンスの場合はそのエラー
`test_output.txt`	完全なテスト出力
`patch.diff`	適用されたパッチ

report の形式

{
  "instance_id": {
    "resolved": true,
    "tests_status": {
      "PASSED": ["test_foo", "test_bar"],
      "FAILED": []
    }
  },
  "sandbox_id": "sandbox-abc123",
  "duration_seconds": 45.2
}

インスタンスでエラーが発生した場合 (たとえば、サンドボックスの起動に失敗した場合)、report.json には "errored": true と error_message 文字列も含まれます。この場合、テスト結果と sandbox_id は省略されることがあります。この形式は、標準的な SWE-bench ツールと互換性があります。

トラブルシューティング

パッチの適用に失敗する

APPLY_PATCH_FAIL がログに表示される場合、パッチが不正な形式であるか、誤ったコミットを対象としているか、空白の問題がある可能性があります。ローカルで git apply --check を実行して問題を確認してください。インスタンス ID が予測と一致していることを確認してください。

テストのタイムアウト

テストスイートによっては、30分以上かかる場合があります。モデルが生成したコードに無限ループが含まれる可能性もあります。必要に応じて --timeout を増やすか、テスト出力を確認してどこで停止しているかを確認してください。

イメージプルエラー

サンドボックスプラットフォームがインスタンスのイメージをプルできない場合、そのサンドボックスは起動に失敗します。スクリプトは [astropy__astropy-12907] Error: ... のようにインスタンス ID とともにエラーをログし、そのインスタンスの report.json の error_message フィールドにも記録します。プルはお使いのマシンではなく CoreWeave のインフラストラクチャー上で実行されるため、ローカル環境から ghcr.io へのネットワークアクセスが原因になることはありません。エラーメッセージを確認したうえで、以下の考えられる原因を調べてください。

イメージが見つからない: Epoch AI がそのインスタンス ID のイメージをパブリッシュしているかを検証してください。--dataset で指定したデータセットに含まれていないインスタンス ID は、サンドボックスまで到達しません。この場合、スクリプトは Instance IDs not found in dataset をログし、そのインスタンスをスキップします。
独自の CKS キャパシティ: placement_mode="cks" を設定している場合、イメージをプルするのはクラスターのノードです。そのため、ノードには ghcr.io へのアウトバウンドアクセスが必要です。また、ランナーのサンドボックスポリシーで ghcr.io/epoch-research のイメージを許可しておく必要もあります。

サンドボックス

サンドボックスを使用する

サンドボックスの管理

リファレンス

この機能

セットアップ

クイックスタート

並列で実行

モデルの予測を評価する

オプション

リソースを調整する

仕組み

コンテナーイメージ

評価フロー

並列実行

クリーンアップ

出力

report の形式

トラブルシューティング

パッチの適用に失敗する

テストのタイムアウト

イメージプルエラー

関連項目

​この機能

​セットアップ

​クイックスタート

​並列で実行

​モデルの予測を評価する

​オプション

​リソースを調整する

​仕組み

​コンテナーイメージ

​評価フロー

​並列実行

​クリーンアップ

​出力

​report の形式

​トラブルシューティング

​パッチの適用に失敗する

​テストのタイムアウト

​イメージプルエラー

​関連項目

この機能

セットアップ

クイックスタート

並列で実行

モデルの予測を評価する

オプション

リソースを調整する

仕組み

コンテナーイメージ

評価フロー

並列実行

クリーンアップ

出力

report の形式

トラブルシューティング

パッチの適用に失敗する

テストのタイムアウト

イメージプルエラー

関連項目