Skip to main content
소규모 DeepSWE v1.1 샘플로 코딩 에이전트를 평가합니다. CoreWeave Sandboxes는 에이전트가 코드를 편집하고 벤치마크가 패치를 검증하는 환경을 제공합니다. DeepSWE 레시피는 평가 스크립트, 의존성 잠금 파일, 샌드박스 어댑터를 제공합니다. 이 레시피는 로컬 머신에서 mini-swe-agent 코딩 에이전트를 실행하고, 에이전트의 셸 명령어를 서버리스 샌드박스로 전송합니다. 에이전트가 작업을 마치면 평가 프레임워크인 Pier가 커밋된 변경 사항을 수집하고 에이전트 샌드박스를 중지합니다. 이어서 새로 생성된 검증용 샌드박스가 패치를 적용하고 비공개 테스트를 실행합니다. 이 예시에서는 Serverless Inference를 통해 moonshotai/Kimi-K2.7-Code로 모델 요청을 처리합니다. DeepSWE와 샌드박스를 사용하는 데 반드시 이 공급자가 필요한 것은 아닙니다. 제공된 레시피에는 Forge 엔드포인트와 사용자 인증 정보 처리 방식이 고정되어 있으며, --model 옵션으로 해당 엔드포인트의 다른 모델을 선택할 수 있습니다. 다른 공급자를 사용하려면 레시피의 모델 구성과 인증을 수정해야 합니다. 비공개 테스트 파일은 검증용 샌드박스에만 전달됩니다. 레시피는 두 샌드박스를 모두 아웃바운드 네트워크 액세스가 차단된 상태로 생성합니다. 샌드박스 및 추론 사용자 인증 정보는 로컬 머신을 벗어나지 않습니다.
이 가이드는 소규모 샘플로 인테그레이션이 제대로 동작하는지 검증합니다. 호스트 측 에이전트 어댑터와 run 제한은 공식 DeepSWE 리더보드 설정과 다릅니다. 작업 두 개의 결과만으로는 전체 벤치마크의 성능을 추정할 수 없습니다.

사전 요구 사항

시작하기 전에 다음 사전 요구 사항을 갖추었는지 확인하세요.
  • Python 3.12 이상, Git, uv 패키지 관리자
  • 서버리스 샌드박스가 활성화된 조직에서 Sandbox User 역할이 부여된 CoreWeave API 액세스 토큰
  • Serverless Inference의 예시 모델에 액세스할 수 있는 Forge API 키
  • 로컬 머신에서 Sandboxes API 및 https://api.inference.wandb.ai/v1 에 액세스할 수 있는 네트워크 환경
각 작업은 CPU 2개와 메모리 8GiB를 요청합니다. 기본적으로 작업은 순차적으로 실행되며, 에이전트와 검증기는 각각 별도의 샌드박스를 사용합니다. GPU나 로컬 도커 설치는 필요하지 않습니다. 어댑터는 작업의 CPU 및 메모리 설정은 적용하지만 storage_mb 설정은 강제 적용하지 않습니다. 샌드박스 사용 요금이 청구되는 계정과 추론 요금을 확인하세요. step 제한과 시간 제한은 실행 범위를 제한할 뿐, 비용 한도 역할을 하지는 않습니다.

레시피 설치

레시피 저장소를 복제하고 잠금 파일에 고정된 의존성을 설치하세요:
이 레시피는 Pier 0.3.1, mini-swe-agent 2.2.6, cwsandbox 1.14.2 버전으로 고정되어 있습니다. 이후 명령어는 모두 recipes/deepswe 디렉터리에서 실행하세요. 작업 이미지와 검증기 레이아웃이 어댑터와 일치하도록 테스트를 마친 DeepSWE 리비전을 가져오세요.

예시 모델 및 사용자 인증 정보 설정

