어떤 GPU 클라우드가 실제로 좋은가? (ClusterMAX 3.0)

URL: https://www.youtube.com/watch?v=MWX36ZYnsm0 날짜: 2026-10-02 채널: latentspacepod 원문 제목: Which GPU Clouds Are Actually Good? | ClusterMAX 3.0

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==GPU 클라우드의 품질은 GPU 모델이나 시간당 가격이 아니라, 고장 격리·네트워크 성능·스토리지·보안·운영 소프트웨어를 고객이 즉시 쓸 수 있는 수준으로 제공하는지로 판별해야 한다.==

• ClusterMAX 3.0은 관리형 GPU 클러스터 77곳을 직접 시험하고, 시장 전체 323개 사업자를 추적하며, 200명이 넘는 실제 사용자를 인터뷰했다.
• CoreWeave와 Nebius가 Platinum, Oracle과 Google Cloud가 Gold에 올랐고, Azure는 Silver로 내려갔으며, AWS와 Crusoe는 Bronze로 내려갔다.
• GPU 공급 부족으로 망가진 Kubernetes나 부실한 스토리지를 가진 사업자도 높은 마진으로 칩을 팔 수 있지만, 고객이 실제로 사야 할 것은 고장 없는 운영 경험과 계약상 복구 수단이다.
• 운영자는 자동 health check, XID 장애 주입, NCCL golden recipe, 캐시 적중률, 테넌트 격리, 최신 보안 패치, 명확한 SLA를 직접 검증해야 한다.

관리형 클러스터는 연구팀이 운영체제·스케줄러·네트워크·스토리지와 씨름하지 않고 모델 구조, 데이터, 학습 전략과 제품에 집중하도록 만드는 서비스다. 그러나 단순히 최신 GPU를 확보하고 Slurm·Kubernetes를 설치하는 것만으로는 충분하지 않다. 고장 난 GPU가 학습에 섞이지 않게 격리하고, 노드와 랙을 신속히 교체하며, 네트워크와 스토리지가 GPU 성능을 가리지 않게 하고, 공격자가 클러스터를 장악할 경로를 막아야 한다. ClusterMAX의 핵심 가치는 이 운영 품질을 가격표가 아니라 실제 장애와 워크로드로 측정하는 데 있다.

1. ClusterMAX 3.0의 범위와 순위 변화

GPU를 보유했다는 사실이 클라우드 사업자의 품질을 보증하지 않으며, 관리형 운영 계층이 실제 구매 결정의 기준이 되어야 한다.

1.1. 조사 범위와 출발점

1. 세 달간의 실전 테스트

   1. Sam Harshe는 테스트가 끝날 때까지 햇빛을 거의 보지 못했고, Kubernetes와 Slurm을 다뤄 온 여러 생애 분량의 경험을 쌓았다고 농담했다.
   2. Pratt Bhatt는 대규모 인프라를 만지는 일 자체가 즐거웠다고 말했다.
   3. ClusterMAX 3.0은 컴퓨트·네트워크·스토리지·오케스트레이션·UI·모니터링·지원까지 클라우드 경험의 거의 모든 층을 확인한다.

2. 측정 대상의 정의

   1. 평가는 관리형 클러스터(managed cluster)에 초점을 둔다. 가장 깔끔한 데이터센터나 가장 강력한 bare metal 셸을 만드는 능력만을 직접 순위 매기지는 않는다.
   2. 고객은 Ubuntu 버전, NAT, 클러스터 규모별 운영법을 직접 익히지 않고도 최신 하드웨어를 써야 한다. 인프라는 배경으로 사라지고, 고객은 모델 구조·데이터 혼합·학습 전략·애플리케이션의 차별화에 시간을 써야 한다.
   3. 네오클라우드는 대규모 플릿에 관리 인프라 비용을 분산해, 최신 이미지·자동화된 health check·모니터링·장애 대응을 제공하고 그에 대한 마진을 받아야 한다.
   4. OpenAI나 Anthropic처럼 수천 개 가속기의 토폴로지에 맞춰 스케줄러와 Kubernetes control plane 자체를 공동 설계해야 하는 프런티어 랩은 완제품 관리형 클러스터만으로는 부족하다. 이런 규모가 아니라면 네오클라우드가 무거운 운영을 대신해야 한다.

1.2. 77개 평가 결과와 순위 이동

1. 상위권 재편

   1. Platinum에는 기존 CoreWeave에 Nebius가 합류했다.
   2. Gold에는 Oracle과 Google Cloud가 자리 잡았고, Google Cloud가 새로 합류했다.
   3. Silver에서는 Azure가 내려왔고, Firmus와 Lambda는 유지했으며, GMI는 올라갔고, TensorWave는 유지했다.
   4. Bronze에서는 AWS와 Crusoe가 함께 내려갔다.

2. 조사 규모의 확대

   1. 직접 순위를 매긴 사업자는 77곳이다.
   2. 전체 네오클라우드 시장 추적 범위는 ClusterMAX 2.0의 209곳에서 323곳으로 확대됐다.
   3. 실제 네오클라우드 사용자 인터뷰는 200명을 훨씬 넘었다.
   4. 이번 판에서는 기준을 높여 Medallion 등급을 받은 네오클라우드가 전 세계 19곳뿐이다.
   5. Bronze와 Underperforming 사이에 Participation Ribbon 등급을 새로 만들었고, 15개 사업자가 최소한의 운영만 하는 범주로 분류됐다.

1.3. GPU 부족이 만든 가격 왜곡

1. 현재 가격 곡선의 backwardation

   1. 고객은 몇 주 안에 받을 수 있는 칩이라면 거의 어떤 가격도 지불하려 한다.
   2. 몇 달 기다릴 수 있는 고객은 큰 할인을 받을 수 있다.
   3. 칩을 가진 사업자는 Kubernetes가 vibe-coded 상태로 망가졌거나 스토리지가 간신히 작동해도 높은 마진으로 GPU를 팔 수 있다.
   4. 과거에는 초기에 장비를 팔지 못한 사업자가 낮은 품질의 신호를 보냈지만, 공급 부족이 심해진 뒤에는 그 사업자도 훨씬 좋은 조건으로 계약을 체결한다.

2. 운영 품질과 시장 착시

   1. GPU를 확보한 것만으로도 업계 모두가 천재처럼 보이는 시기가 만들어졌다.
   2. 단기 계약의 수요가 부실한 운영 계층을 가려 버리므로, 가격과 납기만으로 사업자를 선택하면 실제 비용과 다운타임을 뒤늦게 떠안는다.

2. 네오클라우드의 확장과 관리형 클러스터의 기본기

