대규모 학습은 완전히 멈추기보다 조금씩 느려지는 경우가 많습니다. GPU 한 장의 클록이 낮아지거나 PCIe 경로가 불안정해지고, 데이터 로더나 통신 설정이 한 작업자만 늦출 수 있습니다. 프로세스는 살아 있으므로 상태 검사는 통과하지만, 동기화 지점에서는 모든 작업자가 가장 느린 하나를 기다립니다. 대시보드는 증상을 보여 줘도 어느 장치와 함수가 원인인지는 알려 주지 못합니다.
EROICA는 장비군 감시와 오프라인 프로파일러 사이의 빈틈을 다룹니다. 장비군 감시는 부담이 작고 모든 서버를 볼 수 있지만 초 단위 집계만으로 짧은 함수 이상을 설명하기 어렵습니다. 정밀 프로파일러는 Python 호출, CUDA 커널, 통신 이벤트와 하드웨어 샘플을 남기지만, 논문에 따르면 Torch Profiler는 작업자 한 개에서 초당 100 MB가 넘는 데이터를 만들 수 있습니다. 수만 개 GPU에서 이 데이터를 계속 모으는 대신, EROICA는 보관하고 비교해야 할 단위를 바꿉니다.
전체 감시와 원인 설명 사이의 차이
일반적인 경보는 GPU 사용률이나 NIC 카운터처럼 부품에서 시작합니다. 학습 성능 저하는 동기화된 실행 단계에서 드러납니다. 같은 지연도 사용자 코드, 프레임워크 설정, CPU 경쟁, GPU 주파수, 메모리, NVLink, PCIe, NIC, 네트워크와 원격 스토리지에서 생길 수 있습니다. 네트워크 결함이 통신 함수의 실행 시간을 바꾸는 경우처럼 하드웨어와 소프트웨어가 함께 나타나기도 합니다.
논문의 운영 기록은 원인의 폭을 보여 줍니다. 약 10만 개 GPU를 9개월 동안 관찰한 사례에서 성능 문제의 44.4%는 하드웨어, 48.2%는 소프트웨어에서 발생했습니다. 저자들이 비교한 기존 온라인 도구로 원인까지 확인할 수 있던 비율은 29.6%였습니다. 부족했던 것은 평균 카운터 하나가 아니라, 어떤 함수에서 작업자들의 동작이 달라졌는지를 설명하는 정보였습니다.
EROICA는 전체 지연 감지기가 이상을 확인하면 작업자들의 프로파일링을 같은 시점에 켭니다. GPU 연산과 메모리 처리, 통신 함수 이벤트를 모으고 CPU, 메모리, GPU, NVLink, PCIe와 네트워크 샘플을 붙입니다. 정밀한 관측을 사용하되 항상 켜 두지 않고, 이상 구간에 한정해 수집한 뒤 각 호스트에서 먼저 요약합니다.
원시 이벤트 대신 함수 실행 특성
EROICA가 비교하는 단위는 인과관계가 있는 학습 함수의 실행 특성입니다. 모든 타임스탬프를 보존하지 않고 실행 시간과 당시의 하드웨어 동작을 압축해 기록합니다. 동기식 학습에서 정상 작업자들은 같은 단계를 비슷하게 실행하므로, 문제가 생긴 작업자는 함수 시간이나 하드웨어 특성 중 하나가 달라집니다. 정상 다수는 별도의 고정 비교 서버가 아니라 같은 순간의 기준이 됩니다.
이 방식은 클러스터 전체의 시계를 마이크로초 수준으로 맞춰야 한다는 요구도 줄입니다. 논문은 NTP 오차가 약 10 ms일 수 있지만 관심 함수는 밀리초나 마이크로초 단위로 실행된다고 설명합니다. 서로 다른 호스트의 절대 시간을 바로 비교하면 시계 오차를 실행 순서의 차이로 오인할 수 있습니다. EROICA는 호스트 안의 인과관계를 유지한 뒤 요약된 특성을 작업자 사이에서 비교합니다.
하드웨어 샘플은 진단 모드에 따라 10 kHz에서 200 kHz까지 사용할 수 있습니다. 중요한 점은 가장 높은 샘플링 주파수를 항상 적용하는 것이 아닙니다. 느려진 함수를 구분할 만큼의 구조를 남기면서 원시 프로파일 스트림을 장비군 전체에 전송하지 않는 것이 설계 목표입니다.
느린 작업자에서 실제 원인까지
운영에 쓸 수 있는 진단은 느린 작업자 순위보다 더 구체적이어야 합니다. EROICA는 이상 특성을 해당 함수와 실행 중의 하드웨어 상태에 연결합니다. 특정 네트워크 본드를 지나는 작업자들에서만 올리듀스 처리량이 달라지면 링크를 의심할 수 있습니다. GEMM 시간이 늘면서 GPU 주파수나 점유율이 바뀌면 다른 조치가 필요합니다. CPU 경쟁이 동반된 데이터 로더 지연은 통신 라이브러리 문제와 복구 방법이 다릅니다.
논문에는 네트워크 성능 저하, GPU 스로틀링, 호스트 관리 서비스의 자원 경쟁, 프레임워크 설정과 사용자 코드 사례가 포함됩니다. 장치 결함만 학습한 분류기는 소프트웨어 문제를 놓치고, 소스 코드만 보는 프로파일러는 하드웨어가 느리게 만든 함수를 잘못 해석할 수 있습니다. EROICA는 먼저 이상 함수 구간을 좁힌 뒤 소프트웨어 이벤트와 물리 장치의 근거를 함께 봅니다.
진단 결과를 AI 보조 도구에 넘겨 단순한 코드나 설정 오류의 수정안을 만들 수도 있습니다. 다만 원인 확인과 자동 수정은 다른 단계입니다. 병렬화나 통신 동작을 바꾸는 제안은 작업별 검증과 롤백 절차가 필요하며, 실제 근거는 함수와 장치의 위치를 확인한 결과입니다.
97.5%라는 운영 결과의 범위
EROICA는 약 10만 개 GPU를 포함한 환경에서 1년 6개월 동안 운영 서비스로 사용됐습니다. 저자들은 평가 대상이 된 까다로운 성능 문제의 97.5%에서 진단에 성공했다고 보고합니다. 고정된 합성 장애에 대한 분류 정확도가 아니라, 한 사업자의 실제 소프트웨어와 운영 절차에서 나온 결과라는 점에 의미가 있습니다.
이 비율만으로 진단 시간, 오경보 비용이나 장애 한 건에서 회수한 학습 시간을 알 수는 없습니다. 어떤 사건을 평가 모집단에 넣었는지, 원인을 어떻게 확정했는지도 함께 봐야 합니다. 다른 운영자는 프레임워크와 가속기, 네트워크 토폴로지, 호스트 에이전트가 다르므로 도입 전에 사건 수와 유형, 미해결 사례, 프로파일링 발동 조건, 경보부터 조치까지 걸린 시간을 확인해야 합니다.
운영 수치는 그대로 옮기기 어렵지만 설계 원리는 이식할 수 있습니다. 동기식 작업자는 자연스러운 비교 집단을 제공하고, 함수 경계는 프로그램 동작과 하드웨어 상태를 연결합니다. 문제가 생겼을 때만 정밀도를 높이면 상시 비용을 줄일 수 있고, 호스트에서 요약하면 중앙 전송량을 제한할 수 있습니다. PyTorch, JAX, Megatron이나 사내 런타임에서도 계측과 진단 규칙을 새로 만들면 같은 원리를 적용할 수 있습니다.
로그 양보다 중요한 관측 예산
관측 시스템은 샘플링 주파수나 보관 기간, 대시보드 수로 비교되기 쉽습니다. 실제 운영에서는 네 가지를 따로 봐야 합니다. 문제가 발생했을 때 활성 작업자의 몇 %를 볼 수 있는지, 호스트가 아니라 함수와 장치까지 좁힐 수 있는지, 근거 수집 중 학습 진행을 얼마나 잃는지, 실제 사건 중 조치 가능한 원인에 도달한 비율이 얼마인지가 중요합니다.
모든 이벤트를 저장하면 나중에 다시 분석하기는 쉽지만 네트워크와 스토리지 비용이 커지고 분석이 늦어집니다. 반대로 샘플을 지나치게 줄이면 짧은 이상을 놓칩니다. EROICA는 전체 감지기가 이상을 발견한 순간에만 세부 관측을 켜고, 호스트에서 먼저 압축한 뒤 비교하는 중간 지점을 선택합니다.
따라서 발동 조건도 신뢰성 설계에 포함됩니다. 경보가 늦으면 프로파일링이 시작되기 전에 이상 상태가 사라질 수 있고, 너무 자주 켜면 일시적 프로파일러가 상시 오버헤드로 바뀝니다. 임곗값, 수집 시간, 재발동 대기 시간과 적용 작업을 재현 가능한 정책으로 관리해야 합니다. 호출 스택과 소스 위치에는 고객 코드가 포함될 수 있으므로 멀티테넌트 환경에서는 접근 통제도 필요합니다.
실제 도입을 위한 계측 기준
새 환경에 적용할 때는 자체 장애 기록에서 원인 분류를 먼저 만들어야 합니다. 각 유형마다 가능한 원인을 구분하는 최소 관측값을 정하면 불필요한 데이터 수집을 줄일 수 있습니다. GPU 주파수와 SM 활동은 열이나 전력에 의한 스로틀링을 입력 지연과 구분하고, 함수별 NIC 처리량은 집단 통신 라이브러리와 물리 링크를 나누는 데 도움이 됩니다. CPU와 스토리지 샘플은 체크포인트와 데이터 로더 문제를 설명합니다. 운영자의 조치를 바꾸지 못하는 카운터는 수집할 이유가 적습니다.
압축된 특성을 의심할 수 있는 제한된 원시 로그도 남기는 편이 안전합니다. 전문가 혼합 모델의 비대칭 라우팅이나 동기화가 적은 작업은 정상 다수라는 기준이 약할 수 있습니다. 의심 작업자 몇 개의 짧은 원시 구간을 보존하면 요약 결과를 다시 확인할 수 있습니다. 비교 가능한 동료 작업자가 없을 때는 진단 신뢰도를 낮춰 표시해야 합니다.
마지막 평가지표는 회수한 GPU 시간입니다. 원인 이름을 붙였더라도 조치가 늦거나 재발을 막지 못하면 운영 가치는 작습니다. 진단 기록을 장애 티켓, 설정 변경과 이후 학습 효율에 연결하면 관측 비용이 실제 복구 성과로 이어지는지 확인할 수 있습니다.
GPU 장비군 운영의 판단 기준
EROICA의 핵심은 97.5%라는 숫자 하나보다, 대규모 동기식 학습이 자체 비교 집단을 제공한다는 점입니다. 같은 단계를 실행하는 작업자들의 압축된 특성을 비교하면 모든 서버의 전체 추적 데이터를 중앙에 모으지 않고도 이상 위치를 찾을 수 있습니다.
AI 인프라 팀은 관측 제품이 느린 반복을 정확한 함수와 물리 장치로 연결하는지 물어야 합니다. 사용률 그래프에서 끝나면 가장 비싼 원인 분석은 여전히 사람이 수행합니다. 함수의 인과관계를 보존하고, 작업자 간 차이와 하드웨어 상태를 제한된 수집 비용 안에서 연결할 수 있다면 10만 개 GPU도 계속 프로파일링하지 않고 진단 가능한 장비군으로 바뀝니다.
출처와 저작권 안내
이 글은 NSDI 2026 논문[1]을 우리 표현으로 다시 분석한 편집 다이제스트입니다. 논문의 문장·도판·표를 옮기지 않았으며, 본문 도판은 Silicon & Systems가 새로 제작했습니다. 수치는 저자들이 밝힌 운영 범위와 함께 인용했으며 다른 환경에서는 자체 사건 기록으로 다시 검증해야 합니다. 원 논문의 저작권은 저자와 USENIX 프로시딩(2026)에 있습니다.