솔직히 말해서, 놀랐습니다. 두 대의 DGX Spark 유닛을 클러스터로 연결하고 DeepSeek-V4-Flash를 실행했을 때, 결과는 Mac Studio M3 Ultra보다 총 생성 시간(실제 벽시계 시간)에서 1.78배 빨랐습니다 — 즉, 작업을 약 절반의 시간에 완료했다는 뜻입니다. 그리고 이는 DGX Spark가 추가적인 양자화 없이 공식 FP8 모델을 실행한 결과입니다.
이 벤치마크를 진행하면서, 제가 계속해서 강조해 온 주장이 다시 한번 수치로 뒷받침되었다고 느꼈습니다. 즉:
LLM 성능은 메모리 대역폭에 기반한 디코드 속도(초당 토큰 수, TPS)만으로 측정할 수 없습니다.
GPU 처리 성능, 노드 간 통신, 메모리 계층 구조, 양자화 품질, 컨텍스트 길이, 병렬 처리 등 — 이러한 모든 요소의 "균형"이 실제 사용자 경험을 결정합니다. 그리고 DGX Spark는 단순히 더 나은 균형을 가지고 있었습니다.
사용된 벤치마크: shi3z의 코딩 벤치마크
측정을 위해, shi3z의 일본어 LLM 벤치마크에 있는 코딩 벤치마크를 사용했습니다. 과제는 "단일 생성에서 React로 실행되는 채팅 앱을 완성하는 것"입니다. 생성된 코드는 실제로 Docker에서 시작되며, Playwright를 사용하여 로그인, 친구, DM, 실시간 업데이트를 자동으로 테스트하여 80점 만점의 기능 점수를 산출합니다.
antirez의 ds4 추론 엔진을 통해 Mac Studio M3 Ultra에서 DeepSeek-V4-Flash Q4(4 비트 양자화)를 실행한 결과는 shi3z의 저장소에 나열되어 있습니다. 아래 표는 해당 결과를 이번 DGX Spark 2-유닛 클러스터 + 공식 FP8 결과와 비교합니다.
벤치마크 결과
"tok/s에서는 지지만 벽시계 시간에서는 이기는" 이유
표를 보고 "잠깐, Mac이 tok/s에서 더 빠르네?"라고 생각한다면, 당신 말이 맞습니다. 하나의 토큰을 내뱉는 순간 속도(디코드 TPS)만 보면 Mac Studio M3 Ultra가 1.58 배 빠릅니다. 이는 Apple Silicon의 막대한 메모리 대역폭 때문입니다.
하지만 여기에는 함정이 있습니다. 동일한 "80/80 만점" 채팅 앱을 완성하기 위해, Mac은 8,036개의 토큰을 작성한 반면, DGX Spark는 2,866개의 토큰을 작성했습니다. 이는 약 2.8 배의 차이입니다.
둘 다 DeepSeek-V4-Flash를 사용했으며 공식적인 품질 저하는 없었지만, Q4로 양자화된 Mac 쪽이 중복된 반면, 전체 품질 FP8로 실행된 Spark 쪽이 간결하게 유지되었다고 해석하는 것이 자연스럽습니다. 양자화가 출력 분포에 미치는 영향이 디코드 속도에는 나타나지 않지만 생성 전략에 조용히 영향을 미치는 것은 일반적인 현상입니다.
결과적으로 계산은 다음과 같습니다:
실제 벽시계 시간 = (출력 토큰 수) ÷ (tok/s)
Mac: 8,036 ÷ 26.2 = 307 초 우리: 2,866 ÷ 16.6 = 172 초
tok/s에서는 지지만 벽시계 시간에서 이긴다는 것은 "더 적은 단계로 동일한 정답에 도달한다"는 의미입니다. 실사용에서 인간이 경험하는 것은 순간적인 tok/s가 아니라 "작업이 완료될 때까지의 시간"입니다.
사용된 구성
- 하드웨어: DGX Spark × 2 (NVIDIA GB10, Blackwell 기반, 각 128 GB 통합 메모리)
- 노드 상호 연결: ConnectX-7 200 Gbps RoCE를 통한 직접 연결 (Tensor Parallel = 2, PyTorch 분산 백엔드)
- 추론 엔진: Aiden의 레시피, vLLM 0.21.1dev에 b12x (일련의 GB10 특화 CuTe DSL 커널 세트)를 통합
- 모델: DeepSeek-V4-Flash 공식 FP8 (154 GB, FP8 어텐션, MXFP4 MoE — DeepSeek이 출시한 공식 형식)
- 컨텍스트: 524,288 토큰 (512K), util 0.82, KV 캐시 19.85 GiB, 동시성 3.89×
- 다중 토큰 예측 (MTP): 약 62%의 수용률을 가진 추측 디코딩 (출력 품질 저하 없이 속도 향상)
성능 자세히 살펴보기
이 벤치마크의 수치 외에도, 순수 디코드 및 프리필 속도를 별도로 측정했습니다:
- 순수 디코드 속도 (짧은 텍스트, TTFT 제외): 약 39 tok/s로 안정적
- 프리필 속도 (긴 컨텍스트): 1,277 tok/s (b12x 커널이 없는 이전 구성의 196 tok/s보다 약 6.5 배 빠름)
- 긴 컨텍스트에서의 디코드: 8K → 64K → 128K → 256K → 512K → 768K로 증가시켰을 때도 디코드 속도가 급격히 떨어지지 않았고, 오히려 가속화되었습니다 (768K에서 106 tok/s). 이는 DeepSeek의 Sparse Attention (DSA)이 b12x 커널에 기본 구현되어 있어 어텐션 계산이 컨텍스트 길이와 거의 무관하기 때문입니다.
"양자화 없음, 전체 품질"의 결과
또 한 가지 강조하고 싶은 점은 DGX Spark 쪽이 모델에 추가적인 양자화를 전혀 사용하지 않았다는 것입니다. HuggingFace에 분산되어 있는 공식 154 GB를 있는 그대로 로드하여 DeepSeek이 설계한 공식 양자화 형식인 FP8 어텐션 + MXFP4 MoE로 실행했습니다.
로컬 LLM 세계에서는 거대 모델을 실행하기 위해 IQ2 (2 비트) 또는 Q4로 압축하는 것이 상식이 되었지만, 이는 분명히 품질을 깎아냅니다. 실제로 이전에 DeepSeek-V4-Flash의 IQ2XXS (2 비트) 버전을 시도했을 때, 동일한 벤치마크에서 55/80 + 에이전트 행동 붕괴라는 결과를 보았습니다. 양자화는 공짜 점심이 아닙니다.
두 대의 DGX Spark로 256 GB의 통합 메모리를 확보할 수 있는 구성은 "거대 모델을 전체 품질로 실행"하는 옵션을 처음으로 현실로 만듭니다. 이는 숫자가 암시하는 것보다 더 의미 있는 진전이라고 생각합니다.
Spark의 "균형"이 효과를 본 이유
이 결과를 뒷받침한 기술적 요소들을 분석해 보겠습니다:
- b12x 커널 제품군: CuTe DSL을 사용하여 GB10 / SM12.x용으로 특별히 작성된 네 가지 유형의 커널 (NVFP4 융합 MoE GEMM, NVFP4 밀집 GEMM, FP8 페이징 어텐션, 희소 MLA 어텐션). 일반 vLLM의 MARLIN 경로와 달리, 역양자화 없이 융합 모드에서 직접 계산합니다.
- 200 Gbps RoCE 직접 연결: TP=2 노드 간 all-reduce가 레이어당 두 번 발생하지만, 200 Gbps 직접 연결이 효과적인 지연 시간을 얇게 유지하여 디코딩의 병목 현상이 되지 않습니다.
- 128 GB 통합 메모리 × 2: HBM과 DDR을 분리하지 않는 Grace Blackwell의 장점입니다. 154 GB 공식 FP8 모델을 두 유닛에 그대로 분할하여 512K 컨텍스트를 위한 19.85 GiB KV 캐시를 위한 충분한 공간을 확보할 수 있습니다.
- DeepSeek Sparse Attention (DSA)의 기본 구현: b12x 커널은 GB10의 기본 희소 연산을 사용하여 어텐션 복잡성이 컨텍스트 길이에 의존하지 않는 설계를 올바르게 처리합니다. 이로 인해 디코드 속도가 컨텍스트 길이에 따라 급락하지 않는 결과가 나왔습니다.
즉, 메모리 대역폭, 연산 성능, 노드 통신, 긴 컨텍스트 최적화, 양자화 품질 중 단 하나의 요소만 뛰어나서는 이 결과가 나올 수 없었을 것입니다. Spark는 이 모든 요소를 동일 가격대의 어떤 단일 머신 구성보다 높은 수준에서 제공합니다. 이것이 "균형"의 진정한 본질입니다.
실제 사용에서 무엇이 달라질까?
추상적인 이론을 넘어, 몇 가지 구체적인 이점을 소개합니다:
- 방대한 문서의 요약 및 코드 분석이 현실적으로 가능: 512K 컨텍스트와 1,277 tok/s의 프리필 속도로, 전체 책 (~300,000 토큰)을 약 4 분 만에 로드하고 요약할 수 있습니다.
- 에이전트 루프가 멈추지 않음: 3.89× 동시성으로, 디코드가 붕괴되지 않으면서 채팅과 장문 요약을 동시에 실행할 수 있습니다 (예: Hermes Agent 사용).
- 양자화 실패로 인한 "에이전트가 말만 많은" 문제 없음: IQ2 시리즈 모델에서 여러 번 겪었던 함정입니다. 전체 품질에서는 그런 일이 단순히 발생하지 않습니다.
- 전력 소비 측면에서 Mac과 경쟁력: 추론 중 두 GB10의 총 전력 소비는 약 100W–140W로, Mac Studio M3 Ultra 최대 부하 시와 비슷합니다. 1.78 배 성능을 고려하면 전력 효율도 나쁘지 않습니다.
결론: TPS만으로 LLM 성능을 판단하는 시대는 끝났다
토큰을 내뱉는 순간 속도인 디코드 TPS는 확실히 중요한 지표입니다. 하지만 이는 "100 미터 달리기의 최고 속도"와 같습니다. 실제로 필요한 것은 "동일한 정답에 도달하는 시간", "답변의 품질", "동시에 얼마나 많이 실행할 수 있는지", "얼마나 긴 컨텍스트를 처리할 수 있는지", "에이전트 루프가 작동하는지"입니다. 이것이 총점입니다.
이 결과가 보여준 것은 DGX Spark가 이 총점에서 앞서 나가기 시작했다는 것입니다. 우리는 이제 두 대의 유닛을 클러스터로 연결하기만 하면 거대 모델을 공식 품질, 긴 컨텍스트, 에이전트 호환성을 유지하면서 Mac Studio보다 1.78 배 빠른 벽시계 속도로 실행할 수 있는 시대에 접어들었습니다.
지난 몇 년 동안 사람들은 "LLM은 모두 메모리 대역폭이다", "디코드 TPS가 전부다"라고 말해왔지만, Spark를 실제로 실행해 본 후 "균형이 실질적인 성능이다"라는 나의 주장이 마침내 수치로 증명되었다고 느낍니다.
RTX Spark도 발표되었고, 예상보다 상황이 더 뜨거워지고 있는 느낌입니다 (물론 가격이 공개되면 분위기가 식을 수도 있지만...). 커뮤니티가 성장하고 더 많은 최적화와 노하우가 축적되기를 기대합니다!
Jensen은 정말 대단합니다... 그의 통치가 앞으로도 오래 지속될까요?
**
**
**
**
**
보너스
날카로운 독자라면 이런 비판을 제기할 수 있습니다:
"그렇다면 Mac Studio에서도 원본 공식 FP8을 실행했다면 공정한 비교가 아니었을까요?"
"비교가 불공평한 것 아닌가요? Mac Studio는 Q4로 양자화되었기 때문에 중복된 것뿐입니다. Mac Studio에서 원본 공식 FP8을 실행했다면 품질 면에서 동등한 조건이 아니었을까요?" 이것은 합리적인 질문입니다.
결론부터 말하자면: 현재 Mac Studio에서 '원본 공식 FP8 + MXFP4 MoE'를 실용적인 속도로 실행할 수 있는 방법은 없습니다.
- 먼저, 호환되는 추론 엔진이 없습니다.
Apple Silicon에서 DeepSeek-V4-Flash의 공식 형식 (FP8 어텐션 + MXFP4 MoE + Lightning Indexer + DSA Sparse Attention)을 완전히 지원하는 엔진은 없는 것 같습니다 (Claude Code 검색 기준).
- MLX (Apple의 공식 Apple Silicon LLM 프레임워크): MXFP4 MoE 융합 GEMM의 기본 구현이 없고, FP8 페이징 어텐션이 없으며, DeepSeek의 DSA Sparse Attention에 대한 MLX 구현이 없습니다. 실행하려면 bf16으로 업캐스트해야 할 가능성이 높습니다.
- llama.cpp: MXFP4를 직접 로드할 수 없으므로 GGUF로 재양자화가 필요합니다 = 결국 Q4 / Q5 / IQ2 등으로 변환되어 더 이상 "원본 공식" 버전이 아닙니다.
- vLLM: Apple Silicon 지원이 제한적이며, b12x와 같은 GB10 특화 커널은 Mac에서 실행되지 않습니다.
- antirez/ds4: 이것은 Q4를 전제로 DeepSeek V4 Flash를 위해 MLX 기반으로 특별히 작성된 전용 엔진입니다. Mac Studio에서 실행하기 위한 현재의 최적 솔루션이지만, "원본 FP8"을 처리하도록 구축되지는 않았습니다.
antirez가 Q4를 위해 특별히 DeepSeek V4 Flash 전용 엔진을 작성했다는 사실은 Apple Silicon에서 공식 품질을 있는 그대로 실행할 수 있는 실용적인 경로가 현재 존재하지 않는다는 현실을 말해줍니다.
- bf16 업캐스트로 실행하더라도 대역폭이 거의 완전히 소모됩니다.
논의를 위해 누군가가 공식 가중치를 bf16으로 업캐스트하는 MLX 구현을 만들었다고 가정해 봅시다. 대략적인 대역폭 계산으로 어떤 일이 일어날지 추정할 수 있습니다:
- DeepSeek-V4-Flash는 약 300 억 개의 활성 파라미터를 가진 MoE 구성입니다.
- Q4 (4 비트)에서 활성 파라미터는 약 15 GB를 차지하며, ds4는 26.2 tok/s를 달성했습니다 (측정됨).
- 동일한 모델을 FP8 (8 비트)로 유지하면 활성 파라미터는 약 30 GB = 2 배 대역폭 요구 사항 = 동일 엔진에서 이론적으로 ~13 tok/s.
- 나아가 MLX에서 bf16으로 업캐스트하면 활성 파라미터는 약 60 GB = 4 배 대역폭 요구 사항 = 이론적으로 ~6.5 tok/s.
- Mac Studio M3 Ultra의 유효 메모리 대역폭이 약 800 GB/s이므로, 토큰당 60 GB를 읽는 것은 대역폭 한계에 도달하게 됩니다.
즉, Apple Silicon에서 "원본 품질을 취하는" 선택은 현재 "두 배 이상의 속도를 희생하는" 대가를 치릅니다. 전체 품질 bf16으로 겨우 6 tok/s를 얻는 것보다 ds4 + Q4로 26.2 tok/s를 실행하는 것이 더 실용적인 선택이었습니다.
- 이것이 바로 Spark의 구조적 장점이 빛을 발하는 부분입니다.
반면, 이 DGX Spark 구성은 "원본 공식 FP8 + MXFP4 MoE를 기본적으로" 실행합니다. 이는 다음에 의해 지원됩니다:
- GB10 특화 커널인 b12x 제품군은 "역양자화 없이" NVFP4 융합 MoE GEMM 및 FP8 페이징 어텐션을 실행하는 구현을 갖추고 있습니다.
- 이것은 아직 Apple Silicon용으로 작성되지 않았습니다.
- 결과적으로 Spark는 현재 "공식 품질을 있는 그대로" 그리고 "실용적인 속도로" 실행할 수 있는 유일한 현실적인 솔루션입니다.
요약하자면, 하드웨어 대역폭만 보면 단일 유닛의 Mac Studio 절대값은 비슷한 수준이지만, "공식 양자화 형식을 기본적으로 실행하는 커널 구현의 유무" 가 결정적인 차이를 만듭니다. Spark의 장점은 칩 자체뿐만 아니라 b12x와 같은 GB10 특화 소프트웨어 스택과의 전체적인 조합에서 비롯됩니다.
미래에 누군가 Apple Silicon용 MLX로 MXFP4 융합 MoE GEMM, FP8 페이징 어텐션, DSA Sparse Attention을 작성한다면, 이 전제는 무너질 것입니다. 상황은 커뮤니티 구현에 따라 달라질 것입니다. 현재로서는 Spark가 "공식 품질 × 실용적인 속도"의 조합을 달성하는 데 한 걸음 앞서 있다는 것이 사실입니다.
이것은 Claude Code가 제공한 분석 결과입니다.
