Codex CLI में Gemma 4 को लोकल मॉडल के रूप में चलाना

 (blog.danielvaughan.com)
40 पॉइंट द्वारा GN⁺ 18 일 전 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • Gemma 4 को cloud की जगह लोकल Codex CLI environment में चलाकर tool calling performance और stability को परखा गया, और GPT-5.4 की तुलना में cost और privacy के फायदे की पुष्टि हुई
  • Mac(M4 Pro) 24GB पर 26B MoE और NVIDIA GB10 128GB पर 31B Dense के साथ, क्रमशः llama.cpp और Ollama का उपयोग करके एक ही code generation task चलाया गया, और configuration differences के अनुसार performance की तुलना की गई
  • tool calling success rate 6.6% से बढ़कर 86.4% हो गई, जिससे लोकल मॉडल की व्यावहारिक उपयोगिता साबित हुई, और GB10 environment में पूर्ण code generation हासिल हुआ
  • Mac ने 5.1 गुना तेज token generation speed दिखाई, लेकिन memory constraints और quantization settings की वजह से बार-बार retry की ज़रूरत पड़ी, जबकि GB10 धीमा होने के बावजूद पहली कोशिश में सफल रहा
  • नतीजतन, लोकल मॉडल से भी production-level code generation संभव है, और privacy-focused लोकल processing के साथ complex tasks के लिए cloud पर स्विच करने वाला hybrid approach सुझाया गया है

लोकल मॉडल पर स्विच करने की प्रेरणा

  • cost की समस्या थी, क्योंकि Codex CLI को दिन में कई sessions में, कभी-कभी parallel में चलाने से API cost बढ़ती जा रही थी
  • privacy की ज़रूरत थी, क्योंकि कुछ codebase बाहरी server पर नहीं भेजे जा सकते
  • stability सुनिश्चित करनी थी, क्योंकि cloud API में throttling, outage और pricing changes का risk रहता है
  • पहले लोकल मॉडल इसलिए नहीं आज़माए गए क्योंकि tool calling संभव नहीं थी, जबकि Codex CLI की core value यही है कि मॉडल file पढ़े, code लिखे, test चलाए और patch apply करे
  • Gemma की पिछली generation में tau2-bench function calling benchmark पर 6.6% success था (100 में 93 बार failure), लेकिन Gemma 4 31B ने 86.4% तक छलांग लगाई, जिससे इसे टेस्ट करना सार्थक हो गया

Mac setup process

  • शुरुआत Ollama से हुई, लेकिन v0.20.3 में Gemma 4 की tool calling responses tool_calls array की जगह गलती से reasoning output में route हो रही थीं; यह streaming bug था
  • Apple Silicon पर Gemma 4 इस्तेमाल करते समय लगभग 500 tokens से बड़े prompt पर Flash Attention freeze होता था, और Codex CLI का system prompt लगभग 27,000 tokens का है, इसलिए यह व्यावहारिक रूप से उपयोग लायक नहीं था
  • इसके बाद llama.cpp पर स्विच किया गया, Homebrew से install किया गया, और working server command के लिए 6 critical flags की ज़रूरत पड़ी
    • -np 1: slot को 1 तक सीमित करता है; multiple slots KV cache memory को कई गुना बढ़ा देते हैं
    • -ctk q8_0 -ctv q8_0: KV cache quantization से memory usage 940MB से घटकर 499MB हो गया
    • --jinja: Gemma 4 के tool calling template के लिए अनिवार्य
    • -m में GGUF path सीधे देना ज़रूरी है; -hf flag इस्तेमाल करने पर 1.1GB vision projector अपने-आप download हो जाता है, जिससे OOM crash होता है
  • Codex CLI config में web_search = "disabled" अनिवार्य है, क्योंकि Codex CLI web_search_preview tool type भेजता है जिसे llama.cpp reject कर देता है

GB10 setup process

  • vLLM 0.19.0, PyTorch 2.10.0 के आधार पर compile किया गया है, लेकिन aarch64 Blackwell(compute capability sm_121) के लिए CUDA-supported PyTorch सिर्फ 2.11.0+cu128 है, इसलिए ABI mismatch के कारण ImportError आया
  • llama.cpp को CUDA के साथ source से build करने पर compile और benchmark तो pass हुए, लेकिन Codex CLI का wire_api = "responses" non-function tool types भेजता है जिन्हें llama.cpp reject कर देता है
  • Ollama v0.20.5 में सफलता मिली, और Apple Silicon पर दिखा streaming bug NVIDIA पर reproduce नहीं हुआ
    • ollama pull gemma4:31b चलाने के बाद, SSH tunnel से port 11434 को Mac पर forward किया गया (क्योंकि Codex CLI का --oss mode सिर्फ localhost देखता है)
    • codex --oss -m gemma4:31b के साथ text generation और tool calling दोनों पहली कोशिश में काम कर गए
  • Mac setup में दोपहर का ज़्यादातर समय लग गया, जबकि GB10 पर model download सहित लगभग 1 घंटा लगा

