▲

Gemma 4를 Codex CLI에서 로컬 모델로 실행하기

 (blog.danielvaughan.com)
22P by GN⁺ 18시간전 | ★ favorite | 댓글 5개
  • Gemma 4를 클라우드 대신 로컬 Codex CLI 환경에서 실행해 도구 호출 성능과 안정성을 검증한 사례로, GPT-5.4 대비 비용·프라이버시 이점을 확인
  • Mac(M4 Pro) 24GB 에서 26B MoE 와 NVIDIA GB10 128GB 에서 31B Dense 로 각각 llama.cpp와 Ollama를 사용해 동일한 코드 생성 작업을 수행, 설정 차이에 따른 성능을 비교
  • 도구 호출 성공률이 6.6%에서 86.4%로 향상되어 로컬 모델의 실용 가능성이 입증되었으며, GB10 환경에서는 완전한 코드 생성을 달성
  • Mac은 5.1배 빠른 토큰 생성 속도를 보였으나, 메모리 제약과 양자화 설정으로 인해 반복 시도가 필요했고, GB10은 느리지만 첫 시도에 성공
  • 결과적으로 로컬 모델도 실무 수준 코드 생성이 가능하며, 프라이버시 중심의 로컬 처리와 복잡 작업의 클라우드 전환을 병행하는 하이브리드 접근을 추천

로컬 모델 전환 동기

  • 비용 문제로, Codex CLI를 하루 여러 세션, 때로는 병렬로 실행하면서 API 비용이 누적
  • 프라이버시 요구로, 일부 코드베이스는 외부 서버로 전송되면 안 됨
  • 안정성 확보 필요로, 클라우드 API는 스로틀링·장애·가격 변경 리스크 존재
  • 이전에 로컬 모델을 시도하지 않은 이유는 도구 호출(tool calling) 불가 때문이었으며, Codex CLI의 핵심 가치는 모델이 파일 읽기, 코드 작성, 테스트 실행, 패치 적용을 수행하는 데 있음
  • 이전 Gemma 세대는 tau2-bench 함수 호출 벤치마크에서 6.6%(100번 중 93번 실패)였으나, Gemma 4 31B는 86.4% 로 도약하여 테스트 가치가 생김

Mac 설정 과정

  • Ollama로 시작했으나, v0.20.3에서 Gemma 4의 도구 호출 응답이 tool_calls 배열 대신 reasoning output으로 잘못 라우팅되는 스트리밍 버그 발생
  • Apple Silicon에서 Gemma 4 사용 시 약 500 토큰 이상의 프롬프트에서 Flash Attention freeze 발생, Codex CLI의 시스템 프롬프트는 약 27,000 토큰이므로 사실상 사용 불가
  • llama.cpp로 전환 후 Homebrew로 설치, 작동하는 서버 명령에 6개의 핵심 플래그 필요
    • -np 1: 슬롯 1개로 제한, 다중 슬롯은 KV 캐시 메모리를 배수로 증가시킴
    • -ctk q8_0 -ctv q8_0: KV 캐시 양자화로 940MB에서 499MB로 감소
    • --jinja: Gemma 4의 도구 호출 템플릿에 필수
    • -m에 직접 GGUF 경로 지정 필요, -hf 플래그 사용 시 1.1GB 비전 프로젝터가 자동 다운로드되어 OOM 크래시 유발
  • Codex CLI 설정에서 web_search = "disabled" 필수, llama.cpp가 거부하는 web_search_preview 도구 타입을 Codex CLI가 전송하기 때문

GB10 설정 과정

  • vLLM 0.19.0은 PyTorch 2.10.0 기반으로 컴파일되어 있으나, aarch64 Blackwell(compute capability sm_121)용 CUDA 지원 PyTorch는 2.11.0+cu128뿐이라 ABI 불일치로 ImportError 발생
  • llama.cpp를 CUDA로 소스 빌드하면 컴파일과 벤치마크는 통과하지만, Codex CLI의 wire_api = "responses"가 보내는 비함수 도구 타입을 llama.cpp가 거부
  • Ollama v0.20.5에서 성공, Apple Silicon에서 발생한 스트리밍 버그가 NVIDIA에서는 재현되지 않음
    • ollama pull gemma4:31b 실행 후, SSH 터널로 포트 11434를 Mac으로 포워딩(Codex CLI의 --oss 모드가 localhost만 확인하기 때문)
    • codex --oss -m gemma4:31b로 텍스트 생성과 도구 호출 모두 첫 시도에 작동
  • Mac 설정에 오후 대부분 소요, GB10은 모델 다운로드 대기 포함 약 1시간 소요

