Cara menyiapkan agen coding lokal di macOS

 (ikyle.me)
1 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Konfigurasi agen coding lokal ini memungkinkan model berjalan di macOS melalui API yang kompatibel dengan OpenAI bahkan saat internet bermasalah, serta membuat Pi dapat menangani input teks dan gambar
  • Pengujian dilakukan pada Apple M1 Max 64GB dan macOS 15.7.7 menggunakan llama.cpp Metal serta model Gemma 4 26B-A4B GGUF, dengan kecepatan generasi dasar 58.2 tok/s
  • Setelah menambahkan MTP draft model dan menyetel --spec-draft-n-max 3, kecepatan generasi naik menjadi 72.2 tok/s, sekitar 24% lebih cepat
  • Agar input gambar seperti tangkapan layar dapat diteruskan, mmproj-BF16.gguf harus dimuat dengan --mmproj dan input model Pi harus disetel ke ["text", "image"]
  • Konfigurasi akhirnya menjalankan server llama.cpp di 127.0.0.1:8080/v1 dan Pi menggunakannya sebagai penyedia lokal; Qwen3.6 35B-A3B menunjukkan benchmark agen coding yang lebih baik, tetapi dalam pengujian ini lebih lambat di 55 tok/s

Tujuan konfigurasi agen coding lokal

  • Beberapa gangguan internet yang membuat agen coding tidak bisa dipakai menjadi pemicu untuk mencoba konfigurasi yang berjalan secara lokal
  • Konfigurasi yang diinginkan harus cukup cepat untuk benar-benar dipakai di Mac, dan juga harus bisa digunakan oleh alat lain melalui API yang kompatibel dengan OpenAI
  • Tujuannya adalah menyiapkan sistem yang bisa memproses tangkapan layar atau gambar saat diperlukan, sehingga hasil yang dibuat agen dapat diberikan kembali sebagai input
  • Konfigurasi akhir terdiri dari llama.cpp, Gemma 4 26B-A4B GGUF, Q8 MTP draft model, Gemma 4 multimodal projector, dan agen coding terminal Pi
  • Lingkungan pengujian adalah Apple M1 Max, unified memory 64GB, dan macOS 15.7.7

Model

  • Model utama adalah gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf, yang tersedia di repositori Hugging Face unsloth-gemma-4-26B-A4B-it-GGUF
  • Ukuran file tersebut sekitar 16GB, dan bila MTP draft head serta multimodal projector ditempatkan bersama, folder model menjadi sekitar 17GB
  • Prompt benchmark yang digunakan adalah Write a compact Python function that parses a unified diff and returns the changed file paths. Then explain two edge cases.
  • Setiap benchmark menghasilkan sekitar 128 token

Menjalankan dasar: llama.cpp + Metal

  • Model utama dijalankan langsung dengan llama.cpp dan akselerasi Metal
  • Perintah eksekusi menggunakan llama-cli dengan path model, -ngl 999, -fa on, -c 4096, dan -n 128
  • Pada konfigurasi dasar, kecepatan pemrosesan prompt adalah 298.0 tok/s dan kecepatan generasi adalah 58.2 tok/s
  • 58 tok/s memang tidak terlalu cepat, tetapi masih berada pada tingkat yang dapat dipakai; untuk tugas agen coding, kecepatan setinggi mungkin diperlukan karena banyak pemanggilan alat

Menambahkan MTP draft model

  • Gemma 4 menyediakan MTP draft model dalam bentuk MTP/gemma-4-26B-A4B-it-Q8_0-MTP.gguf
  • Di llama.cpp, model ini dimuat untuk speculative decoding menggunakan --model-draft, --spec-type draft-mtp, dan --spec-draft-n-max
  • Pengujian pertama MTP mencatat 69.2 tok/s pada 4 draft token
  • Dokumentasi Unsloth merekomendasikan --spec-draft-n-max 2 sebagai titik awal, tetapi menyarankan pengujian dari 1 sampai 6 pada setiap perangkat keras untuk menemukan nilai tercepat
  • Setelah penyetelan --spec-draft-n-max, hasil tercepat adalah 72.2 tok/s pada 3 draft token
  • Model utama saja menghasilkan 58.2 tok/s, sementara konfigurasi dengan Q8 MTP draft model mencapai 72.2 tok/s
  • Kecepatan pemrosesan prompt hampir tidak berubah, sementara kecepatan generasi meningkat sekitar 24%

