DGX Spark(GB10)로 Qwen3.8-Flash-Next 모델 실측 비교

125B MoE 모델을 책상 위 GB10 한 대에 올리는 방법은 여러 가지가 나와 있다. 이 가운데 커뮤니티가 공개한 레시피 다섯 개를 실제 서비스 서버에 하나씩 올려, 한국어 속도와 답변 품질, 며칠 돌렸을 때의 안정성을 같은 기준으로 측정했다.

장비 NVIDIA DGX Spark(GB10, 통합 메모리 128GB) 1대 · 드라이버 580.178.04 · 커널 7.0 · 측정 기간 2026-10-02 ~ 10-11

결론부터

GB10 한 대에는 4비트 안팎의 가중치만 올라간다. 공식 FP8 체크포인트는 172.8GiB라 들어가지 않는다. 같은 4비트라도 엔진과 quantization(양자화) 조합에 따라 결과 차이가 컸다. 같은 3D 코드 과제를 어떤 조합은 두 번 모두 정상으로 만들었고, 어떤 조합은 두 번 모두 실행에 실패했다.

레시피 저자들이 내세운 속도는 대부분 영어로 한 건씩 처리한 조건에서 나온 숫자다. 한국어로 여러 명이 쓰면 숫자가 크게 달라졌고, 한 조합은 설정 하나 때문에 5배 느려졌다. 한국어 속도에는 초안 어휘 목록이라는 숨은 변수도 있었다. 기본 목록에 한국어 토큰이 빠져 있어서, 목록을 고치는 것만으로 한국어 1건 속도가 약 14% 올랐다.

운영 엔진은 가장 빠른 조합이 아니라, 동시 사용자를 많이 받고 부하 시험을 통과한 vLLM 기반 조합으로 정했다.

왜 이 실험을 했나

2026년 8월 24일 공개된 Qwen3.8-Flash-Next가 공개 지표에서 기존 모델들을 크게 앞서자, 이 모델을 한 대에 올리는 커뮤니티 레시피가 며칠 간격으로 쏟아졌다. 저마다 「단일 Spark에서 60~75 tok/s」를 내세웠다(MiaAI-Lab 레시피 62.4·64.4, sxuff 레시피 75.68 tok/s).

다만 그 속도는 조건이 좁다. 영어로 질문하고(여기서 prompt(프롬프트)는 모델에 넣는 질문과 지시다), 답변의 무작위성을 정하는 temperature(온도)를 0으로 두고(0이면 같은 질문에 거의 같은 답이 나온다), 한 번에 request(요청) 한 건만 보낸 결과다. 우리가 알고 싶은 것은 한국어로 묻고, temperature를 0.7로 켜고, 여러 명이 동시에 쓸 때의 속도였다. 그래서 레시피를 하나씩 실제 서비스 서버에 올려 같은 방법으로 측정했다.

측정 방법

이 글의 수치는 모두 우리가 직접 확인한 측정값이다. 저자가 발표한 수치는 출처를 달아 따로 구분했다.

• 한국어 속도: 한국어 문항 5개를 3번씩, 600토큰을 생성해 중앙값을 냈다. temperature는 서비스와 같은 0.7이다(초기 일부 측정은 모델 기본값이며 표에 표시했다).
• 동시 처리: 같은 한국어 문항을 2건, 5건, 8건씩 동시에 보내 건당 속도와 합계를 측정했다.
• 코드 품질: three.js로 국제우주정거장 3D 장면을 만들게 한 과제(사고 강도 최고)와, 사고를 끄고 게임을 만들게 한 과제다. 결과는 브라우저에서 직접 실행해 판정했다.
• tool call(도구 호출): 서비스에서 쓰는 시스템 프롬프트로 날씨를 5번 물어, 도구를 제대로 불러 답하는지 확인했다.
• 언어 혼입: 한국어 답변 80개에 중국어 등 다른 문자가 섞인 횟수를 셌다.
• 실사용 속도: 서비스 기록에서 1,500토큰 이상 답변의 질문 저장부터 답변 저장까지 걸린 시간으로 실효 속도를 계산했다.

메모리의 벽: 왜 4비트뿐인가

GB10은 CPU와 GPU가 128GB를 나눠 쓰는 통합 메모리 구조다. 운영체제 몫을 빼면 엔진이 쓸 수 있는 건 120GB 안팎이다. Flash-Next는 활성 파라미터가 작은 MoE지만, 전문가 가중치 외에 수십 GB짜리 n-gram 임베딩 테이블을 따로 가진다.

