AI 워크로드에 최적화된 GPU 및 컴퓨팅 인프라 구축

Zadara는 어떻게 AI 워크로드에 맞춰 AI 성능을 최적화하는가? 그리고 Zadara가 학습 및 추론 모두에 이상적인 AI 팩토리 플랫폼인 이유는 무엇인가?

AI 인프라 프로젝트가 실패하는 이유는 기술 선택이 잘못되어서라기보다는 AI 워크로드에 대한 규모 설정이 잘못되어서인 경우가 더 많습니다. 규모가 너무 작으면 실제 사용자 부하에서 LLM(로더링 수명주기 관리)이 멈춰버립니다. 반대로 규모가 너무 크면 값비싼 GPU 하드웨어를 80%의 시간 동안 유휴 상태로 두게 됩니다.

이 글에서는 초기 요구사항 수집부터 배포 가능한 아키텍처 권장 사항에 이르기까지 AI 워크로드에 필요한 GPU 및 컴퓨팅 인프라 규모를 결정하는 실용적인 단계별 프레임워크를 안내합니다. 또한 Zadara를 기반으로 적절한 규모를 결정했을 때 AI 성능이 어떻게 최적화되는지 자세히 설명합니다. 더 나아가 Zadara의 유연성을 통해 추론, 자율적인 AI, 대규모 배치 학습 옵션을 구현하고, 적절한 규모의 배포 환경에서 탁월한 성능을 달성하는 방법을 명확히 제시합니다.

데이터 주권 워크로드를 위한 프라이빗 AI 배포, GPU 가속 분석 파이프라인 또는 멀티테넌트 추론 플랫폼을 계획하든 관계없이 방법론은 동일합니다. Zadara가 제공하거나 지원하는 하드웨어 옵션은 NVIDIA RTX PRO 6000 Blackwell Server Edition GPU(GPU당 96GB VRAM, 노드당 4개의 GPU) 기반의 집중형 추론 노드부터 NVIDIA Spectrum-X 네트워킹 또는 InfiniBand를 사용하는 대규모 HGX 클러스터에 이르기까지 여기에서 논의된 모든 사용 사례를 포괄합니다.

NVIDIA GTC 2026 에서 Zadara는 AI 분야에서의 입지와 AI 최적화 솔루션을 집중 조명했습니다 . Zadara는 NVIDIA의 멀티테넌트 AI 클라우드 인프라 소프트웨어 참조 가이드와의 협력을 발표하고, 중립 AI 팩토리 아키텍처를 선보였습니다 . NVIDIA GTC 블로그에서는 Zadara가 DDN과 전략적 파트너십을 맺고 NVIDIA 참조 아키텍처 기반의 고성능 AI 인프라를 독립형 클라우드 및 멀티테넌트 AI 팩토리에 제공하는 사례를 소개하기도 했습니다.

AI 워크로드에서 하드웨어 선택보다 크기가 더 중요한 이유

NVIDIA GPU 라인업은 인상적이며, 워크로드 중심의 전문가용 GPU부터 NVIDIA H200 GPU 및 NVIDIA B300 GPU 와 같은 최신 데이터센터 가속기에 이르기까지 빠르게 발전하고 있습니다 . NVIDIA Spectrum-X 이더넷 또는 InfiniBand 네트워킹을 사용하는 대규모 클러스터 구성은 수천 개의 GPU까지 확장할 수 있습니다. 하지만 어떤 GPU를 사용할지 결정하기 전에, 더 근본적인 질문에 답해야 합니다. 바로 어떤 유형의 워크로드를 실행할 것인가입니다.

GPU에서 실행되는 AI 워크로드는 근본적으로 두 가지 범주로 나뉘며, 각각 다른 최적화 목표를 가지고 있습니다.

이러한 차이점을 정확히 이해하는 것이 모든 규모 산정 논의의 첫 번째 단계입니다. 또한, 더 많은 것이 항상 더 좋거나 비용 효율적인 것은 아닙니다. 저희 경험상 많은 고객이 실제 워크로드가 배치 처리임에도 불구하고 가장 빠른 GPU를 요청하는 경우가 많습니다. 하지만 Zadara에서 운영하는 적절한 규모의 GPU 구성이 워크로드 유형에 맞춰져 있기 때문에 비용 효율적이고 운영이 더 간편합니다.

