이 기사에 대하여

study1에서는 gemma4:e2b,

・gemma4:e4b

(Ollama 일반 버전)을, study1-a에서는 MLX 버전을 검증했습니다. 그 과정에서, 2026년 7월 15일에 Google이 Hugging Face 상에서 Gemma 4 패밀리의 개선(FA4 어텐션 (Attention), 채팅 템플릿 수정 등)을 발표했음에도 불구하고, Ollama 배포판에는 아직 반영되지 않았다는 것을 알게 되었습니다.

그렇다면 "본가"인 Hugging Face 상의 오리지널 가중치를 직접 실행하면 어떻게 될까요? Ollama를 거치지 않고 transformers 라이브러리로 직접 로드하여, study1과 동일한 4가지 태스크로 검증했습니다. 번외편 그 두 번째, "study1-b"의 위치입니다.

TL;DR

HF 오리지널 버전 (transformers 최신 버전 필요, google/gemma-4-E2B-it, bf16 비양자화)은 실제로 Apple Silicon의 MPS에서 로드 및 추론이 가능하다 - 단, 환경 구축의 허들이 높다. 표준 transformers 릴리스 버전은 아직 gemma4 아키텍처에 대응하지 않아, GitHub 최신 버전 설치가 필수적이다 - 속도는 Ollama 일반 버전(양자화됨)과 동등하거나 약간 느리며, MLX 버전과 비교하면 3배 이상 느리다 - 중대한 품질 문제를 발견: 기본 샘플링 설정(temperature=1.0)으로 생성하면, 출력에 무관한 다국어 토큰이 혼입된다. 게다가 코드 블록 내에서 발생하면 구문이 깨져 작동하지 않는 코드가 생성된다 (후술). do_sample=False (greedy)로 설정하면 해소된다 - Aider와의 연동은 transformers serve 명령어 (OpenAI 호환 API 서버)로 구현할 수 있었다 - "양자화된 e2b/e4b도 공개되어 있을 것 같다"라는 정보는 공식 QAT int4 양자화 GGUF (google/gemma-4-E2B-it-qat-q4_0-gguf)를 말하는 것이었으나, Ollama의 hf.co 직접 pull 기능으로는 현재 실행할 수 없었다 (Error: 400, 원인 미상)

검증 환경

이 부분이 가장 고전했던 포인트: 검증기는 Apple Silicon (arm64)인데, Homebrew, pyenv, 기본 Python 3.13이 모두 Intel (x86_64) 빌드여서 Rosetta를 통해 동작하고 있었습니다. 최근의 torch macOS용 wheel은 arm64 전용이기 때문에, 그대로는 pip install torch가 "해당 버전 없음"으로 실패합니다. 기존의 Homebrew/pyenv에는 손을 대지 않고, micromamba로 arm64 네이티브 Python 3.11 환경을 별도로 구축함으로써 해결했습니다. 하드웨어와 실제로 동작하는 툴체인의 아키텍처가 일치하는지 python3 -c "import platform; print(platform.machine())"로 확인할 가치가 있습니다.

검증 방법

환경 구축

# arm64 네이티브 Python 환경 생성 (micromamba)
micromamba create -p ./mmenv -c conda-forge python=3.11
# torch・transformers (GitHub 최신 버전)・주변 라이브러리
...

순수 transformers 릴리스 버전 (4.57.6 시점)에서는 KeyError: 'gemma4'로 로드에 실패합니다. GitHub 최신 버전 (5.15.0.dev0)에서 처음으로 Gemma4Config로 인식되었습니다. 또한 Gemma4Processor가 이미지 처리를 위한 의존성으로 pillow와 torchvision을 요구하기 때문에 추가 설치가 필요했습니다.

모델 로드

from transformers import AutoProcessor, AutoModelForCausalLM
import torch
MODEL_ID = "google/gemma-4-E2B-it"
...

주의 사항: device_map="auto"

지정하면, MPS 환경에서는 GPU를 올바르게 인식하지 못하고 "모델 전체를 디스크로 오프로드하려고 시도합니다"라는 정체불명의 에러(ValueError: You are trying to offload the whole model to the disk)가 발생하며 실패했습니다. model.to("mps")를 통해 명시적으로 디바이스를 지정함으로써 회피할 수 있습니다.

로드 시간은 약 50~56초였으며, bf16 상태 그대로 약 10.2GB의 모델이 M4의 MPS 위에서 문제없이 동작했습니다.

4가지 태스크 실행

study1·study1-a와 동일한 4가지 태스크를, transformers serve로 구축한 OpenAI 호환 API 서버(후술)를 경유하여 각각 독립된 요청으로서 실행했습니다.

