GPU olmadan 13 yıllık bir Xeon’da Gemma 4 26B’yi saniyede 5 token hızında çalıştırmak

 (neomindlabs.com)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • 2013 model çift Xeon E5-2690 v2 ve DDR3’ten oluşan bir sunucuda Gemma 4 26B-A4B Q8_0 yalnızca CPU ile çalıştırılarak decode aşamasında yaklaşık 5,2 token/sn, prompt değerlendirmesinde yaklaşık 16 token/sn elde edildi
  • ik_llama.cpp içindeki hızlı yol AVX2·FMA3 varsayımıyla yazılmış olsa da Ivy Bridge CPU yalnızca AVX1 desteklediğinden, AVX2’siz derleme için derleme değişiklikleri ve işlem fallback’leri gerekti
  • Grafik oluşturucu MOE_FUSED_UP_GATE ve FUSED_UP_GATE işlemlerini koşulsuz üretirken AVX2’siz dispatcher’da bunları işleyecek yol yoktu; bu da her forward geçişte yaklaşık 240 tensörün hesaplanmadan kalmasına ve anlamsız çok dilli çıktılara yol açtı
  • Claude, logit enstrümantasyonu ve kod analiziyle hatayı buldu; birleşik işlemleri iki ggml_mul_mat_id ve ggml_fused_mul_unary ile değiştirdi, kullanıcı da deneyleri çalıştırıp doğru sonucun ölçütünü belirledi
  • Eski kurumsal sunucular, ücretli API kesintilerinde yerel bir yedek seçenek ya da yavaş batch işleri için hâlâ kullanılabilir; ancak AVX2’ye özgü düzen oluşturan --run-time-repack kullanılmamalı

13 yıllık depolama sunucusunun çalışma ortamı

  • Yeniden değerlendirilmiş HP StoreVirtual donanımı, 2013 model çift Xeon E5-2690 v2 ve DDR3 bellek kullanıyor; GPU yok
    • Ivy Bridge nesli olduğu için yalnızca AVX1 destekliyor ve AVX2 ile FMA3 desteklemiyor
    • Aslen disk depolama için üretilmiş ve satın alma maliyeti 300 doların altında
  • Çalıştırılan model, Google’ın Gemma 4 26B-A4B sürümü; 26 milyar parametreli, açık ağırlıklı bir uzman karışımı (MoE) modeli
  • Q8_0 nicemlenmiş modelde decode yaklaşık 5,2 token/sn, prompt değerlendirmesi ise yaklaşık 16 token/sn olarak ölçüldü

Başlangıç noktası olan 2016 model Xeon örneği

  • Hacker News’te paylaşılan A 10 year old Xeon is all you need, GPU olmadan 2016 model tek Xeon ve 128 GB DDR3 üzerinde Gemma 4 çalıştırılan bir örnekti
  • Bu kurulum ik_llama.cpp ve yaklaşık 25 ayrıntılı çalışma bayrağı kullanıyordu
    • speculative decoding
    • CPU odaklı MoE routing
    • CPU için flash attention
    • çalışma zamanında ağırlık yeniden paketleme
  • Aynı yaklaşım Ivy Bridge sunucuya uygulandı, ancak çalıştırma daha başlangıçta durdu
    • 2016 model Broadwell CPU’nun aksine E5-2690 v2’de AVX2 ve FMA3 yok
    • Bu komut kümesi 2014’teki Haswell, yani Intel’in v3 nesliyle geldi ve hızlı çekirdekler buna göre yazılmıştı

Claude ile teşhis ve yama

  • Başlatma hatası bilgisi Claude’a verildiğinde, nedeni CPU komut kümesi farkı olarak saptadı
  • Daha önce ücretsiz bir modelle denenen ama tamamlanmayan yaklaşımı devralarak, performans açısından kritik C++ yollarının AVX2 öncesi CPU’larda doğru fallback’e dönmesini sağladı
  • İş tek bir fix it isteğiyle bitmedi
    • başka bir geliştiricinin yazdığı performans odaklı C++ kodunu okudu
    • belirli mikro mimaride çekirdeğin neden geçerli olmadığını analiz etti
    • fork’taki mevcut optimizasyonları atmadan desteklenmeyen yolları dolaştı
  • Kullanıcı, C++ çekirdek fallback’lerini doğrudan yazmak yerine deneyleri çalıştırıp çıktıları okuyarak sonraki soruları belirleme ve doğru sonucun ölçütünü saptama görevini üstlendi
  • Teşhis ve yama, ilgili sunucuda çalışan Claude örneği tarafından yapıldı

