Menjalankan Gemma 4 26B pada Xeon berusia 13 tahun tanpa GPU dengan kecepatan 5 token per detik

 (neomindlabs.com)
1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Pada server berbasis dual Xeon E5-2690 v2 keluaran 2013 dan DDR3, Gemma 4 26B-A4B Q8_0 dijalankan hanya dengan CPU, mencapai sekitar 5,2 token/detik untuk decoding dan sekitar 16 token/detik untuk evaluasi prompt
  • Jalur cepat di ik_llama.cpp mengasumsikan AVX2·FMA3, tetapi CPU Ivy Bridge hanya mendukung AVX1, sehingga diperlukan perubahan kompilasi untuk build non-AVX2 dan fallback komputasi
  • Graph builder selalu membuat MOE_FUSED_UP_GATE dan FUSED_UP_GATE, tetapi dispatcher non-AVX2 tidak memiliki jalur penanganannya, sehingga sekitar 240 tensor per forward pass tidak pernah dihitung dan menghasilkan keluaran multibahasa yang tampak lancar namun kacau
  • Claude menemukan bug tersebut lewat instrumentasi logit dan analisis kode, lalu mengganti operasi terfusi itu dengan dua ggml_mul_mat_id dan ggml_fused_mul_unary, sementara pengguna menjalankan eksperimen dan menentukan acuan hasil yang benar
  • Server enterprise lama masih bisa dimanfaatkan sebagai cadangan lokal saat API berbayar bermasalah atau untuk pekerjaan batch yang lambat, tetapi --run-time-repack yang membuat layout khusus AVX2 tidak boleh digunakan

Lingkungan eksekusi pada server penyimpanan berusia 13 tahun

  • Perangkat HP StoreVirtual bekas pakai ini menggunakan dual Xeon E5-2690 v2 keluaran 2013 dan memori DDR3, tanpa GPU
    • Karena berasal dari generasi Ivy Bridge, CPU ini hanya mendukung AVX1 dan tidak mendukung AVX2 maupun FMA3
    • Awalnya dibuat untuk penyimpanan disk, dan biaya pembeliannya di bawah 300 dolar
  • Model yang dijalankan adalah Gemma 4 26B-A4B dari Google, model mixture-of-experts (MoE) berbobot terbuka dengan 26 miliar parameter
  • Pada model terkuantisasi Q8_0, decoding diukur sekitar 5,2 token/detik dan evaluasi prompt sekitar 16 token/detik

Kasus Xeon keluaran 2016 yang menjadi titik awal

  • Artikel Hacker News A 10 year old Xeon is all you need membagikan contoh menjalankan Gemma 4 pada Xeon tunggal keluaran 2016 dengan 128GB DDR3 tanpa GPU
  • Konfigurasi itu memakai ik_llama.cpp dan sekitar 25 flag eksekusi yang detail
    • speculative decoding
    • routing MoE yang mempertimbangkan CPU
    • flash attention untuk CPU
    • repacking bobot saat runtime
  • Pendekatan yang sama diterapkan ke server Ivy Bridge, tetapi eksekusi berhenti sejak tahap awal
    • Berbeda dari CPU Broadwell keluaran 2016, E5-2690 v2 tidak memiliki AVX2 dan FMA3
    • Instruction set ini baru tersedia mulai Haswell tahun 2014, yaitu generasi v3 Intel, dan kernel cepat ditulis dengan asumsi itu tersedia

Diagnosis dan patch dengan bantuan Claude

  • Setelah menerima informasi kegagalan startup, Claude mengidentifikasi perbedaan instruction set CPU sebagai penyebabnya
  • Melanjutkan upaya sebelumnya yang belum tuntas dengan model gratis, Claude memperbaiki jalur C++ yang penting bagi performa agar bisa fallback dengan benar pada CPU sebelum AVX2
  • Pekerjaan ini tidak selesai hanya dengan satu permintaan fix it
    • membaca kode C++ berorientasi performa yang ditulis pengembang lain
    • menganalisis mengapa kernel tidak valid pada mikroarsitektur tertentu
    • menghindari jalur yang tidak didukung tanpa membuang optimisasi yang sudah ada di fork
  • Alih-alih menulis sendiri fallback kernel C++, pengguna berperan menjalankan eksperimen, membaca output, menentukan pertanyaan berikutnya, dan menilai acuan hasil yang benar
  • Diagnosis dan patch dilakukan oleh instance Claude yang berjalan di server tersebut

