▲

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

 (blog.danielvaughan.com)
40P by GN⁺ | ★ favorite | 댓글 6개
  • 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배 속도 저하가 보고되어 벤치마크가 하룻밤 사이에 변동 가능
GeekNews Weekly에 포함된 글입니다. 에디터 코멘트 보기

함께 보면 좋은 글 β

▲
tsboard   [-]

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

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

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

답변달기
▲
kaydash   [-]

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

답변달기
▲
yangeok   [-]

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

답변달기
▲
GN⁺   [-]
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을 교체했음
      툴 호출 관련 문제를 해결했다고 하니 모델을 업데이트하는 게 좋음
답변달기
▲
boolsee   [-]

ollama로 local LLM 구성이 쉽긴 한데 오픈 소스 모델별 도구 호출이 실패할 가능성이 높다고 합니다. ollama 내부적으로 느슨한 규정과 모델별 도구 호출 Parser 문제가 얽혀있기 때문이라고 하네요.
정작 Local LLM의 가장 근원 문제는 중대형 모델 실행하기 위해서는 고가의 하드웨어가 필요하다는 것입니다. MAC Studio 32GB짜리가 3백 중반, GB10은 5~6백 정도라서 개인이 취미(?)를 위해 구입하기에는 부담스럽습니다. Local LLM은 작은 모델로, 중대형 모델은 Cloud 밖엔 답이 없습니다.

답변달기