2대의 NVIDIA DGX Spark 실전 인퍼런스 경험: 성능·확장성·문제점 공유

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

작성자는 2대의 NVIDIA DGX Spark를 사용해 오픈소스 LLM 인퍼런스와 프로덕션 운영을 수행한 경험을 공유하며 자체 호스팅을 선택한 이유로 프라이버시, 학습 경험, 장기 비용 절감을 들었다. 입력 쿼리는 로컬에서 GPU로 전달되어 모델 파라미터와 활성화를 VRAM에서 로드한 뒤 연산을 거쳐 토큰을 생성하는 흐름으로, Qwen 3.5 122B는 단일 Spark에서 약 40–50 tokens/s, Qwen 3.6 27B는 약 15 tokens/s, Nemotron 3 Super는 약 20–25 tokens/s 정도의 처리량을 보고했다.

하드웨어 비교에서 작성자는 DGX Spark가 M3 Ultra보다 프롬프트 처리에서 빠르지만 RTX Pro 6000보다 느리며, 토큰 생성 속도는 상대적으로 더 느리다고 제시해 성능·비용의 트레이드오프를 명확히 밝혔다. 노드 확장은 메모리 측면에서 거의 1:1 증가하지만 연산 성능은 노드당 약 50–80% 효율로 증가해 2노드 이상부터는 네트워크와 샤딩 오버헤드로 인한 성능 저하와 운영 복잡도가 커진다.

실무적으로는 민감 데이터·지속적 워크로드가 있다면 자체 하드웨어가 경제적일 수 있으나, 전력·냉각 확보와 드라이버·라이브러리 호환성 점검, 확장 시 네트워크 비용 계산이 필수이며 이러한 제약을 고려해야 총소유비용과 안정성을 맞출 수 있다.

실용적 조언

프로덕션 이전에 모델별 tokens/sec을 실제 워크로드로 측정해 응답성 요구와 비용을 비교할 것 — 게시자는 Qwen 3.5 122B에서 40–50 tokens/s라는 실측값을 기준으로 판단했다.
2노드 이상으로 확장 계획이 있다면 네트워크 장비·샤딩 오버헤드·전력·냉각 예산을 우선 확보하고 소프트웨어 호환성 테스트를 수행할 것, 그렇지 않으면 성능 손실과 안정성 문제가 발생한다.
전력·냉각 이슈로 시스템이 불안정하다면 GPU/CPU 언더클럭을 고려해 안정성을 우선 확보한 뒤 최적화 작업을 진행할 것.

섹션별 상세

작성자는 프라이버시·학습 목적·장기 비용 절감을 이유로 클라우드 대신 자체 하드웨어를 선택했으며, 로컬에서 쿼리를 받아 모델 파라미터를 GPU 메모리에 로드하고 내부 연산으로 토큰을 생성해 응답을 반환하는 방식이 선택의 핵심이었다. 선택 사유로는 속도·VRAM·유지비·사용 편의성의 균형을 들었고, 이 균형이 테스트 및 프로덕션에서의 실제 워크로드(오픈소스 LLM 테스트·파인튜닝·고객 작업)에 적합하다고 판단한 경험을 근거로 제시했다. 하드웨어를 소유하면 API 요금 변동이나 정책 변경에 덜 민감해지므로 장기적으로 경제성이 개선될 수 있다는 점이 의미로 제시됐다.

단일 Spark에서 모델을 실행하는 처리 흐름은 입력 쿼리를 GPU로 전달 → 파라미터와 활성화를 GPU 메모리에서 로드 → 연산을 통해 토큰을 생성해 출력하는 구조이며, 저자는 특정 모델들에서 실측 처리량을 제시했다. Qwen 3.5 122B는 단일 Spark에서 약 40–50 tokens/second, Qwen 3.6 27B(denser)는 약 15 tokens/second, Nvidia Nemotron 3 Super는 약 20–25 tokens/second로 보고되었다. 이 수치가 실제 인퍼런스 응용(예: 코딩 보조)에서 '실사용 가능'하다고 판단된다는 점이 실무적 의미로 제시됐다.

동급 규모의 다른 플랫폼과 성능을 비교할 때 입력(프롬프트) 처리 및 토큰 생성 속도에서 차이가 발생하며, 작동 원리는 동일한 입력을 각 플랫폼의 GPU·메모리·드라이버 스택으로 전달해 연산 효율 차이가 출력 속도로 반영되는 것이다. 작성자는 단일 DGX Spark의 프롬프트 처리량이 M3 Ultra Mac Studio보다 약 5배 빠르고 RTX Pro 6000보다 2–3배 느리다는 비교를, 토큰 생성은 M3 Ultra보다 2–3배 느리고 RTX Pro 6000보다 4–5배 느리다는 상대적 수치로 제시했다. 이 비교는 하드웨어 선택 시 성능·비용 트레이드오프를 가늠하는 근거로 활용될 수 있다.

