NVIDIA Spark급 소형 AI 노드와 데스크사이드 클러스터

랙 서버만이 정답이던 시대가 흔들리고 있다

대형 언어모델을 로컬에서 돌리겠다고 마음먹으면 머릿속에 가장 먼저 떠오르는 그림은 대개 비슷합니다. 4U나 8U짜리 거대한 GPU 서버, 굵은 전원 케이블, 뜨거운 배기, 귀를 찌르는 팬 소리, 그리고 서버실 한쪽을 차지한 랙입니다. H100이나 H200, B200이 여러 장 꽂힌 HGX 서버는 확실히 강력합니다. 하지만 모든 팀이 처음부터 그런 장비를 사야 하는 것은 아닙니다.

최근에는 다른 선택지가 생겼습니다. 책상 위에 올려둘 수 있는 소형 AI 노드, 데스크사이드 워크스테이션, 그리고 이 작은 노드를 두 대, 세 대, 네 대씩 묶어 쓰는 방식입니다. NVIDIA DGX Spark 같은 장비가 상징하는 흐름이 바로 이것입니다. 겉모습은 Mac mini보다 조금 더 진지한 미니 워크스테이션처럼 보이지만, 안쪽에는 Grace Blackwell 계열 SoC, 대용량 통합 메모리, NVIDIA 소프트웨어 스택, 고속 네트워크 포트가 들어 있습니다.

이 장에서는 이런 질문에 답해보겠습니다. "대형 랙 서버 대신 Spark급 소형 AI 노드를 여러 대 묶으면 얼마나 실용적일까?" 결론부터 말하면, 소형 노드 클러스터는 거대한 GPU 서버를 완전히 대체하지는 못합니다. 그러나 개발, 검증, 에이전트 실험, 장기 컨텍스트 테스트, 사내 프라이빗 AI 실험실 용도로는 매우 매력적인 중간 지대가 됩니다. 한마디로 말해, 클라우드와 랙 서버 사이에 놓인 '책상 위의 작은 클러스터'입니다.

Spark급 노드가 다른 이유: VRAM이 아니라 통합 메모리로 접근한다

일반적인 RTX 4090이나 RTX 5090 기반 워크스테이션을 생각해봅시다. GPU에는 24GB나 32GB의 VRAM이 있고, CPU 쪽에는 별도의 시스템 메모리가 있습니다. LLM 추론에서는 모델 가중치, KV 캐시, 활성화 버퍼가 되도록 GPU VRAM 안에 있어야 빠릅니다. VRAM 밖으로 밀려나 CPU 메모리로 오프로드되면, 모델은 돌아갈 수는 있어도 속도는 급격히 떨어집니다.

Spark급 소형 AI 노드는 이 구도를 조금 다르게 봅니다. DGX Spark는 GB10 Grace Blackwell 기반 시스템으로, CPU와 GPU가 하나의 대용량 통합 메모리 풀을 공유하는 형태에 가깝습니다. 공개된 분석 자료에 따르면 DGX Spark는 128GB LPDDR5x 통합 메모리와 4TB NVMe SSD를 갖춘 소형 AI 개발 장비로 소개되었고, NVIDIA는 이를 로컬에서 최대 200B급 모델을 다루는 개인 AI 슈퍼컴퓨터로 포지셔닝했습니다¹.

여기서 중요한 단어는 '128GB'보다 '통합'입니다. 물론 이 메모리가 H100의 HBM처럼 초고대역폭인 것은 아닙니다. 하지만 하나의 24GB GPU에 억지로 모델을 욱여넣는 방식과 달리, 훨씬 큰 메모리 공간을 모델과 런타임이 함께 활용할 수 있습니다. NVIDIA가 Grace Hopper와 Grace Blackwell 계열에서 강조하는 NVLink-C2C 기반 CPU-GPU 메모리 공유 역시 같은 방향의 기술입니다. NVIDIA의 설명에 따르면 GH200 같은 통합 메모리 플랫폼에서는 GPU 메모리와 CPU 메모리를 더 긴밀하게 연결해, GPU 단독 메모리 한계를 넘는 모델 로딩이나 KV 캐시 오프로드를 다룰 수 있습니다².

