DGX Spark 두 대로 시작한 로컬 AI — 책상 위 AI 서버 사용기

GA4를 대화로 분석하기와 같은 도구들을 만들어 쓰면서 클로드 코드 같은 AI 에이전트에게 일을 맡기는 시간이 부쩍 늘었다. 그러다 보니 자연스럽게 궁금해졌다. 공개된 AI 모델을 책상 위에서 직접 돌리면 무엇이 달라질까. 그 궁금증을 시작으로 결국 DGX Spark 계열 컴퓨터 두 대를 구매했다. 이번 글은 새 컴퓨터 산 김에 적는 로컬 AI 이야기의 첫 글로, DGX Spark가 어떤 컴퓨터인지와 두 대를 어떤 목적으로 어떻게 나눠 쓰고 있는지 이야기하고자 한다.

DGX Spark는 엔비디아 GB10 칩에 128GB 통합 메모리를 얹은 개인용 AI 컴퓨터로, 필자는 같은 계열의 에이수스 GX10으로 Qwen3.8-Flash-Next를 서빙하고, 기가바이트 AI TOP ATOM으로 이미지·음성 모델을 돌린다. Qwen 에이전트를 여럿 돌려야 할 때는 두 대를 텐서 병렬(TP=2)로 묶어 쓴다.

로컬 AI를 이해하려면 어떤 용어를 알아 두면 좋을까

로컬 AI는 AI 모델을 회사나 집에 있는 내 컴퓨터에서 직접 돌려 쓰는 방식이다. ChatGPT나 Claude는 질문을 인터넷 너머 회사의 서버로 보내고 답을 받아 오지만, 로컬 AI는 질문도 답도 내 컴퓨터 밖으로 나가지 않는다. 이 글에는 낯선 용어가 몇 개 나오는데 아래 정도만 알고 읽으면 충분하다.

용어	뜻
모델	질문을 받아 답을 만들어 내는 AI 본체. Qwen, Claude, GPT가 모두 모델 이름이다
오픈 모델	누구나 내려받아 자기 컴퓨터에서 돌릴 수 있게 공개된 모델
파라미터	모델이 학습으로 익힌 지식을 담은 숫자. 많을수록 모델이 크고 똑똑한 편이지만 메모리도 그만큼 많이 차지한다
토큰	AI가 글을 읽고 쓰는 단위로, 단어 하나나 글자 몇 개 정도의 조각이다. 초당 토큰 수가 곧 답이 나오는 속도다
서빙	모델을 켜 두고 다른 프로그램이 질문을 보낼 수 있게 창구를 열어 두는 일
에이전트	답만 하는 것이 아니라 파일을 읽고 명령을 실행하며 일을 스스로 이어 가는 AI. 클로드 코드가 대표적이다

DGX Spark는 어떤 컴퓨터인가

DGX Spark는 엔비디아(NVIDIA)가 만든 미니 PC 크기의 AI 개발용 컴퓨터로, 128GB 메모리를 CPU와 GPU가 함께 쓰는 것이 가장 큰 특징이다. 컴퓨터의 두뇌인 CPU와 AI 계산을 맡는 GPU가 GB10이라는 칩 하나에 들어 있고, 엔비디아는 이 장비를 '세계에서 가장 작은 AI 슈퍼컴퓨터'라고 부른다. 운영체제는 윈도우나 맥OS가 아니라 리눅스(우분투) 기반의 DGX OS다.

DGX Spark는 엔비디아가 직접 파는 제품의 이름이기도 하지만, 같은 GB10 칩을 쓰는 여러 제조사 제품을 묶어 부르는 이름처럼 쓰이기도 한다. 같은 부품으로 여러 브랜드가 내놓은 노트북을 떠올리면 된다. 필자가 가진 두 대도 에이수스(ASUS)의 Ascent GX10과 기가바이트(GIGABYTE)의 AI TOP ATOM이다. 제조사만 다를 뿐 칩과 메모리, 운영체제는 같다.

항목	사양	쉽게 말하면
칩	NVIDIA GB10 (20코어 Arm CPU + 블랙웰 GPU)	CPU와 GPU를 한 칩에 담았다
메모리	128GB LPDDR5x 통합 메모리	16GB 노트북의 8배다
메모리 대역폭	273GB/s	메모리에서 데이터를 꺼내 오는 속도로, 이 장비의 약점이다
AI 성능	최대 1 PFLOP (FP4, 희소 연산 적용 시)	가장 유리한 조건에서 잰 최대치다
네트워크	ConnectX-7 200Gbps, 10GbE, Wi-Fi 7	두 대를 초고속 케이블로 직접 이을 수 있다

