Gemma 4'ü Codex CLI'da yerel model olarak çalıştırmak

 (blog.danielvaughan.com)
40 puan yazan GN⁺ 16 일 전 | 6 yorum | WhatsApp'ta paylaş
  • Gemma 4'ün bulut yerine yerel Codex CLI ortamında çalıştırılarak araç çağırma performansı ve kararlılığının doğrulandığı bir örnek; GPT-5.4'e kıyasla maliyet ve gizlilik avantajları teyit edildi
  • Mac(M4 Pro) 24GB üzerinde 26B MoE ve NVIDIA GB10 128GB üzerinde 31B Dense ile, sırasıyla llama.cpp ve Ollama kullanılarak aynı kod üretim görevi çalıştırıldı; yapılandırma farklarına göre performans karşılaştırıldı
  • Araç çağırma başarı oranı %6,6'dan %86,4'e yükseldi; bu da yerel modellerin pratikte kullanılabilir olduğunu gösterdi ve GB10 ortamında eksiksiz kod üretimi sağlandı
  • Mac, 5,1 kat daha hızlı token üretim hızı gösterdi; ancak bellek kısıtları ve kuantizasyon ayarları nedeniyle tekrar denemeler gerekti, GB10 ise daha yavaş olsa da ilk denemede başarılı oldu
  • Sonuç olarak yerel modellerle de üretim düzeyinde kod üretimi mümkün; gizlilik odaklı yerel işleme ile karmaşık görevlerde buluta geçişi birleştiren hibrit yaklaşım öneriliyor

Yerel modele geçiş motivasyonu

  • Maliyet nedeniyle, Codex CLI gün içinde birden fazla oturumda, bazen paralel olarak çalıştırıldığında API ücretleri birikiyor
  • Gizlilik gereksinimi nedeniyle, bazı kod tabanları harici sunuculara gönderilmemeli
  • Kararlılık ihtiyacı nedeniyle, bulut API'lerinde hız kısıtlama, kesinti ve fiyat değişikliği riski var
  • Daha önce yerel model denenmemesinin nedeni araç çağırma (tool calling) desteğinin olmamasıydı; oysa Codex CLI'nin asıl değeri modelin dosya okuma, kod yazma, test çalıştırma ve yama uygulama işlemlerini yapabilmesinde yatıyor
  • Önceki Gemma nesli, tau2-bench fonksiyon çağırma kıyaslamasında %6,6 düzeyindeydi (100 denemede 93 başarısızlık); Gemma 4 31B ise %86,4 seviyesine sıçrayarak test edilmeye değer hale geldi

Mac kurulum süreci

  • Başlangıçta Ollama kullanıldı; ancak v0.20.3 sürümünde Gemma 4'ün araç çağırma yanıtları tool_calls dizisi yerine yanlışlıkla reasoning output olarak yönlendirilen bir streaming hatasına takıldı
  • Apple Silicon'da Gemma 4 kullanılırken yaklaşık 500 token'ı aşan istemlerde Flash Attention freeze yaşandı; Codex CLI sistem istemi yaklaşık 27.000 token olduğundan bu pratikte kullanılamaz hale getiriyor
  • Sonrasında llama.cpp'ye geçildi, Homebrew ile kuruldu ve çalışan sunucu komutunun 6 temel bayrağa ihtiyaç duyduğu görüldü
    • -np 1: Yalnızca 1 slot ile sınırlar; çoklu slot kullanımı KV cache belleğini katlayarak artırır
    • -ctk q8_0 -ctv q8_0: KV cache kuantizasyonu ile bellek kullanımı 940MB'den 499MB'ye düştü
    • --jinja: Gemma 4'ün araç çağırma şablonu için zorunlu
    • -m ile GGUF yolunun doğrudan verilmesi gerekiyor; -hf bayrağı kullanıldığında 1,1GB'lık vision projector otomatik indirilip OOM çökmesine yol açıyor
  • Codex CLI yapılandırmasında web_search = "disabled" zorunlu; çünkü Codex CLI, llama.cpp'nin reddettiği web_search_preview araç türünü gönderiyor

