한눈에
- 하이어스턴트 에이전트적 RL: 마이크로소프트 리서치 아시아는 배포에서 사용되는 동일한 에이전트 하이어스를 강화 학습에 직접 참여시키는 훈련 패러다임을 도입하여, 훈련 프레임워크 내에서 에이전트를 다시 구현할 필요를 제거했습니다.
- 설계상 경량화된 제품: Agent Lightning v1.0은 약 3,500줄의 코드로 완전한 에이전트 RL 제어 플레인을 제공합니다.
- 네이티브 Kubernetes 지원: 에이전트는 자체 관리 클러스터, 클라우드 Kubernetes 또는 로컬 인프라에서 표준 Kubernetes 작업으로 실행되며, 유료 상업용 샌드박스 서비스에 대한 의존성이 없습니다.
- 데이터 효율적인 훈련 방법: 종단간 코딩 에이전트 파이프라인을 통해 Qwen3.5-9B를 SWE-bench Verified에서 Pass@1 점수가 41.8%에서 56.4%로 증가시켰으며, 오픈 소스 데이터셋을 기반으로 약 6,000개의 훈련 샘플만을 사용하여 14.6%의 점수 향상을 이루었습니다.
AI 에이전트는 단일 모델에서 모델, 도구, 실행 환경으로 구성된 복잡한 전체 스택 시스템으로 발전했습니다. 그 능력은 모델 외부에서 그들을 조정하는 에이전트 하브스에 점점 더 의존하게 되었습니다. 강화 학습(RL)은 AI 시스템이 시행착오를 통해 배우고, 행동에 대한 보상과 처벌에 의해 지시받는 방법입니다. RL은 그러한 에이전트를 더 나은 상태로 만들 수 있지만, 대부분의 에이전트 RL 시스템에서는 개발자가 훈련 프레임워크 내에서 에이전트를 다시 구현해야 합니다. 이는 비용이 많이 들며, 훈련된 에이전트가 실제 배포되는 에이전트와 완전히 같지 않다는 것을 의미합니다.
이 문제를 해결하기 위해 마이크로소프트 리서치 아시아의 연구원들은 Harnessed Agentic RL 훈련 패러다임을 도입했으며, Agent Lightning v1.0 (새 탭에서 열림)를 완전히 재구축하여 오픈소스로 공개했습니다. 원래 버전의 Agent Lightning v1.0과 비교해, 이번 버전은 경량화에 더 많은 중점을 두고 실제 하네스를 통합하며, 완전하고 재현 가능한 에이전트 RL 훈련 파이프라인을 구축하는 데 중점을 둡니다.
Agent Lightning v1.0은 Harnessed Agentic RL을 기반으로 재구축되었으며, 주요 개선 사항이 있었습니다:
- 경량화된 구조: 전체 프레임워크는 약 3,500줄의 코드로 구성됩니다. Agent Lightning v1.0은 이해하고 수정하며 확장할 수 있을 만큼 작고 명확한 코드베이스 안에 완전한 Harnessed Agentic RL 시스템을 구현하고 있습니다.
- 실제 에이전트 하네스에서의 훈련: 에이전트는 Agent Lightning v1.0의 대규모 언어 모델(LLM) 프록시를 통해 모델에 도달하며, 기존 하네스 코드는 변경되지 않습니다.
- 네이티브 Kubernetes 지원: 에이전트는 외부 상업적 샌드박스 서비스 없이 직접 Kubernetes 작업으로 실행됩니다. 자체 관리된 클러스터와 로컬 인프라 모두에서 대규모로 배포를 지원할 수 있습니다.
- 완전한 코딩 에이전트 훈련 예시: Qwen3.5-9B를 기반으로 구축된 엔드투엔드 파이프라인은 SWE-bench Verified에서 Pass@1 점수를 41.8%에서 56.4%로 향상시켰으며, 6,000개의 훈련 샘플만을 사용하여 14.6퍼센트 포인트의 절대적인 향상을 이루었습니다.
전통적인 에이전트 기반 RL의 한계
전통적인 에이전트 기반 RL은 환경과의 상호작용 루프를 트레이닝 프레임워크가 담당한다고 가정합니다. ReAct 스타일의 루프에서는 모델이 행동을 생성하고, 환경이 관찰값을 반환하며, 그 관찰값은 컨텍스트에 추가되고, 모델이 다음 행동을 생성하여 전체 로우오프가 하나의 연속적인 토큰 궤적으로 이어집니다. verl, AReaL, slime과 같은 초기 RL 시스템도 이러한 방식으로 구축되었으며, 이는 에이전트를 트레이닝하기 위해 RL 프레임워크 내에서 루프를 다시 구축해야 한다는 의미였습니다.
실제 하네스는 그런 가정에 더 이상 적합하지 않습니다. mini-SWE-agent, OpenHands, OpenCode, Claude Code, Codex와 같은 코딩 에이전트들은 각자 고유한 컨텍스트 관리, 도구 프로토콜, 실행 로직, 의존성을 가지고 있으며, 일반적인 에이전트 시스템도 마찬가지입니다. 훈련을 위해 새로운 에이전트를 재구축하는 것은 비용이 많이 들며, 재구축된 에이전트는 배포된 에이전트와 같은 방식으로 작동하지 않을 수 있습니다.
라이트닝 에이전트는 다른 경로를 선택합니다. 에이전트와 모델 사이에 LLM 프록시를 배치합니다. 에이전트는 이전과 같이 계속 작동합니다: 이전에 모델 API를 호출했던 엔드포인트를 라이트닝 에이전트로 지정하기만 하면, 트레이닝 프레임워크는 그 모델 호출을 관찰하고 기록할 수 있습니다. v1.0에서는 연구자들이 이 패러다임을 공식적으로 '하네스드 에이전트적 RL'으로 정의합니다. 배포 시 사용되는 어떤 에이전트가든, 훈련 과정에서 강화 학습에 직접 참여하는 하네스드가 됩니다(그림 1).
실제 호스로 훈련하는 데 있어 네 가지 어려움
하네스드 에이전트릭 RL과 전통적인 에이전트릭 RL의 핵심 차이점은 환경 상호작용 루프가 훈련 프레임워크이 아닌 하네스가 처리한다는 점입니다. 훈련 시스템은 단일 LLM 요청 및 응답 쌍의 시퀀스만을 관찰할 수 있기 때문에, 하나의 롤아웃이 다양한 수의 훈련 샘플로 나뉠 수 있습니다. 이로 인해 네 가지 주요 문제가 발생합니다:
- 재토큰화 및 샘플 병합: 하니스는 컨텍스트를 텍스트 형태로 유지하지만, RL 훈련에는 롤아웃 과정에서 샘플링된 토큰 ID가 필요합니다. 텍스트를 채팅 템플릿과 토큰화기로 다시 통과시키면 토큰 경계가 변동될 수 있어, 인접한 요청들을 항상 하나의 샘플로 병합하기는 어렵습니다.
- 장점 계산: 재토큰화, 서브 에이전트 및 컨텍스트 요약은 하나의 출시를 여러 샘플로 나눌 수 있습니다. 샘플 수준에서 바로 기준값과 장점을 계산하면 더 많은 샘플을 생성하는 출시가 반복적으로 계산되게 되고, 이로 인해 출시 수준의 원래 통계적 관계가 변경됩니다.
- 손실 정규화: 샘플 수를 기준으로 손실을 평균화하면 더 많은 샘플을 생성하는 출시가 더 큰 가중치를 받게 됩니다. 샘플 수는 종종 하네스의 동작의 결과일 뿐이므로, 손실 정규화는 그에 의해 왜곡되지 않도록 해야 합니다.
- 백엔드 일정 설정 훈련: 샘플 수와 길이는 하네스가 완료된 후에만 알 수 있으며, GPU 수와 데이터/텐서 병렬 구성은 일반적으로 고정되어 있습니다. 백엔드는 변동적인 작업량을 고정된 리소스으로 매핑해야 합니다.
스포트라이트: 마이크로소프트 연구 뉴스레터
마이크로소프트 리서치 뉴스레터
오늘 바로 구독하기3,500줄의 코드로 완전한 에이전트 RL 제어 플레인을 구축하기
시스템 설계에서 Agent Lightning v1.0은 단순성을 첫 번째 원칙으로 삼습니다. 전체 프레임워크는 약 3,500줄의 코드로 구성되며, 세 가지 핵심 구성 요소가 있습니다: API 게이트웨이, Rollout 컨트롤러, 그리고 맞춤형 트레이너(그림 2).
API 게이트웨이는 롤아웃, 모델, 이벤트를 저장하며 OpenAI와 호환되는 LLM 프록시 역할을 합니다. 이는 하네스에서의 모든 모델 호출을 롤아웃과 연결하고, 훈련에 필요한 프롬프트, 응답, 로그 확률을 기록합니다. 롤아웃 컨트롤러는 에이전트 실행을 시작하고 관리하며, 이를 로컬 프로세스나 표준 Kubernetes 작업으로 수행하여 훈련자와 에이전트 실행을 분리합니다. 사용자 맞춤형 트레이너는 verl을 기반으로 구축되며, 롤아웃을 생성하고 그 작업이 완료될 때까지 기다린 후 샘플을 수집하고, 샘플 어댑터를 통해 최종 훈련 샘플을 조합합니다. 그 결과, 기존 에이전트 하네스의 경우 모델 엔드포인트를 Agent Lightning 프록시에 연결하면 일반적으로 RL 훈련에 빠르게 연결될 수 있습니다.
콜로킹된 비동기 RL
배포 시간은 에이전트마다 크게 다릅니다. 동기식 RL은 배치 중 가장 느린 에이전트를 기다리며 GPU를 비워둡니다. 반면, 완전히 비동기식 RL은 활용률을 높이지만 배포와 훈련을 위해 별도의 GPU 풀이 필요합니다. 이에 대응하여 Agent Lightning v1.0은 Collocated Async RL을 도입했으며, 이를 통해 배포와 모델 업데이트가 동일한 GPU 세트를 공유할 수 있습니다.
시스템이 충분한 롤오프 데이터를 수집하면 업데이트가 시작됩니다: API 게이트웨이는 새로운 요청을 받는 것을 중단하고, 이미 진행 중인 요청이 완료될 때까지 기다리며, 업데이트가 완료된 후에 롤오프가 재개됩니다. 전체 상태 전환은 외부 에이전트 하우스로는 투명하게 표시됩니다. 실험 결과, 이 접근 방식은 동기식 RL보다 약 2배의 엔드투엔드 속도 향상을 가져왔으며, 기존 비동기식 RL보다 적은 수의 GPU를 사용했습니다(그림 3).
Kubernetes에서 에이전트를 실행하기
충분한 수의 에이전트를 실행하기 위해서는 여러 에이전트를 동시에 운영해야 하며, 이는 상당한 CPU, 메모리 및 컴퓨팅 리소스를 소비합니다. 다른 Harnessed Agentic RL 프레임워크들은 Modal Sandbox나 E2B와 같은 상업적 샌드박스 서비스에 그러한 에이전트를 호스팅하는 경우가 많으며, 규모가 커질수록 비용이 빠르게 증가합니다. 반면 Agent Lightning v1.0은 기존의 자체 관리 클러스터, 클라우드 Kubernetes 또는 로컬 인프라를 표준 Kubernetes 작업으로 실행하여 에이전트들을 운영합니다(그림 4). 기존 컴퓨팅 리소스가 더 효율적으로 사용되며, 대규모 배포 비용이 낮아지고, 전체 파이프라인은 오픈 소스이며 재생산 가능합니다.
6,000개의 훈련 샘플, 14.6포인트의 성능 향상
테스트를 위해 연구자들은 SWE-smith, mini-SWE-agent, Qwen3.5-9B를 사용하여 전체 파이프라인을 구축했으며, 데이터 정제, 환경 구축, 보상 해킹 보호 장치, RL 훈련 등을 포함했다. 훈련 세트는 약 6,000개의 샘플을 포함하며 대규모 컴퓨팅이 필요하지 않았다. RL 훈련만으로도 Qwen3.5-9B는 SWE-bench Verified에서 41.8%에서 56.4%로 증가했으며, 14.6퍼센트 포인트의 향상을 이루었다.
코딩 에이전트의 추가 실험은 두 가지 과제에 대한 이전 분석을 확인해줍니다: 이점 계산과 손실 정규화입니다. 샘플 수준 처리에 비해, 배포 수준 이점과 배포 수준 정규화를 결합하면 더 높은 검증 보상을 얻고, 훈련 중 정책 엔트로피가 더 안정적으로 유지됩니다(그림 5).
Agent Lightning v1.0: 실제 하네스를 사용한 에이전트 훈련을 위한 3,500줄의 경량 에이전트적 RL 프레임워크는 Microsoft Research에서 처음에 게시되었습니다.