Molayo

© 2026 Molayo

Dev.to헤드라인2026. 06. 02. 15:52

DGX Spark에서 Qwen2.5-32B 실행하기: 3주간의 2,859회 테스트, 오류 0건 — 전체 설정 가이드

요약

DGX Spark 하드웨어에서 Qwen2.5-32B 모델을 vLLM으로 최적화하여 실행하는 가이드를 제공합니다. AWQ 양자화와 특정 vLLM 플래그 설정을 통해 에이전트 파이프라인에 필수적인 결정론적 출력과 높은 처리량을 확보하는 방법을 다룹니다.

핵심 포인트

  • AWQ 4비트 양자화를 통해 32B 모델의 메모리 점유율을 18GB로 절감
  • vLLM의 연속 배치와 접두사 캐싱을 활용한 높은 처리량 달성
  • ARM64 환경에서 --enforce-eager 플래그 사용 필수
  • 에이전트 루프를 위한 64K 컨텍스트 윈도우 및 도구 호출 최적화

이 설정을 선택한 이유

만약 여러분이 에이전트 파이프라인 (agent pipelines)을 구축하고 있다면, 이미 그 문제를 알고 있을 것입니다. 47번째 단계에서 도구 호출 (tool call) 하나가 잘못되면, 전체 자율 루프 (autonomous loop)가 망가져 버립니다. 클라우드 API (Cloud APIs)에는 속도 제한 (rate limits)이 있으며, 여러분의 에이전트가 새벽 3시에 작동하고 있다는 사실에는 관심이 없습니다.

저는 로컬 설정이 에이전트에게 가장 중요한 한 가지, 즉 결정론적이고 구조적으로 완벽한 출력 (deterministic, structurally perfect output)을 매번 제공할 수 있는지 확인하고 싶었습니다. 3주 동안 제가 배운 내용은 다음과 같습니다.

하드웨어

DGX Spark (GB10)
128GB 통합 메모리 (unified memory)
20코어 ARM64
Ubuntu 24.04 LTS

단일 머신, 단일 모델입니다. Kubernetes는 사용하지 않았습니다. CGNAT 뒤에 있는 주거용 방에 위치하며, Cloudflare Tunnel을 통해 노출되어 있습니다.

모델 및 엔진

bash
huggingface-cli download Qwen/Qwen2.5-32B-Instruct-AWQ

python -m vllm.entrypoints.openai.api_server
--model Qwen2.5-32B-Instruct-AWQ
--served-model-name Qwen2.5-32B
--host 0.0.0.0 --port 8000
--max-model-len 65536
--gpu-memory-utilization 0.9
--dtype auto
--enforce-eager
--enable-auto-tool-choice
--tool-call-parser hermes

주요 플래그 (flags) 설명:

  • --enforce-eager: ARM64는 CUDA 그래프 (CUDA graphs)를 처리할 수 없습니다. 이는 선택 사항이 아닌 필수 사항입니다.
  • --max-model-len 65536: 긴 에이전트 루프를 위한 전체 64K 컨텍스트 윈도우 (context window).
  • --gpu-memory-utilization 0.9: KV 캐시 (KV cache) 급증에 대비해 10%의 여유 공간을 남겨둡니다.
  • --tool-call-parser hermes: Qwen2.5는 도구 호출 (tool calls)을 위해 Hermes 형식을 사용합니다.

AWQ 4비트 양자화 (quantization)가 이를 가능하게 만들었습니다. 풀 정밀도 (full precision)의 32B 모델은 가중치 (weights)에만 약 64GB가 필요합니다. 양자화하면 약 18GB가 되어, 128GB 통합 메모리 풀에서 KV 캐시를 위한 충분한 공간을 확보할 수 있습니다.

수치 데이터

원시 성능 (Raw Performance)

