NVIDIA AI 인프라, GPU만 비교하던 팀이 네트워크·소프트웨어·스토리지까지 다시 계산해야 하는 이유

NVIDIA AI 인프라 견적에서 GPU 모델, VRAM, peak FLOPS와 시간당 가격만 맞춰 놓으면 비교가 끝난 것처럼 보인다. 하지만 GPU가 계산을 시작하기 전에 데이터가 늦게 도착하거나, 여러 GPU가 중간 결과를 교환하느라 기다리거나, 런타임이 가속기를 충분히 채우지 못하면 사양표의 연산량은 팀이 받는 처리량이 되지 않는다.

이 글은 2026년 8월 30일 기준 NVIDIA 공시와 제품 문서, AWS 공동 발표, MLCommons 자료를 독립 보도와 대조한 아키텍처 분석이다. 하드웨어나 공개 벤치마크를 직접 재현한 결과는 아니다. GPU 클러스터를 증설하거나 새 AI 플랫폼을 고르는 팀이 견적표의 경계를 어디까지 넓히고, PoC에서 무엇을 같은 조건으로 재야 하는지 확인할 수 있다.

20초 핵심 요약

무엇: GPU를 단품이 아니라 스토리지 → 호스트·네트워크 → GPU 메모리 → GPU 간 통신 → 런타임·프레임워크 → 토큰 출력 파이프라인으로 비교한다.
왜: 입력과 collective 통신이 GPU를 기다리게 하거나 라이선스·이전비용을 누락하면, 높은 peak FLOPS를 사도 SLO를 만족한 결과 1단위 비용이 더 커질 수 있다.
어떻게: 동일한 모델·정밀도·배치·입출력 길이·SLO를 고정하고 end-to-end 처리량, 병목 시간, 전체 비용과 장애 영향을 후보별로 기록한다.

구매 단위는 GPU가 아니라 토큰이 통과하는 전체 경로다

NVIDIA가 법정 공시에서 설명하는 데이터센터 플랫폼부터가 GPU 단품이 아니다. GPU와 CPU, DPU, NVLink 스위치, NIC, scale-out 네트워크, CUDA와 라이브러리를 함께 설계한 시스템이다. 회계연도 2026년 데이터센터 네트워킹 매출이 142% 늘었다는 공시도 네트워크가 부수 액세서리가 아니라 제품과 사업의 주요 축이라는 점을 보여준다. 다만 이 수치는 NVIDIA의 사업 범위를 보여주는 근거이지, 모든 팀에서 NVIDIA 네트워크가 더 싸거나 빠르다는 성능 증거는 아니다. NVIDIA FY2026 Form 10-K

AWS와 NVIDIA가 2026년 8월 발표한 2027~2028년 계획도 GPU 200만 개에만 머물지 않는다. Vera CPU, NVLink Fusion, AWS Nitro와 EFA 통합, Spectrum 네트워킹, cuDF와 cuVS를 함께 열거한다. 아직 완료된 배치나 고객 워크로드 결과는 아니지만, 실제 공급사 협력의 설계 범위가 가속기 SKU 밖으로 넓어졌다는 점은 확인할 수 있다. AWS·NVIDIA 공동 발표

따라서 비교의 분모와 분자를 바꿔야 한다. 구매가격을 GPU 수로 나누는 대신, 관측 기간의 총비용을 SLO를 만족한 총 토큰이나 완료된 학습 작업으로 나눈다.

결과 1단위 비용 = 관측 기간의 총비용 / SLO를 만족한 총 tokens 또는 완료된 학습 작업

여기서 총비용에는 compute뿐 아니라 network, storage, software와 support, 전력·냉각·공간, 운영, migration, downtime risk가 들어간다. 각 항목의 실제 금액은 견적과 운영 조건 없이는 채울 수 없지만, 빠진 열을 드러내는 것만으로도 GPU 단가표보다 나은 비교가 된다.

데이터는 저장장치에서 토큰 출력까지 네 번 기다릴 수 있다

전체 경로를 기억하는 가장 쉬운 방법은 GPU를 가운데 둔 데이터 이동으로 보는 것이다. 저장장치에서 읽은 데이터가 GPU 메모리에 도착하고, GPU들이 중간 상태를 교환하며, 런타임과 프레임워크가 계산을 실행한 뒤 사용자에게 토큰이나 학습 결과를 내놓는다. 이 과정에는 서로 다른 책임 주체와 장애 지점이 있다.

스토리지에서 GPU 메모리까지

