DGX Spark를 조금 느리게 쓰기로 한 이유

DGX Spark 두 대로 큰 모델을 돌리다 보면 최고 속도보다 더 중요한 숫자가 있다. 끝까지 완주하느냐다.

MiniMax-H3의 같은 ComfyUI workflow를 무제한 상태로 실행했을 때 spark는 267.69초 뒤 완전히 멈췄다. SSH도 끊겼고 전원 버튼으로 다시 시작해야 했다. 다시 같은 위험을 반복하는 대신 GPU 그래픽 클록 상한을 2GHz로 낮추고, 성능·전력·온도와 완주 여부를 함께 측정했다.

결론부터 말하면 두 대 모두 300–2000MHz 제한을 유지하기로 했다.

쉽게 말해 GPU를 최고 속도로 계속 밀어붙이지 않고, 조금 느리게 돌리는 설정이다. 그 대가와 효과는 다음과 같았다.

• DeepSeek V4 Flash 0731의 중앙 decode 속도는 11.91% 낮아졌다.
• 두 GPU의 평균 부하 전력은 46.80% 줄었다.
• token당 전력 효율은 65.59% 높아졌다.
• 무제한에서 호스트가 멈췄던 MiniMax-H3 workflow는 제한 상태에서 완료됐다.

이전에 DeepSeek V4 Flash 공식 API와 DGX Spark 두 대를 비교하고, Unsloth GGUF와 native vLLM을 비교하면서 로컬 구성의 절대 성능을 살펴봤다. 이번에는 같은 구성에서 최고 클록을 조금 양보하면 운영 특성이 얼마나 달라지는지 본 실험이다.

어떻게 비교했나

DeepSeek는 NVIDIA DGX Spark 두 대를 ConnectX-7로 직결하고, 공식 deepseek-ai/DeepSeek-V4-Flash-0731 checkpoint를 vLLM tensor parallel 2와 DSpark speculative decoding으로 실행했다. DGX Spark는 128GB 통합 메모리와 ConnectX-7을 갖춘 Grace Blackwell 데스크톱 시스템이다.^[1]

무제한과 제한 상태에서 정확히 같은 420-token prompt를 사용했다. 128-token warmup 한 번 뒤 1024-token 출력 세 번을 측정했고, 느린 run도 삭제하지 않은 채 중앙값을 썼다. DSpark 특성상 run별 편차가 커서 세 번의 중앙값을 정밀한 보편값으로 과해석하지 않았다.

MiniMax-H3는 spark 한 대에서 같은 ComfyUI workflow를 사용했다. 864×480, 124프레임, 24fps, 20 steps, seed 1234로 고정했고 spark2는 telemetry 확인용으로만 뒀다.

제한 상태의 실제 부하 클록은 양쪽 모두 약 1.98–1.99GHz였다.

DeepSeek V4 Flash: 속도 12% 대신 전력 47%

처리량 손실은 분명히 있었다. 하지만 11.91%의 중앙 decode 속도를 양보하고 평균 부하 전력을 46.80% 줄였다. 측정 구간에서 token당 효율은 65.59% 좋아졌고 에너지는 거의 절반이 됐다.

다만 실행별 decode 범위는 무제한 52.24–87.89 tok/s, 제한 66.72–86.40 tok/s로 넓었다. 따라서 “2GHz면 언제나 정확히 11.91% 느리다”가 아니라, 이번 짧은 반복에서는 중앙 처리량이 약 12% 낮았고 전력 감소 폭은 그보다 훨씬 컸다고 읽는 편이 맞다.

MiniMax-H3: 무제한은 멈췄고 제한 상태에서는 완주했다

무제한 실행은 끝나지 않았으므로 완료 시간이나 완료 에너지를 비교할 수 없다. 표의 무제한 값은 호스트가 멈추기 전까지 수집된 부분 telemetry다. 실패한 셀에 그럴듯한 완료값을 채우거나, 위험한 무제한 실행을 반복하지 않았다.

