메인 콘텐츠로 건너뛰기
DGX Spark ships with 128GB of unified memory shared between the Grace CPU and the Blackwell GPU. That pool is large enough for dense models up to ~70B at 4-bit quantization and MoE models up to ~120B total parameters at NVFP4 — but not every model at every quantization fits, and not every runtime respects the unified memory layout the same way. This page tells you what works, what works with caveats, and what doesn’t fit at all.

​
간단한 결론

One DGX Spark runs dense models up to ~70B at Q4 and MoE models up to ~120B total parameters at NVFP4. MoE models are the better fit because only a fraction of their parameters activate per token, giving you higher throughput for the same memory footprint.

​
How the 128GB gets used

DGX Spark does not have discrete VRAM. The Grace CPU and Blackwell GPU share a single 128GB memory pool over a 273 GB/s interconnect. When you load a model, 3 things consume that pool:
  1. 모델 가중치 — 파라미터 수와 양자화 수준에 따라 결정되는 가장 큰 고정 비용입니다.
  2. KV 캐시 — 컨텍스트 길이와 동시 요청 수에 따라 증가합니다. 크기 산출 방법은 DGX Spark 메모리 튜닝 페이지를 참고하시기 바랍니다.
  3. 시스템 및 CUDA 오버헤드 — DGX OS, CUDA 런타임, vLLM의 CUDA 그래프 등으로 인해 보통 4에서 8 GB 정도가 소모됩니다.
시스템 오버헤드를 제외하면 가중치와 KV 캐시를 저장하는 데 사용할 수 있는 실질적인 메모리 용량은 대략 115-120 GB 정도입니다.
DeepSeek-V4-Flash-0731은 1 스파크에 맞지 않습니다. 2 스파크들은 배포된 162–167 GB 가중치 계층을 분할하기에 충분한 메모리를 제공하지만, 이중 스파크 기반의 배포 증명 자료는 커뮤니티에서 검증된 것이므로 0731 재검증이 필요합니다. 32K–128K 컨텍스트부터 시작하여 클러스터를 설정하기 전에 DeepSeek V4 Flash 로컬 하드웨어 문서를 꼭 읽어보시기 바랍니다.

​
딥 모델 호환성

딥 모델들은 모든 토큰에 대해 모든 파라미터를 활성화합니다. 이로 인해 가중치 메모리와 연산량이 파라미터 수에 따라 선형적으로 증가하는데, 70B 딥 모델은 35B 딥 모델에 비해 대략 두 배의 메모리와 연산량을 필요로 합니다. DGX 스파크에서는 70B 규모의 모델을 4비트 양자화 수준까지 구동할 수 있으나, KV 캐시 부하로 인해 동시 실행 능력은 제한됩니다.
Qwen3-32B 모델은 동일한 하드웨어 환경에서도 커뮤니티 벤치마크 결과에 따라 성능 편차가 크게 나타납니다(9 대 44 토큰/초). 이러한 차이는 플래시 어텐션 설정 및 양자화 백엔드의 차이에서 기인합니다. 배포 결정을 내리기 전에 사용 환경에서 직접 테스트해보시기 바랍니다.
A 70B dense model at NVFP4 uses ~35 GB for weights, but each concurrent user adds KV cache on top. Community reports cap multi-user concurrency at 5-10 users before the Spark becomes unresponsive. For multi-user 70B workloads, consider two DGX Sparks.

​
통합 메모리 환경에서 밀집형 모델 사용 시 고려해야 할 사항

  • ChatGPT-OSS-20B on Ollama에서는 89%개의 GPU가 사용되고 있는 것으로 나타나지만 지연 시간이 너무 길어서 문제가 됩니다. 커뮤니티에서는 이 모델의 경우 vLLM이나 SGLang으로 전환할 것을 권장하고 있습니다.
  • Qwen3.6-27B at NVFP4 is estimated to achieve 40–55 tok/s for a single user, based on similar dense models in the 27–32B range. The wide spread reflects differences in quantization backend and flash attention settings. With ~14–15 GB for weights, you have ample room for long context on a single Spark.
  • 70B 밀집형 모델들은 정상 작동하지만, 단일 Spark 시스템에서 구현 가능한 밀집형 아키텍처의 실질적 한계치이기도 합니다. 실제 병목 현상은 가중치 메모리가 아닌 동시 요청별 KV 캐시 처리에 발생합니다.
  • For dense models above 70B, you need a two-Spark cluster. See One vs two DGX Sparks.

