DGX Spark 1대와 2대, 로컬링크로 연결하면 얼마나 빨라질까요?: 직접 비교한 결과

DGX Spark 두 대를 케이블로 연결해 두고 이런 생각이 들었습니다. 이제 한 대에 작업을 요청하면 다른 한 대도 같이 계산할까요? 그렇다면 글쓰기나 이미지 생성도 두 배쯤 빨라질까요?

DGX Spark는 NVIDIA가 만든 소형 AI 컴퓨터입니다. 외부 AI 서비스에 요청을 보내는 대신, 장비 안에 모델을 내려받아 실행할 수 있습니다. 제가 쓰는 두 대는 이미 NVIDIA Sync로 연결 설정을 마친 상태였습니다. NVIDIA Sync는 Spark에 원격으로 접속하고 장비 간 연결을 설정하는 도구입니다.

2026년 9월 23일, 두 장비에서 언어 모델과 이미지 모델을 각각 실행해 봤습니다. 언어 모델은 두 대에서 더 빨랐고, 이미지 생성은 한 대와 거의 차이가 없었습니다. 다만 케이블을 꽂았다는 이유만으로 두 장비가 함께 계산한 것은 아닙니다.

연결과 함께 계산하는 것은 별도 설정입니다

두 Spark는 QSFP 케이블로 연결했습니다. QSFP는 고속 네트워크 연결에 쓰는 단자 규격입니다. 연결 상태를 확인했을 때 두 포트 모두 200Gbps로 표시됐습니다. 이 숫자는 링크가 연결된 속도이며, 모델이 실제로 그 속도만큼 데이터를 주고받는다는 뜻은 아닙니다.

NVIDIA Sync에서 연결을 마쳐도, Spark 1에서 실행한 프로그램이 Spark 2의 GPU를 자동으로 쓰지는 않습니다. GPU는 AI 계산을 맡는 칩입니다. 두 대가 한 작업을 나눠 하려면 모델 실행 프로그램에 참여할 장비와 계산 분담 방식을 지정해야 합니다. NVIDIA의 연결 점검 문서도 네트워크 설정과 AI 프로그램 실행을 구분합니다.

이번에는 SGLang을 사용했습니다. SGLang은 AI 모델을 메모리에 올리고 요청을 받아 답을 생성하는 프로그램입니다. 언어 모델에는 텐서 병렬화(TP)를 적용했습니다. 모델 내부의 큰 계산을 여러 GPU로 나누는 방식으로, TP=2는 GPU 두 개가 나눠 계산하도록 지정한 값입니다.

실제 준비는 다음 순서로 진행했습니다.

1. 두 장비의 네트워크 연결과 서로 접속할 수 있는 상태를 확인했습니다.
2. GPU 사이의 데이터 교환을 담당하는 NVIDIA 라이브러리인 NCCL로 통신 시험을 했습니다. 두 장비에서 보낸 값이 올바르게 합쳐지는지 확인했습니다.
3. 두 장비에 같은 모델 파일과 실행에 필요한 소프트웨어를 준비했습니다.
4. SGLang에 장비 수 2, 각 장비의 번호 0과 1, 텐서 병렬화 값 2를 지정했습니다.
5. 장비 간 통신에 쓸 주소를 고속 연결 쪽으로 명시한 뒤 실제 생성 요청을 보냈습니다.

이 과정에서 SGLANG_HOST_IP 설정으로 각 장비가 사용할 주소를 명시해야 정상적으로 기동했습니다. 연결된 네트워크가 여러 개라면 프로그램이 어느 주소로 상대 장비와 통신하는지도 확인해야 합니다. 이 설정은 이번 환경에서 해결한 기동 문제이며, 모든 환경에 그대로 적용할 설치 명령은 아닙니다.

같은 모델로 글쓰기와 코드 생성을 비교했습니다

언어 모델은 Qwen3.8-27B를 사용했습니다. Qwen은 알리바바가 개발하는 AI 모델 계열이고, 3.8은 버전입니다. 27B는 모델이 학습한 내부 수치인 파라미터가 약 270억 개라는 뜻입니다. 이런 언어 모델을 내 장비에서 실행하는 것을 로컬 LLM이라고 부릅니다.

실제로 내려받은 모델은 RadixArk/Qwen3.8-27B-NVFP4입니다. 원래 모델의 수치를 낮은 정밀도로 저장하고 계산하도록 바꾼 배포본입니다. 이런 처리를 양자화라고 하며 메모리 사용량을 줄이는 데 쓰입니다. 이름 끝의 NVFP4는 여기에 적용한 NVIDIA의 저정밀 수치 형식을 가리킵니다. 모델 배포 문서에서 구체적인 구성을 확인할 수 있습니다.