단일 스트림 생성 (Single-stream generation): 12.9 tok/s. 속도 경쟁에서 이길 수준은 아닙니다. ARM64와 32B 파라미터 (parameters)는 매우 무거운 작업입니다.

하지만 vLLM의 연속 배치 (continuous batching)를 사용하면 처리량 (throughput)은 이야기가 달라집니다:

  • 25개 동시 접속: 시스템 처리량 266 tok/s
  • TTFT P50: 649ms
  • 25개 동시 접속 시 TTFT P99: 1,579ms
  • TPOT 중앙값 (median): 74ms

vLLM의 접두사 캐싱 (prefix caching)이 TTFT (첫 토큰 지연 시간) 부하를 크게 줄여주고 있습니다. 에이전트 루프 (agent loops) 내에서 연속적인 호출은 시스템 프롬프트 컨텍스트 (system prompt context)를 공유하며, 캐시 히트 (cache hits) 덕분에 첫 토큰 지연 시간이 낮게 유지됩니다.

동시성 절벽 (The Concurrency Cliff)

가장 놀라운 발견은 다음과 같습니다:

  • 30개 동시 접속: 성공률 100%
  • 35개 동시 접속: 타임아웃 (timeout) 비율 100%

성능이 점진적으로 저하되는 것이 아니라, 단단한 벽에 부딪히는 식입니다. 메모리 대역폭 (memory bandwidth)이 약 32~33개의 동시 요청에서 최대치에 도달하며, GPU 메모리가 더 이상 이를 처리할 수 없습니다. DGX Spark 배포를 계획 중이라면, 여유 공간(headroom) 없이 최대 30개의 동시 접속을 기준으로 계획하십시오.

벤치마크 결과

7개 세션에 걸쳐 EvalScope를 통해 2,859회의 코드 생성 테스트를 수행했습니다. 각 테스트는 JSON 구조, 함수 호출 스키마 (function call schema), 출력 완결성, 그리고 타임아웃 준수 여부를 검증합니다.

구조적 오류: 0건.

비교를 위해 동일한 1,280개의 프롬프트를 클라우드 API (cloud APIs)로 실행했습니다:

모델지연 시간 (Latency)오류 (Errors)출력 (평균 라인 수)
STORM (DGX, 32B)19.6s037
...

DeepSeek가 속도와 상세함 (verbosity) 측면에서 승리했습니다. Kimi는 빠르지만 형식 오류 (format breaks)가 발생했습니다. 14B 모델을 탑재한 Mac M4는 품질 면에서 놀라울 정도로 경쟁력이 있었습니다.

시사점은 무엇인가?

채팅 및 실시간 애플리케이션의 경우, 클라우드 API가 승리합니다. 더 빠르고 간편하며 하드웨어를 관리할 필요가 없습니다.

하지만 다음과 같은 에이전트 파이프라인 (agent pipelines)의 경우:

  • 긴 도구 호출 루프 (tool-calling loops)를 실행하는 경우
  • 단 하나의 잘못된 JSON이 전체 흐름을 깨뜨리는 경우
  • 예측 불가능한 시간대의 속도 제한 (rate limits)을 허용할 수 없는 경우
  • 프롬프트 데이터가 자신의 하드웨어에 머물기를 원하는 경우

...적절한 설정을 갖춘 로컬 추론 (local inference)은 클라우드 API가 제공하지 못하는 것, 즉 _보장된 출력 구조 (guaranteed output structure)_를 제공합니다. 2,859번의 테스트 중 단 한 번도 모델이 형식을 깨뜨리지 않았습니다. 이것이 바로 제품의 핵심 가치입니다.

직접 시도해 보세요

모든 것은 오픈 소스입니다. 설정을 재현하고, 벤치마크를 실행하며, 수치를 확인해 보세요:

DGX 설정, vLLM 튜닝(tuning), 또는 벤치마크 방법론(benchmark methodology)에 대해 궁금한 점이 있으신가요? 댓글을 남겨주세요.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0