Jalur operasi yang rusak pada build non-AVX2

  • ik_llama.cpp yang dipakai untuk inferensi Gemma 4 MoE adalah fork dari llama.cpp dan pada dasarnya menganggap AVX2 sebagai syarat minimum
  • Saat build dengan GGML_USE_IQK_MULMAT dimatikan, sebagian besar jalur cepat dikeluarkan dan fallback ke operasi skalar/SSE umum
    • Untuk perkalian matriks Q8_0 biasa, fallback ini bekerja
    • Namun, fallback tidak diterapkan pada dua operasi graph
  • Jaringan feedforward MoE di Gemma 4 menghasilkan operasi berikut
    • MOE_FUSED_UP_GATE: operasi terfusi yang menggabungkan perkalian matriks gate dan up per expert dengan SwiGLU
    • FUSED_UP_GATE: versi operasi padat yang dipakai pada layer non-MoE
  • Kedua operasi di compute dispatcher dilindungi oleh kondisi GGML_USE_IQK_MULMAT, tetapi graph builder tetap membuat operasinya tanpa syarat
    • Dispatcher pada build non-AVX2 tidak memiliki case untuk menangani enum tersebut
    • Operasi jatuh ke cabang default, sehingga tensor tujuan untuk seluruh jaringan feedforward expert diam-diam tidak pernah dihitung
  • Gemma 4 26B memakai 8 expert aktif per token di 30 layer, sehingga pada tiap forward pass sistem mengonsumsi sekitar 240 tensor berisi nilai sisa yang tertinggal di buffer memori

Petunjuk yang terlihat dari output kacau

  • Output yang salah tampak lancar, tetapi sebenarnya berupa string multibahasa tanpa makna
    • ID token tersebar merata di seluruh 262.000 kosakata
    • Bahasa Thai, bahasa Korea, sentinel <unused>, dan potongan bahasa Inggris muncul dengan frekuensi mirip
  • Pada temperatur 0, output bersifat deterministik, hasil single-thread dan multi-thread juga identik hingga tingkat byte, dan tidak muncul NaN
  • Di setiap layer, konstanta besar mendorong hidden state sehingga softmax akhir menjadi datar
  • Claude menginstrumentasi logit mentah sebelum sampling untuk mencetak 5 token teratas, rentang, rata-rata, dan jumlah NaN
    • Rata-rata logit token prediksi pertama bukan mendekati 0, melainkan +16
    • Sekitar 80% seluruh kosakata memiliki logit positif
  • Karena biasnya konsisten, bukan korupsi acak, pencarian dipersempit ke dugaan bahwa sebagian besar hidden state memakai memori yang belum diinisialisasi yang menyisakan nilai floating-point positif kecil