다만 통합 메모리는 마법의 무한 VRAM이 아닙니다. 이 점을 반드시 기억해야 합니다. 메모리 용량이 넓어지는 대신, 메모리 대역폭과 지연시간은 discrete GPU의 HBM 또는 GDDR 기반 VRAM과 다릅니다. 그래서 Spark급 노드는 "엄청나게 빠른 생성 속도"보다 "큰 모델을 로컬에서 개발 가능한 형태로 올려볼 수 있는 능력"에 더 가깝습니다.

Grace/Blackwell 소형 노드가 잘하는 일

DGX Spark 같은 장비의 매력은 단순히 스펙표에 있지 않습니다. 진짜 장점은 하드웨어, 드라이버, CUDA, 컨테이너, 샘플 플레이북, 원격 접속 도구가 한 덩어리로 맞춰져 있다는 데 있습니다. 소비자용 멀티 GPU 워크스테이션은 부품을 고르고, 케이스 간섭을 확인하고, 전원 용량을 계산하고, 발열을 잡고, 드라이버와 CUDA 버전을 맞추는 일이 절반입니다. 반면 Spark급 노드는 '작은 AI 어플라이언스'에 가깝습니다.

개발자에게 이 차이는 큽니다. 모델을 다운로드하고, 컨테이너를 띄우고, JupyterLab이나 터미널에서 실험을 시작하는 시간이 줄어듭니다. CUDA 기반 라이브러리와 NVIDIA 컨테이너 생태계를 그대로 활용할 수 있기 때문에, 나중에 H100/H200/B200 클라우드 인스턴스나 사내 DGX/HGX 서버로 옮길 때도 환경 차이가 상대적으로 작습니다. 이것은 Apple Silicon이나 AMD Strix Halo 계열 통합 메모리 시스템과 비교했을 때 Spark급 노드가 갖는 가장 큰 무기입니다. 즉, "로컬에서 돌려본 코드가 데이터센터 NVIDIA GPU에서도 같은 방식으로 움직일 가능성"이 높습니다.

Spark급 노드가 특히 어울리는 작업은 다음과 같습니다.

• 30B~120B급 양자화 모델을 로컬에서 실험하고 프롬프트, RAG, 에이전트 워크플로를 개발하는 일

• 긴 컨텍스트, 큰 KV 캐시, 다중 도구 호출처럼 메모리를 많이 먹는 워크로드를 작은 팀이 반복 테스트하는 일

• 클라우드에 올리기 전에 CUDA, TensorRT-LLM, vLLM, NIM, 컨테이너 기반 배포 흐름을 사전 검증하는 일

• 민감한 문서나 내부 코드를 외부 클라우드로 보내지 않고 로컬에서 모델 동작을 확인하는 일

반대로 단일 사용자 채팅에서 "초당 토큰을 최대한 많이 뽑아내는 것"이 목표라면, 같은 가격대의 다중 RTX 3090/4090/5090 워크스테이션이 더 빠를 수 있습니다. 여러 비교 벤치마크에서 DGX Spark는 큰 모델을 올리는 능력과 프롬프트 처리에서는 강점을 보이지만, 토큰 생성 단계에서는 메모리 대역폭의 영향을 크게 받는 것으로 보고되었습니다³.

단일 고메모리 노드, 2노드 클러스터, 여러 소형 노드 묶음

소형 AI 노드를 검토할 때는 "몇 대를 살 것인가"보다 먼저 "무슨 단계를 해결할 것인가"를 정해야 합니다. 같은 Spark급 장비라도 한 대를 쓰는 경우와 두 대를 직접 연결하는 경우, 네 대를 스위치로 묶는 경우는 완전히 다른 시스템입니다.

