모델별 실행 레시피

Qwen3.8-Flash-Next 서빙 가이드: 180B MoE 로컬 레시피

6B 활성 연산과 180B 상주 가중치, 서버급 분산 가속기 및 PLE 오프로드 서빙 설정

쉽게 말하면

Qwen3.8-Flash-Next는 토큰마다 약 6B가 활성화되지만 코어 LM, 51B PLE n-gram 테이블, MTP 모듈을 합친 약 180B 규모의 가중치를 적재해야 합니다. 이 글은 서버급 멀티 GPU 환경과 외장 GPU 호스트 RAM을 활용한 PLE 테이블 오프로드 서빙 경로를 다룹니다.

장비를 고를 때

180B 상주 가중치는 단일 24GB·32GB GPU에 들어가지 않습니다. 외장 GPU 시스템에서는 51B PLE 테이블을 호스트 RAM으로 내리는 방식을 활용할 수 있으나, 잔여 코어 가중치가 VRAM에 들어가야 합니다. 128GB 통합 메모리에서의 압축본 실행은 별도 변환본이 필요합니다.

이 글에서 확인할 내용

  • 125B 코어 LM(6B 활성)과 51B PLE n-gram, 4B MTP로 약 180B 상주 메모리가 요구됩니다.
  • 외장 GPU 환경에서는 SGLang(--ple-offload-embedding) 및 vLLM(VLLM_PLE_CPU_OFFLOAD=1)으로 PLE 테이블 RAM 오프로드를 지원합니다(SSD 페이징 미적용).
  • 단일 소비자 GPU가 아닌 서버급 멀티 가속기 환경과 127.0.0.1 바인딩을 권장합니다.

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

단일 사용자 지연시간 최소화 기준의 안전 시작 문맥, 권장 런타임, GPU 오프로드 및 예상 속도 요약입니다.

하드웨어적합도권장 런타임안전 문맥토큰 생성첫 토큰
MBP M5 Pro 48GB (41GB)메모리 초과 (미지원)적재 불가4,096 토큰--
Studio M5 Ultra 256GB (236GB)메모리 적정LM Studio16,384 토큰41.8 ~ 72.5 tok/s10.4 ~ 18.0초
Studio M5 Ultra 512GB (480GB)메모리 적정LM Studio16,384 토큰41.8 ~ 72.5 tok/s10.4 ~ 18.0초
RTX 4090 24GB (22.5GB)메모리 초과 (미지원)적재 불가4,096 토큰--
2× RTX 3090 48GB (NVLink) (45GB)메모리 초과 (미지원)적재 불가4,096 토큰--
RTX PRO 6000 96GB (93GB)메모리 초과 (미지원)적재 불가4,096 토큰--
DGX Spark 128GB (116GB)메모리 적정llama.cpp (CUDA)8,192 토큰16.7 ~ 23.4 tok/s7.0 ~ 9.4초
Ryzen AI Max+ 395 128GB (116GB)메모리 적정llama.cpp (ROCm/HIP)8,192 토큰15.2 ~ 21.4 tok/s67.2 ~ 157.6초

상세 튜닝 설정은 위 섹션에서 확인할 수 있습니다. 복사할 실행 명령은 아티팩트와 런타임 경로가 확인된 조합에만 표시합니다.

아티팩트 및 런타임 선택

Qwen3.8-Flash-Next는 125B 코어 LM(토큰당 6B 활성)에 51B n-gram/PLE 임베딩 테이블과 4B MTP 모듈이 결합된 약 180B 상주 MoE 아키텍처입니다. 압축본은 포맷과 구현 방식에 따라 크기가 달라지므로 파일 크기와 런타임 지원을 함께 확인해야 합니다.

공식 가중치(Qwen/Qwen3.8-Flash-Next)는 vLLM 또는 SGLang을 사용하는 멀티 GPU 서버 경로로 설명합니다. Mac 통합 메모리에서의 실행은 호환되는 커뮤니티 변환본이 별도로 필요하며, CPU/GPU가 단일 메모리를 공유하므로 분할 오프로드가 적용되지 않습니다.

Qwen3.8-Flash-Next의 125B 코어 LM, 51B n-gram 테이블, 4B MTP를 포함한 180B 상주 가중치 구조도
활성 파라미터는 6B이지만 상주 가중치는 약 180B에 달하므로 서버급 고속 메모리 환경이 필요합니다.

로컬 서버 구동 및 PLE RAM 오프로드 (vLLM / SGLang)

