모델별 실행 레시피

최종 업데이트

Gemma 4 26B-A4B MTP: 한 명과 여러 요청에서 달라지는 속도

Gemma 4 26B-A4B에서 MTP 요청을 비교해요

Gemma 4 26B-A4B는 문서나 사진과 질문을 입력받아 텍스트 답변을 생성하는 MoE1 모델이에요. 전체 25.2B 파라미터 가운데 토큰2마다 약 3.8B를 계산하며, 실행할 때는 전체 가중치와 문맥용 KV 캐시3를 준비해요. MTP4를 켜면 보조 모델이 다음 토큰 후보를 제안하고 본 모델이 검증해 답변 생성 시간을 줄일 수 있어요.

먼저 본 모델(target)만 실행해 사용할 문서를 끝까지 처리하는지 확인해요. 이어 같은 MLX-VLM 환경에서 보조 모델(assistant drafter)을 붙이고 같은 질문을 보내요. 첫 토큰까지의 대기와 이후 답변 생성 시간을 나누어 비교하면 MTP가 평소 작업에 도움이 되는지 알 수 있어요.

실행 조건과 핵심 내용
  • 25.2B 전체 가중치 적재와 토큰당 약 3.8B 활성 계산을 구분해요.
  • MTP에는 26B-A4B target과 짝이 맞는 assistant drafter가 필요해요.
  • 단일 요청과 동시 요청을 각각 측정하고, prompt·출력 길이·메모리를 함께 기록해요.
장비별 실행 설정으로 이동

먼저 전체 가중치와 활성 계산을 구분해요

긴 설계 문서에서 변경점을 찾는다면 26B-A4B의 ‘활성 3.8B’라는 숫자만 보고 메모리를 계산하지 않도록 해요. 한 토큰을 만들 때 일부 전문가만 활성화되지만, 실행기는 선택 가능한 약 25.2B 전체 가중치를 준비해요. 여기에 문맥용 KV 캐시와 운영체제·런타임5의 메모리도 더해져요.

Q4 데스크톱 경로는 8K 문맥과 동시 요청 하나를 비교 시작점으로 삼아요. 이는 모든 장비의 최적 설정이라는 뜻이 아니에요. target-only로 실제 문서 질문 하나가 끝나는지 먼저 확인하고, 안정적으로 실행된 뒤에만 assistant drafter를 더해요.

2026년 5월 Google이 공개한 Gemma 4 MTP drafter는 target에 붙여 쓰는 보조 체크포인트6예요. 작은 일반 채팅 모델을 대신 넣는 방식이 아니며, 앱과 런타임이 assistant 형식과 MTP를 지원해야 해요.

전체 25.2B 가중치와 3.8B 활성 계산량, KV 여유를 나눈 메모리 도식
MTP를 켜기 전에 전체 target 가중치와 문맥 여유를 확보해요.

초안 후보를 검증하는 MTP의 동작을 이해해요

일반 생성은 target이 다음 토큰을 하나씩 계산해요. MTP에서는 4층 assistant drafter가 뒤따를 토큰 후보를 먼저 제안하고, target이 후보 묶음을 검증해요. 맞는 후보가 이어지면 target 계산 한 번에 여러 토큰을 확정할 수 있어 디코드7 대기가 줄 수 있어요. 틀린 후보는 받아들이지 않고 target 출력으로 이어가요.

이득은 초안이 실제 다음 토큰과 얼마나 자주 맞는지에 따라 달라요. 후보가 자주 승인되면 decode 시간이 줄 수 있지만, 승인율이 낮으면 draft 계산과 메모리가 추가돼요. 긴 입력을 읽는 프리필8이 전체 대기의 대부분이면 MTP가 직접 바꾸는 생성 구간의 개선만으로 총 응답 시간이 크게 줄지 않을 수 있어요.

Google은 2026년 5월 발표에서 Apple Silicon의 batch 1에 routing challenge가 있었고, batch 4–8에서는 최대 약 2.2배 개선을 관찰했다고 밝혔어요. 이 결과는 발표의 모델·런타임·요청 묶음 조건에 해당해요. 개인 Mac의 단일 요청이나 다른 양자화9 앱 성능으로 일반화하지 말고, batch와 prompt10·출력 토큰 수를 함께 기록해요.

