모델별 실행 레시피

최종 업데이트

Gemma 4 12B 서빙 설정: Q4 데스크톱과 BF16 서버

Gemma 4 12B를 Q4 데스크톱과 BF16 서버에서 실행해요

Gemma 4 12B는 텍스트 질문을 받아 답변을 만들고, 지원되는 모델·앱 조합에서는 이미지나 오디오 입력도 처리해요. 여기서는 16GB~24GB 데스크톱의 Q4 변환본과 더 큰 NVIDIA 장비의 공식 BF161 체크포인트2를 각각 준비하고, 로컬 API3 응답부터 확인해요.

두 경로는 같은 모델 계열을 쓰지만 파일 형식과 실행기가 달라요. 데스크톱에서는 앱이 지원하는 GGUF4 또는 MLX5 Q4 파일을 고르고, 공식 서버 예시는 NVIDIA에서 google/gemma-4-12B-it BF16 가중치를 사용해요. 먼저 텍스트 질문으로 적재와 응답을 확인한 다음, 실제로 필요한 경우에만 문맥을 늘리거나 이미지·오디오 입력을 더해요.

실행 조건과 핵심 내용
  • Q4 약 7.5GB 파일은 16GB 장비에서 짧은 텍스트 요청을 시험하는 구성이고, 실제 여유는 실행 중 메모리도 함께 봐요.
  • 공식 Transformers/vLLM 경로는 google/gemma-4-12B-it BF16 텍스트 서빙을 기준으로 해요.
  • LM Studio 예시는 127.0.0.1:1234, vLLM 예시는 127.0.0.1:8000에서 확인해요.
장비별 실행 설정으로 이동

먼저 파일 형식과 장비 경로를 골라요

16GB 장비에서 시작한다면 현재 앱이 지원하는 GGUF 또는 MLX Q4 변환본을 사용해요. 약 7.5GB는 파일 크기일 뿐이며, 적재 뒤에는 런타임6과 운영체제, 대화의 KV 캐시7, 다른 앱이 메모리를 나눠 써요. 파일을 받은 뒤에는 앱의 모델 목록에서 실제 식별자와 형식을 확인하고, 짧은 문맥으로 먼저 열어요.

공식 google/gemma-4-12B-it 체크포인트는 BF16 기준 약 24GB예요. 아래 vLLM 예시는 이 공식 가중치를 사용하는 NVIDIA 서버 경로이며, Q4 데스크톱 명령과 섞지 않아요. 두 결과를 비교할 때는 가중치 정밀도와 실행기가 모두 달라진다는 점을 기록해요.

처음에는 이미지나 오디오 대신 짧은 한국어 텍스트 질문을 보내요. 이 요청이 끝까지 처리되면 모델 적재와 텍스트 경로를 확인한 셈이에요. 이후 요약할 문장이나 답을 아는 문서 질문으로 바꾸면, 기본 응답과 추가 입력 기능을 구분해 점검할 수 있어요.

노트북에서 나온 블록을 돋보기로 살핀 뒤, 화살표가 정리된 서버와 흩어진 블록으로 갈라져요.
Q4 변환본과 공식 가중치는 별도 실행 경로로 준비해요.

LM Studio와 공식 vLLM 중 한 경로로 실행해요

데스크톱 명령은 LM Studio에 표시된 모델 식별자를 사용해 Q4 파일을 적재하고 문맥 상한을 8K로 둬요. --gpu8=max는 GPU 오프로드를 요청하는 설정이에요. 실행 후 앱의 적재 상태와 로그에서 실제 사용 경로를 확인해요. 설정값 자체만으로 모든 가중치가 GPU에 올라갔다고 판단하지 않아요.

공식 서버는 google/gemma-4-12B-it를 8K 문맥, GPU 메모리 사용률 0.90으로 실행해요. 예시의 127.0.0.1 바인딩은 서버 프로세스가 로컬 인터페이스에서 듣게 해요. LM Studio에서도 네트워크 제공 범위를 확인하고, 다른 장치에서 접속하도록 바꿀 때는 인증과 방화벽 규칙을 별도로 설정해요.

프로세스가 켜진 뒤 모델 적재 완료와 선택한 모델 이름을 확인하고, 한 번에 요청 하나를 보내요. 첫 요청이 정상 완료된 다음에만 문맥이나 요청 수를 바꾸면 어느 설정이 메모리와 대기에 영향을 줬는지 추적하기 쉬워요.

