DGX Spark LLM 추천 — 64GB·128GB에서 돌아가는 모델과 2대·4대 연결

DGX Spark는 NVIDIA가 GB10 칩으로 만든 데스크톱이고, 통합 메모리 64GB 구성과 128GB 구성이 있습니다. 두 구성의 메모리 대역폭은 같습니다. CanRun 계산으로는 128GB 구성이면 gpt-oss-120b와 Qwen3.5 122B-A10B가 GPU에 전부 올라갑니다. 64GB 구성에도 Q4_K_M Llama 3.3 70B는 들어가지만 gpt-oss-120b는 들어가지 않습니다. 두 대나 네 대를 이으면 더 큰 모델이 들어갑니다. 다만 llama.cpp로 이으면 속도는 빨라지지 않습니다.

한 대·두 대·네 대에서 돌아가는 모델

아래 표는 DGX Spark 페이지에 나오는 구성 여섯 가지에서 모델 여섯 개를 판정한 것입니다. 구성은 64GB·128GB 한 대와, 같은 구성을 두 대·네 대 이은 경우입니다. 칸마다 8k 컨텍스트와 f16(양자화하지 않은 16비트) KV 캐시를 기준으로 했습니다. KV 캐시는 지금까지의 대화를 담는 메모리입니다. 양자화는 모델마다 기본값을 썼습니다. 대부분 CanRun의 기준인 4비트 Q4_K_M이고, gpt-oss와 DeepSeek V4 Flash 0731은 MXFP4입니다. Llama 3.3 70B를 뺀 다섯 모델에는 생각 모드가 있어서, CanRun은 속도 기준을 1.5배 엄격하게 잡습니다. 기본 양자화 파일이 같은 메모리 한 대의 GPU에 이미 다 들어가는 모델은 이어 봐야 느려지기만 합니다. 그래서 여러 대 행에는 판정 대신 ‘1대로 충분’이라고 적었습니다. 카탈로그의 다른 모델도 NVIDIA DGX Spark 페이지에서 같은 구성으로 볼 수 있습니다.

DGX Spark에서 빠르게 도는 것은 MoE(전문가 혼합) 모델입니다. 토큰마다 가중치의 작은 일부만 읽기 때문입니다. Qwen3.6 35B-A3B는 64GB와 128GB 한 대에서 모두 쾌적하게 돌아갑니다. 그래서 여러 대 칸에는 ‘1대로 충분’이라고 나옵니다. gpt-oss-120b는 128GB 구성이 있어야 하고, 여기서 쾌적하게 돌아갑니다. 공개 벤치마크 결과도 있습니다. 토큰마다 쓰는 파라미터가 두 배쯤 많은 Qwen3.5 122B-A10B는 128GB에서 원활하게 돌아갑니다. 이쪽도 공개 벤치마크가 있습니다.

dense 모델은 토큰마다 가중치를 전부 읽습니다. 그래서 DGX Spark의 대역폭으로는 속도가 낮게 묶입니다. Gemma 4 31B는 두 구성 모두에서 겨우 돌아가고, 이 속도는 공개 벤치마크에서 잰 값입니다. Llama 3.3 70B도 두 구성 모두에서 느리게 돌아갑니다. 메모리를 늘려도, 기기를 더 이어도 이 점은 그대로입니다.

여러 대 행이 쓸모 있는 것은 한 대에 안 들어가는 모델입니다. DeepSeek V4 Flash 0731은 MXFP4로 155.6GB가 필요합니다. 64GB 두 대로는 모자랍니다. 128GB 두 대나 64GB 네 대면 들어가고, CanRun 추정으로 원활하게 돌아갑니다. 이 값은 이론 추정입니다. 표에 없는 GLM-5.3 Flash는 이보다도 큽니다. Q4_K_M 파일은 128GB 두 대에서 원활하게 돌아가고, 네 대에서는 오히려 느리게 돌아간다고 추정합니다(이론 추정). 64GB 네 대에는 들어가지 않습니다. 네 대가 두 대보다 낮게 나오는 까닭은 기기를 하나 더 거칠 때마다 토큰 하나에 드는 시간이 늘기 때문입니다. 자세한 내용은 연결을 다룬 절에서 설명합니다.

