Menjalankan Gemma 4 sebagai model lokal di Codex CLI

 (blog.danielvaughan.com)
40 poin oleh GN⁺ 6 hari lalu | 6 komentar | Bagikan ke WhatsApp
  • 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
  • Di Mac (M4 Pro) 24GB dengan 26B MoE dan NVIDIA GB10 128GB dengan 31B Dense, tugas generasi kode yang sama dijalankan masing-masing memakai llama.cpp dan Ollama, lalu dibandingkan performanya berdasarkan perbedaan konfigurasi
  • Tingkat keberhasilan pemanggilan alat meningkat dari 6.6% menjadi 86.4%, membuktikan kelayakan praktis model lokal, dan pada lingkungan GB10 berhasil mencapai generasi kode penuh
  • Mac menunjukkan kecepatan generasi token 5.1x lebih cepat, tetapi karena keterbatasan memori dan pengaturan kuantisasi, dibutuhkan beberapa percobaan ulang; GB10 lebih lambat tetapi berhasil pada percobaan pertama
  • Kesimpulannya, model lokal juga mampu menghasilkan kode pada tingkat kerja nyata, dan direkomendasikan pendekatan hibrida yang menggabungkan pemrosesan lokal berfokus privasi dengan perpindahan ke cloud untuk tugas kompleks

Alasan beralih ke model lokal

  • Masalah biaya, karena Codex CLI dijalankan dalam banyak sesi per hari, kadang paralel, sehingga biaya API terus menumpuk
  • Kebutuhan privasi, karena sebagian codebase tidak boleh dikirim ke server eksternal
  • Perlu keandalan, sebab API cloud memiliki risiko throttling, gangguan, dan perubahan harga
  • Alasan sebelumnya tidak mencoba model lokal adalah karena tidak mendukung tool calling, padahal nilai utama Codex CLI terletak pada 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 (gagal 93 dari 100 kali), tetapi Gemma 4 31B melonjak ke 86.4%, sehingga layak diuji

Proses pengaturan Mac

  • Mulai dengan Ollama, tetapi pada v0.20.3 terjadi bug streaming di mana respons pemanggilan alat Gemma 4 salah diarahkan ke reasoning output alih-alih array tool_calls
  • Saat menggunakan Gemma 4 di Apple Silicon, terjadi freeze Flash Attention pada prompt sekitar 500 token atau lebih; karena system prompt Codex CLI sekitar 27.000 token, praktis tidak bisa digunakan
  • Setelah beralih ke llama.cpp, instalasi dilakukan lewat Homebrew, dan perintah server yang berfungsi memerlukan 6 flag inti
    • -np 1: membatasi ke 1 slot; multi-slot melipatgandakan penggunaan memori cache KV
    • -ctk q8_0 -ctv q8_0: kuantisasi cache KV yang menurunkan penggunaan dari 940MB menjadi 499MB
    • --jinja: wajib untuk template pemanggilan alat Gemma 4
    • Perlu menunjuk path GGUF langsung 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, karena Codex CLI mengirim tipe alat web_search_preview yang ditolak oleh llama.cpp

Proses pengaturan GB10

  • vLLM 0.19.0 dikompilasi berbasis PyTorch 2.10.0, tetapi PyTorch berdukungan CUDA untuk aarch64 Blackwell (compute capability sm_121) hanya tersedia di 2.11.0+cu128, sehingga muncul ImportError karena ketidakcocokan ABI
  • Jika 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 berjalan pada percobaan pertama
  • Pengaturan Mac memakan hampir sepanjang sore, sedangkan GB10 memakan sekitar 1 jam termasuk waktu unduh model

Hasil benchmark

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

Analisis kecepatan: mengapa Mac lebih cepat dari perkiraan

  • Dengan llama-bench pada panjang konteks yang sama, Mac mengukur generasi token 5.1x lebih cepat daripada GB10
  • Kedua mesin sama-sama memiliki bandwidth memori 273 GB/s LPDDR5X, sementara 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 parameter per token (sekitar 1.9GB)
    • Pada bandwidth yang sama, Mac mencatat 52 tok/s, GB10 10 tok/s
  • Kecepatan pemrosesan prompt juga lebih baik dari perkiraan di Mac: pada konteks 8K, Mac 531 tok/s vs GB10 548 tok/s, menunjukkan aktivasi sparse MoE juga menguntungkan untuk pemrosesan prompt

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

  • Mac memang 5.1x 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 kali pemanggilan alat vs 3 kali, 5 kali gagal menulis tes, dan dead code yang tidak dibersihkan model
  • Model cloud membuktikannya lebih jelas lagi: paling cepat, penggunaan token paling sedikit, tidak perlu repair pass, dan selesai 5/5 dalam 65 detik
  • Namun, lokal tetap praktis, karena kedua mesin berhasil menghasilkan kode kerja yang lolos tes
  • Lompatan kualitas dari Gemma 3 (tool calling 6.6%) ke Gemma 4 (86.4%) menjadi titik balik utama; transisi dari “tidak bekerja” ke “bekerja” inilah yang membuat agentic coding lokal menjadi praktis
  • Catatan untuk hasil Mac: Q4_K_M adalah kuantisasi tertinggi yang muat di mesin 24GB, dan hasilnya bisa berbeda bila dijalankan ulang dengan kuantisasi lebih tinggi di Apple Silicon yang memorinya lebih lega
  • Pendekatan hibrida juga memungkinkan: gunakan codex --profile local untuk tugas berulang dan sensitif privasi, lalu gunakan default cloud untuk tugas kompleks; sistem profil Codex CLI memungkinkan perpindahan hanya dengan satu flag

Tips praktis saat melakukan pengaturan

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

Bacaan terkait

6 komentar

 
tsboard 6 hari lalu

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 6 hari lalu

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

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

Coba pakai ini sebagai pengganti skill tersebut hehe
 
yangeok 6 hari lalu

Saya juga ingin mengecek apakah bahasa Korea didukung dengan baik.
 
GN⁺ 6 hari lalu
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 5 hari lalu

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.