GB10 kurulum süreci

  • vLLM 0.19.0, PyTorch 2.10.0 tabanlı derlenmiş durumda; ancak aarch64 Blackwell (compute capability sm_121) için CUDA destekli PyTorch yalnızca 2.11.0+cu128 ile geldiğinden ABI uyuşmazlığı nedeniyle ImportError oluştu
  • llama.cpp CUDA ile kaynak koddan derlendiğinde derleme ve benchmark geçse de, Codex CLI'nin wire_api = "responses" ile gönderdiği fonksiyon dışı araç türleri llama.cpp tarafından reddedildi
  • Başarı Ollama v0.20.5 ile elde edildi; Apple Silicon'da görülen streaming hatası NVIDIA tarafında yeniden oluşmadı
    • ollama pull gemma4:31b çalıştırıldıktan sonra, SSH tüneliyle 11434 portu Mac'e yönlendirildi (çünkü Codex CLI'nin --oss modu yalnızca localhost'u kontrol ediyor)
    • codex --oss -m gemma4:31b ile hem metin üretimi hem araç çağırma ilk denemede çalıştı
  • Mac kurulumu öğleden sonranın büyük kısmını aldı; GB10 ise model indirme bekleme süresi dahil yaklaşık 1 saat sürdü

Benchmark sonuçları

  • Üç yapılandırmanın tamamına aynı görev verildi: codex exec --full-auto ile hata yönetimi içeren parse_csv_summary Python fonksiyonunu yazmak, testleri oluşturmak ve çalıştırmak
  • GPT-5.4 (bulut): tip ipuçları, uygun exception chaining, boolean tür algılama ve temiz yardımcı fonksiyonlar içeren kod üretti; 5 testin tamamı ilk denemede geçti, 65 saniyede tamamlandı ve sonradan temizlik gerekmedi
  • GB10 31B Dense: tip ipuçları veya boolean algılama yoktu ama hata yönetimi sağlamdı, dead code yoktu; 3 araç çağrısıyla 5 test ilk denemede geçti, 7 dakika sürdü
  • Mac 26B MoE: implementasyonda dead code kaldı; tip çıkarım döngüsü yazıp bıraktı, ardından altta Actually, let's simplify yorumuyla yeniden yazdı; test dosyasını yazmak için 5 deneme gerekti
    • Her seferinde farklı heredoc hataları oluştu: filerypt → file_path, encoding=' 'utf-8' (boşluk eklenmiş), fileint(file_path) vb.
    • GB10'un 3 çağrıda bitirdiği iş için 10 araç çağrısı gerekti
    • Bu sonuçlar, 24GB Q4_K_M Codex CLI ortamına ait olup Gemma 4'ün Apple Silicon genel performansı hakkında evrensel bir hüküm anlamına gelmiyor

Hız analizi: Mac neden beklenenden hızlıydı?

  • Aynı bağlam uzunluğunda her iki makine llama-bench ile ölçüldü; Mac'in GB10'dan 5,1 kat daha hızlı token ürettiği görüldü
  • Her iki makinede de 273 GB/s LPDDR5X bellek bant genişliği var; ancak token üretimi bellek bant genişliğiyle sınırlı bir iş yükü
    • 31B Dense, her token için tüm 31,2 milyar parametreyi okuyor (yaklaşık 17,4GB)
    • 26B MoE ise her token'da yalnızca 3,8 milyar parametreyi etkinleştiriyor (yaklaşık 1,9GB)
    • Aynı bant genişliğinde Mac 52 tok/s, GB10 ise 10 tok/s kaydetti
  • İstem işleme hızı da beklentinin aksine Mac lehineydi: 8K bağlamda Mac 531 tok/s, GB10 548 tok/s; MoE'nin seyrek etkinleştirme yapısı istem işlemede de avantaj sağladı