노드 확장 관점에서 메모리 확장은 거의 1:1 수준이라 추가 노드를 통해 더 큰 모델을 올릴 수 있고, 연산 성능은 노드당 약 50–80%의 효율로 증가한다고 보고했다; 처리 흐름은 모델 파라미터를 샤딩해 여러 노드에서 병렬로 연산 → 결과를 조합해 최종 토큰을 내보내는 방식이다. 작성자는 이 수치를 근거로 2노드 수준에서는 실사용 가능하지만 노드 수가 늘어나면 네트워크와 샤딩 오버헤드로 인한 성능 손실이 커진다고 지적했다. 즉, 확장성은 가능하지만 노드 추가에 따른 성능 대비 비용·복잡도가 급증한다는 실무적 의미가 도출됐다.

실제 운영에서 부딪힌 주요 문제로는 2노드 이상으로 확장하기 어려움(추가 네트워킹 장비 필요), 수정된 Blackwell 아키텍처와의 소프트웨어 스택 호환성 문제, 높은 전력 소비와 냉각 문제로 인한 시스템 불안정성이 있다. 작동 상 문제는 네트워크가 모델 샤딩·동기화 과정에서 병목을 만들거나, 특정 드라이버/라이브러리가 수정된 하드웨어 특성에 최적화되지 않아 버그를 일으키는 식으로 드러났고, 전력·냉각 문제는 과도한 전력 사용으로 시스템이 크래시해 언더클럭 같은 조치가 필요했다는 실사용 사례로 뒷받침되었다. 이러한 제약은 대규모 분산 인프라를 구축할 때 비용과 운영 복잡도를 크게 증가시킨다는 점에서 실무적 경고가 된다.

비용 산정 측면에서는 워크로드 패턴이 지속적이고 모델 복잡도가 클수록 자체 하드웨어 보유가 경제적으로 유리해질 수 있으며, 중고 하드웨어의 리셀 가치도 총소유비용(TCO)에 영향을 준다고 언급했다. 계산 흐름 관점에서 동일한 반복적 인퍼런스 수요가 API 요금으로 계속 발생하면 장기적으로 자산 소유가 더 나을 수 있다는 논리로, 작성자는 이 점을 근거로 경제성 판단 기준을 제시했다. 따라서 일회성 또는 간헐적 사용이 대부분인 경우는 클라우드가 더 합리적이지만, 지속적·민감 데이터 워크로드라면 자체 운영이 더 적절할 수 있다는 결론이 나왔다.

용어 해설

모델 병렬화(Model Parallelism): — 큰 모델을 여러 GPU에 나눠서 실행하는 방식으로, 입력 토큰을 분할하거나 파라미터를 샤딩하여 각 노드가 일부 연산을 수행하고 최종 토큰을 합쳐 출력한다. 노드 수와 네트워크 대역폭에 따라 성능과 메모리 한계가 결정되어 대규모 인퍼런스와 분산 학습에서 핵심적이다.
비디오 메모리(VRAM)(VRAM): — GPU가 모델 파라미터·활성화값을 저장하는 전용 메모리로, 모델 크기와 컨텍스트 윈도우를 직접 제약한다. VRAM이 부족하면 모델을 샤딩하거나 오프로드해야 하며, 인퍼런스 처리량과 지연에 큰 영향을 준다.
Blackwell 아키텍처(Blackwell architecture): — NVIDIA의 GPU 아키텍처 계열명으로, 하드웨어 연산 유닛·메모리 서브시스템·드라이버 최적화가 포함된다. 특정 소프트웨어 스택과의 호환성 문제를 일으킬 수 있어, 변형된 구현이 도입되면 개발 커뮤니티가 추가 버그 픽스와 최적화를 요구한다.
메모리 확장(스케일링)(Memory scaling): — 여러 노드를 결합했을 때 사용 가능한 총 모델 메모리가 증가하는 비율로, 1:1에 가까우면 노드 추가만으로 더 큰 모델을 올릴 수 있다. 네트워크와 샤딩 오버헤드에 따라 실제 연산 성능은 메모리 증가율보다 낮게 유지될 수 있다.

언급된 도구

DGX Spark중립

대규모 로컬 인퍼런스용 NVIDIA 기반 하드웨어 클러스터

Mac Studio M3 Ultra중립

단일 머신 소형/중형 인퍼런스 비교용 (작성자는 비교 대상으로 사용)

RTX 6000 / RTX Pro 6000중립

GPU 기반 로컬 인퍼런스·테스트용 하드웨어 옵션

EPYC중립

CPU 플랫폼(서버) 비교용