네오클라우드가 판매하는 것은 GPU 한 장이 아니라 작업의 완료다. 분산 작업이 시작되고, 데이터를 공급받고, 통신하고, 장애를 견디며, 예상한 비용과 시간 안에 끝나야 한다. 공개 자료가 이 전체 경로를 한 번에 측정하는 경우는 드물다. 어떤 사업자는 정상 network link 비율을 말하고, 다른 곳은 fio storage 처리량을 공개하며, 고객 cluster의 평균 장애 간격을 제시하거나 비교 가능한 수치 없이 orchestration 기능을 설명하기도 한다. 이 값을 하나의 순위표에 넣으면 숫자는 정밀해 보이지만 비교는 부정확해진다.
CoreWeave, Nebius, Lambda가 2025년에 공개한 자료는 서로 다른 근거 유형을 보여 준다. CoreWeave는 network와 storage의 상세한 engineering 수치와 재현 가능한 시험 구성을 제공한다[1][2]. Nebius는 고객 cluster의 신뢰성과 복구 값을 공개하면서 적용 범위의 한계도 밝힌다[3]. Lambda는 전용 multi-cloud GPU cluster의 architecture와 운영 interface를 설명하지만 해당 문서에는 직접 비교할 수 있는 성능·신뢰성 수치가 적다[4]. 여기서는 사업자의 우열이 아니라 각 자료가 무엇을 입증하고 구매자가 무엇을 더 확인해야 하는지 살펴본다.
CoreWeave: 구성 요소 telemetry와 조건을 밝힌 storage 시험
CoreWeave는 수백만 개 InfiniBand link를 운영하며 특정 시점에 95% 이상의 goodput을 낼 수 있는 link의 비중으로 “99.9975”를 제시한다[1]. 문맥상 백분율로 보이지만 공개 페이지에는 99.9975 뒤에 % 기호나 다른 단위가 인쇄돼 있지 않다. network stack은 NVIDIA Quantum-2 InfiniBand, SHARP, SHIELD를 사용하고 8개 NDR 연결을 가진 node는 가속기 쪽으로 3.2 Tb/s를 제공한다. 이 값은 회사가 보고한 fleet telemetry다. 공개 글에는 관측 기간, 표본 분포, 고장 link 처리 방식, application collective도 같은 goodput을 내는지가 정의돼 있지 않다. 운영 metric을 보유하고 있다는 근거이지 독립적인 end-to-end benchmark는 아니다.
storage 글은 방법을 더 자세히 공개한다. H200 node에서 CPU 기반 fio를 실행했고, storage traffic은 dual 100 Gb/s BlueField-3 link로 보내 학습용 InfiniBand fabric과 분리했다[2]. 64 node, GPU 512장 시험에서 합산 read가 약 500 GiB/s를 넘었고 node당 7.94 GiB/s를 유지해 GPU당 1 GiB/s라는 설계 목표에 가까웠다. 구성과 script가 공개돼 단순한 제품 주장보다 재현 가능성이 높다.
한계도 분명하다. 실제 학습에서 관측한 접근 pattern을 모사했지만 GPU Direct Storage를 사용하지 않았고, fio 대역폭은 모델 학습 goodput, metadata가 많은 dataset, fabric 장애와 겹친 checkpoint 복구를 측정하지 않는다. 명시한 조건의 storage data path를 입증한 시험이다.
Nebius: 고객 workload와 적용 범위의 경고
Nebius는 익명 고객의 GPU 3,000장, 375 node production cluster를 공개했다[3]. infrastructure 장애 사이의 wall-clock 시간인 MTBF 최고값은 56.6시간이고, GPU-hour로 표현하면 169,800이다. 그 이전 수 주간 평균은 33.0시간이었다. 대부분의 설치 환경에서 평균 복구 시간(MTTR)은 12분이라고 보고한다.
단위를 주의해서 읽어야 한다. 56.6시간에 GPU 3,000장을 곱하면 169,800 GPU-hour가 된다. 같은 장애 간격을 두 방식으로 표현한 것이지 서로 다른 두 성과가 아니다. 최고값과 수 주 평균도 다른 통계다. Nebius의 글은 한 환경의 결과를 모든 cluster에 일반화할 수 없다고 직접 경고한다. 이 문구는 수치를 약하게 만들기보다 workload 경계를 알려 줘 근거를 더 쓸모 있게 한다.
그 뒤의 운영 방식으로 다단계 인수 시험, 능동·수동 health check, workload 격리와 이동, 자동 node 교체, 상태 복구, 전체 경로 관측을 설명한다. 공개되지 않은 부분은 사건별 분포, 장애 유형, workload goodput, 고객 측 checkpoint 손실이다. MTBF와 MTTR은 중요한 조각이지만 유효 학습 시간에는 검출 지연과 재시작 때 잃은 작업량도 들어간다.
Lambda: benchmark보다 운영 청사진
Lambda의 2025년 12월 multi-cloud 청사진은 전용 bare-metal GPU cluster, 낮은 지연의 network, S3 호환 storage, 관리형 또는 자체 관리 Kubernetes, 주요 cloud interconnect, Prometheus 기반 관측을 설명한다[4]. Lambda 안팎으로 데이터를 옮길 때 ingress와 egress 요금이 없다는 상업 조건도 제시한다. AWS, Azure, Google Cloud, Oracle Cloud 사이의 이식성을 강조한 기능·architecture 문서다.
이 문서에는 Nebius 고객 사례와 비교할 cluster MTBF 분포나 CoreWeave fio 시험에 맞출 multi-node storage 곡선이 없다. 이를 성능이 더 낮다는 주장으로 바꾸면 안 된다. 근거의 상태가 다르다는 뜻이다. 문서로 interface, 격리, 상업 조건을 확인할 수 있고, 지속 collective goodput, 복구 동작, storage 확장성은 benchmark, SLO, 고객 workload 기록으로 추가 검증해야 한다.
잘못된 비교를 막는 네 개의 표지
인프라 수치에는 최소 네 표지가 필요하다. 측정 대상은 link, storage node, job, cluster, fleet 중 무엇인지 알려 준다. workload는 합성, 실제 trace 기반, 고객 production, 미공개를 구분한다. 분모에는 규모와 기간이 들어간다. 근거 유형은 재현 가능한 측정, 사업자 telemetry, 고객 보고, model 투영, 기능 주장으로 나눈다.
이 표지를 붙이면 자료가 잘못 경쟁하지 않는다. CoreWeave가 보고한 99.9975 link readiness 값과 Nebius의 peak MTBF 56.6시간은 비교할 수 없다. 하나는 특정 시점의 link 상태를 보고 다른 하나는 작업에 영향을 주는 infrastructure 사건 사이 시간을 센다. CoreWeave의 약 500 GiB/s에는 64 node fio라는 분모가 있고, Lambda의 S3 호환 storage는 interface를 입증할 뿐 처리량을 정하지 않는다. 모두 정당하지만 더 좁은 질문의 답이다.
cluster-hour를 사기 전에 요청할 시험
구매 평가는 구성 요소에서 완료한 작업까지 연결해야 한다. 실제 고객 모델이나 대표 collective를 원하는 규모에서 실행하고, 깨끗한 한 시간의 최고값 대신 며칠 동안 p50과 꼬리 goodput을 기록해야 한다. node, link, storage 장애를 주입하거나 실제 사건을 관찰해 검출, 장비 교체, 통신 재구성, checkpoint 재적재, 잃은 step 시간을 나눠 보고한다. 물리 자원이 정상이어도 scheduler가 topology에 맞는 spare를 붙이지 못하면 작업은 복구되지 않으므로 물리 availability와 scheduling availability도 구분해야 한다.
storage는 학습 통신과 checkpoint burst가 동시에 있을 때 시험해야 한다. network 결과에는 경로 다양성, 성능 저하 상태의 처리량, 목표 collective 대역폭 아래에 머문 시간 비율이 필요하다. 상업적 이식성은 artifact와 orchestration을 cloud 사이에서 실제로 옮겨 보고, 걸린 시간과 egress 정책이 덮지 않는 모든 비용까지 확인해야 한다.
공정한 결론은 어느 네오클라우드가 이겼다는 것이 아니다. CoreWeave는 구성 요소 engineering의 깊이를, Nebius는 고객 신뢰성 간격을, Lambda는 stack의 이식성 계약을 보여 준다. 빠진 근거가 서로 다르다. 기술적으로 진지한 구매자는 그 빈칸을 marketing 비교로 채우지 않고 검증 계획으로 바꾼다.
공개 근거를 완료한 작업의 가격으로 바꾸기
구성 요소 근거는 구매 단위를 바꿀 때 상업적으로 쓸모가 생긴다. GPU시간 가격은 임대한 모든 시간이 같은 진척을 만든다고 가정한다. 공개된 네트워크, 스토리지, 신뢰성 자료는 이 가정이 왜 틀릴 수 있는지 보여 준다. 구매자가 실제로 원하는 것은 승인된 학습 스텝, SLO 안에서 생성한 토큰, 완료한 체크포인트다. 집합 통신의 유효 처리량이 흔들리고 장애가 긴 작업 구간을 지우거나 스토리지가 매 체크포인트 정지를 늘리면 낮은 시간당 가격이 오히려 비싸질 수 있다.
실무 지표는 완료한 작업 단위당 위험 조정 비용이다. 분자에는 임대료, 예약했지만 쓰지 못한 용량, 데이터 이동, 재시작으로 반복한 연산, 엔지니어 개입 비용이 들어간다. 분모에서는 워크로드가 정한 허용 기준 아래의 시간을 제외한다. 검토한 사업자 공개 자료는 이 식의 일부 항목을 채우지만 어느 문서도 전체를 완성하지 않는다. 공개 숫자로 사업자 순위를 만들 수 없는 분석적 이유는 빠진 변수가 결과를 지배하기 때문이다.
따라서 구매 시험의 최종 산출물은 고객이 소유하는 근거 묶음이어야 한다. 워크로드 구성, 소프트웨어 버전, 토폴로지, 백분위별 유효 처리량, 사건 기록, 체크포인트와 복원 시간 분포, 가용성 계산에서 제외한 조건을 함께 남긴다. 하드웨어나 소프트웨어가 바뀔 때 같은 묶음을 다시 실행하면 영업용 벤치마크가 운영 기준선으로 바뀐다. 네오클라우드는 가장 유리한 숫자 하나보다 이 근거 묶음의 완전성으로 경쟁할 때 비로소 비교 가능한 시장이 된다.
계약도 같은 근거 경계를 따라야 한다. 노드 가용성 SLO는 정상적인 토폴로지를 얻지 못해 분산 작업이 시작되지 않은 고객을 보상하지 않는다. 네트워크 가동 시간이 정상이어도 집합 통신 유효 처리량이 학습 계획 아래에 머물 수 있다. 스토리지 가용성이 정상이어도 체크포인트 꼬리가 유효 가속기 시간을 지울 수 있다. 구매자는 작업 시작 실패, 지속적인 집합 통신 하한, 체크포인트 완료, 복구 시간에 연결된 워크로드 관점의 서비스 지표와 보상 조건을 요구해야 한다. 구성 요소 지표는 진단에 필요하지만 상업적 약속의 끝은 완료한 작업이어야 한다.
영구적인 순위보다 시간에 따른 비교가 중요하다. 하드웨어 세대, 펌웨어, 배치 압력, 고객 구성은 구매 주기보다 빨리 바뀐다. 한 번 강한 벤치마크를 공개한 사업자가 장비가 더 빽빽하게 쓰일 때도 결과를 유지한다는 보장은 없고, 공개 근거가 약했던 운영자가 빠르게 나아질 수도 있다. 고객은 시험을 보관하고 증설, 갱신, 큰 소프트웨어 전환 때 다시 실행해야 한다. 날짜, 버전, 토폴로지, 부하 조건이 없는 결과는 네오클라우드의 지속적인 속성이 아니다. 언제 만료될지 모르는 한 시점의 관측이다.
출처와 저작권 안내
이 글은 Silicon & Systems가 2025년에 공개된 사업자 자료를 바탕으로 독자적으로 작성한 분석이다. 회사가 보고한 수치는 그 사실을 표시했고 서로 다른 metric을 하나의 순위로 환산하지 않았다. 원문의 문장, 표, logo, 도판은 옮기지 않았으며 본문의 두 도판은 새로 만들었다. 원문은 CoreWeave의 network 글과 storage benchmark, Nebius의 cluster reliability 보고, Lambda의 multi-cloud 청사진이다. 저작권은 각 발행자에게 있다.