한 대에 이미 들어가는 모델은 이어 봐야 이 시간만 늘어납니다. dense 모델인 Qwen3.6 27B는 128GB 한 대에서 원활하게 돌아가고, 여러 대 칸에는 ‘1대로 충분’이라고 나옵니다. 계산기에서 굳이 두 대를 고르면 한 대보다 느린 추정이 나옵니다. 한 대에 들어가는 모델은 한 대로 돌리는 편이 낫습니다.

GPU가 쓸 수 있는 메모리

DGX Spark에는 따로 달린 VRAM이 없습니다. CPU와 GPU가 메모리 하나를 나눠 씁니다. NVIDIA도 이 메모리를 통합 시스템 메모리로만 적고, GPU 몫은 따로 밝히지 않습니다. Linux에서는 GPU도 다른 프로그램과 같은 메모리에서 몫을 받습니다. 그래서 CanRun은 시스템과 데스크톱이 쓰고 남은 양을 GPU 몫으로 봅니다. 128GB 구성은 116.9GB, 64GB 구성은 48.2GB입니다. GGUF 파일과 KV 캐시, 연산 버퍼를 더한 양이 이 값 안에 들면 모델이 들어간다고 봅니다. 연산 버퍼는 계산에 쓰는 작업 공간입니다.

128GB 값은 사용자들이 NVIDIA 개발자 포럼에 올린 커널 부팅 로그에서 출발합니다. 부팅 뒤 남는 메모리가 가장 적은 기록은 DGX OS 7.5.0에서 나왔습니다. 새 커널 기능이 이전 커널보다 몇 GB를 더 예약하기 때문입니다. 같은 글타래에는 이 문제를 고치는 업데이트가 배포되고 있다는 답이 달려 있습니다. CanRun은 이 가장 낮은 기록에서, 다른 사용자가 잰 데스크톱 기본 사용량을 뺍니다. 64GB 구성은 아직 공개된 부팅 기록이 없습니다. 그래서 128GB에서 구한 고정 몫을 똑같이 뺐습니다. 64GB 구성에 모델을 올릴 공간이 이보다 넉넉하다는 보도도 있지만, NVIDIA가 확인한 값은 아닙니다.

다음 표는 카탈로그의 모든 모델을 구성마다 판정하고, 판정별로 몇 개인지 센 것입니다. GPU가 쓸 수 있는 메모리 열이 위의 값입니다.

CanRun의 값은 가장 낮은 부팅 기록에서 출발했습니다. 이전 커널이나 문제가 고쳐진 커널을 쓰거나 데스크톱 없이 돌리면 여유가 조금 더 있습니다. 이 차이는 필요량이 경계 바로 위에 걸린 파일에서만 문제가 됩니다. 예를 들어 DeepSeek V4 Flash 0731의 Q2_K 파일은 118.0GB가 필요합니다. 128GB 구성의 값을 조금 넘어서, CanRun은 한 대에는 안 들어간다고 봅니다. 남는 메모리가 더 많은 커널에서는 올라갈 수도 있으니, 포기하기 전에 llama.cpp 로딩 로그를 확인해 보세요.

실제로 쓸 때 알아 두면 좋은 점이 세 가지 있습니다. 첫째, CUDA 프로그램이 읽는 남은 메모리는 실제로 할당할 수 있는 양보다 적게 나올 수 있습니다. NVIDIA의 알려진 문제 문서에 나오는 내용입니다. nvidia-smi는 전체 메모리 사용량을 Not Supported로 표시하고, 프로세스별 사용량만 보여 줍니다. 둘째, 한 사용자는 메모리가 바닥나자 메모리 부족 오류로 끝나지 않고 기기 전체가 멈췄다고 알렸습니다. 강제로 다시 켜야 했다고 하니 메모리에 여유를 남겨 두세요. 셋째, llama.cpp에서는 mmap을 끄세요. 지금 빌드는 --load-mode none, 이전 빌드는 --no-mmap입니다. 포럼 사용자들은 mmap을 켜면 모델을 불러오는 시간이 훨씬 길었다고 알렸습니다. llama.cpp 개발자들도 DGX Spark 결과 파일을 mmap을 끄고 쟀습니다. CanRun의 DGX Spark dense 속도 계수는 이 파일에서 구한 값입니다.

