사기 전에 속도와 비용부터

모델별 실행 레시피

Qwen3.8 Flash-Next DGX Spark 설정: SGLang·PLE·MTP 레시피

단일 DGX Spark에서 Qwen3.8 Flash-Next를 실행하려면 전용 압축본, PLE SSD 패치와 MTP 백엔드를 한 묶음으로 맞춰야 합니다. 먼저 32K 문맥에서 적재와 답변 종료를 확인하고, 그 다음 긴 문맥과 MTP 단계를 따로 검증하세요. 여러 설정을 한꺼번에 바꾸면 어느 옵션이 속도나 오류를 만들었는지 알기 어렵습니다.

실행 레시피

장비별 설정

한 사람이 사용할 때

사용할 장비를 고르면 실행 명령과 조정할 옵션이 나옵니다.

가용 메모리: 114GB / 대역폭: 546GB/s

운용 프로필

Apple Mac Studio M4 Max (128GB)

메모리 적정

권장 런타임: oMLX (MLX 4비트 (GGUF Q4_K_M과 별도 형식)) · 문서화된 런타임 설정

설치 직후 처음 실행하거나 매일 안정적으로 사용할 때

선택 프로필 문맥

8,192 토큰

런타임 문서 기반Studio M4 Max 128GB · Q4 · 요청 1개

런타임 문서에 따른 시작 설정입니다. 아래 순서로 조정하며 속도를 비교하세요.

계산기 예상 디코드

24.7 ~ 48.2 tok/s

단일 사용자 예상치

계산기 예상 TTFT

8.8 ~ 17.1초

프리필: 479 ~ 936 tok/s

예상 메모리 점유

107.85GB / 114GB

남은 여유: 약 6.2GB

서버 주소

http://127.0.0.1:8000

로컬 전용 127.0.0.1

예상치는 계산기의 추천 양자화·가속과 8,192토큰 기준입니다. 위 실행 설정의 실측값은 아닙니다.

이 프로필의 실제 설정

적용값왜 이렇게 잡았나
가중치MLX 4비트 (GGUF Q4_K_M과 별도 형식)MLX 모델 디렉터리를 사용합니다. GGUF의 Q4_K_M과 같은 파일 형식이 아닙니다.
입력 길이 확인8,192요청 전 모델 설정의 입력 제한을 확인합니다. 이 실행 명령은 문맥 길이를 지정하지 않습니다.
KV 캐시모델 설정에서 확인이 실행 명령은 KV 캐시 정밀도를 지정하지 않습니다.
프리필 배치런타임 설정에서 확인llama.cpp의 batch-size와 ubatch-size를 MLX 설정값으로 대신 쓰지 않습니다.
동시 요청1한 요청의 속도를 확인합니다. 여러 요청의 합산 처리량과 구분합니다.
메모리 여유2GB 이상모델을 불러온 뒤 실제 메모리와 스왑 여부를 확인합니다.

Studio M4 Max 128GB 실행 명령어 (oMLX)

Apple Silicon · MLX 모델 · 메모리 가드
MODEL_DIR="$HOME/.omlx/models"
omlx serve \
  --model-dir "$MODEL_DIR" \
  --host 127.0.0.1 \
  --port 8000 \
  --max-concurrent-requests 1 \
  --memory-guard balanced
먼저 이 설정으로 기준 속도를 기록한 뒤 아래 튜닝 순서를 따라 한 항목씩 바꿉니다.

실행 후 확인

  1. 01서버 시작 로그에서 모델 적재 완료와 실제 컨텍스트 길이를 확인합니다.
  2. 02준비 실행 뒤 요청은 하나씩 보냅니다. 길이가 같은 서로 다른 입력 세 개로 첫 입력 처리 시간을 기록합니다.
  3. 03같은 입력을 반복한 결과는 캐시 재사용으로 따로 기록합니다. 첫 입력 결과와 합치지 않습니다.
  4. 04프리필 tok/s, 디코드 tok/s, 피크 메모리를 함께 기록한 뒤 한 항목씩만 바꿉니다.

바뀌는 점

  • 문맥과 동시 요청을 보수적으로 잡아 장비의 최대 처리량보다 낮게 나올 수 있습니다.

운용 시 유의사항

  • 내장 n-gram 테이블까지 상주하므로 표시된 총 적재 메모리를 기준으로 문맥을 잡아야 합니다.