벤치마크 결과

  • 세 구성 모두에 동일한 작업 부여: codex exec --full-auto로 parse_csv_summary Python 함수 작성, 에러 핸들링 포함, 테스트 작성 및 실행
  • GPT-5.4(클라우드): 타입 힌트, 적절한 예외 체이닝, 불리언 타입 감지, 깔끔한 헬퍼 함수 포함 코드 생성, 5개 테스트 첫 시도 통과, 65초 완료, 후속 정리 불필요
  • GB10 31B Dense: 타입 힌트나 불리언 감지 없지만 견고한 에러 핸들링, 데드 코드 없음, 3번의 도구 호출로 5개 테스트 첫 시도 통과, 7분 소요
  • Mac 26B MoE: 구현부에 데드 코드 잔존, 타입 추론 루프를 작성 후 방치하고 아래에 'Actually, let's simplify' 주석과 함께 재작성, 테스트 파일 작성에 5번 시도 필요
    • 매번 다른 heredoc 오류 발생: filerypt → file_path, encoding=' 'utf-8'(공백 삽입), fileint(file_path) 등
    • GB10이 3번 만에 완료한 작업에 10번의 도구 호출 소요
    • 이 결과는 24GB Q4_K_M Codex CLI 환경의 결과이며, Gemma 4 Apple Silicon 전반에 대한 보편적 판단이 아님

속도 분석: Mac이 예상보다 빠른 이유

  • llama-bench로 동일한 컨텍스트 길이에서 양쪽 머신 측정, Mac이 GB10보다 토큰 생성 5.1배 빠름
  • 두 머신 모두 273 GB/s LPDDR5X 메모리 대역폭이지만, 토큰 생성은 메모리 대역폭 제한 작업
    • 31B Dense는 매 토큰마다 312억 개 전체 파라미터 읽기(약 17.4GB)
    • 26B MoE는 매 토큰마다 38억 개만 활성화(약 1.9GB)
    • 동일한 대역폭에서 Mac은 52 tok/s, GB10은 10 tok/s 기록
  • 프롬프트 처리 속도는 예상과 달리 Mac이 선전: 8K 컨텍스트에서 Mac 531 tok/s vs GB10 548 tok/s, MoE의 희소 활성화가 프롬프트 처리에도 유리하게 작용

핵심 교훈: 토큰 속도보다 첫 시도 성공률

  • Mac이 토큰 생성 5.1배 빠르지만 최종 완료 시간은 30%만 단축(4분 42초 vs 6분 59초)
  • 시간 차이의 원인은 재시도: 10번의 도구 호출 vs 3번, 5번의 테스트 작성 실패, 모델이 정리하지 않은 데드 코드
  • 클라우드 모델이 이를 더 극명히 입증: 가장 빠르고 토큰 사용 최소, 수리 패스 불필요, 5/5 65초 완료
  • 그러나 로컬도 실용적, 양쪽 머신 모두 테스트 통과하는 작동 코드 생성
  • Gemma 3(도구 호출 6.6%)에서 Gemma 4(86.4%)로의 품질 격차가 핵심적인 전환점이며, '작동하지 않음'에서 '작동함'으로의 단계가 로컬 에이전틱 코딩을 실용화하는 전환
  • Mac 결과에 대한 단서: Q4_K_M이 24GB 머신에서 메모리에 맞는 최고 양자화였으며, 더 넉넉한 Apple Silicon에서 더 높은 양자화로 재실행 시 결과가 달라질 수 있음
  • 하이브리드 접근 가능: codex --profile local로 반복 작업 및 프라이버시 민감 작업 처리, 복잡한 작업은 클라우드 기본값 사용, Codex CLI의 프로필 시스템으로 전환은 플래그 하나

설정 시 실용 팁

  • Apple Silicon: Ollama는 Gemma 4에서 사용 불가했으며, llama.cpp + --jinja 권장
    • Codex CLI 프로필에서 web_search = "disabled" 설정
    • -m으로 직접 GGUF 경로 지정, -hf 사용 금지
    • 컨텍스트 32,768 설정(Codex CLI 시스템 프롬프트에 최소 27,000 토큰 필요)
    • KV 캐시 양자화: -ctk q8_0 -ctv q8_0
  • NVIDIA GB10: Ollama v0.20.5가 첫 번째로 안정적 작동한 경로, codex --oss -m gemma4:31b 사용, 원격 머신이면 SSH로 포트 11434 터널링
  • 프로바이더 설정에서 stream_idle_timeout_ms를 최소 1,800,000으로 설정 필요, Mac에서 단일 도구 호출 사이클이 1분 39초 소요되어 기본 타임아웃 시 세션 종료
  • llama.cpp 버전 고정 권장, 빌드 간 3.3배 속도 저하가 보고되어 벤치마크가 하룻밤 사이에 변동 가능

함께 보면 좋은 글 β