64GB와 128GB, 무엇을 보고 고를까

두 구성은 칩이 같고 대역폭도 273 GB/s로 같습니다. 그래서 양쪽에 다 들어가는 모델이면 추정 속도도 같습니다. 고를 때 볼 것은 돌리려는 모델이 들어가는지, 그리고 컨텍스트를 얼마나 길게 쓰는지입니다.

큰 MoE 모델 가운데 128GB에는 들어가고 64GB에는 안 들어가는 모델이 여럿 있습니다. gpt-oss-120b, Ling-3.0 Flash, Laguna S 2.1이 그렇습니다. 양자화를 한 단계 낮추면 해결되는 모델도 있습니다. Kolibri-1은 Q4_K_M으로 50.5GB가 필요해 64GB 구성의 값을 넘습니다. 한 단계 아래인 IQ4_XS로 받으면 64GB에서도 들어가고 쾌적하게 돌아갑니다. Qwen3.5 122B-A10B는 64GB에 2비트 파일로만 들어갑니다. 품질 손실이 큰 양자화입니다.

컨텍스트도 같은 메모리를 씁니다. Llama 3.3 70B는 8k에서는 64GB 구성에 들어갑니다. 하지만 32k 컨텍스트를 f16 KV 캐시로 잡으면 54.1GB가 필요해 64GB 구성의 48.2GB를 넘습니다. 128GB 구성이면 넉넉하게 들어가는 양입니다. 긴 문서를 넣거나 코딩 에이전트처럼 컨텍스트를 크게 쓴다면, 작은 구성을 고르기 전에 KV 캐시부터 계산해 보세요. KV 캐시가 늘어나는 방식은 ‘KV 캐시와 컨텍스트 길이 — 컨텍스트를 늘리면 VRAM이 얼마나 더 필요할까’에서 다룹니다.

64GB 두 대가 128GB 한 대와 같지는 않습니다. 64GB 두 대에도 gpt-oss-120b가 들어가고, CanRun 추정으로 쾌적하게 돌아갑니다. 이 값은 이론 추정이고, 128GB 한 대의 공개 벤치마크보다 낮습니다. 토큰이 두 기기 사이를 오가야 하기 때문입니다. IQ4_XS Solar Open 2 250B는 64GB 두 대에는 들어가지 않습니다. 128GB 두 대에서는 원활하게 돌아간다고 추정합니다. 이 값도 이론 추정입니다.

이 가이드는 가격을 비교하지 않습니다. CanRun 데이터에 있는 가격은 NVIDIA가 직접 파는 128GB 제품의 출시가 US$3,999뿐입니다. NVIDIA는 2026년 2월 메모리 공급 부족을 이유로 직접 파는 제품의 가격을 올렸습니다. 64GB 구성은 협력 제조사만 팔고, 가격도 제조사마다 따로 정합니다. 국내 판매가는 이 가이드에서 다루지 않습니다.

두 대·네 대 연결

NVIDIA가 지원하는 범위

DGX Spark에는 QSFP 포트 두 개가 달린 ConnectX-7 네트워크가 들어 있습니다. NVIDIA 클러스터링 문서는 케이블로 바로 잇는 경우 세 대까지, 스위치를 쓰면 네 대까지 지원한다고 적습니다. 제품 페이지는 대수를 2의 거듭제곱으로 맞추라고 권합니다. 두 대는 QSFP 케이블 하나로 잇습니다. NVIDIA 케이블 연결 안내에 따르면 케이블을 두 개로 늘려도 성능은 오르지 않습니다. 세 대는 케이블 세 개로 고리 모양으로 잇습니다. 네 대는 NVIDIA 스위치 연결 안내대로 200GbE 스위치를 씁니다. 케이블 네 개로 고리를 만드는 방법도 있지만 수동 설정에서만 됩니다.

