macOS पर लोकल coding agent सेट अप करने का तरीका

 (ikyle.me)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • लोकल coding agent कॉन्फ़िगरेशन ऐसा सेटअप है जिसमें इंटरनेट बाधित होने पर भी macOS पर OpenAI-compatible API के जरिए मॉडल चलाया जा सके और Pi पर text व image input प्रोसेस हो सके
  • Apple M1 Max 64GB, macOS 15.7.7 पर llama.cpp Metal और Gemma 4 26B-A4B GGUF मॉडल का उपयोग किया गया, और डिफ़ॉल्ट generation speed 58.2 tok/s थी
  • MTP draft model जोड़ने और --spec-draft-n-max 3 पर ट्यून करने के बाद generation speed 72.2 tok/s तक बढ़ी, यानी लगभग 24% सुधार
  • mmproj-BF16.gguf को --mmproj से लोड करना और Pi model input को ["text", "image"] पर सेट करना ज़रूरी है, तभी screenshot जैसे image input पास होते हैं
  • अंतिम कॉन्फ़िगरेशन में llama.cpp server 127.0.0.1:8080/v1 पर चलता है और Pi इसे लोकल provider की तरह उपयोग करता है; Qwen3.6 35B-A3B ने coding agent benchmark में बेहतर प्रदर्शन दिखाया, लेकिन इस टेस्ट में 55 tok/s पर अधिक धीमा रहा

लोकल coding agent कॉन्फ़िगरेशन का लक्ष्य

  • इंटरनेट बाधित होने की कुछ घटनाओं के कारण coding agent का उपयोग न कर पाने की स्थिति ने लोकल रनिंग सेटअप आज़माने की प्रेरणा दी
  • चाही गई कॉन्फ़िगरेशन ऐसी थी जो Mac पर वास्तव में उपयोग लायक तेज़ हो और OpenAI-compatible API के माध्यम से दूसरे tools में भी इस्तेमाल की जा सके
  • ज़रूरत पड़ने पर screenshot या image प्रोसेस करके agent द्वारा बनाए गए आउटपुट को फिर से input के रूप में देने वाला सेटअप लक्ष्य था
  • अंतिम कॉन्फ़िगरेशन llama.cpp, Gemma 4 26B-A4B GGUF, Q8 MTP draft model, Gemma 4 multimodal projector, और Pi terminal coding agent से बनी
  • टेस्ट environment Apple M1 Max, 64GB unified memory, और macOS 15.7.7 था

मॉडल

  • मुख्य मॉडल gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf था, जो Hugging Face के unsloth-gemma-4-26B-A4B-it-GGUF repository में है
  • इस फ़ाइल का आकार लगभग 16GB है, और MTP draft head व multimodal projector को साथ रखने पर model folder लगभग 17GB का हो जाता है
  • benchmark prompt था: Write a compact Python function that parses a unified diff and returns the changed file paths. Then explain two edge cases.
  • हर benchmark लगभग 128 token generate करता है

बेसिक रन: llama.cpp + Metal

  • मुख्य मॉडल को llama.cpp और Metal acceleration के साथ सीधे चलाया गया
  • रन कमांड में llama-cli के साथ model path, -ngl 999, -fa on, -c 4096, -n 128 दिए गए
  • बेसिक कॉन्फ़िगरेशन में prompt processing speed 298.0 tok/s और generation speed 58.2 tok/s थी
  • 58 tok/s बहुत तेज़ नहीं है, लेकिन उपयोग लायक है; coding agent workloads में कई tool calls के कारण जितनी हो सके उतनी speed चाहिए

MTP draft model जोड़ना

  • Gemma 4 के लिए MTP/gemma-4-26B-A4B-it-Q8_0-MTP.gguf रूप में MTP draft model उपलब्ध है
  • llama.cpp में इसे speculative decoding के लिए --model-draft, --spec-type draft-mtp, --spec-draft-n-max के साथ लोड किया जाता है
  • MTP की पहली रन में 4 draft token पर 69.2 tok/s मिला
  • Unsloth documentation --spec-draft-n-max 2 को शुरुआती बिंदु के रूप में सुझाती है, लेकिन 1 से 6 तक hardware के अनुसार टेस्ट करके सबसे तेज़ मान चुनने को कहती है
  • --spec-draft-n-max ट्यून करने पर 3 draft token पर 72.2 tok/s सबसे तेज़ मिला
  • सिर्फ main model पर 58.2 tok/s था, जबकि Q8 MTP draft model जोड़ने पर 72.2 tok/s मिला
  • prompt processing speed लगभग बनी रही और generation speed में लगभग 24% सुधार हुआ