Perbaikan dalam tiga tahap

  • Patch terdiri dari tiga commit di atas main pada fork tersebut

  • Perbaikan kompilasi non-AVX2

    • Cabang skalar #else di iqk_quantize.cpp untuk quantize_row_q8_0_x4 dan quantize_row_q8_1_x4_T ternyata tetap merujuk helper AVX2 seperti hsum_i32_8
    • Cabang itu ditulis ulang menjadi loop skalar portabel
    • Sejumlah pemanggilan IQK yang bocor ke ggml.c dan ggml-quants.c diberi guard #if GGML_USE_IQK_MULMAT
    • Include yang hilang ditambahkan agar iqk_cpu_ops.cpp bisa dikompilasi secara mandiri
    • Tanpa perbaikan ini, fork tersebut memang tidak bisa dibuild di hardware non-AVX2

  • Fallback graph saat runtime

    • Alih-alih memperbaiki dispatcher, graph builder diubah agar pada build tersebut menghasilkan operasi yang memang sudah punya jalur komputasi
    • Di ggml_moe_up_gate, bobot terfusi up_gate_exps ditangani saat GGML_USE_IQK_MULMAT dimatikan
    • Bentuk tensor adalah [n_embd, 2*n_ff, n_experts], dengan separuh pertama untuk gate dan separuh kedua untuk up
    • Tensor itu dipisah menjadi dua slice ggml_view_3d
    • ggml_mul_mat_id dijalankan pada masing-masing slice
    • Kedua hasil digabung dengan ggml_fused_mul_unary(gate, up, SILU)
    • Jika bobot gate dan up memang sudah terpisah, maka tanpa slicing digunakan dua ggml_mul_mat_id dan operasi fused multiply-unary
    • Fallback yang sama juga diterapkan pada ggml_fused_up_gate yang dipakai di layer non-MoE
    • mul_mat_id memakai implementasi ggml dasar, dan fused_mul_unary menangani SILU dan perkalian sekaligus, sehingga semua operasi penyusunnya sudah memiliki implementasi non-IQK
    • Seluruh perubahan berada di bawah #if !GGML_USE_IQK_MULMAT, jadi hasil build AVX2 tetap identik bit demi bit dengan sebelumnya

  • Perapihan stub CI

    • Stub #else di sumber IQK berbeda dari iqk_mul_mat.h, sehingga ci/run.sh juga tidak bisa dibuild pada hardware non-AVX2
    • Include <cstdint> tidak ada
    • Sebagian stub memiliki parameter awal ekstra yang tidak perlu atau tidak memiliki parameter sinks, sehingga signaturenya berbeda
    • Sebagian fungsi bahkan tidak punya stub sama sekali, menyebabkan undefined reference saat linking
    • Setelah stub disesuaikan dengan header, test suite akhirnya bisa dijalankan di lingkungan non-AVX2

Biaya performa fallback dan bug repacking

  • Fallback ini menambah biaya karena menjalankan dua mul_mat_id alih-alih satu kernel terfusi
  • CPU tersebut memang sudah terbatas oleh bandwidth memori, dan kernel terfusi asli juga khusus AVX2, jadi tidak ada jalur eksekusi lama di lingkungan ini yang benar-benar dikorbankan
  • Performa akhirnya adalah sekitar 5,2 token/detik untuk decoding dan sekitar 16 token/detik untuk evaluasi prompt pada MoE 26B-A4B
  • --run-time-repack menyusun ulang bobot terkuantisasi saat startup ke format interleave khusus AVX2, yaitu Q8_0_R8
    • Ini adalah bug terpisah yang kembali merusak output pada lingkungan AVX1
    • Patch saat ini tidak memperbaikinya, sehingga flag tersebut dihapus dari skrip eksekusi

Proses mempersempit penyebab

  • Ketidakcocokan instruction set mudah dikonfirmasi, tetapi masalah dispatcher yang diam-diam jatuh ke cabang default tanpa error jauh lebih sulit ditemukan
  • Sejumlah kandidat dieliminasi lewat review kode
    • Helper RMSNorm tampak benar
    • Fallback AVX1 untuk ggml_vec_dot_q8_0_q8_0 juga tampak benar
    • Karena hasil single-thread identik bit demi bit, bug threading bisa dikesampingkan
  • Dari rata-rata logit yang tetap di +16 dan token berekor panjang yang memiliki nilai serupa, disimpulkan bahwa sebagian besar residual stream belum terinisialisasi
  • Setelah mencari #if GGML_USE_IQK_MULMAT di dispatcher, dua jalur operasi yang hilang ditemukan dalam waktu sekitar satu menit