NVIDIA가 여러 대용으로 낸 공식 안내는 NCCL과 vLLM입니다. NCCL은 기기 사이에서 GPU끼리 데이터를 주고받는 라이브러리입니다. vLLM 안내는 두 대~네 대를 다룹니다. NVIDIA의 llama.cpp 안내는 여러 대 연결을 다루지 않습니다. llama.cpp RPC로 여러 대를 잇는 것은 커뮤니티에서 쓰는 방법입니다. CanRun이 계산하는 것은 이 방식입니다. 이 사이트가 이미 보여 주는 llama.cpp 명령을 그대로 넓힌 방식이기 때문입니다.

CanRun이 계산하는 방식: llama.cpp RPC

llama.cpp RPC에서는 첫 기기가 llama-server를 띄우고, 나머지 기기는 RPC 서버를 띄워 층을 나눠 맡습니다. 메모리는 합쳐지지만 토큰은 모든 기기를 차례로 지나갑니다. 그래서 대역폭은 합쳐지지 않고, 기기를 건널 때마다 토큰 하나에 드는 시간이 늘어납니다. CanRun은 두 대로 돌린 공개 결과에서 이 시간을 구하고, 기기가 하나 늘 때마다 한 번씩 더합니다. 원래 빠른 작은 모델일수록 이 시간이 차지하는 비율이 커서 더 많이 느려집니다.

공개 결과도 같은 방향을 가리킵니다. llama.cpp의 DGX Spark 토론에서 한 참여자가 같은 빌드로 gpt-oss-120b를 한 대와 두 대에서 돌렸습니다. 기본 TCP 연결에서는 두 대가 5분의 1쯤 느렸습니다. RDMA로 이은 다른 테스터는 DeepSeek V4 Flash 0731을 두 대로 돌려도 몇 % 느려지는 데 그쳤습니다. 이 테스터는 한 대에 안 들어가는 4비트 파일도 두 대에 올렸습니다. 같은 토론에는 MiniMax-M2와 Qwen3-VL-235B의 4비트 파일을 두 대로 돌린 결과도 있습니다. 둘 다 한 대에는 안 들어가는 크기입니다. 네 대를 llama.cpp RPC로 돌린 공개 결과는 찾지 못했습니다. 그래서 CanRun의 네 대 행은 두 대에서 구한 시간을 늘려 잡은 값입니다.

아래 입력 칸으로 계산기를 열어 DGX Spark를 고르고 연결 대수를 정하면, 기기마다 실행할 명령이 결과에 나옵니다. 명령은 아래와 같은 꼴이고, 주소 자리에는 각 기기의 ConnectX-7 주소를 넣습니다. 먼저 2번 기기부터 나머지 기기마다 RPC 서버를 띄웁니다.

ggml-rpc-server -H <node2-ip> -p 50052 -c

그다음 1번 기기에서 llama-server를 실행합니다.

llama-server -hf <model> -c 8192 -ngl all -fa on --rpc <node2-ip>:50052

llama.cpp는 -DGGML_RPC=ON으로 빌드하고 ggml-rpc-server 타깃도 함께 빌드해야 합니다. NVIDIA llama.cpp 안내의 빌드 명령은 llama-server만 만들기 때문입니다. 2026년 6월 말 전 빌드에서는 서버 이름이 rpc-server입니다. libibverbs가 있는 상태로 빌드하면 RPC 연결이 알아서 RDMA로 바뀝니다. RPC 서버에는 보안 기능이 없으니, 기기끼리 잇는 전용 연결에서만 쓰세요. Ollama는 이렇게 모델을 여러 기기에 나눠 올리지 않습니다.