LM Studio 명령을 실행하면 내려받은 파일을 고르는 목록이 나타나요. lms ls에서 확인한 Gemma 4 12B 파일을 선택하고 로딩을 기다리세요. 이 예제는 API 별칭을 gemma-local로 정해 뒤의 요청과 맞춰요. vLLM을 선택했다면 서버를 실행한 터미널은 그대로 두고 다음 API 요청은 다른 터미널에서 보내세요.

LM Studio CLI 로컬 서빙 (데스크톱 16GB~24GB)
# 1. List models
lms ls

# 2. Load the model with maximum GPU offload and an 8K context
lms load --gpu=max --context-length=8192 --identifier gemma-local

# 3. Start the local server daemon (127.0.0.1:1234)
lms server start --port 1234
목록에서 실제 모델 식별자를 확인해 적재한 뒤 1234 포트의 로컬 서버를 시작해요.
공식 vLLM 텍스트 서빙 (NVIDIA GPU)
vllm serve google/gemma-4-12B-it   --host 127.0.0.1   --port 8000   --max-model-len 8192   --gpu-memory-utilization 0.90
NVIDIA 환경에서 공식 instruction 가중치를 127.0.0.1:8000에 제공해요.

API로 짧은 답과 실제 작업을 점검해요

LM Studio의 요청에는 앞에서 지정한 API 별칭 gemma-local을 넣고 한국어 자기소개를 요청해요. vLLM을 선택했다면 8000 포트의 예제에서 google/gemma-4-12B-it를 사용하세요. 응답이 끝까지 도착하고 선택한 언어로 답하는지 확인해요. 스트리밍은 답변이 전송되는 모습이며, 정확한 생성 속도는 별도 측정으로 기록하면 돼요.

이어서 같은 질문을 여러 번 보내 첫 토큰9이 나올 때까지의 시간, 생성 구간의 속도, 피크 메모리를 기록해요. 일반적인 요약 문서로 입력을 바꾸면 첫 응답까지와 전체 완료까지를 나눠 봐요. 짧은 자기소개만으로 실제 업무 품질을 대표하지 않도록 해요.

문서 안의 날짜나 담당자처럼 답을 확인할 수 있는 질문도 사용해요. 설정을 바꾸어 비교할 때는 같은 문장과 파일을 유지해야 어떤 변화가 결과에 영향을 줬는지 알 수 있어요.

LM Studio는 아래 1234 포트 요청을 사용해요. vLLM의 BF16 서버를 선택했다면 이어지는 8000 포트 요청을 보내세요. 서버가 반환하는 /v1/models 목록에서 모델 이름을 먼저 확인하면 앱 연결에도 같은 값을 넣을 수 있어요.

OpenAI 호환 API 테스트
curl -N http://127.0.0.1:1234/v1/chat/completions   -H "Content-Type: application/json"   -d '{
    "model": "gemma-local",
    "messages": [
      {"role": "user", "content": "한국어로 자기소개를 간단히 작성해줘."}
    ],
    "max_tokens": 512,
    "stream": true
  }'
127.0.0.1:1234의 로컬 API에 스트리밍 요청을 보내요.
vLLM BF16 서버의 모델과 첫 답 확인
curl --fail-with-body http://127.0.0.1:8000/v1/models
curl --fail-with-body http://127.0.0.1:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{"model":"google/gemma-4-12B-it","messages":[{"role":"user","content":"Reply with one short sentence."}],"max_tokens":64}'
이 요청은 위에서 시작한 vLLM 8000 포트 서버에 보내요.
모니터의 색 블록에서 작은 블록 줄이 서버 선반으로 이어지고, 옆에 작은 서버 세 대가 쌓여 있어요.
짧은 텍스트 요청과 API 응답으로 기본 실행을 확인해요.

이미지와 오디오는 하나씩 추가해요

텍스트 기준 요청이 안정적으로 끝난 뒤, 앱과 모델 조합이 실제로 지원하는 이미지 입력을 추가해요. 텍스트 질문은 그대로 두고 그림만 바꿔 물으면 입력 경로와 메모리 변화를 비교하기 쉬워요. 화면에서 파일을 붙일 수 있는 것만으로 모델까지 이미지가 전달됐다고 보지 말고 요청에 포함됐는지 확인해요.

오디오도 받아쓰기인지 음성에 대한 대화인지 작업을 먼저 정하고, 녹음 입력이 앱에서 모델까지 전달되는지 시험해요. 사진·녹음·긴 문서를 한꺼번에 넣지 않으면 실패 원인을 찾기 쉽고, 멀티모달 인코더와 입력 처리에 필요한 메모리도 따로 관찰할 수 있어요.