​
MoE 모델과의 호환성 정보

MoE 모델은 DGX Spark에 가장 적합한 선택입니다. 모든 전문가 가중치가 메모리에 로드되지만, 각 토큰마다 일부만 활성화되므로 소형 모델 수준의 연산 비용으로도 대형 모델의 성능을 누릴 수 있습니다.
Gemma-4-26B-A4B-it fails on DGX Spark because vLLM’s gpu_memory_utilization parameter is not respected during startup profiling on unified memory (SM121). The system becomes unresponsive. The workaround is to use NVFP4 quantization explicitly, but community reports indicate the fix is still incomplete as of mid-2026. Track vLLM issue #46307 for updates.

​
MoE 배포 시 성능 관련 참고사항

  • Qwen3.5-35B-A3B 모델을 NVFP4 방식으로 실행할 경우 단일 사용자 환경에서 47~50 토큰/초의 속도를 유지합니다. 첫 토큰 생성까지 걸리는 시간도 Ollama 대비 3초에서 0.12초로 단축됩니다.
  • Qwen3.6-35B-A3B 모델은 기본 vLLM 설정에서도 단일 사용자 기준 47~50 토큰/초의 속도를 유지합니다. Atlas 엔진(순수 Rust/CUDA 기반)을 사용하면 최대 약 120 토큰/초까지 도달해 기본 vLLM 대비 2.8x배 빠르며, 최대 1M 토큰 길이의 컨텍스트도 처리 가능합니다.
  • Qwen3.5-122B-A10B 모델은 JSON-KIE 작업 수행 시 약 30 토큰/초의 속도를 유지하며 100% 수준의 MTP 수락률을 보여줍니다. 하지만 100K개의 동시 요청이 발생하면 성능이 저하됩니다.
  • GLM-4.5-Air 모델은 106B MoE 구조와 12B개의 활성 파라미터를 갖추어 커뮤니티에서 Spark 환경에 가장 적합한 모델로 평가받고 있습니다. 메모리 요구량도 적절한 수준입니다.
GLM-4.6 (총 357B 개 / 현재 활성화된 것은 32B 개) 모델은 단일 DGX Spark 장치에 탑재하기에 너무 크다. Q4 클래스 양자화 수준에서는 약 178 GB의 메모리가 필요한데, 이는 128 GB에 불과한 통합 메모리 풀의 용량을 훨씬 초과한다. 128 GB 용량의 하드웨어를 사용 중이라면 대신 GLM-4.5-Air 모델을 선택하시기 바란다. 전체 모델 변형 간 비교 내용은 GLM 제품군 페이지를 참고하시기 바란다.

​
Quantization format comparison on SM121

DGX Spark에 탑재된 Blackwell GPU는 SM121 아키텍처를 기반으로 합니다. 모든 양자화 형식이 기본적으로 지원되는 것은 아닙니다.
DGX Spark 환경에서는 NVFP4이 기본으로 권장되는 방식입니다. 이 방식은 SM121 하드웨어에서 기본적으로 지원되며 품질 저하를 최소화하면서 용량을 75%만큼 줄여줍니다. 또한 vLLM과 Atlas 엔진 모두와 호환됩니다. llama.cpp나 Ollama를 사용할 경우에만 GGUF Q4_K_M를 선택하시기 바랍니다.

​
컨텍스트 길이 제한 사항

컨텍스트 길이는 KV 캐시가 소모하는 메모리 양에 직접적인 영향을 미치며, 이는 모델 가중치에 할당될 수 있는 메모리 양을 줄이게 됩니다. DGX Spark의 통합 메모리 구조에서는 KV 캐시에 사용되는 모든 바이트가 모델 가중치, CUDA 런타임 및 운영체제가 공유하는 128GB 용량 풀에서 할당됩니다. FP8 KV 캐시(--kv-cache-dtype fp8)를 활용하면 품질 저하가 2% 미만 수준에 그치면서 해당 수치들이 절반으로 줄어들며, 결과적으로 처리 가능한 컨텍스트 양이 두 배로 증가합니다. KV 캐시 크기 산출 방식 및 튜닝 파라미터에 관해서는 DGX Spark 메모리 튜닝 문서를 참고하시기 바랍니다.