한 항목씩 조정

속도를 올리는 순서

여러 값을 한꺼번에 바꾸면 원인을 찾기 어렵습니다.

  1. STEP 1

    기준값 저장

    첫 입력과 캐시 재사용을 구분하고 각각 세 번 기록합니다. 프리필·디코드·피크 메모리를 함께 비교합니다.

    멈출 때: 오류가 있거나 메모리 여유가 2GB보다 작으면 다음 단계로 넘어가지 않습니다.

  2. STEP 2

    프리필 청크 조정

    1,024 → 2,048 → 4,096 순서로 올리며 긴 입력의 TTFT와 피크 메모리를 비교합니다.

    멈출 때: TTFT가 줄지 않거나 메모리 정점이 급증하면 직전 값으로 돌아갑니다.

  3. STEP 3

    KV 캐시 조정

    문맥이 부족할 때만 F16/BF16 기준값과 Q8 캐시를 같은 질문으로 비교합니다.

    멈출 때: 출력 차이가 생기거나 필요한 문맥이 이미 확보됐다면 기본 정밀도를 유지합니다.

  4. STEP 4

    MTP·투기 디코딩

    지원 모델에서만 켠 뒤 코드와 일반 문장을 나눠 수락률과 실제 디코드 tok/s를 측정합니다.

    멈출 때: 세 번의 중앙값이 기준보다 좋아지지 않으면 끕니다.

  5. STEP 5

    문맥 확장

    실제로 필요한 길이까지 두 배씩 늘리고 중간 정보 검색과 스왑 여부를 확인합니다.

    멈출 때: 검색 정확도가 떨어지거나 스왑·메모리 압축이 시작되면 한 단계 줄입니다.

내 장비 측정 기록 보내기

같은 조건으로 3회 이상 측정한 JSON을 가져오세요. 전송 버튼을 누르기 전에는 이 브라우저에서만 확인합니다.

장비·모델·실행 조건과 측정값만 받습니다. 질문·답변·원본 로그·파일 경로는 넣지 마세요.

기록 파일이 없다면, 실행 중인 로컬 서버에서 측정 도구로 만들 수 있습니다. Node.js 20 이상이 필요하며 결과를 자동 전송하지 않습니다.

검토한 이용자 제출 기록입니다. 이 사이트의 직접 측정과는 구분합니다.

설정 오류 제보

선택한 설정에서 막힌 부분을 알려주세요. 제보는 관리자만 확인합니다.

전송할 설정 · Studio M4 Max 128GB · Qwen3.8-Flash-Next · 균형 설정

같은 모델 이름만으로는 같은 구성이 아닙니다

이 경로는 Qwen3.8-Flash-Next의 특정 NVFP4 체크포인트를 사용합니다. 모든 텐서가 일괄 4비트라는 뜻은 아닙니다. 어텐션과 MTP 등 더 높은 정밀도로 유지하는 부분이 있어 전체 파일과 실제 적재를 확인해야 합니다.

단일 Spark의 통합 메모리 안에서 가중치를 CPU 쪽으로 옮기는 것만으로 물리 공간이 늘지는 않습니다. 큰 PLE 테이블을 NVMe 파일에 두고 필요한 부분을 조회하는 전용 mmap 패치가 핵심입니다. 기본 SGLang에 플래그만 추가한 경로와 구분하세요.

실험 파일과 스크립트는 버전과 내용을 검토하고 정상 환경과 분리해 준비합니다. 다운로드·변환용 임시 공간도 필요합니다. 아래 실행 묶음의 약 140GB 이상 여유 안내를 참고하되 현재 배포 파일에 필요한 총공간을 다시 확인하세요.

같은 모델 이름만으로는 같은 구성이 아닙니다
같은 모델 이름만으로는 같은 구성이 아닙니다

32K 기록을 재현하는 출발점

현재 공개 스크립트는 TP 1, 메모리 비율 0.85와 프리필 청크 2,048에서 시작합니다. 프리필은 Triton, 디코드는 trtllm_mha를 사용하고, MTP는 NEXTN 3단계·top-k 1·draft token 4개입니다. 이 기본값을 공개 측정 당시의 모든 조건이 확인됐다는 뜻으로 읽지는 마세요.