Benchmark results

  • तीनों configurations को एक ही task दिया गया: codex exec --full-auto के साथ parse_csv_summary Python function लिखना, error handling जोड़ना, test लिखना और चलाना
  • GPT-5.4(cloud): type hints, proper exception chaining, boolean type detection और साफ helper functions वाला code बनाया, 5 tests पहली कोशिश में pass हुए, 65 seconds में काम पूरा, बाद में cleanup की ज़रूरत नहीं
  • GB10 31B Dense: type hints या boolean detection नहीं था, लेकिन error handling मजबूत थी, dead code नहीं था, 3 tool calls में 5 tests पहली कोशिश में pass हुए, 7 minutes लगे
  • Mac 26B MoE: implementation में dead code बचा रह गया, type inference loop लिखकर छोड़ दिया गया और नीचे 'Actually, let's simplify' comment के साथ फिर से लिखा गया, test file लिखने में 5 attempts लगे
    • हर बार अलग heredoc error आई: filerypt → file_path, encoding=' 'utf-8'(बीच में space), fileint(file_path) आदि
    • जिस काम को GB10 ने 3 बार में पूरा किया, उसमें 10 tool calls लगे
    • यह परिणाम 24GB Q4_K_M Codex CLI environment का है; इसे पूरे Gemma 4 Apple Silicon behavior पर सामान्य निष्कर्ष नहीं मानना चाहिए

Speed analysis: Mac उम्मीद से तेज क्यों था

  • llama-bench से एक ही context length पर दोनों machines को मापा गया, और Mac की token generation speed GB10 से 5.1 गुना तेज निकली
  • दोनों machines में 273 GB/s LPDDR5X memory bandwidth है, और token generation memory-bandwidth-limited workload है
    • 31B Dense में हर token पर पूरे 31.2 billion parameters पढ़ने पड़ते हैं (लगभग 17.4GB)
    • 26B MoE में हर token पर सिर्फ 3.8 billion parameters active होते हैं (लगभग 1.9GB)
    • समान bandwidth पर Mac ने 52 tok/s और GB10 ने 10 tok/s दर्ज किए
  • prompt processing speed में भी उम्मीद के विपरीत Mac ने अच्छा प्रदर्शन किया: 8K context में Mac 531 tok/s बनाम GB10 548 tok/s, यानी MoE की sparse activation prompt processing में भी फायदेमंद रही

मुख्य सीख: token speed से ज़्यादा अहम है पहली कोशिश की success rate

  • Mac की token generation 5.1 गुना तेज थी, लेकिन final completion time सिर्फ 30% कम हुआ (4 मिनट 42 सेकंड बनाम 6 मिनट 59 सेकंड)
  • समय के अंतर की वजह retry थी: 10 tool calls बनाम 3, test लिखने में 5 failures, और मॉडल द्वारा cleanup न किया गया dead code
  • cloud model ने इसे और स्पष्ट साबित किया: सबसे तेज, token usage सबसे कम, repair pass की ज़रूरत नहीं, 5/5 tests के साथ 65 seconds में completion
  • फिर भी लोकल setup व्यावहारिक है, क्योंकि दोनों machines ने tests pass करने वाला working code बनाया
  • Gemma 3 (tool calling 6.6%) से Gemma 4 (86.4%) तक की quality jump ही असली turning point है; 'काम नहीं करता' से 'काम करता है' तक का यह बदलाव लोकल agentic coding को practical बनाता है
  • Mac result के लिए caveat: Q4_K_M 24GB machine में memory में फिट होने वाली सबसे ऊँची quantization थी; ज़्यादा memory वाले Apple Silicon पर higher quantization के साथ दोबारा चलाने पर नतीजे अलग हो सकते हैं
  • hybrid approach संभव है: codex --profile local से repetitive और privacy-sensitive tasks संभालें, और complex tasks के लिए default cloud model रखें; Codex CLI की profile system में switch करना सिर्फ एक flag का काम है

Setup के समय काम की tips

  • Apple Silicon: Gemma 4 के साथ Ollama काम नहीं कर सका; llama.cpp + --jinja recommended है
    • Codex CLI profile में web_search = "disabled" सेट करें
    • -m से GGUF path सीधे दें, -hf का इस्तेमाल न करें
    • context 32,768 रखें (Codex CLI system prompt के लिए कम-से-कम 27,000 tokens चाहिए)
    • KV cache quantization: -ctk q8_0 -ctv q8_0
  • NVIDIA GB10: Ollama v0.20.5 पहला stable working path था; codex --oss -m gemma4:31b इस्तेमाल करें, और remote machine होने पर SSH से port 11434 tunnel करें
  • provider settings में stream_idle_timeout_ms को कम-से-कम 1,800,000 पर सेट करना ज़रूरी है, क्योंकि Mac पर एक tool calling cycle में 1 मिनट 39 सेकंड लगे और default timeout में session खत्म हो गया
  • llama.cpp का version pin करना recommended है, क्योंकि builds के बीच 3.3 गुना speed drop report हुआ है, जिससे benchmark overnight बदल सकते हैं

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.