Qwen3.8-Flash-Next 최적 설정: 단일 DGX Spark SGLang 레시피

하드웨어별 속도 튜닝 및 서빙 레시피 요약

가중치, KV 캐시, 프리필 배치, 동시 요청과 가속 기능을 분리하고 균형·속도·긴 문맥 프로필로 제공합니다.

상세 페이지에서 프로필별 실행 명령, 적용값, 멈춰야 할 조건과 측정 순서를 확인할 수 있습니다. 실행 명령은 모델 파일과 실행 프로그램가 확인된 조합에만 표시합니다.

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

이 경로는 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에만 게시됐는지도 확인하세요.

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 포트는 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

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

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

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

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

# 앞의 다운로드·준비 및 로컬 포트 설정을 마친 뒤 실행
# 서버 주소: 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를 끈 값과 켠 값을 코드·일반 문장 각각 같은 조건으로 기록합니다.

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

이 레시피로 얻고 싶은 결과

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

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