결과: 속도

HF 오리지널 버전(bf16 비양자화)은, Ollama 통상 버전(양자화됨)과 거의 동등하거나 약간 느렸으며, MLX 버전과 비교하면 3배 이상 느리다는 결과가 나왔습니다. 비양자화된 만큼 이론상으로는 정밀도 면에서 유리해야 하지만, 이번 4가지 태스크 범위 내에서는 속도 측면의 이점은 보이지 않았습니다.

결과: 내용의 질 — 무관한 토큰이 혼입되는 문제

내용의 정확성 자체는 나쁘지 않았습니다. 버그 탐지 태스크에서는 "이번 코드에서는 results가 5개의 요소를 가지고 있으므로 ZeroDivisionError는 발생하지 않지만, 함수 단독으로는 빈 리스트에 대한 방어 기제가 없다"라는, study1에서 높은 평가를 받았던 통상 버전과 동등한 수준의 문맥 이해를 보여주었습니다.

하지만, 기본 generation 설정(do_sample=True, temperature=1.0, top_p=0.95, top_k=64)으로 생성하면, 출력에 무관한 다국어 토큰이 혼입되는 현상이 4가지 태스크 중 4가지 태스크 모두에서 발생했습니다.

구체적인 예시 (FizzBuzz 태스크, 실제 생성된 코드에서 발췌):

if num % এসেছিলেন == 0: # 원래는 "if num % 3 == 0:"
output += "Fizz"

3이라는 숫자가 벵골어 단어(eshechilo, "왔다"라는 뜻)로 대체되어 있어, 이 코드는 구문 오류(Syntax Error)로 인해 실행할 수 없습니다. 유사한 현상은 버그 탐지 태스크에서도 발생하여, total이 스페인어인 delgado("마른")로, results가 포르투갈어인 Escola("학교")로 대체되어 생성된 코드 예시가 망가져 있었습니다. 단순한 외관상의 흐트러짐이 아니라, 실용상의 리스크로서 무시할 수 없는 수준입니다.

원인 파악을 위해 do_sample=False (greedy decoding)로 동일한 FizzBuzz 태스크를 재실행한 결과, 혼입은 발생하지 않았으며 정확하고 깨끗한 코드가 생성되었습니다.

def fizzbuzz_basic(n):
    for i in range(1, n + 1):
        if i % 3 == 0 and i % 5 == 0:
            ...

즉, 이번에 관측된 혼입은 모델 자체의 손상이 아니라, 온도(Temperature) 1.0에서의 샘플링이 선택한 저확률 토큰이 우연히 코드의 일부를 대체해 버리는 현상이라고 생각됩니다. study1·study1-a의 Ollama 실행 시에는 이 정도로 현저한 혼입은 보고되지 않았으며, 양자화 버전(GGUF/MLX)과 bf16 비양자화 버전 간에 동일한 sampling 설정에서도 실제 출력 분포에 차이가 있을 가능성이 있습니다 (이 점은 본 기사의 검증만으로는 단정할 수 없으며, 추가 조사가 필요합니다).

실무상의 교훈: HF 오리지널 버전을 코드 생성 용도로 사용할 경우, 기본 설정 그대로 사용하면 신뢰할 수 없습니다. do_sample=False로 설정하거나, 생성 후에 구문 체크를 거치는 것을 권장합니다.

Aider와의 연동

Ollama를 경유하지 않기 때문에, OpenAI 호환 API 서버를 별도로 구축해야 합니다. 이번에는 transformers

패키지에 동봉된 transformers serve 명령어를 사용했습니다.

pip install "transformers[serving]"
transformers serve google/gemma-4-E2B-it --device mps --port 8008

이렇게 하면 http://localhost:8008/v1/chat/completions에 OpenAI 호환 엔드포인트(Endpoint)가 구축됩니다. Aider 측에서는 다음과 같이 지정하는 것만으로 접속할 수 있었습니다.

aider --openai-api-base http://localhost:8008/v1 \
--openai-api-key dummy \
--model openai/google/gemma-4-E2B-it

실제로 FizzBuzz 코드 생성 및 파일 쓰기까지 문제없이 동작했습니다 (685 토큰 송신, 220 토큰 수신). vllm이나 text-generation-webui와 같은 중량급 서버를 별도로 셋업하지 않아도, transformers 단독으로 Aider 연동을 완결할 수 있다는 점은 높게 평가할 만합니다.

「양자화 버전」의 정체와 Ollama에서의 현황

