Panduan Jamesob untuk Menjalankan LLM Mutakhir Secara Lokal

 (github.com/jamesob)
2 poin oleh GN⁺ 5 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Merangkum dalam satu repositori konfigurasi hardware, pengaturan switch PCIe, dan konfigurasi menjalankan Docker untuk menjalankan LLM mutakhir serta konversi speech-to-text secara lokal
  • Anggaran sekitar $2k ditujukan untuk konfigurasi 2× RTX 3090 dengan 48GB VRAM, agar bisa menjalankan Qwen3.6-27B dan STT lokal berbasis whisper-large-v3
  • Anggaran sekitar $40k mengasumsikan konfigurasi 4× RTX PRO 6000 Blackwell Workstation dengan 384GB VRAM untuk mendapatkan kecerdasan model yang cukup mendekati Claude Opus
  • Sistem 4× RTX 6000 Pro yang sebenarnya menggabungkan unit utama berbasis EPYC/DDR4 bekas dengan switch PCIe Gen4 c-payne, sehingga komunikasi P2P antargpu ditangani di dalam switch fabric, bukan melalui CPU root complex
  • Setelah menyesuaikan BIOS, GRUB, ACS, hingga batas daya, P2P mencapai line rate Gen4 dengan 27,5GB/s satu arah, 50,4GB/s dua arah, dan latensi 0,37–0,45µs

Rentang anggaran untuk menjalankan LLM lokal

  • Konfigurasi ini ditujukan bagi pengguna yang ingin menjalankan model mutakhir dan konversi speech-to-text secara lokal
  • Repositori ini mencakup hardware yang digunakan, alasan pembelian, tips pengaturan, cara menjalankan STT lokal, dan konfigurasi menjalankan model berbasis container Docker
  • Ada catatan bahwa isi selain tabel di README tidak ditulis oleh AI

  • Konfigurasi sekitar $2k

    • Mengusulkan konfigurasi 2× RTX 3090 untuk memperoleh total 48GB VRAM
    • Pada konfigurasi ini, Qwen3.6-27B dapat dijalankan
    • STT lokal menggunakan whisper-large-v3, dan memakai harness stt lintas platform untuk akses
    • ./runners/stt memiliki konfigurasi STT siap jalan yang mengasumsikan hanya ada sekitar 11GB VRAM pada GPU Nvidia
    • STT lokal diperlakukan sebagai alat yang bisa digunakan lebih nyaman dibanding layanan hosting

  • Konfigurasi sekitar $40k

    • Mengasumsikan konfigurasi 4× RTX 6000 Pro untuk memperoleh total 384GB VRAM
    • Pada kisaran harga ini, konfigurasi tersebut digambarkan sebagai tahap untuk mendapatkan kecerdasan model yang cukup mendekati Claude Opus
    • Per 2026-07, model terbaik saat ini untuk 4× RTX6kPRO yang disebutkan adalah GLM-5.2-Int8Mix-NVFP4-REAP-594B
    • Konfigurasi menjalankannya ada di runners/GLM-5.2-594B
    • Pendekatan lain yang disebutkan adalah menghubungkan klaster 4× DGX Spark untuk memperoleh 512GB VRAM, lalu membiarkan Qwen3.7-27B menangani pekerjaan berulang dengan cepat sebagai otak besar yang lambat

Hardware 4× RTX 6000 Pro yang sebenarnya

  • Sistem sebenarnya dibangun di sekitar 4× RTX PRO 6000 Blackwell Workstation
  • Masing-masing GPU memiliki 96GB, total 384GB VRAM, dengan harga sekitar $46.000
  • Unit utama memanfaatkan EPYC generasi sebelumnya dan komponen DDR4 dari eBay untuk menekan biaya sistem dasar dan memusatkan biaya pada VRAM
  • Per Juli 2026, karena sistem berbasis PCIe5/DDR5 sangat mahal, dipilih switch PCIe Gen4 dan unit utama berbasis DDR4

  • BOM sistem dasar

    • Sistem dasar sebagian besar terdiri dari komponen EPYC generasi sebelumnya yang didapat dari eBay
    • Komponen utama dan harganya adalah sebagai berikut
    • Motherboard ASRock Rack ROMED8-2T: $715
    • CPU AMD EPYC Milan 7313P 16-core 3,0GHz: $504
    • 8× 16GB Crucial DDR4 ECC RDIMM, total 128GB RAM: $642
    • 2× Super Flower 1700W PSU: $750
    • Switch PCIe c-payne Microchip Switchtec PM40100 Gen4: sekitar $1.330
    • NVMe boot 4TB: $291
    • 2× NVMe 8TB untuk bobot model: $1.200
    • Total sistem dasar adalah $5.587

  • Switch PCIe Gen4

    • Menggunakan switch PCIe4 dari c-payne untuk menangani komunikasi antargpu hampir secara langsung
    • Pada tahap allreduce dalam tensor parallelism, data antargpu berpindah di dalam switch fabric tanpa melewati PCI root complex
    • Sub-BOM switch sekitar €1.220, sekitar $1.330 USD
    • Switch PCIe Gen4 5× x16 berbasis Microchip Switchtec PM40100
    • SlimSAS PCIe Gen4 Host Adapter x16
    • 2 kabel SlimSAS SFF-8654 8i
    • Membuat sendiri enclosure kayu untuk GPU dan switch PCI, yang memakan waktu sekitar satu hari
    • Kipas bawaan switch PCI sangat bising dan tampak tidak berguna, sehingga dilepas dari board

