Menjalankan Gemma 4 sebagai model lokal di Codex CLI

• Studi kasus menjalankan Gemma 4 di lingkungan Codex CLI lokal alih-alih cloud untuk memverifikasi performa dan stabilitas pemanggilan alat, sekaligus mengonfirmasi keunggulan biaya dan privasi dibanding GPT-5.4
• Pada Mac (M4 Pro) 24GB dengan 26B MoE dan NVIDIA GB10 128GB dengan 31B Dense, tugas pembuatan kode yang sama dijalankan masing-masing memakai llama.cpp dan Ollama, lalu performanya dibandingkan berdasarkan perbedaan konfigurasi
• Tingkat keberhasilan pemanggilan alat meningkat dari 6.6% menjadi 86.4%, membuktikan bahwa model lokal sudah layak digunakan secara praktis, dan pada lingkungan GB10 berhasil mencapai pembuatan kode yang lengkap
• Mac menunjukkan kecepatan generasi token 5.1 kali lebih cepat, tetapi karena keterbatasan memori dan pengaturan kuantisasi tetap membutuhkan percobaan berulang, sementara GB10 lebih lambat namun berhasil pada percobaan pertama
• Kesimpulannya, model lokal juga mampu menghasilkan kode pada level kerja nyata, dan direkomendasikan pendekatan hibrida yang menggabungkan pemrosesan lokal berfokus privasi dengan pemindahan tugas kompleks ke cloud

---

Motivasi beralih ke model lokal

• Masalah biaya, karena menjalankan Codex CLI dalam banyak sesi per hari, terkadang secara paralel, membuat biaya API terus menumpuk
• Kebutuhan privasi, karena sebagian codebase tidak boleh dikirim ke server eksternal
• Perlu menjamin stabilitas, sebab API cloud memiliki risiko throttling, gangguan layanan, dan perubahan harga
• Alasan sebelumnya tidak mencoba model lokal adalah karena tidak mendukung pemanggilan alat (tool calling), padahal nilai utama Codex CLI adalah kemampuan model untuk membaca file, menulis kode, menjalankan tes, dan menerapkan patch
• Generasi Gemma sebelumnya hanya mencatat 6.6% pada benchmark pemanggilan fungsi tau2-bench (93 gagal dari 100 percobaan), tetapi Gemma 4 31B melonjak ke 86.4%, sehingga layak diuji

Proses konfigurasi di Mac

• Awalnya memakai Ollama, tetapi pada v0.20.3 muncul bug streaming Gemma 4 yang salah mengarahkan respons pemanggilan alat ke reasoning output alih-alih array tool_calls
• Saat memakai Gemma 4 di Apple Silicon, terjadi freeze Flash Attention pada prompt sekitar 500 token ke atas, sementara system prompt Codex CLI sekitar 27.000 token, sehingga praktis tidak bisa dipakai
• Setelah beralih ke llama.cpp, instalasi dilakukan lewat Homebrew, dan perintah server yang berfungsi membutuhkan 6 flag inti
  • -np 1: membatasi ke 1 slot; multi-slot melipatgandakan penggunaan memori KV cache
  • -ctk q8_0 -ctv q8_0: kuantisasi KV cache, menurunkan dari 940MB menjadi 499MB
  • --jinja: wajib untuk template pemanggilan alat Gemma 4
  • Perlu menunjuk langsung path GGUF di -m; jika memakai flag -hf, vision projector 1.1GB akan terunduh otomatis dan memicu crash OOM
• Dalam konfigurasi Codex CLI, web_search = "disabled" wajib disetel karena Codex CLI mengirim tipe alat web_search_preview yang ditolak oleh llama.cpp

Proses konfigurasi di GB10