Hasil tuning MTP

  • Nilai --spec-draft-n-max dari 1 hingga 6 diuji
  • Nilai 1 menghasilkan prompt 295.5 tok/s dan generasi 68.4 tok/s
  • Nilai 2 menghasilkan prompt 299.1 tok/s dan generasi 72.0 tok/s
  • Nilai 3 adalah yang tercepat dengan prompt 295.6 tok/s dan generasi 72.2 tok/s
  • Nilai 4 menghasilkan generasi 70.7 tok/s, nilai 5 menghasilkan 63.7 tok/s, dan nilai 6 turun ke 61.2 tok/s
  • Pada lingkungan M1 Max, 3 adalah yang tercepat, dan 2 juga memberikan hasil yang sangat dekat

Perbandingan MLX

  • Untuk melihat cara yang mungkin lebih cepat menjalankan model di Mac, model MLX berbasis mlx-lm juga diuji
  • llama.cpp Metal + MTP mencatat 72.2 tok/s dengan kombinasi Unsloth GGUF Q4 dan Q8 MTP
  • llama.cpp Metal saja mencatat 58.2 tok/s pada Unsloth GGUF Q4
  • MLX-LM mencatat 45.8 tok/s pada Unsloth UD MLX 4-bit
  • MLX-LM mencatat 43.9 tok/s pada mlx-community 4-bit, dan 38.1 tok/s pada mlx-community OptiQ 4-bit
  • Dalam konfigurasi khusus ini, llama.cpp lebih cepat daripada MLX, dan llama.cpp dengan MTP menjadi pilihan terbaik
  • Gemma 4 MTP juga sempat dicoba dengan gemma-4-swift-mlx, tetapi checkpoint MLX 26B 4-bit yang diuji tidak cocok dengan weight key yang diharapkan loader, sehingga percobaan dihentikan tanpa mengunduh ulang dan menyesuaikan model baru

Menambahkan dukungan gambar

  • Agar tangkapan layar bisa dilampirkan dari Pi, input model tidak boleh hanya teks
  • Awalnya entri model lokal disetel ke "input": ["text"], dan dalam kondisi ini Pi tidak dapat mengirim output alat gambar ke model dengan benar
  • Server llama.cpp juga membutuhkan Gemma 4 multimodal projector mmproj-BF16.gguf untuk fungsi multimodal
  • Jika projector dimuat dengan --mmproj, llama.cpp akan mengiklankan dukungan multimodal dan Pi dapat mengirim gambar
  • Pengujian llama.cpp Metal + MTP tanpa projector menghasilkan prompt 120.3 tok/s dan generasi 71.4 tok/s
  • Eksekusi akhir dengan mmproj-BF16.gguf dimuat menghasilkan prompt 297.4 tok/s dan generasi 72.2 tok/s
  • Tidak terlihat penurunan kecepatan generasi teks pada eksekusi akhir saat projector dimuat

Instalasi llama.cpp

  • Dependensi cmake, git, tmux, dan python@3.11 dipasang dengan Homebrew
  • Path ~/Developer/ML-Models/Gemma4/repos dibuat, lalu repositori ggml-org/llama.cpp di-clone ke repos/llama.cpp
  • Build dikonfigurasi dengan cmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_METAL=ON -DGGML_ACCELERATE=ON
  • Setelah itu, build rilis dijalankan dengan cmake --build build --config Release -j
  • Build yang diuji menggunakan pengaturan GGML_METAL=ON, GGML_ACCELERATE=ON, GGML_BLAS=ON, GGML_BLAS_VENDOR=Apple

Mengunduh file model

  • Virtual environment Python 3.11 dibuat, lalu huggingface_hub dan hf_xet dipasang
  • huggingface-cli download digunakan untuk mengunduh model utama Gemma 4, mmproj-BF16.gguf, dan MTP draft model
  • File yang diunduh adalah gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf, mmproj-BF16.gguf, dan MTP/gemma-4-26B-A4B-it-Q8_0-MTP.gguf
  • Folder model akhir berisi ketiga file tersebut di bawah models/unsloth-gemma-4-26B-A4B-it-GGUF/