네오클라우드의 다음 성장 영역은 관리형 클러스터 위에 호스팅 학습·추론·RL 인프라를 얹는 일이지만, 기본 클러스터 운영이 먼저 해결되어야 한다.

2.1. 왜 네오클라우드는 여러 제품을 동시에 내놓는가

1. 높은 컴퓨트 마진을 향한 확장

   1. SpaceX가 Google과 Anthropic을 비롯한 여러 네오랩에 좋은 컴퓨트를 제공하는 것처럼, 네오클라우드는 랩이 얻는 고마진 사업의 일부를 가져오려 한다.
   2. 관리형 클러스터는 전체 클러스터를 구성해야 하므로 어렵고 비용이 많이 든다.
   3. 사업자는 클러스터보다 위 계층으로 올라가 hosted training, managed inference, serverless inference endpoint, RL용 post-training 인프라, harness, sandbox를 판매하려 한다.
   4. 이런 움직임은 컴퓨트의 중앙집중화로 이어진다. 고객이 직접 모든 인프라를 운영하기보다, 자본과 운영 역량을 가진 몇몇 사업자가 여러 계층을 묶어 제공하는 방향이다.

2. 관리형 클러스터의 제품 로드맵

   1. 일부 사업자는 bare metal이나 추론 endpoint에 집중하면서 관리형 클러스터 순위에서 내려가거나 Unavailable이 됐다.
   2. 그러나 자체 추론을 운영하는 랩도 여전히 학습 클러스터를 필요로 한다.
   3. 고객이 원하는 것은 화려한 기능보다 bulletproof한 Slurm·Kubernetes와 제대로 작동하는 health check다.
   4. 관리형 클러스터 제공자는 기본기를 조금만 개선해도 GPU 시간당 가격에 몇 센트를 더 받을 수 있다.

2.2. 좋은 운영 경험을 만드는 내부 역량

1. 내부 사용자가 있는 사업자의 장점

   1. 내부 팀이 직접 클러스터를 사용하면 좋은 Slurm·Kubernetes 계층의 기준을 고객 피드백으로 구체화할 수 있다.
   2. health check의 배치와 장애 대응을 실제 사용자가 검증하므로 문서만 보고 만든 설정보다 신뢰성이 높다.
   3. 한 계층을 선택해 탁월하게 만드는 편이 여러 신제품을 성급하게 출시하는 것보다 낫다.

2. 프런티어 랩과 일반 랩의 경계

   1. OpenAI와 Anthropic은 기본값이 더 이상 작동하지 않는 규모에서 자체 scheduler, apiserver, etcd, controller, service discovery를 확장해야 한다.
   2. 이런 랩은 workload와 control plane을 동시에 공동 설계하므로, 좋은 Slinky 구현이라도 그대로 빌려 쓸 수 없다.
   3. 그 외의 랩은 관리형 클러스터를 통해 운영 인력을 절약하고, 하드웨어를 기다리는 시간보다 실험과 제품 개발에 집중하는 편이 합리적이다.

3. Health check와 장애 주입으로 측정하는 신뢰성

GPU 클라우드의 첫 번째 품질 기준은 GPU FLOPS가 아니라 고장 난 자원을 고객 작업에서 분리하는 능력이며, health check는 그 능력을 검증하는 자동화된 계약이다.

3.1. 능동형·수동형 health check

1. 능동형(active) 검사

   1. 클러스터에 다른 작업이 없을 때 실제 workload 또는 dummy workload를 실행한다.
   2. 대개 preemptible이며, 고객 학습 작업이 시작되면 검사 작업이 중단되고 실제 workload가 우선한다.
   3. GPU 계산, 메모리, 링크, 노드 상태처럼 실제 장애를 드러내는 동작을 반복해 조용한 하드웨어 고장을 잡는다.

2. 수동형(passive) 검사

   1. 고객 작업과 동시에 백그라운드에서 실행된다.
   2. 성능 오버헤드는 가능한 한 작아야 하며, CPU 로그를 읽는 것처럼 GPU 작업에 영향을 거의 주지 않는 방식도 가능하다.
   3. 정상 작업을 방해하지 않으면서 GPU·NIC·스토리지·노드의 이상 신호를 감시한다.

3.2. 설계 자체가 실행 가능한지 검증하기

1. 도식 검토만으로 잡히는 결함

   1. health check를 종이에 그렸을 때 실제로 작동할 가능성이 있어야 한다.
   2. 드문 race condition뿐 아니라 상태 전이의 모순도 확인해야 한다.
   3. 검사가 실행되려면 노드가 이미 healthy여야 하지만, 그 검사의 목적이 노드를 healthy로 되돌리는 것이라면 구조적으로 실행될 수 없다.

2. Amazon HyperPod Slurm 사례

   1. 첫 테스트에서 auto-remediation 단계의 health check가 노드가 이미 healthy 상태여야 실행되도록 구성돼 있었다.
   2. 노드를 플릿에 복귀시키기 위해 필요한 검사가 노드가 플릿에 복귀한 뒤에만 실행되는 자기모순이었다.
   3. 이런 사례가 테스트 전반에 다섯~열 개 정도 있었고, 잘못된 health check는 무검사보다 나쁘게 작업을 적극적으로 방해한다.

3.3. DCGM/XID 장애 주입과 복구 경로

1. 장애를 재현하는 기본 절차

   1. 필요한 권한이 있는 노드를 고른다.
   2. NVIDIA가 문서화한 DCGM injection 방식으로 실제 GPU 하드웨어 장애 때 나올 XID 메시지를 kernel ring buffer에 기록한다.
   3. 클러스터가 해당 메시지를 실제 장애와 똑같이 처리하는지 health check 경로를 관찰한다.
   4. 사업자 설정에 따라 다르지만, health check가 정상적으로 트리거되면 노드 격리·검증·자동 복구가 production과 같은 순서로 진행된다.

2. 정상적인 복구 시나리오

   1. 장애 노드는 즉시 quarantine되어 새 작업을 받지 않아야 한다.
   2. 수동형 검사가 노드 상태를 확인한 뒤 auto-remediation을 진행한다.
   3. HGX 시스템은 고장 난 노드를 drain하고 hot spare로 교체한다.
   4. NVL72 같은 rack-scale 시스템은 재부팅이나 수리 workflow를 수행한다.
   5. 복구가 끝나고 검증을 통과한 노드만 플릿에 돌아와 다시 작업을 받아야 한다.