레시피를 실행할 터미널에서 두 가지 사용자 인증 정보를 모두 설정하세요. [API-ACCESS-TOKEN]은 CoreWeave API 액세스 토큰으로, [FORGE-API-KEY]는 Forge API 키로 바꾸세요. 또는 시크릿 관리자에서 두 값을 내보내세요.
이 레시피는 샌드박스에 CoreWeave 인증을 사용하도록 명시적으로 지정합니다. 업스트림 레시피는 FORGE_API_KEY 변수를 자동으로 인식하지 않으므로, 추론 시 이 변수를 읽도록 로컬 사본을 설정하세요. run.py에서 parse_args()의 사용자 인증 정보 확인 부분을 다음 코드로 바꾸세요.
host_agent.py에서 HostMiniSweAgent.run() 시작 부분에 있는 추론 키 할당 코드를 다음 코드로 바꾸세요.
OPENAI_API_KEY는 LiteLLM이 이 OpenAI 호환 엔드포인트에 사용하는 변수입니다. 이렇게 하면 사용자 인증 정보가 직렬화된 모델 구성이 아닌 프로세스 메모리에 보관됩니다. 레시피는 프로세스 환경에서 변수를 읽으며, 프로젝트의 .env 파일은 자동으로 로드하지 않습니다. 샌드박스를 생성하기 전에 모델 액세스 권한을 확인하세요.
요청이 성공하면 OK와 같은 짧은 응답이 반환됩니다. 샘플을 시작하기 전에 인증, 모델 액세스, 크레딧 관련 오류가 있다면 먼저 해결하세요.

샘플 실행하기

먼저 인테그레이션이 제대로 작동하는지 확인하려면 Python 작업 하나를 실행하세요.
작업이 하나뿐인 run이라도 step 또는 시간 한도의 대부분을 소진할 수 있습니다. 이 run은 인테그레이션을 확인하기 위한 것이므로, 모델이 작업을 해결하지 못해도 run은 성공할 수 있습니다. 샘플을 확장하려면 새 작업 이름으로 Go 작업 하나와 Python 작업 하나를 실행하세요:
레시피는 샌드박스 생성, 완료된 모델 step, 샌드박스 종료를 보고합니다. 각 작업에는 에이전트 step 160개 제한과 30분의 에이전트 timeout이 적용됩니다. 셸 명령어의 timeout은 120초입니다. 명령어 timeout은 관찰 결과로 처리되므로 에이전트는 작업을 계속 진행할 수 있습니다. 작업의 수집 훅은 기본 커밋과 HEAD 레퍼런스 간의 차이를 추출합니다. 변경 사항을 제출된 패치에 포함하려면 에이전트가 해당 변경 사항을 커밋해야 합니다. 커밋되지 않은 편집 내용은 수집되지 않습니다. 새 run을 시작하려면 새 작업 이름을 사용하세요. Pier는 기존 작업 디렉터리를 재개할 수 있으므로, kimi-sample 작업 이름을 재사용하면 처음부터 깨끗하게 다시 실행되지 않습니다. 결정론적 랜덤 샘플링 및 기타 레시피 옵션은 레시피 README를 참조하세요.

동시성 및 재시도 설정