MTP tuning परिणाम

  • --spec-draft-n-max के 1 से 6 तक मान टेस्ट किए गए
  • मान 1 पर prompt 295.5 tok/s और generation 68.4 tok/s था
  • मान 2 पर prompt 299.1 tok/s और generation 72.0 tok/s था
  • मान 3 पर prompt 295.6 tok/s और generation 72.2 tok/s था, जो सबसे तेज़ था
  • मान 4 पर generation 70.7 tok/s, मान 5 पर 63.7 tok/s, और मान 6 पर 61.2 tok/s तक धीमा हो गया
  • M1 Max environment में 3 सबसे तेज़ था, और 2 भी काफ़ी नज़दीकी परिणाम देता था

MLX तुलना

  • Mac पर मॉडल चलाने का कोई और तेज़ तरीका है या नहीं, यह देखने के लिए mlx-lm आधारित MLX मॉडल भी टेस्ट किए गए
  • llama.cpp Metal + MTP ने Unsloth GGUF Q4 और Q8 MTP संयोजन पर 72.2 tok/s रिकॉर्ड किया
  • सिर्फ llama.cpp Metal ने Unsloth GGUF Q4 पर 58.2 tok/s रिकॉर्ड किया
  • MLX-LM ने Unsloth UD MLX 4-bit पर 45.8 tok/s रिकॉर्ड किया
  • MLX-LM ने mlx-community 4-bit पर 43.9 tok/s और mlx-community OptiQ 4-bit पर 38.1 tok/s रिकॉर्ड किया
  • इस विशेष कॉन्फ़िगरेशन में llama.cpp MLX से तेज़ था, और MTP वाला llama.cpp सबसे अच्छा विकल्प रहा
  • gemma-4-swift-mlx के साथ Gemma 4 MTP भी आज़माया गया, लेकिन टेस्ट किए गए 26B 4-bit MLX checkpoint का loader द्वारा अपेक्षित weight key से मेल न खाने के कारण, नया मॉडल दोबारा डाउनलोड और ट्यून किए बिना इसे रोक दिया गया

image support जोड़ना

  • Pi में screenshot attach करने के लिए model input सिर्फ text नहीं हो सकता
  • मूल लोकल model entry "input": ["text"] पर सेट थी, और इस स्थिति में Pi image tool output को मॉडल तक सही तरह नहीं भेज पाता था
  • multimodal क्षमता के लिए llama.cpp server को Gemma 4 multimodal projector mmproj-BF16.gguf भी चाहिए
  • projector को --mmproj के साथ लोड करने पर llama.cpp multimodal support घोषित करता है और Pi images भेज सकता है
  • projector के बिना llama.cpp Metal + MTP चलाने वाले टेस्ट में prompt 120.3 tok/s और generation 71.4 tok/s थी
  • mmproj-BF16.gguf लोड करने वाली अंतिम रन में prompt 297.4 tok/s और generation 72.2 tok/s थी
  • projector लोड करने वाली अंतिम रन में text generation speed में कोई गिरावट नहीं दिखी

llama.cpp इंस्टॉल करना

  • dependencies के लिए Homebrew से cmake, git, tmux, python@3.11 इंस्टॉल किए गए
  • ~/Developer/ML-Models/Gemma4/repos path बनाया गया और ggml-org/llama.cpp repository को repos/llama.cpp में clone किया गया
  • build को cmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_METAL=ON -DGGML_ACCELERATE=ON से configure किया गया
  • इसके बाद cmake --build build --config Release -j से release build किया गया
  • टेस्ट की गई build में GGML_METAL=ON, GGML_ACCELERATE=ON, GGML_BLAS=ON, GGML_BLAS_VENDOR=Apple सेटिंग्स थीं

model files डाउनलोड

  • Python 3.11 virtual environment बनाया गया और huggingface_hub व hf_xet इंस्टॉल किए गए
  • huggingface-cli download से Gemma 4 main model, mmproj-BF16.gguf, और MTP draft model डाउनलोड किए गए
  • डाउनलोड की जाने वाली target files थीं gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf, mmproj-BF16.gguf, MTP/gemma-4-26B-A4B-it-Q8_0-MTP.gguf
  • अंतिम model folder models/unsloth-gemma-4-26B-A4B-it-GGUF/ के भीतर इन तीन फ़ाइलों को रखता है