참고: NVIDIA - DGX Spark Hardware Overview | NVIDIA Newsroom - DGX Spark Arrives for World's AI Developers

통합 메모리는 무엇이 다른가

일반 PC는 CPU가 쓰는 메모리(RAM)와 그래픽카드가 쓰는 메모리(VRAM)가 따로 있다. AI 모델은 VRAM에 올라가야 빠르게 돌기 때문에, 소비자용 최상위 그래픽카드인 RTX 5090도 32GB를 넘는 모델은 한 장으로 감당하기 어렵다. DGX Spark는 CPU와 GPU가 128GB 하나를 함께 쓴다. 작업대로 비유하면 칸막이 없이 넓은 작업대 하나를 통째로 쓰는 셈이다.

덕분에 수십 GB에서 100GB 가까운 모델도 한 대에 올라간다. 엔비디아는 FP4 형식을 쓰면 최대 2,000억(200B) 파라미터 모델까지 추론하고 700억(70B) 파라미터 모델까지 파인튜닝할 수 있다고 설명한다. 다만 128GB 안에는 운영체제와 컨테이너, 모델 가중치, 그리고 대화 맥락을 담아두는 KV 캐시가 모두 들어가야 한다. 모델이 클수록 동시에 처리할 수 있는 대화의 여유가 줄어든다는 뜻이다.

전기는 얼마나 쓰는가

필자는 두 대를 늘 켜 두지 않고 필요할 때만 켜서 쓴다. 스마트 플러그로 최근 일주일 동안 1시간 단위로 재 보니, 켜서 일을 시키는 동안의 시간 평균 전력은 대부분 40W에서 80W 사이였다. 두 대를 묶어 쓴 날에도 GX10이 77W에서 85W, ATOM이 65W에서 71W 수준이었고 가장 피크를 찍었던 한 시간도 GX10 116W, ATOM 134W로 어댑터 용량(240W)의 절반 남짓이었다. 꺼 두면 1W를 조금 넘는 전력만 흐르고 많이 쓴 날도 하루 사용량은 GX10 1.5kWh, ATOM 2.6kWh를 넘지 않았다. 시간 평균이라 순간 최대치는 이보다 높을 수 있다.

여기에는 필자가 걸어 둔 설정도 한몫한다. GB10은 전력 상한을 걸 수 없게 막혀 있어서 두 대 모두 GPU 클럭 상한을 GX10 2,000MHz, ATOM 2,100MHz로 묶어 두었다. 이렇게 하니 부하 전력이 약 25% 줄었고 토큰 생성 속도는 메모리 대역폭에 묶여 있어 거의 그대로였다. 대신 긴 문서를 읽거나 이미지를 만드는 속도는 15%쯤 느려진다.

그래픽카드 한 장만 해도 게임 중 수백 W를 쓰는(RTX 5090은 575W) 고성능 게이밍 PC와 비교하면 켜 두고 쓰는 부담이 적은 편이다.

통합 메모리가 128GB인데 왜 답이 빨리 나오지 않을까

DGX Spark에서 답이 생각보다 느리게 나오는 이유는 토큰을 하나 만들 때마다 모델 가중치를 메모리에서 읽어와야 하는데, 그 통로인 메모리 대역폭이 273GB/s로 좁기 때문이다. 작업대는 넓은데 재료를 나르는 복도가 좁은 셈이다. 그래서 모델을 올릴 수 있느냐와 빠르게 쓸 수 있느냐는 전혀 다른 질문이 된다. 큰 모델을 한 대에 올리는 것은 쉽지만 그 모델로 답을 빠르게 받으려면 모델을 고르는 기준부터 달라져야 한다.

숫자로 보면 차이가 확실하다. 처음 ATOM에서 서빙하던 Qwen3.8-27B는 토큰마다 모든 파라미터를 쓰는 밀집(dense) 모델이다. 4비트(NVFP4)로 줄여 21GiB 남짓한 모델인데도 질문을 읽는 속도(prefill)는 초당 4,859토큰이 나온 반면, 답을 한 토큰씩 만들어내는 속도(decode)는 초당 10.2토큰에 그쳤다. 메모리 대역폭을 모델 크기로 나눈 이론 상한(초당 약 12.8토큰)에 거의 붙은 값이다. 다음 토큰 몇 개를 미리 짐작해 한 번에 확정하는 MTP를 붙이고 나서야 초당 23.5토큰까지 올라갔다.