3. 측정해야 할 시간

   1. 사업자가 장애를 감지하는 데 걸리는 시간을 잰다.
   2. 노드를 drain하고 클러스터 밖으로 빼는 데 걸리는 시간을 잰다.
   3. hot spare 투입, reboot, repair 중 실제 선택된 경로가 끝나는 데 걸리는 시간을 잰다.
   4. 노드가 unhealthy 상태로 남아 고객 학습을 느리게 하거나 실패시키지 않았는지 확인한다.

3.4. SLA가 필요한 이유

1. 고객의 유일한 계약상 구제 수단

   1. 고객은 사용하지 못한 GPU 시간에 계속 돈을 내지 않도록 downtime의 정의를 계약에 명시해야 한다.
   2. 장애가 발생했을 때 받을 credit의 양과 지급 조건도 미리 정해야 한다.
   3. 사업자가 예외 조항을 늘어놓아 책임을 피하지 못하도록 node·rack·site·cluster의 정의, downtime, force majeure를 구체적으로 적어야 한다.

2. 권장되는 우선순위

   1. 좋은 SLA를 체결해 스스로를 보호해야 한다.
   2. 그보다 좋은 방법은 처음부터 신뢰할 수 있는 사업자를 고르는 것이다.
   3. 연간 가동 중단이 3주에 달한 뒤 5%의 credit을 돌려받기 위해 싸우는 상황은 좋은 거래가 아니다.

4. Inference endpoint의 캐시와 숨은 비용

API endpoint는 Lambda function처럼 호출하면 항상 같은 비용과 품질이 나오는 단순한 표면이 아니며, 캐시 인식 라우팅과 autoscaling을 검증해야 한다.

4.1. preliminary test가 드러낸 차이

1. 겉보기 API와 실제 하드웨어의 차이

   1. endpoint는 함수처럼 실행하면 결과를 반환하는 것으로 보이지만, 내부 하드웨어 배치와 autoscaling 설정이 결과를 바꾼다.
   2. cache-aware routing이 제대로 작동하지 않으면 같은 프롬프트의 캐시가 있어도 적절한 GPU로 요청이 가지 않는다.
   3. preliminary test는 이후 concurrency 1,024 이상을 시험하는 “hero run”의 전초전으로 설계됐다.

2. 캐시 적중률 수치

   1. 유명한 한 사업자는 약 75%의 cache hit rate를 보였다.
   2. 다른 좋은 사업자는 99% 수준의 적중률을 보였다.
   3. 약 800 tokens짜리 trace를 단일 endpoint에 replay한 결과, 75% 적중률만으로도 전체 비용이 거의 두 배가 됐다.
   4. 200달러를 지불하는 작업이 같은 정확도에서 약 400달러가 될 수 있고, 캐시 오버라이드 때문에 속도까지 느려질 수 있다.

4.2. 추론 사업의 기본기를 오해하지 않기

1. vLLM·SGLang만 설치해서는 부족하다

   1. ClusterMAX에서 낮은 평가를 받은 일부 네오클라우드는 곧바로 managed inference endpoint를 만들면 된다고 생각한다.
   2. vLLM이나 SGLang을 설치하면 작은 테스트는 돌아가지만, 고객 수와 workload가 커지면 기본 설정만으로는 부족하다.
   3. cache-aware routing, autoscaling, 운영 모니터링과 비용 통제가 함께 필요하다.

2. 커널과 serving stack의 추가 작업

   1. RadixArk와 Inferact 같은 팀은 kernel과 mega-kernel을 개발해 kernel launch 시간을 줄이고 inference latency를 낮춘다.
   2. 오픈소스 엔진을 가져다 GPU에 연결하는 것만으로 80% 마진을 보장할 수 없다.
   3. endpoint 사업자는 오픈소스 위에 고객 workload에 맞는 최적화와 라우팅 계층을 직접 구축해야 한다.

5. 네트워크·NCCL·스토리지 성능

GPU 세대의 FLOPS는 사업자 간 차별화가 약하므로, 실제 학습 성능은 reliability 다음으로 네트워크와 스토리지의 기본 설정에 좌우된다.

5.1. NCCL golden recipe의 조건

1. 고객이 즉시 실행할 수 있는 기본값

   1. NCCL(NVIDIA Collective Communications Library)은 다중 GPU 클러스터의 기본 통신 라이브러리다.
   2. 고객이 이상한 인터페이스 설정을 찾거나 nccl.conf를 직접 수정하지 않아도 합리적인 성능이 나와야 한다.
   3. 클러스터에 접속해 명령 한 번으로 출발점이 되는 golden recipe를 실행할 수 있어야 한다.
   4. 이후 모델과 parallelism 전략에 맞춰 고객이 직접 hill climbing할 수 있어야 한다.

2. 메시지 크기 sweep

   1. 여러 메시지 크기를 모두 검사하고, 노드 수의 2배 단위로 범위를 확장한다.
   2. 128KB에서 성능이 급락하거나 너무 작은 메시지가 전혀 전달되지 않는 pathological 구간을 찾아야 한다.
   3. 메시지 크기가 커질수록 throughput이 단조롭게 증가하는지 확인한다.
   4. 이상적인 결과는 매끄러운 logistic curve에 가깝다.
   5. NVIDIA 기본 라이브러리 자체도 완벽하지 않아 나쁜 소프트웨어나 라우팅 휴리스틱 때문에 dip이 생길 수 있지만, 고객에게 그 문제를 처음부터 떠넘겨서는 안 된다.

5.2. Google과 AWS EFA의 trade-off

1. Google Cloud의 접근

   1. Google은 NVIDIA의 스위치·NIC 실리콘을 사용하지 않는 자체 네트워크도 NCCL에서 즉시 작동하도록 NVIDIA NGC container에 통합했다.
   2. 컨테이너 버전마다 NCCL의 모든 tuning parameter를 추적하고 네트워크에 맞춰 다시 조정할 필요를 줄였다.

2. AWS EFA의 한계

   1. EFA(Elastic Fabric Adapter)는 이전 테스트보다 NCCL을 사용하기 쉬워졌지만, 최신 collective library를 모두 지원하지는 않는다.
   2. DeepEP와 Mooney P 같은 라이브러리는 NCCL보다 낮은 수준의 NVSHMEM 위에 구축돼 추가 성능을 낸다.
   3. EFA에서는 이런 recipe가 기본 지원되지 않아, AWS가 자체 scale-out 네트워크에서 절약한 비용이 고객과 엔지니어가 별도 설정에 쓰는 시간으로 전환된다.
   4. Perplexity 등의 팀이 EFA에서 합리적인 성능을 내는 방법을 공개했지만, 고객이 업계 표준 오픈소스 recipe를 그대로 쓰지 못하면 생태계의 발전을 막는다.