AVX2’siz derlemede bozulan işlem yolu

  • Gemma 4 MoE çıkarımı için kullanılan ik_llama.cpp, llama.cpp fork’u ve varsayılan olarak asgari koşul olarak AVX2 kabul ediyor
  • Derleme sırasında GGML_USE_IQK_MULMAT kapatılırsa hızlı yolların çoğu devre dışı kalıyor ve genel scalar/SSE işlemlerine fallback yapılıyor
    • genel Q8_0 matris çarpımında bu fallback çalışıyor
    • ancak iki grafik işlemine fallback uygulanmıyordu
  • Gemma 4’ün MoE feedforward ağı şu işlemleri üretiyor
    • MOE_FUSED_UP_GATE: uzman başına gate·up matris çarpımı ile SwiGLU’yu birleştiren işlem
    • FUSED_UP_GATE: MoE olmayan katmanlarda kullanılan yoğun işlem sürümü
  • Hesap dispatcher’ındaki bu iki işlem GGML_USE_IQK_MULMAT koşuluyla korunuyordu, fakat grafik oluşturucu işlemleri koşulsuz üretiyordu
    • AVX2’siz derlemenin dispatcher’ında bu enum’ları ele alan bir case yoktu
    • işlem varsayılan dala düşüyor, tüm uzman feedforward ağlarının hedef tensörleri sessizce hesaplanmadan kalıyordu
  • Gemma 4 26B, 30 katmanda token başına 8 etkin uzman kullandığından, her forward geçişte bellek tamponunda kalmış değerleri içeren yaklaşık 240 tensör tüketiliyordu

Anlamsız çıktıda görülen ipuçları

  • Hatalı çıktı akıcı görünüyor ama anlam içermeyen çok dilli dizelerden oluşuyordu
    • 262.000 sözcüklük tüm sözlükte token ID’leri neredeyse eşit yayılıyordu
    • Tayca, Korece, <unused> sentinel’leri ve İngilizce parçaları benzer sıklıkla üretiliyordu
  • Sıcaklık 0 iken çıktı deterministikti; tek iş parçacıklı ve çok iş parçacıklı çalıştırmaların sonucu da byte düzeyinde aynıydı ve NaN oluşmuyordu
  • Katman bazında büyük sabitler gizli durumu itiyor ve son softmax’ı düzleştiriyordu
  • Claude, örnekleme öncesi ham logit’leri enstrümante ederek ilk 5 token’ı, aralığı, ortalamayı ve NaN sayısını yazdırdı
    • ilk tahmin token’ının ortalama logit’i 0 civarında değil, +16 idi
    • tüm sözlüğün yaklaşık %80’inde logit pozitiftı
  • Rastgele bozulmadan farklı olarak sapma tutarlı olduğu için, gizli durumun büyük bölümünün küçük pozitif kayan nokta değerleri içeren başlatılmamış belleği kullandığı sonucuna varıldı