लोकल server शुरू करना

  • अंतिम server को llama-server से चलाया जाता है, जिसमें main model, MTP draft model, और multimodal projector तीनों निर्दिष्ट होते हैं
  • मुख्य options हैं --spec-type draft-mtp, --spec-draft-n-max 3, -ngl 999, -fa on, -c 65536, --parallel 1
  • server को --host 127.0.0.1 --port 8080 के साथ चलाया जाता है
  • OpenAI-compatible endpoint http://127.0.0.1:8080/v1 है
  • start_server.sh wrapper tmux session में server चलाता है और logs को logs/llama-server-mtp.log में लिखता है
  • chmod +x start_server.sh के बाद ./start_server.sh से server शुरू किया जाता है
  • server के काम करने की पुष्टि curl http://127.0.0.1:8080/v1/models से की जाती है

Pi कॉन्फ़िगरेशन

  • Pi model provider settings को ~/.pi/agent/models.json से पढ़ता है
  • लोकल provider gemma4-local का baseUrl http://127.0.0.1:8080/v1 की ओर इशारा करता है
  • api को openai-completions रखा जाता है, और लोकल server होने के कारण authHeader को false पर रखा जाता है
  • model ID gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf है, और नाम Gemma 4 26B-A4B Q4 + MTP रखा जाता है
  • input का ["text", "image"] होना ज़रूरी है, नहीं तो Pi मॉडल को text-only मानता है
  • context window 65536 और max tokens 8192 पर सेट किए जाते हैं
  • ज़रूरत हो तो ~/.pi/agent/settings.json में defaultProvider को gemma4-local और defaultModel को संबंधित GGUF फ़ाइलनाम पर सेट किया जा सकता है
  • pi --offline --list-models gemma चलाने पर image support yes के रूप में दिखने की अपेक्षा है
  • लोकल मॉडल रन pi --provider gemma4-local --model gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf से किया जाता है
  • non-interactive रन pi -p --provider gemma4-local --model gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf "Explain what this repository does" के रूप में किया जाता है
  • screenshot input pi -p @"/path/to/screenshot.png" "Describe this image and point out anything relevant to the UI" के रूप में दिया जाता है

अंतिम कॉन्फ़िगरेशन

  • अंतिम inference runtime llama.cpp है
  • macOS acceleration Metal + Accelerate संयोजन है
  • main model gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf है
  • draft model gemma-4-26B-A4B-it-Q8_0-MTP.gguf है
  • MTP setting --spec-draft-n-max 3 है
  • multimodal projector mmproj-BF16.gguf है
  • server 127.0.0.1:8080 पर चलने वाला llama-server है
  • API OpenAI-compatible /v1 है
  • coding agent Pi है, और Pi model input ["text", "image"] है
  • इस environment में MTP draft model ने Gemma 4 generation speed को 58.2 tok/s से 72.2 tok/s तक बढ़ाया, और सेटअप इतना सरल है कि इसे लोकल OpenAI-compatible server की तरह चलाया जा सके