모든 4비트 조합이 n-gram 테이블을 디스크에서 읽는다. 그래서 디스크 읽기 방식이 속도에 직접 영향을 준다.

8비트는 올라가지 않고 6비트도 사실상 어렵다. 5비트는 계산상 KV 캐시 자리가 거의 남지 않는다. 4비트 안팎이어야 KV 캐시와 동시 사용자가 쓸 메모리를 확보할 수 있다. GB10 두 대를 묶으면 이 제약이 풀리지만 이번 측정은 한 대 기준이다.

다섯 조합

표기는 조합의 가중치 형식이나 엔진 이름에서 따왔다. MLX판은 MLX 4비트 가중치, NVFP4판은 NVFP4 가중치, vLLM판은 vLLM 엔진, Zig판은 TensorFold Zig 엔진, EXL3판은 EXL3 가중치다. 모두 공개 레시피를 따랐고, 바꾼 건 뒤의 「재현 정보」에 따로 적었다.

속도

MLX판·vLLM판·NVFP4판의 1건 속도는 모델 기본 temperature, Zig판·EXL3판은 temperature 0.7 측정이다. EXL3판은 동시 사용자를 2명까지만 받아 동시 5건 중 3건이 줄을 서서 첫 글자까지 중앙값 11.3초가 걸렸다. vLLM판의 긴 입력 수치는 레시피의 128k 측정값, NVFP4판은 5k~51k 토큰 중앙값, EXL3판은 9.7k~36.7k 토큰 실측(3.7만 토큰에 47초)이다.

저자 발표 수치와 우리 측정

같은 조합인데 저자 수치와 우리 수치가 다른 건 측정 조건이 달라서다. 저자들은 대부분 영어, temperature 0(또는 그에 가까운 설정), 요청 1건으로 측정했다.

저자 도구와 조건으로 다시 측정한 MLX판은 저자 수치와 비슷하게 나왔다. Zig판과 EXL3판은 저자 도구로 다시 측정하지 않았으니, 차이가 난 이유를 저자 수치가 틀려서라고 단정할 수 없다.

숫자만 보면 MLX판이 1건 속도에서, Zig판이 동시 처리에서 앞선다. vLLM판은 1건 속도가 중간이지만 동시 사용자를 16명까지 받아 사람이 몰려도 대기가 짧다. 대신 엔진을 띄우고 남는 메모리가 2.6GB뿐이라 음성 전사 같은 다른 모델을 함께 올릴 수 없다. EXL3판은 남는 메모리가 가장 크지만 동시 사용자가 2명으로 고정돼 있다.

품질: 같은 모델인데 결과가 달랐다

「—」는 그 조합에서 측정하지 않은 항목이다. 시험 횟수가 2~5번뿐이라 경향을 보는 정도로 읽어야 한다.

차이가 가장 컸던 것은 코드다. MLX판은 속도가 가장 빨랐지만 만든 코드가 실행되지 않는 일이 잦아, 코드 과제 5개가 모두 실행에 실패했다. 같은 우주정거장 과제를 vLLM판은 두 번 모두 정상으로 만들었다.

외부 보고서에서도 비슷한 결과가 나왔다. vLLM판 레시피를 만든 My LLM Box가 2026-10-06 공개한 6개 구성 비교에서, TensorFold v0.6.1 + MLX 4비트 조합은 과제 12개가 모두 broken 판정을 받았다. 같은 보고서에서 vLLM판의 hibrid48도 12개 중 3개가 broken이었다. 작성자가 비교 대상 가운데 하나를 만든 사람이라는 점은 감안해야 한다.

일부 문제는 가중치가 아니라 엔진에서 나왔다.

• TensorFold 계열에서만 답변 끝에 「[도구 호출이 중단되었습니다]」 같은 대괄호 문구가 나왔다. 가중치가 달라도(MLX·NVFP4) 같은 엔진이면 나왔고, vLLM에선 나오지 않았다.
• Zig판은 반복 억제 값(presence_penalty)을 받지 않는다. 혼입 시험에서 「用什么」를 끝없이 반복하는 붕괴가 1건 나왔다.

Zig판 체크포인트의 저자는 토큰마다 쓰는 전문가를 5개로 줄였고, 자체 평가에서 점수가 약 10% 내려갔다고 밝혔다. 속도를 얻는 대신 코드 품질을 내준 셈이다.

한국어에서 느려지는 이유: 초안 어휘 목록