vLLM 텐서 병렬은 더 빠를 수 있다

vLLM이나 TensorRT-LLM은 층 하나를 여러 기기에 나눠 맡길 수 있습니다. 이 방식을 텐서 병렬이라고 부릅니다. 토큰마다 기기가 저마다 층의 일부만 읽으니, 이때는 대역폭도 합쳐집니다. NVIDIA 기술 블로그는 NVFP4 Llama 3.3 70B를 TensorRT-LLM 텐서 병렬로 돌린 결과를 실었습니다. 출력 토큰 하나에 걸리는 시간이 두 대에서 절반쯤으로, 네 대에서 4분의 1을 조금 넘는 수준으로 줄었습니다. 한 테스터는 DeepSeek V4 Flash 0731을 두 대에서 vLLM으로 돌렸습니다. 같은 두 대의 llama.cpp RPC보다 네 배쯤 빨랐습니다. 다만 글쓴이가 밝혔듯 두 쪽은 가중치와 양자화가 서로 다릅니다.

CanRun은 텐서 병렬을 계산하지 않습니다. 이 사이트의 여러 대 행은 모두 llama.cpp RPC 기준입니다. 여러 대에서 vLLM을 돌릴 계획이라면 이 행은 llama.cpp 기준값으로만 보세요. vLLM은 가중치 형식과 메모리 설정도 따로 씁니다.

맥 스튜디오·스트릭스 헤일로·RTX 5090과 비교

두 번째 표는 128GB DGX Spark 한 대를 다른 기기와 나란히 놓았습니다. 위에서부터 128GB 스트릭스 헤일로(Ryzen AI Max+ 395) PC, 2026년 맥 스튜디오의 M5 Max 128GB와 M5 Ultra 256GB가 차례로 나옵니다. M5 Max는 40코어 GPU 칩입니다. 마지막 줄은 시스템 RAM 32GB를 단 RTX 5090 PC입니다.

가장 비슷한 기기는 스트릭스 헤일로입니다. 대역폭이 256 GB/s로 DGX Spark와 비슷하고, gpt-oss-120b는 두 기기 모두에서 쾌적하게 돌아갑니다. 둘 다 공개 벤치마크가 있습니다. 차이는 GPU 몫입니다. CanRun은 스트릭스 헤일로의 GPU 몫을 메모리의 약 70%인 89.6GB로 봅니다. 그래서 Solar Open 2 250B의 Q2_K 파일은 스트릭스 헤일로의 GPU 몫에 들어가지 않고, CanRun은 이 파일을 CPU 전용으로 계산합니다. CPU 전용 상한 때문에 ‘겨우 가능’ 배지가 붙습니다(이론 추정). DGX Spark에서는 같은 파일이 GPU에 올라가 원활하게 돌아갑니다. llama.cpp DGX Spark 토론에는 같은 빌드로 두 기기를 비교한 결과도 있습니다. 대화 첫머리의 gpt-oss-120b 프롬프트 처리는 DGX Spark가 두 배 가까이 빨랐습니다.

M5 Max의 대역폭은 614 GB/s로 DGX Spark의 두 배가 조금 넘습니다. 이 차이는 dense 모델에서 드러납니다. Gemma 4 31B와 Llama 3.3 70B는 M5 Max에서 원활하게 돌아가고, DGX Spark에서는 느리게 돌아갑니다. Qwen3.5 122B-A10B는 M5 Max에서 쾌적하게, DGX Spark에서 원활하게 돌아갑니다. 같은 128GB라도 CanRun은 맥의 GPU 몫을 약 70%로 봅니다. 그래서 DGX Spark GPU에 들어가는 Solar Open 2 250B Q2_K 파일이 M5 Max GPU에는 들어가지 않습니다. M5 Max에서는 이 파일을 CPU 전용으로 계산하고, CPU 전용 상한 때문에 ‘겨우 가능’ 배지가 붙습니다. 추정 속도 자체는 DGX Spark보다 높게 나오고, 이 값은 이론 추정입니다. macOS 기본 한도는 CanRun의 값보다 높습니다. 자세한 내용은 ‘맥 미니·맥북·맥 스튜디오에서 로컬 LLM 돌리기 — M4·M5 통합 메모리는 얼마나 필요할까’에 있습니다.

