distributed-computing

2 개의 포스트

meta

RCCLX: AMD 플랫폼 (새 탭에서 열림)

메타(Meta)는 AMD 플랫폼에서 AI 모델의 혁신을 가속화하기 위해 최적화된 통신 라이브러리인 RCCLX를 오픈소스로 공개했습니다. RCCLX는 메타 내부의 워크로드를 위해 개발된 RCCL의 강화 버전으로, 직접 데이터 액세스(DDA)와 저정밀도 집합 통신 기능을 통해 LLM 추론 및 학습 성능을 대폭 향상시킵니다. 이 라이브러리는 Torchcomms API에 통합되어 개발자들이 하드웨어 백엔드에 구애받지 않고 고성능 통신 기능을 손쉽게 활용할 수 있도록 설계되었습니다. ### Direct Data Access(DDA)를 통한 단일 노드 통신 최적화 * **추론 병목 해결**: LLM 추론 과정 중 텐서 병렬화 시 발생하는 AllReduce 연산은 전체 지연 시간의 최대 30%를 차지하는데, DDA는 이를 효과적으로 단축합니다. * **DDA Flat 알고리즘**: 각 랭크가 다른 랭크의 메모리에서 직접 데이터를 로드하도록 하여 소규모 메시지의 지연 시간을 O(N)에서 O(1)로 줄여줍니다. * **DDA Tree 알고리즘**: 연산을 Reduce-scatter와 All-gather 단계로 나누어 수행하며, 링(Ring) 알고리즘과 동일한 데이터 이동량을 유지하면서도 중간 규모 메시지의 지연 시간을 상수로 고정합니다. * **성능 지표**: AMD MI300X GPU 기준, 디코딩(작은 메시지) 단계에서 10~50%, 프리필(큰 메시지) 단계에서 10~30%의 성능 향상을 보였으며, 결과적으로 TTIT(Time-to-Incremental-Token)를 약 10% 개선했습니다. ### 저정밀도 집합 통신(Low-precision Collectives)의 활용 * **FP8 양자화 적용**: FP32 및 BF16 데이터 타입을 지원하며, FP8 양자화를 통해 최대 4:1의 압축률을 구현함으로써 16MB 이상의 대규모 메시지 통신 오버헤드를 줄입니다. * **수치적 안정성**: 통신 시에는 저정밀도를 사용하지만, 계산 단계에서는 FP32 고정밀도를 유지하여 수치적 오차를 최소화합니다. * **효율적인 인프라 활용**: AMD Infinity Fabric을 통한 병렬 P2P 메시 통신을 활용하여 대역폭 사용을 최적화합니다. * **실제 효과**: 내부 실험 결과 지연 시간은 약 9~10% 감소하고 처리량은 7% 증가했으며, GSM8K 평가에서 모델 정확도 하락은 0.3% 수준에 불과했습니다. ### Torchcomms 통합 및 플랫폼 호환성 * **단일 API 제공**: RCCLX는 Torchcomms API의 커스텀 백엔드로 통합되어, NVIDIA용 NCCLX와 기능적 동등성을 목표로 합니다. * **유연한 이식성**: 개발자는 기존에 익숙한 API를 그대로 사용하면서 코드 수정 없이 AMD 플랫폼으로 애플리케이션을 이식하고 CTran과 같은 고성능 기능을 사용할 수 있습니다. * **간편한 활성화**: `RCCL_LOW_PRECISION_ENABLE=1`과 같은 환경 변수 설정만으로 고성능 최적화 기능을 즉시 활성화할 수 있는 편의성을 제공합니다. RCCLX는 AMD 하드웨어의 잠재력을 최대한 끌어올리려는 연구자와 엔지니어에게 필수적인 도구입니다. 현재 공개된 초기 버전에는 GPU 상주 집합 통신인 AllToAllvDynamic 등이 포함되어 있으며, 향후 수개월 내에 더욱 다양한 고성능 전송 기능들이 추가될 예정이므로 LLM 서비스의 비용 효율성을 높이고자 하는 팀에게 적극 권장됩니다.

pinterest

Pinterest의 Apache Spark에서 (새 탭에서 열림)