제한 상태에서는 321.55초에 workflow가 끝났고 5.167초짜리 H.264/AAC 영상이 만들어졌다. 124프레임 전체 decode와 오디오를 확인했고, 검은 프레임이나 정지 프레임, 심각한 객체 붕괴는 보이지 않았다.

이 한 쌍의 실행만으로 hard-hang의 근본 원인이 온도였다고 확정할 수는 없다. driver, firmware, 메모리 압박, 전원이나 특정 kernel 경로도 변수일 수 있다. 여기서 확인한 사실은 같은 workflow가 무제한에서는 호스트를 멈췄고, 2GHz 제한 상태에서는 한 번 정상 완료됐다는 범위다.

재부팅 뒤에도 유지하되 언제든 되돌릴 수 있게 했다

NVIDIA의 nvidia-smi -lgc는 원하는 최소·최대 GPU 클록을 MHz 쌍으로 지정하고, -rgc는 기본 GPU 클록으로 되돌린다. 두 명령 모두 root 권한이 필요하다.^[2]

두 호스트에 다음 systemd unit을 설치했다.

[Unit]
Description=GPU clock cap 300-2000MHz
After=multi-user.target
Wants=multi-user.target

[Service]
Type=oneshot
ExecStart=/usr/bin/nvidia-smi -lgc 300,2000
RemainAfterExit=yes
ExecStop=/usr/bin/nvidia-smi -rgc
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

설치와 적용:

sudo install -m 0644 gpu-clock-cap.service \
  /etc/systemd/system/gpu-clock-cap.service
sudo systemctl daemon-reload
sudo systemctl enable --now gpu-clock-cap.service

두 노드 확인:

for host in spark spark2; do
  ssh "$host" '
    systemctl is-enabled gpu-clock-cap.service
    systemctl is-active gpu-clock-cap.service
    nvidia-smi \
      --query-gpu=clocks.current.sm,power.draw,temperature.gpu \
      --format=csv,noheader
  '
done

제한 해제:

sudo systemctl disable --now gpu-clock-cap.service

disable --now가 서비스를 멈추면 ExecStop의 nvidia-smi -rgc가 실행된다. 여기서 “영구 제한”은 하드웨어를 되돌릴 수 없게 바꿨다는 뜻이 아니라, enable된 systemd 서비스가 재부팅 때 정책을 다시 적용한다는 뜻이다.

지금은 2GHz가 더 실용적이다

DGX Spark를 항상 benchmark 최고점으로만 쓸 생각이라면 12%의 중앙 decode 손실도 아쉬울 수 있다. 하지만 내가 이 장비로 하는 일은 짧은 속도 측정만이 아니다. 몇 분에서 몇 시간 걸리는 영상 생성과 대형 모델 실험이 끝까지 돌아가는지가 더 중요하다.

이번 조건에서는 2GHz 제한이 그 목적에 잘 맞았다.

• DeepSeek V4 Flash의 체감 가능한 성능을 대부분 유지했다.
• 전력과 온도를 크게 낮췄다.
• 같은 MiniMax-H3 workflow를 끝까지 실행했다.
• 재부팅 후에도 자동으로 적용된다.
• 필요하면 서비스 하나를 끄는 것으로 기본 정책에 돌아갈 수 있다.

그래서 spark와 spark2는 당분간 300–2000MHz로 둔다. driver나 firmware, runtime이 크게 바뀌면 같은 workflow로 다시 확인할 예정이다.

측정 범위

이 결과는 DGX Spark 두 대와 해당 날짜의 driver/runtime, DeepSeek V4 Flash 0731 vLLM+DSpark 구성, MiniMax-H3 고정 workflow에 대한 제한적인 실사용 테스트다. DeepSeek는 측정 요청 세 번의 중앙값이며, H3 안정성 비교는 무제한 실패 한 번과 제한 완료 한 번이다. 다른 모델과 장비에서도 같은 비율이나 안정성 차이가 난다고 일반화하지 않는다.

원문 출처2개 펼치기

출처 ×

원문 열기 ↗ 전체 출처 보기

Tue, 11 Aug 2026 01:53:39 +0900