10 yıllık bir Xeon yeterli

 (point.free)
5 puan yazan GN⁺ 4 시간 전 | 2 yorum | WhatsApp'ta paylaş
  • Gemma 4 26B-A4B, 2016 model tek bir Intel Xeon E5-2620 v4, 128GB DDR3 ve GPU'suz bir sunucuda ik_llama.cpp optimizasyonlarıyla okuma hızına yakın seviyede çalıştırıldı
  • LLM decoder geçişinde darboğaz hesaplamadan çok bellek bant genişliği; CPU, bir sonraki ağırlıkları RAM'den önbelleğe getirmeyi beklerken ciddi zaman harcıyor
  • --spec-type mtp, --cpu-moe, --merge-up-gate-experts, --run-time-repack gibi seçenekler, MTP speculative decoding, MoE yönlendirmesi ve önbellek dostu bellek yerleşimiyle DDR3 ortamındaki darboğazı azaltıyor
  • Loglara göre toplam bellek gereksinimi 82,355MiB ve tam 262K context içinde KV cache yaklaşık 56GB ile, yaklaşık 25GB'lık ağırlıklardan daha büyük
  • ollama gibi kara kutu araçlar gerekli model desteği ve ince ayar düğmelerini yeterince sunmuyor; eski donanımda performans almak için inference motorunu ve bellek yapısını derinlemesine anlamak gerekiyor

Çalışma ortamı ve temel darboğaz

  • Test sunucusu yeniden kullanılmış bir donanım ve özellikleri Intel Xeon E5-2620 v4 @ 2.10GHz, 8 çekirdek 16 thread, AVX2, 20MiB L3 cache, 2MiB L2, 128GB DDR3, GPU yok
  • Bu CPU, AVX-512, AVX-VNNI, BF16 desteklemiyor ve dahili GPU da içermiyor
  • LLM inference'ta token'ları tek tek üreten decoder geçişi esas olarak hesaplama gücünden değil, bellek bant genişliğinden etkileniyor
  • Bir sonraki token'ı hesaplamak için modelin eğitilmiş bilgisini taşıyan ağırlıkların RAM'den CPU cache'ine ve çekirdeklere sürekli taşınması gerekiyor; işlemci, matris hesaplamasından çok sıradaki ağırlıkların gelmesini bekliyor
  • Bu tür bir “memory wall”, yalnızca Xeon'da değil H100 gibi yüksek performanslı donanımlarda da önemli bir performans engeli olarak ortaya çıkıyor

Kara kutu araçlar yerine gerekli çalışma düğmeleri

  • DDR3 ve GPU'suz bir ortamda llama-cli'yi doğrudan çalıştırmak çok yavaş kalıyor ve genel GPU kullanım senaryolarına göre yapılmış optimizasyonlar nedeniyle ciddi iyileştirme alanı bulunuyor
  • ollama, gerekli model desteğini sunmayabiliyor ve çalışma performansını gerçekten yukarı çekmek için yeterli ayrıntılı ayarı açığa çıkarmıyor
  • Gerçek çalıştırma, ik_llama.cpp'nin sunduğu çok sayıdaki flag'in birlikte kullanılmasını gerektiriyor
  • Temel flag grubu şöyle
--spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune  
-sm graph -smgs -sas -mea 256 --split-mode-f32  
-t 8 --parallel 8  
--cpu-moe --merge-up-gate-experts  
--flash-attn on --mla-use 3  
--mlock --run-time-repack --no-kv-offload