단일 Spark급 노드는 "큰 모델을 한 번 올려보고 개발하는 장비"로 볼 수 있습니다. 예를 들어 70B 모델을 4비트 또는 8비트로 돌리고, 100K 이상의 긴 컨텍스트를 테스트하고, 문서 검색 시스템과 연결하는 정도라면 한 대로도 충분히 많은 실험을 할 수 있습니다. 여기서 중요한 것은 최대 파라미터 수보다 실제 컨텍스트 길이와 동시 사용자 수입니다. 모델 가중치가 메모리에 들어가도, KV 캐시가 커지면 금방 여유 공간이 사라집니다.

2노드 구성은 이야기가 달라집니다. NVIDIA의 DGX Spark 문서는 두 대의 Spark 시스템을 QSFP/CX7 케이블로 직접 연결해 가상 클러스터처럼 구성하는 절차를 안내합니다. 이 구성은 Ubuntu 24.04 이상, NVIDIA 드라이버, MPI, NCCL 2.28.3을 전제로 하며, GPU 간 collective operation을 NCCL로 처리하는 방식입니다⁴. 즉, 두 대를 그냥 같은 공유기에 꽂는다고 '큰 GPU 한 장'이 되는 것이 아닙니다. SSH 키, 네트워크 인터페이스, NCCL 통신, 분산 실행 백엔드를 맞춰야 합니다.

여러 소형 노드를 묶는 방식은 더 흥미롭지만 더 까다롭습니다. 일부 보도에서는 DGX Spark가 최대 네 대 연결 구성으로 확장되어 512GB급 공유 메모리 풀을 구성할 수 있으며, 두 대는 직접 연결, 세 대는 링, 네 대는 RoCE 200GbE 스위치가 필요할 수 있다고 설명합니다⁵. 여기까지 오면 "책상 위 장비"라기보다는 "작은 클러스터"입니다. 네트워크 스위치, 케이블, 주소 계획, 컨테이너 레지스트리, 공유 스토리지, 잡 스케줄러까지 신경 써야 합니다.

모델 크기별로 보는 현실적인 선택

모델 크기를 기준으로 보면 Spark급 노드의 위치가 더 선명해집니다. 아래 표는 정답표가 아니라 의사결정용 지도입니다. 양자화 방식, 컨텍스트 길이, 배치 크기, 프레임워크 최적화 상태에 따라 실제 결과는 달라집니다.

여기서 가장 중요한 경계선은 70B와 120B 사이입니다. 70B 모델은 중고 RTX 3090 두 장, RTX 4090 두 장, RTX 5090 조합 등으로도 꽤 현실적으로 접근할 수 있습니다. 그러나 120B 이상으로 가면 소비자용 GPU에서는 VRAM을 맞추기 위해 카드 수가 늘어나고, 케이스와 전원, 발열이 급격히 어려워집니다. 이때 Spark급 단일 노드는 조용하고 작은 몸집으로 큰 메모리 공간을 제공한다는 장점이 생깁니다.

하지만 속도는 별개의 문제입니다. 3×RTX 3090 같은 DIY 멀티 GPU 구성은 전력과 소음이 크고 설정이 번거롭지만, 메모리 대역폭과 병렬 연산 측면에서 Spark급 통합 메모리 시스템보다 토큰 생성이 훨씬 빠를 수 있습니다. 한 비교 자료에서는 GPT-OSS 120B 계열 워크로드에서 3×RTX 3090 구성이 DGX Spark보다 높은 토큰 생성 성능을 보였고, DGX Spark는 프롬프트 처리와 CUDA 생태계 접근성 측면에서 장점을 보였습니다⁶.

따라서 선택 기준은 단순합니다. "큰 모델을 편하게 올려 개발하고 싶다"면 Spark급 노드가 매력적입니다. "한 명 또는 여러 명에게 빠르게 토큰을 뽑아 서비스해야 한다"면 멀티 GPU 서버나 클라우드 GPU가 더 적합합니다.

소형 노드 클러스터의 첫 번째 병목: 네트워크

