네오클라우드가 판매하는 것은 GPU 한 장이 아니라 작업의 완료입니다. 분산 작업이 시작되고, 데이터를 공급받고, 통신하고, 장애를 견디며, 예상한 비용과 시간 안에 끝나야 합니다. 공개 자료가 이 전체 경로를 한 번에 측정하는 경우는 드뭅니다. 어떤 사업자는 정상 네트워크 링크 비율을 말하고, 다른 곳은 fio 스토리지 처리량을 공개하며, 고객 클러스터의 평균 장애 간격을 제시하거나 비교 가능한 수치 없이 오케스트레이션 기능을 설명하기도 합니다. 이 값을 하나의 순위표에 넣으면 숫자는 정밀해 보이지만 비교는 부정확해집니다.
CoreWeave, Nebius, Lambda가 2025년에 공개한 자료는 서로 다른 근거 유형을 보여 줍니다. CoreWeave는 네트워크와 스토리지의 상세한 공학 수치와 재현 가능한 시험 구성을 제공합니다[1][2]. Nebius는 고객 클러스터의 신뢰성과 복구 값을 공개하면서 적용 범위의 한계도 밝힙니다[3]. Lambda는 전용 멀티클라우드 GPU 클러스터의 아키텍처와 운영 인터페이스를 설명하지만 해당 문서에는 직접 비교할 수 있는 성능·신뢰성 수치가 적습니다[4]. 따라서 사업자 이름보다 각 자료가 입증한 범위와 구매 전 추가로 확인할 값을 구분해야 합니다.
CoreWeave: 구성 요소 텔레메트리와 조건을 밝힌 스토리지 시험
CoreWeave는 수백만 개 InfiniBand 링크를 운영하며 특정 시점에 95% 이상의 유효 처리량을 낼 수 있는 링크의 비중으로 “99.9975”를 제시합니다[1]. 문맥상 백분율로 보이지만 공개 페이지에는 99.9975 뒤에 % 기호나 다른 단위가 인쇄돼 있지 않습니다. 네트워크 스택은 NVIDIA Quantum-2 InfiniBand, SHARP, SHIELD를 사용하고 8개 NDR 연결을 가진 노드는 가속기 쪽으로 3.2 Tb/s를 제공합니다. 이 값은 회사가 보고한 장비군 텔레메트리입니다. 공개 글에는 관측 기간, 표본 분포, 고장 링크 처리 방식, 애플리케이션 집합 통신도 같은 유효 처리량을 내는지가 정의돼 있지 않습니다. 운영 지표를 보유하고 있다는 근거이지 독립적인 종단 간 벤치마크는 아닙니다.
스토리지 글은 방법을 더 자세히 공개합니다. H200 노드에서 CPU 기반 fio를 실행했고, 스토리지 트래픽은 dual 100 Gb/s BlueField-3 링크로 보내 학습용 InfiniBand 패브릭과 분리했습니다[2]. 64 노드, GPU 512장 시험에서 합산 read가 약 500 GiB/s를 넘었고 노드당 7.94 GiB/s를 유지해 GPU당 1 GiB/s라는 설계 목표에 가까웠습니다. 구성과 script가 공개돼 단순한 제품 주장보다 재현 가능성이 높습니다.
한계도 분명합니다. 실제 학습에서 관측한 접근 패턴을 모사했지만 GPU Direct 스토리지를 사용하지 않았고, fio 대역폭은 모델 학습의 유효 처리량, 메타데이터가 많은 데이터셋, 패브릭 장애와 겹친 체크포인트 복구를 측정하지 않습니다. 명시한 조건의 스토리지 데이터 경로만 입증한 시험입니다.
Nebius: 고객 작업부하와 적용 범위의 경고
Nebius는 익명 고객의 GPU 3,000장, 375 노드 운영 환경 클러스터를 공개했습니다[3]. 인프라 장애 사이의 실제 경과 시간으로 측정한 MTBF 최고값은 56.6시간이고, GPU 시간으로 표현하면 169,800입니다. 그 이전 수 주간 평균은 33.0시간이었습니다. 대부분의 설치 환경에서 평균 복구 시간(MTTR)은 12분이라고 보고합니다.
단위를 주의해서 읽어야 합니다. 56.6시간에 GPU 3,000장을 곱하면 169,800 GPU 시간이 됩니다. 같은 장애 간격을 두 방식으로 표현한 것이지 서로 다른 두 성과가 아닙니다. 최고값과 수 주 평균도 다른 통계입니다. Nebius의 글은 한 환경의 결과를 모든 클러스터에 일반화할 수 없다고 직접 경고합니다. 이 문구는 수치를 약하게 만들기보다 작업부하 경계를 알려 줘 근거를 더 쓸모 있게 합니다.
그 뒤의 운영 방식으로 다단계 인수 시험, 능동·수동 health check, 작업부하 격리와 이동, 자동 노드 교체, 상태 복구, 전체 경로 관측을 설명합니다. 공개되지 않은 부분은 사건별 분포, 장애 유형, 작업부하 유효 처리량, 고객 측 체크포인트 손실입니다. MTBF와 MTTR은 중요한 조각이지만 유효 학습 시간에는 검출 지연과 재시작 때 잃은 작업량도 들어갑니다.
Lambda: 벤치마크보다 운영 청사진
Lambda의 2025년 12월 멀티클라우드 청사진은 전용 bare-metal GPU 클러스터, 낮은 지연의 네트워크, S3 호환 스토리지, 관리형 또는 자체 관리 Kubernetes, 주요 클라우드 interconnect, Prometheus 기반 관측을 설명합니다[4]. Lambda 안팎으로 데이터를 옮길 때 ingress와 외부 전송 요금이 없다는 상업 조건도 제시합니다. AWS, Azure, Google 클라우드, Oracle 클라우드 사이의 이식성을 강조한 기능·아키텍처 문서입니다.
이 문서에는 Nebius 고객 사례와 비교할 클러스터 MTBF 분포나 CoreWeave fio 시험에 맞출 multi-node 스토리지 곡선이 없습니다. 이를 성능이 더 낮다는 주장으로 바꾸면 안 됩니다. 근거의 상태가 다르다는 뜻입니다. 문서로 인터페이스, 격리, 상업 조건을 확인할 수 있고, 지속 집합 통신 유효 처리량, 복구 동작, 스토리지 확장성은 벤치마크, SLO, 고객 작업부하 기록으로 추가 검증해야 합니다.
잘못된 비교를 막는 네 가지 기준
인프라 수치에는 최소 네 가지 조건이 필요합니다. 측정 대상은 링크, 스토리지 노드, 작업, 클러스터, 장비군 중 무엇인지 알려 줍니다. 작업부하는 합성, 실제 추적 기록 기반, 고객 운영 환경, 미공개를 구분합니다. 분모에는 규모와 기간이 들어갑니다. 근거 유형은 재현 가능한 측정, 사업자 텔레메트리, 고객 보고, 모델 투영, 기능 주장으로 나눕니다.
이 조건을 붙이면 서로 다른 자료를 잘못 경쟁시키지 않을 수 있습니다. CoreWeave가 보고한 99.9975 링크 준비 상태 값과 Nebius의 최고 MTBF 56.6시간은 비교할 수 없습니다. 하나는 특정 시점의 링크 상태를 보고 다른 하나는 작업에 영향을 주는 인프라 사건 사이 시간을 셉니다. CoreWeave의 약 500 GiB/s에는 64 노드 fio라는 분모가 있고, Lambda의 S3 호환 스토리지는 인터페이스를 입증할 뿐 처리량을 정하지 않습니다. 모두 정당하지만 더 좁은 질문의 답입니다.
GPU 사용 시간을 계약하기 전에 요청할 시험
구매 평가는 구성 요소에서 완료한 작업까지 연결해야 합니다. 실제 고객 모델이나 대표 집합 통신을 원하는 규모에서 실행하고, 깨끗한 한 시간의 최고값 대신 며칠 동안 p50과 꼬리 유효 처리량을 기록해야 합니다. 노드, 링크, 스토리지 장애를 주입하거나 실제 사건을 관찰해 검출, 장비 교체, 통신 재구성, 체크포인트 재적재, 잃은 단계 시간을 나눠 보고합니다. 물리 자원이 정상이어도 스케줄러가 토폴로지에 맞는 예비 장비를 붙이지 못하면 작업은 복구되지 않으므로 물리 가용성과 스케줄링 가용성도 구분해야 합니다.
스토리지는 학습 통신과 체크포인트 집중 쓰기가 동시에 있을 때 시험해야 합니다. 네트워크 결과에는 경로 다양성, 성능 저하 상태의 처리량, 목표 집합 통신 대역폭 아래에 머문 시간 비율이 필요합니다. 상업적 이식성은 산출물과 오케스트레이션을 클라우드 사이에서 실제로 옮겨 보고, 걸린 시간과 외부 전송 정책이 덮지 않는 모든 비용까지 확인해야 합니다.
공개 자료만으로 세 사업자의 우열을 정할 수는 없습니다. CoreWeave는 구성 요소 수준의 설계와 측정 조건을, Nebius는 고객 클러스터의 신뢰성 간격을, Lambda는 스택의 이식성 구조를 보여 줍니다. 각 자료에서 확인할 수 없는 항목이 서로 다르므로, 구매자는 이를 별도 검증 계획으로 만들어야 합니다.
공개 근거를 완료한 작업의 가격으로 바꾸기
구성 요소 근거는 구매 단위를 바꿀 때 상업적으로 쓸모가 생깁니다. GPU시간 가격은 임대한 모든 시간이 같은 진척을 만든다고 가정합니다. 공개된 네트워크, 스토리지, 신뢰성 자료는 이 가정이 왜 틀릴 수 있는지 보여 줍니다. 구매자가 실제로 원하는 것은 승인된 학습 스텝, SLO 안에서 생성한 토큰, 완료한 체크포인트입니다. 집합 통신의 유효 처리량이 흔들리고 장애가 긴 작업 구간을 지우거나 스토리지가 매 체크포인트 정지를 늘리면 낮은 시간당 가격이 오히려 비싸질 수 있습니다.
외부 산업 분석도 비용 측면에서 같은 결론에 도달합니다. SemiAnalysis는 연구 목표를 달성하는 데 걸리는 시간과 유효 처리량을 반영한 클러스터 비용을 제안하고, The Next Platform은 단순 GPU시간 대신 실제로 완료한 학습 진도를 비교해야 한다고 설명합니다[5][6]. 이 자료들이 여기서 검토한 사업자 수치를 독립적으로 검증하는 것은 아닙니다. 다만 설정, 간섭, 장애, 복구 비용을 제외한 시간당 가격만으로는 구매 판단을 내릴 수 없다는 점은 분명해집니다.
실무 지표는 완료한 작업 단위당 위험 조정 비용입니다. 분자에는 임대료, 예약했지만 쓰지 못한 용량, 데이터 이동, 재시작으로 반복한 연산, 엔지니어 개입 비용이 들어갑니다. 분모에서는 작업부하가 정한 허용 기준 아래의 시간을 제외합니다. 검토한 사업자 공개 자료는 이 식의 일부 항목을 채우지만 어느 문서도 전체를 완성하지 않습니다. 공개 숫자로 사업자 순위를 만들 수 없는 분석적 이유는 빠진 변수가 결과를 지배하기 때문입니다.
따라서 구매 시험의 최종 산출물은 고객이 소유하는 근거 묶음이어야 합니다. 작업부하 구성, 소프트웨어 버전, 토폴로지, 백분위별 유효 처리량, 사건 기록, 체크포인트와 복원 시간 분포, 가용성 계산에서 제외한 조건을 함께 남깁니다. 하드웨어나 소프트웨어가 바뀔 때 같은 묶음을 다시 실행하면 영업용 벤치마크가 운영 기준선으로 바뀝니다. 네오클라우드는 가장 유리한 숫자 하나보다 이 근거 묶음의 완전성으로 경쟁할 때 비로소 비교 가능한 시장이 됩니다.
계약도 같은 근거 경계를 따라야 합니다. 노드 가용성 SLO는 정상적인 토폴로지를 얻지 못해 분산 작업이 시작되지 않은 고객을 보상하지 않습니다. 네트워크 가동 시간이 정상이어도 집합 통신 유효 처리량이 학습 계획 아래에 머물 수 있습니다. 스토리지 가용성이 정상이어도 체크포인트 꼬리가 유효 가속기 시간을 지울 수 있습니다. 구매자는 작업 시작 실패, 지속적인 집합 통신 하한, 체크포인트 완료, 복구 시간에 연결된 작업부하 관점의 서비스 지표와 보상 조건을 요구해야 합니다. 구성 요소 지표는 진단에 필요하지만 상업적 약속의 끝은 완료한 작업이어야 합니다.
영구적인 순위보다 시간에 따른 비교가 중요합니다. 하드웨어 세대, 펌웨어, 배치 압력, 고객 구성은 구매 주기보다 빨리 바뀝니다. 한 번 강한 벤치마크를 공개한 사업자가 장비가 더 빽빽하게 쓰일 때도 결과를 유지한다는 보장은 없고, 공개 근거가 약했던 운영자가 빠르게 나아질 수도 있습니다. 고객은 시험을 보관하고 증설, 갱신, 큰 소프트웨어 전환 때 다시 실행해야 합니다. 날짜, 버전, 토폴로지, 부하 조건이 없는 결과는 네오클라우드의 지속적인 속성이 아닙니다. 언제 만료될지 모르는 한 시점의 관측입니다.
구매 단계가 깊어질수록 근거도 강해져야 할 이유
초기 아키텍처 선택은 기능의 존재를 확인하는 구성 요소 자료로 시작할 수 있습니다. 용량 예약에는 실제 작업 재생이 필요하고, 장기 계약에는 유지보수와 장애, 성능 변화가 포함된 운영 근거가 필요합니다. 같은 공급사 숫자를 세 단계에 반복해서 쓰면 근거보다 정밀한 결론을 만들게 됩니다.
근거를 네 단계로 나눌 수 있습니다. 먼저 GPU, 호스트, 메모리, 패브릭, 스토리지, 토폴로지, 소프트웨어 버전을 확인합니다. 다음으로 동시성과 데이터 배치를 명시한 구성 요소 시험을 재현합니다. 셋째로 품질과 SLO를 붙인 구매자 작업을 실행합니다. 마지막으로 유지보수와 장애를 거쳐 반복 실행한 기록을 봅니다. 발표 자료에 여러 번 인용됐다는 이유로 근거 단계가 올라가지는 않습니다.
벤치마크를 계약 안에 남겨야 할 이유
구매 전 시험과 실제 배정 구성이 다를 수 있다면 결과의 가치는 제한적입니다. 계약에는 허용할 GPU와 호스트 세대, 비과가입 패브릭, 스토리지 동작, 배치 범위, 소프트웨어 이미지, 정기 검증 작업을 남겨야 합니다. 대체 부품을 허용할 때는 같은 부품 이름보다 완료 작업 비용이 동등함을 보여 줘야 합니다.
반복 카나리는 펌웨어, 드라이버, 집합 통신 라이브러리, 스케줄러 정책, 다른 고객의 부하 변화를 큰 작업 전에 찾을 수 있습니다. 평균뿐 아니라 분포를 기록해야 느린 랭크 몇 개가 동기식 단계 전체를 늦추는 문제를 볼 수 있습니다. 성능 저하 시 작업을 멈출 기준, 대체 용량의 지역성, 재실행 비용도 계약에 포함해야 합니다.
가속기 시간이 아니라 완료한 작업을 가격화해야 할 이유
시간당 GPU 가격에는 확장 손실, 큐 대기, 체크포인트와 재시작, 데이터 이동, 반복 실행 가능성이 빠져 있습니다. 품질과 지연 목표를 만족한 학습 단계나 추론 작업을 분모로 두고, 토폴로지 단편화 때문에 예약했지만 쓸 수 없는 장치도 비용에 넣어야 합니다.
네오클라우드라는 분류 자체는 기술 변수가 아닙니다. 공개 근거는 경쟁 가능한 대안이 존재함을 보여 주지만 하나의 표로 순위를 확정하기에는 부족합니다. 공개 자료로 시험을 만들고, 시험으로 계약을 쓰며, 반복 근거로 약속을 확인하는 과정이 필요합니다. 실제로 신뢰할 수 있는 플랫폼은 장치나 링크가 계획대로 움직이지 않는 날까지 포함해 목표 작업을 약속한 비용으로 끝내야 합니다.
출처와 저작권 안내
이 글은 Silicon & Systems가 2025년에 공개된 사업자 자료를 바탕으로 독자적으로 작성한 분석입니다. 회사가 보고한 수치는 그 사실을 표시했고 서로 다른 지표를 하나의 순위로 환산하지 않았습니다. 원문의 문장, 표, 로고, 도판은 옮기지 않았으며 본문의 두 도판은 새로 만들었습니다. 원문은 CoreWeave의 네트워크 글과 스토리지 벤치마크, Nebius의 클러스터 신뢰성 보고, Lambda의 멀티클라우드 청사진입니다. 저작권은 각 발행자에게 있습니다.