일반적인 데이터 경로에서는 스토리지에서 CPU 메모리의 bounce buffer로 읽은 뒤 GPU 메모리로 다시 복사할 수 있다. GPUDirect Storage(GDS)는 cuFile과 지원 드라이버를 이용해 스토리지나 NIC의 DMA 엔진이 GPU 메모리로 직접 데이터를 옮기는 경로를 제공한다. 피하는 것은 데이터의 CPU bounce buffer이며, 제어 경로와 드라이버까지 CPU에서 사라지는 것은 아니다.

‘GDS 지원’ 로고만으로 실제 대역폭을 확정할 수 없는 이유도 여기에 있다. 파일시스템, 커널과 드라이버, CUDA·cuFile, O_DIRECT와 정렬, PCIe 토폴로지, 동시 요청 수가 맞아야 하며 조건에 따라 compatibility 또는 fallback 경로를 쓸 수 있다. 애플리케이션이 충분한 동시성을 만들지 못하면 GDS가 그 자체로 링크를 채워주지 않는다. 용량과 순차 GB/s 옆에 GPU당 유효 read GB/s, 첫 epoch 시간, 체크포인트 시간, CPU 절감량과 튜닝 인력을 함께 적어야 한다. GDS Overview의 Compatibility and Generality

한 노드·랙 안의 scale-up 통신

모델 병렬화와 tensor·pipeline parallelism에서는 GPU들이 중간 상태를 자주 교환한다. NVLink와 NVLink 스위치는 이 노드 또는 랙 안의 고대역폭 scale-up 영역을 담당한다. GPU 메모리 총합에 모델이 들어가더라도 collective 통신이 계산과 겹치지 않거나 토폴로지가 맞지 않으면 step time은 길어진다.

명목 NVLink 대역폭 대신 GPU별 collective 시간, 통신과 계산의 overlap, 느린 작업자가 반영된 p95 step latency를 본다. NVLink 영역의 크기와 한 구성요소 장애 때 몇 개 GPU가 함께 멈추는지도 기록해야 한다. 이 영역 밖으로 나간 트래픽에는 다음 scale-out 네트워크의 조건이 적용된다.

랙과 노드 사이의 scale-out 통신

분산 학습의 all-reduce와 all-to-all, 분산 추론의 KV나 상태 이동은 Ethernet 또는 InfiniBand와 NIC, 스위치, 케이블, 라우팅·혼잡 제어를 통과한다. NVLink와 역할이 다르므로 ‘GPU 네트워크’ 한 줄로 합치면 병목과 장애 범위를 찾기 어렵다.

Spectrum-X는 Spectrum 스위치와 SuperNIC을 함께 조정해 adaptive routing, congestion control과 성능 격리를 제공한다는 NVIDIA의 Ethernet 플랫폼이다. 표준 Ethernet과 SONiC 지원은 개방성 요소지만, NVIDIA가 제시하는 성능 배수를 자사 환경의 결과로 옮겨 적을 수는 없다. NCCL collective의 유효 대역폭, 혼잡 시 tail latency, 재전송, 멀티테넌트 격리, NIC·스위치 장애 영향과 관측 도구를 실제 후보 구성에서 확인해야 한다. NVIDIA Spectrum-X Ethernet Platform

런타임과 프레임워크에서 결과까지

CUDA는 커널 실행의 기반이고, CUDA-X, NCCL, cuDNN, TensorRT 계열 라이브러리와 프레임워크 통합은 하드웨어 연산량을 모델 처리량으로 바꾸는 층이다. 무료 개발 도구가 있다는 사실과 production 지원·라이선스 비용이 0이라는 주장은 다르다. NVIDIA AI Enterprise의 production consumption 공식 가격 문서는 2026년 6월 8일 업데이트 기준으로 GPU당 시간당 1달러에 CSP 인스턴스 비용을 더한다고 표시하며, 장기 production은 별도 견적이다. 지역, 세금, 할인과 지원 조건은 공급사 견적에서 다시 확인해야 한다. NVIDIA AI Enterprise Pricing

소프트웨어 의존성은 ‘CUDA를 쓴다’는 체크박스보다 옮겨야 할 자산의 규모로 센다. CUDA 전용 커널과 코드량, NCCL·cuFile 직접 호출, 전용 컨테이너와 오퍼레이터, 최적화 엔진, 모니터링·배포 자동화, 운영자 숙련, 정확도와 SLO 재검증 시간이 전환비용이다. 반대로 PyTorch나 JAX의 표준 연산을 중심으로 쓰고 여러 백엔드를 CI에서 함께 검증한다면 이전 범위는 줄어들 수 있다.