3. 비용 절감과 고객 선택권의 균형

   1. 전체 대형 클러스터 비용에서 네트워크 이외 요소가 약 75~80%를 차지한다는 언급이 있었다.
   2. 네트워크에서 몇 퍼센트를 절감하는 것 자체는 의미가 있지만, 그 대가로 고객이 DeepSeek 계열 통신 recipe 같은 최신 workload를 못 쓰게 만들면 손해가 더 크다.
   3. 사업자는 자체 하드웨어와 소프트웨어를 쓰더라도 업계 최선의 공개 stack과 호환성을 유지해야 한다.

5.3. Firmus GB300 사례

1. out-of-the-box 성능 격차

   1. Firmus의 GB300 클러스터에서 NCCL 성능 곡선을 측정한 결과, 이전 설정과 협업 후 설정 사이에 차이가 나타났다.
   2. 통신 집약적인 expert-parallel TorchTitan GPT-OSS 학습에서 Firmus는 기본 상태로 GPU당 초당 1,455 tokens를 기록했다.
   3. 다른 테스트 대상은 약 3,500 tokens/s/GPU까지 올라가 Firmus의 초기 성능은 절반 이하로 떨어졌다.
   4. 프로파일링에서는 각 step에 노출된 communication time이 노란색으로 나타났고, Firmus의 step 시간이 훨씬 길었다.

2. 사업자 평가의 균형

   1. Firmus가 나쁜 사업자라는 뜻은 아니다. 수천 개 GB300을 설치했고 만족하는 고객도 있다.
   2. 다만 고객과의 반복적인 문제 해결에서 얻는 battle scars가 없으면 최신 GB200·GB300의 네트워크를 처음부터 올바르게 설정하기 어렵다.
   3. 내년에 Vera Rubin이 출시될 때는 NVIDIA 문서와 공급업체의 약속 중 무엇을 믿어도 되는지 이미 경험한 사업자를 우선해야 한다.

5.4. Lustre와 Linux kernel이 만든 장애

1. 예상 밖의 실제 노드 장애

   1. XID 주입은 테스트 마지막에 실행하는데, 복귀하지 않으면 전체 테스트를 shorthanded로 진행해야 하기 때문이다.
   2. 어느 날 실제로 노드 다운 이메일이 왔고, 아무도 작업을 실행하지 않았는데 노드가 사라져 Slack에서 “누가 내 클러스터를 건드렸나”라는 농담이 오갔다.
   3. 성능 엔지니어는 모든 것이 작동하기를 바라지만, ClusterMAX 테스터는 버그가 없으면 할 일이 없기 때문에 버그를 원한다는 반대의 입장이 농담으로 제시됐다.

2. 오래된 Linux kernel의 dirty inode 문제

   1. 종료 중인 오래된 Slurm 작업이 writeback cache에 쌓인 dirty inode의 소유권을 재할당해야 했다.
   2. 몇 년 전 버전의 Linux kernel에 남아 있던 나쁜 quadratic-time 알고리즘이 dirty page를 처리했다.
   3. 알고리즘은 한 NUMA node에 연결된 CPU 코어를 잠갔고, 파일시스템의 Lustre client가 CPU 시간을 얻지 못했다.
   4. Lustre client가 “아직 살아 있는가”라는 기본 요청에 응답하지 못하자 health check가 스토리지 장애로 판단했다.
   5. 그러나 CPU가 잠겨 health check도 작업을 완료할 수 없었고, Slurm 작업이 정리되는 몇 시간 동안 노드는 비정상 상태였다.
   6. 정리가 끝나 CPU가 정상화되자 health check가 즉시 실행돼 노드를 다시 검사했다.

3. 운영 결론

   1. GPU가 고장 나지 않았는데 파일시스템 health check와 CPU kernel bug 때문에 노드가 플릿에서 빠지는 상황은 피해야 한다.
   2. 최소한 스토리지 client가 health check를 수행할 CPU 시간을 확보해야 한다.
   3. 고객에게는 GPU만큼이나 kernel, NUMA, Slurm 종료 경로, Lustre client가 결합한 corner case가 중요하다.

6. Agentic coding과 클러스터 보안

AI agent는 로그 조사와 디버깅을 가속하지만, 클러스터 운영을 자동으로 안전하게 만들지 않으며 기본적인 취약점과 권한 설정은 사람이 직접 교정해야 한다.

6.1. Agentic coding이 만든 새로운 부하

1. CMAX CLI와 에이전트의 역할

   1. ClusterMAX는 오픈소스인 CMAX CLI를 전면에 두고, 에이전트를 그 위에 감싼다.
   2. CMAX CLI가 클러스터에서 문제를 만나면 에이전트가 로그와 상태를 조사해 원인을 찾도록 한다.
   3. 에이전트가 클러스터에서 실행하는 workload는 사람이 순차적으로 실행하는 것보다 훨씬 공격적이고 스트레스가 크다.

2. 모델이 운영 인프라를 망가뜨리는 방식

   1. 클러스터 오케스트레이션은 에이전트가 표면적으로는 유용해 보일 만큼 친숙하지만, 세부 설정을 잘못 이해하면 사용자의 발을 매번 쏘는 영역이다.
   2. 모델은 그럴듯한 Slurm·Kubernetes·NCCL 패턴을 제안하지만, 특정 workload와 토폴로지에서 실제로 작동하는지 보장하지 못한다.
   3. Jordan Nanos가 만든 대시보드처럼 사람도 brittle한 도구를 만들 수 있으므로, 에이전트의 자신감 있는 출력만으로 실행을 승인하면 안 된다.

3. 비용 추정의 위험

   1. endpoint 전체를 sweep하자는 작업을 에이전트에게 물었더니 30만~40만 달러가 든다는 답이 나왔다.
   2. 40만 달러도 SemiAnalysis에는 “가벼운 일”이라는 농담이 나왔지만, 실제 실행 전에는 먼저 시스템을 bulletproof하게 만들어야 했다.
   3. 자동화가 주는 가짜 확신을 억제하려면 비용·동시성·실패 경로를 사람이 독립적으로 재검증해야 한다.

6.2. 제품이 복잡해지기 전에 기본기를 해결하기

1. 사업자의 우선순위

   1. 최신 GPU를 가장 빠르게 온라인에 올리는 일은 어렵지만, 몇 개의 VM을 만들고 Kubernetes 클러스터를 안정적으로 구성하는 일은 이미 해결된 문제여야 한다.
   2. 일부 사업자는 1년 전보다 본질적으로 복잡하지 않은 제품을 제공하면서 오히려 내부 이해도가 낮아진 것처럼 보였다.
   3. 성능 스토리지와 block storage는 좋은 사업자도 아직 모두 제공하지 않는 비교적 높은 마진의 확장 영역이다.