Temel ders: token hızından çok ilk denemede başarı oranı önemli

  • Mac, token üretiminde 5,1 kat hızlı olsa da toplam tamamlanma süresi yalnızca %30 daha kısaydı (4 dakika 42 saniye vs 6 dakika 59 saniye)
  • Zaman farkının nedeni yeniden denemeler oldu: 10 araç çağrısı vs 3, test dosyası yazımında 5 başarısızlık ve modelin temizlemediği dead code
  • Bulut modeli bunu daha da net gösterdi: en hızlısıydı, en az token kullandı, düzeltme geçişi gerektirmedi ve 5/5 testi 65 saniyede tamamladı
  • Buna rağmen yerel kullanım da pratik, çünkü her iki makine de testleri geçen çalışan kod üretebildi
  • Gemma 3'ten (araç çağırma %6,6) Gemma 4'e (%86,4) geçişteki kalite sıçraması asıl dönüm noktası; "çalışmıyor" aşamasından "çalışıyor" aşamasına geçiş, yerel ajan tabanlı kodlamayı pratik hale getiren kırılma oldu
  • Mac sonucu için bir not: Q4_K_M, 24GB makinede belleğe sığan en yüksek kuantizasyondu; daha fazla belleğe sahip Apple Silicon sistemlerde daha yüksek kuantizasyonla yeniden çalıştırıldığında sonuçlar değişebilir
  • Hibrit yaklaşım uygulanabilir: codex --profile local ile tekrar eden ve gizliliğe duyarlı işler yerelde yürütülür, karmaşık görevlerde bulut varsayılanı kullanılır; Codex CLI profil sistemi sayesinde geçiş tek bir bayrakla yapılabiliyor

Kurulum sırasında pratik ipuçları

  • Apple Silicon: Ollama, Gemma 4 ile kullanılamadı; llama.cpp + --jinja öneriliyor
    • Codex CLI profilinde web_search = "disabled" ayarlayın
    • GGUF yolunu -m ile doğrudan verin, -hf kullanmayın
    • Bağlamı 32.768 olarak ayarlayın (Codex CLI sistem istemi için en az 27.000 token gerekiyor)
    • KV cache kuantizasyonu: -ctk q8_0 -ctv q8_0
  • NVIDIA GB10: İlk istikrarlı çalışan yol Ollama v0.20.5 oldu; codex --oss -m gemma4:31b kullanın, uzak makineyse SSH ile 11434 portunu tünelleyin
  • Sağlayıcı ayarlarında stream_idle_timeout_ms değerinin en az 1.800.000 olması gerekiyor; Mac'te tek bir araç çağırma döngüsü 1 dakika 39 saniye sürdüğünden varsayılan timeout ile oturum kapanıyor
  • llama.cpp sürümünü sabitlemek öneriliyor; derlemeler arasında 3,3 kat hız düşüşü bildirildiği için benchmark sonuçları bir gecede değişebilir

İlgili okumalar

6 yorum

 
tsboard 15 일 전

Şirkette 2 adet H100 ile Gemma4-31B’yi çalıştırmayı denedim.

  1. Yanıt kalitesi gayet iyi sayılır ve Türkçe desteği de başarılı.
  2. Araç çalıştırma konusunda karar verme ve çalıştırma sonrası sonuçları düzenleme işini de iyi yapıyor.
  3. Ancak bu, sonuçta 31B parametre dikkate alındığında “şaşırtıcı!” denebilecek bir seviye; doğal olarak daha büyük parametrelere sahip modellerle (ör. MiniMax-M2.5) karşılaştırıldığında yanıtların genel kalitesi gibi konularda geride kaldığı da bir gerçek.

Genel olarak küçük ve hızlı çalışan bir model istiyorsanız Gemma4 yeterli olacaktır. Ben GPT-OSS-120B → Qwen3.5-35B-A3B’ye geçtikten sonra şimdi Gemma4-31B’de karar kıldım ve oldukça memnun kaldım. Muhtemelen kullanmaya devam edeceğim.
 
kaydash 15 일 전

Vay canına, web araması kullanılamıyor mu! Searxng yapılandırsan bile kullanılamıyor mu?
 
yangeok 16 일 전

Korece desteğinin de iyi olup olmadığını kontrol etmek istiyorum.
 