공개 기록의 디코드는 영어 코드 약 41.5 tok/s, 스페인어 일반 문장 약 22.8 tok/s로 나뉩니다. 한국어 답변에도 같은 속도가 나온다는 뜻은 아닙니다. 이전에 소개한 프리필 1,910 tok/s는 비교 기준에서 뺐습니다. 원문이 입력 캐시 재사용에 따른 측정 오염을 알렸고, 캐시를 비운 반복 측정은 아직 끝나지 않았기 때문입니다. 이 수치를 새 문서의 입력 처리 속도로 사용하면 안 됩니다.

준비 스크립트와 검증을 통과한 뒤 실제 요청은 한 개씩 보내 기준을 남깁니다. 서버의 최대 요청 허용값과 측정 중 동시에 보낸 요청 수는 다릅니다. Docker 바깥의 포트가 127.0.0.1에만 게시됐는지도 확인하세요.

단일 DGX Spark 32K 실행
git clone https://github.com/hashd1ve/qwen38-flash-next-one-dgx-spark.git
cd qwen38-flash-next-one-dgx-spark

./scripts/download.sh
./scripts/prepare.sh
sed -i.bak 's/-p "$PORT":30000/-p "127.0.0.1:$PORT:30000"/' scripts/serve.sh
MEMFRAC=0.85 PREFILL=2048 CTX=32768 ./scripts/serve.sh
python3 verify.py
Docker와 약 140GB 이상의 NVMe 여유 공간이 필요합니다.
공개 스크립트의 핵심 SGLang 옵션
# Docker 포트는 127.0.0.1:30000에만 게시
--tp-size 1
--prefill-attention-backend triton
--decode-attention-backend trtllm_mha
--quantization modelopt_fp4
--ple-offload-embedding
--mamba-radix-cache-strategy extra_buffer
--mem-fraction-static 0.85
--chunked-prefill-size 2048
--max-running-requests 4
--speculative-algorithm NEXTN
--speculative-num-steps 3
--speculative-eagle-topk 1
--speculative-num-draft-tokens 4
--speculative-draft-model-quantization unquant
PLE mmap 패치가 없는 stock SGLang에 이 플래그만 복사하면 같은 메모리 배치가 되지 않습니다.

문맥 숫자 하나만 키우지 않습니다

긴 문맥에서는 메모리 비율 0.79, 프리필 청크 1,024를 여유 공간을 남기는 시작값으로 사용합니다. 공개된 긴 문맥 측정은 메모리 비율 0.85와 요청 한 개 조건이므로, 아래 명령은 그 측정의 정확한 재현 명령이 아닙니다. 문맥을 262,144로 설정할 수 있다는 사실만으로 내 문서가 안정적으로 처리된다고 보장되지는 않습니다.

먼저 작은 입력에서 정상 동작을 확인한 뒤 8K·32K·128K처럼 단계적으로 늘립니다. 각 길이에서 정답을 아는 문장을 중간에도 넣어 실제로 찾는지 확인하세요. 다른 GPU 작업을 줄이고 요청 한 개 조건으로 메모리와 첫 토큰 시간을 함께 봅니다.

청크를 줄여 메모리 정점을 낮추면 짧은 입력의 처리량은 낮아질 수 있습니다. 긴 문맥이 필요하지 않다면 가장 큰 설정을 유지할 이유는 없습니다. 평소 길이의 결과로 돌아와 어느 프로필을 남길지 결정하세요.

단일 DGX Spark 262K 실행
# 앞의 다운로드·준비 및 로컬 포트 설정을 마친 뒤 실행
# 서버 주소: http://127.0.0.1:30000
cd qwen38-flash-next-one-dgx-spark
sed -i.bak 's/--max-running-requests 4/--max-running-requests 1/' scripts/serve.sh
MEMFRAC=0.79 PREFILL=1024 CTX=262144 ./scripts/serve.sh
python3 verify.py
프리필 청크를 줄이는 대신 짧은 입력의 처리량은 낮아질 수 있습니다.
문맥 숫자 하나만 키우지 않습니다
문맥 숫자 하나만 키우지 않습니다

남의 숫자보다 느릴 때 확인할 순서

체크포인트와 패치·컨테이너 버전을 먼저 확인하고 PLE 파일이 실제 NVMe 경로에 있는지 봅니다. 그다음 로그에서 프리필·디코드 백엔드와 MTP 가중치의 정밀도가 의도대로 선택됐는지 확인합니다. 후보 단계부터 무작정 늘리지 마세요.