2. 문서와 모델의 활용

   1. ClusterMAX 보고서의 권장 패턴을 agent context에 넣으면 기존 검색보다 나은 시작점을 얻을 수 있다.
   2. Slurm과 Kubernetes에는 학습 데이터에 좋은 패턴도 많지만 특정 use case에서 실패하는 패턴도 많다.
   3. 에이전트는 경험 없는 사람이 혼자 구성하는 것보다 나은 결과를 낼 수 있지만, 여전히 잘못된 설정을 자신 있게 반환한다.

6.3. 취약점 검증에서 드러난 false positive

1. 모델의 과도한 거부와 환각
   1. 일부 frontier model은 취약점 exploit을 꺼리며 실제 공격 가능성 대신 false positive를 낸다.
   2. 한 테스트에서 모델은 CVE를 이용해 host access와 control plane 접근을 얻을 수 있다고 자신 있게 답했다.
   3. 두 시간 동안 디버깅한 뒤 모델은 자신이 만든 proof of concept이 거짓이며 실제로 exploit할 수 없다고 인정했다.
   4. 환각은 줄었을 수 있지만 false positive는 사라지지 않았고, 보안 담당자는 모델의 “가능하다”는 답을 실제 재현으로 검증해야 한다.

6.4. 네오클라우드가 넘어야 할 보안 기준

1. 낡은 패치와 테넌트 격리

   1. GPU 클러스터는 가치가 높고 공격력도 강한 장비지만 여러 사업자에서 부주의하게 보호되고 있다.
   2. 두 해 전 CVE가 여전히 기본 소프트웨어에 적용되는 사례가 발견됐다.
   3. 고객은 이웃 테넌트의 Grafana를 볼 수 없어야 하며, 최신 CUDA Toolkit과 커널을 사용해야 한다.
   4. 테넌트 격리는 거창한 AI 안전 연구가 아니라 기본적인 권한·네트워크·관찰성 설정의 문제다.

2. Agentic attacker에 맞선 방어

   1. 공격자가 더 강력한 모델을 사용하면 사람이 수동으로 로그를 읽는 속도로 방어하기 어렵다.
   2. Hugging Face를 경유한 OpenAI 사이버 공격 사례처럼 방어에도 agentic AI가 필요할 수 있다.
   3. 그러나 “AI 시대라서 어쩔 수 없다”는 변명은 기본 보안 실패를 가려서는 안 된다.

3. OpenAI 사례에서 배워야 할 기본기

   1. 공격에 활용된 첫 단계에는 적용 가능한 Linux kernel CVE가 있었다.
   2. Kubernetes 권한 관리가 허술해 privilege escalation이 가능했다.
   3. 인터넷에 무제한으로 접근하는 agent를 sandbox에 넣었다면 이를 감지하는 alerting이 있어야 했지만 없었다.
   4. 수많은 chain-of-thought를 분석할 때는 모델이 도움이 될 수 있지만, 커널 업데이트·권한 제한·인터넷 egress 감시는 모델 없이도 실행해야 하는 최소선이다.
   5. 복잡한 공격에는 agent로 맞서더라도, 기본적인 잘못을 “새로운 세계라서 그렇다”라고 포장할 수 없다.

7. 금융, SLA, NVIDIA의 백스톱

ClusterMAX는 단순한 성능표가 아니라 수억~수십억 달러의 GPU 계약이 실제로 이행될 수 있는지를 판단하는 신용·보험 인프라의 일부다.

7.1. 대규모 투자가 실패하는 두 경로

1. 납기 실패

   1. 사업자가 계약한 데이터센터를 충분히 빨리 건설하지 못하거나, 장비를 온라인으로 올리지 못하면 고객 acceptance를 통과하지 못한다.
   2. 고객이 지불을 시작하지 않으므로 사업자는 부채와 장비 비용을 감당하지 못한다.

2. SLA 위반과 계약 취소

   1. 클러스터가 반복적으로 다운돼 SLA를 크게 위반하면 고객은 cancellation right를 행사할 수 있다.
   2. 대출기관과 네오클라우드는 납기 지연과 계약 취소라는 두 위험을 보험처럼 헤지하려 한다.

7.2. 보험과 표준 계약의 역할

1. Parametric risk underwriting

   1. Parametrix 같은 회사는 계약의 parametric risk를 인수하려면 클러스터와 사이트의 실질적 복원력을 알아야 한다.
   2. 사이트 수준의 이중 전력, 이중 냉각, 이중 인터넷 연결이 있는지 확인해야 한다.
   3. 장애를 완화할 설계와 부품 창고, 충분한 현장 인력, 가까운 수리 자원이 있어야 한다.
   4. 홍수 평야나 허리케인 위험이 있는 부지라면 자연재해 보험과 force majeure 조항이 필요하다.

2. 산업 표준 SLA

   1. ClusterMAX는 고객이 사용할 수 있는 예시 SLA와 계약을 만들고 사업자·랩과 공유한다.
   2. node·rack·site·cluster의 정의를 통일해야 서로 다른 계약을 비교할 수 있다.
   3. downtime, force majeure, credit, acceptance 조건을 표준화하면 사업자는 필요한 맞춤화를 하면서도 핵심 용어의 분쟁을 줄일 수 있다.
   4. 여러 계약과 실제 장애를 경험한 기술평가가 대주·공급자·구매자 모두에게 거래 완료의 확실성을 준다.

7.3. 스타트업의 compute 계약이 가진 치명성

1. 어떤 스타트업은 시드 라운드의 100%를 compute에 썼고, 창업자들이 급여를 받지 않은 채 VC 수표를 네오클라우드 용량으로 바로 돌렸다.
2. 수억 달러를 조달한 회사가 내리는 가장 중요한 결정이 어느 사업자를 믿을지 선택하는 일일 수 있다.
3. 현장 방문·직접 장애 재현·운영 대응 관찰을 포함한 기술평가가 계약 이전에 필요하다.

7.4. NVIDIA·Amazon·Google의 자본 백스톱

1. NVIDIA의 규모

   1. NVIDIA의 off-balance-sheet backstop universe는 FY2027 기준 5,880억 달러를 넘는 것으로 추정됐다.
   2. 현재 추세가 이어지면 2031년 말에는 2조 달러를 넘을 수 있다.
   3. Pratt Bhatt는 FY2031에 HBM 등 공급망만을 위한 NVIDIA의 backstop이 약 8,270억 달러에 이를 수 있다고 덧붙였다.
   4. 8,270억 달러는 데이터센터 건설과 토지·전력까지 포함한 수치가 아니라 HBM 공급자 등을 포함한 공급망 부분만을 가리킨다.