Qwen3.6 35B-A3B विकल्प

  • कुछ लोगों ने Gemma 4 26B-A4B की जगह Qwen3.6 35B-A3B उपयोग करने का सुझाव दिया
  • सत्यापित किए जा सकने वाले benchmarks के आधार पर Qwen को Gemma 4 से कहीं बेहतर coding agent माना गया
  • लेकिन Qwen कॉन्फ़िगरेशन अधिक धीमी रही, और Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf, unsloth-Qwen3.6-35B-A3B-MTP-GGUF, mmproj-BF16.gguf संयोजन पर 55 tok/s रिकॉर्ड हुआ
  • 72 tok/s की तुलना में 55 tok/s, उपयोगकर्ता के इंतज़ार की स्थिति में काफ़ी बड़ा अंतर बनता है
  • Qwen model डाउनलोड unsloth/Qwen3.6-35B-A3B-MTP-GGUF से Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf और mmproj-BF16.gguf लेने के रूप में किया जाता है
  • Qwen server वही llama-server उपयोग करता है, लेकिन --port 8081 पर चलता है
  • Pi कॉन्फ़िगरेशन में Qwen provider का नाम qwen36-local और baseUrl http://127.0.0.1:8081/v1 होता है
  • Qwen model setting में reasoning: true, input: ["text", "image"], contextWindow: 65536, maxTokens: 8192 का उपयोग होता है

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

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • बेंचमार्क प्रॉम्प्ट था: “unified diff को parse करके बदली गई फ़ाइल paths लौटाने वाला एक संक्षिप्त Python function लिखो, और दो edge cases समझाओ”, और अगर हर बेंचमार्क ने लगभग 128 tokens generate किए, तो अच्छे नतीजे पाने के लिए 128 tokens बहुत कम लगते हैं
    MTP acceleration इस बात पर निर्भर करती है कि predicted tokens कितनी बार accept होते हैं, और अनुभव से आउटपुट के शुरुआती हिस्से में acceptance rate ज़्यादा होता है, इसलिए छोटे tests false positive acceleration पैदा कर सकते हैं
    llama.cpp में benchmarking के लिए एक dedicated tool है जो server restart किए बिना और prompt भेजे बिना arguments को sweep करता है: https://github.com/ggml-org/llama.cpp/blob/master/tools/llam...
    model download section में यह भी बताना चाहिए था कि llama.cpp का -hf argument model को अपने-आप download कर देता है। लेखक ने अपना अनुभव साझा किया, यह अच्छी बात है, लेकिन beginners के लिए यह सबसे अच्छा guide नहीं हो सकता

    • यह कोई ठीक-ठाक developer guide के रूप में लिखा गया लेख नहीं था। screen recording को बहुत bookmarks मिले और setup कैसे करें यह पूछने वाले messages आने लगे, इसलिए मैंने जल्दी से लिख दिया कि यह test कैसे configure किया था
      Unclothe की “2x speed” announcement देखकर लगा, “क्या अब यह इतना तेज़ है कि सच में इस्तेमाल किया जा सके?” इसलिए मैंने खुद setup करके देखा
      पिछले साल भी Devstral जैसी चीज़ों से test किया था, लेकिन वह बहुत slow और बेवकूफ़ लगी, इसलिए आगे इस्तेमाल करने का मन नहीं हुआ। इस बार पहली बार लगा कि speed और intelligence दोनों में यह काम लायक स्तर पर पहुँच गया है
    • व्यवहारिक रूप से, random user prompt के साथ पर्याप्त system prompt भी जोड़कर experiment करना चाहिए। कम से कम 1000 tokens, और वास्तव में करीब 3000 tokens बेहतर लगते हैं
      llama.cpp में इसके लिए tool है, और ठीक से measure करने के लिए token generation से पहले prefill डालना चाहिए। अब 32k या 64k जैसे लंबे context में token generation speed मापना भी ज़्यादा महत्वपूर्ण होता जा रहा है
    • 128 tokens पर benchmark करना opera नहीं, सिर्फ overture को benchmark करने जैसा है
    • यह बिना असली समस्या देखे “मेरे कंप्यूटर पर तो चलता है” कहने जैसा है। 128 tokens सच में कुछ भी नहीं हैं, बस छोटे greeting response से थोड़ा ही ज़्यादा

  • मैंने पहले ollama और opencode का इस्तेमाल करके ऐसा ही एक लेख लिखा था: https://blog.kulman.sk/running-local-llm-coding-server/

    • Ollama अच्छा विकल्प नहीं है: https://sleepingrobots.com/dreams/stop-using-ollama/
      क्या opencode का system prompt context बहुत ज़्यादा नहीं खा जाता? local models में context limitation काफ़ी बड़ी होती है, और याद है कि opencode उनमें से लगभग 10k या उसके आसपास इस्तेमाल कर लेता है
    • यह सच में उपयोगी है, और ollama GUI इस्तेमाल करें तो शायद इसे और भी सरल बनाया जा सकता है

  • अगर आप सिर्फ llama.cpp इस्तेमाल कर रहे हैं, तो कुछ download करने के लिए huggingface-cli ज़रूरी नहीं लगता। -hf ... देने पर यह model download कर देता है
    download location बदलने के लिए LLAMA_CACHE set कर सकते हैं:
    LLAMA_CACHE="models" ./llama-server \\
    -hf unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL \\
    ...

    • draft model के लिए -hfd इस्तेमाल कर सकते हैं

  • अगर unified memory RAM बड़ी है लेकिन teraflops और bandwidth GB/s औसत या उससे कम हैं, तो आम तौर पर MoE सबसे उम्मीद वाला विकल्प होता है। मेरे setup, M2 Max 96GB, पर (intelligence, tok/s, context depth) के हिसाब से अभी नंबर 1 DeepSeek-V4-Flash REAP25 <65gb gguf + ds4-server + pi agent है
    बेशक यह cloud API से बेहतर नहीं है, लेकिन ज़रूरत पड़े तो समझौते के साथ इस्तेमाल करने लायक है। इंटरनेट के बिना 4 घंटे की फ़्लाइट में भी local LLM 60W खपत के बावजूद battery काफ़ी चली
    REAP support वाला ds4 branch यहाँ है: https://github.com/ljubomirj/ds4/tree/reap-compact-support
    DS4F का 784K context तक ही 10 tok/s से नीचे, यानी लगभग अनुपयोगी स्तर, पर गिरना बड़ा फ़र्क पैदा करता है

  • जिज्ञासा है कि क्या ऐसे local models उन users की भी सच में मदद कर सकते हैं जो किसी खास programming language के expert नहीं हैं
    inline autocomplete या unit implementation से आगे बढ़कर, क्या वे सचमुच काम करने वाली technical specifications डिज़ाइन और जोड़ सकते हैं, इस पर भरोसा नहीं है

  • llama.cpp/server का इस्तेमाल करके local LLM चलाना और उसे Claude Code या Codex-CLI के साथ जोड़ना काफ़ी आसान है
    ज़रूरी llama server settings अक्सर इधर-उधर बिखरी रहती हैं, इसलिए कुछ लोकप्रिय open LLMs के लिए निर्देश मैं यहाँ maintain करता हूँ: https://pchalasani.github.io/claude-code-tools/integrations/...

    • क्या आप उसे रोज़मर्रा के इस्तेमाल में चला रहे हैं? Claude Code का prompt बहुत बड़ा होता है, इसलिए local models में prompt processing में बहुत समय लगता है, और थोड़ी देर में पूरा context भी भर जाता है

  • मैंने omlx.ai का इस्तेमाल करके अपने hardware के हिसाब से कई MLX models download किए हैं, और उन models के साथ open-source और closed harnesses (Claude Code, Codex) को auto-run कराने में काफ़ी सफलता मिली है
    यह web और desktop UI दोनों में संभव है, इसलिए मुझे व्यक्तिगत रूप से लगता है कि omlx इस्तेमाल करें तो blog post follow करने की ज़रूरत नहीं पड़ती

    • 64GB M1 Max पर मुझे oMLX या MLX का llama.cpp के GGUF की तुलना में कोई खास फ़ायदा नहीं दिखा
      अभी तक जो Gemma 4 MLX builds मिले, वे same quantization पर ज़्यादा slow थे, और MTP में तो काफ़ी ज़्यादा slow थे
      model चुन लेने के बाद llama.cpp का built-in web UI काफ़ी अच्छा है, और अलग-अलग चीज़ें आज़माने के लिए LM Studio भी ठीक है
      Gemma-4 और Qwen 3.6 को सामान्य opencode system prompt का बड़ा हिस्सा बिल्कुल नहीं चाहिए, और उसे हटाना बेहतर है
    • अगर आप oMLX और Pi से जोड़ने के लिए sandbox ढूँढ रहे हैं, तो यह है: https://github.com/Dotnaught/pi-sandbox
    • मेरे हिसाब से Mac पर local inference के लिए यही state of the art है। regression आ भी जाए तो developers बहुत तेज़ी से respond करते हैं, और हाल में देखे open-source projects में यह सबसे प्रभावशाली है

  • antirez के ds4 पर चलने वाला DeepSeek v4 Flash काफ़ी प्रभावशाली लगा
    “stored knowledge” के लिहाज़ से यह GPT-4 class model जैसा महसूस होता है, लेकिन लंबे flow वाले tool calling में यह GPT-4 class models से भी बेहतर है
    128GB MBP M4 Max पर generation लगभग 24 t/s और prefill लगभग 200 t/s मिलता है। उम्मीद थी कि यह धीमा होगा, और code generation जैसे कामों में यह सच में धीमा है, लेकिन सरल tasks के लिए machine orchestrator के रूप में यह चौंकाने वाली तरह से उपयोगी है
    non-agentic use cases में यह बातचीत के लिए भी काफ़ी अच्छा model है, और पूरी तरह self-hosted व private होने का फ़ायदा भी है
    [0]https://github.com/antirez/ds4

  • अगर बहुत आलसी तरीका चाहिए, तो terminal में Claude Code खोलिए, इस लेख की ओर इशारा कीजिए, और बस कहिए, “कर दो”

    • अब मैं लगभग Google search का इस्तेमाल नहीं करता। 10 में से 9 बार information quality बहुत ख़राब होती है, और चारों तरफ़ के spam में ज़रूरी चीज़ छाँटना मुश्किल होता है
      जबकि Claude अक्सर एक ही बार में, या बहुत थोड़ी editing के बाद, काम कर देता है
      knowledge और execution तक पहुँचने का gateway अब LLM है, और Google Search किसी dinosaur जैसा लगता है
      smartphone से भी ज़्यादा प्रभावशाली, जैसे हम एक सदी भविष्य में आ गए हों