측정 구간에 따라 필요한 기록을 나눠요.
측정 구간확인할 질문기록할 조건
모델 적재target과 assistant가 메모리에 올라오는가?cold 시작, 파일 정밀도, 피크 메모리
프리필·TTFT긴 문서를 읽고 첫 토큰을 내기까지 얼마나 걸리는가?입력 토큰 수, warm/cold prefix, 문맥
디코드첫 토큰 뒤 답을 얼마나 빠르게 이어 쓰는가?출력 길이, 승인 토큰, temperature
전체 요청시작부터 완료까지 얼마나 걸리는가?batch, 동시성, 준비 실행과 반복 수

MLX-VLM에서 target-only 기준을 만들어요

이 실습은 Apple Silicon에서 MLX-VLM의 같은 BF1611 target을 먼저 실행한 뒤, 대응하는 BF16 assistant drafter를 더한 MTP와 비교해요. 두 모델 파일을 함께 준비할 메모리가 필요해요. Q4 LM Studio 결과를 비교군으로 섞지 않고, 같은 MLX-VLM 안에서 target만 쓸 때와 MTP를 켰을 때를 봐요.

첫 실행에는 모델을 내려받고 적재하는 시간이 포함될 수 있어요. 적재 완료와 응답을 확인한 뒤 같은 prompt와 256토큰 상한으로 target-only 요청을 3회 기록해요. 이어 drafter를 더한 명령을 같은 조건으로 실행해요. 로그에서 assistant 적재와 draft acceptance 통계가 나오는지도 확인해요.

두 실행 모두 답을 내고 MTP 로그에 승인 정보가 나타나는지 봐요. temperature 0에서 결과 문장이 달라지면 그 사실을 기록하고, runtime 버전·체크포인트·prompt template과 로그를 확인해요. 발표된 효율과 직접 실행한 측정값은 구분해요.

Gemma 4 26B-A4B target과 assistant MTP 비교
python -m pip install -U mlx-vlm
mlx_vlm.generate --model mlx-community/gemma-4-26B-A4B-it-bf16 --prompt "Design note: The Northstar launch moves from May 12 to May 19. The API freeze remains May 5. Summarize the changed date and the unchanged milestone." --max-tokens 256 --temperature 0
mlx_vlm.generate --model mlx-community/gemma-4-26B-A4B-it-bf16 --draft-model mlx-community/gemma-4-26B-A4B-it-assistant-bf16 --draft-kind mtp --draft-block-size 6 --prompt "Design note: The Northstar launch moves from May 12 to May 19. The API freeze remains May 5. Summarize the changed date and the unchanged milestone." --max-tokens 256 --temperature 0
공식 MLX-VLM 조합의 예예요. 첫 실행의 다운로드 시간을 분리하고 같은 prompt로 반복 비교해요.
Gemma 4 Q4 모델에서 LM Studio 로컬 API와 BF16 vLLM 서버로 이어지는 두 실행 경로
MTP는 같은 MLX-VLM 실행 환경에서 target-only와 보조 모델 경로를 비교해요.

단일 요청과 batch 처리를 따로 재요

target-only와 MTP를 각각 단일 요청으로 실행해요. 같은 prompt·출력 상한으로 준비 실행 후 3회 이상 반복하고, 첫 파일 적재 시간은 warm 측정과 분리해요. 중앙값, 답변 누락, 승인 토큰 수, 피크 메모리를 기록해요. 긴 입력에서는 생성 속도뿐 아니라 첫 토큰과 전체 완료 시간도 봐요.

서버가 여러 요청을 받는 상황은 별도 시험이에요. batch를 바꿀 때 prompt·출력 길이·요청 수만 조정하고 모델 파일과 draft block size는 유지해요. 한 사람의 반응성이 목적이면 단일 요청 대기가 기준이고, 서버 용량이 목적이면 요청별 지연과 전체 처리량12을 함께 봐요.

승인율이 낮거나 draft 비용 때문에 느려지면 해당 작업에서는 target-only가 더 나은 구성이 될 수 있어요. throughput 증가만으로 각 사용자의 답이 빨라졌다고 보지 말고, 자신의 실제 요청 묶음으로 판단해요.

모델 적재, 입력 처리, MTP token 검증과 문맥별 메모리 확인 순서를 그린 점검 흐름
단일 요청과 여러 요청을 나눠 측정해 사용할 조건에 맞는지 확인해요.