2. 대형 기업의 위험 분담

   1. Amazon과 Google도 balance sheet를 활용해 이 생태계에 참여한다.
   2. 이들은 모든 위험을 직접 떠안기보다, 고객이 오지 않으면 NVIDIA나 자신이 capacity를 인수할 수 있다는 backstop을 제공한다.
   3. 자금 조달이 아직 끝나지 않은 회사가 1,000-GPU 1년 계약을 맺고 첫해 학습 결과로 다음 라운드를 기대하는 구조가 존재한다.
   4. 로보틱스·신약 발견·재료과학·코딩 agent 사업자가 실제 성과를 내고 있어 이 레버리지가 지금까지는 작동하지만, 납기·가동률·수요의 물리적 조건은 계속 검증해야 한다.

8. 오래된 GPU와 데이터센터 전력의 재평가

수요가 공급을 계속 초과하면 세대가 지난 GPU도 전원을 켤 수 있는 한 높은 잔존가치를 가지며, 차세대 랙은 기존 시설의 전력 밀도를 넘어선다.

8.1. H100·A100의 긴 수명

1. 현재도 3~4년 된 H100을 원하는 고객이 많고, Vera Rubin이 출시되면 H100은 시장에서 5년 된 장비가 된다.
2. OpenAI는 2020년에 받은 A100을 한 번도 반납하지 않았으며, 그 GPU는 6년 이상 사용되고 있다.
3. 오늘도 H100 capacity에 4년짜리 계약이 체결된다.
4. 수요가 공급을 계속 초과하고 GPU가 켜져 있기만 하면, 오래된 GPU의 가격은 유지되거나 오를 수 있다.
5. 이 흐름은 일부 투자자가 주장한 급격한 GPU 감가상각 가정과 다르며, 금융사는 5~6년 뒤 계약 종료 시점의 terminal value를 다시 계산해야 한다.

8.2. GB300과 Vera Rubin의 전력 밀도

1. H100 랙은 약 30kW이고, 기존 시설은 대략 30~40kW를 기준으로 지어졌다.
2. Grace Blackwell GB300 랙은 140kW에 이르며 peak에서 200kW에 가까워질 수 있다.
3. 기존 시설은 새 Vera Rubin 랙을 그대로 수용할 수 없다.
4. 시설 운영자는 기존 H100을 계속 돌리거나, 랙을 빼고 CPU 서버·sandbox용 장비·스토리지를 넣는 선택을 해야 한다.
5. 800V DC 전력 분배와 데이터센터 개조가 다음 논의의 핵심이 되며, 고밀도 가속기 전환은 GPU 공급만이 아니라 전력·냉각·배선·건물 설계 문제다.

9. Hosted training과 RL 인프라의 난이도

RL post-training은 규모가 작아 보여도 inference·training·environment를 동기화해야 하므로, 단순한 managed cluster나 endpoint보다 훨씬 어려운 서비스다.

9.1. RL이 어려운 세 가지 이유

1. 서로 다른 세 계층의 동기화

   1. inference가 trajectory를 생성한다.
   2. trainer가 그 trajectory로 모델을 업데이트한다.
   3. environment 또는 sandbox가 실제 task와 보상 신호를 제공한다.
   4. 세 구성요소가 서로 다른 속도로 실패하거나 확장되면 correctness와 reliability가 동시에 무너진다.

2. 훈련보다 큰 인프라 표면

   1. RL environment lab은 environment만 실행하는 서버 팜과 방 전체를 운영하기도 한다.
   2. Docker와 virtualization만으로 끝나지 않고, iPhone·Android 같은 실제 하드웨어에서 environment를 실행해야 하는 경우가 있다.
   3. hosted training은 environment node, inference node, trainer node를 모두 자동 확장해야 한다.
   4. 각 계층의 autoscaling 중에도 trainer-inference mismatch가 없어야 한다.

9.2. Hosted training이 아직 대중화되지 않은 이유

1. Pratt Bhatt는 아직 큰 시장이 형성되지 않았다고 보지만, 향후 시장 가능성은 열어 두었다.
2. 기업은 모델 학습에 쓰는 지식재산을 OpenAI나 Anthropic 같은 제3자에게 넘기지 않고 자체 보유하려 한다.
3. 반대로 OpenAI나 Anthropic의 제품이 충분히 우수하면 IP 보호보다 결과 품질을 우선하는 고객도 생길 수 있다.
4. managed hosted training은 고객이 environment 생성부터 실제 학습까지 이해하도록 교육하고, 초기에는 forward-deployed researcher와 엔지니어가 손을 잡고 구축해야 한다.
5. 모든 계층을 고객 대신 다루고 고객이 과정을 익힌 뒤에야 제공자가 운영에서 손을 뗄 수 있다.

9.3. Pre-training과 RL의 서비스 약속 차이

1. CoreWeave나 Nebius가 일반적으로 보장하는 것은 인프라의 성능·신뢰성이지, 고객의 데이터 혼합·모델 구조·학습 결과 자체가 성공한다는 약속은 아니다.
2. RL hosted provider는 infrastructure뿐 아니라 environment, 모델 학습 correctness, 고객의 사업 맥락까지 이해해야 한다.
3. forward-deployed engineer는 단순 FDE(Forward Deployed Engineer)가 아니라 FDR(Forward Deployed Researcher)라고 부르는 편이 맞다는 농담이 나왔다.
4. 고객의 모델이 실제로 좋아지는지 보장하려면 provider가 연구와 제품 domain을 함께 이해해야 한다.

9.4. Framework 전쟁과 trainer-inference mismatch

1. 주요 프레임워크

   1. RL 생태계에는 Slime, Miles, verl, PrimeRL 등 여러 프레임워크가 경쟁하고 있다.
   2. RadixArk는 Miles를 한 번에 설정할 수 있고 agent 친화적으로 만든 점이 강점으로 언급됐다.
   3. PrimeRL은 GPU가 부족하던 시절에도 직접 여러 번 실행해 볼 만큼 쓸 만한 경험을 제공했다.
   4. 초보자도 한 번에 실행할 수 있어 보이지만 hyperparameter를 정해야 하므로 실제 학습은 여전히 어렵다.