첫 디스크 접근과 페이지 캐시가 남은 반복 접근도 구분해야 합니다. 준비 직후의 숫자와 평소 여러 앱을 켜둔 상태의 숫자는 다를 수 있습니다. MTP를 끈 값과 켠 값을 코드·일반 문장 각각 같은 조건으로 기록합니다.

실행이 자주 실패하면 속도보다 안정적인 기준을 먼저 복구합니다. 포트가 외부에 열려 있다면 접근 범위를 제한하고, 공유 서버로 바꿀 때는 별도의 인증과 방화벽을 준비해야 합니다.

이 레시피로 얻고 싶은 결과

특수 패치로 큰 모델을 한 대에 올리는 것은 의미 있는 실험입니다. 하지만 설정을 재현했다는 성취와 매일 편하게 쓸 도구를 얻었다는 결과는 다를 수 있습니다. 필요한 문서와 코드를 실제로 끝까지 처리해보세요.

이미 한 대의 안정적인 설정에서 원하는 일이 된다면 두 대를 살 이유는 줄어듭니다. 더 긴 문맥이나 여러 요청이 꼭 필요하다면 그 조건으로 두 대와 비교합니다. 기록의 최고 속도보다 내 환경에서 반복되는 결과를 구매 판단에 사용하세요.

이 레시피로 얻고 싶은 결과
이 레시피로 얻고 싶은 결과

NVFP4로 실행하려면

PLE 적재 방식에 따라 파일 크기가 달라집니다. Spark 단일 노드는 전용 패치 경로를 확인하세요.

vLLM / SGLang · nvidia/Qwen3.8-Flash-Next-NVFP4

수정 내역

사이트의 안내가 바뀐 기록입니다. 설치된 엔진·모델 버전을 자동으로 확인한 결과는 아닙니다.

  1. Flash-Next 본문과 실행 프로필의 설정값 통일

    본문의 프리필 청크를 공개 스크립트와 같은 2,048로 고치고 긴 문맥 명령에도 요청 상한 1개를 반영했습니다. 공개 측정의 언어 조건과 안전한 시작값을 구분했습니다.

  2. Flash-Next 단일 Spark의 프리필 수치 정정

    캐시 재사용이 섞인 1,910 tok/s를 첫 입력의 프리필 속도로 제시하던 문구를 제거했습니다. 캐시를 쓰지 않은 조건의 재측정이 필요한 상태로 바꿨습니다.

  3. Flash-Next 긴 문맥의 요청 상한 조정

    단일 Spark의 262K 문맥 명령에서 실행 요청 상한을 4개에서 1개로 낮췄습니다. 오래된 QSA 패치의 출력 오류를 확인하도록 검증 순서도 보완했습니다.

  4. Mac의 모델 형식과 실행 설정 정정

    Mac의 MLX 실행 경로를 GGUF Q4_K_M과 구분하고, 엔진 이름·모델 형식·명령의 표기를 맞췄습니다. 명령에서 지정하지 않는 KV 캐시 정밀도와 프리필 배치는 모델·런타임 설정에서 확인하도록 바꿨습니다.

    명령이 그대로인데 배치만 커진 것처럼 보이던 MLX 속도 프로필도 제거했습니다.

  5. 첫 입력과 캐시 재사용의 기록 분리

    검증 순서에서 처음 읽는 입력과 같은 입력을 반복한 결과를 따로 기록하도록 바꿨습니다. 캐시 효과를 프리필 처리량이나 장비 차이로 합산하지 않습니다.

  6. 장비·프로필 저장과 다시 열기 추가

    실행 가능한 프로필은 장비와 함께 이 브라우저에 최대 5개까지 저장하고, 가이드 목록에서 다시 열 수 있게 했습니다. 저장한 뒤 공개 설정이 바뀌거나 프로필이 없어지면 실행 전에 다시 확인하도록 안내합니다.

  7. 실행 엔진 설명으로 이어지는 링크 추가

    설정에 표시된 엔진 이름에서 해당 실행 프로그램의 설명으로 이어지도록 했습니다. 엔진이 확인되지 않은 경로에는 임의의 프로그램을 연결하지 않습니다.