• vLLM 0.19.0 dikompilasi berbasis PyTorch 2.10.0, tetapi PyTorch dengan dukungan CUDA untuk aarch64 Blackwell (compute capability sm_121) hanya tersedia di 2.11.0+cu128, sehingga terjadi ketidakcocokan ABI dan muncul ImportError
• Saat llama.cpp dibangun dari source dengan CUDA, kompilasi dan benchmark lolos, tetapi tipe alat non-fungsi yang dikirim wire_api = "responses" dari Codex CLI ditolak oleh llama.cpp
• Berhasil di Ollama v0.20.5, dan bug streaming yang muncul di Apple Silicon tidak terulang di NVIDIA
  • Jalankan ollama pull gemma4:31b, lalu forward port 11434 ke Mac melalui SSH tunnel (karena mode --oss Codex CLI hanya memeriksa localhost)
  • Dengan codex --oss -m gemma4:31b, baik generasi teks maupun pemanggilan alat langsung bekerja pada percobaan pertama
• Konfigurasi Mac memakan hampir sepanjang sore, sedangkan GB10 selesai sekitar 1 jam termasuk menunggu unduhan model

Hasil benchmark

• Tiga konfigurasi diberi tugas yang sama: memakai codex exec --full-auto untuk menulis fungsi Python parse_csv_summary, termasuk penanganan error, lalu menulis dan menjalankan tes
• GPT-5.4 (cloud): menghasilkan kode dengan type hint, exception chaining yang tepat, deteksi tipe boolean, dan helper function yang rapi; 5 tes lolos pada percobaan pertama; selesai dalam 65 detik; tidak perlu pembersihan lanjutan
• GB10 31B Dense: tidak memiliki type hint atau deteksi boolean, tetapi penanganan error tetap solid dan tanpa dead code; 5 tes lolos pada percobaan pertama lewat 3 pemanggilan alat; memakan waktu 7 menit
• Mac 26B MoE: masih menyisakan dead code di implementasi; menulis loop inferensi tipe lalu dibiarkan, kemudian menulis ulang di bawahnya dengan komentar 'Actually, let's simplify'; perlu 5 percobaan untuk menulis file tes
  • Setiap kali muncul error heredoc yang berbeda: filerypt → file_path, encoding=' 'utf-8' (spasi tersisip), fileint(file_path), dan lain-lain
  • Tugas yang diselesaikan GB10 dalam 3 langkah membutuhkan 10 pemanggilan alat di sini
  • Hasil ini adalah hasil pada lingkungan Codex CLI Q4_K_M 24GB, bukan penilaian umum atas Gemma 4 di seluruh Apple Silicon

Analisis kecepatan: mengapa Mac lebih cepat dari perkiraan

• Dengan llama-bench pada panjang konteks yang sama, Mac mencatat generasi token 5.1 kali lebih cepat daripada GB10
• Kedua mesin sama-sama memiliki bandwidth memori 273 GB/s LPDDR5X, tetapi generasi token adalah pekerjaan yang dibatasi bandwidth memori
  • 31B Dense membaca seluruh 31,2 miliar parameter pada setiap token (sekitar 17.4GB)
  • 26B MoE hanya mengaktifkan 3,8 miliar per token (sekitar 1.9GB)
  • Pada bandwidth yang sama, Mac mencatat 52 tok/s, GB10 10 tok/s
• Kecepatan pemrosesan prompt juga cukup baik di Mac di luar dugaan: pada konteks 8K, Mac 531 tok/s vs GB10 548 tok/s, dan aktivasi sparse pada MoE juga menguntungkan pemrosesan prompt

Pelajaran utama: tingkat keberhasilan percobaan pertama lebih penting daripada kecepatan token

• Mac memang 5.1 kali lebih cepat dalam generasi token, tetapi waktu penyelesaian akhir hanya 30% lebih singkat (4 menit 42 detik vs 6 menit 59 detik)
• Penyebab selisih waktu adalah percobaan ulang: 10 pemanggilan alat vs 3, 5 kegagalan saat menulis tes, dan dead code yang tidak dibersihkan model
• Model cloud membuktikannya lebih jelas lagi: paling cepat, penggunaan token paling hemat, tidak perlu repair pass, dan selesai 65 detik dengan hasil 5/5
• Meski begitu, lokal tetap praktis, karena kedua mesin berhasil menghasilkan kode yang berjalan dan lolos tes
• Lompatan kualitas dari Gemma 3 (pemanggilan alat 6.6%) ke Gemma 4 (86.4%) menjadi titik balik penting; transisi dari 'tidak bekerja' ke 'bekerja' inilah yang membuat coding agent lokal menjadi praktis
• Catatan untuk hasil di Mac: Q4_K_M adalah kuantisasi tertinggi yang muat di mesin 24GB; jika dijalankan ulang dengan kuantisasi lebih tinggi pada Apple Silicon yang lebih lega memorinya, hasilnya bisa berbeda
• Pendekatan hibrida juga memungkinkan: gunakan codex --profile local untuk tugas berulang dan sensitif privasi, sementara tugas kompleks tetap memakai default cloud; perpindahan lewat sistem profil Codex CLI hanya butuh satu flag

