최근 엔지니어링 커뮤니티에서 가장 화제가 된 글 하나를 꼽자면 단연 Modal의 Keeping 20k GPUs Healthy 일 겁니다. 단순히 “우리가 이렇게 규모가 크다”고 자랑하는 글이 아닙니다. 이 글은 현재 AI 인프라 시장의 치부를 적나라하게 드러내는 내부 고발에 가깝습니다.

저는 지난 15년간 인프라를 다루면서 “CPU가 고장 났다”는 소리는 거의 들어본 적이 없습니다. 하지만 GPU는 다릅니다. 오늘 이 글에서는 Modal이 2만 개의 GPU를 4개의 메이저 클라우드(AWS, GCP, Azure, OCI로 추정되는)에서 굴리며 얻은 피와 땀이 섞인 인사이트를 분석해보려 합니다.

1. 클라우드 인스턴스는 ‘뽑기’다

우리는 흔히 AWS나 GCP에서 p4d.24xlarge 같은 인스턴스를 빌리면, 언제 어디서나 동일한 성능을 낼 것이라고 믿습니다. 하지만 Modal의 데이터는 이 믿음이 완벽한 착각 임을 보여줍니다.

Modal은 각 클라우드 제공사를 A, B, C, D로 익명화했지만, 그 특징은 너무나 뚜렷합니다.

• Cloud A: API는 안정적이지만, H100의 성능이 타사 대비 50%나 떨어집니다.
• Cloud C: 쿨링 이슈가 심각합니다. H100 온도가 90도를 넘어가는 일이 빈번해 성능 스로틀링(Throttling)이 발생합니다.
• Cloud D: 가성비는 좋지만, 하드웨어 레벨의 클럭 다운(Clock Slowdown)과 ECC 에러가 빈번합니다.

특히 충격적인 건 Cloud C 의 사례입니다. 2025년 몇 달 동안 H100의 온도가 90도를 찍었다는 건, 데이터센터 쿨링 설계에 심각한 결함이 있었거나 오버프로비저닝을 했다는 뜻입니다. 70도 중반부터 FLOPs 성능 저하가 오는데 90도라니요. 비싼 돈 내고 빌린 GPU가 제 성능의 반도 못 내는 상황인 겁니다.

2. PCIe vs SXM: 스펙 시트의 함정

많은 엔지니어들이 간과하는 부분이 바로 인터커넥트입니다. Modal이 공개한 벤치마크 데이터를 보면, 같은 H100이라도 연결 방식에 따라 성능 차이가 극심합니다.

Category	Cloud D H100 SXM	Cloud B H100 NVL (PCIe)	차이
torch_matmul_duration	1.62s	2.72s	67.5% 느림
torch_matmul_flops	678 TF/s	405 TF/s	40% 낮음

단순히 PCIe 대역폭 문제라고 생각하기 쉽지만, 실제로는 NVLink와 보드 설계의 차이가 MatMul 연산 속도에까지 영향을 미칩니다. 만약 여러분이 “H100이니까 빠르겠지” 하고 PCIe 버전을 덜컥 계약했다면, 같은 돈을 내고 40% 느린 모델을 학습시키고 있는 셈입니다.

3. 부팅 검사: 우유 냄새를 맡지 마라

인스턴스가 부팅될 때 모든 하드웨어를 검사해야 할까요? 여기서 Modal의 접근 방식은 매우 실용적입니다.

“카페에서 커피를 살 때 우유 냄새를 맡아보진 않는다.”

dcgmi diag --run 4 같은 딥 다이브 테스트는 1시간이 걸립니다. 오토스케일링이 생명인 플랫폼에서 부팅에 1시간을 쓴다는 건 말이 안 되죠. 대신 이들은 Light Check 전략을 취합니다.

1. Boot Phase: systemctl, nvidia-smi, 간단한 I/O 테스트만 수행 (1~2분 내).
2. Runtime: dmesg와 dcgmi를 통해 Xid 에러를 수동적으로 모니터링.
3. Weekly: 주 1회 정도 인스턴스를 잡고 GPU-burn이나 NCCL all-reduce 같은 하드한 테스트 수행.

이건 SRE 관점에서 매우 타당한 트레이드오프입니다. 99.9%의 확률로 정상일 하드웨어를 검증하느라 고객의 대기 시간(Latency)을 늘리는 건 바보 같은 짓이니까요. 문제가 생기면 그때 해당 노드를 격리(Drain)하고 죽이는 게 훨씬 효율적입니다.

4. GPU는 ‘화장지’다?

이 글과 관련된 Hacker News의 반응 중 흥미로운 시각이 있어 소개합니다.

“GPU는 결국 화장지처럼 쓰고 버려지는 소모품이다. 지금의 GPU-as-a-Service 모델이 지속 가능한지 의문이다.”

Meta의 Llama 3 논문에 따르면, 학습 중 발생한 예상치 못한 문제의 58.7%가 GPU 이슈 였다고 합니다. CPU 관련 이슈는 고작 0.5%였습니다. 엔비디아의 하드웨어는 성능 면에서 경이롭지만, 신뢰성 면에서는 여전히 갈 길 멉니다.

GPU는 감가상각이 엄청나게 빠르고, 고장률도 높습니다. Modal 같은 중간 사업자(Reseller)들이 이 복잡성을 추상화해주지 않는다면, 개별 기업이 직접 베어메탈(Bare Metal)을 관리하는 건 엄청난 리소스 낭비가 될 겁니다. “Cloud D”의 잦은 ECC 에러를 직접 디버깅하고 싶으신가요? 저는 사양하겠습니다.

결론: 인프라의 추상화가 필요한 이유

Modal의 이번 포스팅은 “왜 우리가 비싼 돈을 주고 매니지드 서비스를 써야 하는가”에 대한 가장 기술적인 답변입니다. 단순히 서버를 띄워주는 게 아니라, 지뢰밭 같은 하드웨어 품질을 소프트웨어로 평탄화 해주는 것이 그들의 진짜 가치이기 때문입니다.

만약 여러분이 직접 대규모 GPU 클러스터를 구축할 계획이라면, 다음 세 가지를 꼭 명심하십시오.

1. 클라우드 제공사의 SLA 를 맹신하지 마십시오. 그들은 90도 찍는 GPU를 정상이라고 줄 수도 있습니다.
2. Machine Image 빌드 파이프라인에 DCGM 테스트를 반드시 포함하십시오.
3. Xid 에러 로그를 수집하고, 특정 패턴이 보이면 즉시 노드를 킬(Kill)하는 자동화를 만드십시오.

그게 귀찮다면? 그냥 Modal 같은 서비스를 쓰는 게 정신 건강에 이로울 겁니다.