메모리 문제와 생성 대기에 맞춰 기능을 골라요

QAT는 가중치 표현과 압축 효율을 바꿔 메모리 요구를 낮추려는 선택이고, MTP는 생성 중 후보 토큰을 검증해 대기를 줄이려는 선택이에요. QAT target에 MTP를 적용하려면 두 기능을 함께 지원하는 target/drafter 짝을 확인해요. 임의 파일 이름에 QAT나 MTP가 들어 있다고 서로 호환되는 것은 아니에요.

target 자체가 적재되지 않으면 먼저 파일 정밀도와 메모리 여유를 조정해요. target은 동작하지만 답변 생성이 주된 병목일 때 MTP를 비교해요. 입력을 읽는 시간이 길다면 프리필과 캐시 조건부터 살펴요. target-only가 더 빨랐다면 그 작업에는 보조 모델을 얹지 않는 편이 나아요.

공식 발표와 실행 자료를 확인해요

MTP 구조와 Apple Silicon batch 결과는 Google이 2026년 5월 공개한 조건이에요. CLI13 실행 예시는 MLX-VLM의 공개 명령과 Gemma 4 pairing에 따랐어요. 이 글은 장비별 성능을 새로 측정하지 않았으므로, 개인 측정값은 사용한 모델·런타임·요청 조건과 함께 기록해요.

용어 각주

  1. MoE — 여러 전문가 하위망 중 일부를 입력에 따라 선택해 사용하는 모델 구조입니다. 총 파라미터 수와 한 토큰 처리에 활성화되는 파라미터 수는 다를 수 있습니다.

    본문으로 돌아가기
  2. 토큰 — 모델이 입력이나 출력을 나누어 처리하는 단위입니다.

    본문으로 돌아가기
  3. KV 캐시 — 어텐션에서 이전 토큰의 키·값을 저장해 다음 토큰 생성 때 재사용하는 메모리입니다. 문맥 길이와 배치 크기에 따라 용량이 달라집니다.

    본문으로 돌아가기
  4. MTP — 한 번에 여러 미래 토큰을 예측하도록 학습하는 목표 또는 이를 수행하는 모델 구성입니다. 추측 디코딩에서는 이 예측을 후보 토큰으로 제안할 수 있습니다.

    본문으로 돌아가기
  5. 런타임 — 프로그램이 실행될 때 필요한 기능을 제공하는 소프트웨어 환경입니다. 로컬 AI에서는 모델을 실행하는 엔진을 가리키기도 합니다.

    본문으로 돌아가기
  6. 체크포인트 — 학습된 모델의 가중치 등을 저장한 파일입니다. 같은 모델 계열도 버전이나 용도에 따라 다른 체크포인트를 쓸 수 있습니다.

    본문으로 돌아가기
  7. 토큰 디코드 — 입력과 앞서 만든 답변을 바탕으로 다음 출력 토큰을 차례로 생성하는 단계입니다.

    본문으로 돌아가기
  8. 프리필 — LLM이 입력 프롬프트를 읽고 각 토큰의 내부 표현을 계산하는 단계입니다. 입력이 길수록 처리할 토큰이 많아집니다.

    본문으로 돌아가기
  9. 양자화 — 모델의 가중치나 계산값을 더 적은 비트로 표현해 저장 공간과 메모리 사용량을 줄이는 방법입니다. 표현 단계가 거칠어져 정확도에도 영향을 줄 수 있습니다.

    본문으로 돌아가기
  10. 프롬프트 — 모델에 보내는 입력문입니다. 생성 모델에서는 만들 결과를 설명하는 문장이 되어 출력의 구성과 내용을 크게 좌우합니다.

    본문으로 돌아가기
  11. BF16 — 모델 수치를 저장하고 계산하는 16비트 부동소수점 형식입니다. FP32와 같은 폭의 지수부를 써 넓은 값 범위를 표현합니다.

    본문으로 돌아가기
  12. 처리량 — 일정 시간 동안 처리하거나 생성한 작업량입니다. 토큰/초, 요청/초처럼 단위를 함께 확인해야 비교할 수 있습니다.

    본문으로 돌아가기
  13. CLI — Command-Line Interface의 약자입니다. 터미널에 명령어를 입력해 프로그램을 조작하는 방식입니다.

    본문으로 돌아가기

자주 묻는 질문