Menjalankan server lokal

  • Server akhir dijalankan dengan llama-server, dengan model utama, MTP draft model, dan multimodal projector semuanya ditentukan
  • Opsi pentingnya adalah --spec-type draft-mtp, --spec-draft-n-max 3, -ngl 999, -fa on, -c 65536, dan --parallel 1
  • Server dijalankan dengan --host 127.0.0.1 --port 8080
  • Endpoint yang kompatibel dengan OpenAI adalah http://127.0.0.1:8080/v1
  • Wrapper start_server.sh menjalankan server dalam sesi tmux dan menyimpan log ke logs/llama-server-mtp.log
  • Setelah chmod +x start_server.sh, server dijalankan dengan ./start_server.sh
  • Untuk memeriksa apakah server berjalan, gunakan curl http://127.0.0.1:8080/v1/models

Konfigurasi Pi

  • Pi membaca konfigurasi penyedia model dari ~/.pi/agent/models.json
  • baseUrl penyedia lokal gemma4-local mengarah ke http://127.0.0.1:8080/v1
  • api adalah openai-completions, dan karena ini server lokal, authHeader disetel ke false
  • ID model adalah gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf, dan namanya disetel ke Gemma 4 26B-A4B Q4 + MTP
  • input harus ["text", "image"]; jika tidak, Pi akan memperlakukan model sebagai teks saja
  • Context window disetel ke 65536, dan token maksimum disetel ke 8192
  • Jika perlu, di ~/.pi/agent/settings.json, defaultProvider dapat disetel ke gemma4-local dan defaultModel ke nama file GGUF tersebut
  • Saat menjalankan pi --offline --list-models gemma, hasil yang diharapkan adalah dukungan gambar ditampilkan sebagai yes
  • Menjalankan model lokal dilakukan dengan pi --provider gemma4-local --model gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf
  • Eksekusi noninteraktif dilakukan dalam bentuk pi -p --provider gemma4-local --model gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf "Explain what this repository does"
  • Input tangkapan layar dilakukan dalam bentuk pi -p @"/path/to/screenshot.png" "Describe this image and point out anything relevant to the UI"

Konfigurasi akhir

  • Runtime inferensi akhirnya adalah llama.cpp
  • Akselerasi macOS menggunakan kombinasi Metal + Accelerate
  • Model utamanya adalah gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf
  • Draft model-nya adalah gemma-4-26B-A4B-it-Q8_0-MTP.gguf
  • Pengaturan MTP adalah --spec-draft-n-max 3
  • Multimodal projector-nya adalah mmproj-BF16.gguf
  • Server-nya adalah llama-server di 127.0.0.1:8080
  • API-nya adalah /v1 yang kompatibel dengan OpenAI
  • Agen coding-nya adalah Pi, dan input model Pi adalah ["text", "image"]
  • Dalam lingkungan ini, MTP draft model meningkatkan kecepatan generasi Gemma 4 dari 58.2 tok/s menjadi 72.2 tok/s, dan konfigurasinya cukup sederhana untuk dijalankan sebagai server lokal yang kompatibel dengan OpenAI