Speculative decoding ve MoE optimizasyonu

  • --spec-type mtp --draft-max 3 --draft-p-min 0.0 --spec-autotune, 26B verifier'ı daha önce oluşturulmuş küçük bir MTP drafter ile birlikte kullanıyor
  • --draft-max 3, taslak başına en fazla 3 token; --draft-p-min 0.0, tüm olasılıkların kabulü; --spec-autotune ise zincir uzunluğunu iş yüküne göre ayarlıyor
  • Uzun inference zincirleri üretilirken kullanıcıya yalnızca kısa bir son yanıt görünse bile, gizli düşünce token'larının her biri için tam decoder geçişi gerekiyor
  • CPU'da verifier ağırlıklarını cache'e akıtmanın maliyeti yüksek; küçük drafter'ın aktif katmanları ise L3 cache'e iyi sığdığı için speculative decoding'in avantajı daha da belirginleşiyor
  • Gemma 4 26B-A4B, 128 uzman içinden token başına 8'inin etkinleştiği bir MoE yapısına sahip; toplam yaklaşık 25.2B parametrenin yalnızca yaklaşık 3.8B'si aktif
  • --cpu-moe, yönlendirmeyi CPU cache hiyerarşisine göre ayarlıyor ve 128 uzman arasında sürekli gidip gelmenin yarattığı, cache'i boşaltıp veriyi DDR3'ten yeniden çekmeye zorlayan cache thrashing'i azaltacak şekilde çalışıyor
  • --merge-up-gate-experts, uzman içindeki up projection ile gate projection'ı tek bir matris çarpımında birleştiriyor; loglarda bu durum fused_up_gate = 1 olarak görülüyor
  • -t 8, 8 fiziksel çekirdeğe uygun ayar; bellek darboğazlı iş yüklerinde 16 SMT thread'inin tamamını kullanmak, throughput'tan çok zamanlama maliyetini artırabiliyor

Belleği sabitleme, yeniden yerleşim ve grafik bölme

  • --run-time-repack, inference'tan hemen önce ağırlık matrislerini CPU cache yerleşimine göre yeniden düzenliyor; loglarda Repacked 265 tensors olarak görünüyor
  • Bu ayar başlangıçta birkaç saniyelik bir maliyetle RAM içindeki sayı tablolarını CPU'nun daha verimli okuyabileceği biçime yerleştiriyor ve gerçek metin üretimi sırasında bellek bant genişliğinin en üst düzeyde kullanılmasını sağlıyor
  • --mlock, modeli RAM'e sabitliyor ve işletim sisteminin onu diske swap etmesini engelliyor
  • Çekirdekteki memlock sınırı yeterli değilse failed to mlock 27628376064-byte buffer ve Try increasing RLIMIT_MEMLOCK uyarıları çıkıyor; bu, LLM'e özgü bir sorun değil, varsayılan ulimit ayarının sonucu
  • --no-kv-offload, GPU olmayan ortamda KV cache'i GPU'ya taşımaya yönelik denemeleri atlıyor ve onu sistem RAM'inde tutuyor
  • -sm graph, hesaplama grafiğini dikey olarak bölerek birden fazla işlem biriminin veya bellek bölgesinin aynı katmanın farklı parçalarını eşzamanlı hesaplamasını amaçlayan bir grafik bölme deniyor
  • Bu çalıştırmada Split mode 'graph' is not supported for Gemma4 external MTP loguyla birlikte güvenli biçimde katman bölmeye geri düşülüyor
  • -sas, iş yükünün fiziksel CPU socket'leri veya NUMA düğümleri arasında bölünmesini söylüyor; --split-mode-f32 ise bölünüp yeniden birleştirilen ara noktalarda 32 bit kayan nokta hassasiyeti kullanılmasını sağlıyor

Attention, bellek kullanımı ve sonuç

  • ikawrakow, CPU üzerinde Flash Attention çalıştıran özel kernel'ler yazarak ağır context işlemlerinin GPU olmadan yapılmasını sağladı
  • --flash-attn on, attention softmax ile matris çarpımını birleştiriyor; böylece tam N×N attention matrisi RAM'e fiziksel olarak yazılmadan, küçük parçalar halinde cache içinde hesaplanıp tüketiliyor
  • --mla-use 3, Multi-Head Latent Attention'ı etkinleştirerek KV cache'teki Key ve Value'ları daha küçük latent gösterimlere sıkıştırıyor
  • Loglarda flash_attn = 1, fused_moe = 1, fused_up_gate = 1 görünüyor; yani ilgili optimizasyonlar gerçekten uygulanmış
  • Bellek loglarına göre tüm katmanların toplamı 81,607.46MiB ve model tensor'ları ile cache için gereken toplam bellek 82,355MiB
  • Tam 262K context'te ağırlıklar yaklaşık 25GB, KV cache ise yaklaşık 56GB; yani KV cache modelin kendisinden daha büyük
  • Bu kurulum, 25B parametreli bir MoE'yi yükleyip MTP drafter ile speculative decoding yaparak 2016 model Xeon, DDR3 ve GPU'suz bir sunucuda okuma hızında metin üretiyor
  • Sonuç olarak modern açık ağırlıklı yapay zekayı yerelde çalıştırmanın darboğazı yalnızca silikon değil; inference motorunun davranışını ve bellek yapısını anlamak da kritik. Doğru fork, uygun quantization ve bellek mimarisi bilgisiyle eski sunucularda da çalıştırmak mümkün