2. 정확성의 누적 문제

   1. Human SAN 블로그는 대규모 native NVFP4 training이 어떻게 이뤄지는지 보여 주는 참고 자료로 추천됐다.
   2. trajectory가 길어지고 step 수가 늘면 trainer와 inference의 작은 불일치가 누적된다.
   3. optimizer가 기술적으로 올바른 방향을 배우려면 더 많은 step이 필요하지만, 약 100 step 동안 mismatch가 누적되면 모델이 크게 diverge하고 학습이 collapse할 수 있다.
   4. RL 프레임워크 팀이 매일 PR을 보내는 이유는 단순한 기능 추가가 아니라 이 수치적 일관성과 동기화 문제를 해결하기 위해서다.

3. slop PRs라는 운영 문제

   1. 자동화 agent가 보낸 PR은 양이 많아도 품질이 보장되지 않는다.
   2. Inferact의 Roger는 PR을 병합하려면 Slack으로 메시지를 보내 달라고 했고, 모든 slop PR을 읽을 수 없다고 말했다.
   3. 이 장면에서 slop PRs를 “SLARS”처럼 부르자는 농담이 나왔지만, 대규모 오픈소스 운영에서 리뷰 병목이 실제 문제가 된다는 점을 보여 준다.

10. 결론과 ClusterMAX 4.0을 향한 기준

좋은 GPU 클라우드는 고객이 존재를 의식하지 않아도 되는 클러스터를 제공하며, 다음 세대 가속기와 새로운 비NVIDIA 가속기까지 동일한 운영 품질로 검증해야 한다.

10.1. 고객이 계약 전에 검증할 체크리스트

1. 신뢰성

   1. active·passive health check가 실제로 실행되는지 확인한다.
   2. DCGM/XID injection 후 장애 감지·drain·교체·복귀 시간을 측정한다.
   3. 고장 난 GPU가 고객 job에 계속 배정되지 않는지 확인한다.

2. 성능

   1. NCCL golden recipe가 사전 제공되는지 확인한다.
   2. 모든 메시지 크기의 성능 곡선과 노드 규모별 scale-out을 측정한다.
   3. 캐시 hit rate가 75%에 머무르지 않고 workload 비용을 두 배로 만들지 않는지 확인한다.
   4. GB200·GB300·Vera Rubin처럼 목표 세대에서 실제 고객 workload 성능이 나오는지 확인한다.

3. 보안과 계약

   1. 커널·CUDA·NIC firmware가 최신 보안 버전인지 확인한다.
   2. 이웃 테넌트의 Grafana, Kubernetes 권한, 인터넷 egress가 격리되는지 확인한다.
   3. node·rack·site·cluster와 downtime을 SLA에 정의하고, credit·교체·cancellation 조건을 명시한다.
   4. 부품·현장 인력·전력·냉각·네트워크 이중화와 자연재해 대응을 확인한다.

10.2. 사업자의 제품 전략

1. Slurm과 Kubernetes를 안정적으로 만들고 health check를 완성하는 일이 새로운 네 제품을 내놓는 것보다 우선이다.
2. 성능 스토리지와 block storage는 현재 제공되지 않는 실용적인 확장 영역이다.
3. managed inference와 hosted training은 오픈소스 설치본이 아니라 routing·kernel·autoscaling·고객 교육까지 묶은 제품이어야 한다.
4. 고객이 실제로 쓰는 workload와 내부 엔지니어가 겪은 장애의 battle scars가 최신 GPU 지원의 신뢰성을 결정한다.

10.3. 마지막 농담과 다음 세대

1. Sam Harshe는 ClusterMAX 4.0에서 쓸 obscure bug가 없어지고, Slinky에 로그인해 topology awareness가 작동하며 health check가 발을 쏘지 않기를 바랐다.
2. Jordan Nanos는 사업자가 노드를 임의로 지우거나 재부팅하고 kubectl을 사흘 동안 멈추게 하는 일이 없어야 한다고 덧붙였다.
3. 다음 ClusterMAX는 Vera Rubin이 데이터센터에 들어온 뒤 이어질 예정이다.
4. Pratt Bhatt가 TPU도 평가하느냐고 묻자, TPU·Trainium·각국 데이터센터에 배치되는 새로운 accelerator가 다음 평가 대상이 될 수 있다는 암시가 나왔다.
5. GPU 클라우드의 미래는 NVIDIA GPU만의 순위가 아니라 TPU·Trainium·novel accelerator까지 같은 reliability·performance·security 기준으로 비교하는 방향으로 넓어진다.

주요 발언 모음

“GPU가 있으면 Kubernetes가 완전히 vibe-coded 상태여도, 스토리지가 간신히 작동해도 사람들은 좋은 마진을 내고 가져간다.” — Sam Harshe

“관리형 클러스터에 필요한 것은 화려한 bells and whistles보다 Slurm과 Kubernetes를 bulletproof하게 만들고 health check를 제대로 하는 일이다.” — Sam Harshe

“75% cache hit rate가 괜찮아 보이지만, 같은 replay 비용을 거의 두 배로 만들 수 있다.” — Pratt Bhatt

“고장 난 GPU가 작업에 섞이지 않게 하고, 감지·drain·교체·복귀 시간을 재야 한다.” — Jordan Nanos의 테스트 원칙

“모델의 환각은 줄었을 수 있지만 false positive는 사라지지 않았다.” — Pratt Bhatt

“OpenAI 공격에서 커널 CVE, Kubernetes 권한, 인터넷 접근 경보 부재는 모두 기본적인 문제였다.” — Sam Harshe

“고객이 1년 뒤에도 살아 있을지 모르는 상태에서 수천 GPU를 약정하므로, 누가 backstop을 제공하는지 봐야 한다.” — Jordan Nanos의 금융 분석

“RL은 inference의 어려움과 training의 어려움을 합치고, environment를 추가한 세 구성요소를 동기화해야 한다.” — Jordan Nanos

“더 좋은 클러스터일수록 ClusterMAX 4.0에 쓸 내용이 줄어든다.” — Sam Harshe

핵심 데이터 & 수치

