DGX Spark에서 vLLM: 아키텍처, 구성 및 로컬 평가

vLLM은 NVIDIA DGX Spark에서 빠르고 효율적인 로컬 추론을 가능하게 하여 노트북 수준 개발과 데이터 센터 GPU 서비스 사이의 격차를 메웁니다. OpenAI 호환 API와 고급 메모리, 배칭, 텔레메트리 제어를 결합함으로써, vLLM은 개발자들이 DGX Spark의 고유 하드웨어 아키텍처에서 대형 NVFP4 모델을 로컬로 실행할 수 있게 합니다.

DGX Spark 아키텍처 및 메모리 모델

NVIDIA DGX Spark은 통합 CPU 및 GPU 메모리 풀을 활용하는 GB10 Grace Blackwell SoC를 중심으로 설계되었습니다. 이 아키텍처는 추론 워크로드가 구성되고 실행되는 방식에 큰 영향을 미칩니다.

통합 메모리와 모델 용량

공유 CPU/GPU 메모리 풀을 통해 개발자는 고정된 전용 GPU 메모리 풀보다 더 큰 NVFP4 모델을 로드할 수 있습니다. 이는 모델 아키텍처와 런타임 구성에 따라 단일 Spark에서 최대 2000억 파라미터까지의 모델을 실행하는 것이 실용적임을 의미합니다. vLLM은 --gpu-memory-utilization, --max-model-len, --max-num-seqs와 같은 플래그와 페이지 기반 KV 캐시를 사용하여 모델 크기, 컨텍스트 길이, 동시성을 균형 있게 관리합니다.

하드웨어별 검증

DGX Spark에 배포할 때는 sm_121 타깃에 대해 검증된 vLLM 빌드, 컨테이너 이미지 태그 및 런타임 설정을 사용해야 합니다. 대형 GPU 시스템에서 가져온 구성은 성능 벤치마크라기보다 커널 지원을 위한 엔지니어링 체크리스트로 간주해야 합니다.

NVFP4 MoE 최적화

DGX Spark은 NVFP4 Mixture-of-Experts (MoE) 서비스에 특히 적합합니다. NVFP4는 메모리 압력을 감소시키고 프리필 동작을 개선합니다. 약 100억~150억 개의 활성 파라미터를 가진 MoE 모델은 시스템 메모리 대역폭에서 디코드 성능을 최적화하는 작은 활성 파라미터 집합 때문에 매우 적합합니다.

로컬 서빙을 위한 vLLM 기능

vLLM은 DGX Spark의 로컬 소규모 배치 추론 프로파일을 최적화하는 여러 핵심 기능을 제공합니다.

페이지 기반 KV 캐시와 연속 배칭

채팅 워크로드에서 정적 배칭의 비효율성을 피하기 위해 vLLM은 매 디코드 단계마다 요청을 수락하고 제거하는 연속 배칭을 사용합니다. 페이지 기반 KV 캐시와 결합하면 DGX Spark은 과도한 메모리 단편화 없이 다수의 인플라이트 요청을 지원할 수 있습니다. 120B NVFP4 MoE 모델을 사용한 테스트에서 KV 캐시 사용률은 단일 사용자에 대해 보통 5% 이하, 소규모 배치 데모 트래픽에 대해 30% 이하였습니다.

OpenAI 호환 스트리밍