Flash-Next 엔진들은 MTP(다음 토큰 여러 개를 미리 추측하는 헤드)로 속도를 높인다. 추측이 맞으면 토큰 여러 개를 한 번에 확정한다. 추측 후보는 전체 어휘 24만 개가 아니라 자주 쓰는 토큰만 모은 목록에서 고르는데, 계산을 줄이려는 것이다. 이 목록을 초안 어휘 목록이라고 부른다.

TensorFold 기본 목록(79,591개)은 영어와 코드 중심이었다. 우리가 쓰던 목록(90,508개)과 비교하니, 기본 목록은 우리 목록에서 한국어 토큰 10,917개를 그대로 뺀 것이었다. 한국어 토큰은 추측 후보에 아예 오르지 못한다는 뜻이다.

목록 밖 비율은 실제 한국어 답변 278개(31.8만 토큰)를 토크나이저로 나눠 측정했다. 영어 속도는 그대로였다.

목록을 더 키워도 속도는 더 오르지 않는다. 남은 수용률 차이(한국어 47~62%, 영어 69~78%)는 MTP 헤드가 한국어를 영어만큼 잘 맞히지 못해서 생긴다. 한국어로 쓸 계획이라면 레시피를 받은 뒤 초안 목록에 한국어가 들어 있는지부터 확인하길 권한다. 엔진에 따라서는 목록을 실행 파일에 넣어 빌드하기도 하는데(Zig 1.0.0), 이때는 목록을 고친 뒤 다시 빌드해야 한다(약 20분).

서비스에 올리고 나서 생긴 문제

벤치마크에서는 보이지 않다가 실제 서비스에 올리자 드러난 문제다.

1. temperature만 주면 5배 느려진다 (EXL3판)

TensorFold 0.6.5 경로는 top_k 없이 temperature를 주면 전체 어휘 24만 개에서 뽑는 느린 경로를 탄다. 한국어 기준 temperature 0.7만 주면 9.9 tok/s, top_k 20을 같이 주면 46.6, temperature 0이면 47.7이었다. 레시피의 기본값이 temperature 0이라 저자 측정에서는 드러나지 않았다. 앞단 중계에서 top_k가 없는 요청에 Qwen 권장값 20을 채워 해결했다.

2. 구조화 출력을 거부하는 엔진 (MLX판·Zig판)

TensorFold v0.6.1은 response_format을 강제하는데 이미지에 xgrammar가 없어 400으로 거부했다. Zig 1.0.0은 구조화 출력 필드 자체를 받지 않는다. 앱이 JSON 출력을 강제하던 기능(의도 분류 등)은 중계에서 필드를 떼고 지시문으로 바꿔 우회했다. 지시문은 강제가 아니라 확률이라, 엔진을 바꿀 때마다 다시 시험해야 했다.

3. 레시피 기본값이 모든 인터페이스에 열린다

두 레시피는 기본 설정이 0.0.0.0에 연결(바인드)하게 되어 있다. 이 엔진들에는 인증이 없어서, 서버가 외부 IP를 가진 환경이면 그대로 인터넷에 공개된다. 받자마자 127.0.0.1로 바꿔야 한다. Docker로 포트를 열면(publish) 호스트 방화벽의 INPUT 규칙으로도 막히지 않는다는 점도 주의해야 한다.

4. 시스템 언어를 한국어로 두면 시작이 멈춘다

두 레시피의 시작 스크립트는 free 명령 출력의 Mem: 줄로 남은 메모리를 확인한다. 시스템 언어가 한국어로 설정돼 있으면(locale, 언어·지역 설정) 이 줄이 「메모리:」로 나와 남은 메모리를 0GB로 읽고 멈춘다. LANG=C를 붙여 실행하면 해결된다.

5. 메모리가 조금씩 줄었다 (vLLM판)

