Amazon EKS MoE 강화학습, 처리량 40% 향상…다만 벤치마크에는 한계
Amazon은 자사 엔지니어들이 Elastic Fabric Adapter 위에서 DeepEP를 활성화한 뒤 Amazon EKS MoE 강화학습의 총 롤아웃 처리량이 40% 증가했다고 밝혔다. 테스트에는 P5en 인스턴스 48대가 사용됐으며, 이 가운데 16대는 정책 학습에, 32대는 추론 롤아웃 생성에 배정됐다. 이는 대규모 모델 포스트 트레이닝에서 비용 부담이 큰 단계에 대한 상당한 성과다.
핵심 변화는 단순히 더 빠른 GPU 구성 하나를 추가한 것이 아니다. Amazon은 DeepEP의 전문가 간 통신 경로를 libfabric을 사용하도록 조정해 DeepEP v2에 AWS 네트워킹의 네이티브 지원을 제공했다. 이 통합은 Mixture-of-Experts 모델이 서로 다른 GPU의 전문가들 사이로 토큰을 라우팅할 때 발생하는 불규칙한 트래픽 패턴을 겨냥한다.
다만 이 결과는 신중하게 해석할 필요가 있다. AWS가 공개한 것은 하나의 초희소 MoE 워크로드에서의 상대적 처리량 향상이지, 모든 모델·클러스터·강화학습 프레임워크에 적용되는 보편적 벤치마크는 아니다. 독립적인 시스템 연구들은 서로 다른 GPU 및 네트워크 아키텍처를 넘나드는 전문가 병렬 통신의 어려움을 문서화해 왔다.
Amazon이 MoE 강화학습 스택에서 바꾼 점
Amazon이 보고한 성과는 측정 대상 클러스터에 더 많은 장비를 추가한 결과가 아니라, 라우팅된 토큰이 전문가 사이를 이동하는 방식을 바꾼 데서 나왔다.
AWS 아키텍처는 강화학습 작업을 여러 워커 그룹으로 나눈다. GPU 노드는 정책 학습, 보상 모델 추론, 롤아웃 생성을 담당한다. CPU 노드는 환경과 전처리를 실행하고, 메모리 최적화 노드는 경험 버퍼와 체크포인트 캐시를 보관한다.
Amazon EKS는 오케스트레이션 계층 역할을 한다. 컨테이너를 배치하고, 분리된 노드 그룹을 관리하며, 장애를 조정하고, 운영자가 워크로드의 각 부분을 독립적으로 확장할 수 있게 한다. Amazon S3는 지연 시간에 민감한 실행 경로 밖에서 데이터세트, 체크포인트, 최종 가중치 및 기타 영구 아티팩트를 저장한다.
이러한 분리는 강화학습이 단일하고 균일한 연산이 아니기 때문에 중요하다. 롤아웃 생성 중 추론 워커는 현재 정책을 사용해 환경과 상호작용하고 후보 응답 또는 궤적을 생성한다. 보상 시스템은 이 샘플들을 평가하며, 정책 학습 워커는 그 결과로 얻은 경험을 소비한다.
업데이트된 가중치는 이후 롤아웃 플릿으로 돌아가 다음 정책 반복을 시작한다. 이 루프는 선호도 신호를 활용해 모델을 개선하는 인간 피드백 기반 강화학습(Reinforcement Learning from Human Feedback), 즉 RLHF에서 나타난다. 또한 그룹 내 다른 샘플과 비교해 출력을 평가하는 그룹 상대 정책 최적화(Group Relative Policy Optimization), 즉 GRPO에서도 나타난다.
각 단계는 인프라에 서로 다른 부담을 준다. 롤아웃 생성은 분산 추론과 유사하며, 종종 독립적인 워커들에 작업을 나눌 수 있다. 정책 학습은 참여 GPU가 다음 단계로 진행하기 전 조정된 작업을 완료해야 하므로 더 긴밀한 동기화가 필요하다.
이에 따라 해당 아키텍처는 보고된 테스트에서 추론 인스턴스 32대와 학습 인스턴스 16대를 분리한다. Amazon은 이 48대의 P5en 시스템 전반에서 EFA 위의 DeepEP가 DeepEP를 사용하지 않은 구성 대비 총 롤아웃 처리량을 40% 끌어올렸다고 밝혔다.
P5en 인스턴스는 NVIDIA H200 GPU와 고대역폭 AWS 네트워킹을 사용한다. 인스턴스 48대를 완전히 구성한 배포는 수백 개의 가속기를 의미하지만, AWS는 더 큰 아키텍처가 약 1,000개의 가속기까지 확장될 수 있다고 설명한다. 공개된 비율은 가능한 모든 클러스터 규모가 아닌 48인스턴스 비교를 설명한다.
모델 자체는 초희소 MoE 모델로만 소개됐다. Mixture-of-Experts 모델은 여러 특화 피드포워드 블록을 포함하지만, 각 토큰에 대해서는 그중 일부만 활성화한다. 희소성은 토큰당 연산량을 줄이지만, 전문가가 서로 다른 GPU에 존재할 때 까다로운 라우팅 문제를 만든다.
모든 랭크가 비슷한 크기의 예측 가능한 블록을 교환할 때 표준 집합 연산은 잘 작동한다. MoE 라우팅은 다르다. 토큰은 동적으로 전문가를 선택하므로 트래픽은 희소하고 불균등하며, 많은 소규모 전송으로 구성될 수 있다.
이 차이는 인프라가 중요한 이유를 설명한다. 이론적인 모델 용량 증대가 자동으로 초당 더 많은 유용한 토큰으로 이어지지는 않는다. 전문가 디스패치와 결과 수집이 네트워크를 압도하면, 고가의 GPU는 활성화를 처리하는 대신 대기하게 된다.
Amazon EKS MoE 강화학습이 네트워크 병목에 부딪히는 이유
희소 연산은 산술 연산량을 절약하지만, 전문가 병렬화는 그 비용을 통신 지연으로 되돌려 놓을 수 있다.
전문가 병렬화는 모델의 전문가들을 여러 GPU에 분산한다. 라우터가 원격 전문가를 선택하면 시스템은 각 토큰의 활성화를 올바른 장치로 디스패치해야 한다. 전문가가 이를 처리한 뒤에는 결합 연산이 출력을 원래 실행 경로로 되돌린다.
이러한 교환은 모델 전체에서 반복적으로 발생한다. 목적지는 런타임에 이루어진 라우팅 결정에 따라 달라지며, 전문가마다 수신하는 토큰 수가 다를 수 있다. 따라서 네트워크는 일부 바쁜 목적지가 모든 참여자를 지연시키지 않도록 하면서, 많은 세분화된 전송을 처리해야 한다.
DeepEP는 이러한 패턴을 위해 만들어졌다. DeepEP 프로젝트는 전문가 병렬 워크로드를 위한 특화된 디스패치 및 결합 커널을 제공한다. 서버 내부 통신에는 NVLink를, 서버 간 통신에는 RDMA 지원 전송 방식을 사용한다.
원격 직접 메모리 접근(Remote Direct Memory Access), 즉 RDMA는 한 머신이 CPU 개입을 줄인 상태로 다른 머신의 메모리로 데이터를 직접 전송할 수 있게 한다. 이처럼 짧아진 경로는 소프트웨어 오버헤드를 줄이고 고속 네트워크 하드웨어를 더 유용하게 만들 수 있다.
Elastic Fabric Adapter, 즉 EFA는 긴밀하게 결합된 컴퓨팅을 위한 AWS의 저지연 네트워크 인터페이스다. EFA 문서는 AWS Scalable Reliable Datagram을 기반으로 한 운영체제 우회 경로를 설명한다. EKS는 분산 머신러닝 애플리케이션을 실행하는 포드에 EFA 장치를 노출할 수 있다.
각 P5en 인스턴스 내부에서는 NVLink와 NVSwitch가 로컬 가속기 패브릭 전반의 GPU 트래픽을 전달한다. 인스턴스 간 전송에서는 EFA가 관련 경로가 된다. Amazon의 통합은 애플리케이션이 공통 API를 통해 서로 다른 고성능 네트워크 제공자에 접근할 수 있게 하는 인터페이스인 libfabric을 사용한다.
Amazon은 자사 엔지니어들이 DeepEP 통신 프리미티브를 CUDA 전용 RDMA 백엔드에서 libfabric으로 옮기는 기능에 기여했다고 밝혔다. 이 작업으로 DeepEP v2는 전문가 디스패치 및 결합을 위한 특화 커널을 유지하면서 EFA를 통해 노드 간 데이터를 전송할 수 있다.
특화된 전문가 연산과 밀집형 집합 연산의 차이는 이 결과의 핵심이다. NCCL은 all-reduce, all-gather, reduce-scatter 같은 규칙적인 연산에 여전히 유용하다. DeepEP는 MoE 레이어 주변에서 발생하는 희소한 all-to-all 교환을 겨냥한다.
최근 연구도 이러한 구분을 반영한다. NCCL EP의 저자들은 전문가 통신을 위한 별도의 저지연 및 고처리량 모드를 설명한다. 이들의 고처리량 설계는 노드 간 RDMA 연결을 통해 전송하기 전에 NVLink 도메인 내에서 데이터를 집계한다.
이 계층 구조는 머신 간의 더 느린 경계를 넘는 세분화된 트래픽의 양을 줄인다. 또한 클러스터가 하나의 균일한 네트워크가 아니라는 점을 인정한다. 서버 내부 통신은 서버 간 통신과 다른 대역폭 및 지연 시간 특성을 가진다.
AWS 구현도 같은 넓은 원칙을 따른다. 로컬 트래픽은 NVLink에 남고, libfabric은 EFA를 통해 노드 간 DeepEP 트래픽을 전달한다. 이 토폴로지 인식 경로는 모든 토큰 전송을 일반적으로 처리하던 방식을 대체한다.
이로 인한 40% 증가는 단순한 통신 마이크로벤치마크가 아니라 총 롤아웃 출력에 관한 수치다. 더 빠른 커널이 전체 강화학습 루프를 항상 가속하는 것은 아니므로, 이 같은 종단 간 측정은 가치가 있다. 이 성과는 전문가 통신이 완료된 롤아웃 작업에 영향을 줄 만큼 중요했음을 시사한다.
그러나 롤아웃 처리량은 여전히 시스템의 한 계층일 뿐이다. 정책 반복 시간은 환경 실행, 보상 평가, 샘플 버퍼링, 체크포인트 게시, 학습 연산, 가중치 동기화에도 좌우된다. 한 단계를 최적화하면 다른 곳의 병목이 드러날 수 있다.
진짜 경쟁은 특화 라우팅과 범용 집합 연산 사이에 있다
핵심 경쟁은 동적인 전문가 라우팅을 위해 설계된 통신과 규칙적인 데이터 이동을 위해 설계된 집합 연산 간의 대결이다.
범용 집합 연산은 성숙하고 폭넓게 지원되며 통합하기 쉽기 때문에 매력적이다. 다양한 학습 프레임워크와 하드웨어 구성에서 작동한다. 운영자는 익숙한 도구로 이를 테스트하고 동기화 동작을 파악할 수도 있다.
MoE 트래픽은 이러한 집합 연산을 효율적으로 만드는 여러 가정을 깨뜨린다. 모든 토큰은 서로 다른 전문가 집합을 선택할 수 있다. 일부 전문가는 일시적으로 인기를 얻고, 메시지 크기는 작게 유지되며, 시스템은 모든 MoE 레이어에서 디스패치와 결합 연산을 수행한다.
일반적인 구현은 이 트래픽을 all-to-all 연산으로 패키징할 수 있다. 이 접근 방식은 여전히 기능하지만, 전문가 병렬화가 더 많은 노드에 걸쳐 확장될수록 동기화 및 메시지 처리 오버헤드가 커진다. 그러면 GPU가 늘어날수록 유용한 연산량이 비례해 증가하는 대신 통신 관계가 더 많아진다.
DeepEP는 전문가 라우팅의 의미론을 중심으로 구축된 커널로 이 문제를 공략한다. 디스패치 커널은 토큰 활성화를 선택된 전문가에게 전송한다. 결합 커널은 처리된 활성화를 반환하면서, 사용되지 않는 목적지에 대해 범용 집합 연산이 수행할 수 있는 작업을 피한다.
이 설계는 통신과 연산을 겹치게 하는 것도 목표로 한다. 전송이 진행되는 동안 GPU가 유용한 행렬 연산을 계속할 수 있다면, 일부 네트워크 시간은 임계 경로에서 사라진다. 통신에 반복적인 CPU 조정이나 엄격한 전역 동기화가 필요할 경우 이러한 중첩은 더 어려워진다.
Amazon의 libfabric 마이그레이션이 중요한 이유는 기존 최적화가 NVIDIA GPU 및 InfiniBand 스타일 네트워킹과 밀접하게 연관돼 있었기 때문이다. 한 패브릭에서 잘 작동하는 통신 라이브러리가 다른 패브릭에서도 자동으로 동일한 동작을 유지하는 것은 아니다. 순서 보장, 메시지 시작, 장치 인터페이스는 서로 다르다.
따라서 이 통합은 단순히 네트워크 주소를 바꾸는 작업 이상이다. DeepEP의 가정은 EFA의 전송 의미론에 맞춰져야 하며, 구현은 토큰이 정확히 전달되도록 보장해야 한다. 또한 특화 라우팅의 이점을 상쇄할 만큼의 소프트웨어 오버헤드가 추가되지 않도록 해야 한다.
Amazon은 지원되는 P5 및 P6 시스템이 EFA와 함께 GPUDirect RDMA를 사용할 수 있다고 밝혔다. GPUDirect RDMA는 모든 페이로드를 일반 호스트 메모리를 거치게 하지 않고 네트워크 전송이 GPU 메모리에서 직접 읽고 쓸 수 있게 한다. 운영체제는 주 데이터 경로 밖에 머문다.
이 설계는 표준 집합 연산에만 의존하는 범용 MoE 배포에 압박을 가한다. 대규모 전문가 병렬 모델을 사용하는 인프라 팀은 이제 특화 경로가 하나의 프로덕션 관련 강화학습 워크로드를 개선할 수 있다는 근거를 갖게 됐다.
이 결과는 프레임워크 유지관리자에게도 압박을 준다. DeepEP 지원은 서빙 엔진, 강화학습 시스템, 컨테이너 이미지, 스케줄러, 관측성 도구까지 도달해야 한다. 취약한 커스텀 빌드를 요구하는 빠른 전송 방식은 배포나 복구 과정에서 그 이점을 잃을 수 있다.
NCCL 2.31은 이 그림에 또 하나의 조각을 더한다. AWS는 해당 릴리스에 밀집형 집합 통신을 위한 최신 EFA 최적화가 포함된다고 밝혔다. 따라서 현실적인 MoE 학습 스택은 하나의 보편적 승자를 선언하기보다 트래픽 유형별로 서로 다른 메커니즘을 사용한다.
DeepEP는 불규칙한 expert dispatch와 combine을 처리한다. NCCL은 attention layer, tensor parallelism, data parallelism, optimizer state 주변의 밀집형 동기화를 계속 처리한다. EFA는 각 패턴에 최적화된 경로를 통해 두 유형의 트래픽을 머신 간에 전달한다.
이러한 분업이 더 큰 아키텍처적 교훈이다. MoE 확장은 형태와 목적에 따라 통신을 식별하는 데 달려 있다. 모든 전송을 상호 교환 가능한 것으로 취급하면 활용 가능한 성능을 놓치게 된다.
DeepEP 처리량 40% 주장으로는 입증되지 않는 것
이 벤치마크는 특정 아키텍처 결정을 뒷받침하지만, DeepEP가 EFA보다 보편적으로 40% 더 높은 성능을 낸다는 사실을 입증하지는 않는다.
Amazon은 인스턴스 구성, 상대적 향상 폭, 모델의 대략적인 희소성 특성을 식별한다. 그러나 모델의 파라미터 수, expert 수, 라우팅 분포, 시퀀스 길이, 배치 크기 또는 전체 기준선 구성은 공개하지 않는다.
이러한 세부 사항은 expert 통신에 직접 영향을 준다. 토큰당 더 많은 expert를 활성화하는 모델은 더 많은 트래픽을 생성할 수 있다. 더 큰 배치는 메시지를 더 효율적으로 결합할 수 있는 반면, 작은 decode 배치는 고정 지연 시간을 증폭시킬 수 있다.
“aggregate rollout throughput”이라는 표현도 맥락이 필요하다. AWS는 공개 게시물에서 초당 절대 출력 토큰 수, trajectory 수 또는 완료 요청 수를 제공하지 않는다. 독자는 클러스터의 전체 활용도를 계산하거나 다른 제공업체와 직접 비교할 수 없다.
기준선도 마찬가지로 중요하다. “Without DeepEP”은 특정 튜닝 선택이 적용된 표준 NCCL all-to-all 구현을 의미할 수 있다. 다른 메시지 집계, expert 배치, 동시성 또는 라우팅 정책은 측정된 격차를 좁히거나 넓힐 수 있다.
Amazon은 자사의 내부 워크로드에서 통제된 결과를 보고한다. 회사는 이 벤치마크가 독립 감사를 받았다고 주장하지 않으며, 공개 자료에는 반복 시험의 분산도 포함되지 않는다. 따라서 올바른 표현은 AWS가 처리량이 40% 증가했다고 밝힌다는 것이다.
이식성 문제도 있다. 이전 UCCL-EP research는 GPU 및 네트워크 인터페이스에 밀접하게 연결된 expert 통신 시스템이 상당한 통합 작업을 초래한다고 주장했다. 이 논문은 특히 서로 다른 순서 보장 의미론이 EFA 및 기타 non-InfiniBand 네트워크 지원을 어떻게 복잡하게 만드는지 검토했다.
해당 연구는 Amazon이 새로 설명한 네이티브 EFA 작업보다 앞선 것이다. 이는 AWS가 이제 libfabric 기여를 통해 해결했다고 밝힌 기술적 장벽을 설명하기 때문에 여전히 관련성이 있다. 두 설명은 빠르게 변화하는 구현 역사에서 서로 다른 시점을 다룬다.
UCCL-EP는 다른 경로를 택한다. 라우팅 결정은 GPU에 유지하되, 네트워크 실행은 멀티스레드 CPU proxy에 위임하고 제어 채널을 사용해 하드웨어 차이를 연결한다. 저자들은 NVIDIA와 EFA 시스템에서 성능 향상을 보고하지만, 해당 테스트는 자체 모델, 프레임워크 및 구성으로 수행됐다.
어느 결과도 다른 결과를 무효화하지 않는다. 두 결과는 전송 설계가 결과를 바꿀 수 있으며, “EFA support”가 하나의 고정된 실행 경로를 뜻하지 않는다는 점을 보여준다. 운영자는 빌드가 GPU-initiated transfer, CPU proxy, 메시지 집계 또는 다른 호환성 계층을 사용하는지 알아야 한다.
DeepEP가 공개한 요구 사항과 성능 결과도 변화해 왔다. 현재 프로젝트 문서는 지원되는 RDMA 구성에서 강력한 대역폭을 보고하지만, 사용자에게 더 큰 expert-parallel 배포 환경에서 직접 벤치마크할 것을 권장한다. 이 조언은 토폴로지와 혼잡 특성이 다른 클라우드 패브릭에서 특히 중요하다.
클러스터 규모는 추가 불확실성을 만든다. 보고된 테스트는 P5en 인스턴스 48개를 사용한 반면, AWS는 더 광범위한 아키텍처를 약 1,000개의 accelerator 규모로 확장하는 방안을 논의한다. 48개 노드에서 잘 작동하는 설계가 모든 더 큰 규모에서 같은 효율을 유지한다는 보장은 없다.
여러 worker group이 인프라를 공유하면 네트워크 경합이 발생할 수 있다. 모델 또는 워크로드 동작이 변하면 토큰 라우팅의 불균형도 더 커질 수 있다. 단일 느린 rank 역시 긴밀하게 동기화된 학습 작업을 지연시킬 수 있다.
강화학습은 자체적인 변동 원인도 추가한다. 프롬프트 길이, 응답 길이, 환경 지연 시간, 샘플링 설정 및 reward-model 복잡성은 모두 rollout worker가 통신에 소비하는 시간에 영향을 준다. 통신 비중이 큰 워크로드에서 40% 향상은 생성 또는 환경 실행이 지배적일 때 줄어들 수 있다.
이 결과가 온라인 serving에 대해 말해주는 바는 더 적다. 프로덕션 추론은 흔히 더 작은 배치와 엄격한 요청별 지연 시간 목표를 사용한다. rollout 생성에 맞춰 조정된 고처리량 kernel이 대화형 사용자에 대한 첫 토큰까지의 시간이나 출력 토큰당 시간을 자동으로 줄여주지는 않는다.
비용도 절대값 기준으로는 제시되지 않는다. 동일한 클러스터에서 더 높은 처리량은 일반적으로 accelerator-hour당 유효 작업량을 개선하지만, 게시물은 총 학습 비용을 제공하지 않는다. 또한 최적화된 구성을 대체 인스턴스 유형이나 네트워크 라이브러리와 비교하지도 않는다.
이러한 누락이 결과의 중요성을 떨어뜨리는 것은 아니다. 다만 결과가 유용한 범위를 규정한다. 이 벤치마크는 AWS의 DeepEP 통합이 하나의 대규모 MoE 강화학습 파이프라인에서 의미 있는 병목을 제거할 수 있다는 증거다.
EKS와 Spot Capacity가 RL 시스템의 나머지를 바꾼다
스케줄러, buffer, storage 및 장애 모델이 더 빨라진 rollout fleet에 충분한 작업을 지속적으로 공급할 때에만 통신 성능 향상은 운영상 유용해진다.
Amazon EKS는 아키텍처가 서로 다른 노드 유형을 구분된 작업에 할당할 수 있게 한다. GPU node group은 학습 및 추론 수요에 맞춰 확장할 수 있다. CPU group은 environment worker를 위해 확장할 수 있고, 메모리 중심 시스템은 단기 experience data를 흡수한다.
이러한 이질성은 GRPO와 RLHF에 특히 관련성이 높다. Rollout worker는 대량의 임시 데이터를 생성할 수 있지만, policy trainer는 이를 동기화된 배치로 소비한다. 생산과 소비 속도가 어긋나면 한쪽은 기다리고 다른 쪽은 큐를 쌓게 된다.
공유 in-memory experience buffer는 짧은 기간 동안 이러한 속도를 분리한다. Rollout worker는 완료된 sample을 게시하고, trainer는 준비가 되면 배치를 가져간다. Checkpoint cache는 모든 전송을 내구성 있는 object storage로 통과시키지 않고도 업데이트된 weight를 배포하는 데 도움을 준다.
Amazon S3는 다른 역할을 맡는다. 데이터셋, 복구 가능한 checkpoint, 완료된 모델 artifact 및 최종 weight를 보관한다. 가장 빈번한 sample 교환에서 이 내구성 경로를 분리하면 object-storage 지연 시간이 모든 학습 단계를 좌우하지 않게 된다.
이 분리는 EKS의 가치도 명확히 한다. Kubernetes는 matrix multiplication이나 expert kernel을 가속하는 것이 아니다. accelerator의 생산성을 유지하는 데 필요한 서비스 집합을 조정한다.
EKS는 배치, 재시작, 확장 정책 및 node-group 경계를 관리한다. 안정적인 policy-training capacity를 더 탄력적인 rollout worker와 별도로 스케줄할 수 있다. 이 경계는 Amazon의 두 번째 최적화, 즉 일부 rollout generation에 EC2 Spot Instances를 사용하는 방식을 뒷받침한다.
AWS가 기반 인스턴스를 회수해야 할 경우 Spot capacity는 중단될 수 있다. worker 하나를 잃는 것만으로도 조정된 작업이 중단되거나 재시작될 수 있으므로, 이 위험은 긴밀하게 동기화된 policy training에 어렵다. Rollout 작업은 분할과 재시도가 더 쉽다.
Amazon은 rollout worker에 범위가 제한된 작업 단위를 부여하고 sample을 자주 게시할 것을 권장한다. 중단 알림이 도착하면 worker는 진행 중인 요청을 마무리하고 미완료 작업을 큐로 돌려보낼 수 있다. 다른 worker는 전체 policy-training group을 재시작하지 않고 계속 작업한다.
이 전략이 중단 비용을 없애지는 않는다. 잃어버린 부분 생성 결과는 일부 컴퓨팅 자원을 낭비하고, 대체 노드는 container, model weight 및 communication library가 필요하다. Autoscaling 결정도 큐 깊이, 모델 로딩 시간 및 사용 가능한 Spot capacity를 고려해야 한다.
그럼에도 이 토폴로지는 두 장애 도메인을 분리한다. Policy trainer는 안정적인 capacity에 남아 있고, rollout generation은 더 저렴하지만 예측 가능성이 낮은 pool을 사용한다. 이 설계는 두 단계의 서로 다른 동기화 요구 사항에 부합한다.
DeepEP 처리량 40% 증가는 이 균형을 바꿀 수 있다. 더 빠른 inference worker는 trainer가 소비하는 것보다 더 빠르게 experience를 제공할 수 있다. 운영자는 유휴 생산에 비용을 지불하지 않도록 node group 크기를 조정하거나, batch scheduling을 조정하거나, inference capacity를 줄여야 한다.
Policy update 후에는 반대 상황이 발생할 수 있다. Weight 배포와 worker 재시작 시간은 일시적으로 experience buffer를 고갈시킬 수 있다. 따라서 유용한 프로덕션 dashboard는 단순히 초당 생성 토큰 수가 아니라 end-to-end policy iteration을 추적해야 한다.
팀에는 재현 가능한 빌드 정보도 필요하다. DeepEP, NCCL, CUDA, libfabric, EFA driver, framework 버전 및 GPU 아키텍처는 모두 데이터 경로에 영향을 준다. 구성 요소 하나를 변경하는 것만으로도 더 느린 fallback이 조용히 선택될 수 있다.
이 운영 증거는 모델 및 실험 기록과 함께 보관해야 한다. 엔지니어링 팀은 구성 결정, 벤치마크 메모 및 장애 보고서를 검색 가능한 technical knowledge base에 보존할 수 있다. 나중에 image rebuild가 모델 변경 없이 처리량을 바꿀 때 이 관행은 가치가 커진다.
성능 향상이 일반화되는지 보여줄 세 가지 신호
다음 시험은 모델, 클러스터 규모 및 완전한 policy iteration 전반에서의 재현성이다.
첫 번째 신호는 절대 처리량을 포함한 공개 벤치마크 패키지다. 유용한 결과에는 초당 토큰 또는 trajectory 수, 지연 시간 분포, expert-load 불균형, 네트워크 활용도 및 반복 실행 분산이 포함된다.
이 패키지는 기준선 collective, 모든 관련 소프트웨어 버전 및 정확한 DeepEP transport path를 명시해야 한다. 또한 모델 차원, 토큰당 활성 expert 수, 배치 크기, 프롬프트 길이, 응답 길이 및 expert-parallel degree를 공개해야 한다.
독립 팀이 유사한 성능 향상을 재현한다면 AWS의 주장은 더 강해진다. 결과가 크게 달라진다면 통합은 여전히 유용하지만 워크로드에 특화된 것으로 남는다. 어느 결과든 운영자가 추가 복잡성이 정당화되는 시점을 판단하는 데 도움이 된다.
두 번째 신호는 공개된 48개 인스턴스 구성 이상의 확장 효율이다. 여러 클러스터 규모의 결과는 처리량이 비례적으로 증가하는지, 아니면 동기화, 혼잡 및 expert 불균형으로 인해 효율을 잃는지를 보여줄 것이다.
의미 있는 확장 연구는 리소스를 늘리는 동안 워크로드 정의를 일정하게 유지해야 한다. aggregate output과 accelerator당 효율을 모두 보고해야 한다. 전체 처리량은 추가된 모든 GPU가 더 적은 유효 작업을 기여하는 상황에서도 증가할 수 있다.
약 1,000개의 accelerator를 향한 강력한 효율은 AWS의 더 폭넓은 아키텍처 주장을 뒷받침할 것이다. 급격한 감소는 DeepEP가 하나의 병목을 제거했지만 더 큰 규모에서 다른 병목이 나타났음을 시사할 것이다.
세 번째 신호는 실제 장애 상황에서의 end-to-end policy iteration 시간이다. Rollout 처리량이 중요한 이유는 학습 worker가 최신 experience를 필요로 하기 때문이지, 고립된 토큰 생성이 최종 목표이기 때문은 아니다.
향후 측정에는 environment execution, reward evaluation, buffer delay, policy update, checkpoint publication 및 weight redistribution이 포함돼야 한다. 또한 Spot interruption이 완료된 sample과 복구 시간에 어떤 영향을 주는지도 보여줘야 한다.
더 짧은 전체 iteration은 통신 최적화가 유휴 시간을 다른 곳으로 옮기는 것이 아니라 강화학습의 진전을 개선한다는 점을 확인해줄 것이다. Iteration 시간이 거의 변하지 않는다면, 팀은 rollout capacity를 더 추가하기 전에 학습, storage 또는 synchronization을 조사해야 한다.
Amazon EKS MoE 강화 학습은 이제 Kubernetes 오케스트레이션, EFA 네트워킹, 특화된 전문가 간 통신을 결합할 수 있는 신뢰할 만한 경로를 갖추게 됐다. 보고된 40% 향상은 이 경로를 시험해볼 가치를 보여주지만, 이는 어디에나 적용 가능한 상수가 아니라 출발점이 되는 측정치에 가깝다. 인프라 팀은 이 스택을 표준화하기 전에 자체 모델, 라우팅 프로필, RL 루프를 바탕으로 비교를 재현해야 한다. 실질적인 질문은 DeepEP가 더 빠른 차트를 만들 수 있는지가 아니다. 시스템의 모든 요소를 반영한 뒤에도 동일한 클러스터가 허용 가능한 신뢰성과 비용으로 더 많은 검증된 정책 업데이트를 완료할 수 있는지다.