그래픽카드와 나란히 놓으면 이 숫자가 얼마나 느린지 보인다. RTX 5090은 메모리 대역폭이 1,792GB/s로 DGX Spark의 약 6.6배다. Tom's Hardware에서 Qwen3.8-27B NVFP4를 vLLM으로 돌려 본 결과를 보면, RTX 5090 두 장을 묶었을 때 MTP 없이도 초당 70에서 80토큰, MTP를 켜면 초당 100에서 110토큰이 나왔다. 필자의 ATOM이 MTP를 켜고 낸 초당 23.5토큰의 네 배가 넘는다. 같은 기사에서 잰 DGX Spark도 MTP를 켜고 초당 20토큰 안팎이었다. 다만 5090 한 장으로는 메모리가 32GB뿐이라 vLLM 기본 설정에서 컨텍스트가 32K로 묶이고 MTP를 켤 여유도 없어 초당 20토큰 수준에 머물렀다. 답을 뽑는 속도는 그래픽카드가 앞서고 모델과 긴 컨텍스트를 담는 공간은 DGX Spark가 넉넉한 구도다.

그래서 이 장비에서는 전체 크기보다 토큰 하나를 만들 때 실제로 쓰는 파라미터 수가 중요하다. 전문가 여럿 중 일부만 골라 쓰는 MoE(Mixture of Experts) 구조의 모델이 여기에 잘 맞는다. 지금 서빙 중인 Qwen3.8-Flash-Next는 본체 1,250억(125B) 파라미터 중 토큰마다 60억(6B)만 쓴다(별도의 N-gram 임베딩 510억 개는 제외). 그래서 한 대로도 직접 재 보면 한국어 글은 초당 약 40토큰, 코드는 약 46토큰이 나온다. 처음 올렸을 때는 한국어가 초당 22토큰이었는데 설정을 다듬어 1.8배로 끌어올린 값이다.

하나 더, 이 장비는 요청 하나보다 여러 요청을 한꺼번에 처리할 때 강하다. GX10의 Qwen3.8-Flash-Next에 한국어 글 약 2,000자를 주고 요약을 시켜 보니 요청 하나일 때는 합계 초당 37토큰이었는데, 8개를 동시에 보내자 요청마다 속도는 초당 22토큰으로 떨어져도 합계는 초당 118토큰까지 올라갔다. 대신 첫 글자가 나오기까지의 시간은 0.7초에서 5.3초로 길어졌다. 에이전트를 여럿 돌리는 사용 방식과 잘 맞는 성격이다. 어떤 모델을 고르면 좋은지는 따로 정리해 볼 만한 주제다.

참고: Tom's Hardware - Benchmarking Qwen 3.8 27B on RTX 5090 and beyond

왜 DGX Spark를 두 대나 샀을까

DGX Spark 계열 컴퓨터를 두 대나 들인 이유는 비용 절감이 아니라, 모델을 직접 돌려보고, 서빙 방식을 스스로 정하고, 여러 모델을 동시에 실험하기 위해서다. 솔직히 비용 효율만 따지면 ChatGPT나 Claude 구독만 한 게 없다. 좋은 답을 빠르게 받는 것이 목적이라면 로컬 장비를 살 이유가 없다. 이 장비를 고른 이유는 결과물이 아니라 과정과 통제권에 있다.

ATOM(4TB)은 2026년 8월 중고로 700만 원, GX10(1TB)은 9월 해외 직구로 관세 포함 620만 원에 들였다. 그럼에도 로컬 장비가 주는 것이 분명히 있다.

1. 직접 돌려보며 배운다. 모델을 올리고, 설정을 바꾸고, 이것저것 해보는 과정에서 AI가 어떻게 돌아가는지 감이 잡힌다.
2. 모델과 서빙 방식을 직접 정한다. 어떤 모델을 쓸지, 언제 바꿀지, 버전을 고정할지 모두 직접 결정한다. 주간 사용 한도에 걸릴 걱정도 없다.
3. 새 모델을 바로 실험한다. 오픈 모델이 공개되면 그날 바로 올려서 써볼 수 있다.
4. 여러 모델을 동시에 띄운다. 언어 모델, 이미지 모델, 음성 모델을 각자 켜둔 채로 번갈아 쓴다.
5. 데이터를 다루는 선택지가 생긴다. 고객 데이터처럼 외부 LLM 서비스에 올리기 부담스러운 자료를 로컬 모델로 처리하는 길이 열린다.