Syarat reproduksi dan ruang pemanfaatan

  • Syarat reproduksi pada perangkat sebelum AVX2 adalah sebagai berikut
    • Hardware: dual Xeon E5-2690 v2, Ivy Bridge, AVX1, DDR3, tanpa GPU
    • Build: ik_llama.cpp dari branch patch dikompilasi tanpa GGML_USE_IQK_MULMAT
    • Model: Gemma 4 26B-A4B Q8_0
    • Eksekusi: gunakan flag CPU ik_llama.cpp yang umum, tetapi tanpa --run-time-repack
  • Perubahan lengkapnya dapat dilihat di ikawrakow/ik_llama.cpp PR #2138
    • Pada saat penulisan, PR ini masih terbuka dan menunggu tinjauan maintainer, jadi eksekusi harus dilakukan langsung dari branch
    • Bug yang muncul pada perangkat serupa bisa dilaporkan di thread PR
  • Menyimpan model lokal di server enterprise lama dapat menjadi alternatif ketika API berbayar berhenti tersedia, atau untuk menangani pekerjaan batch lambat yang tidak cocok dengan skema biaya per token
  • Pendekatan ini lebih menekankan kemampuan menggali kode asing dan sistem lama secara langsung ketimbang mengandalkan layanan berlangganan, dan pola yang sama juga berlaku untuk merawat aplikasi Rails berusia 15 tahun atau database yang sudah ditinggalkan penanggung jawabnya

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Komentar Hacker News

  • Diperkirakan pada pertengahan 2027, model mixture-of-experts (MoE) dengan lebih dari 200 miliar parameter akan bisa dijalankan di hardware konsumen biasa
    Saya menjalankan Qwen3.6-35B-A3B secara lokal di Mac 16GB dan mendapatkan 7–9 token per detik: https://github.com/deepanwadhwa/samosa-chat
    Artinya, model setara GPT-4 bisa dijalankan secara lokal di MacBook Air RAM 16GB dengan kecepatan seperti ini

    • Sepertinya bahkan tidak perlu menunggu sampai saat itu. Model bobot ternary Bonsai 27B yang dirilis Prism beberapa hari lalu hanya sekitar 7GB dan menghasilkan lebih dari 44 token per detik di laptop M4 Max: https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit
      Ini sudah berada di kisaran jumlah parameter aktif pada sebagian besar model 200 miliar parameter ke atas, jadi jika Prism mau, mereka bisa merilis model seperti itu. Namun, jaringan saraf rekursif seperti HRM tidak memerlukan parameter sebanyak itu, jadi apakah skala sebesar itu benar-benar perlu masih bisa diperdebatkan: https://huggingface.co/sapientinc/HRM-Text-1B
    • 7–9 token per detik sulit disebut kecepatan yang bagus. Saya bukan ahli, tetapi dari eksperimen lokal, kalau lebih lambat dari 12–16 token per detik rasanya membuat frustrasi
    • Saya pada dasarnya setuju dengan prediksinya, tetapi waktunya mungkin sedikit lebih lambat. Untuk mencapai itu, kita memerlukan kompresi yang benar-benar berbeda dari sekadar mengurangi bit per parameter seperti sekarang, sehingga dalam situasi itu metrik jumlah parameter itu sendiri bisa jadi tidak lagi bermakna
      Misalnya, kalau setiap lapisan hanya punya satu seed 256-bit lalu memasukkannya ke fungsi noise untuk menghasilkan 16K bobot nyata, ukuran penyimpanan per bobot bisa ditekan menjadi kurang dari 1 bit
    • Saya menjalankan Ornith 35B di Pi dan mendapatkan lebih dari 50 token per detik. Sejak tahu bahwa Pi juga mendukung pencarian dan pengambilan, saya jadi tidak perlu lagi mencari model besar untuk keperluan pencarian
      Sepertinya model-model baru yang akan mengubah peta persaingan bakal keluar berturut-turut bulan ini dan bulan depan, jadi saya antusias. Ornith benar-benar layak dicoba
    • 9 token per detik tampaknya sulit ditoleransi. Dalam sesi Claude, menghabiskan 1 juta token dalam waktu kurang dari sehari itu hal yang biasa, jadi untuk pekerjaan nyata ini terlihat terlalu lambat

  • Mungkin ada yang tidak suka mendengarnya, tetapi saya rasa biaya token dari penyedia inferensi lebih murah daripada biaya listrik untuk menjalankan model secara lokal
    Untuk menyederhanakan, jika hanya menghitung pembuatan output, 5 token per detik berarti 18.000 token per jam, dan biaya dari penyedia sekitar $0,005. Jika server memakai sekitar 500W saat inferensi dan kita pakai patokan Jerman dengan tarif listrik $0,3 per kWh, maka menghasilkan jumlah yang sama secara lokal memerlukan $0,15, jadi 30 kali lebih mahal
    Jika privasi menjadi kekhawatiran, menjalankan secara lokal tetap bagus, tetapi kita perlu sadar bahwa ini jauh lebih tidak efisien daripada penyedia inferensi. GPU baru akan terus meningkatkan efisiensi inferensi, sehingga kesenjangan ini juga akan makin melebar
    Awalnya saya salah menghitung menjadi 180.000 token, tetapi sebenarnya 18.000 token, jadi kecuali listrik Anda nyaris gratis, sulit untuk bersaing. Penyedia juga kemungkinan masih memakai H200/H100 untuk model kecil, tetapi jika beralih ke GB300 atau GPU Ruby tahun depan, biaya inferensi bisa turun menjadi seper-30, sehingga nilai utama model lokal nantinya mungkin adalah privasi

    • Jika menjalankan Qwen 27B di rumah, sistem saya memakai sekitar 400W saat bekerja, menghasilkan sekitar 40 token per detik, dan yang lebih penting, pemrosesan prompt sekitar 1.000 token per detik
      Dalam satu jam, itu berarti bisa memproses 3,6 juta token input atau menghasilkan 144.000 token, dengan biaya listrik sekitar $0,15. Jika jumlah yang sama diproses dengan Sonnet, inputnya akan menelan $7,2 dan generasinya $1,4, jadi cloud 10 kali lebih mahal untuk generasi dan hampir 50 kali lebih mahal untuk pemrosesan
    • Di AS, tarif listrik bahkan tidak mendekati $0,30 per kWh. Pada jam-jam sepi tarifnya setengah dari itu, dan dengan investasi $1.000 pada baterai, Anda juga bisa menyimpan listrik $0,11 dari jam supermurah
      Penyedia inferensi sedang bersaing memperebutkan pangsa pasar sambil menanggung utang besar, jadi harganya jelas akan naik
    • Akan keren kalau ada server LLM self-hosted mandiri yang berjalan dengan tenaga surya dan baterai. Seperti Low Tech Magazine, servernya offline saat sinar matahari kurang, lalu dibangun pada skala yang dibutuhkan komunitas lokal—teman, jalan, klub, dan sebagainya—untuk dipakai setiap hari
      Jika AI didemokratisasi sampai komunitas bisa benar-benar mengendalikannya, masalah data center juga bisa teratasi, dan tingkat sensor maupun alignment bisa diputuskan komunitas secara demokratis. Gagasannya mirip dengan sebagian tulisan Geohotz
      Model open source sebentar lagi akan cukup bagus dan efisien untuk dilayani murah memakai hardware bekas. Di tiap komunitas kecil, cukup ada satu orang yang melek teknologi untuk mengumpulkan biaya awal beberapa ratus dolar, lalu setelah itu bisa dijalankan nyaris gratis tanpa biaya listrik
      https://solar.lowtechmagazine.com/
    • Efisiensi memang penting, tetapi banyak juga orang yang listriknya murah atau punya perangkat yang efisien. Pada home server AMD Strix Halo, Gemma4-26B bisa disajikan sekitar 70 token per detik dengan konsumsi hanya 100W
    • Saya tidak peduli kalau biayanya lebih mahal. Alasan menjalankan secara lokal bukan untuk menghemat uang, melainkan untuk mendapatkan kebebasan dan privasi, dan jika opsi itu ada, dalam jangka panjang biaya juga akan turun
      Jika tidak ada alternatif lokal, harga model cloud akan jauh lebih mahal

  • Dual Xeon generasi ini kemungkinan mengonsumsi lebih dari 300W saat dibebani. Dengan tarif listrik rata-rata di AS, biayanya sekitar 1,35 dolar per hari, dan akan lebih mahal jika ruangan perlu didinginkan pada musim panas
    Jika waktu pemrosesan prompt diabaikan dan dijalankan 24 jam penuh, hasilnya sekitar 400 ribu token per hari, jadi biayanya sekitar 0,30 dolar per 1 juta token output. Kebetulan ini sama dengan harga model tersebut di OpenRouter saat ini, tetapi kecepatan generasi OpenRouter 8 kali lebih cepat
    Ada banyak alasan untuk bereksperimen dengan LLM lokal, seperti menjaga agar data tidak keluar dari rumah, tetapi sulit mengatakan ini menguntungkan secara finansial. Sebagai orang yang sudah menginvestasikan jauh lebih banyak uang pada perangkat inferensi lokal di rumah, menurut saya ini menyenangkan, tetapi bukan cara untuk berhemat

    • Bagi orang yang benar-benar tinggal di rumah milik sendiri, ini perhitungan yang masuk akal. Saya tinggal di rumah sewa dan tidak membayar listrik sendiri, jadi batas efisiensi biaya adalah saat pemilik rumah mulai protes
    • Saya rasa kebanyakan orang menjalankan model secara lokal bukan untuk menghemat uang, melainkan agar tidak menyebarkan data pribadi
    • Mirip dengan kripto. Karena biaya listrik, bagi kebanyakan orang membeli lebih murah daripada menambang sendiri
    • Pada musim dingin saat pemanas rumah dinyalakan, panas buang juga bisa dimanfaatkan sehingga jadi lebih ekonomis

  • Sudah dirangkum hasil menjalankan beberapa model tanpa GPU di dual Xeon dan DDR4 256GB
    https://gist.github.com/hparadiz/f3596d00a62d8ebb2dadcc46ee5822c7

    • Saya penasaran apakah pernah dicoba menggunakan hanya satu CPU untuk menghilangkan penurunan performa NUMA. Memang hanya akan bisa memakai setengah memori, tetapi saya ingin tahu seberapa besar perbedaan performanya
    • Sepertinya jika RAM yang lambat tersedia dalam jumlah sangat besar, model kecil pun bisa berjalan cukup cepat. Saya penasaran bagaimana model yang lebih besar akan bekerja di perangkat ini

  • Ini tergolong cukup lambat. Saya mendapatkan 8~12 token per detik bahkan di CPU berusia 13 tahun, dan hasilnya bisa berbeda tergantung ukuran konteks dan pengaturan lain
    https://news.ycombinator.com/item?id=48354801

    • Bahkan dengan Xeon E3-1270 V2 3.50GHz dan Nvidia Quadro K2200 4GB lawas, saya mendapatkan 8~9 token per detik. Saya menjalankan gemma4:e2b dan gemma4:12b-it-qat di Ollama
    • Bukankah perbedaannya karena tulisan asli memakai kuantisasi Q8 sedangkan di sini memakai Q4?

  • Saya penulis postingan aslinya. Tampaknya komentar asli saya sempat dilaporkan karena suatu alasan. Perbaikannya sudah saya buka sebagai PR #2138 di proyek induk: https://github.com/ikawrakow/ik_llama.cpp/pull/2138

  • Sepertinya tidak ada port yang layak dipakai untuk memasang perangkat lunak pada perangkat StoreVirtual ini. Hanya ada port USB, jadi saya penasaran apakah pemasangannya dilakukan lewat konsol serial

  • Saya menjalankan Gemma 4 26B pada Mac Pro 2013 dengan konfigurasi yang sama dan mendapatkan sekitar 5 token per detik. Kartu grafis gandanya tidak berguna untuk ini, tetapi untuk beberapa pekerjaan masih cukup praktis

  • Saya sudah melihat langsung konfigurasinya di ruang bawah tanah, dan memang luar biasa. Lain kali akan menyenangkan kalau printer 3D-nya juga diperlihatkan

  • Sebagai video yang agak terkait, ada yang menjalankan LLM di Pentium 4 dan menjulukinya NetburstGPT. Tentu saja sangat lambat
    https://www.youtube.com/watch?v=ILV-eu90te8