Tips praktis saat konfigurasi

• Apple Silicon: Ollama tidak bisa dipakai untuk Gemma 4, dan disarankan memakai llama.cpp + --jinja
  • Setel web_search = "disabled" di profil Codex CLI
  • Tunjuk langsung path GGUF dengan -m, jangan gunakan -hf
  • Setel konteks 32,768 (system prompt Codex CLI membutuhkan minimal 27.000 token)
  • Kuantisasi KV cache: -ctk q8_0 -ctv q8_0
• NVIDIA GB10: Ollama v0.20.5 adalah jalur pertama yang bekerja stabil; gunakan codex --oss -m gemma4:31b; jika mesin remote, buat SSH tunnel untuk port 11434
• Pada pengaturan provider, stream_idle_timeout_ms perlu disetel minimal 1,800,000, karena satu siklus pemanggilan alat di Mac memakan 1 menit 39 detik dan session akan berakhir dengan timeout default
• Disarankan melakukan pin versi llama.cpp, karena pernah dilaporkan penurunan kecepatan 3.3 kali antar-build sehingga benchmark bisa berubah drastis dalam semalam

[tsboard]

Saya sempat menjalankan Gemma4-31B di perusahaan dengan 2 kartu H100.

1. Kualitas jawabannya lumayan solid dan juga bekerja baik dalam bahasa Korea.
2. Model ini juga bagus dalam menilai kapan perlu menjalankan tool dan merangkum hasil setelah eksekusi.
3. Namun tetap saja, ini lebih ke tingkat “mengejutkan untuk ukuran model 31B parameter!”, dan tentu jika dibandingkan dengan model yang memiliki parameter lebih besar (misalnya MiniMax-M2.5), memang kualitas jawaban secara keseluruhan masih kalah.

Secara umum, kalau menginginkan model yang kecil dan gesit, Gemma4 sepertinya sudah lebih dari cukup. Saya sempat mengganti dari GPT-OSS-120B → Qwen3.5-35B-A3B, lalu sekarang menetap di Gemma4-31B, dan saya cukup puas. Sepertinya akan terus saya pakai.

[kaydash]

Wah, ternyata tidak bisa pakai pencarian web! Bahkan kalau sudah mengonfigurasi searxng juga tetap tidak bisa dipakai?

[ysm0622]

https://github.com/ysm-dev/skills/blob/main/skills/web-search/SKILL.md

Coba pakai ini sebagai pengganti skill tersebut hehe

[yangeok]

Saya juga ingin mengecek apakah bahasa Korea didukung dengan baik.

[GN⁺]

Komentar Hacker News

• Gemma 4 26B menunjukkan performa yang benar-benar luar biasa di antara model dengan skala parameter serupa
  Dalam benchmark internal, nilainya mirip GPT 5.2 dan Gemini 3 Pro Preview, tetapi lemah dalam area coding berbasis agen dan pengambilan keputusan non-coding
  Skornya turun pada penggunaan tool, perbaikan iteratif, dan pengelolaan konteks besar, bahkan performanya justru lebih rendah saat berada dalam situasi yang memerlukan tool
  Kemungkinan model ini overfitting pada harness atau benchmark yang umum. Meski begitu, kecepatannya di Macbook seri M sangat mengejutkan
  Benchmark bisa dilihat di gertlabs.com

  • Dalam tes ‘hello world’ saya, model ini gagal
    Soalnya adalah “buat kalkulator 1D bin fitting dalam satu halaman web”; Qwen3.5, Nematron, Step 3.5, dan gpt-oss lolos, tetapi Gemma gagal
  • Secara keseluruhan ini adalah model open-weight yang bagus
    Namun di M5 saya, model ini lebih sering membuat kesalahan coding sederhana dibanding GPT-OSS. Meski begitu, secara umum levelnya tetap cukup dekat
  • Cukup mengejutkan bahwa skor Gemma 31B lebih rendah daripada 26B-A4B