이 글에서 가장 먼저 확인할 것은 무엇인가요?
Gemma 4 26B-A4B는 문서나 사진과 질문을 입력받아 텍스트 답변을 생성하는 MoE 모델이에요. 전체 25.2B 파라미터 가운데 토큰마다 약 3.8B를 계산하며, 실행할 때는 전체 가중치와 문맥용 KV 캐시를 준비해요. MTP를 켜면 보조 모델이 다음 토큰 후보를 제안하고 본 모델이 검증해 답변 생성 시간을 줄일 수 있어요.
필요한 메모리는 어느 정도인가요?
이 실습은 Apple Silicon에서 MLX-VLM의 같은 BF16 target을 먼저 실행한 뒤, 대응하는 BF16 assistant drafter를 더한 MTP와 비교해요. 두 모델 파일을 함께 준비할 메모리가 필요해요. Q4 LM Studio 결과를 비교군으로 섞지 않고, 같은 MLX-VLM 안에서 target만 쓸 때와 MTP를 켰을 때를 봐요.

실행 레시피

장비별 설정

한 사람이 사용할 때

사용할 장비를 고르면 실행 명령과 조정할 옵션이 나옵니다.

가용 메모리: 56GB / 대역폭: 307GB/s

운용 프로필

Apple MacBook Pro M5 Pro (64GB)

메모리 적정

권장 런타임: LM Studio (MLX 4비트 (GGUF Q4_K_M과 별도 형식)) · 문서화된 런타임 설정

설치 직후 처음 실행하거나 매일 안정적으로 사용할 때

선택 프로필 문맥

16,384 토큰

런타임 문서 기반MBP M5 Pro 64GB · Q4 · 요청 1개

런타임 문서에 따른 시작 설정입니다. 아래 순서로 조정하며 속도를 비교하세요.

계산기 예상 디코드

26.9 ~ 65.4 tok/s

단일 사용자 예상치

계산기 예상 TTFT

8.8 ~ 21.5초

프리필: 765 ~ 1,861 tok/s

예상 메모리 점유

약 16.34GB / 56GB

남은 여유: 약 39.7GB

서버 주소

http://127.0.0.1:1234

로컬 전용 127.0.0.1

예상치는 계산기의 추천 양자화·가속과 16,384토큰 기준입니다. 위 실행 설정의 실측값은 아닙니다.

이 프로필의 실제 설정

적용값왜 이렇게 잡았나
가중치MLX 4비트 (GGUF Q4_K_M과 별도 형식)MLX 모델 디렉터리를 사용합니다. GGUF의 Q4_K_M과 같은 파일 형식이 아닙니다.
입력 길이 확인16,384lms load의 context-length와 실제 로드 결과를 함께 확인합니다.
KV 캐시모델 설정에서 확인이 실행 명령은 KV 캐시 정밀도를 지정하지 않습니다.
프리필 배치런타임 설정에서 확인llama.cpp의 batch-size와 ubatch-size를 MLX 설정값으로 대신 쓰지 않습니다.
동시 요청1한 요청의 속도를 확인합니다. 여러 요청의 합산 처리량과 구분합니다.
메모리 여유2GB 이상모델을 불러온 뒤 실제 메모리와 스왑 여부를 확인합니다.

MBP M5 Pro 64GB 실행 명령어 (LM Studio)

LM Studio MLX 엔진 · 로컬 MLX 4비트 모델
# lms ls에서 확인한 MLX 4비트 모델 식별자를 입력
MODEL_ID=""
lms ls
: "${MODEL_ID:?MLX 모델 식별자를 입력하세요}"
lms load "$MODEL_ID" --gpu=max --context-length=16384
lms server start --port 1234
먼저 이 설정으로 기준 속도를 기록한 뒤 아래 튜닝 순서를 따라 한 항목씩 바꿉니다.

실행 후 확인

  1. 01서버 시작 로그에서 모델 적재 완료와 실제 컨텍스트 길이를 확인합니다.
  2. 02준비 실행 뒤 요청은 하나씩 보냅니다. 길이가 같은 서로 다른 입력 세 개로 첫 입력 처리 시간을 기록합니다.
  3. 03같은 입력을 반복한 결과는 캐시 재사용으로 따로 기록합니다. 첫 입력 결과와 합치지 않습니다.
  4. 04프리필 tok/s, 디코드 tok/s, 피크 메모리를 함께 기록한 뒤 한 항목씩만 바꿉니다.