▲
tsboard 15시간전  [-]

제가 회사에서 H100 2장으로 Gemma4-31B 운영을 해보니

  1. 답변 품질이 나름 준수하고 한국어 잘됩니다.
  2. 도구 실행에 대한 판단이나 실행 후 결과 정리도 잘합니다.
  3. 하지만 어디까지나 31B 파라미터를 감안했을 때 놀랍다! 수준인거고 당연히 더 큰 파라미터를 가지는 모델 (예: MiniMax-M2.5)과 비교할 때는 답변의 종합적인 품질 등에서 떨어지는 건 사실입니다.

전반적으로 작고 빠릿한 동작을 원하면 Gemma4로 충분할 것 같습니다. 저는 GPT-OSS-120B → Qwen3.5-35B-A3B로 교체했다가 이제 Gemma4-31B로 정착했는데 꽤 만족스러웠습니다. 계속 유지할 것 같네요.

답변달기
▲
kaydash 15시간전  [-]

헐 웹서치를 못 쓴다니! searxng 구성해도 못 쓰나요

답변달기
▲
yangeok 17시간전  [-]

한국어도 잘 되나 확인해보고싶네요

답변달기
▲
GN⁺ 18시간전  [-]
Hacker News 의견들

  • Gemma 4 26B는 같은 파라미터 규모의 모델 중 정말 예외적인 성능을 보였음
    내부 벤치마크에서 GPT 5.2, Gemini 3 Pro Preview와 비슷한 점수를 냈지만, 에이전트형 코딩과 비코딩 의사결정 영역에서는 약했음
    툴 사용, 반복적 개선, 대규모 컨텍스트 관리 등에서 점수가 떨어졌고, 오히려 툴을 써야 하는 상황에서는 성능이 낮아졌음
    아마도 흔한 하니스나 벤치마크에 오버피팅된 듯함. 그래도 M 시리즈 Macbook에서의 속도는 놀라움
    벤치마크는 gertlabs.com에서 확인 가능함

    • 내 ‘hello world’ 테스트에서는 실패했음
      “1차원 bin fitting 계산기를 웹페이지 하나로 구현하라”는 문제였는데, Qwen3.5, Nematron, Step 3.5, gpt-oss는 통과했지만 Gemma는 못했음
    • 전반적으로는 좋은 오픈 가중치 모델임
      다만 내 M5에서 GPT-OSS보다 단순한 코딩 실수를 더 자주 했음. 그래도 전체적으로는 근접한 수준임
    • Gemma 31B가 26B-A4B보다 점수가 낮게 나온 게 의외였음

  • “모델 품질이 토큰 속도보다 중요하다”는 결과가 놀랍다는 말이 있었음
    사실 당연한 얘기처럼 들림. 컨텍스트 크기를 32k로 제한하는 대신 --cpu-moe 옵션으로 MoE 연산을 CPU로 오프로드할 수도 있음

    • 토큰 속도는 결국 작업 완료 속도에만 영향을 주는 것 아닌가 생각함
    • 피곤할 때 커피 마시는 느낌임. 여전히 피곤하지만 단지 “빠르게” 움직이는 것뿐인 느낌임
    • Codex를 매일 쓰는 입장에서 보면, 속도보다 모델이 쓸데없는 루프에 빠지지 않는 것이 훨씬 중요함
      토큰 속도만 빠르면 결국 ‘AI 슬롭 코드베이스’가 폭증할 것임

  • 나는 현재 M3 Ultra(48GB RAM)에서 LM Studio와 Opencode로 google/gemma-4-26b-a4b를 돌려보고 있음
    컨텍스트를 65536으로 늘려야 했지만 잘 작동함. Zed와 ACP로도 쉽게 연동됨
    주로 간단한 코드 리뷰나 프론트엔드 코드 생성에 사용 중임

    • 나도 비슷한 환경임. pi-coding-agent를 써보면 좋음
      시스템 프롬프트와 툴 오버헤드가 2k 토큰 미만이라 프리필 지연이 훨씬 짧음
    • AMD RX7900XTX(24GB VRAM)에서 4개 채팅을 동시에 돌리며 512K 컨텍스트로 사용 중임
      속도는 약 100t/s로 거의 즉각적이고, Claude Code를 점점 덜 쓰게 됨
    • M1 Macbook에서 MLX 버전으로 XCode에 통합해 돌려봤는데, 작은 iOS 코드베이스에서는 중간에 멈춰버렸음
      챗봇으로는 괜찮지만 XCode 연동에는 부적합했음
    • Runpod GPU에서 31B 풀 버전을 돌려봤는데 인상적이었음
      지금은 Google API로 하루 1500회 무료 요청을 활용 중임
    • M4 Max(64GB) MacBook Pro에서 같은 설정을 사용 중임
      LM Studio 0.4.11+1 업데이트 전에는 툴 호출이 작동하지 않았지만, 지금은 Codex와 Opencode 모두 잘 됨

  • “로컬 모델은 툴 호출이 불가능하다”는 말은 틀림
    이미 2년 전부터 로컬에서도 툴 호출을 해왔고, Gemma3의 툴 호출 성공률이 7%라는 건 말이 안 됨
    Llama3.3에서도 최소 75%는 나왔음

    • 나도 그 문장에 놀랐음. 아마 작성자가 로컬 모델을 처음 돌려본 듯함
      Gemma 4 gguf Q4(16GB)처럼 과도하게 양자화된 모델은 성능이 많이 떨어짐
    • 그래도 Gemma 3와 4의 Tau 함수 호출 벤치마크 차이가 크다는 점은 사실임
    • 글 전체가 AI 자동생성 느낌이었음
      GB10 장비가 있다면 spark-vllm-docker 세팅이나 Qwen 3.5 122B A10B 최적화 버전을 써보길 추천함. 50tk/s 정도로 꽤 빠름

  • M4 Pro(24GB)에서 M5 Pro(48GB)로 업그레이드했는데, 같은 Gemma 4 MoE(Q4)가 8배 빠른 t/s를 보였음
    디스크에서 메모리로 로딩 속도도 2배 향상됨

    • RAM이 많다면 Q8_0으로 직접 돌려보길 권함. 초기 로딩 외에는 느리지 않고 품질도 거의 동일함
      MLX 버전을 쓰는지 확인해야 함. mlx-lm 커뮤니티 양자화 버전은 최근 수정되었음
      나는 16GB M1 Macbook에서는 힘들었지만, 64GB RAM의 AMD Framework 13에서는 CPU만으로도 충분히 빠르게 돌아감
      프롬프트 캐시 기능이 커다란 시스템 프롬프트를 삽입할 때 유용함

  • 로컬 하드웨어를 24/7로 돌리며 Gemma 4 같은 모델로 실험을 자동화하고, 큰 결정은 Claude Opus에 맡기는 하니스 아이디어를 제안함
    로컬 모델이 작은 실험과 POC를 수행하고, 막히면 Opus에 도움을 요청하는 구조임
    이렇게 하면 프롬프트 캐싱을 완전히 통제할 수 있어 비용이 거의 들지 않음

    • Mario의 Pi coding agent 확장 개발자인 Nico Bailon이 비슷한 시도를 하고 있음
      데모 영상과 pi-model-switch 저장소 참고 가능함

  • 코딩용으로는 Q6_K 이하의 양자화는 의미가 없음
    더 낮은 양자화는 코드 오류율이 급격히 높아짐

    • 대부분 이걸 모름. 토큰 수보다 토큰 품질이 중요함
      메모리가 허락하는 한 최대한 높은 양자화를 쓰는 게 좋음

  • Q4_K_M, Q8_0, Q6_K 등 양자화 방식별 품질 비교가 있었으면 좋겠음. 단순한 tok/s 수치보다 유용할 것 같음

  • Qwen3.5와 Gemma 4의 비교가 궁금함
    특히 Qwen3.5-27B-Claude-4.6-Opus 모델은 툴 호출에 특화되어 있고 다운로드도 50만 회 이상임

    • Jackrong이 공개한 파인튜닝 가이드를 보고 있음. 노트북 예제까지 잘 정리되어 있음
    • 나는 DGX Spark에서 직접 테스트했는데, 결국 Gemma 4로 돌아왔음
      Qwen 모델은 오케스트레이션 중 오류 수정 요청이 잦아 생산성이 떨어졌음
      Ollama용 가중치로 돌렸음
    • 개인 개발자가 대형 연구소보다 성능을 더 끌어올렸다는 주장은 다소 의심스러움
      최신 버전은 Qwopus3.5-27B-v3임

  • 며칠간 Gemma 4를 써봤는데, 빠르고 똑똑하지만 툴 사용 문제는 여전함
    속도보다 지능이 한계라 생산성이 제한됨. 루프에 빠질 때가 많음
    이런 상황을 감지해 더 똑똑한 모델에 “도움 요청”할 수 있으면 좋겠음
    이제는 코더라기보다 에이전트 오케스트레이터로 일하고 있음. 여러 에이전트를 병렬로 돌리며 관리하는 역할임

    • Google이 최근 gemma-4-31B-it의 chat_template.jinja와 tokenizer_config.json을 교체했음
      툴 호출 관련 문제를 해결했다고 하니 모델을 업데이트하는 게 좋음
답변달기
긱뉴스에 GeekBadge 기능이 추가되었습니다. 긱배지로 자신을 표현해 보세요.