• Ada yang bilang hasil bahwa “kualitas model lebih penting daripada kecepatan token” itu mengejutkan
  Sebenarnya terdengar cukup masuk akal. Alih-alih membatasi konteks ke 32k, operasi MoE juga bisa di-offload ke CPU dengan opsi --cpu-moe

  • Saya merasa kecepatan token pada akhirnya hanya memengaruhi kecepatan penyelesaian pekerjaan
  • Rasanya seperti minum kopi saat lelah. Anda tetap lelah, hanya saja bergerak “lebih cepat”
  • Dari sudut pandang orang yang memakai Codex setiap hari, jauh lebih penting bahwa model tidak terjebak dalam loop yang tidak berguna daripada soal kecepatan
    Jika hanya kecepatan token yang cepat, pada akhirnya ‘AI slop codebase’ akan meledak jumlahnya

• Saat ini saya menjalankan google/gemma-4-26b-a4b di M3 Ultra (RAM 48GB) dengan LM Studio dan Opencode
  Saya memang harus menaikkan konteks ke 65536, tetapi berjalan dengan baik. Integrasi dengan Zed dan ACP juga mudah
  Saya terutama memakainya untuk code review sederhana atau pembuatan kode frontend

  • Lingkungan saya juga mirip. Coba gunakan pi-coding-agent
    Karena system prompt dan overhead tool-nya kurang dari 2k token, latensi prefill jauh lebih pendek
  • Saya memakainya di AMD RX7900XTX (VRAM 24GB) dengan 4 chat berjalan bersamaan dan konteks 512K
    Kecepatannya sekitar 100t/s jadi nyaris instan, dan saya semakin jarang memakai Claude Code
  • Saya pernah mengintegrasikannya ke XCode di Macbook M1 dengan versi MLX, tetapi pada codebase iOS kecil modelnya berhenti di tengah jalan
    Sebagai chatbot masih oke, tetapi tidak cocok untuk integrasi XCode
  • Saya pernah menjalankan versi penuh 31B di GPU Runpod dan hasilnya mengesankan
    Saat ini saya memanfaatkan 1500 request gratis per hari melalui Google API
  • Saya memakai pengaturan yang sama di MacBook Pro M4 Max (64GB)
    Sebelum update LM Studio 0.4.11+1, tool calling tidak berfungsi, tetapi sekarang Codex dan Opencode sama-sama berjalan baik

• Pernyataan bahwa “model lokal tidak bisa melakukan tool calling” itu salah
  Saya sudah melakukan tool calling secara lokal sejak 2 tahun lalu, dan angka keberhasilan tool calling Gemma3 yang cuma 7% itu tidak masuk akal
  Di Llama3.3 pun setidaknya angkanya mencapai 75%

  • Saya juga kaget dengan kalimat itu. Mungkin penulisnya baru pertama kali menjalankan model lokal
    Model yang terlalu dikuantisasi seperti Gemma 4 gguf Q4 (16GB) memang performanya turun banyak
  • Namun memang benar bahwa perbedaan benchmark Tau function calling antara Gemma 3 dan 4 cukup besar
  • Seluruh tulisannya terasa seperti dibuat otomatis oleh AI
    Jika punya perangkat GB10, saya merekomendasikan setup spark-vllm-docker atau versi optimisasi Qwen 3.5 122B A10B. Kecepatannya cukup tinggi, sekitar 50tk/s

• Saya upgrade dari M4 Pro (24GB) ke M5 Pro (48GB), dan Gemma 4 MoE (Q4) yang sama menunjukkan t/s 8 kali lebih cepat
  Kecepatan loading dari disk ke memori juga meningkat 2 kali lipat

  • Jika RAM cukup besar, saya sarankan langsung menjalankan Q8_0. Selain loading awal, tidak terasa lambat dan kualitasnya juga hampir sama
    Pastikan memakai versi MLX. Versi kuantisasi komunitas mlx-lm baru-baru ini sudah diperbaiki
    Di Macbook M1 16GB saya memang berat, tetapi di AMD Framework 13 dengan RAM 64GB, bahkan dengan CPU saja modelnya tetap cukup cepat
    Fitur prompt cache berguna saat menyisipkan system prompt yang besar