GN⁺ 16 일 전
Hacker News yorumları

  • Gemma 4 26B, aynı parametre ölçeğindeki modeller arasında gerçekten istisnai bir performans gösterdi
    İç benchmark’larda GPT 5.2 ve Gemini 3 Pro Preview’a benzer puanlar aldı, ancak ajan tarzı kodlama ve kod dışı karar verme alanlarında zayıftı
    Tool kullanımı, yinelemeli iyileştirme ve büyük bağlam yönetimi gibi konularda puanı düştü; hatta tool kullanması gereken durumlarda performansı daha da kötüleşti
    Muhtemelen yaygın harness’lere ya da benchmark’lara overfit olmuş gibi görünüyor. Yine de M serisi Macbook’larda hızı etkileyici
    Benchmark’lara gertlabs.com üzerinden bakılabilir

    • Benim ‘hello world’ testimde başarısız oldu
      Sorun, “1 boyutlu bin fitting hesaplayıcısını tek bir web sayfası olarak uygula” idi; Qwen3.5, Nematron, Step 3.5 ve gpt-oss geçti ama Gemma geçemedi
    • Genel olarak iyi bir açık ağırlıklı model
      Yalnız benim M5’imde GPT-OSS’e kıyasla daha sık basit kodlama hataları yaptı. Yine de genel düzey olarak yakın
    • Gemma 31B’nin 26B-A4B’den daha düşük puan alması şaşırtıcıydı

  • “Model kalitesi token hızından daha önemli” sonucuna şaşıranlar olmuş
    Aslında kulağa gayet bariz geliyor. Bağlam boyutunu 32k ile sınırlamak yerine --cpu-moe seçeneğiyle MoE hesaplamasını CPU’ya offload etmek de mümkün

    • Bence token hızı sonuçta sadece işin tamamlanma hızını etkiliyor
    • Yorgunken kahve içmek gibi. Hâlâ yorgunsun ama sadece “daha hızlı” hareket ediyormuşsun gibi geliyor
    • Codex’i her gün kullanan biri olarak bakınca, hızdan çok modelin gereksiz döngülere saplanmaması çok daha önemli
      Sadece token hızı yüksek olursa sonunda ‘AI slop codebase’ patlaması yaşanır

  • Şu anda M3 Ultra’da (48GB RAM) LM Studio ve Opencode ile google/gemma-4-26b-a4b çalıştırıyorum
    Bağlamı 65536’ya çıkarmam gerekti ama iyi çalışıyor. Zed ve ACP ile de kolayca entegre oluyor
    Daha çok basit kod incelemeleri ya da frontend kod üretimi için kullanıyorum

    • Ben de benzer bir kurulumdayım. pi-coding-agent denemeye değer
      Sistem prompt’u ve tool overhead’i 2k token’ın altında olduğu için prefill gecikmesi çok daha kısa
    • AMD RX7900XTX (24GB VRAM) üzerinde aynı anda 4 sohbet çalıştırıp 512K bağlamla kullanıyorum
      Hız yaklaşık 100t/s, neredeyse anlık; bu yüzden Claude Code’u giderek daha az kullanıyorum
    • M1 Macbook’ta MLX sürümünü XCode’a entegre edip denedim ama küçük bir iOS kod tabanında bile yarıda takılıp kaldı
      Chatbot olarak fena değil ama XCode entegrasyonu için uygun değildi
    • Runpod GPU’da 31B tam sürümünü çalıştırdım, etkileyiciydi
      Şu anda Google API üzerinden günde 1500 ücretsiz isteği kullanıyorum
    • M4 Max (64GB) MacBook Pro’da aynı ayarları kullanıyorum
      LM Studio 0.4.11+1 güncellemesinden önce tool calling çalışmıyordu, ama şimdi hem Codex hem Opencode ile sorunsuz

  • “Yerel modellerde tool calling yapılamaz” sözü yanlış
    Zaten 2 yıl önceden beri yerelde tool calling yapıyorduk; Gemma3’ün tool calling başarı oranının %7 olması da mantıksız
    Llama3.3’te bile en az %75 çıkıyordu

    • Ben de o cümleye şaşırdım. Muhtemelen yazar yerel modeli ilk kez çalıştırmış gibi
      Gemma 4 gguf Q4 (16GB) gibi aşırı kuantize edilmiş modellerde performans ciddi biçimde düşüyor
    • Yine de Gemma 3 ile 4 arasındaki Tau function calling benchmark farkının büyük olduğu doğru
    • Yazının tamamı AI tarafından otomatik üretilmiş gibi hissettirdi
      GB10 donanımın varsa spark-vllm-docker kurulumu ya da Qwen 3.5 122B A10B’nin optimize sürümünü denemeni öneririm. Yaklaşık 50tk/s ile epey hızlı

  • M4 Pro’dan (24GB) M5 Pro’ya (48GB) yükselttim; aynı Gemma 4 MoE (Q4) ile t/s değeri 8 kat arttı
    Diskten belleğe yükleme hızı da 2 kat iyileşti

    • RAM’in yeterliyse doğrudan Q8_0 çalıştırmanı öneririm. İlk yükleme dışında yavaş değil ve kalite de neredeyse aynı
      MLX sürümünü kullandığından emin olmak lazım. mlx-lm topluluk kuantizasyon sürümleri yakın zamanda düzeltildi
      Benim için 16GB M1 Macbook’ta zordu ama 64GB RAM’li AMD Framework 13’te sadece CPU ile bile yeterince hızlı çalışıyor
      Prompt cache özelliği, büyük sistem prompt’ları eklerken çok faydalı

  • Yerel donanımı 7/24 çalıştırıp Gemma 4 gibi modellerle deneyleri otomatikleştiren ve büyük kararları Claude Opus’a bırakan bir harness fikri önerildi
    Yapı şöyle: yerel model küçük deneyleri ve POC’leri yapıyor, tıkandığında Opus’tan yardım istiyor
    Böylece prompt cache’i tamamen kontrol etmek mümkün oluyor ve maliyet neredeyse sıfıra iniyor

    • Mario’nun Pi coding agent uzantısının geliştiricisi Nico Bailon da benzer bir şey deniyor
      Demo videosuna ve pi-model-switch deposuna bakılabilir

  • Kodlama için Q6_K altındaki kuantizasyonların pek anlamı yok
    Daha düşük kuantizasyonlarda kod hata oranı keskin biçimde artıyor

    • Bunu çoğu kişi bilmiyor. Token sayısından çok token kalitesi önemli
      Belleğin izin verdiği ölçüde mümkün olan en yüksek kuantizasyonu kullanmak daha iyi

  • Q4_K_M, Q8_0, Q6_K gibi farklı kuantizasyon yöntemlerinin kalite karşılaştırması olsa güzel olurdu. Sadece tok/s sayılarından daha faydalı olurdu

  • Qwen3.5 ile Gemma 4 karşılaştırmasını merak ediyorum
    Özellikle Qwen3.5-27B-Claude-4.6-Opus modeli tool calling için özelleştirilmiş ve 500 binden fazla indirilmiş

    • Jackrong’un yayımladığı fine-tuning rehberine bakıyorum. Notebook örneklerine kadar iyi düzenlenmiş
    • Ben DGX Spark üzerinde bizzat test ettim ama sonunda yine Gemma 4’e döndüm
      Qwen modeli orkestrasyon sırasında sık sık hata düzeltme isteyerek üretkenliği düşürdü
      Ollama ağırlıklarıyla çalıştırdım
    • Bireysel bir geliştiricinin büyük araştırma laboratuvarlarından daha yüksek performans çıkardığı iddiası biraz şüpheli
      En güncel sürüm Qwopus3.5-27B-v3

  • Birkaç gündür Gemma 4 kullanıyorum; hızlı ve akıllı ama tool kullanımı sorunları hâlâ sürüyor
    Hızdan çok zekâ sınırı üretkenliği kısıtlıyor. Sık sık döngüye giriyor
    Böyle durumları algılayıp daha akıllı bir modelden “yardım isteyebilse” iyi olurdu
    Artık kod yazandan çok bir ajan orkestratörü gibi çalışıyorum. Birden fazla ajanı paralel çalıştırıp yöneten roldeyim

    • Google kısa süre önce gemma-4-31B-it için chat_template.jinja ve tokenizer_config.json dosyalarını değiştirdi
      Tool calling ile ilgili sorunları çözdüklerini söylediklerine göre modeli güncellemek iyi bir fikir
 
boolsee 15 일 전

ollama ile yerel LLM kurulumunu yapmak kolay, ancak açık kaynak modellerde araç çağrılarının modelden modele sık sık başarısız olabildiği söyleniyor. Bunun nedeni, ollama içinde gevşek kurallar ile modele özgü araç çağrısı parser sorunlarının iç içe geçmiş olmasıymış.
Asıl mesele ise Local LLM’in en temel sorununun, orta-büyük ölçekli modelleri çalıştırmak için pahalı donanım gerektirmesi olması. 32GB’lık Mac Studio yaklaşık 3 milyon ortası won, GB10 ise yaklaşık 5~6 milyon won seviyesinde olduğundan, bireylerin hobi(?) için satın alması kolay değil. Küçük modeller için Local LLM kullanılabilir, ancak orta-büyük modeller için Cloud dışında pek seçenek yok.