AI 워크로드에 적합한 GPU 크기 선정의 세 가지 핵심 요소

워크로드 유형을 파악했다면, AI 워크로드에 필요한 하드웨어 요구 사항을 결정하는 세 가지 기술적 요소가 있습니다. 이 요소들은 서로 겹겹이 쌓이는 계층 구조라고 생각하면 됩니다.

핵심 1: 모델 가중치, VRAM 기준선

모든 AI 모델에는 매개변수가 있습니다. 각 매개변수는 GPU에 로드하기 위해 메모리가 필요합니다. 각 매개변수가 차지하는 바이트 수는 모델이 제공하는 전체 정밀도 수준에 영향을 미칩니다. 결과적으로 필요한 메모리 양은 선택한 수치 정밀도(형식)에 따라 달라집니다.

모델 가중치용 VRAM = 매개변수 개수 x 매개변수당 바이트 수

표 1 – 정밀도 형식 및 AI 모델의 전체 크기.

흔히 사용되는 실용적인 경험 법칙은 다음과 같습니다.

 모델 크기(수십억 단위) x 2 = 최소 VRAM 용량(GB, FP16 기준).

Zadara의 GPU 클라우드는 전 세계 수백 개의 엣지 클라우드에서 다양한 NVIDIA GPU 구성을 지원합니다. 추론에 최적화된 노드는 NVIDIA RTX PRO 6000 Blackwell Server Edition(GPU당 96GB GDDR7 VRAM, 노드당 4개의 GPU, 총 384GB)을 사용하여 특정 워크로드 및 독립적인 엣지 환경에 적합합니다. 대규모 모델 및 높은 동시 처리 요구 사항을 충족하기 위해 Zadara는 NVIDIA H200 GPU(141GB HBM3e, 노드당 8개의 GPU, 총 1,128GB) 및 NVIDIA B300 GPU(288GB HBM3e, 노드당 8개의 GPU, 총 2,304GB)를 포함한 HGX급 AI Factory 데이터센터 가속기를 지원합니다. 단일 노드 VRAM 용량을 초과하는 모델의 경우, NVIDIA Spectrum-X 또는 InfiniBand 클러스터를 사용한 멀티 노드 구성을 통해 필요한 규모까지 확장할 수 있습니다.

참고 사항: 금융, 의료, 정부 등 규제 산업 분야의 프로덕션 워크로드에는 INT4보다는 FP16 또는 INT8을 권장합니다. 품질 차이가 확연히 드러나며, 독립적인 AI 배포 환경에서는 GPU 성능을 최대한 끌어내는 것보다 안정성이 훨씬 중요합니다.

두 번째 핵심 요소: 메모리 대역폭, 진정한 성능 향상 요인

LLM 추론에 대한 다소 역설적인 사실이 하나 있습니다. 병목 현상은 컴퓨팅 자원(FLOPS)에서 발생하는 경우가 드뭅니다. 오히려 토큰 생성 과정에서 모델 가중치를 VRAM에서 읽어오는 속도, 즉 메모리 대역폭이 성능에 영향을 미치는 경우가 훨씬 많습니다.

디코딩 단계(각 출력 토큰 생성)에서 모델은 생성된 모든 토큰에 대한 전체 가중치 세트를 읽어야 합니다. 이는 연산 능력보다는 메모리 대역폭에 좌우되는 작업입니다.

초당 토큰 처리량(근사치) = GPU 메모리 대역폭(GB/s) / 모델 크기(GB)

4,800GB/s 대역폭을 가진 단일 NVIDIA H200 SXM GPU에서 70B FP16 모델(140GB)의 경우:

4,800GB/s / 140GB = 사용자당 약 34토큰/초 (단일 GPU, 배치 처리 없음)

4개의 NVIDIA H200 GPU(총 약 19,200GB/s)에 걸친 텐서 병렬 처리와 vLLM을 통한 최적화된 서비스 제공:

19,200 GB/s / 140 GB = 배치 처리 오버헤드 전 총 처리량 약 137 토큰/s

