Qwen3.6‑35B NVFP4, 한 대 H100으로 충분…A

출처: Dev.to


NVIDIA는 2026년 5월 28일에 nvidia/Qwen3.6-35B-A3B-NVFP4를 발표했다 — 알리바바의 350억 파라미터 MoE 모델에 post‑training FP4 양자화를 적용해 H100 한 대에서 약 71 GB의 VRAM을 ~23 GB로 줄여 단일 GPU에 맞는 변형이다. A100 또는 소비자용 GPU를 사용 중이라면 먼저 ‘주의 사항’ 섹션으로 이동하라 — 이 양자화 포맷은 해당 하드웨어에서는 실행되지 않는다.

71 GB → 23 GB: 양자화되는 내용과 그렇지 않은 내용

NVFP4 양자화는 트랜스포머와 MoE 블록 내 선형 연산자들의 가중치와 활성화에만 집중한다 — LayerNorms(레이어 노멀), 임베딩, 편향은 수치적 안정성을 위해 BF16/F32를 유지한다. 선택적 4비트 압축은 베이스 BF16 대비 디스크 사용량과 VRAM을 3.06× 감소시켜 Hopper 하드웨어에서 약 71 GB에서 ~23 GB로 낮춘다.

간단 답변: nvidia/ Qwen3.6-35B-A3B-NVFP4는 선형 연산자 가중치와 활성화에 4비트 양자화를 적용해 H100 한 대에서 35B MoE 추론 모델을 실행한다. VRAM을 ~71 GB → ~23 GB (3.06×) 로 줄이며 표준 벤치마크에서 정확도 손실이 1점 미만이다. Hopper 또는 Blackwell이 필요 — A100과 RTX 4090은 FP4 연산 경로가 전혀 없다.

캘리브레이션 파이프라인은 두 데이터셋을 사용했다: cnn_dailymail(300K+ 영어 뉴스 기사) 과 NVIDIA의 Nemotron-Post-Training-Dataset-v2 (다중 턴 대화 커버를 위한)로, NVIDIA Model Optimizer v0.44.0 로 처리했다. 두 데이터셋을 동시에 사용한다는 점은 주목할 만하다: 뉴스 기사만으로 캘리브레이션한 양자화는 구조적인 멀티턴 인스트럭션‑프로잉에 재현성 저하가 발생할 가능성이 있다 — 이 결과는 벤치마크에서 나타난다.

NVIDIA 공식 평가 스위트는 정확도 격차가 좁다는 것을 보여준다. NVFP4는 추론 벤치마크 전반에서 BF16 대비 0.5~0.8 포인트 이내에 유지하며, 인스트럭션‑프로잉 및 멀티모달 작업에서는 약간 우수하다 :

NVFP4 양자화된 모델은 BF16 원본과 거의 동일한 정확도를 유지하면서 메모리 요구량을 3.06× 감소시켜, 다중 GPU 텐서 병렬화가 필요했던 하드웨어에서도 배포가 가능하다.” — NVIDIA 모델 최적화 팀, nvidia/ Qwen3.6-35B-A3B-NVFP4 모델 카드

Hopper 또는 Blackwell: 다른 카드가 작동하지 않는 이유

FP4 텐서 코어 실행 경로는 Hopper(H100, H200) 및 Blackwell(GB200, GB300, DGX Spark GB10) 아키텍처에만 존재한다. RTX 4090(Ada Lovelace, sm_89), RTX 5090, A100(Ampere, sm_80)는 네이티브 FP4 연산 유닛이 없다. 해당 카드에서 --quantization modelopt 를 전달하면 로드 시 오류가 발생하거나, 더 나아가 잘못된 출력이 조용히 출력된다.

비 Hopper/Blackwell 하드웨어에서의 백업 옵션:

BF16 베이스 모델: 약 71 GB의 VRAM이 필요 — RTX PRO 6000(96 GB) 또는 H100/A100 80 GB

커뮤니티 GGUF 양자화: llama.cpp를 통해 소비자 하드웨어에서 실행한다. unsloth/ Qwen3.6-35B-A3B-NVFP4 와 [AEON-7/ Qwen3.6-35B-A3B-heretic-NVFP4]는 다양한 양자화 트레이드‑오프와 더 넓은 하드웨어 커버리지를 제공한다