두 대를 들인 이유는 따로 있다. 첫째, 매일 쓰는 서빙용과 이것저것 올려보는 실험용을 나누고 싶었다. 실험하다가 서버를 재시작해도 매일 쓰는 언어 모델이 멈추지 않아야 하기 때문이다. 둘째, 필요할 때는 두 대를 ConnectX-7로 묶어 한 대로는 버거운 작업을 처리하고 싶었다. 셋째, 언어 모델과 이미지·음성 모델이 서로 메모리 자리를 뺏지 않고 각자 떠 있기를 바랐다.

DGX Spark로 Qwen을 어떻게 서빙하고 있을까

GX10은 기본 언어 모델 서버로, 켜 두는 동안 Qwen3.8-Flash-Next를 vLLM으로 서빙한다. vLLM은 언어 모델을 API 서버로 띄워주는 오픈소스 추론 엔진인데, 오픈AI(OpenAI) 호환 API와 앤트로픽(Anthropic) 호환 API를 함께 열 수 있어서 기존 AI 도구에 주소만 바꿔 연결하기 좋다. 클로드 코드처럼 앤트로픽 API를 쓰는 도구도 이 서버에 그대로 붙는다. 밖에서 쓸 때도 공유기 포트는 열지 않고 Tailscale을 활용한 내부망으로만 접속한다.

Qwen3.8-Flash-Next는 알리바바 Qwen 팀이 2026년 8월 26일 공개한 MoE 모델이다. 텍스트뿐 아니라 이미지와 동영상도 입력으로 받고 기본 컨텍스트가 26만 토큰이라 긴 로그나 문서를 한 번에 읽힐 수 있다. 다만 DGX Spark 한 대에 올리려면 손이 조금 간다. 모델 파일만 126GiB라 한 대의 메모리에 전부 올릴 수 없기 때문이다. 그래서 한 대로 쓸 때는 모델의 일부인 N-gram 테이블(48GiB)을 메모리에 올리지 않고 SSD에 둔 채 필요한 부분만 읽어 온다. 올리는 과정은 기회가 되면 따로 풀어 볼 생각이다.

이 서버를 가장 많이 쓰는 곳은 클로드와의 협업이다. llm-router라는 작은 도구를 직접 만들어서 클로드가 계획과 검토를 맡고, 로컬 Qwen이 구현과 코드 리뷰, 긴 로그 읽기를 맡도록 일을 나눠 쓰고 있다. 예를 들어 테스트나 빌드 출력이 300줄을 넘어가면 로컬 Qwen이 먼저 로그를 읽고 클로드는 결론과 근거가 되는 줄만 받는다. 클라우드 모델의 토큰은 판단이 필요한 곳에만 쓰고, 읽고 요약하는 일은 로컬이 맡는 구조다.

기대치는 낮춰 둘 필요가 있다. 같은 요청 4개를 클로드 코드로 보내 체감 속도를 재 보니 2대를 묶은 로컬 Qwen이 평균 초당 30.6토큰, 클로드의 Opus가 74.3토큰이었다. 여러 단계를 거치는 도구 사용이나 긴 계획을 세우는 솜씨도 Opus 모델이 확연히 앞선다. 그래서 진지한 코딩과 판단은 클로드에 두고 대화·요약·번역·긴 로그 읽기처럼 반복되는 일을 로컬에 맡긴다.

반복 테스트도 로컬 모델이 맡는다. 에이전트 스킬을 하나 만들면 같은 시나리오를 며칠 내내 돌리면서 스킬이 의도대로 움직이는지, 어디서 엇나가는지를 확인한다. GA4를 대화로 분석하기에서 소개한 ga4-skill도 이렇게 테스트를 반복하며 다듬었다. 클로드 구독으로 같은 횟수를 돌렸다면 사용 한도부터 신경 써야 했을 것이다. 속도와 솜씨는 클로드에 못 미쳐도 사용량에 제한이 없다는 점이 이런 일에서는 가장 큰 장점이 된다.