NVIDIA RTX PRO 6000 Blackwell Server Edition GPU(각각 약 1,792GB/s의 GDDR7 대역폭, 96GB VRAM 제공)를 사용하는 추론 최적화 노드에서 70비트 INT8 모델(70GB)은 단일 GPU에 탑재할 수 있습니다. 따라서 단일 카드의 대역폭 계산은 1,792 / 70으로, 초당 약 25개의 토큰을 처리할 수 있습니다. 노드 전체에서 4개의 GPU를 모두 텐서 병렬 처리에 활용하면 총 대역폭은 약 7,168GB/s에 달하여 배치 처리 시 훨씬 높은 처리량을 제공합니다.

이것이 바로 Zadara의 AI 클라우드를 사용하는 멀티 GPU 구성, 특히 노드 간에 NVIDIA Spectrum-X 고대역폭 네트워킹 또는 InfiniBand를 활용하는 구성이 대규모 모델 추론에서 탁월한 성능 향상을 가져오는 이유입니다.

Zadara의 Spectrum-X 구현은 최대 51.2Tb/s의 총 스위칭 용량을 제공하는 NVIDIA Spectrum-4 이더넷 스위치와 GPU 서버 간 최대 400GbE RoCE 연결을 제공하는 BlueField-3 SuperNIC를 기반으로 합니다.

Zadara의 GPU-Net 기술은 이 솔루션을 차별화하는 핵심 요소입니다. GPU-Net은 가상 머신 간 전용 동서 스케일아웃 GPU 통신 경로를 자동으로 프로비저닝하고, NVIDIA 레퍼런스 아키텍처를 따르는 Spectrum-X의 레일 최적화 토폴로지에 맞춰 구성을 조정하며, 자동화된 VRF 할당을 통해 멀티테넌트 격리를 처리하는 오케스트레이션 레이어입니다. 고객은 수동 관리의 복잡성 없이 이더넷에서 최고 수준의 GPU 인터커넥트 성능을 경험할 수 있습니다.

세 번째 핵심 요소: KV 캐시, 숨겨진 VRAM 소비처

언어 모델은 토큰을 생성할 때 한 번에 하나의 토큰씩 생성합니다. 이는 지금까지 생성된 토큰들의 전체 문맥에 "주의를 기울이기" 때문입니다. 이러한 토큰 코퍼스는 추론이 진행됨에 따라 커집니다. 동일한 토큰이 반복적으로 생성되는 것을 방지하기 위해 언어 모델은 내부적으로 지금까지 처리한 모든 토큰에 대한 키-값 벡터(KV)를 계산하고 저장합니다. 이것이 KV 캐시이며, KV 캐시가 없으면 모델은 매 생성 단계마다 전체 문맥을 다시 계산해야 하므로 추론 속도가 비효율적으로 느려집니다.

KV 캐시는 필수적입니다. 모델 가중치에 대한 크기 조정만 수행할 경우에는 눈에 띄지 않지만, 실제 작업 부하에서는 전체 VRAM 요구량을 두 배 또는 세 배로 늘릴 수 있습니다.

캐시 크기는 모델 아키텍처(레이어 수, 어텐션 헤드 수, 은닉층 크기), 컨텍스트 길이, 동시 접속 사용자 수라는 세 가지 요소에 따라 증가합니다. LLaMA-3 70B와 같은 최신 대규모 언어 모델은 기존의 64개 KV 헤드 대신 8개의 KV 헤드를 사용하는 GQA(Grouped Query Attention) 방식을 채택하여, 기존의 멀티 헤드 어텐션 아키텍처에 비해 사용자당 KV 캐시 크기를 크게 줄였습니다. 4K 컨텍스트에서 GQA를 사용하는 LLaMA-3 70B의 경우, 동시 접속 사용자당 필요한 KV 캐시 크기는 약 0.5GB에서 1GB 정도로 예상됩니다.

표 2 – KV 캐시 크기

참고: GQA가 없는 구형 아키텍처(예: 초기 GPT 방식의 풀 멀티헤드 어텐션)의 경우 사용자당 KV 캐시 크기가 3~4배 더 클 수 있습니다. 크기를 결정할 때는 항상 특정 모델의 어텐션 구성을 확인하십시오.