Alternatif Qwen3.6 35B-A3B

  • Sebagian orang menyarankan penggunaan Qwen3.6 35B-A3B alih-alih Gemma 4 26B-A4B
  • Berdasarkan benchmark yang dapat diverifikasi, Qwen dinilai sebagai agen coding yang jauh lebih baik daripada Gemma 4
  • Namun, konfigurasi Qwen lebih lambat; kombinasi Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf, unsloth-Qwen3.6-35B-A3B-MTP-GGUF, dan mmproj-BF16.gguf mencatat 55 tok/s
  • 55 tok/s dibanding 72 tok/s menjadi perbedaan yang cukup besar saat pengguna harus menunggu
  • Unduhan model Qwen dilakukan dari unsloth/Qwen3.6-35B-A3B-MTP-GGUF dengan mengambil Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf dan mmproj-BF16.gguf
  • Server Qwen menggunakan llama-server yang sama, tetapi dijalankan dengan --port 8081
  • Nama penyedia Qwen di konfigurasi Pi adalah qwen36-local, dan baseUrl-nya adalah http://127.0.0.1:8081/v1
  • Konfigurasi model Qwen menggunakan reasoning: true, input: ["text", "image"], contextWindow: 65536, dan maxTokens: 8192

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Komentar Hacker News

  • Jika prompt benchmark-nya adalah “tulis fungsi Python ringkas yang mem-parsing unified diff dan mengembalikan path file yang berubah, lalu jelaskan dua edge case”, dan tiap benchmark hanya menghasilkan sekitar 128 token, maka 128 token tampak terlalu sedikit untuk mendapatkan hasil yang bagus
    Percepatan MTP bergantung pada seberapa sering token prediksi diadopsi; dari pengalaman, tingkat adopsi lebih tinggi di bagian awal keluaran, jadi pengujian pendek bisa menciptakan percepatan positif palsu
    llama.cpp punya alat khusus benchmark yang menyapu argumen tanpa perlu me-restart server dan mengirim prompt lagi: https://github.com/ggml-org/llama.cpp/blob/master/tools/llam...
    Bagian unduhan model juga seharusnya menyebutkan bahwa argumen -hf di llama.cpp bisa mengunduh model secara otomatis. Terima kasih penulis sudah membagikan pengalamannya, tetapi untuk pemula ini mungkin bukan panduan terbaik

    • Ini memang bukan tulisan yang dimaksudkan sebagai panduan developer yang proper. Rekaman layar itu mendapat banyak bookmark dan saya mulai menerima pesan yang menanyakan cara menyiapkannya, jadi saya hanya merangkum cepat bagaimana saya menyusun pengujian ini
      Setelah melihat pengumuman “2x lebih cepat” dari Unclothe, saya jadi penasaran, “apakah ini sekarang cukup cepat untuk benar-benar dipakai?” lalu saya coba atur sendiri
      Tahun lalu saya juga menguji hal seperti Devstral, tetapi terlalu lambat dan terlalu bodoh sehingga saya tidak tertarik terus memakainya; kali ini rasanya akhirnya sampai ke titik cukup layak dipakai baik dari sisi kecepatan maupun kecerdasan
    • Secara realistis, eksperimen harus dilakukan dengan menambahkan system prompt yang memadai di atas prompt pengguna acak. Minimal 1000 token, dan secara nyata sekitar 3000 token tampak lebih baik
      llama.cpp punya alat untuk ini, dan untuk pengukuran yang benar Anda perlu memasukkan prefill sebelum generasi token. Mengukur kecepatan generasi token pada konteks panjang seperti 32k atau 64k juga makin penting
    • 128 token itu ibarat hanya membenchmark overture, bukan keseluruhan opera
    • Ini mirip berkata “berjalan di komputer saya” tanpa melihat masalah nyatanya. 128 token benar-benar bukan apa-apa, cuma sedikit lebih panjang dari respons sapaan singkat

  • Saya pernah menulis artikel serupa dulu menggunakan ollama dan opencode: https://blog.kulman.sk/running-local-llm-coding-server/

    • Ollama bukan pilihan yang bagus: https://sleepingrobots.com/dreams/stop-using-ollama/
      Bukankah system prompt opencode memakan terlalu banyak konteks? Model lokal punya keterbatasan konteks yang besar, dan setahu saya opencode memakai sekitar 10k atau mendekati itu
    • Ini benar-benar berguna, dan jika memakai GUI ollama mungkin bisa dibuat lebih sederhana lagi

  • Jika hanya memakai llama.cpp, sepertinya huggingface-cli tidak wajib untuk mengunduh sesuatu. Cukup berikan -hf ... dan model akan diunduh
    Untuk mengubah lokasi unduhan, atur LLAMA_CACHE:
    LLAMA_CACHE="models" ./llama-server \
    -hf unsloth/gemma-4-31B-it-GGUF:UD-Q4_K_XL \
    ...

    • Untuk draft model, gunakan -hfd

  • Jika RAM unified memory besar tetapi teraflops dan bandwidth GB/s berada di kelas menengah ke bawah, biasanya MoE adalah harapan terbaik. Di lingkungan saya, M2 Max 96GB, peringkat nomor 1 saat ini berdasarkan (kecerdasan, tok/s, kedalaman konteks) adalah DeepSeek-V4-Flash REAP25 <65gb gguf + ds4-server + pi agent
    Tentu ini tidak lebih baik daripada API cloud, tetapi kalau perlu masih cukup layak untuk ditoleransi dan dipakai. Saat penerbangan 4 jam tanpa internet pun LLM lokal yang memakai 60W masih bisa ditopang baterai dengan cukup baik
    Branch ds4 yang mendukung REAP ada di sini: https://github.com/ljubomirj/ds4/tree/reap-compact-support
    Fakta bahwa DS4F baru turun ke tingkat tak terpakai, di bawah 10 tok/s, saat konteks 784K membuat perbedaan besar

  • Saya penasaran apakah model lokal seperti ini benar-benar bisa menyelesaikan masalah bahkan untuk pengguna yang bukan ahli pada bahasa pemrograman tertentu
    Di luar autocomplete inline atau implementasi unit, saya belum yakin apakah ini bisa benar-benar merancang dan merangkai spesifikasi teknis yang bekerja

  • Menjalankan LLM lokal dengan llama.cpp/server lalu memakainya bersama Claude Code atau Codex-CLI relatif sederhana
    Karena pengaturan llama server yang diperlukan sering tersebar di mana-mana, saya mengelola panduan untuk beberapa open LLM populer di sini: https://pchalasani.github.io/claude-code-tools/integrations/...

    • Apakah Anda memakainya untuk penggunaan sehari-hari? Prompt Claude Code sangat besar, jadi pada model lokal pemrosesan prompt memakan waktu sangat lama, dan tidak lama kemudian konteksnya juga habis

  • Dengan omlx.ai saya cukup berhasil mengunduh berbagai model MLX yang cocok dengan hardware saya, lalu menjalankan harness open-source dan tertutup (Claude Code, Codex) secara otomatis dengan model tersebut
    Bisa dilakukan baik dari UI web maupun desktop, jadi secara pribadi saya merasa kalau memakai omlx tidak perlu mengikuti artikel blog seperti ini

    • Di M1 Max 64GB saya tidak melihat keunggulan khusus oMLX atau MLX dibanding GGUF di llama.cpp
      Build Gemma 4 MLX yang saya temukan sejauh ini lebih lambat pada kuantisasi yang sama, dan jauh lebih lambat pada MTP
      Setelah memilih model, web UI bawaan llama.cpp sudah cukup bagus, dan LM Studio juga oke untuk coba-coba berbagai hal
      Gemma-4 dan Qwen 3.6 sama sekali tidak memerlukan bongkahan besar system prompt opencode yang umum itu, dan justru lebih baik jika dihilangkan
    • Jika Anda mencari sandbox untuk dipasangkan dengan oMLX dan Pi, ada ini: https://github.com/Dotnaught/pi-sandbox
    • Menurut saya ini adalah state of the art untuk inferensi lokal di Mac. Bahkan saat ada regresi, para developernya merespons dengan sangat cepat, dan ini salah satu proyek open-source paling mengesankan yang pernah saya lihat belakangan ini

  • DeepSeek v4 Flash yang dijalankan dengan ds4 buatan antirez cukup mengesankan
    Dari sisi “pengetahuan tersimpan”, rasanya setara model kelas GPT-4, tetapi untuk pemanggilan tool dalam alur panjang justru lebih baik daripada model-model kelas GPT-4
    Di MBP M4 Max 128GB, generasinya sekitar 24 t/s dan prefill sekitar 200 t/s. Saya kira ini akan lambat, dan memang lambat untuk tugas seperti generasi kode, tetapi sebagai orkestrator mesin untuk tugas sederhana ini sangat berguna secara mengejutkan
    Untuk penggunaan non-agentik, ini cukup enak diajak bercakap-cakap, dan juga punya keunggulan sepenuhnya berjalan sendiri serta privat
    [0]https://github.com/antirez/ds4

  • Kalau ingin sangat malas, cukup buka Claude Code di terminal, arahkan ke artikel ini, lalu suruh saja “kerjakan”

    • Sekarang saya hampir tidak pernah lagi memakai Google Search. Sembilan dari sepuluh kali, kualitas informasinya buruk dan sulit memilah hal yang dibutuhkan di tengah spam di sekelilingnya
      Sebaliknya, Claude bisa langsung mengerjakannya dalam sekali jalan atau dengan sedikit perapian saja
      Gerbang menuju pengetahuan dan eksekusi sekarang adalah LLM, dan Google Search terasa seperti dinosaurus
      Ini terasa seperti hidup satu abad di masa depan, bahkan lebih keren daripada smartphone