Üç aşamalı düzeltme

  • Yama, fork’un main dalı üzerine üç commit’ten oluşuyor

  • AVX2’siz derleme düzeltmeleri

    • iqk_quantize.cpp içindeki quantize_row_q8_0_x4 ve quantize_row_q8_1_x4_T için scalar #else dalları gerçekte hsum_i32_8 gibi AVX2 yardımcılarına başvuruyordu
    • Bu dallar taşınabilir scalar döngüler olarak yeniden yazıldı
    • ggml.c ve ggml-quants.c içine sızan bazı IQK çağrılarına #if GGML_USE_IQK_MULMAT koruması eklendi
    • iqk_cpu_ops.cpp dosyasının bağımsız derlenebilmesi için eksik include eklendi
    • Bu düzeltme olmadan fork’un kendisi AVX2’siz donanımda derlenmiyor

  • Çalışma zamanında grafik fallback’i

    • Dispatcher’ı düzeltmek yerine grafik oluşturucu, ilgili derlemede zaten hesap yolu olan işlemleri üretecek şekilde değiştirildi
    • ggml_moe_up_gate içinde GGML_USE_IQK_MULMAT kapalıyken birleşik up_gate_exps ağırlıkları işlendi
    • Tensör şekli [n_embd, 2*n_ff, n_experts]; ilk yarı gate, ikinci yarı up
    • Bunlar iki ggml_view_3d dilimine ayrıldı
    • Her dilim için ggml_mul_mat_id çalıştırıldı
    • İki sonuç ggml_fused_mul_unary(gate, up, SILU) ile birleştirildi
    • Gate ve up ağırlıkları zaten ayrıysa, dilimleme olmadan iki ggml_mul_mat_id ve birleşik çarpma·unary işlem kullanıldı
    • MoE olmayan katmanlarda kullanılan ggml_fused_up_gate için de aynı fallback uygulandı
    • mul_mat_id varsayılan ggml uygulamasını kullanıyor ve fused_mul_unary SILU ile çarpmayı tek adımda işlediği için, tüm bileşen işlemler için IQK dışı uygulamalar zaten mevcut
    • Tüm değişiklik #if !GGML_USE_IQK_MULMAT arkasında olduğundan AVX2 derleme çıktısı eskisiyle bit düzeyinde aynı kalıyor

  • CI stub düzenlemesi

    • IQK kaynaklarındaki #else stub’ları iqk_mul_mat.h ile uyuşmadığı için ci/run.sh de AVX2’siz donanımda derlenmiyordu
    • <cstdint> include’u eksikti
    • Bazı stub’ların gereksiz ön parametreleri vardı ya da sinks parametresi eksikti; yani imzalar farklıydı
    • Bazı işlevlerde stub hiç olmadığından bağlama aşamasında tanımsız başvuru hataları oluşuyordu
    • Stub’lar başlık dosyasıyla uyumlu hâle getirilince AVX2’siz ortamda test paketi çalıştırılabilir oldu

Fallback’in performans maliyeti ve repack hatası

  • Fallback, tek bir birleşik çekirdek yerine iki kez mul_mat_id çalıştırdığı için ek maliyet getiriyor
  • Bu CPU zaten bellek bant genişliği kısıtlı ve asıl birleşik çekirdek de AVX2’ye özel olduğundan, bu ortamda vazgeçilen mevcut bir çalışma yolu yoktu
  • Nihai performans, 26B-A4B MoE için decode’da yaklaşık 5,2 token/sn ve prompt değerlendirmesinde yaklaşık 16 token/sn
  • --run-time-repack, başlangıçta nicemlenmiş ağırlıkları AVX2’ye özel iç içe geçmiş Q8_0_R8 biçimine yeniden düzenliyor
    • Bu, AVX1 ortamında çıktıyı yeniden bozan ayrı bir hata
    • Mevcut yama bunu düzeltmiyor ve çalışma betiğinden bu bayrak çıkarılıyor

Nedeni daraltma süreci

  • Komut kümesi uyumsuzluğu kolay doğrulandı, ancak dispatcher’ın hata vermeden varsayılan dala düşmesi daha zor bulundu
  • Kod incelemesiyle birçok aday elendi
    • RMSNorm yardımcıları doğru görünüyordu
    • ggml_vec_dot_q8_0_q8_0 için AVX1 fallback’i de doğru görünüyordu
    • Tek iş parçacıklı sonucun bit düzeyinde aynı çıkması, threading hatasını dışladı
  • Logit ortalamasının +16’da sabitlenmesi ve uzun kuyruktaki token’ların benzer değerlere sahip olması, residual stream’in büyük kısmının başlatılmamış olduğunu düşündürdü
  • Dispatcher içinde #if GGML_USE_IQK_MULMAT arandıktan yaklaşık 1 dakika sonra eksik iki işlem yolu bulundu