Pier는 레시피의 시도 큐를 관리합니다. --concurrency를 사용하여 동시에 실행할 시도의 최대 개수를 설정하세요. 기본값은 1입니다. 먼저 이 설정으로 전체 워크플로를 확인하세요. 그런 다음 같은 계정을 사용하는 다른 작업의 요청까지 고려하여, 추론 공급자의 기본 제공 사용량 범위 안에서 동시성을 점진적으로 늘리세요. 모델 액세스 확인에 성공했더라도 동시 요청을 처리할 용량까지 검증된 것은 아닙니다. 레시피의 기본값은 --max-retries 2입니다. RateLimitError, APIConnectionError 또는 ServiceUnavailableError가 발생하면 Pier는 시도를 최대 두 번까지 다시 시작할 수 있습니다. 첫 번째 재시도 전에는 30초, 두 번째 재시도 전에는 60초를 대기합니다. 재시도할 때마다 새로운 에이전트 시도가 시작되며 추가 요금이 발생할 수 있습니다. step 제한과 에이전트 시간 제한은 각 실행에 개별적으로 적용됩니다. 재시도할 때마다 새 샌드박스가 생성되므로, 생성되는 샌드박스의 총개수가 동시 시도 제한을 초과할 수 있습니다. 인증 오류, SandboxFailedError와 같은 샌드박스 시작 실패, 위에 나열되지 않은 기타 예외, 낮은 검증기 점수는 자동 재시도를 트리거하지 않습니다. 시도 재시도를 비활성화하려면 --max-retries 0을 설정하세요. 레시피는 Pier가 시도 디렉터리를 교체하기 전에 실패한 시도를 jobs/[JOB-NAME]/failed-attempts/[TRIAL-NAME]/[ATTEMPT-ID]/ 아래에 보존합니다. 일반 시도 디렉터리와 작업 summary에는 최종 실행 결과가 담깁니다. 병렬 실행 명령어는 레시피의 동시성 및 재시도 설정을 참조하세요.

추론 스로틀링 처리

rate_limit_exceeded 및 concurrency limit reached for requests가 포함된 HTTP 429 응답은 추론 공급자가 모델 요청을 거부했다는 의미입니다. Forge는 프로젝트별, 사용자별로 제한을 적용합니다. --concurrency 값을 낮추고, 같은 추론 계정을 사용하는 다른 작업의 동시 모델 요청도 줄이세요. 제한을 높여야 하는 경우 추론 제한 문서를 참고해 지원팀에 문의하세요. 예시처럼 MSWEA_MODEL_RETRY_STOP_AFTER_ATTEMPT=3으로 설정하면 mini-swe-agent는 실패한 모델 쿼리마다 최초 시도를 포함해 최대 세 번까지 시도합니다. 요청이 성공하면 재시도는 기존 대화를 그대로 이어갑니다. 모델 클라이언트도 한 번의 시도 안에서 자체적으로 재시도할 수 있습니다. 재시도 대상 예외로 요청 재시도가 모두 소진되면 Pier가 시도 재시도 정책을 적용합니다. Pier 0.3.1은 시도 전체를 단위로 제한을 적용합니다. 이 레시피에는 추론 요청에 대한 별도의 동시 실행 제한이나 동시성 자동 조정 기능이 없습니다. 따라서 재시도 횟수만 늘려서는 지속적인 과부하를 해결할 수 없습니다. 하나의 작업 안에서도 스로틀링된 시도 중 일부는 복구되고 나머지는 재시도를 모두 소진할 수 있습니다. 이런 시도에는 최종 예외가 그대로 남고, 레시피는 0이 아닌 상태로 종료됩니다. 해당 시도가 별도 알림 없이 건너뛰어지는 일은 없습니다. 지속적인 스로틀링 문제를 해결한 후에는 영향을 받은 작업만 동시성을 낮추고 새 작업 이름을 지정해 다시 실행하세요. 재시도가 다른 오류로 끝났다면 failed-attempts/ 디렉터리도 확인하세요. 추론 스로틀링과 샌드박스 시작 실패는 각각 따로 진단해야 합니다. 관련 명령어와 Pier의 기본 제공 오류 필터 기반 작업 복구 방법은 레시피의 스로틀링 복구 절차를 참고하세요.

결과 확인