소형 AI 노드를 두 대 이상 묶는 순간, 가장 먼저 부딪히는 벽은 네트워크입니다. 단일 노드 안에서는 GPU와 메모리 사이의 대역폭이 시스템 내부 문제입니다. 하지만 노드가 나뉘면 레이어 출력, 텐서 조각, attention 관련 중간값, 동기화 신호가 네트워크를 건너갑니다.

DGX Spark의 2노드 직접 연결 문서가 QSFP/CX7 케이블과 NCCL 테스트를 강조하는 이유가 여기에 있습니다. NVIDIA 문서에 따르면 Spark의 CX-7 포트는 이더넷 구성만 지원하며, 두 노드 연결 후 ping, SSH, NCCL 테스트를 통해 실제 GPU 간 통신이 정상인지 확인해야 합니다⁴. 즉, 케이블을 꽂았다고 끝이 아니라 "분산 LLM이 요구하는 통신 패턴을 충분히 버틸 수 있는가"를 검증해야 합니다.

네트워크 병목은 특히 텐서 병렬에서 두드러집니다. 텐서 병렬은 한 레이어 안의 행렬 연산을 여러 GPU 또는 여러 노드로 나누기 때문에, 토큰을 생성할 때마다 GPU들 사이에 자주 통신합니다. 단일 서버 안의 NVLink/NVSwitch라면 그나마 괜찮지만, 노드 간 이더넷에서는 지연시간과 대역폭이 민감해집니다. 반대로 파이프라인 병렬이나 레이어 분할은 통신 빈도가 낮아 네트워크가 느려도 비교적 견딜 수 있지만, GPU들이 동시에 바쁘게 일하지 못해 성능 효율이 떨어질 수 있습니다.

현실적인 판단은 이렇습니다. 두 대의 소형 노드를 묶어 70B나 120B 모델을 개발용으로 돌리는 것은 충분히 의미가 있습니다. 하지만 4대 이상을 묶어 "HGX 한 대처럼" 쓰겠다는 기대는 조심해야 합니다. 네트워크가 고속이라고 해도, 노드 바깥으로 나가는 순간 단일 서버 내부의 NVLink/NVSwitch와 같은 세계가 아닙니다.

두 번째 병목: 스토리지와 모델 동기화

대형 모델을 여러 노드에서 실행할 때 의외로 자주 발목을 잡는 것이 스토리지입니다. 70B 모델 하나만 해도 양자화 형식에 따라 수십 GB입니다. 120B, 200B, MoE 모델로 가면 모델 파일은 100GB를 훌쩍 넘기기 쉽습니다. 여기에 여러 버전의 체크포인트, tokenizer, LoRA 어댑터, TensorRT 엔진, vLLM 캐시, 평가 데이터셋까지 쌓이면 4TB SSD도 금방 좁아집니다.

소형 노드 클러스터에서 스토리지는 세 가지 방식 중 하나로 설계합니다. 첫 번째는 모든 노드에 같은 모델 파일을 복사해 두는 방식입니다. 단순하고 빠르지만, 모델 버전이 바뀔 때마다 동기화가 귀찮습니다. 두 번째는 NAS나 NFS 같은 공유 스토리지를 쓰는 방식입니다. 관리가 편하지만 모델 로딩 시 네트워크 스토리지가 병목이 될 수 있습니다. 세 번째는 각 노드에 NVMe를 두고, rsync나 객체 스토리지 캐시를 이용해 필요한 모델만 배포하는 방식입니다. 실제 운영에서는 세 번째 방식이 가장 균형 잡힌 경우가 많습니다.

문제는 모델 파일만이 아닙니다. 분산 서빙에서는 모든 노드가 같은 컨테이너 이미지, 같은 CUDA/NCCL 버전, 같은 Python 패키지, 같은 모델 revision을 봐야 합니다. 한 노드만 토크나이저 버전이 다르거나, 한 노드만 커널 최적화가 다르면 이상한 오류가 납니다. 단일 워크스테이션에서는 "어제는 됐는데 오늘은 안 된다" 정도로 끝나지만, 클러스터에서는 "1번 노드는 되고 2번 노드는 안 된다"가 됩니다. 이 순간부터 우리는 개발자가 아니라 작은 데이터센터 운영자가 됩니다.