바뀌는 점

  • 문맥과 동시 요청을 보수적으로 잡아 장비의 최대 처리량보다 낮게 나올 수 있습니다.

한 항목씩 조정

속도를 올리는 순서

여러 값을 한꺼번에 바꾸면 원인을 찾기 어렵습니다.

  1. STEP 1

    기준값 저장

    첫 입력과 캐시 재사용을 구분하고 각각 세 번 기록합니다. 프리필·디코드·피크 메모리를 함께 비교합니다.

    멈출 때: 오류가 있거나 메모리 여유가 2GB보다 작으면 다음 단계로 넘어가지 않습니다.

  2. STEP 2

    프리필 청크 조정

    1,024 → 2,048 → 4,096 순서로 올리며 긴 입력의 TTFT와 피크 메모리를 비교합니다.

    멈출 때: TTFT가 줄지 않거나 메모리 정점이 급증하면 직전 값으로 돌아갑니다.

  3. STEP 3

    KV 캐시 조정

    문맥이 부족할 때만 F16/BF16 기준값과 Q8 캐시를 같은 질문으로 비교합니다.

    멈출 때: 출력 차이가 생기거나 필요한 문맥이 이미 확보됐다면 기본 정밀도를 유지합니다.

  4. STEP 4

    MTP·투기 디코딩

    지원 모델에서만 켠 뒤 코드와 일반 문장을 나눠 수락률과 실제 디코드 tok/s를 측정합니다.

    멈출 때: 세 번의 중앙값이 기준보다 좋아지지 않으면 끕니다.

  5. STEP 5

    문맥 확장

    실제로 필요한 길이까지 두 배씩 늘리고 중간 정보 검색과 스왑 여부를 확인합니다.

    멈출 때: 검색 정확도가 떨어지거나 스왑·메모리 압축이 시작되면 한 단계 줄입니다.

내 장비 측정 기록 보내기

같은 조건으로 3회 이상 측정한 JSON을 가져오세요. 전송 버튼을 누르기 전에는 이 브라우저에서만 확인합니다.

장비·모델·실행 조건과 측정값만 받습니다. 질문·답변·원본 로그·파일 경로는 넣지 마세요.

기록 파일이 없다면, 실행 중인 로컬 서버에서 측정 도구로 만들 수 있습니다. Node.js 20 이상이 필요하며 결과를 자동 전송하지 않습니다.

검토한 이용자 제출 기록입니다. 이 사이트의 직접 측정과는 구분합니다.

설정 오류 제보

선택한 설정에서 막힌 부분을 알려주세요. 제보는 관리자만 확인합니다.

전송할 설정 · MBP M5 Pro 64GB · Gemma 4 26B-A4B (MoE) · 균형 설정

수정 내역

사이트의 안내가 바뀐 기록입니다. 설치된 엔진·모델 버전을 자동으로 확인한 결과는 아닙니다.

  1. Mac의 모델 형식과 실행 설정 정정

    Mac의 MLX 실행 경로를 GGUF Q4_K_M과 구분하고, 엔진 이름·모델 형식·명령의 표기를 맞췄습니다. 명령에서 지정하지 않는 KV 캐시 정밀도와 프리필 배치는 모델·런타임 설정에서 확인하도록 바꿨습니다.

    명령이 그대로인데 배치만 커진 것처럼 보이던 MLX 속도 프로필도 제거했습니다.

  2. 첫 입력과 캐시 재사용의 기록 분리

    검증 순서에서 처음 읽는 입력과 같은 입력을 반복한 결과를 따로 기록하도록 바꿨습니다. 캐시 효과를 프리필 처리량이나 장비 차이로 합산하지 않습니다.

  3. 장비·프로필 저장과 다시 열기 추가

    실행 가능한 프로필은 장비와 함께 이 브라우저에 최대 5개까지 저장하고, 가이드 목록에서 다시 열 수 있게 했습니다. 저장한 뒤 공개 설정이 바뀌거나 프로필이 없어지면 실행 전에 다시 확인하도록 안내합니다.

  4. 실행 엔진 설명으로 이어지는 링크 추가

    설정에 표시된 엔진 이름에서 해당 실행 프로그램의 설명으로 이어지도록 했습니다. 엔진이 확인되지 않은 경로에는 임의의 프로그램을 연결하지 않습니다.