Penyimpanan bobot model dan cara menjalankannya

  • Semua bobot model disimpan secara lokal pada filesystem ZFS yang direplikasi di dua drive 8TB
  • Filesystem di-mount ke ~/storage
  • Model yang akan dijalankan terlebih dahulu diunduh secara lokal dengan perintah berikut
hf download <model-name> --local-dir ~/storage/<model-name>
  • Setiap model memiliki docker-compose.yml di direktori terpisah dan berjalan di dalam container Docker-nya sendiri
  • Konfigurasi menjalankannya ada di ./runners/
  • Setiap container me-mount ~/storage/models sebagai read-only untuk membaca bobot yang sudah di-cache
  • Ketika model disajikan dari http://clank.j.co:5000, model diakses melalui opencode yang di-host pada VM di mesin lain
  • Server DNS internal memetakan clank.j.co ke mesin LLM, tetapi bentuk http://<llm-machine-ip>:5000 juga memungkinkan

Harness agen dan konfigurasi tool

  • Di dalam VM terpisah, digunakan aplikasi yang membuat sesi tmux untuk setiap direktori pada tree ~/src, dan menjalankan instance opencode di setiap sesi
  • Setiap instance opencode menggunakan HTTP API mesin inferensi, http://clank.j.co:5000, sebagai backend
  • Kunci untuk memanfaatkan model open-source dengan baik diperlakukan sebagai konfigurasi tool
  • Ringkasan skills/ mencakup tool berikut
    • Browsing web dan pencarian melalui camofox, kunci API kagi.com, dan searXNG
    • Komunikasi dan notifikasi melalui bot Telegram
    • Instance Gitea lokal privat untuk kolaborasi source code
  • Agen dapat diajak bekerja secara interaktif dalam sesi, atau ditugaskan menangani issue Gitea dan mengajukan PR
  • Pekerjaan ini berjalan di dalam VM sandbox, dan komunikasi dengan host hanya dilakukan melalui mount filesystem bersama

Switch PCIe dan pengaturan multi-GPU

  • Pengaturan BIOS

    • Pengaturan BIOS pada motherboard ROMED8-2T disesuaikan agar kecepatan switch PCI tidak turun
    • AMD PCIE Link Width disetel ke x16 untuk slot switch
    • Pengaturan bifurkasi x8/x8 lama membagi slot sehingga upstream link dilatih sebagai Gen4 x8
    • Kedua kabel SlimSAS 8i harus terhubung, dan tiap kabel menangani x8
    • PCIe Link Speed dipaksa ke Gen4
    • Ketika perangkat Blackwell Gen5 melakukan negosiasi otomatis melalui switch Gen4, training bisa gagal dan turun ke Gen1
    • ASPM disetel ke Disabled
    • ASPM L1 menurunkan link idle ke 2,5GT/s
    • Ini menjadi penyebab mengapa pada lspci terlihat seperti diturunkan ke Gen1, tetapi saat ada beban tetap berjalan sebagai Gen4
    • Re-Size BAR disetel ke Enabled
    • Diperlukan untuk mengekspos seluruh BAR VRAM 96GB dan GPU P2P
    • SR-IOV disetel ke Disabled
    • Ini adalah pengaturan untuk menghindari overhead IOMMU dan gangguan P2P pada lingkungan inferensi bare-metal
    • Preferred IO dibiarkan Auto
    • Menetapkan bus switch c-payne 81 secara manual mungkin sedikit mengurangi latensi, tetapi itu optimasi, bukan perbaikan, dan nomor bus dapat berubah setelah perubahan BIOS

  • Redriver dan kabel

    • Sesuai saran c-payne, redriver gain diturunkan ke lvl 3 menggunakan c-payne tool
    • Tingkat gain bergantung pada panjang kabel konektor SAS
    • Karena memesan kabel terlalu sedikit dari c-payne, sempat membeli kabel SAS yang tampak mirip dari Amazon, tetapi perbedaan kecil menyebabkan masalah sehingga harus memesan ulang