한 대와 두 대 모두 같은 모델과 생성 설정을 사용했습니다. 한국어 작성, 코드 생성, 긴 기록 요약을 각각 세 번 실행하고 중앙값을 비교했습니다. 중앙값은 측정값을 순서대로 놓았을 때 가운데 값입니다.

여기서 토큰은 모델이 문장을 처리하는 단위입니다. 한 글자나 한 단어와 항상 일치하지는 않습니다. token/s는 초당 처리한 토큰 수이며, 이번 글에서는 출력 토큰 수를 요청부터 완료까지 걸린 전체 시간으로 나눈 값을 사용합니다. 첫 답을 기다린 시간도 포함하므로, 답이 나오기 시작한 뒤의 생성 속도만 재는 수치와는 다릅니다.

언어 모델은 두 대에서 24~44% 빨랐습니다

먼저 요청을 하나씩 보냈을 때의 결과입니다. 각 작업을 세 번 실행한 중앙값이며, 숫자가 클수록 같은 시간에 더 많은 출력 토큰을 생성했습니다.

한국어 작성은 같은 256토큰을 받는 데 걸린 시간이 약 14.56초에서 11.00초로 줄었습니다. 두 대를 쓴 효과는 있었지만, 처리 속도가 두 배가 되지는 않았습니다.

처음 답이 나오기까지 걸린 시간은 다른 결과를 보였습니다. 한국어 작성은 약 0.20초에서 0.19초로 거의 같았고, 긴 기록 요약은 약 0.55초에서 0.56초로 오히려 조금 길었습니다. 이번 두 대 구성의 이점은 첫 답이 빨리 나타나는 것보다 요청한 분량을 다 받는 시간이 줄어든 것에 있었습니다.

동시에 요청했을 때도 비교했습니다. 이때는 한국어 작성 두 개를 보낸 것이 아니라, 한국어 작성 하나와 코드 생성 하나를 함께 실행했습니다. 아래 수치 역시 시스템 전체의 합산 처리량이 아니라 각 요청의 처리 속도입니다.

한 대에서도 두 요청을 처리할 수 있었지만, 하나씩 실행할 때보다 각각의 속도는 낮아졌습니다. 두 대로 나눠 계산했을 때는 두 작업 모두 더 높은 처리 속도를 보였습니다.

다만 이 실험은 완성된 글이나 프로그램의 품질을 평가한 것은 아닙니다. 출력 길이를 256토큰으로 제한했기 때문에 요청한 글이나 코드가 끝나기 전에 잘렸습니다. 별도의 짧은 계산, 함수 실행, 지정한 도구 호출 확인은 두 구성 모두 통과했지만, 그것만으로 복잡한 업무의 정확도를 판단할 수는 없습니다.

코드가 한국어 글보다 빠른 이유는 확정하지 못했습니다

표에서 코드 생성이 한국어 작성보다 훨씬 빠르게 나옵니다. 같은 장비와 모델을 썼는데도 작업에 따라 결과가 달랐습니다.

두 구성에는 DFlash 계열의 DFlash2라는 생성 가속 방식이 켜져 있었습니다. 작은 보조 모델이 다음에 나올 토큰을 먼저 제안하고 본 모델이 검증하는 방식입니다. 제안한 토큰이 많이 채택되면 한 번에 더 많은 출력을 진행할 수 있습니다. 코드와 자연어에서 제안이 얼마나 잘 맞는지에 따라 속도가 달라졌을 가능성은 있습니다.

하지만 이번 기록에는 제안한 토큰의 채택률이 없습니다. 따라서 코드는 규칙적이어서 더 빨랐다고 원인을 확정할 수 없습니다. 한국어와 코드는 입력 내용과 출력 형태도 다릅니다. 토큰을 나누는 방식이 달라 같은 256토큰이라도 사람이 읽는 분량이 같지 않고, 반복 요청에서 이미 계산한 입력을 재사용했을 가능성도 있습니다.

코드가 빨랐다는 것은 이번 요청에서 관찰한 결과입니다. 이유를 확인하려면 가속 기능을 켜고 끈 상태를 비교하고, 여러 한국어 문장과 코드 문제에서 채택률까지 함께 측정해야 합니다.

이미지 생성은 두 대보다 실행 환경의 차이가 컸습니다

이미지 모델은 Qwen-Image-2.1을 사용했습니다. Qwen 계열의 이미지 생성 및 편집 모델이고, 2.1은 버전입니다. 이번에는 이미지 편집 대신 문장으로 그림을 생성하는 기능을 시험했습니다. 공식 저장소에 모델과 실행 예제가 공개돼 있습니다.