메모리 부족이 생기면 먼저 문맥과 동시에 보낸 요청 수를 낮춰 텍스트 기준 요청이 회복되는지 확인해요. 가중치 파일의 Q4 형식과 KV 캐시 정밀도는 다른 설정이므로 구분해서 조정해요. 평소 작업에서 같은 한계가 반복될 때 더 큰 메모리 장비를 검토하면 실제로 필요한 여유를 기준으로 비교할 수 있어요.

업무에 필요한 경로만 남기고 선택해요

Q4 구성이 문서와 텍스트 요청을 충분히 처리하고 기다림도 괜찮다면 더 큰 가중치로 바꾸지 않아도 돼요. 다른 후보를 시험할 때는 같은 파일과 질문, 문맥을 사용하고 성공 여부와 전체 완료 시간을 비교해요.

공식 BF16 서버를 운영할 계획이라면 약 24GB 가중치와 서버의 추가 여유를 담을 NVIDIA 장비를 별도로 검토해요. 먼저 실제로 사용할 파일과 입력 기능을 정한 뒤 구매 조건을 맞추면, 쓰지 않을 경로의 메모리까지 비용에 포함하지 않게 돼요. 안정적으로 동작한 모델 파일, 앱 버전, 문맥과 서버 설정을 기록해 두면 업데이트 뒤 재시험 기준으로 쓸 수 있어요.

작은 컴퓨터와 큰 서버가 초록색 체크 표시가 있는 점선으로 이어지고, 위에는 서로 다른 블록 묶음이 있어요.
실제로 쓰는 작업에 맞춰 작은 Q4 경로와 서버 경로를 선택해요.

NVFP4 배포본을 쓸 때는 엔진 호환성을 확인해요

Gemma 4 로더가 포함된 SGLang 분기가 필요해요. AxionML/Gemma-4-12B-NVFP4 구성은 FFN에 NVFP410를, 어텐션11에 BF16을 사용해요. 배포본을 받기 전에 선택한 SGLang 분기가 해당 형식을 지원하는지 확인하고, 실행 로그에서 실제로 로드된 가중치 경로를 살펴요.

용어 각주

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

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

    본문으로 돌아가기
  3. API — 프로그램의 기능을 다른 코드에서 호출하기 위한 약속된 인터페이스입니다.

    본문으로 돌아가기
  4. GGUF — 모델 정보를 담는 파일 형식으로 llama.cpp 계열 도구에서 널리 사용됩니다.

    본문으로 돌아가기
  5. MLX — Apple이 개발하는 머신러닝 프레임워크로, Apple Silicon의 CPU와 GPU가 공유하는 메모리를 활용해 모델을 실행합니다.

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

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

    본문으로 돌아가기
  8. GPU — 많은 계산을 병렬로 처리하는 프로세서입니다. AI 모델 실행에서는 모델 계산을 맡습니다.

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

    본문으로 돌아가기
  10. NVFP4 — NVIDIA가 정의한 4비트 부동소수점 데이터 형식입니다. 지원 여부는 GPU 세대, 모델과 소프트웨어 구현에 따라 다릅니다.

    본문으로 돌아가기
  11. 어텐션 — 입력 토큰 사이의 관련도를 계산해 각 위치의 정보를 현재 표현에 반영하는 신경망 연산입니다.

    본문으로 돌아가기

자주 묻는 질문

이 글에서 가장 먼저 확인할 것은 무엇인가요?
Gemma 4 12B는 텍스트 질문을 받아 답변을 만들고, 지원되는 모델·앱 조합에서는 이미지나 오디오 입력도 처리해요. 여기서는 16GB~24GB 데스크톱의 Q4 변환본과 더 큰 NVIDIA 장비의 공식 BF16 체크포인트를 각각 준비하고, 로컬 API 응답부터 확인해요.
필요한 메모리는 어느 정도인가요?
16GB 장비에서 시작한다면 현재 앱이 지원하는 GGUF 또는 MLX Q4 변환본을 사용해요. 약 7.5GB는 파일 크기일 뿐이며, 적재 뒤에는 런타임과 운영체제, 대화의 KV 캐시, 다른 앱이 메모리를 나눠 써요. 파일을 받은 뒤에는 앱의 모델 목록에서 실제 식별자와 형식을 확인하고, 짧은 문맥으로 먼저 열어요.

실행 레시피

장비별 설정

한 사람이 사용할 때

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

가용 메모리: 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개

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

계산기 예상 디코드

31.3 ~ 34.8 tok/s

단일 사용자 예상치

계산기 예상 TTFT

21.3 ~ 46.3초

프리필: 354 ~ 769 tok/s

예상 메모리 점유

약 9.61GB / 56GB

남은 여유: 약 46.4GB

서버 주소

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 12B · 균형 설정

수정 내역

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

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

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

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

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

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

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

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

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

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