Pinterest는 대규모 Spark 환경에서 빈번하게 발생하는 OOM(Out-of-Memory) 오류를 해결하기 위해 'Auto Memory Retries' 기능을 도입했습니다. 이 시스템은 태스크 수준에서 리소스 요구량을 동적으로 판단하고, 실패 시 더 큰 메모리 프로필을 가진 실행기(Executor)에서 태스크를 재시도하도록 자동화합니다. 이를 통해 수동 튜닝의 번거로움을 줄이고 자원 효율성을 높여 전체적인 작업 실패율과 운영 비용을 획기적으로 낮추는 성과를 거두었습니다. ### 기존 Spark 리소스 관리의 한계와 문제점 * Pinterest의 Spark 클러스터는 하드웨어 대비 높은 메모리 요구량으로 인해 OOM 오류가 잦았으며, 전체 작업 실패 원인의 약 4.6%가 메모리 부족에서 기인했습니다. * 사용자가 모든 스테이지와 태스크의 메모리 요구량을 정확히 예측하여 수동으로 설정하는 것은 매우 어렵고 시간이 많이 소요되는 작업입니다. * 데이터 스큐(Skew) 현상으로 인해 같은 스테이지 내에서도 특정 태스크만 과도한 메모리를 사용하는 경우가 많아, 모든 태스크를 최대치에 맞춰 설정하면 심각한 자원 낭비가 발생합니다. * 제품 팀의 우선순위 문제로 인해 비용 절감을 위한 수동 최적화가 지속적으로 이루어지기 어려운 구조적 한계가 있었습니다. ### Auto Memory Retries의 단계별 대응 전략 * **CPU 할당량 증설을 통한 메모리 확보 (1단계):** 실행기에 1개 이상의 코어가 있는 경우, OOM 발생 시 첫 번째 재시도에서 태스크당 CPU 할당량(`spark.task.cpus`)을 두 배로 늘립니다. 이를 통해 실행기 내 동시 실행 태스크 수를 줄여 개별 태스크가 사용할 수 있는 공유 메모리 공간을 즉각적으로 확보합니다. * **물리적으로 큰 실행기 투입 (2단계):** CPU 조절만으로 해결되지 않거나 단일 태스크가 이미 실행기 전체 메모리를 사용 중인 경우, 물리적으로 더 큰 메모리를 가진 새로운 실행기를 동적으로 런칭합니다. * **하이브리드 확장 프로필 적용:** 기본 설정의 2배, 3배, 4배 크기의 리소스 프로필을 미리 등록하고 단계별로 순차 적용합니다. Apache Gluten을 사용하는 워크로드의 경우 Off-heap 메모리도 함께 증설하여 가속화된 연산을 지원합니다. ### 시스템 구현 및 Spark 엔진 확장 * **태스크 수준의 리소스 프로필:** 기존 Spark의 고정된 리소스 할당 방식에서 벗어나, `Task` 객체에 개별 리소스 프로필 ID(`taskRpId`)를 저장할 수 있도록 확장하여 동일한 TaskSet 내에서도 태스크마다 사양을 다르게 가질 수 있게 구현했습니다. * **스케줄링 로직 최적화:** `TaskSetManager`는 OOM 감지 시 즉시 상위 프로필을 할당하며, `TaskSchedulerImpl`은 증설된 CPU 속성을 가진 태스크를 기존 실행기에서 우선 실행할 수 있게 하여 리소스 재사용 속도를 높였습니다. * **동적 리소스 할당:** `ExecutorAllocationManager`가 상위 프로필을 필요로 하는 대기 태스크를 실시간으로 추적하고, 물리적으로 큰 실행기가 필요한 시점에 맞춰 Kubernetes 등에 자원을 요청합니다. * **사용자 경험 개선:** 사용자가 어떤 태스크가 더 많은 자원을 사용했는지 쉽게 파악할 수 있도록 Spark UI의 태스크 목록에 리소스 프로필 ID를 표시하는 기능을 추가했습니다. 효율적인 Spark 운영을 위해서는 모든 작업을 최대 메모리 요구량에 맞추기보다, 상위 90%(P90) 수준의 일반적인 설정으로 실행하고 예외적인 태스크만 'Auto Memory Retries'로 구제하는 탄력적 전략이 권장됩니다. 이는 데이터 스큐가 심한 대규모 파이프라인에서 운영 안정성을 확보함과 동시에 인프라 비용을 최적화할 수 있는 강력한 해법이 될 것입니다.