M5 Ultra는 대역폭이 DGX Spark의 4.5배쯤입니다. 256GB 구성이면 MXFP4 DeepSeek V4 Flash 0731이 한 대에 들어갑니다. CanRun 추정으로는 쾌적하게 돌아갑니다(이론 추정). DGX Spark로 같은 파일을 돌리려면 128GB 두 대나 64GB 네 대가 있어야 합니다.

RTX 5090은 VRAM이 32GB이고 대역폭이 1,792 GB/s로 DGX Spark의 여섯 배가 넘습니다. VRAM에 들어가는 모델은 훨씬 빠르게 돌아갑니다. Gemma 4 31B는 RTX 5090에서 쾌적하게 돌아갑니다. 더 큰 모델은 시스템 RAM으로 넘쳐야 합니다. 시스템 RAM이 32GB면 gpt-oss-120b가 들어가지 않습니다. 64GB면 전문가를 RAM에 두고 원활하게 돌아갑니다. 이 값은 RAM 속도에 따라 달라지는 이론 추정입니다. Llama 3.3 70B는 두 기기 모두에서 느리게 돌아가지만 이유가 다릅니다. RTX 5090에서는 층 일부가 시스템 RAM에 남고, DGX Spark에서는 모델 전체가 GPU에 있어도 대역폭이 발목을 잡습니다. 그래픽카드와 시스템 RAM을 함께 쓰는 방법은 ‘그래픽카드보다 큰 MoE 모델 돌리기 — gpt-oss-120b와 시스템 RAM’에서 다룹니다.

다음으로 볼 만한 페이지:

• 카탈로그의 모든 모델을 한 대·두 대·네 대로 본 결과: NVIDIA DGX Spark
• 128GB 통합 메모리 미니PC 비교 — AI Max+ 395(스트릭스 헤일로)·DGX Spark·맥 스튜디오: 스트릭스 헤일로와 맥의 GPU 몫, 같은 빌드로 비교한 스트릭스 헤일로 결과
• 그래픽카드 2장으로 로컬 LLM — 메모리는 더해지고 속도는 더해지지 않는다: 모델을 여러 장치에 나누면 메모리는 늘고 속도는 늘지 않는 이유

이 숫자는 얼마나 확실한가

메모리 수치는 공식으로 계산한 값입니다. 실제 GGUF 파일 크기, 모델 설정에서 구한 KV 캐시 크기, 연산 버퍼 공식을 씁니다. 근사가 들어가는 곳은 GPU 몫입니다. 128GB 구성은 가장 낮은 공개 부팅 기록에서 구했고, 64GB 구성은 그 값에서 다시 계산했습니다. 여러 대를 이으면 CanRun은 모델을 가장 많이 맡는 기기 한 대를 봅니다. 층은 llama.cpp 기본값처럼 기기마다 남은 메모리 비율로 나눈다고 봅니다. 층마다 크기가 같다고 보고 계산하므로 이 몫도 근사입니다.