이러한 점에서 페이지 어텐션을 적용한 vLLM은 선택적 최적화가 아닌 필수적인 아키텍처 설계 요소가 됩니다. vLLM은 운영체제의 가상 메모리 작동 방식과 동일하게 KV 캐시를 동적 메모리 페이지로 관리함으로써, 미리 할당되었지만 사용되지 않는 캐시 블록으로 인한 VRAM 낭비를 줄입니다. 실제로 이는 특정 하드웨어 구성에서 처리할 수 있는 동시 사용자 수를 3~4배까지 증가시킵니다.

Zadara의 zCompute 클라우드에서는 NVIDIA GPU Operator를 사용하여 디바이스 플러그인을 관리하고 vLLM을 Kubernetes에 컨테이너화된 워크로드로 배포합니다. 이를 통해 구매 시점뿐 아니라 런타임에도 적절한 규모로 유연하게 스케줄링할 수 있습니다.

AI 워크로드에 대한 실용적인 규모 산정 프레임워크

세 가지 핵심 요소를 이해했으니, 이제 Zadara에서 AI 워크로드에 필요한 GPU 인프라 규모를 결정할 때 사용하는 5단계 프레임워크를 살펴보겠습니다.

1단계: AI 워크로드에 대한 요구 사항 명확화

하드웨어 카탈로그를 열기 전에 다음 질문에 답하십시오. 어떤 모델을 선택해야 할까요(모델명 및 파라미터 개수)? 온라인 추론 방식인가요, 배치 처리 방식인가요? 최대 동시 접속 사용자 수(온라인 방식) 또는 시간당 배치 처리량(배치 처리 방식)은 얼마인가요? 최대 컨텍스트 길이(2K/4K/8K/128K 토큰)는 얼마인가요? 품질 요구 사항(FP16 프로덕션 등급 또는 INT8/INT4 허용 가능)은 무엇인가요? 데이터 주권 제약 조건(온프레미스, 특정 지역, 에어갭)은 어떻게 되나요?

마지막으로 언급할 사항은 기업 고객에게 점점 더 중요해지고 있습니다. Zadara의 Sovereign AI Edge Cloud 는 전 세계 수백 개의 엣지 로케이션(온프레미스 또는 파트너 데이터 센터)에 배포되어 있으며, 데이터가 특정 지역이나 시설을 벗어날 수 없는 조직을 위해 특별히 설계되었습니다.

2단계: 총 VRAM 계산

총 VRAM = 모델 가중치 + KV 캐시 + 프레임워크 오버헤드

모델 가중치: 매개변수(B) x 포맷 승수(GB). KV 캐시: 모델 아키텍처(GQA 헤드 수 확인), 컨텍스트 길이 및 동시 사용자 수에 따라 달라집니다. 컨텍스트 길이가 길어질수록 비례적으로 확장됩니다. 프레임워크 오버헤드: 2~4GB(CUDA 런타임, vLLM, Kubernetes 오버헤드).

3단계: GPU 구성 선택

필요한 VRAM 용량을 GPU 클래스 및 구성에 맞춰 선택하세요. Zadara는 다양한 NVIDIA GPU 티어를 지원합니다. 적합한 GPU는 모델 크기, 동시 처리량 및 성능 요구 사항에 따라 달라집니다.

Zadara 팀에 문의하여 현재 사용 가능한 GPU 구성을 확인하십시오. 제품 포트폴리오는 NVIDIA의 로드맵에 따라 지속적으로 발전합니다.

4단계: 성능 검증

구성이 지연 시간 및 처리량 요구 사항을 충족하는지 다시 확인하십시오.

예상 토큰/초 = (총 대역폭 GB/s) / (모델 크기 GB)

온라인 추론 목표의 경우, 첫 토큰 생성 시간(TTFT)은 2초 미만이어야 합니다. 체감 토큰 생성 속도는 사용자당 초당 30개 이상이어야 합니다.

예상치가 부족할 경우 GPU를 추가하거나 양자화를 고려하되, 품질 저하에 따른 절충점을 고객에게 명확히 설명해야 합니다.

5단계: 중복성 추가 및 확장

단일 노드 GPU 배포는 프로덕션 환경에 적합하지 않습니다. 고객에게 직접 제공되는 모든 워크로드의 경우:

고가용성: 로드 밸런서 뒤에 최소 2개의 독립적인 GPU 노드가 필요합니다. Kubernetes 스케줄링: zCompute Kubernetes에서 NVIDIA GPU Operator를 사용하면 노드 수준의 GPU 스케줄링 및 상태 모니터링이 가능합니다. 수평 확장: Zadara의 자동 확장 그룹을 통해 GPU 노드 수를 수요에 따라 유연하게 조정할 수 있습니다.

모델 가중치 및 데이터셋 저장: Zadara의 아키텍처는 두 가지 상호 보완적인 스토리지 계층을 제공합니다. Zadara는 탄력적인 블록 볼륨(zStorage VPSA)을 항상 제공하여 iSCSI를 통해 Kubernetes 영구 볼륨에 연결함으로써 GPU 노드에 일관되고 지연 시간이 짧은 블록 스토리지를 제공합니다. 이는 모델 가중치 저장의 기본 방식이며 콜드 스타트 ​​시 성능 저하를 방지합니다. 대규모 학습 데이터셋, 노드 간 체크포인트 관리 또는 멀티테넌트 모델 레지스트리와 같이 높은 처리량의 공유 파일 스토리지가 필요한 워크로드의 경우, Zadara는 애플리케이션 요구 사항에 따라 DDN EXAScaler 또는 Zadara 자체 파일 시스템을 통합합니다. 이러한 공유 스토리지 옵션 중 어떤 것을 선택할지는 워크로드의 특정 성능 프로필, 규모 및 데이터 액세스 패턴에 따라 결정됩니다.

사례 연구: 금융 서비스 고객을 위한 주권형 AI 플랫폼

이를 구체화하기 위해, 규제 산업 고객을 위해 설계한 배포 사례를 대표하는 규모 산정 예시를 보여드리겠습니다.

고객 프로필: 지역 금융 서비스 기관. 내부 규정 준수 문서 분석 및 구조화된 질의응답을 위해 비공개 LLM(법률 문서 관리자)이 필요합니다. 데이터는 반드시 해당 기관의 관할 구역 내에 유지되어야 합니다. 최대 동시 분석가 수 40명. 컨텍스트 길이 최대 8,192 토큰(장문의 규제 문서). 응답 시간: 첫 번째 토큰 수신 시간(Time to First Token) 2초 미만.

모델 선정: INT8의 LLaMA-3 70B (구조화된 문서 질의응답에 충분한 품질, 온프레미스 환경에 배포 가능).

2단계: VRAM 계산

모델 가중치(INT8): 70GB. KV 캐시(사용자 40명, 8K 컨텍스트, 8개의 KV 헤드를 사용하는 GQA): 약 25GB. 8K 컨텍스트에서 사용자당 캐시 용량은 4K 컨텍스트 추정치의 약 두 배이므로, 사용자 40명이 각각 약 0.6GB를 사용하면 총 약 25GB가 됩니다. 프레임워크 오버헤드: 4GB.

필요한 총 VRAM 용량: 약 99GB

3단계: GPU 선택

필요 사양: 약 99GB VRAM.

옵션 A: NVIDIA RTX PRO 6000 Blackwell Server Edition 노드(4 x 96GB = 총 384GB). 70GB INT8 모델은 단일 GPU에 탑재 가능하며, 해당 카드에는 KV 캐시를 위한 26GB의 여유 공간이 있습니다. 텐서 병렬 처리를 2개의 GPU에 분산하면 모델은 각 GPU에 35GB씩 할당되어 KV 캐시 및 프레임워크 오버헤드를 위해 GPU당 약 61GB가 남게 됩니다. 이는 8K 컨텍스트에서 40명의 동시 사용자를 처리하기에 충분합니다.

옵션 B: NVIDIA H200 GPU(8 x 141GB = 총 1,128GB)가 장착된 HGX 서버 노드. 향후 확장, 더 높은 동시 처리 용량 확보, 그리고 고객이 더 큰 모델이나 더 긴 컨텍스트 윈도우로 확장할 계획이 있는 경우에 권장됩니다. 텐서 병렬 처리(tp=2)를 사용하면 각 GPU 샤드는 35GB이며, GPU당 100GB 이상의 여유 용량을 제공합니다.