• 77개: ClusterMAX 3.0에서 직접 평가한 관리형 GPU 클라우드 수다.
• 323개: 전체 시장 추적 범위로, ClusterMAX 2.0의 209개에서 증가했다.
• 200명 초과: 연구 기간에 인터뷰한 네오클라우드 실제 사용자 수다.
• 19개: 이번 판에서 Medallion 등급을 받은 네오클라우드 수다.
• 15개: Bronze와 Underperforming 사이의 Participation Ribbon에 들어간 사업자 수다.
• 75% 대 99%: 한 endpoint의 cache hit rate와 다른 우수 사업자의 비교 수치다.
• 약 800 tokens: endpoint cache replay에서 사용한 trace 규모다.
• 200달러에서 400달러: 75% cache hit rate가 같은 정확도의 실행 비용을 거의 두 배로 만들 수 있다는 예시다.
• 1,455 tokens/s/GPU 대 약 3,500 tokens/s/GPU: Firmus GB300의 초기 TorchTitan GPT-OSS expert-parallel 성능과 비교 대상의 차이다.
• 약 75~80%: 대규모 클러스터 비용에서 네트워크 이외 요소가 차지한다는 대략적 언급이다.
• 5~10건: health check 설계 자체가 실행될 수 없었던 사례의 대략적 수다.
• 1,024 이상: preliminary endpoint test 뒤 계획한 hero run의 목표 동시성이다.
• 5,880억 달러 초과: FY2027 기준 NVIDIA off-balance-sheet backstop universe 추정치다.
• 2조 달러 초과: 현 추세가 이어질 때 2031년 말 예상되는 NVIDIA backstop universe다.
• 약 8,270억 달러: FY2031에 HBM 등 공급망만을 위해 NVIDIA가 backstop할 수 있다는 별도 추정치다.
• 3~4년: 현재도 시장에서 높은 수요가 있는 H100의 대략적인 사용 연령이다.
• 5년: Vera Rubin 출시 시점에 시장에 나올 H100의 예상 연령이다.
• 6년 이상: OpenAI가 2020년부터 보유한 A100의 사용 연령이다.
• 30kW 대 140~200kW: H100 랙과 GB300 랙의 전력 밀도 비교다.
• 약 100 step: trainer-inference mismatch가 누적돼 모델 발산과 학습 붕괴를 일으킬 수 있는 설명상의 구간이다.

결론 및 시사점

1. GPU 구매자는 가격·GPU 모델·납기만 비교하지 말고 장애 주입, 네트워크 sweep, 캐시 replay, 보안 검증을 포함한 acceptance test를 계약에 넣어야 한다.
2. 사업자는 여러 제품을 동시에 출시하기 전에 Slurm·Kubernetes·health check·스토리지 client를 bulletproof하게 만들어야 한다.
3. Platinum과 Gold 사업자의 우위는 로고나 FLOPS가 아니라 최신 클러스터에서 이미 장애와 성능 문제를 겪고 고친 운영 경험에서 나온다.
4. 네오클라우드의 금융 가치는 NVIDIA와 대형 클라우드의 backstop이 키우지만, 납기·전력·냉각·부품·SLA가 실제 현금흐름을 결정한다.
5. 오래된 H100과 A100도 공급 부족이 이어지면 terminal value를 유지하므로, 감가상각은 칩 세대만으로 추정하면 안 된다.
6. hosted training은 endpoint의 상위 버전이 아니라 environment·inference·trainer를 모두 운영하고 고객의 연구를 교육하는 별도 사업이다.
7. RL 프레임워크의 경쟁은 기능 수보다 trainer-inference 일관성, 환경 구축, 장기 trajectory 안정성을 중심으로 전개될 가능성이 높다.
8. Agentic coding은 디버깅을 가속하지만 잘못된 설정과 false positive를 확대할 수 있으므로, 실행 권한과 비용 한도를 분리해야 한다.
9. TPU·Trainium·Vera Rubin 같은 새 가속기에도 동일한 reliability·security·performance 기준을 적용해야 진짜 클라우드 품질 비교가 가능하다.
10. 최종적으로 좋은 GPU 클라우드는 존재감이 없는 클라우드다. 사용자는 topology-aware 스케줄러에 로그인하고, 고장 난 노드가 자동으로 빠지고, NCCL과 스토리지가 바로 작동하며, SLA를 사용할 일이 거의 없어야 한다.

핵심 요약 (20줄)

1. ClusterMAX 3.0은 관리형 GPU 클러스터 77곳을 직접 시험하고 전체 네오클라우드 시장 323곳을 추적했다.
2. 연구팀은 실제 네오클라우드 사용자 200명 이상을 인터뷰해 운영 품질의 기준을 보완했다.
3. CoreWeave와 Nebius는 Platinum, Oracle과 Google Cloud는 Gold 등급을 받았다.
4. Azure는 Silver로 내려갔고 AWS와 Crusoe는 Bronze로 내려가며 등급 기준이 높아졌다.
5. GPU 공급 부족 때문에 부서진 Kubernetes와 스토리지를 가진 사업자도 당장은 높은 마진을 얻는다.
6. 고객은 최신 GPU보다 고장 격리와 운영 소프트웨어가 실제로 작동하는지 먼저 확인해야 한다.
7. active health check는 workload를 실행하고 passive health check는 작업을 방해하지 않으며 상태를 감시한다.
8. Amazon HyperPod의 일부 health check는 노드가 이미 healthy여야 실행돼 자동 복구가 불가능했다.
9. DCGM과 XID 장애 주입은 감지·drain·hot spare·복귀 시간을 실제 production 경로로 검증한다.
10. 한 endpoint의 75% cache hit rate는 99% 수준의 사업자보다 비용을 거의 두 배로 만들 수 있다.
11. NCCL golden recipe와 메시지 크기 sweep은 고객이 네트워크를 즉시 사용할 수 있는지 판별한다.
12. Firmus GB300의 초기 TorchTitan GPT-OSS 성능은 GPU당 1,455 tokens/s로 비교 대상 약 3,500보다 낮았다.
13. 오래된 Linux kernel의 dirty inode 처리 버그가 CPU와 Lustre client를 잠가 GPU 노드를 잘못 격리했다.
14. Agentic coding은 CMAX CLI 장애 조사에 유용하지만 클러스터 설정을 항상 올바르게 만들지는 못한다.
15. OpenAI 공격 사례는 커널 CVE, Kubernetes 권한, 인터넷 접근 경보 같은 기본 보안 실패가 치명적임을 보였다.
16. NVIDIA의 off-balance-sheet backstop은 FY2027에 5,880억 달러를 넘고 2031년에는 2조 달러를 넘을 수 있다.
17. H100과 A100은 수요가 공급을 웃도는 동안 각각 5년과 6년 이상 사용돼도 높은 잔존가치를 유지한다.
18. GB300 랙의 140~200kW 전력 밀도는 H100 랙의 약 30kW보다 훨씬 높아 데이터센터 개조를 요구한다.
19. RL hosted training은 environment·inference·trainer를 동기화해야 하므로 managed endpoint보다 훨씬 어렵다.
20. 진짜 좋은 GPU 클라우드는 topology-aware 운영과 신속한 복구를 제공해 고객이 클러스터를 의식하지 않게 만든다.