​
DGX Spark에서 Kimi K 3 실행하기

Kimi K3 does not fit on any practical DGX Spark cluster. The model’s 2.8T total parameters (~50B active per token through Stable LatentMoE) need about 1.4 TB at the native MXFP4 precision. Eight DGX Sparks pool 1 TB and still fall 376 GB short. NVIDIA documents Spark clusters up to 4 nodes (512 GB), and Moonshot recommends a supernode with 64 or more accelerators for K3. For the full calculation, see the Kimi K3 hardware deep dive. For Spark today, the models that fit are in the tables above — up to ~70B dense at Q4 and ~120B MoE at NVFP4 on a single node. See what to run instead of Kimi K3 for the best pick at each Spark count.

​
Qwen3.8 모델의 구동 가능성

The Qwen3.8 flagship shipped in August 2026 as Qwen3.8-2.4T-A95B: a Mixture-of-Experts model with 2.4 trillion total parameters and 95B active per token, text-only, released under Qwen’s custom qwen3.8-max license. The generation also includes Qwen3.8-27B (released 2026-08-14, Apache-2.0), a dense vision-language model that does fit a single Spark — see the verdict below the cluster math.

​
양자화 수준별 메모리 요구량

KV 캐시, CUDA 그래프 및 시스템 오버헤드를 제외한 가중치 전용 메모리 산출식: Even at the most aggressive quantization, a single DGX Spark cannot run Qwen3.8-2.4T-A95B. This is a multi-node model that requires at least 10 Sparks at Q4 — and realistically 20+ Sparks at FP8 for reasonable KV cache headroom.

​
다중 노드 클러스터 규모 산정

MoE models load all expert weights into memory even though only a subset activates per token. Qwen3.8-2.4T-A95B activates 95B of its 2.4T, but the 1.2 TB at Q4 is a hard floor regardless. The MoE advantage is in compute (fewer FLOPs per token), not in memory.

​
런타임 지원 현황

Qwen 측에서는 2.4T 가중치와 함께 vLLM, SGLang, TokenSpeed용 배포 가이드라인도 제공합니다. 하지만 llama.cpp, Ollama, LM Studio에 대한 지원 정보는 아직 공개되지 않았습니다. 이 모델의 하이브리드 Gated DeltaNet + Gated Attention 구조를 고려할 때 GGUF 기반 배포를 실현하려면 별도의 커널 최적화 작업이 선행되어야 합니다.

​
하나의 Spark에 맞는 Qwen3.8 모델

Qwen3.8-27B is the single-machine member of the generation: a dense 27B vision-language model released 2026-08-14 under Apache-2.0. Every official precision fits one Spark — 55.6 GB BF16 outright, and the official 30.9 GB FP8 build leaves roughly 90 GB of the 128 GB pool for KV cache. Serve it through vLLM or SGLang; no GGUF or NVFP4 build exists yet. Full sizing is on the Qwen3.8 model page; tested Spark configurations will be added here once verified.

​
GLM-5.2 활용 가능성

​
MoE 모델의 필요 메모리 용량은 활성화된 파라미터 수로 산정해서는 안 됩니다

활성화된 매개변수들은 각 토큰별 연산에만 영향을 주며, 저장된 가중치의 최소값에는 영향을 주지 않습니다. GLM-5.2은 총 753B개의 매개변수를 보유하고 있습니다. (Hugging Face에 따르면 753,329,940,480개의 매개변수가 78개의 레이어에 분포되어 있으며, 각 토큰마다 8개의 전문가가 활성화되고 256개의 전문가 중 1개는 공유됩니다.) 따라서 가중치당 비트 수의 투명한 하한값은 정확히 4비트가 됩니다.
이 수치는 대략 3개의 단일 DGX Spark 노드가 제공하는 128 GB 용량과 맞먹는데, 따라서 1개의 Spark 노드만으로는 턱없이 부족합니다. 2개의 Spark 노드를 사용해도 256 GB 용량만으로는 가중치 데이터만으로도 충분하지 않죠. 3개의 Spark 노드를 활용하면 이론상으로는 384 GB 용량을 확보할 수 있지만, 실제로는 포맷 메타데이터와 운영체제, 런타임 버퍼 및 KV 캐시를 위해 클러스터 전체에서 약 7 GB GB가 소모되므로 실제 활용이 불가능합니다. 4개의 Spark 노드를 사용한 512 GB 구성이야말로 실질적인 여유 공간을 제공하는 첫 번째 설정입니다. FP8 연산을 위해서는 가중치 데이터만 처리하는 데에도 753 GB GB가 필요한데, 이는 오버헤드를 고려하지 않아도 6개의 Spark 노드가 필요한 수치입니다.
Do not claim GLM-5.2 fits on 1 or 2 Sparks at INT4 or FP8 — the published 753B checkpoint size rules it out. Do not promise a 1M context on a 4-Spark cluster from parameter counts alone. Verify the exact downloadable files, runtime support, and measured KV-cache use first.