서버급 로컬 노드에서 vLLM 또는 SGLang을 구동할 때는 장착된 물리 가속기 수에 맞춰 텐서 병렬(--tensor-parallel-size) 값을 지정합니다. 초기 컨텍스트 길이는 보수적인 16K(16,384 토큰)로 설정하여 KV 캐시 안정성을 먼저 확보합니다.

외장 NVIDIA GPU 환경에서 VRAM이 부족한 경우, 51B PLE 임베딩 테이블을 호스트 시스템 RAM으로 오프로드할 수 있습니다. SGLang의 --ple-offload-embedding 플래그나 vLLM의 VLLM_PLE_CPU_OFFLOAD=1 환경변수를 사용할 수 있으나, 정확한 동작 여부는 런타임 버전 및 체크포인트 포맷에 따라 달라집니다.

주의: NVMe SSD 직접 페이징 방식은 커뮤니티 실험 및 패치 단계로 성능과 안정성이 불확실하므로 공식 권장 구성에서 제외되며 본 사이트의 성능 모델에서도 OOM을 해소하는 경로로 취급하지 않습니다.

모든 서빙 데몬은 127.0.0.1 로컬 바인딩을 유지합니다. 외부 노출이 필요한 경우 사내망 방화벽과 역방향 프록시를 통해 인증을 거치도록 구성하세요.

vLLM 분산 텐서 병렬 + PLE RAM 오프로드 서빙 예시

GPU_COUNT=8 # 실제 물리 GPU 수로 수정
VLLM_PLE_CPU_OFFLOAD=1 vllm serve Qwen/Qwen3.8-Flash-Next   --tensor-parallel-size "$GPU_COUNT"   --host 127.0.0.1   --port 8000   --max-model-len 16384   --gpu-memory-utilization 0.90

VLLM_PLE_CPU_OFFLOAD=1로 51B 임베딩 테이블을 호스트 RAM에 적재합니다.

SGLang 분산 서빙 + PLE 임베딩 오프로드 실행 예시

GPU_COUNT=8 # 실제 물리 GPU 수로 수정
python -m sglang.launch_server   --model-path Qwen/Qwen3.8-Flash-Next   --tp "$GPU_COUNT"   --ple-offload-embedding   --host 127.0.0.1   --port 8000   --context-length 16384

SGLang에서 --ple-offload-embedding 옵션을 활성화해 VRAM 부담을 경감합니다.

vLLM 및 SGLang 런타임 기반 Qwen3.8-Flash-Next 서버 구동 파이프라인과 텐서 병렬 설정 구조도
단일 소비자 GPU가 아닌 멀티 가속기 분산 환경에서 공식 모델 ID와 보수적 컨텍스트로 서빙을 시작합니다.

엔드포인트 검증 및 MoE 라우팅 테스트

로컬 서버가 시작되면 curl로 127.0.0.1:8000 엔드포인트가 정상 응답하는지 확인합니다. 활성 파라미터 수만으로 실제 품질이나 속도를 단정하지 않고, 같은 프롬프트로 첫 토큰 시간과 디코드 처리량을 기록합니다.

PLE 오프로드, QSA, MTP 경로의 적용 여부는 런타임 시작 로그와 메모리 할당 상태에서 확인합니다. 모델에 해당 구조가 포함돼 있어도 선택한 런타임 버전에서 지원되지 않으면 실패할 수 있습니다.

로컬 REST API 응답 검증

curl http://127.0.0.1:8000/v1/chat/completions   -H "Content-Type: application/json"   -d '{
    "model": "Qwen/Qwen3.8-Flash-Next",
    "messages": [
      {"role": "user", "content": "Flash-Next 아키텍처의 특징을 설명해줘."}
    ],
    "max_tokens": 512
  }'

127.0.0.1:8000 엔드포인트로 스트리밍 챗 완료 응답을 확인합니다.

Qwen3.8-Flash-Next의 127.0.0.1 API 엔드포인트 응답 검증 및 MoE 라우팅 처리량 모니터링 다이어그램
로컬 API 호출로 기본 응답을 검증하고 전문가 라우팅 및 n-gram 테이블의 메모리 상주 상태를 점검합니다.

메모리 점검 및 분산 트러블슈팅

180B 가중치가 분산 가속기 및 시스템 RAM에 의도대로 적재되었는지 nvidia-smi 또는 시스템 모니터로 확인합니다. 특정 가속기에 VRAM이 몰려 OOM이 발생할 경우 텐서 병렬 옵션과 오프로드 플래그를 점검하세요.

노드 간 인터커넥트 대역폭(PCIe/NVLink)이 충분하지 않거나 RAM 대역폭 병목이 생기면 토큰 생성 속도가 저하될 수 있으므로 분산 통신 상태를 지속적으로 모니터링해야 합니다.