세 번째 병목: 전력, 소음, 공간

소형 노드는 작고 조용해 보입니다. 그래서 여러 대를 쌓아도 부담이 없을 것처럼 느껴집니다. 하지만 네 대를 묶는 순간 이야기가 달라집니다. 한 대당 200W 안팎의 전력만 먹는다고 해도 네 대면 800W입니다. 여기에 스위치, NAS, 모니터링 장비, UPS까지 더하면 작은 전열기 하나를 계속 켜두는 것과 비슷해집니다.

소음도 누적됩니다. 단일 노드는 조용해도 네 대가 동시에 긴 컨텍스트 추론을 돌리면 팬이 올라갑니다. 사무실 책상 위에서는 견딜 만해도, 조용한 연구실이나 회의실에서는 거슬릴 수 있습니다. 발열은 더 직접적인 문제입니다. 작은 방에서 1kW 가까운 장비가 장시간 동작하면 여름에는 냉방 비용도 인프라 비용이 됩니다.

공간 역시 단순히 본체 크기만 보면 안 됩니다. 고속 DAC 케이블은 굵고 잘 휘지 않습니다. QSFP 케이블, 전원 어댑터, 10GbE/200GbE 스위치, NAS, UPS를 놓기 시작하면 책상 위 '미니 클러스터'는 금방 작은 랙처럼 변합니다. 따라서 세 대 이상을 운용할 계획이라면 처음부터 선반, 케이블 라벨링, 전원 분배, 통풍 방향을 설계하는 것이 좋습니다.

DGX/HGX 서버, 클라우드 GPU, 소형 노드 클러스터 비교

이제 세 가지 큰 선택지를 나란히 놓고 봅시다. 첫째는 DGX/HGX 같은 전용 GPU 서버입니다. 둘째는 클라우드 H100/H200/B200 인스턴스입니다. 셋째는 Spark급 소형 AI 노드 클러스터입니다. 셋 다 답이 될 수 있지만, 답이 되는 상황이 다릅니다.

DGX/HGX 서버는 강력합니다. 특히 8×H100/H200/B200 구성은 단일 노드 안에서 GPU들이 고속으로 연결되어 있어 대형 모델 서빙과 파인튜닝에 유리합니다. 하지만 가격, 전력, 냉각, 조달, 유지보수 난도가 높습니다. GPU 서버를 사는 순간 우리는 모델 개발뿐 아니라 서버 운영도 함께 사는 것입니다.

클라우드는 반대입니다. 클릭 몇 번으로 H100, H200, B200을 쓸 수 있고, 최신 GPU를 빠르게 테스트할 수 있습니다. 그러나 장시간 켜두면 비용이 무섭게 쌓입니다. 데이터셋을 올리고 내리는 egress 비용, 스토리지 비용, 예약 실패, 인스턴스 가용성도 고려해야 합니다. 특히 매일 24시간 돌아가는 사내 챗봇이나 RAG 서비스라면 클라우드 비용이 온프레미스 장비 가격을 추월하는 순간이 옵니다.

Spark급 소형 노드 클러스터는 이 둘 사이에 있습니다. 절대 성능은 HGX 서버보다 낮지만, 구매와 설치의 심리적 장벽이 낮고 로컬 개발 경험이 좋습니다. 클라우드처럼 매시간 과금되지 않고, 랙 서버처럼 전용 서버실이 필요하지도 않습니다. 다만 노드 수가 늘면 운영 복잡도가 빠르게 올라가므로, "작게 시작해서 어디까지 커질지"를 미리 정해야 합니다.

소형 노드 클러스터를 고를 때의 실전 기준

소형 AI 노드를 살지, 멀티 GPU 워크스테이션을 만들지, 클라우드를 쓸지 결정할 때는 스펙보다 워크플로를 먼저 보아야 합니다. 다음 질문에 답하면 선택이 쉬워집니다.