İlgili okumalar

2 yorum

 
GN⁺ 4 시간 전
Hacker News görüşleri

  • Yeni Gemma 4 Drafter modelini çalıştırmanın yollarının az olması ve ana akım araçların performans ayar noktalarını gizlemesinin yarattığı hayal kırıklığı nedeniyle bu yazıyı yazdığını söylüyor.
    Sonunda, GPU olmadan, yalnızca tek bir Xeon E5-2620 v4 ve 128GB DDR3 RAM bulunan eski bir geri dönüştürülmüş sunucuda en yeni 26B MoE modelini okuma hızında çalıştırmayı başarmış.
    Yazının sonunda kuantize modeli de linklemiş ama bahsettiği ik_llama-cpp fork’unu kullanmazsanız çalışmayacağını, ayrıntılar için başka bir yazıya bakmak gerektiğini belirtiyor.
    Kendisi bir makine öğrenimi mühendisi değil ve sunucu da Nix cache göreviyle meşgul, ama soru olursa elinden geldiğince yanıtlayabileceğini söylüyor.

    • Eğer iş yükü bellek bant genişliğiyle sınırlıysa, SMT’nin aksine tipik olarak faydalı olduğu durumlardan biri bu değil mi diye merak ediyorum.
      Sonuçta bir thread DDR3’ü beklerken diğer thread çalışabilir.
      Ayrıca --cpu-moe açıklamasını da pek anlayamadım. Bir uzman yaklaşık 4.0GiB parametreye sahipken ve L3 cache yalnızca 20MiB ise, uzman sırasını optimize etseniz bile parametreleri anlamlı şekilde cache’lemek mümkün görünmüyor.
      Başkalarının da söylediği gibi Intel Xeon E5-2xxx v4 serisinin yalnızca bazı modelleri DDR3 destekliyordu ve Intel belgelerine göre E5-2620 v4 bunlardan biri değil.
    • Gerçekten pratik açıdan harika bir sonuç. Benzer bir Dell T7610 iş istasyonunda benzer ya da daha iyi performans alınıp alınamayacağını merak ediyorum.
      Çift Xeon ve 128GB DDR3 yapılandırması var; CPU tarafında toplam 24 çekirdek/48 thread sunan 2 × Xeon E5-2697 v2 kullanıyor, bu yüzden çekirdek sayısı daha iyi ama pratikte fark çok büyük olmayabilir.
      Tozlanan bir cihaz ama okuma hızında Gemma için oldukça umut verici.
    • 2 yıl önce Amazon’dan yenilenmiş 2× E5-2690v4 sunucu, 128GB RAM ve bir Dell T7810’u 500 doların altında aldım.
      Amazon’da “chia farming” diye arayın ama chia seeds ilanlarını geçin.
      Şimdi aynı ekipman yaklaşık 2,5 kat daha pahalı ama yine de güncel nesil DDR5 makinelerden çok daha ucuz.
      https://www.amazon.com/dp/B095TRGCSX
    • Bunun gerçekten DDR3 olduğundan emin değilim. Evde iki tane E5 v4 sistemim var ve ikisi de DDR4, bu yüzden 2011-3 soketin hem DDR3 hem DDR4 destekleyip desteklemediği konusunda kafam karıştı.
    • Bu kurulum benim durumuma tam uyuyor gibi görünüyor.
      Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz, online CPU 0-31, 128GB RAM yapılandırmam var.
      8 DIMM slotu olduğunda bellek bant genişliğinin gerçekten artıp artmadığını merak ediyorum. Şu anda bu zavallı makineyi sadece YouTube izlemek için kullanıyorum.

  • Henüz tam o noktada değiliz ama mevcut balonun biteceği bariz son durak, yerel donanımda ve cihazlarda çalışan açık modellerin çoğu kullanım için “yeterince iyi” hale gelmesi.
    Bu olursa şu anda teknoloji sektöründe olan biten her şey tamamen çökebilir.

    • Bu benim için bile şimdiden oldu. CoPilot fiyat değişikliği üzerine aboneliğimi iptal ettim ve yalnızca VRAM içinde çalışan bir yerel kodlama modeli kurdum.
      Gerçekten tıkandığımda Claude API’yi çağırırım ama ihtiyaçlarımın %80’ini daha aptal bir yerel modelle karşılayabilirmişim gibi görünüyor.
      Programlama dilleri ve teknikler çok değişmediği için bunu en az 5 yıl kullanabilmeyi umuyorum; aynı VRAM’e daha akıllı modeller sığacak şekilde optimizasyonlar geldiğinde o zaman yükseltme yaparım.
      Bu yönü seviyorum.
    • Amazon açısından bakınca açık modelleri çalıştırıp saati, çalıştırma maliyetine yakın bir fiyattan satmak daha avantajlı olmaz mı diye düşünüyorum.
      Bunu neden yapmadıklarına dair tahminim, şu anda AI laboratuvarlarının modelleri büyük zararlarla satıyor olması; bu yüzden Amazon için düşük marjlı hesaplama, diğer yüksek marjlı ürünler kadar cazip olmayabilir.
      Mevcut durumun çökmesi için bunun mutlaka yerelde çalıştırmaya kadar gitmesi gerekmeyebilir. AI laboratuvarlarının bedava para pistinin sonuna gelip modelleri gerçek çalıştırma maliyetinin üstünde fiyatlamak zorunda kaldıklarında, elinde hesaplama gücü olan herkesin açık model hizmetlerini genel piyasa fiyatlarının altında sunması için teşvik oluşur.
    • OpenAI ve Anthropic sonuçta birer AI şirketinden çok hesaplama altyapısı işletmesine daha yakın.
      Herkes modelleri elde edip çalıştırma becerisine kavuşacak ve bu yüzden GPU kıtlığı onların lehine işliyor.
    • Yeni doğmuş trilyon dolarlık şirketler için bu en kötü senaryo.
      Tüm umutları, büyük ve orta ölçekli şirketlerin tüm iş süreçlerini buluta taşımasına ve çalışanların mümkün olduğunca çok token kullanmak için yarışmasına bağlı.
    • Bunun tamamen çökeceğini söylemem ama o yöne gittiğimiz açık.
      “Yeterince iyi” modellere mahremiyet ve uzun vadeli maliyet tasarrufu da eklenince ortaya çekici bir tablo çıkıyor.
      Paradoksal biçimde, kodlama ajanları için genel amaçlı yürütme ortamları ne kadar iyileşirse Claude gibi hizmetlerin hendeği o kadar daralıyor. Birkaç ay önce en öndeki modelleri bazı açık modellerin ne kadar hızlı yakaladığını görmek inanması zor bir şeydi.

  • Yazı da güzel, teknik açıdan da etkileyici. Derleme pipeline’ını anlamak ve yerelde çalıştırabilmek gerektiğine katılıyorum.
    Ancak elektrik fiyatına bağlı olarak ekonomik olmayabilir. Eski sunucular enerji verimliliği açısından zayıf ve eski Xeon sunucuların yük altında yaklaşık 200W çektiğini düşünüyordum; oysa aynı model OpenRouter’da 1 milyon token başına 0.1/0.3 dolar, 76 token/sn ve 262k context ile sunuluyor.
    Üstelik bu tür sunucular gürültülü oluyor. Yine de 200W tahminim fazla yüksekmiş gibi görünüyor; geçmişte kullandığım eski Xeon sunucular çok elektrik tüketirdi ama tam modellerini hatırlamıyorum.

    • 2620v4 elektriği sömüren bir canavar değil. Anakartına göre değişir ama sunucuların hepsi ille de öyle değildir.
      Sunucular genelde gürültülüdür ama bu da yapılandırmaya göre değişir. Bu tür çiplere dayalı çok ucuz hosting var ve güç verimliliği düşünüldüğünden daha iyi.
    • Yük altında 85W’a daha yakın olur. Ucuz bir soğutucuyla bile çok sessizdir ve sıcaklık da nadiren 50°C’nin üstüne çıkar.
    • 1U ya da 2U kasaya koymak istiyorsanız gereken statik basıncı üretmek için yüksek hızlı fanlar gerekir; bu yüzden bu tür sunucular gürültülü olur.
      Benzer bir yapılandırmayı 4U kasa ve yavaş 120mm fanlarla çalıştırırsanız sorun olmaz.

  • Bunu başkalarının da fark ettiğini görmek sevindirici. 2012 model bir Xeon ve 16~24GB RAM’li bir konteynerde Gemma 26B-A4B Q4 çalıştırıyorum ve yaklaşık 8~12 token/sn alıyorum
    Büyük bağlamlar ya da GPU üzerinde çalıştırmayla kıyaslanamaz ve llama.cpp’nin görüntü çözücüsü de GPU’dan çok daha yavaş, ama küçük otomasyon işleri veya genel bilgi soruları için gayet yeterli. Okurken takip edebilecek kadar hızlı olduğu için bekleme daha az hissettiriyor
    Kurulum, OpenBLAS ve OpenMP etkin llama.cpp derlemesi, OPENBLAS_NUM_THREADS=4, OMP_NUM_THREADS=4, unsloth/gemma-4-26B-A4B-it-GGUF:UD-Q4_K_XL, q8_0 cache ve 8192 bağlam gibi ayarlardan oluşuyor
    CPU’ya göre AVX2 gibi optimizasyonlara bakmak gerekiyor; MTP’yi kısa süre denedim ama performans artışı olmadı. Cache·bağlam batch boyutunu ayarlayabilir ya da Q2’ye kadar düşürebilirsiniz; ayrıca fazla thread atamaktan kaçınmak iyi olur. Varsayılanlarla ya da llama-bench ile başlamanızı tavsiye ederim

    • Şu anda bir Frankenstein sistemi kuruyorum. Çin üretimi DDR3 X99 kart, 12 çekirdekli Xeon v3, 32GB 1866MT/s RAM ve 1080 Ti’dan oluşan bir kurulum
      Testlerde 11GB VRAM’e tamamen sığan gemma4:e4b-it-q4_K_M çalıştırdım ve 50 token/sn’yi aştı. O kadar küçük bir model kodlama için pek kullanışlı değil ama başka kullanım alanları olabilir
      Bunu Wake-on-Use ile kişisel ChatGPT gibi kullanmak istiyorum. Araya bir Pi proxy koyup Wake-on-LAN betiğini çağırmak mümkün olabilir; bir gün eğlenceli bir hafta sonu projesi olabilir
      Sürekli açık tuttuğum LLM, 12GB 2060’a yarısından azı sığan dense Gemma4:31b; çok yavaş ama kalitesi iyi ve otomatik kuyruk işleme için kullanıyorum, yani başında çıktıyı izleyip durmuyorum. Bir tane daha 2060 var ama ikisini birden takınca PC POST edemiyor
    • llama ve yerel hesaplama konusuna gelmişken, birkaç gün önce Georgi Gerganov Mac M2 Ultra veya RTX 5090 üzerinde yerelde Qwen3.6 27B çalıştırıp llama.cpp geliştirmesine yardımcı olduğunu tweetledi

  • Bir süre Mac Studio Pro’yu düşündüm ama sonunda bu yola girdim. HP Z620 headless makinede 192GB ECC RAM, çift Xeon E5-2680 v2, Optane AIC, 10GB VRAM’li iki P102-100, Debian 12.6 yüklü minimal boot SSD ve Pascal kartlarını destekleyen sabitlenmiş eski bir CUDA sürümü kurdum
    Bodrumdan AMT/meshcommander ile uzaktan kullanıyorum, llama.cpp ve frontend’i ayağa kaldırdıktan sonra yerel ağ üzerinden bağlanıyorum. Talkie, Qwen 3.6 27b ve medgemma ile uğraşıyorum; uygun quantization seçildiğinde GGUF performansı genel olarak gayet iyiydi
    Toplam maliyet 500 doların altındaydı ama sunucuyu geçen yıl eBay’den aldım, şimdi durum farklı olabilir
    İleride üçlü tabanlı LLM’ler yaygınlaşırsa bu eski donanımın aslında bilgiyle dolu yüksek yoğunluklu modelleri barındırabilmesini umuyorum. GPU RAM’inden büyük olup Optane’a taşsa da sorun değil; hızdan çok genel olgusal bilgi önemli
    Nihai planım, her şeyi ayarladıktan sonra bunu bodrumdaki Faraday çöp kutusunda saklamak ve dünya çökerse “medeniyeti yeniden kurma” amaçlı bir kâhin olarak bırakmak. Tabii böyle bir durumda asıl sorun elektrik olurdu, ama bu donanım bu kadar ucuzken ve modern yapay zeka bu kadar sık pratik işe yararken denemeye değer

  • Yapay zekadaki ilerlemenin en ilginç yanı AGI ya da belli bir yapay zeka unicorn’un en yeni modeli değil, yerelde ne çalıştırabildiğimiz
    6 yıl önce üst düzey bir oyun PC’sinde eğlenceli ama pek işe yaramayan modeller çalıştırıyordum; şimdi ise M5 dizüstünde ondan 100 kat daha iyisini çalıştırabiliyorum
    Pazar bellek kıtlığına tepki vermeye devam eder ve Apple silicon aynı hızla ilerlerse, 6 yıl sonra yerelde çalıştırabileceklerimiz çok ilginç ya da korkutucu olacak
    Bunun yapay zeka şirketlerinin değerlemeleri için ne anlama geldiğini de bilmiyorum. Eskiden bir etkinlikte o şirketlerden birinin çalışanına benzer bir soru sormuştum; cevap vermek yerine gidip kokteyl aldı

    • Söylenmemesi gereken şeyler var. Yapay zeka model işinde, savunulması kolay kalıcı bir teknik üstünlük yani bir hendek yok; sadece kısa vadeli avantajlar var
      Yapay zeka işi, eski fabrikalar gibi sermaye yoğun. Veri merkezleri pahalı, modeller çok elektrik tüketiyor ve iç donanımı her 3~4 yılda bir yenilemek gerekiyor
      Daha küçük ve özelleşmiş modeller alttan marjları kemiriyor. Transkripsiyon, ses ve görüntü tespiti için dev modellere gerek yok
      Geleneksel yazılım işleri gibi yüksek marj beklemek için bir neden yok; yapay zekanın kazancının çoğu tüketiciye gidiyor. Yine de Microsoft, Google, Amazon ve Meta gibi birkaç dev şirket ölçek ekonomisiyle maliyet avantajı yakalayabilir
    • Tüketici donanımında yerelde çalıştırılabilen seviye epey iyi ilerliyor
      5080 gibi en üst düzey olmasa da düzgün bir oyuncu GPU’su varsa, 2025 başındaki son teknolojiden daha iyi yerel modeller çalıştırabilirsiniz
      İstediğiniz işe göre model değiştirmeniz gerekebilir ve her şeyi tek başına yapan aşırı büyük modeller hâlâ veri merkezi alanında
    • Sonuçta mesele kullanışlılık. Wikipedia’dan sosyal medyaya, e-postadan video sunucularına kadar pek çok şeyi yerelde çalıştırabilirsiniz
      Ama tam zamanlı işi ve iki çocuğu olan çoğu insanın yamalama ve bakım için zamanı ya da enerjisi yok. Sistemler giderek daha karmaşık hale geliyor ve hata sayısı da artıyor. Bu, özgürlük ile kolaylık arasındaki eski ödünleşim
    • Bunun yapay zeka şirketi değerlemeleri üzerinde muhtemelen pek etkisi olmayacak
      Kullanıcıların çoğu LLM’in ne olduğunu ya da nasıl çalıştığını bilmiyor. LLM kullananların büyük kısmı işyerinde kendilerine ne verildiyse onu varsayılan olarak kullanıyor; biraz daha bilgili kullanıcılar bile OpenAI veya Anthropic aboneliği ödemeyi makul buluyor
      Yerel LLM’leri tercih eden küçük ama adanmış bir açık ağırlıklı model kullanıcı kitlesi oluşacaktır, ama geri kalanların büyük sağlayıcılardan tüketmesi daha olası. Bu, bugün işletim sistemi seçiminde olduğu gibi; az sayıda Linux kullanıcısı ve çoğunlukta Windows, macOS, Chrome kullanıcıları olması gibi olabilir
    • Yazılımda, özellikle oyunlarda, durum hep böyleydi
      5~6 yıllık oyunları çok daha ucuza alabilir ve sıradan donanımda çalıştırabilirsiniz. Ama sektör 5 yıl boyunca yerinde durmuyor; daha iyi donanım gerektiren yeni yazılımlar gelmeye devam ediyor

  • Asıl gönderi yazarı yorumlarda sonucun yaklaşık 12 token/sn olduğunu belirtmiş.
    Bu donanımda mümkün olacağını düşündüğümden çok daha etkileyici bir çaba, ancak tatmin edici bir etkileşimli oturum için gereken seviyenin hâlâ epey altında.

    • Özellikle bu kadar küçük modeller OpenRouter gibi platformlarda gerçekten ucuz ve hızlı.
      Çoğu zaman en güncel modellere göre 100~500 kat daha ucuz oluyorlar ve token/sn hızları da 2~5 kat daha yüksek olabiliyor.
    • O sonuca ulaşmak çok uzun sürmüş. Modelin SSD üzerinde bile çalıştırılabildiğini düşününce, yavaş RAM üzerinde çalışabilmesi şaşırtıcı değil.
    • Etkileşimli kullanım için o kadar da kötü değil: https://mikeveerman.github.io/tokenspeed/?rate=12&mode=text
      Arka plan işleri için gayet yeterli olur.
    • RSA şifrelemesi kâğıt, kalem ve bilimsel hesap makinesiyle de yapılabilir.
      Çalışır, ama ciddi işler için yeterli bir throughput sunmaz.

  • E5-2620 v4 harika. 10 yıldır kullanıyorum; yükseltmeyi düşünüyordum ama bugünkü fiyatları görünce vazgeçtim.
    64GB DDR4 ve RX 9060 XT 16GB ile oyunlar hâlâ hızlı çalışıyor. DOOM The Dark Ages'te CPU biraz darboğaz yaratabiliyor ama 60fps olduğu için sorun değil.
    Hafif LLM'leri GPU'da çalıştırmak zaten bariz tercih, ama CPU'da da ayarlayınca fena olmayan şekilde çalışabilmesi hoş.
    Bir ay önce 2667 v4'ü 30 dolara aldım; performans artışı muhtemelen kayda değer olur ama henüz ihtiyaç duymadım. Yazıdaki gibi LLM tarafını zorlayacaksam, 2667 biraz daha hızlı RAM'i desteklediği için muhtemelen yükseltme yaparım.

    • Dual E5 2667-v4, 256GB DDR4, Z640 ve 1080 Ti kurulumum var; 2025'in ilk yarısında SSD hariç tüm parçaları toplam 500 doların altında topladım.
      İkinci el piyasasında hâlâ bulunabilen şeylere oldukça şaşırıyorum.
      RAM ve GPU fiyatlarının bu kadar patlayacağını bilmiyordum ama zamanlama tesadüfen çok iyi oldu. eBay'de 300 dolar civarında bir 3080 yakalayıp 1080 Ti'yi satmayı düşünüyorum, ama onun dışında mükemmel bir yükseltmeydi.
      Elektriği Coca Cola içer gibi tüketiyor ama workstation olarak mükemmel çalışıyor; bozulana kadar zorlamayı planlıyorum.
    • Bir CPU'yu 10 yıl kullanmak gerçekten çok uzun geliyor.
      Eskiden ısı kaynaklı hasarın 5~7 yıl sonra CPU'ları öldürdüğünü sanırdım; bunun yanlış bir varsayım olup olmadığını merak ediyorum. Belki de günümüz CPU'ları eskisine göre çok daha güçlü ve dayanıklıdır.

  • Eski Xeon optimizasyonlarıyla ilgili yakın zamanda benzer bir yazı vardı.
    “High-Performance AI on a Budget: Optimizing llama.cpp for Qwen3.5 Inference on a Dual-GPU HP Z440”
    https://news.ycombinator.com/item?id=47320244

  • Şaşırtıcı şekilde Itanium da LLM'ler için epey uygun görünüyor: https://medium.com/@tglozar/running-llama-inference-on-intel...
    Düşününce mantıklı geliyor
 
cronex 1 시간 전

İçerik ilginçmiş. Eski bir Xeon sistemim var, bir kez denemem gerekecek.