계획 단계에서 사용자로부터 "양자화 버전의 e2b/e4b도 새로 공개된 것 같다"라는 정보가 있었으나, 조사 결과 이는 공식 QAT (Quantization-Aware Training) int4 양자화 GGUF 버전인 google/gemma-4-E2B-it-qat-q4_0-gguf (본체 3.35GB + 멀티모달용 mmproj 987MB)를 의미하는 것으로 판명되었습니다. study1-a에서 다루었던 MLX 버전 (nvfp4 양자화)과는 다른 양자화 방식입니다.

Ollama v0.31.2는 hf.co/... 형식으로 Hugging Face 상의 GGUF를 직접 pull 하는 기능을 가지고 있지만, 이 QAT 버전을 시도해 본 결과 Error: 400으로 실패했습니다.

$ ollama pull hf.co/google/gemma-4-E2B-it-qat-q4_0-gguf
pulling manifest
pulling fa401b55b07e: 100% ▕██████████████████▏ 3.3 GB
...

서버 로그를 확인해도 구체적인 에러 내용은 얻을 수 없었으며, 원인은 특정하지 못했습니다. 리포지토리에 메인 GGUF 파일과 더불어 멀티모달용 mmproj 파일이 동봉되어 있는 구성에 대해, 현재 Ollama의 hf.co 직접 pull 기능이 완벽히 대응하지 못하고 있을 가능성이 있습니다. llama.cpp 본체를 직접 사용하거나, unsloth/bartowski 등 다른 제공처의 GGUF를 시도하는 등의 회피책은 이번에 검증하지 않았습니다.

요약

계획 단계에서 세웠던 가설인 "HF 오리지널 버전은 환경 구축의 허들이 높아, 간편하게 테스트할 수 있다는 시리즈의 전제에서 벗어날 가능성이 있다"는 것은 실측 결과 뒷받침되었습니다. 구동 자체는 가능하지만, 그곳에 도달하기까지의 환경 구축 비용 (arm64 네이티브 환경 준비, GitHub 최신 버전 transformers 빌드, 주변 패키지 보완)은 Ollama의 ollama pull 한 번과는 비교할 수 없을 정도로 높으며, 게다가 구동한 후에도 속도 면의 이점이 없고 기본 설정에서는 생성 품질에 무시할 수 없는 불안정함이 있습니다.

study1~1-b를 통한 결론

study1 (통상 버전) · study1-a (MLX 버전) · 본 기사 (HF 오리지널 버전)까지 총 3편에 걸쳐 Gemma 4를 검증해 왔으나, Apple Silicon에서 Gemma 4를 사용한다면 순순히 MLX 버전 (gemma4:e2b-mlx / e4b-mlx)을 선택하는 것이 최선이라는 것이 최종적인 결론입니다.

MLX 버전은 "빠르고, 정확하며, ollama pull

「빠르고, 정확하며, ollama pull 한 번」이라는 세 박자를 모두 갖추고 있었으며, 실측 결과 명확한 약점으로 발견된 것은 데코레이터 설명 태스크에서의 해석 차이(모호한 프롬프트에 대한 기본 해석) 정도였습니다. HF (Hugging Face) 오리지널 버전은 비양자화 (non-quantized) 모델이기에 기대했던 정밀도 측면과는 달리, 속도에서도 MLX 버전에 뒤처졌으며, 기본 설정에서의 생성 품질에서도 과제가 발견되었습니다.

다만, 이 세 가지는 모두 각 태스크를 1회씩 실행한 결과이며, 통계적 근거를 동반한 엄밀한 비교는 아닙니다. 특히 이번에 발견된 토큰 혼입이 HF 오리지널 버전 (bf16 비양자화) 특유의 현상인지, 아니면 MLX 버전에서도 조건에 따라 발생할 수 있는지는 동일 조건에서의 다회차 시도를 통한 추가 검증을 수행하지 않았기에 단정할 수 없습니다. "경향성으로서의 비교"로 읽어주시는 것이 안전합니다.

실무에서의 결론: 평상시 사용은 MLX 버전 하나로 충분합니다. HF 오리지널 버전은 최신 학술적 개선 사항 (FA4 어텐션 등)을 가장 빠르게 검증하고 싶을 때나, transformers 에코시스템의 도구 (양자화, 파인튜닝 등)와 조합하고 싶을 때에 한해서만 선택할 가치가 있다는 것이 이번 검증을 통해 느낀 점입니다.

🤖 본 기사는 생성형 AI와의 대화 (Claude Code)를 바탕으로, 실제로 Hugging Face, transformers, Ollama, Aider를 조작하여 얻은 검증 결과를 구성 및 편집하였습니다.

Discussion