첫째, 모델이 주로 메모리에 막히는가, 속도에 막히는가? 120B급 모델을 로컬에서 자주 열어봐야 하고, 동시 사용자는 많지 않다면 Spark급 노드가 좋습니다. 반대로 70B 모델을 여러 사용자에게 빠르게 제공해야 한다면 RTX 4090/5090 멀티 GPU나 H100 계열 서버가 더 나을 수 있습니다.

둘째, CUDA 호환성이 중요한가? NVIDIA 생태계의 TensorRT-LLM, vLLM, NIM, NCCL, Docker/NGC 컨테이너와 맞춰 가야 한다면 Spark급 노드는 Apple Silicon이나 AMD 통합 메모리 시스템보다 유리합니다. 반대로 llama.cpp 기반 GGUF 모델을 단일 사용자로 돌리는 것이 대부분이라면 Mac Studio나 고성능 소비자 GPU도 좋은 선택입니다.

셋째, 장비를 누가 운영할 것인가? 연구원이 직접 장비를 관리해야 한다면 단일 Spark급 노드나 단순한 2노드 구성이 좋습니다. 사내 인프라 팀이 있고, 모니터링과 백업, 장애 대응 체계를 만들 수 있다면 4노드 소형 클러스터나 Kubernetes 기반 운영도 고려할 수 있습니다.

넷째, 실패해도 되는 실험인가, 항상 살아 있어야 하는 서비스인가? 실험 장비는 가끔 재부팅해도 됩니다. 프로덕션 서비스는 안 됩니다. 소형 노드 클러스터는 실험에는 매력적이지만, 상시 서비스에는 로드밸런싱, 헬스체크, 롤링 업데이트, 장애 격리가 필요합니다. 이 부분은 다음 장에서 Kubernetes와 서빙 플랫폼을 다루며 더 구체적으로 이어갈 것입니다.

추천 아키텍처: 개발은 소형 노드, 검증은 클라우드, 운영은 전용 서버

가장 현실적인 전략은 하나의 인프라에 모든 것을 맡기지 않는 것입니다. 개발, 검증, 운영을 나누면 각 장비의 장점이 살아납니다.

개발 단계에서는 Spark급 소형 노드나 고VRAM 워크스테이션을 씁니다. 여기서 프롬프트 템플릿, RAG 파이프라인, 에이전트 도구 호출, 모델 양자화, 컨텍스트 길이, KV 캐시 사용량을 반복적으로 실험합니다. 민감한 문서도 로컬에서 다룰 수 있고, 클라우드 비용을 걱정하지 않고 밤새 테스트를 돌릴 수 있습니다.

검증 단계에서는 클라우드 H100/H200/B200을 씁니다. 큰 배치, 여러 동시 사용자, 장기 부하 테스트, 더 큰 모델 후보, 다른 정밀도 설정을 빠르게 확인합니다. 클라우드는 "계속 켜두는 곳"이 아니라 "비싼 실험실을 필요한 시간만 빌리는 곳"으로 쓰면 비용 대비 효과가 좋습니다.

운영 단계에서는 요구 조건에 따라 전용 GPU 서버나 Kubernetes 클러스터로 갑니다. 상시 서비스라면 장애 대응, 배포 자동화, 모니터링, 인증, 로깅, 비용 예측이 중요합니다. 소형 노드에서 검증한 컨테이너와 모델 설정을 운영 클러스터로 옮기면 개발과 운영 사이의 간극을 줄일 수 있습니다.

이 하이브리드 전략은 특히 작은 팀에 잘 맞습니다. 처음부터 수억 원대 서버를 들이지 않아도 됩니다. 먼저 소형 노드 한 대로 워크플로를 만들고, 필요하면 두 대로 분산 추론을 익히고, 정말 성능이 필요한 순간에 클라우드나 전용 서버로 확장하면 됩니다.

Spark급 장비를 사도 되는 사람, 아직 아닌 사람