​
사용 사례별로 권장되는 모델들

원하는 모델을 선택하셨나요? 이제 해당 모델을 연결해보세요

Give your DGX Spark deployment one authenticated endpoint at https://api.tokios.com — no inbound ports, about 5 minutes.

​
속도와 모델 크기 중 어느 것을 선택할 것인가

DGX Spark에서 가장 핵심적인 균형점은 모델의 성능과 처리량 사이에 있습니다.
  • If speed matters most (coding agents, interactive chat): Pick a 35B MoE model at NVFP4. You get 47-50 tok/s (or 120 tok/s with Atlas), which feels instant.
  • 품질이 가장 중요할 경우 (복잡한 추론이나 연구 작업): 사용 가능한 모델 중 가장 크기가 큰 Qwen3.5-122B-A10B 또는 GLM-4.5-Air를 선택하되, 이 경우 25에서 30 토큰/초 정도의 속도만 기대할 수 있습니다.
  • 동시 접속자 수가 중요할 경우 (팀 단위 서비스 제공): 35B 크기 MoE 모델을 유지하면서 FP8 KV 캐시 기능을 활용해 동시 접속자 수를 극대화하세요. 구체적인 수치는 DGX Spark 메모리 튜닝 문서를 참고하시기 바랍니다.

​
사용 중인 Spark 환경에서의 호환성 확인

커뮤니티에서 제공하는 벤치마크 결과도 참고할 만하지만, 실제 사용 환경의 DGX OS 버전, CUDA 드라이버, vLLM 빌드에 따라 결과가 달라질 수 있습니다. 모델을 확정하기 전에 다음 검증을 수행해보세요.
  1. 실행 전 메모리 상태 확인:
  2. 보수적인 설정값으로 모델을 실행해보기:
  3. Increase max-model-len incrementally until you hit your target context or memory pressure.
  4. 추론 과정 중 지속적으로 상태를 모니터링하세요:
  5. 벤치마크 처리량:
만약 어떤 단계에서 시스템이 반응하지 않게 된다면 전원을 재부팅한 뒤 gpu_memory_utilization 값을 0.05만큼 줄여보시기 바랍니다.

​
Tokios를 통해 귀하의 모델을 서비스하세요

DGX Spark에서 vLLM, Ollama 또는 llama.cpp를 이용해 모델을 실행한 뒤에는 인바운드 포트를 열지 않고도 인증이 필요한 단일 엔드포인트를 통해 모델을 제공할 수 있습니다. Tokios 커넥터가 Spark에서 외부로 연결되며 https://api.tokios.com 주소에서 OpenAI 및 Anthropic과 호환되는 API를 제공합니다. 전체 설정 과정은 DGX Spark를 프라이빗 엔드포인트으로 전환하기 문서를 참고하시고, 업스트림 모델 ID를 배포 이름에 매핑하려면 모델 등록하기로 바로 이동하시기 바랍니다.

DGX Spark에서의 vLLM 활용

각 모델 크기에 맞는 NVFP4 설정값을 적용하여 vLLM을 단계별로 설치하는 방법입니다.

DGX Spark 메모리 최적화

KV cache sizing, batch trade-offs, and tuning parameters for 128GB.

DGX Spark 한 대 vs 두 대 활용

분산형 추론을 위해 두 번째 Spark를 도입해야 하는 시점과 1 노드 이상의 용량을 필요로 하는 모델에 대한 설명입니다.

양자화의 기본 개념

어떤 형식을 선택할지 결정하기 전에 NVFP4, AWQ, FP8, 그리고 GGUF에 대해 먼저 이해해두어야 합니다.