적절한 규모로 설계된 인프라에서 Zadara가 AI 성능을 최적화하는 방식과, 학습 및 추론 모두를 위한 이상적인 AI Factory 플랫폼인 이유
AI 인프라 프로젝트는 잘못된 기술 선택 때문에 실패하는 경우보다, 잘못된 사이징(규모 산정) 때문에 실패하는 경우가 훨씬 더 많습니다.
규모를 과소 산정하면 실제 사용자 부하에서 LLM이 제대로 동작하지 못하고, 반대로 과도하게 산정하면 값비싼 GPU 하드웨어가 80%의 시간 동안 유휴 상태로 남게 됩니다.
이 글에서는 요구사항 수집부터 실제 배포 가능한 아키텍처 권장안 도출에 이르기까지, AI 워크로드를 위한 GPU 및 컴퓨팅 인프라 사이징을 위한 실용적인 단계별 프레임워크를 안내합니다. 또한 적절한 사이징 결정이 이루어진 이후 Zadara를 기반으로 사용할 때 전체 AI 성능이 어떻게 최적화되는지에 대해서도 설명합니다. 더 나아가, 잘 설계된 배포 환경에서 Zadara의 유연성이 어떻게 추론, 소버린 AI, 그리고 대규모 배치 학습 옵션을 고성능으로 지원하는지를 명확히 합니다.
데이터 주권(Data Sovereignty)이 요구되는 워크로드를 위한 프라이빗 AI 배포, GPU 가속 분석 파이프라인, 또는 멀티테넌트 추론 플랫폼을 계획하고 있는 경우에도 방법론은 동일합니다. Zadara가 제공하거나 지원하는 하드웨어 선택지는, NVIDIA RTX PRO 6000 Blackwell Server Edition GPU(각 GPU당 96GB VRAM, 노드당 4개 GPU) 기반의 추론 특화 노드부터 NVIDIA Spectrum-X 네트워킹 또는 InfiniBand를 갖춘 대규모 HGX 클러스터에 이르기까지, 본문에서 다루는 모든 유스케이스를 포괄합니다.
Zadara의 AI 분야에서의 입지와 AI 최적화 솔루션은 NVIDIA GTC 2026에서 강조되었습니다. 이 자리에서 Zadara는 멀티테넌트 AI 클라우드 인프라를 위한 NVIDIA Software Reference Guide와의 정렬을 발표했으며, ‘Neutral AI Factory’ 아키텍처를 선보였습니다. 또한 NVIDIA GTC 블로그에서는 DDN과의 전략적 파트너십을 통해 NVIDIA 레퍼런스 아키텍처 기반의 소버린 클라우드 및 멀티테넌트 AI 팩토리를 위한 고성능 AI 인프라를 제공하는 사례로 Zadara가 소개되었습니다.
왜 하드웨어 선택보다 사이징이 중요한가
NVIDIA GPU 라인업은 매우 인상적이며 빠르게 진화하고 있습니다. 워크로드에 특화된 전문가용 GPU부터 최신 데이터센터 가속기인 NVIDIA H200 GPU 및 NVIDIA B300 GPU에 이르기까지 다양한 선택지가 존재합니다.
또한 NVIDIA Spectrum-X 이더넷 또는 InfiniBand 네트워킹을 활용한 대규모 클러스터 구성은 수천 개의 GPU까지 확장할 수 있습니다.
그러나 어떤 GPU를 사용할지 결정하기 전에, 보다 근본적인 질문에 답해야 합니다.
“어떤 유형의 워크로드를 실행하고 있는가?”
GPU 기반 AI 워크로드는 본질적으로 두 가지 범주로 나뉘며, 각각 서로 다른 최적화 목표를 가지고 있습니다.
이 구분을 정확히 이해하는 것이 모든 사이징 논의의 첫 번째 단계입니다. 또한, 항상 더 많은 것이 더 좋은 것이거나 비용 효율적인 것은 아닙니다. 저희 경험상 많은 고객들이 실제 워크로드가 배치 중심임에도 불구하고 가장 빠른 GPU를 요구하는 경우가 많습니다. 그러나 워크로드 유형에 맞게 적절히 사이징된 GPU 구성을 Zadara를 통해 운영하는 것이 비용 효율성과 운영 측면에서 훨씬 더 단순하고 효과적입니다.
GPU 사이징의 세 가지 핵심 요소
워크로드 유형을 파악했다면, 하드웨어 요구사항을 결정하는 세 가지 기술적 요소가 있습니다. 이를 서로 위에 쌓이는 계층으로 생각할 수 있습니다.
첫 번째 요소: 모델 가중치(Model Weights) — VRAM의 기준선
모든 AI 모델은 파라미터로 구성되어 있으며, 각 파라미터는 GPU에 로드되기 위해 메모리를 필요로 합니다. 각 파라미터가 차지하는 바이트 수는 모델이 제공하는 전체 정밀도 수준에 영향을 미칩니다.
따라서 필요한 메모리 용량은 선택한 수치 정밀도(포맷)에 따라 달라집니다.
실무에서 자주 사용되는 경험적 기준은 다음과 같습니다.
👉 모델 크기(십억 단위) × 2 = FP16 기준 최소 VRAM(GB)
Zadara의 GPU Cloud는 전 세계 수백 개의 엣지 클라우드에 걸쳐 다양한 NVIDIA GPU 구성을 지원합니다. 추론 최적화 노드는 NVIDIA RTX PRO 6000 Blackwell Server Edition GPU(각 GPU당 96GB GDDR7 VRAM, 노드당 4개 GPU로 총 384GB)를 사용하며, 특정 워크로드 및 소버린 엣지 환경에 적합합니다.
더 큰 모델과 높은 동시성 요구사항을 위해 Zadara는 HGX급 AI Factory 데이터센터 가속기를 지원합니다. 여기에는 NVIDIA H200 GPU(141GB HBM3e, 노드당 8개 GPU로 총 1,128GB)와 NVIDIA B300 GPU(288GB HBM3e, 노드당 8개 GPU로 총 2,304GB)가 포함됩니다.
단일 노드 VRAM을 초과하는 모델의 경우, NVIDIA Spectrum-X 또는 InfiniBand 클러스터 기반의 멀티 노드 구성을 통해 필요한 만큼 확장할 수 있습니다.
- 사이징 참고 : 금융, 헬스케어, 공공 등 규제 산업의 프로덕션 워크로드에서는 INT4보다는 FP16 또는 INT8을 사용하는 것을 권장합니다. 품질 차이는 실제로 측정 가능하며, 소버린 AI 환경에서는 GPU 자원을 최대한 압축하는 것보다 신뢰성이 더 중요합니다.
두 번째 요소: 메모리 대역폭 — 실제 성능을 결정하는 핵심 요소
LLM 추론에 대한 다소 직관에 반하는 사실이 있습니다. 병목은 연산 자원(FLOPS)에 있는 경우가 드물고, 대부분은 메모리 대역폭, 즉 토큰 생성 과정에서 VRAM으로부터 모델 가중치를 얼마나 빠르게 읽어올 수 있는지에 의해 성능이 결정됩니다.
디코딩 단계(각 출력 토큰을 생성하는 과정)에서는, 생성되는 모든 토큰마다 모델의 전체 가중치를 읽어야 합니다. 이는 연산 중심(compute-bound) 작업이 아니라 메모리 대역폭에 의해 제한되는(memory-bandwidth-bound) 작업입니다.
대략적인 토큰 생성 속도 계산식은 다음과 같습니다.
- tokens/sec ≈ GPU 메모리 대역폭(GB/s) / 모델 크기(GB)
- 예를 들어, 대역폭이 4,800 GB/s인 단일 NVIDIA H200 SXM GPU에서 70B FP16 모델(140GB)을 실행할 경우: 4,800 / 140 ≈ 사용자당 약 34 tokens/sec (단일 GPU, 배칭 없음)
- 4개의 NVIDIA H200 GPU를 텐서 병렬화로 구성하여 총 대역폭이 약 19,200 GB/s이고, vLLM으로 최적화된 서빙을 사용할 경우: 19,200 / 140 ≈ 배칭 오버헤드 이전 기준 총 약 137 tokens/sec 처리량
- 추론 최적화 노드에서 사용되는 NVIDIA RTX PRO 6000 Blackwell Server Edition GPU의 경우, 각 GPU는 약 1,792 GB/s의 GDDR7 대역폭과 96GB VRAM을 제공합니다.
- 70B INT8 모델(70GB)은 단일 GPU에 적재가 가능하며, 이 경우: 1,792 / 70 ≈ 약 25 tokens/sec
노드 내 4개의 GPU를 텐서 병렬화로 구성하면 총 대역폭은 약 7,168 GB/s로 증가하며, 배칭과 함께 훨씬 높은 처리량을 제공합니다.
이러한 이유로, Zadara AI Cloud에서 멀티 GPU 구성을 사용할 경우—특히 노드 간 연결에 NVIDIA Spectrum-X 고대역폭 네트워킹이나 InfiniBand를 활용하는 경우—대규모 모델 추론에서 성능이 비약적으로 향상됩니다.
Zadara의 Spectrum-X 구현은 최대 51.2 Tb/s의 총 스위칭 용량을 제공하는 NVIDIA Spectrum-4 이더넷 스위치와, GPU 서버 간 최대 400 GbE RoCE 연결을 제공하는 BlueField-3 SuperNIC을 기반으로 구성됩니다.
이 환경에서 Zadara의 GPU-Net 기술이 중요한 역할을 합니다. GPU-Net은 가상 머신 간에 전용 동서(east-west) 방향의 GPU 통신 경로를 자동으로 구성하고, NVIDIA 레퍼런스 아키텍처에 따른 Spectrum-X 최적 토폴로지에 맞게 설정을 정렬하며, 자동화된 VRF 할당을 통해 멀티테넌트 격리를 처리하는 오케스트레이션 계층입니다.
이를 통해 고객은 복잡한 네트워크 설정을 직접 관리하지 않고도, 이더넷 환경에서 최고 수준의 GPU 간 통신 성능을 확보할 수 있습니다.
세 번째 핵심 요소: KV-Cache, 숨겨진 VRAM 소비 요소
언어 모델은 토큰을 생성할 때 한 번에 하나씩 생성합니다. 이 과정에서 지금까지 생성된 전체 토큰의 문맥에 “어텐션(attention)”을 유지하며 동작합니다. 이 토큰들의 집합은 추론이 진행될수록 계속 증가합니다. 동일한 토큰을 반복 생성하는 것을 방지하기 위해, 언어 모델은 지금까지 본 모든 토큰에 대해 Key와 Value 벡터를 내부적으로 계산하고 저장합니다. 이것이 KV-Cache이며, 만약 이것이 없다면 모델은 매 생성 단계마다 전체 문맥을 다시 계산해야 하므로 추론 속도가 현실적으로 사용하기 어려울 정도로 느려집니다.
KV-Cache는 필수적인 요소입니다. 그러나 모델 가중치만 기준으로 사이징을 수행할 경우에는 보이지 않는(hidden) 요소이기도 합니다.
실제 워크로드에서는 총 VRAM 요구량을 2배에서 3배까지 증가시킬 수 있습니다.
KV-Cache는 다음 세 가지 요소에 따라 증가합니다.
- 모델 아키텍처 (레이어 수, 어텐션 헤드 수, 히든 디멘션)
- 컨텍스트 길이
- 동시 사용자 수
LLaMA-3 70B와 같은 최신 대규모 언어 모델은 기존의 전체 64개 헤드 대신, 8개의 KV 헤드를 사용하는 GQA(Grouped Query Attention)를 적용합니다. 이는 기존 멀티헤드 어텐션 구조 대비 사용자당 KV-Cache 크기를 크게 줄여줍니다.
실무적으로, LLaMA-3 70B 모델을 4K 컨텍스트에서 GQA 기반으로 사용할 경우, 동시 사용자 1명당 KV-Cache는 약 0.5 ~ 1GB 수준으로 추정할 수 있습니다.
이 지점에서 vLLM의 Paged Attention은 선택적인 최적화가 아니라 핵심적인 아키텍처 요소가 됩니다.
vLLM은 KV-Cache를 운영체제의 가상 메모리와 유사하게 동적 메모리 페이지로 관리함으로써, 사전에 할당되었지만 실제로 사용되지 않는 캐시 블록으로 인한 VRAM 낭비를 줄입니다.
실제 환경에서는 이를 통해 동일한 하드웨어 구성에서 처리할 수 있는 동시 사용자 수를 3배에서 4배까지 증가시킬 수 있습니다.
Zadara의 zCompute Cloud에서는 vLLM을 Kubernetes 상에서 컨테이너 형태의 워크로드로 배포하며, 디바이스 플러그인 관리를 위해 NVIDIA GPU Operator를 사용합니다.
이를 통해 초기 인프라 도입 시점이 아니라 운영 중(runtime)에도 유연하게 사이징을 조정할 수 있는 스케줄링 유연성을 확보할 수 있습니다.
실전 사이징 프레임워크
세 가지 핵심 요소를 이해했다면, 이제 Zadara에서 고객의 GPU 인프라를 사이징할 때 사용하는 5단계 프레임워크를 소개합니다.
Step 1: 워크로드 요구사항 명확화
하드웨어 카탈로그를 검토하기 전에, 다음 질문에 먼저 답해야 합니다.
- 어떤 모델을 사용할 것인가? (모델명 및 파라미터 수)
- 온라인 추론인가, 배치 처리인가?
- 최대 동시 사용자 수(온라인) 또는 시간당 배치 처리량(배치)은 얼마인가?
- 최대 컨텍스트 길이는 얼마인가? (2K / 4K / 8K / 128K 토큰)
- 요구되는 품질 수준은 무엇인가? (FP16 프로덕션 수준 또는 INT8/INT4 허용 여부)
- 데이터 주권 요구사항이 있는가? (온프레미스, 특정 지역 제한, 에어갭 환경 등)
마지막 항목은 기업 고객에게 점점 더 중요해지고 있습니다.
Zadara의 Sovereign AI Edge Cloud는 전 세계 수백 개의 엣지 위치(온프레미스 또는 파트너 데이터센터)에 배포되어 있으며, 데이터가 특정 지역이나 시설을 벗어나지 않아야 하는 조직을 위해 설계되었습니다.
Step 2: 총 VRAM 계산
총 VRAM = 모델 가중치 + KV-Cache + 프레임워크 오버헤드
- 모델 가중치: 파라미터 수(B) × 포맷 계수(GB)
- KV-Cache: 모델 구조(GQA 헤드 수 등), 컨텍스트 길이, 동시 사용자 수에 따라 결정 → 컨텍스트가 길어질수록 비례하여 증가
- 프레임워크 오버헤드: 2~4GB (CUDA 런타임, vLLM, Kubernetes 오버헤드)
Step 3: GPU 구성 선택
계산된 총 VRAM 요구사항을 기준으로 GPU 클래스 및 구성을 매핑합니다.
Zadara는 다양한 NVIDIA GPU 티어를 지원하며, 최적의 선택은 모델 크기, 동시성, 그리고 성능 요구사항에 따라 결정됩니다.
Step 4: 성능 검증
구성한 인프라가 지연 시간과 처리량 요구사항을 충족하는지 교차 검증합니다.
- Estimated tokens/s = (총 메모리 대역폭 GB/s) / (모델 크기 GB)
온라인 추론 기준:
- Time to First Token (TTFT): 2초 이하
- 사용자 체감 생성 속도: 사용자당 30 tokens/s 이상
예상 성능이 목표에 미치지 못할 경우, GPU를 추가하거나 양자화(quantization)를 고려해야 합니다.
단, 이 경우 고객에게 품질 저하에 따른 트레이드오프를 명확히 설명해야 합니다.
Step 5: 이중화 및 확장성 확보
단일 노드 GPU 구성은 프로덕션 환경에 적합하지 않습니다. 고객 대상 서비스에서는 다음 구성이 필요합니다.
- 고가용성(HA): 로드 밸런서 뒤에 최소 2개의 독립 GPU 노드 구성
- Kubernetes 스케줄링: zCompute Kubernetes 환경에서 NVIDIA GPU Operator를 통해 노드 단위 GPU 스케줄링 및 상태 모니터링 제공
- 수평 확장(Horizontal Scaling): Zadara의 오토스케일링 그룹을 통해 GPU 노드 수를 수요에 맞게 탄력적으로 조정
모델 및 데이터 저장소 구성
Zadara 아키텍처는 두 가지 보완적인 스토리지 계층을 제공합니다.
- 블록 스토리지 (기본 구성)
Zadara의 zStorage VPSA가 항상 제공되며, iSCSI를 통해 Kubernetes Persistent Volume으로 GPU 노드에 연결됩니다.
이는 일관된 저지연 성능을 제공하며, 모델 가중치 저장의 기본 방식으로 사용됩니다. 또한 콜드 스타트 시 성능 저하를 방지합니다.
- 공유 파일 스토리지 (고성능 워크로드용)
대규모 학습 데이터셋, 체크포인트 관리, 멀티테넌트 모델 레지스트리 등 고처리량이 필요한 경우, DDN EXAScaler 또는 Zadara 파일 시스템이 통합 제공됩니다.
이 두 가지 스토리지 옵션 중 선택은 워크로드의 성능 요구사항, 규모, 데이터 접근 패턴에 따라 결정됩니다.
사례: 금융 서비스 고객을 위한 소버린 AI 플랫폼
보다 구체적으로 설명하기 위해, 규제 산업 고객을 위해 우리가 설계한 배포를 대표하는 사이징 예시를 소개합니다.
- 고객 프로파일:
지역 금융 서비스 기관. 내부 컴플라이언스 문서 분석 및 구조화된 질의응답을 위한 프라이빗 LLM이 필요합니다.
데이터는 해당 관할 내에 유지되어야 합니다. 최대 동시 사용자 수는 40명의 분석가입니다. 컨텍스트 길이는 최대 8,192 토큰(장문의 규제 문서)입니다.
응답 시간 요구사항은 Time to First Token 기준 2초 이하입니다.
Step 1: 모델 선택
- LLaMA-3 70B (INT8): 구조화된 문서 기반 Q&A에 충분한 품질을 제공하며, 온프레미스 소버린 배포에 적합
Step 2: VRAM 계산
- 모델 가중치 (INT8): 70 GB
- KV-Cache (40명 사용자, 8K 컨텍스트, GQA 8 KV 헤드): 약 25 GB
- 8K 컨텍스트에서는 사용자당 캐시 크기가 4K 기준 추정치의 약 2배 수준이므로, 사용자당 약 0.6 GB × 40명 ≈ 약 25 GB가 됩니다.
- 프레임워크 오버헤드: 4 GB
- 총 필요 VRAM: 약 99 GB
Step 3: GPU 선택
옵션 A: NVIDIA RTX PRO 6000 Blackwell Server Edition 노드 (4 × 96 GB = 총 384 GB)
- 70 GB INT8 모델은 단일 GPU에 적재 가능하며, 해당 GPU에는 KV-Cache를 위한 약 26 GB의 여유 공간이 남습니다.
- 2개의 GPU로 텐서 병렬화를 적용하면 모델은 GPU당 35 GB로 분할되며, 각 GPU에는 KV-Cache 및 프레임워크 오버헤드를 위한 약 61 GB의 여유 공간이 남습니다.
- 이는 8K 컨텍스트에서 40명의 동시 사용자 처리에 충분합니다.
옵션 B: NVIDIA H200 GPU 기반 HGX 서버 노드 (8 × 141 GB = 총 1,128 GB)
- 향후 확장성, 더 높은 동시성 요구, 또는 더 큰 모델이나 더 긴 컨텍스트 윈도우로 확장할 계획이 있는 경우 권장됩니다.
- 텐서 병렬화(tp=2)를 적용하면 모델은 GPU당 35 GB로 분할되며, 각 GPU에는 100 GB 이상의 여유 공간이 확보됩니다.
Step 4: 성능 검증 (NVIDIA RTX PRO 6000 Blackwell, tp=2)
- 총 대역폭: 2 × 1,792 GB/s = 3,584 GB/s
모델 분할: 70 GB / 2 = GPU당 35 GB
- tokens/s 추정: 3,584 / 70 ≈ 약 51 tokens/s (총 처리량)
- 사용자당 (40명 동시, 배칭 적용): 약 40~50 tokens/s
TTFT: 약 1.2초 (목표 충족)
Step 5: 전체 아키텍처
- 컴퓨팅: Zadara zCompute 상 동일한 NVIDIA RTX PRO 6000 Blackwell Server Edition 노드 2대, 고가용성을 위한 active/active 구성
- 오케스트레이션: Zadara zCompute 상 Kubernetes, NVIDIA GPU Operator 사용
- 서빙: vLLM, Paged Attention 및 텐서 병렬화 적용
- 블록 스토리지: Zadara zStorage VPSA (NVMe 기반, iSCSI를 통해 Kubernetes persistent volumes로 제공, 모델 가중치 저장)
- 공유 스토리지: DDN EXAScaler 또는 Zadara 파일 시스템 (데이터셋 접근 패턴 및 처리량 요구사항에 따라 선택)
- 네트워킹: 인터넷 egress가 없는 격리된 Zadara VPC, 프라이빗 엔드포인트 구성
- 모니터링: Prometheus 및 Grafana (GPU 사용률, TTFT, tokens/s, VRAM 사용량)
결과
- 동시 사용자 40명
- TTFT는 지속적으로 1.5초 이하 유지
- 고객 관할 내에서 데이터 주권 완전 유지
- 퍼블릭 클라우드 API에 대한 의존성 없음
Spectrum-X 네트워킹 기반 클러스터 구성으로 확장이 필요한 경우
단일 노드 GPU 배포는 대부분의 엔터프라이즈 추론 워크로드를 충분히 처리할 수 있습니다.
그러나 다음과 같은 경우에는 NVIDIA Spectrum-X 네트워킹 기반의 멀티 노드 GPU 클러스터가 적합한 선택이 됩니다.
- 파운데이션 모델 파인튜닝:
70B 이상의 모델을 학습하거나 파인튜닝하려면 다수의 GPU에 걸친 지속적인 연산이 필요합니다.
이 경우 GPU 노드 간 네트워크 대역폭이 주요 제약 요소가 됩니다. Spectrum-X의 51.2 Tb/s 스위칭 용량과 BlueField-3 기반 400 GbE RoCE 연결은 이러한 병목을 제거합니다.
- 초대형 모델 (400B 이상):
LLaMA 405B와 같은 모델이나 자체 대규모 아키텍처는 수백 GB의 VRAM과 GPU 간 고속 통신을 필요로 합니다.
Spectrum-X의 2계층 leaf/spine 아키텍처는 최대 8,000개의 GPU까지 확장 가능하여, 네트워크가 클러스터 규모의 한계가 되지 않도록 합니다.
- 대규모 동시 사용자 추론:
멀티 노드 환경에서 모델이 분산된 상태로 많은 동시 사용자를 처리할 경우, KV-Cache 접근 패턴으로 인해 GPU 간 동서(east-west) 트래픽이 크게 증가합니다.
각 토큰 생성 단계마다 캐시된 key-value 데이터를 읽고 업데이트해야 하며, 이러한 캐시가 여러 노드에 분산되어 있는 경우 네트워크 지연과 대역폭이 Time to First Token 및 사용자당 처리량에 직접적인 영향을 미칩니다.
Spectrum-X의 adaptive routing과 RoCE congestion control은 이러한 노드 간 KV-Cache 트래픽을 높은 부하 상황에서도 안정적으로 처리하여, 사용자 경험을 저하시킬 수 있는 tail-latency 증가를 방지합니다.
- 대규모 동시 사용자 추론:
멀티 노드 환경에서 모델이 분산된 상태로 많은 동시 사용자를 처리할 경우, KV-Cache 접근 패턴으로 인해 GPU 간 동서(east-west) 트래픽이 크게 증가합니다.
각 토큰 생성 단계마다 캐시된 key-value 데이터를 읽고 업데이트해야 하며, 이러한 캐시가 여러 노드에 분산되어 있는 경우 네트워크 지연과 대역폭이 Time to First Token 및 사용자당 처리량에 직접적인 영향을 미칩니다.
Spectrum-X의 adaptive routing과 RoCE congestion control은 이러한 노드 간 KV-Cache 트래픽을 높은 부하 상황에서도 안정적으로 처리하여, 사용자 경험을 저하시킬 수 있는 tail-latency 증가를 방지합니다.
이러한 모든 경우에도 zCompute 플랫폼은 단일 노드 배포와 클러스터 배포 전반에 걸쳐 동일한 관리 인터페이스, 동일한 VPC 및 네트워크 모델, 동일한 Kubernetes 기반 운영 방식을 유지합니다.
하드웨어는 확장되지만 운영 복잡성은 증가하지 않습니다.
AI Factory 플랫폼으로서의 Zadara
개별 GPU 사이징을 넘어, Zadara의 더 큰 가치는 NVIDIA가 ‘AI Factory’라고 정의하는 개념을 구현할 수 있도록 한다는 점에 있습니다.
이는 AI 모델을 개발하고, 학습시키고, 배포하며, 유지관리하는 과정을 반복 가능하고 프로덕션 수준으로 수행할 수 있는 확장 가능하고 자동화된 인프라를 의미합니다. Zadara는 이를 가능하게 하는 소프트웨어 플랫폼과 오케스트레이션 계층을 제공합니다.
여기에는 탄력적인 GPU 컴퓨팅을 위한 zCompute, 탄력적인 블록 볼륨을 제공하는 Zadara zStorage VPSA와 고처리량 공유 스토리지를 위한 DDN EXAScaler 또는 Zadara 파일 시스템을 결합한 계층형 스토리지 아키텍처(애플리케이션 요구사항에 따라 선택), 자동화된 Spectrum-X 네트워킹을 위한 GPU-Net, 그리고 데이터가 특정 지역이나 시설을 벗어나지 않아야 하는 배포를 위한 Sovereign AI Edge Cloud가 포함됩니다.
이러한 구성 요소들은 서로 다른 벤더 제품을 조합한 것이 아니라, 처음부터 통합된 형태로 제공됩니다.
올바른 사이징 접근
GPU 인프라 사이징은 기술적인 작업인 동시에 요구사항을 파악하는 과정이기도 합니다.
어떤 질문을 하느냐(워크로드 유형, 모델 크기, 동시 사용자 수, 컨텍스트 길이, 품질 요구사항, 데이터 주권 제약 등)가 성능이 부족한 구성이나 과도한 투자로 이어지는 구성을 구분하는 핵심 요소입니다.
Zadara의 zCompute Cloud는 초기에는 적절한 규모로 시작하고, 워크로드가 변화함에 따라 수평적으로 확장할 수 있는 유연성을 제공합니다.
추론에 최적화된 NVIDIA RTX PRO 6000 Blackwell GPU 노드부터 Spectrum-X 네트워킹 기반 HGX 클러스터(NVIDIA H200 GPU 및 NVIDIA B300 GPU)에 이르는 다양한 GPU 구성, 긴밀하게 통합된 계층형 엔터프라이즈 스토리지, 그리고 수백 개의 엣지 위치에 걸친 소버린 배포 옵션을 통해, 인프라는 워크로드에 맞춰 적응하게 됩니다.
GPU 인프라 구축을 계획 중이며, 본 사이징 프레임워크를 귀사의 워크로드에 맞게 적용해보고자 한다면 Zadara Korea 에 문의하시기 바랍니다. 구체적인 수치 산정을 함께 도와드릴 수 있습니다.
