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

4 days ago 7

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% 로 도약하여 테스트 가치가 생김

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가 전송하기 때문

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 전반에 대한 보편적 판단이 아님

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배 속도 저하가 보고되어 벤치마크가 하룻밤 사이에 변동 가능