GPU 단품표에 이 아홉 개 열을 더해야 한다

비교표의 출발점은 후보마다 같은 일을 시키는 것이다. 모델과 가중치, 정밀도, 배치, 입력·출력 길이, 품질 목표와 SLO가 다르면 GPU 세대와 가격을 맞춰도 결과를 비교할 수 없다.

비교 축	GPU 단품표의 값	전체 경로에서 더할 값	판단 질문
워크로드	GPU 모델, VRAM, peak FLOPS	모델·가중치, 정밀도, 배치, 입출력 길이, 품질 목표, SLO	후보가 같은 일을 했는가?
최종 성능	GPU utilization, 이론 연산량	학습 time-to-train·samples/s, 추론 tokens/s·TTFT·ITL p50/p95	사용자가 받는 결과가 빨라졌는가?
scale-up	NVLink 유무와 명목 GB/s	collective 시간, overlap, 영역 크기, 장애 영향	병렬화가 fabric을 얼마나 기다리는가?
scale-out	NIC 속도	all-reduce/all-to-all 유효 대역폭, 혼잡 tail, 재전송, 격리	다른 작업이 들어와도 step time이 유지되는가?
스토리지	용량, 순차 GB/s	GPU당 read GB/s, 첫 epoch·checkpoint 시간, GDS·파일시스템 호환성	GPU가 입력을 기다리는가?
소프트웨어	CUDA 지원 여부	버전, 라이선스, 지원, 최적화와 유지보수	성능을 재현하고 업그레이드할 수 있는가?
가용성	노드 수	NIC·스위치·스토리지·라이선스 서비스의 장애 도메인	한 부품 장애가 몇 GPU를 멈추는가?
비용	GPU 구매가 또는 시간당 요금	CPU·NIC·스위치·케이블·스토리지·시설·지원·운영인력	3년 총비용과 결과 1단위 비용은 얼마인가?
전환	새 GPU 가격	전용 코드·데이터 경로·이미지·오케스트레이션·재검증·egress·철거	12~24개월 뒤 다른 후보로 옮길 수 있는가?

GPU 메모리의 공급망 경계를 더 확인하려면 SK하이닉스 HBM 미국 공장 글에서 생산 범위와 일정의 구분을 이어서 볼 수 있다. 이 링크는 네트워크 성능이나 현재 HBM 가격의 근거가 아니라, 비교표에 공급 조건을 더 조사할 때의 다음 읽을거리다.

GPU utilization은 최종 순위가 아니라 원인을 찾는 보조 지표다. 높더라도 재계산, 과도한 padding이나 통신 대기와 겹친 비효율을 숨길 수 있다. 낮다면 입력 I/O, collective, CPU 전처리 또는 scheduler 중 어디에서 기다리는지를 나눠 봐야 한다. 최종 비교는 동일 품질과 SLO를 만족한 end-to-end 결과로 한다.

MLCommons도 MLPerf Training을 모델·소프트웨어·하드웨어를 함께 스트레스하는 full-system 시험으로 정의한다. peak FLOPS보다 time-to-train 같은 전체 시스템 결과를 보라는 방법론을 뒷받침한다. 다만 제출 시스템은 규모와 최적화, 가용성과 가격이 서로 다르므로 MLPerf 순위를 자사 TCO 순위로 그대로 바꾸면 안 된다. MLPerf Training v6.0

통합 스택과 분리 조달은 책임 비용을 다르게 낸다

NVIDIA 통합 스택의 채택 이유는 모든 부품이 항상 가장 싸거나 빠르기 때문이 아니다. 함께 검증된 GPU·NVLink·NIC·스위치·CUDA-X 경로와 비교적 선명한 지원 창구가 장애 분석 시간을 줄일 가능성이 있기 때문이다. 대규모 collective나 데이터 이동이 실제 병목이고, 공급사의 검증 조합이 자사 모델에서 결과 1단위 비용을 낮추며, 지원 절감액이 전환 선택권보다 가치가 클 때 채택 근거가 생긴다.

대신 NVIDIA 전용 API와 운영 지식이 늘수록 이전할 범위도 커진다. production 소프트웨어 비용, 호환 네트워크와 스토리지 BOM은 GPU 밖의 CAPEX와 OPEX를 늘릴 수 있다. 이 비용까지 넣고도 장애 해결과 성능 재현이 쉬워지는지가 질문이다.

