2026-06-07 — 회 조회
vLLM 공식 DGX Spark 가이드: 왜 120B NVFP4 모델의 디코딩이 약 23 tok/s 인가, 그리고 그것이 대역폭 제약 로컬 추론에 대해 가르쳐 주는 것
2026 년 6 월 1 일, vLLM 프로젝트는 NVIDIA 의 DGX Spark(GB10 Grace Blackwell, sm_121, 128 GB 통합 메모리)에서 vLLM 을 실행하는 공식 가이드를 발표했다. vllm/vllm-openai:cu130-nightly 컨테이너에서 Nemotron-3-Super-120B-A12B-NVFP4 를 서빙하며, 디코딩 22.7-23.7 tok/s
무엇이 출시되었나
2026 년 6 월 1 일, vLLM 프로젝트는 NVIDIA 의 DGX Spark 에서 vLLM 을 실행하는 공식 단계별 안내를 발표했다. DGX Spark 는 128 GB 통합 LPDDR5X 메모리와 컨슈머 Blackwell 의 sm_121 연산 능력을 갖춘 데스크사이드형 GB10 Grace Blackwell 기기다. 「부팅에 성공했다」는 대부분의 포럼 게시물과 달리, 이 글은 검증된 배포 레시피와 실제 로컬 평가를 결합하여 단일 박스 추론 경제성을 어떻게 생각할지에 대한 참고 자료로도 기능한다.
간판 워크로드는 Nemotron-3-Super-120B-A12B-NVFP4 다: 총 120B 파라미터, 전문가 혼합(MoE) 구성에서 토큰당 약 12B 가 활성화되며, NVFP4 로 양자화되었다. 이 조합이야말로 이 시도의 전부다. BF16 의 120B 밀집 모델은 결코 들어가지 못하지만, 약 12B 의 활성 파라미터를 가진 NVFP4 MoE 는 128 GB 에 넉넉히 들어가며 토큰당 그 가중치의 일부만 스트리밍하면 된다.
보고된 수치
vllm/vllm-openai:cu130-nightly 컨테이너(CUDA 13)에서 --gpu-memory-utilization 0.85, --max-model-len 131072, --max-num-seqs 4 로 서빙하여, 이 글은 다음을 측정했다:
| 지표 | 보고된 범위 |
|---|---|
| 디코딩 처리량 | 22.7-23.7 tok/s |
| 프리필 처리량 | ~140 tok/s(58-tok 프롬프트)에서 ~1,884 tok/s(7,234-tok 프롬프트) |
| 첫 토큰까지의 시간 | 0.42 s(짧음)에서 ~3.85 s(긺) |
| KV 캐시 사용률 | 단일 사용자 5% 미만; 소규모 배치 30% 미만 |
두 가지가 두드러진다. 첫째, KV 캐시 점유율이 극히 작아 128 GB 는 거의 전부 컨텍스트가 아닌 가중치에 쓰인다. 둘째, 프리필은 프롬프트 길이에 따라 확장되지만 디코딩은 무엇이든 약 23 tok/s 에서 평탄하게 머문다. 그 평탄한 디코딩 선이 바로 단서다.
왜 디코딩이 평탄한가: 연산이 아니라 대역폭
구조적 교훈은 메모리 버스에 있다. GB10 은 256-bit LPDDR5X 인터페이스(8,533 MT/s)를 통해 273 GB/s 로 데이터를 이동시킨다 — H100 의 ~3.35 TB/s HBM3 보다 약 12 배 느리다. 자기회귀 디코딩은 토큰당 한 번 활성 가중치를 읽으므로, 낮은 배치에서는 텐서 코어가 대부분 메모리를 기다리며 놀고 있다. 독립적인 분해 보고서도 같은 점을 직설적으로 지적한다: 273 GB/s 에서는 아무리 많은 연산을 투입해도 35 GB 모델은 이론상 약 7.8 tok/s 가 상한이다.
이것이 또한 NVFP4 가 데이터센터 카드에서보다 여기서 더 중요한 이유다. 가중치를 16 bytes/param(BF16)에서 약 4.5 bytes/param 으로 줄이면 토큰당 이동하는 바이트 수가 절반이 되며, 이는 대역폭 제약 기기에서 디코딩 처리량을 대략 두 배로 늘린다. 생태계에 떠도는 한 비교는 동일한 Nemotron 3 Super 가 NVFP4 빌드에서 약 38 tok/s 인 반면 Q4_K_M GGUF 에서는 약 19.5 tok/s 임을 보여준다 — 같은 모델이며, 변수는 포맷과 커널 경로다. (vLLM 글 자체의 ~23 tok/s 는 해당 글의 특정 131K 컨텍스트 구성과 컨테이너를 반영하므로, 출처 간 수치는 완전한 동일 비교가 아니라 방향성 있는 것으로 다룰 것.)
실무적 관점
이 글은 그 적용 범위에 대해 상쾌할 만큼 솔직하다: DGX Spark 는 「로컬 단일 사용자 또는 소규모 배치 추론 대상으로 보는 것이 최선」이다. 의도적으로 --max-num-seqs 4 로 실행한다; 동시성을 더 높이면 지연 시간을 희생하게 되는데, 이미 연산이 아니라 대역폭이 부족하기 때문이다. ConnectX 패브릭 상의 다중 Spark 구성은 언급되지만 이 글에서는 명시적으로 평가되지 않는다.
통합 메모리 아키텍처가 조용한 조력자다. CPU 와 GPU 가 하나의 물리적 128 GB 풀을 공유하므로, 가중치와 KV 캐시는 PCIe 를 가로지르는 cudaMemcpy 왕복 없이 상주한다 — HBM 대비 원시 대역폭은 잃지만 복사 비용을 건너뛴다. 이것이 바로 120B 급 모델이 데스크톱에서 존재할 수 있게 하는 요인이다.
실무자 메모: 100-130B 의 NVFP4 MoE 를 위한 단일 박스 로컬 서버를 사양 설계한다면, 데이터센터급 처리량이 아니라 약 20-40 tok/s 디코딩과 낮은 max-num-seqs 를 전제로 기대치를 설정하라. 실제로 실행할 컨테이너／CUDA 조합을 검증하라(여기서 공식 경로는 cu130-nightly 이미지와 모델별 추론 파서다); 다른 컨텍스트, 양자화 커널, 또는 서빙 스택에서 발표된 디코딩 속도는 깔끔하게 이전되지 않으며, 초기 가중치 로딩만으로도 10-15 분이 걸릴 수 있다.
충분히 고려되지 않은 관점: 거의 모든 DGX Spark 벤치마크 헤드라인은 단일 스트림 디코딩 수치이며, 이는 MoE 모델을 돋보이게 한다 — 토큰당 약 10% 의 파라미터만 이동하기 때문이다. 이 기기가 소규모 팀에게 쓸 만한지를 실제로 예측하는 지표는 현실적인 KV 점유 하의 동시성 디코딩이다. KV 캐시 사용률 5% 미만에서는 시스템이 가장 약한 자원을 거의 사용하지 않는다; 흥미롭고(그리고 대체로 미발표된) 질문은 273 GB/s 버스에서 배치를 높일 때의 처리량 대 지연 곡선이다. 왜냐하면 바로 그곳이 데스크사이드 통합 메모리 기기가 몇 명의 동시 사용자를 버텨내느냐, 아니면 엄격히 1 인용 도구로 무너지느냐의 갈림길이기 때문이다.