이 연결은 클로드 코드의 스킬로 붙어 있다. 어떤 상황에서 로컬로 넘길지를 글로 정해두면 에이전트가 알아서 따른다. 요청이 90분 동안 없으면 vLLM을 내려 메모리 76GiB를 돌려주고 일이 생기면 맥미니에서 도는 관리 패널이 다시 띄운다. 로컬에 맡긴 작업이 얼마나 쓸 만했는지도 지표로 남기고 있다. 이 구조와 효과도 언젠가 자세히 적어 보고 싶다.

참고: Hugging Face - Qwen/Qwen3.8-Flash-Next | vLLM Docs - Online Serving

DGX Spark로 이미지·음성 모델은 어떻게 돌리는가

ComfyUI로 이미지·동영상 생성 모델을, Whisper로 음성 인식(STT)을, Qwen3-TTS로 음성 합성(TTS)을 돌리고 있는데, 이 일은 실험용인 ATOM이 맡고 있고 새 모델이 나오면 가장 먼저 올려보는 실험대로도 쓴다. 서빙용 GX10을 건드리지 않고 마음껏 설치하고 지우고 재시작할 수 있다는 점이 실험용 한 대를 따로 둔 가장 큰 이유다.

이미지·동영상 생성

이미지와 동영상은 ComfyUI로 다룬다. ComfyUI는 이미지·동영상 생성 모델을 노드로 이어 붙여 작업 흐름을 만드는 오픈소스 도구로, 엔비디아도 DGX Spark용 공식 설치 안내(플레이북)를 제공한다. 이미지는 FLUX.2 [klein], Krea 2, Qwen-Image를, 동영상은 MiniMax H3를 주로 올려본다. MiniMax H3는 참조 이미지와 영상, 오디오를 넣어 영상을 만드는 모델로, 녹음한 목소리를 앵커로 넣으면 입 모양을 그 소리에 맞춰 준다. 메모리가 넉넉해서 그래픽카드 VRAM이 모자라 모델을 못 올리는 일은 거의 없다. 대신 영상 작업은 피크 때 36GiB에서 45GiB를 써서 두 대를 묶는 동안에는 할 수 없다.

다만 동영상 생성 속도는 기대를 낮추는 편이 좋다. 필자가 쓰는 설정으로 MiniMax H3가 짧은 컷 하나를 만드는 데 약 437초, 7분 남짓이 걸린다. 같은 컷을 LTX로 만들면 144초라 세 배 빠르지만 LTX는 두 번째 프레임부터 카메라가 얼굴로 밀고 들어가 설정화와 다른 인물이 되어 버렸다. 그래서 느려도 그림을 지켜 주는 H3를 쓴다. 빨리 뽑아내는 장비라기보다 큰 모델을 올려 두고 공들여 뽑는 장비에 가깝다.

음성 인식과 음성 합성

음성 인식은 Whisper(WhisperX large-v3)로 회의록 전사 서비스를 만들어 쓴다. 녹음본을 올리면 ATOM이 받아 적으면서 누가 말했는지까지 나누고 한 번 이름을 붙인 화자는 다음 회의부터 목소리로 알아본다. 30분짜리 녹음을 받아 적고 단어 위치까지 맞추는 데 350초가 걸렸고 GPU 메모리는 4GB 정도만 썼다. 음성 합성에는 한국어를 지원하는 Qwen3-TTS(1.7B)를 쓴다. 반대로 엔비디아의 음성 인식 모델 Parakeet v3는 유럽 언어 25개만 지원해서 한국어 음성에는 쓸 수 없다. 음성 모델을 고를 때는 한국어 지원 여부부터 확인하는 것이 순서다.

영상 한 편은 어떤 순서로 만들어지는가

이 모델들을 하나씩 따로 돌리기만 하는 것은 아니다. 영상 제작 하네스를 만들어 두고 이미지·영상·음성 생성은 전부 ATOM에 맡긴다. 필자가 사용 중인 공정은 두 갈래다.

첫째는 내레이션 영상이다. 주제 한 줄을 주면 대본을 쓰고 화풍을 고정할 스타일 앵커 그림과 장면별 키프레임을 만든다. 사람이 키프레임을 한 번 승인하면 그 뒤는 자동이다. TTS로 낭독하고 키프레임을 영상 클립으로 움직인 다음 자막을 붙여 가로 본편과 세로 쇼츠, 썸네일, 업로드 설명문을 뽑는다.