Kernel, ACS, dan batas daya

  • GRUB dan NVIDIA UVM

    • Parameter kernel berikut disetel di /etc/default/grub
    GRUB_CMDLINE_LINUX="iommu=off amd_iommu=off nomodeset"
sudo update-grub
    • Tanpa iommu=off, NCCL berhenti pada P2P multi-GPU
    • Untuk perbaikan NVIDIA UVM P2P, pengaturan berikut diterapkan
    echo 'options nvidia_uvm uvm_disable_hmm=1' | sudo tee /etc/modprobe.d/uvm.conf
sudo update-initramfs -u

  • Menonaktifkan ACS

    • Jika ACS aktif secara default, traffic P2P tidak tetap berada di dalam switch fabric dan melewati CPU root port
    • Dalam kondisi ini, efek switch PCIe hilang
    • Karena pcie_acs_override memerlukan kernel yang sudah di-patch, ACS dinonaktifkan saat runtime dengan setpci
    • Pada setiap boot, /usr/local/bin/disable-acs.sh dijalankan sebagai layanan systemd oneshot
    • Cara verifikasinya adalah sebagai berikut
    • Pada lspci -vvv | grep ACSCtl, semuanya harus ditampilkan dengan minus sign
    • Pada nvidia-smi topo -m, hubungan di antara keempat GPU harus terlihat sebagai PIX, bukan PHB/NODE
    • ./tools/measure-gpu-speed.sh dapat digunakan untuk mengukur bandwidth dan latensi P2P dengan mudah

  • Batas daya GPU

    • Untuk menghindari pemasangan sirkuit 220V, sistem dijalankan pada satu sirkuit 110V dengan membatasi daya GPU
    • Dengan systemd, persistence mode dan batas daya diterapkan saat boot
    sudo nvidia-smi -pm 1
sudo nvidia-smi -pl 350
    • Batas daya GPU adalah 350W per GPU, sedangkan default-nya 600W
    • 4×350W berarti beban GPU 1.400W, angka yang disesuaikan dengan anggaran PSU
    • Pada tahap satu PSU 1700W sebelum sirkuit 240V, GPU dioperasikan sekitar 260W
    • 4×260W = 1.040W GPU
    • Ditambah sekitar 280W untuk sistem, totalnya sekitar 1.320W
    • Verifikasi dilakukan dengan nvidia-smi --query-gpu=index,power.limit,power.draw --format=csv

Hasil pengukuran dan referensi

  • Upstream ke arah CPU adalah Gen4 x16 dan sekitar 30GB/s
  • P2P melalui switch adalah 27,5GB/s satu arah, 50,4GB/s dua arah
  • Latensinya 0,37–0,45µs, setara line rate Gen4
  • Jika ASPM aktif di suatu tempat, lspci dapat menampilkan link GPU downstream yang idle sebagai 2.5GT/s (downgraded)
  • Tampilan ini bersifat kosmetik, dan link akan dilatih ulang ke Gen4 saat mendapat beban

  • Resources

    • local-inference-lab/rtx6kpro: repositori yang sering diperbarui tentang penggunaan 4, 6, dan 8 kartu RTX 6000 Pro
    • c-payne: switch PCI indie yang digunakan dalam konfigurasi ini
    • RTX6kPRO Discord: server Discord yang membahas benchmark RTX6kPRO dan pengujian model baru

Bacaan terkait

