모델별 실행 레시피

Gemma 4 26B-A4B 서빙 가이드: 24GB~32GB MoE 레시피

총 25.2B 상주와 3.8B 활성 연산, 24GB~32GB 데스크톱 MoE 서빙

쉽게 말하면

Gemma 4 26B-A4B는 총 25.2B 파라미터 중 토큰당 3.8B가 활성화되는 MoE 모델입니다. 계산에 참여하는 파라미터가 적더라도 전체 가중치는 적재해야 합니다. 24GB~32GB 장비의 Q4 경로와 더 많은 메모리가 필요한 공식 체크포인트 경로를 나누어 설명합니다.

장비를 고를 때

활성 파라미터가 3.8B라고 해서 4GB GPU에 돌릴 수 있는 것은 아닙니다. 25.2B 전체 가중치와 KV 캐시를 담을 수 있는 24GB~32GB 이상의 메모리 환경이 필요합니다.

이 글에서 확인할 내용

총 25.2B 가중치 상주를 위해 Q4 기준 약 16GB 이상의 가용 메모리가 필요합니다.
3.8B 활성 수치는 토큰당 계산량을 설명하며 품질이나 실제 속도를 보장하는 수치가 아닙니다.
초기 8K 보수적 컨텍스트와 127.0.0.1 로컬 바인딩으로 안전하게 시작합니다.

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

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

하드웨어	적합도	권장 런타임	안전 문맥	토큰 생성	첫 토큰
MBP M5 Pro 48GB (41GB)	메모리 적정	LM Studio	16,384 토큰	26.9 ~ 65.4 tok/s	8.8 ~ 21.5초
Studio M5 Ultra 256GB (236GB)	메모리 적정	LM Studio	16,384 토큰	85.2 ~ 160.6 tok/s	3.6 ~ 6.8초
Studio M5 Ultra 512GB (480GB)	메모리 적정	LM Studio	16,384 토큰	85.2 ~ 160.6 tok/s	3.6 ~ 6.8초
RTX 4090 24GB (22.5GB)	메모리 적정	llama.cpp (CUDA)	8,192 토큰	67.6 ~ 157 tok/s	1.9 ~ 2.0초
2× RTX 3090 48GB (NVLink) (45GB)	메모리 적정	llama.cpp (멀티 GPU)	16,384 토큰	83.7 ~ 242.7 tok/s	4.6 ~ 7.9초
RTX PRO 6000 96GB (93GB)	메모리 적정	llama.cpp (CUDA)	16,384 토큰	117.8 ~ 273.4 tok/s	3.2 ~ 3.9초
DGX Spark 128GB (116GB)	메모리 적정	llama.cpp (CUDA)	16,384 토큰	17.9 ~ 41.6 tok/s	11.0 ~ 14.9초
Ryzen AI Max+ 395 128GB (116GB)	메모리 적정	llama.cpp (ROCm/HIP)	16,384 토큰	16.8 ~ 39.1 tok/s	70.0 ~ 268.6초

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

아티팩트 및 런타임 선택

Gemma 4 26B-A4B는 총 25.2B 파라미터 중 토큰당 3.8B가 활성화되는 Mixture of Experts 아키텍처입니다. 데스크톱에서는 현재 런타임과 호환되는 Q4_K_M GGUF 또는 MLX 변환본을 확인해 사용합니다. 24GB VRAM이나 36GB 이상 통합 메모리에서는 8K 문맥부터 여유를 확인합니다.

공식 지시 튜닝 가중치(google/gemma-4-26B-A4B-it)를 BF16으로 서빙하는 경로는 가중치와 런타임 여유를 합쳐 64GB급 이상의 NVIDIA 환경을 기준으로 봅니다. 활성 파라미터가 3.8B여도 모든 전문가 가중치가 고속 메모리에 올라와야 합니다.

Gemma 4 26B-A4B MoE 모델의 총 25.2B 상주 가중치와 토큰당 3.8B 활성 파라미터 메모리 배치도 — 디코딩 계산은 3.8B 수준이지만 25.2B 전체 가중치를 상주시킬 24GB~32GB 메모리 여유가 요구됩니다.

로컬 서버 구동 (LM Studio / vLLM)

LM Studio CLI에서는 lms load를 사용해 호환 모델을 로드하고 안전한 8K(8,192 토큰) 컨텍스트를 지정합니다. 이어서 lms server start로 127.0.0.1:1234 포트를 개방합니다.

vLLM을 사용할 경우 공식 모델 ID를 직접 서빙하며, --max-model-len 8192 옵션으로 초기 메모리 헤드룸을 확보합니다. 네트워크에 열 때는 인증과 방화벽을 먼저 구성합니다.

LM Studio CLI 로컬 서빙 (24GB~32GB 데스크톱)

# 1. 로컬 모델 식별자 확인
lms ls

# 2. 호환 변환본을 8K 문맥으로 로드
lms load <gemma-26b-a4b-identifier> --gpu=max --context-length=8192

# 3. 로컬 서버 시작
lms server start --port 1234

24GB GPU 또는 Mac 36GB+ 환경에서 127.0.0.1 로컬 데몬을 실행합니다.

공식 vLLM MoE 서빙 (고용량 NVIDIA)

vllm serve google/gemma-4-26B-A4B-it   --host 127.0.0.1   --port 8000   --max-model-len 8192   --gpu-memory-utilization 0.90

공식 instruction 체크포인트는 Q4 데스크톱 경로보다 많은 메모리가 필요합니다.

LM Studio 및 vLLM을 통한 Gemma 4 26B-A4B MoE 로컬 서빙 실행과 8K 컨텍스트 설정 파이프라인 — 공식 모델 ID 또는 호환 Q4 파일을 불러와 127.0.0.1 로컬 바인딩으로 안전하게 서빙을 시작합니다.

엔드포인트 검증 및 MoE 디코드 테스트

서버 시작 후 curl로 로컬 API가 정상 응답하는지 확인합니다. 같은 장비·양자화·문맥 조건에서 첫 토큰 시간과 토큰 생성 속도를 기록해야 밀도형 모델과 비교할 수 있습니다.

긴 문맥에서는 MoE 계산량뿐 아니라 KV 캐시와 런타임 구현도 병목이 됩니다. 활성 파라미터 수만 보고 처리량을 추정하지 않습니다.

OpenAI 호환 챗 완성 호출 테스트

curl http://127.0.0.1:1234/v1/chat/completions   -H "Content-Type: application/json"   -d '{
    "model": "<gemma-26b-a4b-identifier>",
    "messages": [
      {"role": "user", "content": "MoE 아키텍처의 장점을 짧게 정리해줘."}
    ],
    "max_tokens": 512
  }'

127.0.0.1 로컬 엔드포인트의 응답 지연과 생성 속도를 측정합니다.

Gemma 4 26B-A4B API 응답 검증과 MoE 전문가 활성화 시 KV 캐시 및 디코드 속도 측정 다이어그램 — OpenAI 호환 챗 엔드포인트 호출을 통해 응답을 확인하고 긴 문맥 입력 시의 메모리 증가폭을 모니터링합니다.

메모리 점검 및 트러블슈팅

24GB 단일 GPU에서는 변환본 파일 크기, 로드 뒤 실제 점유량, 8K KV 캐시를 각각 확인합니다. 남은 메모리가 작다면 컨텍스트를 늘리기 전에 동시 요청 수부터 1로 고정합니다.

시스템 메모리 스왑이 발생하는 경우 디코드 속도가 급락하므로, 스왑 징후가 보이면 즉시 컨텍스트 길이를 축소하거나 Q4 양자화로 전환하세요.