둘째는 캐릭터 대사극 형식의 짧은 애니메이션이다. 기획·각본, 설정화, 선녹음, 콘티, 원화, 클립, 촬영·편집, 더빙 순으로 흐른다. 필자는 감독 자리에서 다섯 번의 승인 게이트만 본다. 공정마다 맡는 모델이 다르다.

공정	모델	하는 일
설정화·미술 보드	Krea 2, Qwen-Image 2.1	캐릭터 시트와 장소 배경을 그린다
원화	FLUX.2 [klein]	설정화를 참조로 받아 컷마다 인물을 그린다
선녹음·더빙	Qwen3-TTS	캐스팅한 목소리를 복제해 대사를 읽는다
클립	MiniMax H3	녹음한 목소리에 입 모양을 맞춰 원화를 움직인다
검수	Whisper, GX10의 Qwen	더빙을 받아 적어 대사와 대조하고, 원화의 손·인물 이상을 1차로 걸러 낸다

원화 1차 검수는 GX10에서 도는 Qwen3.8-Flash-Next가 이미지를 보고 판정한다. 한 대는 그림을 그리고 다른 한 대는 그 그림을 검사하는 셈이다. 이렇게 최근 1주 동안 한국어·일본어로 더빙한 단편 일곱 편을 완성했고 ATOM의 ComfyUI가 남긴 결과물은 이미지 2,500여 장과 영상 480여 개였다. (어딘가에 배포하기보단 개인 학습을 목적으로 해본 작업이다.)

업무에는 어떻게 쓸 수 있을까

업무로 옮겨 보면 쓸 곳이 꽤 많다. 회의나 고객 인터뷰 녹음을 글로 옮기고, 광고나 SNS에 쓸 이미지 시안을 여러 장 뽑아 보고, 제품 소개 영상의 내레이션 초안을 만드는 일을 외부 서비스에 파일을 올리지 않고 처리할 수 있다. 사용량을 신경 쓰지 않아도 되니 시안을 여러 장 뽑아 놓고 고르는 식으로 쓰기에도 부담이 없다.

참고: NVIDIA - DGX Spark ComfyUI Playbook | Hugging Face - MiniMaxAI/MiniMax-H3 | Hugging Face - Qwen3-TTS

DGX Spark 두 대는 언제 하나로 묶을까

평소에는 두 대를 따로 쓰다가, 여러 프로젝트를 동시에 진행하면서 Qwen 에이전트를 여럿 돌려야 할 때는 두 대를 ConnectX-7 케이블로 묶어 텐서 병렬(TP=2)로 쓴다. 텐서 병렬은 모델의 각 층을 이루는 가중치 행렬(텐서)을 두 대에 쪼개 올리고 토큰마다 두 대가 함께 계산하는 방식이다. 평소에는 GX10 한 대로 Qwen을 서빙하고 묶을 때는 GX10과 ATOM이 함께 같은 Qwen을 서빙한다.

한 대로 쓸 때와 가장 크게 다른 점은 모델을 두는 곳이다. 한 대로는 메모리가 모자라 N-gram 테이블을 SSD에 두고 필요한 부분만 읽어 오지만 두 대를 묶으면 두 대의 메모리를 합쳐 모델 전체를 메모리에 올린다.

묶는 이유는 속도보다 여유다. 에이전트 하나하나가 각자 긴 코드와 로그를 붙들고 일하기 때문에 여럿을 동시에 돌리면 대화 맥락을 담아 두는 자리(KV 캐시)가 먼저 모자란다. 자리가 모자라면 요청이 줄을 서서 기다리게 된다. 두 대의 메모리를 함께 쓰면 이 자리가 넉넉해진다.

물론 대가도 있다. 묶는 동안에는 ATOM의 메모리도 언어 모델이 쓰기 때문에 ComfyUI를 멈춰야 하고 모드를 바꿀 때마다 모델을 다시 올려야 한다. 그래서 항상 묶어두지 않고 필요할 때만 관리 패널에서 버튼으로 전환한다.

참고: NVIDIA Developer Forums - Two DGX Sparks over the ConnectX-7 direct link

앞으로 어떤 이야기를 써 볼까

두 대를 쓰면서 따로 정리해 두고 싶은 주제가 꽤 쌓였다. 순서를 정해 둔 것은 아니고 아래 같은 이야기를 앞으로 적어 볼까 고민하는 중이다.