1 komentar

 
GN⁺ 5 jam lalu
Komentar Hacker News

  • Saya sudah banyak memakai LLM lokal dan menghabiskan uang berlebihan untuk perangkat keras, jadi ekspektasi perlu diturunkan dan syarat detailnya harus dibaca baik-baik
    Build besar di artikel itu mulai dari anggaran 40 ribu dolar, tetapi karena mencakup 4 GPU seharga 12 ribu dolar per kartu, biayanya sebenarnya lebih dekat ke 50–55 ribu dolar
    Konfigurasi lokal sering mengandalkan teknik seperti kuantisasi atau REAP untuk menyesuaikan model dengan perangkat keras. Banyak yang mengklaim kuantisasi 4-bit itu lossless, tetapi itu berasal dari pengukuran divergensi KL pada korpus kecil, dan jika dipakai untuk pekerjaan coding dengan konteks panjang, penurunan kualitasnya terlihat jelas. Bahkan pada tugas non-coding seperti analisis dataset, perbedaan kualitas antara kuantisasi 4-bit, 8-bit, dan kadang versi asli 16-bit cukup bisa diukur
    Tulisan ini juga menganjurkan penggunaan model REAP, yang artinya seseorang memangkas sebagian bobot model agar lebih kecil. Idenya adalah menghapus bobot yang kurang berguna untuk tugas tertentu, tetapi kualitas output keseluruhan kembali menurun
    Jebakannya adalah ketika orang berkata “menjalankan GLM-5.2 secara lokal”, itu terdengar hebat jika melihat benchmark, tetapi kenyataannya yang dijalankan bukan GLM-5.2 melainkan model turunan yang membuang sebagian besar bit dan menghapus sebagian expert. Untuk tugas sangat kecil atau chat, perbedaan antara model kuantisasi/REAP dan versi asli mungkin tidak terlalu terlihat, tetapi pada pekerjaan jangka panjang tempat kesalahan kecil menumpuk, perbedaannya jadi menyakitkan
    Lalu karena sudah telanjur menghabiskan 50 ribu dolar, orang masuk ke lereng licin pemikiran bahwa untuk sedikit menaikkan kualitas dan membuat investasi itu terasa layak, tinggal beli satu atau dua GPU lagi seharga 12 ribu dolar

    • Saya menjalankan Qwen3.6 di RTX4090 dan dalam kebanyakan kasus hasilnya sangat baik
      Untuk tugas coding, sesi perlu dipecah menjadi beberapa panggilan. Saya membuat https://github.com/aka-rider/orqestra, tetapi dengan lingkungan eksekusi tool saat ini, hal serupa bisa dibuat sendiri hampir di mana saja
      Intinya adalah memisahkan sesi yang menghabiskan konteks untuk membaca kode dan memanggil tool, lalu membuat laporan Markdown seperti “kode dan dokumen terkait ada di sini, dan dasar buktinya ini” untuk mengurangi halusinasi. Sesi perencanaan dipisahkan, dan karena model kecil cenderung melewati detail, kritikus dan perancang dibuat bolak-balik 1–3 kali, dan pekerja serta validator juga dibuat bolak-balik karena alasan yang sama
      Qwen3.6 dalam mode read-only bisa mencari bug kompleks selama berjam-jam dan biasanya menemukannya. Perbaikan yang diusulkan mungkin akan agak hacky, tetapi Sonnet juga sama
      Qwen3.6 bisa menulis kode secara mekanis mengikuti rencana yang dibuat Opus. Setelah itu, perlu diberi prompt seperti “tinjau langsung perubahanmu. Ada bug? Cek silang dengan rencana awal, ada yang terlewat? Ada pelanggaran terhadap CLAUDE.md?” Tetapi hal yang sama juga harus dilakukan pada Sonnet
      LLM lokal juga dipakai untuk mengindeks ulang knowledge base. Saat merapikan tiket, cukup meninggalkan catatan mentah seperti “panel tunggal untuk rendering error, pindahkan semua pesan error”, lalu bisa kembali sebagai spesifikasi yang sudah sekitar 90% jadi dengan tujuan dan konteks yang terpasang
    • Saya juga mengalami hal serupa saat menjalankan Qwen 26B non-MoE dengan kuantisasi 8-bit secara lokal di komputer saya
      Untuk tugas kecil hasilnya memang sangat bagus, tetapi ketika pertama kali diberi tugas besar, model itu lupa sedang berada di lingkungan eksekusi agen apa dan mulai salah menulis format pemanggilan tool. Itu berjalan di Pi, tetapi meyakini dirinya berjalan di Claude dan mencoba memanggil tool Claude yang tidak ada
    • Saya menjalankan ds4 di MBP yang dibeli sebelum harga RAM jadi gila, dan cukup berguna
      Model itu tidak menulis seluruh aplikasi sendirian, tetapi berhasil menyelesaikan masalah jaringan tailnet yang merepotkan dan saya sendiri tidak punya waktu atau motivasi untuk memahaminya, dan saya juga sering memakainya untuk tugas sederhana yang sebelumnya tidak saya lakukan karena biaya investigasinya besar. Ini bukan Opus, tetapi tetap berguna, dan saya tidak perlu khawatir apakah nilainya sepadan dengan biaya langganan atau API
    • Saya berharap tulisan dan komentar tentang “menjalankannya secara lokal” juga menyertakan hasil menjalankan ulang benchmark publik yang sama untuk perbandingan
    • Ini sepenuhnya benar. Demam menjalankan coding LLM secara lokal justru merugikan AI lokal yang sebenarnya bisa bermanfaat, yaitu small language model yang dibuat sesuai tujuan
      Pemrosesan bahasa alami, sintesis suara, pemrosesan gambar, rekayasa audio, pemrosesan sinyal, dan tool kecil seperti plugin difusi untuk Krita sangat cocok untuk konfigurasi lokal. Saya juga menulis singkat soal ini beberapa hari lalu[1]
      [1] https://abishekmuthian.com/multiple-20-ai-plans-are-better-t...

  • Klaim bahwa “dengan sekitar 40 ribu dolar, tingkat kecerdasan model naik satu level dan cukup mendekati Claude Opus” setara dengan biaya memakai Claude Opus 4.8 atau Codex GPT 5.5 selama 16,8 tahun dengan patokan 200 dolar per bulan
    Saya sangat suka menjalankan model lokal, tetapi tetap saja biayanya sangat tidak masuk akal, kualitasnya lebih rendah, dan kalau ada backdoor juga bisa berbahaya. Saya sungguh berharap kenyataannya tidak seperti itu

    • 200 dolar per bulan itu kalau memang harus membayar harga API penuh; misalnya kalau Anda perusahaan “enterprise”, biayanya sudah lebih mendekati 4.000 dolar per bulan. Kalau begitu, biaya ekuivalennya turun menjadi 10 bulan
      Meski begitu, saya ragu perangkat lokal benar-benar bisa memproses beban yang setara dengan penggunaan API senilai 4.000 dolar per bulan. Perangkat lokal sulit menjalankan prompt paralel seefisien banyak pusat data Anthropic
    • Saya setuju dengan pokok argumennya, tetapi perhitungan ini mengasumsikan bahwa harga LLM akan terus tetap
      Perusahaan seperti OpenAI dan Anthropic masih menjual paket dengan harga yang disubsidi oleh modal ventura, dan modal itu pada akhirnya akan menuntut keuntungan
    • Gagasan bahwa model terdepan dibekingi backdoor itu tidak masuk akal. Saya belum pernah mendengar satu pun model yang memang dibekingi backdoor, dan kalau ditemukan, kemungkinan besar akan cepat dihapus dari Hugging Face. Ini bukan masalah
    • Di sisi hardware, Anda bisa memakai token jauh lebih banyak daripada paket 200 dolar per bulan
      Dengan OEM spark saya memakai 1 miliar token pada bulan pertama, yang kalau dihitung dengan tarif Opus nilainya lebih dari 1.000 dolar. Pola tokennya berbeda jadi ini bukan perbandingan yang sepenuhnya adil, tetapi setelah itu ada peningkatan vLLM, terutama berkat MTP, sehingga kecepatannya juga naik 2–3x. DiffusionGemma sekitar 4x lebih cepat daripada Gemma biasa
    • Daripada mencoba menjalankannya secara lokal, lebih baik sewa cloud GPU
      Anda juga tidak punya jalur fiber sendiri, jadi saya tidak paham kenapa masih ingin punya aset lain yang cepat terdepresiasi, mahal, dan merepotkan
      Dengan menyewa cloud GPU, Anda tetap bisa ikut budaya kepemilikan, kontrol data, kontrol harga, dan budaya hacking tanpa harus membuat kotak Frankenstein raksasa untuk hobi. Kotak itu mahal, sudah didistilasi sehingga kegunaan nyatanya berkurang, dan perawatannya juga merepotkan

  • Orang bilang “40 ribu dolar sudah hampir seperti Opus”, tetapi kalau GLM 5.2 yang dimaksud “hampir seperti Opus”, maka untuk inferensi yang nyaman setidaknya butuh 8xH200, jadi biayanya lebih dekat ke 400 ribu dolar daripada 40 ribu dolar
    Dalam tulisan itu disarankan memakai model yang dimodifikasi: “GLM-5.2 yang dipangkas dengan REAP sehingga sekitar 22% expert dihapus, lalu dikuantisasi dengan Int8-mix NVFP4, sekitar 594B parameter”
    Saya penasaran bagaimana kinerjanya di dunia nyata di luar benchmark. Bahkan Qwen3.6 pada kuantisasi 6-bit saja sering masuk loop saat inferensi, sedangkan di sini sebagian expert juga sudah dihapus. Kadang model kecil 8-bit atau 16-bit bisa lebih pintar daripada model besar yang sudah seperti di-lobotomi. Untuk coding, tampaknya ada semacam konsensus bahwa sebaiknya jangan turun di bawah 8-bit
    Selain itu juga belum jelas berapa banyak konteks yang masih bisa dipakai saat model yang sudah “di-lobotomi” itu dipaksa masuk ke 4 kartu RTX 6000. Di bawah 100k sering kali hampir tidak bisa dipakai karena sudah kena kompresi sebelum konteks yang dibutuhkan terkumpul. Saya cek repositorinya, konteksnya 240k

    • Saya penasaran bagaimana kalau GLM 5.2 dijalankan hanya dengan satu H200
      Saya ingin tahu apakah benar-benar tidak bisa jalan, atau sekadar terlalu lambat sampai tidak layak dipakai. Saya ingin memverifikasi build dan konsep model kelas terbaru secara lokal, lalu melengkapi sisanya 18–24 bulan lagi saat harga GPU turun besar
    • Saya juga penasaran bagaimana ini berhubungan dengan skalabilitas
      Apakah itu berarti kita bisa menjalankan ratusan prompt secara bersamaan
    • Loop, seperti kebanyakan fenomena terkait LLM, adalah masalah sampling, dan bisa diselesaikan dengan mudah memakai penalti DRY
      Itu sudah ada di llamacpp. Orang yang membuat heretic juga membuat strategi pencegahan loop dan diversifikasi yang paling mutakhir
    • Pada 8x RTX6000, jika memakai kuantisasi NVFP4 dari lukealonso, konteks 1M juga memungkinkan, dan setidaknya sampai 400k konsistensi serta kegunaannya tetap terjaga
      Kecuali memang ingin begitu, secara praktis tidak ada kebutuhan untuk menjalankan 8x H200. Pengecualiannya jika Anda rutin melayani banyak pengguna bersamaan atau banyak agen

  • Ada juga pilihan tengah. Kalau punya 128GB VRAM, sekarang sudah ada beberapa opsi yang bisa memberi kapasitas sebesar itu lewat arsitektur unified memory, dan Anda bisa menjalankan DeepSeek V4 flash melalui DwarfStar dengan kecepatan yang bagus
    Saya sendiri tidak akan mengeluarkan uang untuk itu, tetapi bagi banyak orang ini tampaknya kompromi yang masuk akal

    • Saya baru mulai mencobanya di m4 max 128, dan ini pertama kalinya sejak membeli mesin ini setahun lalu saya merasa LLM lokal benar-benar langsung bekerja untuk coding yang cukup bagus
      Hanya saja harus memakai Pi. claude code punya terlalu banyak bootstrap context sehingga semuanya jadi jauh lebih lambat

  • Mereka bilang “dengan dua RTX 3090 dan total VRAM 48GB, Anda bisa menjalankan Qwen3.6-27B, dan itu model yang sangat bagus”, tetapi dengan $3.000 Anda bisa membeli M5 MacBook Pro dengan memori bersama 48GB, dan itu juga bukan kotak raksasa
    Atau layak juga mempertimbangkan memakai uang itu untuk penyedia hosting cloud. Setidaknya sampai taraf tertentu, mungkin malah jauh lebih murah. Tentu saja, bisa menjalankan model secara lokal itu keren

    • Karena saya cukup bodoh sampai tidak bisa membayangkan situasi yang belum pernah saya alami, saya selalu menganggap LLM lokal hanyalah mainan yang tidak layak dikejar
      Namun setelah benar-benar mencoba sesuatu yang lumayan seperti Gemma 4 31B dan Qwen 3.6 27B, saya baru sadar betapa bergunanya itu
      Anda jadi tidak lagi khawatir sedang membagikan informasi sensitif, tidak lagi khawatir token akan habis, dan juga tidak perlu khawatir soal ketersediaan AI jarak jauh. LLM lokal sangat berharga
    • Hal keren dari 3090 adalah bandwidth memorinya. Pembuatan token kebanyakan dibatasi oleh bandwidth memori
      Dua 3090 punya total bandwidth memori 1,87 TB/s, atau 0,936 TB/s per kartu, sedangkan M5 MacBook Pro hanya 0,3 TB/s. Chip Max bisa sampai 0,63 TB/s, tetapi konfigurasi itu adalah mesin $10.000
      Jadi Qwen 27B berjalan cukup cepat untuk pekerjaan nyata pada dua 3090, tetapi terasa menyiksa di MacBook Pro. Selain itu, saat menjalankan model besar di MacBook Pro, UI menjadi tersendat dan keyboard ikut panas. Jauh lebih baik menaruh dua 3090 di ruang bawah tanah lalu mengaksesnya dari MacBook
    • Saya punya M5 MacBook Pro dan juga konfigurasi GPU terpisah untuk menjalankan model, dan perbedaan kecepatannya besar
      Bukan hanya kecepatan generasi token, tetapi juga waktu hingga token pertama, yaitu waktu pemrosesan prompt. Perangkat keras M5 itu sendiri luar biasa, tetapi GPU tetap jauh lebih cepat
      Menjalankan model di kotak GPU juga punya keuntungan karena Anda tetap bisa memakai laptop di pangkuan tanpa menjadikannya seperti piring panas
    • Saya menjalankan Qwen3.6-27B pada satu GPU 24GB dengan 80 token/detik, jadi bahkan tidak perlu sampai dua kartu
    • Itu pilihan yang masuk akal, tetapi perlu diketahui bahwa M5 Pro hanya punya sekitar 1/3 bandwidth memori, dan M5 Max sekitar 2/3. Konfigurasi paling rendah M5 Max saja sudah $4.100
      Jadi baik prefill yang dibatasi FLOPS maupun decode yang dibatasi bandwidth, keduanya akan lebih lambat

  • Saya baru membangun LLM lokal minggu ini, jadi saya tambahkan pengalaman saya. Saya memilih kartu Intel Arc B70 berkapasitas 32GB; lebih murah daripada 3090 dan RAM-nya lebih besar, tetapi bus memorinya lebih lambat
    Saya memilih ini karena model-model yang ingin saya pakai sedikit terlalu besar untuk muat nyaman di 24GB, dan saya juga butuh ruang untuk memuat beberapa model kecil tambahan untuk autocompletion dan pengenalan suara. Selain itu, saya sudah punya server murah, dan kalau mau memakai GPU ganda saya harus mengganti motherboard, power supply, dan mungkin juga casing
    Penyiapannya cukup rumit. Lini Intel memerlukan paket driver bernama level zero untuk mendukung SYCL, semacam versi CUDA ala Intel, dan cukup sulit membuatnya bekerja dengan benar. Saya menjalankan llama.cpp di kontainer Docker, dan agar kontainer bisa melihat kartunya juga perlu sedikit usaha. Kernel yang cukup baru, dari beberapa bulan terakhir, juga diperlukan
    Begitu sudah berjalan, hasilnya sangat mengesankan untuk investasi $1.000. Menjalankan Qwen 3.6 35B dengan kuantisasi q4 memakai sekitar 3/4 RAM dan menghasilkan sekitar 88 token/detik. Kalau Anda ingin model berukuran lumayan dengan biaya murah, ini bisa jadi salah satu cara

    • Itu salah. Keduanya memakai GDDR6
      B70 adalah 256-bit bus pada 2375MHz, 608 GB/s, sedangkan 3090 adalah 384-bit bus pada 2438MHz, 936 GB/s. Bukan karena lebih lambat, tetapi karena jumlah kanalnya lebih sedikit, yaitu lebarnya lebih sempit

  • qwen3.6-27b bisa menjalankan varian q4 pada satu 3090 dengan total konteks sekitar 250K
    Cukup cepat sehingga tidak terasa menjengkelkan, jadi peningkatan kecepatan dari dua 3090 tidak sepadan bagi saya. Ada juga opsi menjalankan q6 pada dua kartu dengan setengah kecepatan dan konteks yang lebih kecil, tetapi tetap tidak akan bisa bersaing dengan model terkini, jadi menurut saya pada harga saat ini satu kartu adalah investasi terbaik kecuali Anda memang sudah punya dua 3090. Dengan lingkungan runtime yang disusun dengan baik, itu sudah cukup untuk melakukan banyak hal

    • Saat menjalankan qwen3.6-27b pada satu 3090, apakah KV cache-nya juga disetel ke q4?
      Dalam pengalaman saya, pada presisi seperti itu akurasi recall untuk konteks panjang turun cukup besar. Lebih baik mempertahankan KV cache di q8 dan bekerja dengan konteks 120k
    • Perhitungan konteks 250k, model Q4, dan VRAM 24GB itu hanya masuk akal jika cache K/V juga memakai kuantisasi q4, dan itu mungkin bukan ide yang bagus

  • Terkait hal itu, saya penasaran apa sistem isolasi terbaik yang bisa dipakai saat ini. Saya tidak tahu apakah harus sampai memakai VM penuh yang berat, atau sesuatu seperti Firecracker sudah cukup
    Setiap opsi yang memungkinkan tampaknya punya jebakan halus yang mudah membuat Anda menembak kaki sendiri, dan sangat mudah berakhir dalam keadaan yang pada praktiknya hampir tidak punya keamanan sama sekali. VM dipakai karena kita benar-benar bisa percaya bahwa keamanan adalah prinsip dasar teknologi tersebut, bukan pendekatan seperti “pakai 20 flag ini lalu kalau dilihat sambil menyipitkan mata seharusnya aman”

    • Di MacOS ada sandbox seatbelt bawaan. Di Linux, Anda bisa memakai Docker dengan SELinux atau utilitas serupa di atas namespace
      Pertama-tama, vektor serangannya harus dimodelkan. rm -rf bisa dicegah dengan pembatasan tulis, dan curl malware.sh | sh bisa dicegah dengan membatasi eksekusi dari direktori yang dapat ditulisi (seatbelt/SELinux). Hanya dengan pembatasan tulis ke direktori sensitif saja, kemungkinan besar sebagian besar malware sudah bisa sangat dilemahkan
      Kebocoran kredensial bisa ditangani dengan membersihkan environment variable, melarang pembacaan .ssh, .aws, dan sebagainya, serta tidak menempatkan LLM dekat dengan sistem operasional
      Saya membuat utilitas kecil untuk MacOS https://github.com/aka-rider/leash, tetapi ini juga bisa dilakukan dengan skrip bash
    • Itu tergantung untuk apa. Jika model keamanannya adalah mengurung agen dalam sandbox agar tidak merusak PC Anda, pilihannya banyak
      Jika ingin yang ringan, bisa memakai sesuatu seperti bubblewrap[1] atau microVM seperti libkrun[2], dan jika ingin sekalian alat pendukung terkait, bisa sampai memakai Docker penuh
      [1] https://github.com/containers/bubblewrap
      [2] https://github.com/libkrun/libkrun
    • Sepertinya tidak ada konfigurasi siap pakai yang cocok untuk semua orang. Untuk batas keamanan apa pun, tiap lapisan hardening selalu datang dengan trade-off pada usability
      Saya paham dengan ketidakpastian soal bagaimana benar-benar tahu bahwa semuanya sudah terkunci rapat
      Secara pribadi, saya rasa VM atau microVM adalah arah yang tepat. Tidak seperti container, ini memang dirancang sebagai batas keamanan yang nyata. Bahkan dibanding bubblewrap, Anda bisa memberikan seluruh filesystem kepada agen dan menjalankannya dalam mode YOLO, sedangkan dengan bubblewrap Anda harus mem-bootstrap ketersediaan tiap alat pengembangan satu per satu dan me-mount direktori konfigurasi serta cache paket dengan aman, dan bahkan setelah itu pun kemungkinan besar Anda masih akan terus menemui error izin. Isolasinya juga jauh lebih lemah
      Dukungan runtime memang terbatas, tetapi menurut saya cukup masuk akal untuk menjalankan proses runtime di host lalu mendelegasikan semua pemanggilan alat dan interaksi filesystem ke VM. Dengan begitu, data sesi dan kunci autentikasi bisa tetap berada di mesin utama dan tidak pernah masuk ke dalam konteks. Sebagai gantinya, runtime itu sendiri menjadi bagian dari batas keamanan, dan itulah trade-off-nya
      Cara memindahkan data masuk dan keluar VM juga menjadi masalah usability. Saya memakai skrip yang mendorong repositori git lokal ke VM lalu mengambilnya kembali seolah-olah dari remote, sehingga VM tidak bisa memulai koneksi ke host dan juga tidak perlu memiliki kredensial git. Tetapi bagi orang yang ingin agen bisa langsung push ke GitHub, itu mungkin terasa terlalu merepotkan
      Opsi yang pernah saya coba atau lihat untuk VM itu sendiri adalah qemu + libvirt, crun-vm, dan keluarga libkrun. qemu + libvirt butuh usaha untuk penyetelan, tetapi sangat teruji dan sangat bisa dikonfigurasi. crun-vm adalah PoC lapisan integrasi tingkat tinggi antara podman dan qemu; tampaknya sudah ditinggalkan, tetapi tetap menarik karena berfokus pada alat dan standar yang sudah ada. libkrun adalah pendatang yang lebih baru, dengan wrapper seperti microsandbox, smolvm, dan krunvm. Semuanya ini untuk Linux
    • Saya jauh lebih tidak percaya pada VM penuh yang dipasangi GPU passthrough dibanding VM yang hanya memakai CPU

  • Rasanya aneh harus bersusah payah sejauh ini hanya untuk memakai LLM. Terutama kalau tujuannya mengejar sesuatu yang state-of-the-art seperti ini
    Kalaupun hal-hal seperti Claude hilang besok, saya tidak akan berkedip sedikit pun
    Saya tidak mengerti kenapa orang mau menukar lipatan otaknya demi akses ke mesin slop. Kalau mau dianalogikan, mungkin seperti memberi tukang kayu terampil sebuah mesin yang menghasilkan furnitur dengan kualitas satu atau dua tingkat di bawah Ikea. Apakah pekerjaan tetap selesai? Kebanyakan iya. Apakah si tukang kayu menikmati prosesnya? Tidak

  • Dalam pengalaman saya, saya belum pernah menjalankan model yang sangat dikuantisasi seperti q4 atau model yang agak dimodifikasi lalu merasa “wow, ini benar-benar hebat.” Biasanya setelah beberapa prompt, ujung-ujungnya masuk tong sampah
    Saya punya RTX 6000 PRO 96GB, dan yang masih nyaman dijalankan itu sekitar Qwen 3.6 27B atau MoE, serta Gemma 4 31B. Kalau model dijalankan dengan presisi penuh dan panjang konteks maksimum, batasnya memang sekitar itu
    Model-model ini performanya bagus dan bisa dipakai untuk berbagai hal seperti coding, riset internet, dan lain-lain. Kalau setelah dihitung-hitung Anda sepertinya akan menghabiskan lebih dari 2.400 dolar per tahun di Anthropic, membeli kartu seperti ini mungkin masuk akal, tetapi Anda harus menerima penurunan kualitas. Toh, siapa juga yang tahu apakah 5 tahun lagi manusia masih akan menulis kode sendiri.