• Ada usulan ide harness yang menjalankan hardware lokal 24/7 untuk mengotomatisasi eksperimen dengan model seperti Gemma 4, lalu menyerahkan keputusan besar kepada Claude Opus
  Strukturnya adalah model lokal menangani eksperimen kecil dan POC, lalu jika buntu meminta bantuan ke Opus
  Dengan cara ini, prompt caching bisa dikendalikan sepenuhnya sehingga biayanya nyaris nol

  • Nico Bailon, pengembang ekstensi Pi coding agent milik Mario, sedang mencoba pendekatan serupa
    Bisa lihat video demo dan repositori pi-model-switch

• Untuk coding, kuantisasi di bawah Q6_K tidak ada gunanya
  Pada kuantisasi yang lebih rendah, tingkat error kode naik sangat tajam

  • Kebanyakan orang tidak tahu ini. Yang penting bukan jumlah token, melainkan kualitas token
    Selama memori memungkinkan, lebih baik gunakan kuantisasi setinggi mungkin

• Akan bagus jika ada perbandingan kualitas berdasarkan metode kuantisasi seperti Q4_K_M, Q8_0, dan Q6_K. Rasanya itu akan lebih berguna daripada sekadar angka tok/s

• Saya penasaran dengan perbandingan Qwen3.5 dan Gemma 4
  Khususnya model Qwen3.5-27B-Claude-4.6-Opus yang dioptimalkan untuk tool calling dan sudah diunduh lebih dari 500 ribu kali

  • Saya sedang melihat panduan fine-tuning yang dirilis Jackrong. Bahkan contoh notebook-nya juga tertata rapi
  • Saya mengujinya langsung di DGX Spark, tetapi akhirnya kembali ke Gemma 4
    Model Qwen sering meminta perbaikan error saat orkestrasi, sehingga produktivitas turun
    Saya menjalankannya dengan bobot untuk Ollama
  • Klaim bahwa developer individu bisa mendorong performa melampaui lab riset besar terasa agak meragukan
    Versi terbarunya adalah Qwopus3.5-27B-v3

• Saya sudah memakai Gemma 4 selama beberapa hari, dan model ini cepat serta pintar, tetapi masalah penggunaan tool masih tetap ada
  Produktivitas dibatasi bukan oleh kecepatan, melainkan oleh batas kecerdasannya. Model ini cukup sering masuk ke loop
  Akan bagus jika situasi seperti ini bisa dideteksi lalu “meminta bantuan” ke model yang lebih pintar
  Sekarang rasanya saya bekerja bukan lagi sebagai coder, melainkan orkestrator agen. Perannya adalah mengelola banyak agen yang berjalan paralel

  • Google baru-baru ini mengganti chat_template.jinja dan tokenizer_config.json untuk gemma-4-31B-it
    Katanya masalah terkait tool calling sudah diperbaiki, jadi sebaiknya modelnya diupdate

[boolsee]

Memang mudah menyiapkan LLM lokal dengan ollama, tetapi katanya kemungkinan pemanggilan tool gagal cukup tinggi tergantung model open source yang dipakai. Konon hal ini karena kombinasi aturan yang longgar di internal ollama dan masalah parser pemanggilan tool yang berbeda-beda untuk tiap model.

Masalah paling mendasar dari Local LLM justru adalah bahwa untuk menjalankan model menengah hingga besar dibutuhkan hardware yang mahal. MAC Studio 32GB harganya sekitar pertengahan 3 juta won, sedangkan GB10 sekitar 5~6 juta won, jadi cukup memberatkan jika dibeli perorangan hanya untuk hobi (?). Untuk Local LLM, pilihannya adalah model kecil, sementara untuk model menengah hingga besar pada akhirnya selain Cloud memang tidak banyak opsi.