DGX Spark(Blackwell, sm_120/ 121a)는 공식적으로 지원되지만 CUDA 13.0과 vllm/vllm-openai:cu130-nightly Docker 이미지가 추가로 필요하다. 현재 안정적인 vLLM 릴리스에는 해당 아키텍처용 FlashInfer CUTLASS MoE 커널이 아직 포함되지 않는다. serve를 시도하기 전 vLLM 빌드가 압축‑텐서 NVFP4 지원을 포함하고 있는지 확인하라 — 불일치한 빌드는 조용히 백업하거나 모델 로드 시 충돌한다.

vLLM 서빙 명령어: 일반 및 DGX Spark

vllm serve nvidia/ Qwen3.6-35B-A3B-NVFP4 \  
   --port 8000 \  
   --quantization modelopt \  
   --max-model-len 262144 \  
   --reasoning-parser qwen3  

전체 화면 모드 진입

전체 화면 모드 종료

아래 코드 스니펫(예시이며 실행하려면 CUDA 환경과 transformers가 설치된 상태여야 함) 은 모델 로드 전 GPU가 Hopper 클래스인지 확인하는 방법을 보여준다. 각 완성 응답에 major ... 블록이 포함된다. JSON completions을 파싱하는 클라이언트는 잘못된 출력을 보게 되며, 스트리밍 클라이언트는 사고 사슬을 최종 사용자에게 직접 표시한다. 이 플래그는 선택적이지 않다.

DGX Spark 프로덕션 운영상의 한 가지 주의사항은 vllm/ vllm-openai:cu130-nightly 이미지가 안정적인 릴리스가 아니라는 것이다. 재현 가능한 배포를 위해서는 특정 빌드 해시를 고정하거나, 업스트림에 완전한 NVFP4 Blackwell 지원을 포함한 안정적인 vLLM 릴레이스를 대기하라.

플래그별 설명:

--kv-cache-dtype fp8 — BF16 대비 KV‑캐시 메모리를 절반으로 줄여, 0.85 VRAM 활용에서 더 긴 사용 가능한 컨텍스트를 직접 가능하게 함

--moe-backend marlin — Blackwell용 Marlin MoE 커널을 선택한다; 기본 선택이 이 아키텍처에 최적화되지 않을 수 있다

--max-num-seqs 4 — 제한된 VRAM 환경에서 총 동시 시퀀스 메모리를 예측 가능하게 유지한다; 신중히 늘리고 OOM 동작을 주시하라

--enable-chunked-prefill — DGX Spark에 필수이다; 없으면 장문의 프롬프트가 65536 토큰 한도 이전에 OOM 발생한다

--enable-prefix-caching — 멀티턴 채팅 워크로드에서 반복되는 시스템 프롬프트의 첫 토큰까지 소요되는 시간을 감소시킨다

--speculative-config '{"method":"mtp","num_speculative_tokens":3,"moe_backend":"triton"}' — 내장된 멀티‑토큰 예측(MTP) 헤드를 활성화한다; 별도 초안 모델을 로드하거나 관리할 필요 없이 사용 가능하다

내장된 MTP 추측 디코딩 헤드는 단일 사용자 베이스라인(512 토큰 출력)에서 85.4% 토큰 수용률을 달성하고, 4,096 토큰 출력에서는 92.8% 로 상승한다. 두 번째 초안 모델을 로드하거나 관리할 필요 없이 — MTP 헤드는 베이스 체크포인트에 내장되어 있다. 동시성 1에서 출력 throughput은 55.9 토큰/초이며, 동시성 32에서는 433.4 토큰/초로 확장된다. 커뮤니티 AEON-7 DFlash 변종은 DGX Spark에서 greedy decoding 시 117 토큰/s 를 보고하며, 초안 수용률은 62–78%, 목표 단계당 평균 수락된 토큰 수는 2.7–4.4이다.

네이티브 컨텍스트 창은 131K 토큰이며, RoPE 스케일링을 통해 262,144 토큰까지 확장 가능하다. DGX Spark에서는 --max-model-len 을 65536 로 제한해 0.85 VRAM 활용 범위 내에서 안전하게 유지한다.