4단계: 성능 검증 (NVIDIA RTX PRO 6000 Blackwell, tp=2)

총 대역폭: 2 x 1,792 GB/s = 3,584 GB/s
모델 분할 용량: 70GB / 2 = 카드당 35GB
토큰/초 추정치: 3,584 / 70 = 약 51 토큰/초 (총 처리량)
사용자당 (일시 접속 40명, 일괄 처리 시): 초당 약 40-50 토큰
이 부하에서의 TTFT: 약 1.2초 (목표 범위 내)

5단계: 전체 아키텍처 설계

컴퓨팅: Zadara zCompute에 설치된 동일한 NVIDIA RTX PRO 6000 Blackwell Server Edition 노드 2개(고가용성 확보를 위한 액티브/액티브 구성). 오케스트레이션: Zadara zCompute에서 NVIDIA GPU Operator를 사용하는 Kubernetes. 서비스: 페이지 어텐션 및 텐서 병렬 처리를 지원하는 vLLM. 블록 스토리지: 모델 가중치 저장을 위한 Zadara zStorage VPSA(NVMe 기반, iSCSI를 통해 Kubernetes 영구 볼륨에 제공). 공유 스토리지: 데이터셋 접근 패턴 및 처리량 요구 사항에 따라 DDN EXAScaler 또는 Zadara 파일 시스템 선택. 네트워킹: 인터넷 외부 연결이 없는 프라이빗 엔드포인트를 갖춘 격리된 Zadara VPC. 모니터링: GPU 사용률, TTFT, 토큰/초, VRAM 사용량 모니터링을 위한 Prometheus + Grafana.

결과: 동시 사용자 40명, TTFT(처리 시간)는 일관적으로 1.5초 미만, 고객 관할 구역 내에서 완전한 데이터 주권 유지, 퍼블릭 클라우드 API에 대한 의존성 제로.

Spectrum-X 네트워킹을 사용하여 AI 워크로드를 클러스터 구성으로 확장하기

단일 노드 GPU 배포는 대부분의 엔터프라이즈 추론 워크로드를 무리 없이 처리합니다. 하지만 NVIDIA Spectrum-X 네트워킹을 사용하는 멀티 노드 GPU 클러스터가 적합한 시나리오도 있습니다.

기초 모델 미세 조정: 70억 개 이상의 매개변수를 가진 모델을 학습하거나 미세 조정하려면 여러 GPU에서 동시에 지속적이고 연산 집약적인 작업이 필요합니다. 이때 GPU 노드 간 네트워크 대역폭이 주요 제약 조건이 됩니다. Spectrum-X의 51.2Tb/s 스위칭 용량과 BlueField-3의 400GbE RoCE 연결은 이러한 병목 현상을 해소합니다.

초대형 모델(400B 이상): LLaMA 405B와 같은 모델이나 독자적인 대규모 아키텍처는 수백 GB의 VRAM과 텐서 병렬 처리를 위한 높은 GPU 간 통신량을 필요로 합니다. Spectrum-X의 2계층 리프/스파인 아키텍처는 최대 8,000개의 GPU를 지원하므로 네트워크 용량이 클러스터 크기의 한계가 되지 않습니다.

대규모 고동시 추론: 여러 노드에 분산된 모델을 사용하여 수많은 동시 사용자를 처리할 때, KV 캐시 접근 패턴은 GPU 간에 상당한 동서 트래픽을 발생시킵니다. 모든 토큰 생성 단계에서는 캐시된 키-값 쌍을 읽고 업데이트해야 하며, 이러한 캐시가 여러 노드에 분산되어 있는 경우 네트워크 지연 시간과 대역폭은 최초 토큰 획득 시간(Time to First Token, TFT)과 사용자별 처리량에 직접적인 영향을 미칩니다. Spectrum-X의 적응형 라우팅 및 RoCE 혼잡 제어는 다수의 사용자가 동시에 접속하는 상황에서도 노드 간 KV 캐시 트래픽 흐름을 예측 가능하게 유지하여, 대규모 환경에서 사용자 경험을 저하시키는 지연 시간 급증 현상을 방지합니다.