다음 예시에서는 작업 두 개로 구성된 작업을 확인합니다. 작업이 하나인 run의 경우 kimi-sample을 kimi-smoke로 바꾸세요. 작업 summary를 조회합니다.
stats.n_completed_trials는 오류가 발생한 시도를 포함해 완료된 시도 수를 집계합니다. stats.n_retries는 추가 벤치마크 샘플 수가 아니라 시도가 추가로 실행된 횟수를 집계합니다. 복구된 시도는 최종 결과에 예외가 없더라도 아카이브된 오류가 남아 있을 수 있습니다. 작업의 집계 점수를 해석하기 전에 stats.n_errored_trials와 각 시도의 최종 exception_info 및 verifier_result를 확인하세요. 검증이 시작되지 못해 채점된 패치가 하나도 없으면 집계 평균이 0이 될 수 있습니다. 검증기의 이진 보상이 0 또는 1이고 예외가 없는 시도는 워크플로를 끝까지 완료한 것입니다. 보상 1은 모든 필수 검사를 통과했다는 뜻입니다. 보상 0은 패치가 필수 검사를 모두 충족하지 못했다는 뜻입니다. 예외가 발생했거나, 보상이 없거나, 보상이 -1이면 run 오류입니다. run 오류는 모델 성능과 별개로 조사하세요. jobs/kimi-sample/ 아래의 각 시도 디렉터리에는 다음 파일이 있습니다. 에이전트가 자체 테스트를 통과했다고 보고하더라도 비공개 테스트 결과를 반드시 확인하세요. reward.json에서 f2p_passed와 f2p_total은 새 동작에 대한 검사 수를, p2p_passed와 p2p_total은 기존 검사 수를 나타냅니다. 필수 검사 중 하나라도 실패하면 partial 점수가 높더라도 이진 reward는 0일 수 있습니다. 저장된 토큰 수는 불완전할 수 있습니다. 이 어댑터에서는 도구 호출이 없어 거부된 응답이 토큰을 소비하고도 그 사용량이 트래젝터리에 기록되지 않을 수 있습니다. 따라서 이 수치로 계산한 비용은 부분 추정치로 보고, 실제 요금은 공급자의 결제 내역에서 확인하세요. 사전 점검 요청과 샌드박스 요금은 별도로 청구됩니다. 에이전트가 패치를 제출했지만 검증기 시작에 실패했다면 artifacts/model.patch와 원본 오류 결과를 보존하세요. 이 레시피는 검증기만 재시도하는 명령어를 지원하지 않습니다. 모델 run을 새로 실행하면 저장된 패치를 다시 채점하는 것이 아니라 새로운 시도가 생성됩니다. 별도로 재채점하려면 변경되지 않은 패치와 일치하는 작업 리비전을 사용하고, 재채점 결과는 따로 보관해야 합니다. 검증기를 독립적으로 확인하려면 레시피의 무편집 및 참조 솔루션 대조군을 따르세요. 대조군은 모델을 호출하지 않으므로 모델 결과와 섞이지 않도록 분리해서 관리해야 합니다.

정리

Pier는 작업이 정상적으로 완료되거나 오류로 인해 정리 작업이 진행될 때 에이전트 샌드박스와 검증기 샌드박스를 중지합니다. 또한 각 샌드박스의 최대 수명은 90분입니다. 패치, 궤적 또는 테스트 보고서가 필요하다면 작업 디렉터리를 삭제하지 말고 보관하세요. 정리 작업이 끝나기 전에 로컬 평가 프로세스가 종료되었다면 남아 있는 샌드박스를 직접 중지하세요. [SANDBOX-ID]를 run 로그에 표시된 샌드박스 ID로 바꾸세요.
이 레시피는 GPU 배포, 모델 엔드포인트, 퍼시스턴트 볼륨을 생성하지 않습니다.

문제 해결

다음 단계

자세한 내용은 다음 리소스를 참조하세요.
  • 평가 개요: 평가 워크플로를 선택하고 모델 추론과 벤치마크 실행을 분리하세요.
  • DeepSWE 레시피: 어댑터, 테스트, 샘플링 옵션을 검토하세요.
  • SWE-bench 평가: 다른 벤치마크에서 기존 패치를 평가하세요.
  • 정리 패턴: 직접 개발한 애플리케이션에서 샌드박스 라이프사이클을 관리하세요.
마지막 수정일 2026년 10월 15일