Yeniden üretim koşulları ve kullanım alanı

  • AVX2 öncesi donanımda yeniden üretim koşulları şöyle
    • Donanım: çift Xeon E5-2690 v2, Ivy Bridge, AVX1, DDR3, GPU yok
    • Derleme: yama dalındaki ik_llama.cpp, GGML_USE_IQK_MULMAT olmadan derlenmiş
    • Model: Gemma 4 26B-A4B Q8_0
    • Çalıştırma: olağan ik_llama.cpp CPU bayrakları kullanılmalı, ancak --run-time-repack hariç tutulmalı
  • Tam değişiklikler ikawrakow/ik_llama.cpp PR #2138 içinde görülebilir
    • Yazı yazıldığı sırada hâlâ açık ve yönetici incelemesini bekliyor; bu yüzden doğrudan branch üzerinden çalıştırmak gerekiyor
    • Aynı donanımda görülen hatalar PR başlığı altında raporlanabilir
  • Eski kurumsal sunucularda yerel model tutmak, ücretli API kesildiğinde bir yedek olarak kullanılabilir ya da token başı ücretlendirmenin uygun olmadığı yavaş batch işleri işleyebilir
  • Abonelik hizmeti kullanmaktan çok tanıdık olmayan kodu ve eski sistemleri bizzat kazıma becerisine değer veriliyor; bu yaklaşım 15 yıllık bir Rails uygulamasını ya da sorumlusu ayrılmış bir veritabanını ayakta tutmada da aynı şekilde geçerli

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News yorumları

  • 2027 ortasına gelindiğinde 200 milyardan fazla parametreli uzman karışımı (MoE) modellerinin sıradan tüketici donanımında çalıştırılabileceğini tahmin ediyor.
    16 GB’lık bir Mac’te Qwen3.6-35B-A3B’yi yerel olarak çalıştırıp saniyede 7-9 token alıyorum: https://github.com/deepanwadhwa/samosa-chat
    Bu, 16 GB RAM’li bir MacBook Air’de GPT-4 seviyesinde bir modelin bu hızda yerel çalışması demek.

    • O zamana kadar beklemeye bile gerek olmayabilir. Prism’in birkaç gün önce yayımladığı üçlü ağırlık modeli Bonsai 27B yalnızca yaklaşık 7 GB ve M4 Max dizüstünde saniyede 44 token’ın üzerine çıkıyor: https://huggingface.co/prism-ml/Ternary-Bonsai-27B-mlx-2bit
      Zaten çoğu 200 milyar+ modelin etkin parametre sayısına yakın bir aralıkta; bu yüzden Prism isterse böyle bir model çıkarabilir. Ancak HRM gibi özyinelemeli sinir ağları o kadar çok parametreye ihtiyaç duymadığından, gerçekten bu ölçeğe gerek olup olmadığı tartışmalı: https://huggingface.co/sapientinc/HRM-Text-1B
    • Saniyede 7-9 token iyi bir hız sayılmaz. Uzman değilim ama yerelde denemelerimde saniyede 12-16 token’ın altı bunaltıcı gelmişti.
    • Tahmine genel olarak katılıyorum ama zamanlamanın biraz daha geç olabileceğini düşünüyorum. Böyle sonuçlar için, bugünkü gibi parametre başına bit sayısını düşürmekten tamamen farklı bir sıkıştırma gerekecek; o durumda da mevcut parametre sayısı ölçütünün kendisi anlamsız olabilir.
      Örneğin her katmanda yalnızca 256 bitlik bir seed tutup bunu bir gürültü fonksiyonuna vererek 16K gerçek ağırlık üretirseniz, ağırlık başına depolama boyutunu 1 bitin altına indirebilirsiniz.
    • Ornith 35B’yi Pi üzerinde çalıştırıp saniyede 50 token’ın üzerinde alıyorum. Pi’nin arama ve getirme işlemlerini de desteklediğini öğrendiğimden beri arama için büyük model aramama gerek kalmadı.
      Bu ay ve gelecek ay oyunu değiştirecek yeni modellerin peş peşe çıkacağını düşünüyorum, heyecan verici. Ornith kesinlikle denenmeye değer.
    • Saniyede 9 token katlanması zor değil mi? Claude oturumlarında bir günden kısa sürede 1 milyon token kullanmak yaygın; gerçek işlerde çok yavaş görünüyor.

  • Bunu duymak istemeyenler olabilir ama çıkarım sağlayıcılarının token maliyetinin yerel çalıştırmadaki elektrik maliyetinden ucuz olduğunu düşünüyorum.
    Basitleştirmek için yalnızca çıktı üretimini hesaplarsak, saniyede 5 token saatte 18.000 token eder ve sağlayıcı maliyeti yaklaşık 0,005 dolardır. Sunucunun çıkarım sırasında yaklaşık 500 W tükettiğini ve elektrik fiyatının kWh başına 0,3 dolar olduğu Almanya’yı baz alırsak, aynı miktarı yerelde üretmek 0,15 dolara gelir; yani 30 kat daha pahalıdır.
    Gizlilik konusunda endişeniz varsa yerel çalıştırma hâlâ iyidir, ancak çıkarım sağlayıcılarına göre çok daha verimsiz olduğunu bilmek gerekir. Yeni GPU’lar çıkarım verimliliğini artırdıkça bu fark da ciddi biçimde açılacaktır.
    Başta 180 bin token olarak yanlış hesaplamıştım ama aslında 18.000 token; dolayısıyla elektriği neredeyse bedavaya kullanmıyorsanız rekabet etmek zor. Sağlayıcılar küçük modeller için hâlâ H200/H100 kullanıyor olmalı; GB300’e ya da gelecek yılın Ruby GPU’larına geçtiklerinde çıkarım maliyeti otuzda bire düşecek ve yerel modellerin başlıca değeri gizlilik olacak gibi görünüyor.

    • Evde Qwen 27B çalıştırdığımda iş sırasında yaklaşık 400 W tüketiyor; üretim hızı saniyede yaklaşık 40 token, daha önemli olan prompt işleme hızı ise saniyede yaklaşık 1.000 token.
      Bir saatte 3,6 milyon giriş token’ı işleyebilir ya da 144.000 token üretebilir; elektrik maliyeti yaklaşık 0,15 dolar. Sonnet ile aynı miktarı işlemek giriş için 7,2 dolar, üretim için 1,4 dolar eder; yani bulut üretimde 10 kat, işlemede ise neredeyse 50 kat daha pahalı.
    • ABD’de kWh başına 0,30 dolara yaklaşmıyor bile. Kullanımın düşük olduğu saatlerde bunun yarısı; ayrıca bir bataryaya 1.000 dolar yatırıp çok ucuz saatlerdeki 0,11 dolarlık elektriği depolayabilirsiniz.
      Çıkarım sağlayıcıları büyük borç yüküyle pazar payı için yarışıyor; fiyatların kesinlikle artacağı açık.
    • Güneş enerjisi ve bataryayla çalışan bağımsız, kendi kendine barındırılan bir LLM sunucusu yapmak harika olurdu. Low Tech Magazine gibi, güneş yetersiz olduğunda çevrimdışı olur; arkadaş grupları, sokaklar, kulüpler gibi yerel toplulukların günlük kullanımına yetecek ölçekte kurulur.
      Yapay zekayı topluluğun doğrudan kontrol edebileceği kadar demokratikleştirirseniz veri merkezi sorununu da çözebilir, sansür ve hizalama düzeyini de topluluk demokratik biçimde belirleyebilir. Geohotz’un bazı yazılarına benzer bir fikir.
      Açık kaynak modeller yakında ikinci el donanımla ucuza hizmet verilebilecek kadar iyi ve verimli hâle gelecek. Küçük her toplulukta teknolojiye yatkın bir kişi birkaç yüz dolarlık başlangıç maliyetini toplarsa, sonrasında elektrik masrafı olmadan neredeyse ücretsiz işletilebilir.
      https://solar.lowtechmagazine.com/
    • Verimlilik de önemli ama elektriği ucuz olan ya da verimli ekipmana sahip çok kişi var. AMD Strix Halo ev sunucusunda yalnızca 100 W kullanarak Gemma4-26B’yi yaklaşık saniyede 70 token hızında sunabiliyorum.
    • Daha pahalıya gelip gelmediği umurumda değil. Yerelde çalıştırma nedenim para tasarrufu değil, özgürlük ve gizlilik elde etmek; ayrıca bir seçenek var olduğunda uzun vadede maliyetler de düşer.
      Yerel alternatif olmasaydı bulut model fiyatları çok daha pahalı olurdu.

  • Bu neslin çift Xeon’ları yük altındayken 300 W’tan fazla tüketme olasılığı yüksek. ABD ortalama elektrik fiyatıyla günde 1,35 dolar eder; yazın bulunduğu alanı soğutmanız gerekiyorsa daha da artar.
    Prompt işleme süresini yok saysanız ve 24 saat çalıştırsanız bile günde yaklaşık 400 bin token üretir; yani 1 milyon çıktı token’ı başına yaklaşık 0,30 dolar. Tesadüfen bu, OpenRouter’da bu modelin güncel fiyatıyla aynı, ancak OpenRouter’ın üretim hızı 8 kat daha yüksek.
    Verilerin ev dışına çıkmamasını sağlamak gibi yerel LLM denemek için pek çok neden var, ancak maddi olarak kazançlı çıkmak zor. Evdeki yerel çıkarım donanımına çok daha fazla para yatırmış biri olarak, eğlenceli olsa da bir tasarruf yöntemi olmadığını düşünüyorum.

    • Gerçek bir müstakil evde yaşayan biri için makul bir hesap. Ben kiralık evde yaşıyorum ve elektriği doğrudan ödemiyorum; bu yüzden maliyet verimliliğinin sınırı ev sahibinin şikâyet etmeye başladığı nokta.
    • Bence çoğu kişi modelleri para biriktirmek için değil, kişisel verilerini yaymamak için yerelde çalıştırıyor.
    • Kripto paraya benziyor. Elektrik maliyetleri yüzünden çoğu kişi için doğrudan madencilik yapmak yerine satın almak daha ucuz.
    • Evde ısıtmayı açtığınız soğuk mevsimlerde atık ısıyı da kullanabildiğiniz için ekonomisi daha iyi hâle gelir.

  • GPU olmadan çift Xeon ve 256 GB DDR4 üzerinde çeşitli modelleri çalıştırma sonuçlarını derledim.
    https://gist.github.com/hparadiz/f3596d00a62d8ebb2dadcc46ee5822c7

    • NUMA performans düşüşünü ortadan kaldırmak için yalnızca tek CPU kullanmayı denediniz mi merak ediyorum. Belleğin yalnızca yarısını kullanabilecek olursunuz ama performans farkının ne kadar olduğunu bilmek isterim.
    • Çok fazla yavaş RAM varsa küçük modeller de epey hızlı çalışıyor gibi görünüyor. Bu makinede daha büyük modellerin nasıl çalışacağını merak ediyorum.

  • Oldukça yavaş sayılır. 13 yıllık bir CPU’da bile saniyede 8–12 token alıyorum; bağlam boyutuna ve diğer ayarlara göre değişebilir.
    https://news.ycombinator.com/item?id=48354801

    • Xeon E3-1270 V2 3.50 GHz ve eski bir Nvidia Quadro K2200 4 GB ile de saniyede 8–9 token alınıyor. Ollama’da gemma4:e2b ve gemma4:12b-it-qat çalıştırıyorum.
    • Asıl yazının Q8 kuantizasyonu kullanıp burada Q4 kullanılıyor olması gibi bir fark yok mu?

  • Asıl yazının yazarıyım. Görünüşe göre orijinal yorum bir nedenle şikâyet edilip işleme alınmış. Düzeltmeleri üst projede PR #2138 olarak açtım: https://github.com/ikawrakow/ik_llama.cpp/pull/2138

  • Bu StoreVirtual cihazında yazılım kurmak için kullanılabilecek pek port yok gibi görünüyor. Sadece USB portu var gibi; kurulumun seri konsol üzerinden mi yapıldığını merak ediyorum.

  • Aynı yapılandırmayla 2013 Mac Pro’da Gemma 4 26B çalıştırıyor ve saniyede yaklaşık 5 token alıyorum. Çift ekran kartı burada işe yaramıyor ama bazı işler için yeterince pratik.

  • Bodrumdaki kurulumu bizzat gördüm; gerçekten harika. Bir dahaki sefere 3D yazıcıyı da tanıtırsan iyi olur.

  • Biraz ilgili bir video: Pentium 4 üzerinde LLM çalıştırıyor ve buna NetburstGPT takma adını vermiş. Elbette çok yavaş.
    https://www.youtube.com/watch?v=ILV-eu90te8