한 대의 속도는 ‘실측’ 라벨이 붙은 칸이 공개 벤치마크 결과입니다. 나머지 한 대 칸은 ±20% 범위의 보정된 추정입니다. 보정에는 llama.cpp 개발자들이 mmap을 끄고 잰 DGX Spark 결과 파일과, llama.cpp 풀 리퀘스트 하나에 실린 DGX Spark 결과를 썼습니다. 프롬프트 처리 계수는 그 풀 리퀘스트에서만 구했습니다. 여러 대 행의 판정은 모두 이론 추정(±30%)이고, 같은 모델의 CanRun 한 대 추정보다 빠르게 나오지 않습니다. 한 대에 들어가는 모델에는 여러 대 판정을 따로 보여 주지 않습니다. 한 대 칸에 공개 벤치마크가 있는 Gemma 4 31B도 그렇습니다. 계산기에서 이 모델로 여러 대를 고르면 그 추정이 공개 벤치마크보다 높게 나올 수 있습니다. 공개 벤치마크가 CanRun의 한 대 추정보다 낮기 때문입니다. 기기를 건너는 시간은 기본 TCP 연결로 두 대를 돌린 공개 결과에서 구했습니다. RDMA로 두 대를 이은 공개 결과도 있습니다. 같은 테스터가 잰 한 대 결과와 비교하면, 기기를 건널 때마다 잃는 시간이 CanRun이 잡은 값보다 짧았습니다. 네 대는 비교할 공개 결과가 없습니다. 여러 대의 프롬프트 처리 속도는 한 대와 같은 값으로 추정하며, 대략 ±40% 범위입니다. 두 대로 돌린 공개 결과는 한 대보다 빠른 경우와 느린 경우가 섞여 있습니다.

텐서 병렬, 전원 모드, 다른 프로그램이 쓰는 메모리, 동시에 여러 요청을 받는 경우는 계산하지 않습니다. 본문의 판정 이름은 8k 컨텍스트·f16 KV 기준입니다. 생각 모드가 있는 모델은 답하기 전에 생각에 토큰을 더 쓸 수 있습니다. Gemma 4 31B처럼 기본으로 꺼져 있어도 마찬가지라, CanRun은 속도 기준을 1.5배 엄격하게 잡습니다. 아래 범례에는 이 조정이 나오지 않습니다. 판정 기준은 다음과 같습니다.

자주 묻는 질문

DGX Spark 64GB로 gpt-oss-120b를 돌릴 수 있나요?

CanRun 계산으로는 한 대로는 안 됩니다. gpt-oss-120b는 64.3GB가 필요한데, CanRun이 64GB 구성에서 보는 GPU 몫은 48.2GB입니다. 64GB 두 대를 이으면 들어갑니다. 이때 속도는 이론 추정이고, 위 표에 나옵니다. 128GB 한 대에서는 쾌적하게 돌아가고, 공개 벤치마크도 있습니다.

DGX Spark를 두 대 이으면 더 빨라지나요?

llama.cpp RPC로 이으면 빨라지지 않습니다. 메모리는 합쳐지지만 토큰이 두 기기를 모두 거치기 때문입니다. CanRun의 여러 대 추정은 같은 모델의 한 대 추정보다 느립니다. 두 대로 돌린 공개 결과도 한 대보다 느리거나, 차이가 몇 % 안쪽이었습니다. NVIDIA 안내와 블로그에서 쓰는 vLLM이나 TensorRT-LLM의 텐서 병렬은 다릅니다. 두 대가 한 대보다 빨랐다는 공개 결과가 있고, NVIDIA가 직접 잰 Llama 3.3 70B는 두 배쯤 빨라졌습니다. CanRun은 이 경우를 계산하지 않습니다.

DGX Spark는 몇 대까지 이을 수 있나요?

NVIDIA는 네 대까지 지원합니다. 두세 대는 QSFP 케이블로 바로 잇고, 네 대면 NVIDIA 안내대로 200GbE 스위치를 씁니다. NVIDIA는 대수를 2의 거듭제곱으로 맞추라고 권합니다. NVIDIA DGX Spark 페이지에는 두 대와 네 대 결과가 있고, 세 대는 계산기에서 확인할 수 있습니다.

ASUS Ascent GX10 같은 협력 제조사 제품도 같은 기기인가요?

같은 GB10 칩과 같은 메모리 대역폭을 쓰고, 주로 저장장치가 다릅니다. 그래서 CanRun은 이 제품들을 DGX Spark로 계산하고, 계산기에서 제품 이름으로 찾을 수도 있습니다. NVIDIA가 직접 파는 제품은 128GB뿐이고, 64GB 구성은 협력 제조사만 팝니다.

DGX Spark로 70B 모델을 돌릴 수 있나요?