표준 Ethernet을 재사용해 부품을 분리 조달하거나 다른 가속기를 선택하면 기존 fabric과 운영 도구를 살리면서 공급사 선택권을 유지할 수 있다. 워크로드가 작은 scale-up 영역에 머물거나 네트워크 민감도가 낮고, 내부 플랫폼 팀이 조합 검증과 장애 책임 조정을 감당할 수 있다면 유리할 수 있다. 반면 스위치, NIC, collective 라이브러리와 가속기의 조합을 팀이 검증해야 하므로 싼 peak FLOPS가 곧 싼 결과로 이어지지는 않는다.

‘통합은 폐쇄적이고 표준은 자동 호환된다’고 나누는 것도 정확하지 않다. Spectrum-X는 표준 Ethernet과 SONiC를 지원한다고 밝히면서 최적화된 성능은 NVIDIA 스위치·SuperNIC·소프트웨어의 결합에서 주장한다. AWS 사례 역시 NVIDIA와 AWS 구성요소를 공동 통합한다. 개방성은 프로토콜 이름보다 실제로 교체할 수 있는 부품, 지원 조합, 자동화된 호환 테스트와 코드·데이터 이전시간으로 평가하는 편이 낫다.

PoC는 최고 수치보다 실패 조건을 먼저 고정한다

PoC에는 동일 워크로드의 단일 노드 기준선과 목표 규모 비교가 모두 필요하다. 정상 상태만 돌리지 말고 네트워크 혼잡, 스토리지 지연, 노드 장애 가운데 운영 위험이 큰 한 가지를 포함한다. 평균 tokens/s뿐 아니라 추론의 TTFT·ITL 또는 학습 step time의 p95·p99가 SLO 안에 남는지 확인해야 한다.

다음 중 하나가 생기면 peak 성능이 높아도 도입을 보류할 근거가 된다.

모델·정밀도·배치·입출력 길이가 달라 후보 간 결과를 맞춰 볼 수 없다.
결과 1단위 비용이 줄지 않거나 p95 SLO를 만족하지 못한다.
단일 노드 결과만으로 multi-node collective와 혼잡 격리를 추정해야 한다.
파일시스템, 드라이버, CUDA·cuFile과 PCIe 토폴로지의 GDS 호환성을 확인할 수 없다.
공급사의 최대 성능 배수를 자사 TCO에 넣어야만 경제성이 성립한다.
라이선스, CSP 인스턴스, egress, 네트워크 포트·광모듈, 시설과 운영인력을 견적에서 분리할 수 없다.
NIC·스위치·스토리지·라이선스 서비스 장애가 멈추게 할 작업 범위를 알 수 없다.
병목의 책임 주체와 지원 창구가 불명확하다.

이 글은 실제 NVIDIA 또는 대체 가속기 클러스터, NVLink·Spectrum-X·InfiniBand, GDS 스토리지를 시험하지 않았다. 공개 MLPerf 결과도 재현하지 않았고 OEM·클라우드 견적과 시설·운영 비용을 확보하지 못했다. 따라서 공급사가 제시한 성능 배수나 cost-per-token 개선을 일반화하거나 ROI로 제시하지 않는다. 이 빈칸은 문서가 아니라 자사 워크로드 PoC와 실제 견적으로만 채울 수 있다.

견적 두 개를 받으면 같은 모델 한 개로 표를 채운다

GPU는 여전히 계산의 기반이다. 달라진 것은 GPU 단가표를 버리는 것이 아니라 구매와 측정의 경계를 전체 데이터 경로로 넓혀야 한다는 점이다. 같은 GPU라도 스토리지 입력, scale-up·scale-out 통신, 런타임 최적화와 지원 조건이 다르면 팀이 얻는 결과와 장애 범위는 달라진다.

다음 단계는 본문의 비교표를 자사 모델 한 개와 실제 견적 두 개에 적용하는 것이다. 소프트웨어 라이선스와 네트워크·스토리지 BOM이 빠지지 않았는지 공급사에 확인하고, 동일 SLO의 결과 1단위 비용과 장애 시 영향이 더 나은 후보만 PoC에 남긴다.

참고 링크

제휴·협찬은 없다.

NVIDIA AI 인프라, GPU만 비교하던 팀이 네트워크·소프트웨어·스토리지까지 다시 계산해야 하는 이유

20초 핵심 요약

구매 단위는 GPU가 아니라 토큰이 통과하는 전체 경로다