Spark의 vLLM 엔드포인트는 OpenAI 호환 API(예: http://localhost:8000/v1)를 사용하므로 기존 클라이언트 코드를 재사용할 수 있습니다. stream=true 사용은 로컬 응답성을 위해 필수적이며, 토큰이 도착하는 즉시 렌더링하여 채팅, 코딩, 에이전트 워크플로우에서 인지된 지연을 최소화합니다.

Prometheus를 통한 가시성

vLLM의 Prometheus 엔드포인트(/metrics)는 개발자가 로컬 장치의 상태를 모니터링할 수 있게 합니다. DGX Spark에 대한 주요 신호는 다음과 같습니다:

• KV-cache 사용률 (vllm:kv_cache_usage_perc)
• 프롬프트 및 생성 토큰 카운터
• TTFT(첫 토큰까지 시간) 및 토큰 간 지연 히스토그램

런타임 구성 및 배포

DGX Spark에 성공적으로 배포하려면 런타임 플래그를 시스템의 통합 메모리 프로파일 및 특정 모델 레시피에 맞춰야 합니다.

모델 선택 가이드

모델 선택은 주요 성능 레버입니다. 100130B MoE NVFP4 모델 중 활성 파라미터가 100억150억인 모델이 Spark의 메모리 용량 및 디코드 속도에 가장 효율적으로 맞습니다.

핵심 vllm serve 플래그

• --gpu-memory-utilization: OS, 컨테이너 런타임 및 KV 캐시 성장에 대한 여유 공간을 남기도록 조정해야 합니다.
• --max-model-len 131072: 최대 프롬프트 및 완성 길이를 설정합니다. vLLM은 모든 요청에 대해 전체 길이를 예약하는 대신 활성 컨텍스트를 기준으로 스케줄링합니다.
• --max-num-seqs 4: 동시 디코드 스트림 수를 낮게 유지하여 토큰당 대역폭 비용이 TTFT를 급증시키는 것을 방지합니다.
• 자동 프리픽스 캐싱: vLLM V1에서 기본적으로 활성화되며, 시작 프롬프트를 공유하는 요청 간에 KV 블록을 재사용합니다. 이는 긴 시스템 프롬프트에 매우 유리합니다.

JIT 사전 워밍 및 로딩

콜드 스타트 지연은 중요한 요소이며, 부팅 후 첫 요청은 Inductor와 FlashInfer JIT 코드 생성을 트리거하여 Nemotron-3-Super의 경우 약 25초가 소요됩니다. 개발자는 시작 시 작은 "ping" 요청을 보내 커널을 워밍업해야 합니다. 또한 초기 가중치 로딩에 10~15분이 걸릴 수 있지만, fastsafetensors 또는 InstantTensor와 같은 경로를 검토하여 시간을 단축할 수 있습니다.

로컬 평가 결과: Nemotron-3-Super

Nemotron-3-Super-120B-A12B-NVFP4 모델을 단일 DGX Spark에서 평가한 결과, 다양한 시나리오에서 22.7~23.7 토큰/초 범위의 일관된 디코드 처리량을 보였습니다.

시나리오	프롬프트 토큰	생성 토큰	TTFT	전체 지연	프리필 토큰/초	디코드 토큰/초
Typical judge call	58	2	0.42 s	~0.53 s	140	~23
Medium prompt, short gen	1,834	32	1.12 s	1.12 s	1,636	23.7
Long prompt, short gen	7,234	32	3.85 s	~5.26 s	1,877	22.7
Medium prompt, long gen	1,834	108	1.12 s	~5.74 s	1,639	23.4
Long prompt, long gen	7,234	124	3.84 s	~9.26 s	1,884	22.9

주요 성능 인사이트

• 프리필 스케일링: 프리필 처리량은 프롬프트가 커질수록 증가하여 140에서 거의 1,900 토큰/초까지 상승합니다. 이는 오버헤드가 더 많은 토큰에 걸쳐 상쇄되기 때문입니다.
• 디코드 안정성: 디코드 처리량은 프롬프트 길이에 관계없이 안정적으로 유지되며, 활성 파라미터 수와 FP4 커널 경로에 의해 결정됩니다.
• TTFT: 프롬프트 크기가 네 배 증가하면 첫 토큰까지 시간이 대략 세 배가 됩니다.

운영 요약

DGX Spark에서 vLLM을 최적화하려면 개발자는 100~130B MoE NVFP4 모델을 우선 선택하고, sm_121에 대해 검증된 공식 vLLM 이미지를 사용하며, 통합 메모리 풀에 맞게 --gpu-memory-utilization을 조정해야 합니다. JIT을 사전 워밍하고 /metrics 엔드포인트를 활용하면 예측 가능하고 인터랙티브한 로컬 추론 경험을 보장합니다.