올릴 수는 있지만 dense 모델은 느립니다. Q4_K_M Llama 3.3 70B는 8k에서 64GB 구성에도 들어가지만, 두 구성 모두에서 느리게 돌아갑니다. 두 구성의 속도는 공개 벤치마크에서 잰 값입니다. 전체 크기가 더 큰 MoE 모델이 오히려 훨씬 빠릅니다. 128GB 구성의 gpt-oss-120b처럼 토큰마다 읽는 가중치가 적기 때문입니다.

출처

• NVIDIA DGX Spark 제품 페이지: 대역폭이 같은 64GB·128GB 구성, 협력 제조사만 파는 64GB 구성, 최대 네 대 연결, 케이블 연결과 2의 거듭제곱 권고
• NVIDIA 블로그: 64GB DGX Spark: 64GB 구성을 파는 협력 제조사
• NVIDIA DGX Spark 릴리스 노트: 두 구성을 모두 지원하는 시스템 소프트웨어
• NVIDIA 개발자 포럼: DGX OS 7.5.0에서 부팅 뒤 남는 메모리 감소: 여러 커널의 부팅 로그(CanRun 값의 출발점인 가장 낮은 기록 포함)와 문제를 고치는 업데이트에 관한 답
• NVIDIA 개발자 포럼: DGX 시스템이 차지하는 메모리: CanRun이 빼는 데스크톱 기본 사용량
• NVIDIA DGX Spark 사용자 안내: 알려진 문제: 할당할 수 있는 양보다 적게 나오는 남은 메모리, nvidia-smi의 Not Supported 표시
• NVIDIA 개발자 포럼: CUDA 메모리 부족 오류 대신 멈추는 현상: 메모리가 바닥나 기기가 멈췄다는 사용자 보고
• NVIDIA 개발자 포럼: DGX Spark의 느린 mmap: mmap을 켰을 때와 껐을 때의 모델 로딩
• NVIDIA DGX Spark 사용자 안내: 클러스터링: 케이블로 세 대, 스위치로 네 대
• NVIDIA 안내: 케이블로 잇기·스위치로 잇기: 두 대는 케이블 하나, 세 대는 고리 연결, 스위치 요건
• NVIDIA 안내: 여러 대에서 NCCL·여러 대에서 vLLM: 두 대~네 대용 NVIDIA 공식 안내
• NVIDIA 안내: DGX Spark에서 llama.cpp: 한 대 기준 llama.cpp 안내와 빌드 명령
• NVIDIA 기술 블로그: DGX Spark로 작업 규모 늘리기: 한 대·두 대·네 대에서 TensorRT-LLM 텐서 병렬로 돌린 NVFP4 Llama 3.3 70B
• llama.cpp 토론 #16578: DGX Spark 성능: TCP로 한 대·두 대에서 돌린 gpt-oss-120b, 한 대에 안 들어가는 모델을 두 대로 돌린 결과, 같은 빌드로 비교한 스트릭스 헤일로
• Classmethod: DeepSeek V4 Flash 0731을 DGX Spark 한 대·두 대로: RDMA로 이은 llama.cpp RPC 한 대·두 대 결과, 한 대에 안 들어간 파일, 두 대 vLLM 텐서 병렬
• llama.cpp RPC README: RPC 서버, 빌드 옵션, RDMA, 보안 기능이 없다는 점
• llama.cpp DGX Spark 결과 파일: CanRun의 DGX Spark dense·MoE 속도 계수를 맞춘 한 대 결과(mmap 끔)
• llama.cpp 풀 리퀘스트 #22522: CanRun의 MoE 속도 계수에도 쓰고 프롬프트 처리 계수를 구한 DGX Spark 한 대 결과
• NVIDIA 개발자 포럼: DGX Spark 가격 변경: 메모리 공급 부족을 이유로 한 2026년 2월 가격 변경
• Apple: 맥 스튜디오(M5 Max·M5 Ultra) 사양: M5 Max·M5 Ultra 메모리 구성과 대역폭