LLM Wiki

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

9 min read

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

codex를 클라우드 고정 도구가 아니라 로컬 오픈웨이트 백엔드와 결합 가능한 실행 하네스로 바라보게 만드는 사례. 핵심은 “토큰 속도”보다 “첫 시도 성공률”, 그리고 로컬/클라우드 하이브리드 운영이다.

Key Points

  • Gemma 4는 Codex CLI 같은 에이전트형 코딩 루프에서 가장 중요했던 약점인 tool calling을 크게 개선했다. 글에서 인용한 tau2-bench 기준으로 Gemma 3의 6.6%에서 Gemma 4 31B의 86.4%까지 상승했다.
  • 비교 환경은 두 가지다: Mac M4 Pro 24GB + llama.cpp + Gemma 4 26B MoE, NVIDIA GB10 128GB + ollama + Gemma 4 31B Dense.
  • Mac은 생성 속도에서 52 tok/s로 빠르지만 재시도와 도구 호출 오류가 많았고, GB10은 10 tok/s로 느려도 첫 시도 성공률이 높아 총 작업 완성도는 더 좋았다.
  • 같은 codex exec --full-auto 과제에서 GPT-5.4는 65초, GB10 31B는 약 7분, Mac 26B는 4분 42초가 걸렸다. 그러나 Mac은 10번 도구 호출과 5번의 테스트 작성 실패가 있었고, GB10은 3번 도구 호출로 안정적으로 완료했다.
  • 결론은 “로컬도 이제 실무 수준 코딩이 가능하다”이지만, 기본 권장은 여전히 하이브리드다. 반복 작업과 프라이버시 민감 작업은 로컬, 복잡한 작업은 클라우드 모델이 더 낫다.

왜 중요한가

이 사례는 codex를 단순히 OpenAI API에 붙는 클라우드 CLI가 아니라, 적절한 OpenAI 호환/로컬 백엔드만 있으면 다른 모델에도 연결 가능한 에이전트 실행기라는 점을 보여준다. 동시에 로컬 오픈웨이트 모델이 “챗봇은 되지만 에이전트는 안 된다”는 단계에서 벗어나, 제한적이지만 실제 코드 생성·테스트·패치 루프를 소화하기 시작했다는 신호다.

다음 함의가 크다.

  • 로컬 코딩 에이전트 비용 구조를 다시 설계할 수 있다.
  • 민감 코드베이스를 외부 API에 보내지 않는 선택지가 현실화된다.
  • 로컬 모델 선택에서 단순 벤치마크 점수보다 tool calling 안정성과 재시도 비용이 더 중요해진다.

환경별 설정 메모

1. Mac + llama.cpp + Gemma 4 26B MoE

  • Ollama v0.20.3에서는 Gemma 4 tool calling 응답이 tool_calls 대신 reasoning output으로 잘못 라우팅되는 버그가 있었다.
  • Apple Silicon에서는 긴 프롬프트에서 Flash Attention freeze가 발생해 Codex CLI의 약 27K 토큰 시스템 프롬프트를 감당하기 어려웠다.
  • 그래서 llama.cpp로 전환했고, 글에서 강조한 핵심 플래그는 다음과 같다.
-np 1
-ctk q8_0 -ctv q8_0
--jinja
-m <GGUF 경로>
  • -np 1: 슬롯을 1개로 제한해 KV 캐시 메모리 폭증 방지
  • -ctk q8_0 -ctv q8_0: KV 캐시를 940MB → 499MB로 축소
  • --jinja: Gemma 4 tool-calling 템플릿에 필수
  • -m: GGUF 파일 직접 지정. -hf는 비전 프로젝터 다운로드로 OOM을 유발할 수 있음
  • Codex 설정에서는 web_search = "disabled" 필요. web_search_preview 타입을 llama.cpp가 거부하기 때문

2. NVIDIA GB10 + ollama + Gemma 4 31B Dense

  • vLLM은 PyTorch/CUDA ABI 불일치로 실패했다.
  • CUDA 빌드 llama.cpp도 Codex responses wire format과의 비함수 도구 타입 충돌로 실전 경로가 되지 못했다.
  • 결과적으로 안정적인 조합은 ollama v0.20.5였다.
ollama pull gemma4:31b
codex --oss -m gemma4:31b
  • 원격 GB10에서는 SSH 터널로 11434를 로컬에 포워딩했다. Codex --oss가 localhost를 기대하기 때문이다.
  • Apple Silicon에서 보인 스트리밍 버그가 NVIDIA 환경에서는 재현되지 않았고, 텍스트 생성과 도구 호출이 모두 첫 시도에 작동했다.

성능 해석

속도만 보면 Mac이 유리

  • Mac: 52 tok/s
  • GB10: 10 tok/s
  • 8K 프롬프트 처리: Mac 531 tok/s, GB10 548 tok/s

MoE 구조 덕분에 26B 전체 파라미터 중 약 3.8B만 활성화되어 토큰 생성 속도가 빨랐다. 반면 31B Dense는 매 토큰마다 전체 파라미터를 읽어야 해서 느렸다.

하지만 실무 완료 시간은 첫 시도 성공률이 좌우

  • Mac: 10번 도구 호출, 5번의 테스트 파일 작성 실패, 데드 코드 잔존
  • GB10: 3번 도구 호출, 첫 시도 테스트 통과, 데드 코드 없음
  • GPT-5.4: 65초, 후속 정리 없이 종료

즉 “빠른데 자주 틀리는 모델”보다 “느려도 한 번에 맞히는 모델”이 에이전트 코딩에서는 더 실용적일 수 있다. 이건 2026-04-13-claude-code-local-cloud-dichotomy에서 정리한 로컬/클라우드 역할 분리와도 맞닿아 있다.

실무 운영 팁

  • 로컬 프로필을 따로 두고 codex --profile local처럼 전환하는 하이브리드 운영이 현실적이다.
  • 프라이버시 민감 작업, 반복 리팩토링, 간단한 코드 수정은 로컬로 보내고, 복합 추론·긴 루프는 클라우드로 남기는 전략이 적합하다.
  • 메모리가 허락하면 낮은 양자화(Q4 이하)보다 높은 양자화를 우선 검토해야 한다. 커뮤니티 반응에서도 “코딩용은 품질이 tok/s보다 중요하다”는 의견이 반복되었다.
  • 긴 도구 호출 사이클 때문에 provider 설정에서 stream_idle_timeout_ms를 크게 늘려야 세션 중간 종료를 막을 수 있다.
  • llama.cpp와 Gemma 템플릿은 빠르게 바뀌므로 버전 고정과 재현 가능한 벤치마크 메모가 중요하다.

커뮤니티 반응

  • GeekNews 댓글에서는 “31B 기준으로는 꽤 준수하며 한국어와 도구 결과 정리도 잘한다”는 실사용 의견이 있었다.
  • Hacker News 쪽에서는 Gemma 4 26B가 동급 대비 인상적이지만, 에이전트형 코딩·비코딩 의사결정·대규모 컨텍스트 관리에서는 아직 한계가 있다는 반응도 많았다.
  • 동시에 “로컬 모델도 이미 2년 전부터 tool calling은 가능했다”는 반론, “Q4 같은 낮은 양자화 결과를 일반화하면 안 된다”는 지적도 나왔다.

Sources

그래프 뷰

백링크