vLLM판은 긴 입력이 들어올 때마다 버퍼가 쌓여 남는 메모리가 7.6GB에서 1시간 반 만에 1.9GB로 줄었다. 레시피 저장소에 올라온 패치(vLLM #57105 백포트)를 적용하자 2.6GB 근처에서 멈췄다. 그 뒤 동시 16건에 길이가 제각각인 긴 입력을 섞어 75분간 부하를 걸었는데 실패는 없었다. 그 전에 간헐 크래시가 한 번 있었는데(두 번째 요청이 합류하는 순간 CUDA 오류, 자동 재시작으로 2분 36초 만에 복구), 부하 시험에서는 재현되지 않았다. 원인은 아직 모른다.

6. 재부팅하면 안 뜬다

EXL3판 레시피는 감시 프로세스가 컨테이너를 일회성으로 띄우는 구조라, 서버를 재부팅하면 엔진이 자동으로 올라오지 않는다. 운영에 쓰려면 레시피의 user systemd 설치와 linger 설정이 따로 필요하다.

7. 앱이 모델의 판단에 맡기던 분기

엔진을 바꿀 때마다 앱 쪽에서도 다른 문제가 났다. 표 파일을 첨부하고 「판매 데이터 분석해줘」라고 하면, 같은 문장이 엔진에 따라 정상 분석, 「지원하지 않는 분석」, 일반 대화로 나뉘었다. 일반 대화로 빠진 경우에는 엉뚱한 웹검색까지 했다. 「이 요청이 계산 요청인가」를 LLM에게 묻고 있었기 때문이다. 이렇게 모델의 판단에 맡긴 분기는 규칙으로 고정해야 모델을 바꿔도 같은 결과가 나온다.

실사용 체감 속도

벤치마크가 아니라 서비스 사용 기록으로 계산했다. 1,500토큰 이상 답변의 질문 저장부터 답변 저장까지 걸린 시간으로 실효 속도(사고·입력 읽기 포함)를 구했다.

중앙값은 답변을 속도순으로 세웠을 때 가운데 값이다. p90은 답변의 90%가 이 속도 이하라는 뜻이라, 가장 빠른 10%는 이 값보다 빠르다. 답변 수가 적은 구간은 경향으로만 본다.

사용자가 「예전엔 70~80이 나왔다」고 기억하는 속도는 MLX판 시절의 것이다. 체감 속도는 MLX판이 가장 좋았지만 코드 품질 문제 때문에 오래 쓰지 못했다.

최종 선택: vLLM판으로 고정

열흘 동안 운영 엔진을 여덟 번 바꿨고, 마지막에 vLLM판으로 고정했다. 새 레시피가 나올 때마다 실제 서비스 서버에 올려 측정했고, 엔진을 바꿀 때마다 앞에서 본 문제 가운데 하나가 서비스에서 터졌다. Flash-Next는 보드 메모리를 혼자 차지해서 시험용 엔진과 서비스용 엔진을 한 대에 같이 올릴 수 없다. 장비가 한 대뿐이라 시험하는 서버가 곧 서비스하는 서버였다.

vLLM판으로 고정한 이유는 세 가지다.

1. 품질: 코드 과제 2번이 모두 정상이었고, 답변 끝에 대괄호 문구가 붙는 것 같은 엔진 쪽 이상이 없었다.
2. 동시성: 동시 사용자를 16명까지 받아 동시 10건에서도 합계 148 tok/s가 나왔다. 2명이나 5명까지 받는 조합은 사람이 몰리면 첫 글자가 나오기까지 수십 초를 기다려야 했다.
3. 안정성: 메모리 패치 뒤 75분 부하 시험에서 실패가 없었다. 표준 vLLM 위에서 돌아 OpenAI 호환 기능(도구 호출, 구조화 출력, 반복 억제)이 별도 중계 없이 동작한다.

대신 1건 속도는 MLX판보다 22% 느리고, 남는 메모리가 2.6GB라 다른 모델을 같이 올릴 수 없다. 엔진 시험은 앞으로 사용자가 적은 시간에만 하고, 끝나면 되돌린다.

이 측정으로 알 수 없는 것

• 원본 정밀도 기준선이 없다. 같은 문항을 양자화하지 않은 원본 정밀도로는 실행하지 않았다. 그래서 품질 차이가 4비트 양자화 때문인지 엔진 구현 때문인지 가를 수 없다. 조합에 따라 결과가 달랐다는 데까지만 확인했다.
• 시험 횟수가 적다. 코드 과제는 조합마다 2번, 도구 호출은 5번이다. 경향을 보는 정도로 읽어야 한다.
• 측정 조건이 완전히 같지 않다. 초기 측정(MLX판·NVFP4판·vLLM판의 1건 속도)은 모델 기본 temperature, 이후 측정은 temperature 0.7이다.
• 장비 한 대, 한 시점의 결과다. 엔진과 레시피가 며칠 단위로 바뀌고 있어 이 글의 숫자는 2026년 10월 초 버전 기준이다.
• 저자 수치와 다르다고 저자가 틀렸다는 뜻은 아니다. 저자 도구와 조건으로 다시 측정한 MLX판은 저자 수치와 비슷했고, 나머지 조합은 우리 조건으로만 측정했다. 조건이 다르면 숫자가 달라진다는 기록이다.

재현 정보

모든 레시피와 엔진은 공개 저장소에서 받을 수 있고, 모델 가중치는 Qwen 라이선스를 따른다.