Spark급 소형 AI 노드는 멋진 장비입니다. 하지만 모든 사람에게 필요한 장비는 아닙니다. 사도 되는 사람은 비교적 분명합니다. 대형 모델을 로컬에서 자주 실험해야 하고, CUDA 생태계가 필요하며, 랙 서버를 둘 공간이나 예산은 없지만 클라우드에 모든 데이터를 올리기도 부담스러운 팀입니다. 특히 AI 에이전트, RAG, 긴 컨텍스트, 사내 문서 분석, 모델 서빙 PoC를 자주 하는 개발팀이라면 만족도가 높을 가능성이 큽니다.

반대로 단순히 "가장 빠른 로컬 챗봇"을 원한다면 다시 생각해봐야 합니다. 7B, 14B, 32B 모델 중심이라면 RTX 4090/5090 한 장이나 Mac Studio, 혹은 기존 워크스테이션이 더 경제적일 수 있습니다. 70B 모델을 빠르게 돌리는 것이 목표라면 중고 RTX 3090 두세 장이나 4090 다중 구성도 여전히 강력합니다. 405B 이상 모델을 안정적으로 서빙하거나 파인튜닝해야 한다면 소형 노드 클러스터보다 HGX 서버나 클라우드가 맞습니다.

중요한 것은 장비의 이름이 아니라 병목의 위치입니다. 메모리가 병목이면 통합 메모리 소형 노드가 빛납니다. 대역폭과 처리량이 병목이면 HBM/NVLink 기반 서버가 빛납니다. 실험 속도와 구매 민첩성이 병목이면 클라우드가 빛납니다. 그리고 데이터 통제와 반복 개발이 병목이면 로컬 소형 노드가 빛납니다.

작은 클러스터는 작은 데이터센터다

Spark급 소형 AI 노드를 여러 대 묶는 일은 생각보다 즐겁습니다. 두 대를 케이블로 연결하고, NCCL 테스트가 통과하고, vLLM이나 Ray가 두 노드를 인식하는 순간 작은 승리감이 있습니다. 마치 책상 위에 나만의 AI 데이터센터가 생긴 것 같습니다.

하지만 그때부터 데이터센터의 문제도 함께 따라옵니다. 네트워크가 느리면 모델이 멈칫거립니다. 스토리지 동기화가 어긋나면 한 노드만 다른 모델을 봅니다. 전원이 불안하면 긴 추론 작업이 날아갑니다. 팬 소음이 커지면 회의실에서 쫓겨납니다. 로그를 안 모으면 장애 원인을 알 수 없습니다.

그래서 소형 노드 클러스터를 바라보는 올바른 태도는 낭만과 현실을 동시에 갖는 것입니다. 대형 랙 서버만이 답은 아닙니다. 그러나 작은 장비를 여러 대 묶는다고 자동으로 거대한 GPU 하나가 되는 것도 아닙니다. 소형 AI 노드는 대형 모델 시대의 새로운 선택지입니다. 특히 개발자와 작은 팀에게 "직접 만질 수 있는 대형 모델 인프라"를 제공한다는 점에서 의미가 큽니다.

다음 단계는 이 작은 클러스터를 어떻게 운영 체계 안으로 끌어넣느냐입니다. 컨테이너를 어떻게 배포하고, GPU를 어떻게 스케줄링하며, 모델 서버를 어떻게 업데이트하고, 장애가 났을 때 트래픽을 어디로 보낼 것인가. 이제 이야기는 자연스럽게 Kubernetes와 서빙 플랫폼으로 넘어갑니다.

참고

¹NVIDIA DGX Spark Review: Pros, Cons & Performance Benchmarks

²CPU-GPU 메모리 공유를 통한 대규모 LLM 추론 및 KV 캐시 오프로드 가속화

³DGX Spark vs Mac Studio & Halo: Benchmarks & Alternatives

⁴Spark Stacking — DGX Spark User Guide

⁵Nvidia DGX Spark Now Supports Four-Node Linking and 512GB Shared RAM

⁶DGX Spark vs Mac Studio & Halo: Benchmarks & Alternatives