일반 사물 이미지, 한국어 포스터, 투명 배경 로봇을 요청했습니다. 각 요청을 두 번씩 실행해 구성당 6장, 네 가지 구성에서 총 24장을 만들었습니다. 크기는 1024×1024픽셀, 이미지를 다듬는 반복 계산은 40단계, 초기 난수값은 seed 42로 맞췄습니다. 모델을 처음 불러오는 시간과 예열 실행은 생성 시간에서 제외했습니다.

다음 이미지는 SGLang으로 한 대에서 생성한 실제 결과입니다. 빨간 머그잔과 초록 식물, 파란 공책을 요청했습니다.

이미지 모델을 실행하는 방법으로 Diffusers와 SGLang을 비교했습니다. Diffusers는 이미지 생성 모델을 Python 코드에서 실행할 수 있게 해 주는 라이브러리입니다. 두 대를 쓰는 SGLang에서는 시퀀스 병렬화(SP)를 적용했습니다. 한 이미지를 만드는 계산 중 시퀀스에 해당하는 부분을 여러 GPU가 나눠 처리하는 방식이며, 이번에는 두 GPU로 나누는 SP=2 구성을 썼습니다.

SGLang 한 대와 두 대는 약 0.45초 차이였습니다. 이 조건에서는 두 대를 사용해 한 장을 더 빨리 만드는 효과를 확인하지 못했습니다. 각 구성에서 6장만 생성한 결과이므로 두 대가 항상 더 느리다는 뜻도 아닙니다.

오히려 같은 Spark 2에서 실행 환경을 바꿨을 때 차이가 컸습니다. Diffusers의 51.97초에서 SGLang의 36.45초로, 생성 시간이 약 29.9% 줄었습니다. 다만 두 환경은 AI 계산 기반인 PyTorch의 버전도 달랐습니다. 시간 측정에도 차이가 있어 Diffusers는 GPU 계산 완료까지, SGLang은 요청 응답과 PNG 이미지 데이터를 응답으로 내보내기 위한 변환까지 포함했습니다. 따라서 이 차이를 실행 프로그램 하나만의 효과로 분리해서 해석하지는 않았습니다.

두 대를 어떻게 쓸지는 작업을 보고 정해야 합니다

이번 환경에서 Qwen3.8-27B의 응답 완료 시간을 줄이는 데는 두 대의 분산 실행이 도움이 됐습니다. 반면 Qwen-Image-2.1로 1024픽셀 이미지를 만드는 작업은 한 대의 실행 환경부터 비교할 이유가 있었습니다.

두 대를 쓰는 목적도 구분해야 합니다. 한 요청을 빨리 끝내고 싶은지, 여러 요청을 동시에 처리하고 싶은지, 한 대의 메모리에 들어가지 않는 큰 모델을 실행하고 싶은지는 서로 다른 문제입니다. 이번 실험은 첫 번째를 중심으로 일부 동시 요청을 확인했습니다. 두 장비가 이미지를 따로 만드는 방식의 전체 처리량이나 더 큰 모델, 더 높은 이미지 해상도는 측정하지 않았습니다.

저라면 지금의 이미지 설정에서는 두 대가 한 장을 나눠 그리도록 바로 묶기보다, 각 장비가 한 장씩 생성하거나 한 대는 언어 모델, 다른 한 대는 이미지 모델을 맡는 구성을 다음으로 비교하겠습니다. 이는 이번에 성능을 확인한 결과가 아니라, 다음 실험의 선택입니다.

두 대가 연결돼 있는지 확인한 다음에는, 내가 쓰는 프로그램이 실제로 계산을 나누는지와 내가 기다리는 시간이 줄었는지를 확인해야 합니다. 이번 결과에서 얻은 가장 구체적인 판단 기준입니다.

측정 기록과 적용 범위

실험일은 2026년 9월 23일이며, 이 글의 수치와 공식 문서는 2026년 9월 24일에 대조했습니다. 언어 모델 속도 요청은 한 대와 두 대에서 각각 15회씩 총 30회입니다. 단독 요청 세 종류를 각 3회, 한국어와 코드의 동시 요청을 각 3회 실행했습니다. 표는 각 조건의 중앙값이고 속도 증가율은 반올림 전 수치로 계산했습니다.

언어 모델은 SGLang의 Qwen3.8용 개발 버전과 qwen38-dflash2:v1.2.3 실행 환경을 사용했습니다. 반복 횟수가 적고, 단일 장비와 분산 실행의 사전 실행 및 입력 재사용 상태를 완전히 통제하지는 못했습니다. 긴 입력도 실제 긴 회의록이 아닌 반복 문장입니다. 따라서 다른 모델이나 일반 업무 전체의 성능을 대표하는 수치로 확대하지 않습니다.