대용량 멀티테넌트 추론 플랫폼: 완전히 격리된 테넌트에서 수백 명의 동시 사용자를 지원하려면 GPU 확장성과 엄격한 성능 격리가 모두 필요합니다. Zadara의 GPU-Net 기술은 테넌트 격리를 자동으로 처리합니다. 각 테넌트의 GPU 통신 경로는 수동 네트워크 구성 없이 프로비저닝되며, 인접 테넌트의 활동에 관계없이 성능 일관성이 보장됩니다.

이러한 사용 사례에서 zCompute 플랫폼은 단일 노드 배포와 클러스터 배포 모두에서 동일한 관리 인터페이스, 동일한 VPC 및 네트워킹 모델, 그리고 동일한 Kubernetes 네이티브 운영을 유지합니다. 운영 복잡성을 늘리지 않고도 하드웨어를 확장할 수 있습니다.

Zadara는 AI 워크로드를 위한 AI 팩토리 플랫폼입니다.

개별 GPU 크기 결정 그 이상으로, Zadara의 더 큰 가치는 NVIDIA가 AI 팩토리라고 부르는 것을 구현하는 데 있습니다. AI 팩토리란 반복 가능하고 생산 수준의 방식으로 AI 모델을 개발, 학습, 배포 및 유지 관리할 수 있는 확장 가능하고 자동화된 인프라를 의미합니다.

Zadara는 이러한 구현을 가능하게 하는 소프트웨어 플랫폼 및 오케스트레이션 계층을 제공합니다. 여기에는 탄력적인 GPU 컴퓨팅을 위한 zCompute, 탄력적인 블록 볼륨을 위한 Zadara zStorage VPSA와 고처리량 공유 스토리지를 위한 DDN EXAScaler 또는 Zadara 파일 시스템(애플리케이션 요구 사항에 따라 선택)을 결합한 계층형 스토리지 아키텍처, 자동화된 Spectrum-X 네트워킹을 위한 GPU-Net, 그리고 특정 지역 또는 시설 내에 데이터를 유지해야 하는 배포를 위한 Sovereign AI Edge Cloud가 포함됩니다. 이러한 구성 요소는 처음부터 통합되어 제공되며, 개별 공급업체 제품을 조합하여 사용하는 방식이 아닙니다.

AI 워크로드 규모 산정에 대한 올바른 논의를 시작하기

AI 워크로드에 적합한 GPU 인프라 규모를 결정하는 것은 기술적인 작업인 동시에 탐색 과정이기도 합니다. 워크로드 유형, 모델 크기, 동시 실행 수, 컨텍스트 지속 시간, 품질 요구 사항, 리소스 주권 제약 조건 등 올바른 질문을 던지는 것이 효율적인 배포와 성능 저하 또는 과도한 투자로 이어지는 차이를 만드는 핵심 요소입니다.

Zadara의 zCompute 클라우드는 워크로드 변화에 따라 적절한 규모로 시작하여 수평적으로 확장할 수 있는 유연성을 제공합니다. 추론에 최적화된 NVIDIA RTX PRO 6000 Blackwell GPU 노드부터 Spectrum-X 네트워크 기반의 HGX 클러스터(NVIDIA H200 GPU 및 NVIDIA B300 GPU)에 이르는 다양한 GPU 구성, 긴밀하게 통합된 계층형 엔터프라이즈 스토리지, 그리고 수백 개의 엣지 로케이션에 걸친 독립적인 배포 옵션을 통해 인프라가 워크로드에 맞춰 조정됩니다.

GPU 인프라 구축을 계획 중이시고 특정 워크로드 매개변수를 사용하여 이 사이징 프레임워크를 실행해 보고 싶으시다면 Zadara 팀에 문의해 주세요. 저희가 기꺼이 도와드리겠습니다.

© 2026 Zadara. 모든 권리 보유. 본 문서는 정보 제공 목적으로만 제공되며 법률, 재정 또는 전문적인 조언을 구성하지 않습니다. Zadara의 사전 서면 허가 없이는 본 출판물의 어떤 부분도 복제 또는 배포할 수 없습니다. 모든 제품명, 로고 및 브랜드는 해당 소유자의 자산이며, 이러한 상표의 사용은 식별 목적으로만 사용되며 보증을 의미하지 않습니다.