DGX Spark 한 대와 두 대, Qwen3.8 Flash-Next는 얼마나 달라질까?

DGX Spark 한 대 레시피는 TensorFold의 Zig 엔진으로 Qwen3.8 Flash Next를 서비스해요. 기본 설정은 INT4-AutoRound 체크포인트, FP8⁵ KV cache⁶, 이미지 입력, context 262,144, parallel 8이에요. 두 대 레시피는 rank마다 Spark 한 대를 배정하고 ConnectX-7 링크로 연결해 더 큰 문맥 창과 두 체크포인트 선택지를 제공해요.

이 Spark 수치는 MIA가 공개한 CUDA⁷ recipe별 TensorFold Zig 빌드와 설정에서 나온 값이에요. 일부 MIA 레시피가 TensorFold 0.6.x를 패치해 쓰는 것과 마찬가지로, 이 결과도 기본 TensorFold 1.0.8의 검증표로 옮겨 읽지 않아요. 모델·브랜치·패치가 바뀌면 같은 이름의 GPU⁸에서도 조건이 달라져요.

두 구성 모두 별도 레시피예요. 한 대 측정값을 두 대의 같은 체크포인트·문맥 결과로 읽지 않고, 추가 장비의 효과와 양자화⁹ 차이를 나눠 봐요.

표의 decode¹⁰는 prose 생성 측정이에요. 단일 요청 값과 동시 요청 전체의 합계를 분리했어요. 동시 요청 수가 늘면 합계는 커질 수 있지만 각 요청에 돌아가는 토큰 속도는 낮아지고 첫 토큰 대기시간은 길어져요.

혼자 쓸 때는 1개 요청 열을 비교해요. 공동 서버라면 합산 처리량과 측정 병렬 수도 함께 읽어요. 두 대의 NVFP4와 INT4-AutoRound 행은 서로 다른 체크포인트를 사용하므로 구성 선택에도 그 조건을 남겨두세요.

한 대 구성은 NVIDIA GPU 드라이버가 포함된 DGX Spark, Docker와 NVIDIA Container Toolkit, 약 160GB 여유 디스크가 준비물이에요. README가 제공하는 start.sh가 컨테이너와 체크포인트를 내려받고 기본 설정으로 서버를 준비해요.

git clone https://github.com/MiaAI-Lab/Qwen3.8-Flash-Next-Single-DGX-Spark-TensorFold.git
cd Qwen3.8-Flash-Next-Single-DGX-Spark-TensorFold
./start.sh

저장소의 Quick start에서 현재 브랜치에 고정된 절차를 따라요. 설치가 끝나면 서버가 포트 8888에서 LIVE 상태를 표시하고, API¹¹ base는 head 장비의 주소에 /v1을 붙여요. 모델 ID는 Qwen3.8-Flash-Next예요. curl 요청에 답이 오면 클라이언트 설정에 같은 주소와 모델 이름을 입력해요.

curl -s http://127.0.0.1:8888/v1/models
curl -s http://127.0.0.1:8888/v1/chat/completions -H 'Content-Type: application/json' -d '{"model":"Qwen3.8-Flash-Next","messages":[{"role":"user","content":"Write a Python fibonacci function."}],"max_tokens":1000}'

두 대 recipe는 먼저 아래 명령으로 scripts/local.sh를 만들어요. 다음 설정 블록은 터미널에서 실행하지 않고 파일 편집기로 그 파일의 WORKER·FABRIC_PEER 값을 바꿔 저장하세요. WORKER는 관리망 SSH 대상, FABRIC_PEER는 필요한 경우 worker의 CX7 직결 주소예요. 예시의 192.0.2.x는 실제 주소로 바꿔요. 양쪽에 Docker와 NVIDIA Container Toolkit을 준비하고, head에서 키 기반 SSH를 확인해요. 기본 copy 방식은 양쪽에 체크포인트를 저장하므로 두 장비의 디스크 여유가 필요해요.

git clone https://github.com/MiaAI-Lab/Qwen3.8-Flash-Dual-DGX-Sparks-TensorFold.git
cd Qwen3.8-Flash-Dual-DGX-Sparks-TensorFold
cp scripts/local.sh.example scripts/local.sh

# Replace both reserved documentation addresses with your actual values.
WORKER=user@192.0.2.2       # worker SSH target on the management LAN
FABRIC_PEER=192.0.2.12      # worker CX7 address when needed

grep -nE 'WORKER=|FABRIC_PEER=' scripts/local.sh

ssh-copy-id user@192.0.2.2
ssh -o BatchMode=yes user@192.0.2.2 true

./start.sh

curl -fsS http://127.0.0.1:8888/v1/models
curl -fsS http://127.0.0.1:8888/v1/chat/completions -H 'Content-Type: application/json' -d '{"model":"Qwen3.8-Flash-Next","messages":[{"role":"user","content":"Write a Python fibonacci function."}],"max_tokens":1000}'

두 대 레시피는 최대 1M 문맥, 기본 parallel 16을 제공하지만 이를 실제 요청에서 항상 채울 수 있다는 의미로 읽으면 안 돼요. Spark마다 약 102GiB 여유 메모리가 필요하고, 요청을 늘리면 KV pool을 나눠 써요. 1M 문맥과 16개 동시 요청을 동시에 원하는지, 혹은 짧은 문맥의 한두 요청이 대부분인지에 따라 장비 선택이 달라져요.

prefill¹²은 입력 프롬프트¹³를 읽고 첫 토큰을 준비하는 구간이에요. 한 대는 32K prompt에서 2,630 tok/s였고, 두 대 NVFP4는 같은 길이 근처에서 약 2,575 tok/s, INT4-AR는 약 3,285 tok/s였어요. 첫 토큰 대기시간은 문맥 길이에도 좌우되므로 모델 답변 속도와 따로 살펴요.