Gemma 4 26B MoE 모델을 NVIDIA DGX Spark에서 NVFP4 양자화로 실행하는 방법

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

핵심 요약

Gemma 4 26B MoE 모델을 NVFP4 양자화로 16.5GB까지 압축하고 vLLM으로 최적화하여 서빙하는 구체적인 방법과 패치를 공유함.

배경

Gemma 4 26B MoE 모델을 NVIDIA DGX Spark 하드웨어에서 효율적으로 실행하기 위해 NVFP4 양자화 및 vLLM 서빙 최적화 과정을 수행하고 그 결과를 공유했다.

의미 / 영향

NVFP4 양자화가 MoE 모델의 메모리 요구량을 획기적으로 낮춰 단일 GPU 환경에서도 대형 모델 서빙이 가능함을 보여준다. 최신 아키텍처 모델의 경우 표준 라이브러리 지원 전까지는 커스텀 패치와 특정 백엔드 최적화가 성능과 정확도 확보의 관건이다.

커뮤니티 반응

작성자가 직접 개발한 커스텀 패치와 양자화 모델을 공유하여 커뮤니티의 높은 관심을 받았으며, 특히 최신 하드웨어인 Blackwell에서의 실측 성능 데이터가 유용한 정보로 평가받았다.

합의점 vs 논쟁점

합의점

NVFP4 양자화는 MoE 모델의 메모리 효율을 극대화한다
vLLM 서빙 시 특정 백엔드 플래그 설정이 결과의 정확도에 결정적이다

실용적 조언

Gemma 4 서빙 시 transformers 라이브러리를 5.4 이상으로 업데이트할 것
MoE 모델의 정확한 추론을 위해 --moe-backend marlin 플래그를 반드시 사용할 것
Instruct 모델 사용 시 completions 대신 chat/completions 엔드포인트를 사용할 것

섹션별 상세

NVFP4 양자화를 통해 Gemma 4 26B MoE 모델의 크기를 49GB에서 16.5GB로 줄였다. Google의 MoE 전문가 가중치가 3D 텐서로 융합되어 기존 도구로 처리가 불가능했으나, 전문가 레이어를 개별적으로 분리한 뒤 양자화하여 다시 내보내는 커스텀 플러그인을 개발했다. 이를 통해 3배의 압축률을 달성하면서도 모델의 91%에 달하는 전문가 가중치를 성공적으로 처리했다.

vLLM을 이용한 서빙 과정에서 최신 라이브러리 버전과 특정 백엔드 설정의 중요성을 확인했다. Gemma 4를 인식하기 위해 transformers 5.4 버전 이상이 필수적이며, MoE 전문가 계산 오류를 방지하기 위해 --moe-backend marlin 플래그를 명시적으로 설정했다. 또한 VLLM_NVFP4_GEMM_BACKEND=marlin 환경 변수를 통해 비 MoE 레이어의 연산 효율을 극대화했다.

bash

docker run -d \
--gpus all --ipc=host --network host \
-e VLLM_NVFP4_GEMM_BACKEND=marlin \
-v ~/.cache/huggingface:/root/.cache/huggingface \
-v ./gemma4_patched.py:/usr/local/lib/python3.12/dist-packages/vllm/model_executor/models/gemma4.py \
\
vllm serve bg-digitalservices/Gemma-4-26B-A4B-it-NVFP4 \
--served-model-name gemma-4 \
--host 0.0.0.0 --port 8888 \
--quantization modelopt \
--dtype auto --kv-cache-dtype fp8 \
--gpu-memory-utilization 0.40 \
--max-model-len 262144 \
--moe-backend marlin \
--enable-auto-tool-choice \
--tool-call-parser gemma4 \
--trust-remote-code

Gemma 4 NVFP4 양자화 모델을 vLLM으로 서빙하기 위한 Docker 실행 명령어

vLLM의 가중치 로더에서 발견된 NVFP4 스케일 키 매핑 버그를 해결하기 위해 gemma4.py 파일을 패치했다. 파라미터 이름의 점과 밑줄 표기 차이로 인해 발생하는 로딩 오류를 수정하여 모델이 정상적으로 구동되도록 조치했다. 이 패치된 파일을 Docker 컨테이너 내부에 마운트하여 실행함으로써 서빙 문제를 해결했다.

NVIDIA DGX Spark(GB100 Blackwell) 환경에서 초당 45-60 토큰의 생성 속도와 16.5GB의 VRAM 사용량을 기록했다. 256K에 달하는 긴 컨텍스트 윈도우를 충분한 여유 메모리와 함께 처리할 수 있음을 확인했다. 추론 결과에서 농담, 추론, 도구 호출 기능이 정상 작동했으나 코딩 능력은 양자화와 무관하게 베이스 모델 자체의 한계로 평이한 수준이었다.

실무 Takeaway

NVFP4 양자화를 통해 Gemma 4 26B 모델의 VRAM 점유율을 49GB에서 16.5GB로 3배 가량 절감했다.
MoE 전문가 가중치가 융합된 텐서 구조를 처리하기 위해 커스텀 플러그인으로 전문가 레이어를 분리 후 양자화하는 방식을 도입했다.
vLLM 서빙 시 transformers 5.4 이상 버전과 --moe-backend marlin 플래그를 사용해야 정확한 추론 결과와 성능을 얻을 수 있다.

언급된 도구

vLLM추천

추론 및 서빙 엔진

NVIDIA Model Optimizer중립

모델 양자화 도구

Transformers추천

ML 라이브러리

언급된 리소스

DemoGemma-4-26B-A4B-it-NVFP4 (Hugging Face)

GitHubspark-vllm-docker (GitHub)