• 내 컴퓨터에 AI 서버 올리기 — GX10 한 대에 Qwen3.8-Flash-Next를 올리고 ChatGPT·Claude와 같은 방식으로 연결하는 과정
• 128GB에 어떤 모델을 올릴까 — 모델별 메모리 사용량과 속도, 한국어 품질 비교
• AI 서빙 프로그램 비교 — vLLM, SGLang, Ollama, llama.cpp를 같은 조건에서 비교
• 클로드와 로컬 AI 나눠 쓰기 — 일을 나눠 주는 구조와 실제 절감 효과
• GA4 데이터를 로컬 모델로 분석하기 — ga4-skill을 로컬 모델과 함께 쓰는 방법
• GTM 컨테이너 로컬 검수 — 고객사 태깅 자료를 외부에 올리지 않고 검토하기
• 두 대를 한 대처럼 쓰기 — 케이블 연결과 설정, 한 대와 두 대 비교
• 운영기 — 필요할 때 켜고 끄기, 전력 관리, 한 달 사용 기록

자주 묻는 질문

Q. DGX Spark 한 대로 어느 크기의 모델까지 돌릴 수 있는가?

엔비디아는 모델을 4비트(FP4)로 가볍게 줄이면 파라미터가 2,000억 개인 모델까지 돌릴 수 있다고 설명한다. 다만 128GB 안에 운영체제와 대화 기억 공간도 함께 들어가야 하고, 700억 파라미터급 일반 모델은 초당 2에서 3토큰 수준으로 느리다. 실제로는 전체 크기가 커도 답을 쓸 때 일부만 쓰는 MoE 모델을 고르는 것이 현실적이다.

Q. 제조사가 다른 DGX Spark 계열 두 대도 하나로 묶을 수 있는가?

묶을 수 있다. 필자는 에이수스 GX10과 기가바이트 AI TOP ATOM을 ConnectX-7 케이블로 연결해 TP=2로 쓰고 있다. 두 제품 모두 같은 GB10 칩과 DGX OS를 쓰기 때문에 가능한 일이고 연결 전에 양쪽 펌웨어와 시스템 소프트웨어를 최신으로 맞춰두는 것이 좋다.

Q. DGX Spark는 전기를 얼마나 쓰는가?

출시 직후 리뷰 실측 기준으로 대기 중에는 35W에서 45W, 언어 모델 추론 중에는 60W에서 90W 정도를 썼다. 2026년 2월 소프트웨어 업데이트 이후에는 ConnectX-7 포트를 쓰지 않을 때 대기 전력이 25W 안팎까지 내려갔다. 필자가 스마트 플러그로 재 보니 켜서 일을 시키는 동안의 시간 평균은 대부분 40W에서 80W 사이였고 가장 바쁜 한 시간도 134W를 넘지 않았다. 전원 어댑터는 240W지만 칩의 설계 전력은 140W다.

마치며

정리하면 DGX Spark는 128GB라는 넓은 작업대를 가졌지만 재료를 나르는 복도가 좁은 컴퓨터다. 그래서 필요한 부분만 골라 쓰는 MoE 모델을 고르고, 한 대는 매일 쓰는 Qwen 서버로, 한 대는 이미지·음성 실험실로 나눠 쓰다가, 에이전트를 여럿 돌릴 때만 두 대를 묶는다.

로컬 AI가 구독을 대체한다고 생각하지는 않는다. 판단이 필요한 일은 여전히 클라우드의 최상위 모델이 잘하고, 읽고 요약하고 반복하는 일은 로컬 모델이 충분히 해낸다. 로컬의 성능이 빠르게 올라가고 있는 만큼 AI 도구도 구독 서비스와 로컬을 섞어 쓰는 쪽으로 가지 않을까 하는 생각이 든다.

누구에게나 권할 장비는 아니다. 자금의 여유가 있으면서 리눅스나 원격 접속(SSH) 같은 개발 환경이 낯설지 않고, 모델을 직접 올리고 고치는 과정 자체를 즐길 수 있는 사람에게 맞다. 그런 사람이라면 한 번쯤 책상 위에 AI 서버를 들여 보기를 바란다.

사실 DGX Spark를 들여 써 본 지는 아직 얼마 되지 않았다. 지금 쓰는 방식도 계속 바뀌는 중이고 해 보고 싶은 일도 많이 남아 있다. 앞으로도 여러 방면으로 써 보면서 알게 된 것을 하나씩 글로 남겨 보려 한다.