2 puan yazan GN⁺ 5 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Yerelde en güncel seviye LLM ve konuşmadan metne dönüştürme çalıştırmak için donanım kurulumu, PCIe switch ayarları ve Docker çalışma yapılandırmaları tek bir depoda derlenmiş
  • Yaklaşık $2k bütçe, 2× RTX 3090 ile 48GB VRAM sağlayarak Qwen3.6-27B ve whisper-large-v3 tabanlı yerel STT çalıştırmayı hedefliyor
  • Yaklaşık $40k bütçe, 4× RTX PRO 6000 Blackwell Workstation ile 384GB VRAM sağlayarak Claude Opus’a epey yakın model zekâsı elde etmeyi varsayıyor
  • Gerçek 4× RTX 6000 Pro sistemi, ikinci el EPYC/DDR4 tabanlı ana sistem ile c-payne PCIe Gen4 switch birleşimini kullanarak GPU’lar arası P2P iletişimini CPU root complex yerine switch fabric içinde yürütüyor
  • BIOS, GRUB, ACS ve güç sınırı ayarları tamamlandığında P2P, 27.5GB/s tek yönlü, 50.4GB/s çift yönlü ve 0.37–0.45µs gecikmeyle Gen4 hat hızına ulaşıyor

Yerel LLM çalıştırmak için bütçe aralıkları

  • Bu kurulum, yerelde en güncel seviye modelleri ve konuşmadan metne dönüştürmeyi çalıştırmak isteyen kullanıcıları hedefliyor
  • Depoda kullanılan donanım, satın alma gerekçeleri, yapılandırma ipuçları, yerel STT’nin nasıl çalıştırıldığı ve Docker konteyner tabanlı model çalışma yapılandırmaları yer alıyor
  • README’deki tablo dışında kalan içeriğin AI tarafından yazılmadığına dair bir not bulunuyor
  • Yaklaşık $2k yapılandırma

    • Toplam 48GB VRAM için 2× RTX 3090 içeren bir yapılandırma öneriliyor
    • Bu yapılandırmada Qwen3.6-27B çalıştırılabiliyor
    • Yerel STT için whisper-large-v3 kullanılıyor; erişim için çapraz platform stt harness’i kullanılıyor
    • ./runners/stt içinde, Nvidia GPU’da yaklaşık 11GB VRAM varmış gibi varsayan kullanıma hazır bir STT yapılandırması bulunuyor
    • Yerel STT, barındırılan hizmetlerden daha rahat kullanılabilen bir araç olarak ele alınıyor
  • Yaklaşık $40k yapılandırma

    • Toplam 384GB VRAM için 4× RTX 6000 Pro içeren bir yapılandırma varsayılıyor
    • Bu fiyat seviyesinde, Claude Opus’a epey yakın model zekâsı elde edilen aşama olarak tanımlanıyor
    • 2026-07 itibarıyla 4× RTX6kPRO için mevcut en iyi model olarak GLM-5.2-Int8Mix-NVFP4-REAP-594B gösteriliyor
    • Çalıştırma yapılandırması runners/GLM-5.2-594B içinde yer alıyor
    • Alternatif bir yaklaşım olarak, 4× DGX Spark cluster’ını bağlayıp 512GB VRAM elde ederek, yavaş ama büyük bir beyin gibi çalışan sistemin Qwen3.7-27B ile yinelemeli işleri hızla işlemesi de anılıyor

Gerçek 4× RTX 6000 Pro donanımı

  • Gerçek sistem, 4× RTX PRO 6000 Blackwell Workstation etrafında kurulmuş
  • GPU’lar kart başına 96GB, toplamda 384GB VRAM sunuyor ve fiyatları yaklaşık $46,000
  • Ana sistem, önceki nesil EPYC ve eBay’den alınan DDR4 parçalarıyla temel sistem maliyetini düşürüp bütçeyi VRAM’e odaklıyor
  • 2026 Temmuz itibarıyla PCIe5/DDR5 tabanlı sistemler çok pahalı olduğundan, PCIe Gen4 switch ve DDR4 tabanlı ana sistem tercih edilmiş
  • Temel sistem BOM

    • Temel sistem büyük ölçüde eBay’den alınan önceki nesil EPYC parçalarından oluşuyor
    • Başlıca parçalar ve fiyatları şöyle
    • ASRock Rack ROMED8-2T anakart: $715
    • AMD EPYC Milan 7313P 16 çekirdek 3.0GHz CPU: $504
    • 8× 16GB Crucial DDR4 ECC RDIMM, toplam 128GB RAM: $642
    • 2× Super Flower 1700W PSU: $750
    • c-payne Microchip Switchtec PM40100 Gen4 PCIe switch: yaklaşık $1,330
    • 4TB önyükleme NVMe: $291
    • Model ağırlıkları için 2× 8TB NVMe: $1,200
    • Temel sistem toplamı $5,587
  • PCIe Gen4 switch

    • GPU’lar arası iletişimi neredeyse doğrudan yürütmek için c-payne’in PCIe4 switch’i kullanılıyor
    • Tensor paralelleştirmedeki allreduce aşamasında GPU’lar arası veri, PCI root complex’ten geçmeden switch fabric içinde hareket ediyor
    • Switch alt BOM’u yaklaşık €1,220, yani yaklaşık $1,330 USD
    • Microchip Switchtec PM40100 tabanlı PCIe Gen4 5× x16 switch
    • SlimSAS PCIe Gen4 Host Adapter x16
    • 2 adet SlimSAS SFF-8654 8i kablo
    • GPU’lar ve PCI switch için ahşap bir muhafaza elde yapılmış ve bu yaklaşık bir gün sürmüş
    • PCI switch’in yerleşik fanı çok gürültülü ve işe yaramaz göründüğü için karttan sökülmüş

Model ağırlıklarını saklama ve çalıştırma yöntemi

  • Tüm model ağırlıkları, iki adet 8TB sürücüye kopyalanmış ZFS dosya sistemi üzerinde yerelde saklanıyor
  • Dosya sistemi ~/storage konumuna bağlanıyor
  • Çalıştırılacak model önce şu komutla yerel olarak indiriliyor
hf download <model-name> --local-dir ~/storage/<model-name>
  • Her model, kendi dizinindeki docker-compose.yml ile ayrı bir Docker konteyneri içinde çalıştırılıyor
  • Çalıştırma yapılandırmaları ./runners/ altında bulunuyor
  • Her konteyner, önbelleğe alınmış ağırlıkları okumak için ~/storage/models dizinini salt okunur olarak bağlıyor
  • Model http://clank.j.co:5000 üzerinde servis edildiğinde, başka bir makinedeki VM’de barındırılan opencode üzerinden erişiliyor
  • Dahili DNS sunucusunda clank.j.co, LLM makinesine eşleniyor; ancak http://<llm-machine-ip>:5000 biçimi de kullanılabiliyor

Ajan harness’i ve araç yapılandırması

  • Ayrı bir VM içinde, ~/src ağacındaki her dizin için bir tmux oturumu oluşturan ve her oturumda bir opencode örneği çalıştıran bir uygulama kullanılıyor
  • Her opencode örneği, arka uç olarak çıkarım makinesinin HTTP API’si olan http://clank.j.co:5000 adresini kullanıyor
  • Açık kaynak modelleri iyi kullanabilmenin anahtarı araç yapılandırması olarak ele alınıyor
  • skills/ özetinde şu araçlar yer alıyor
    • camofox, kagi.com API anahtarı ve searXNG üzerinden web gezintisi ve arama
    • Telegram botu üzerinden iletişim ve bildirimler
    • Kaynak kod iş birliği için yerel özel bir Gitea örneği
  • Ajanla oturum içinde etkileşimli biçimde birlikte çalışılabiliyor ya da Gitea issue’larını ele alıp PR açması sağlanabiliyor
  • Bu çalışma sandbox VM içinde yürütülüyor ve host ile iletişim yalnızca paylaşılan dosya sistemi bağları üzerinden gerçekleşiyor

PCIe switch ve çoklu GPU yapılandırması

  • BIOS ayarları

    • ROMED8-2T anakartta PCI switch hızının düşmemesi için BIOS ayarları düzenlenmiş
    • AMD PCIE Link Width, switch yuvası için x16 olarak ayarlanıyor
    • Eski x8/x8 bölme ayarı, yuvayı bölerek upstream bağlantının Gen4 x8 olarak eğitilmesine neden oluyor
    • Her iki SlimSAS 8i kablosunun da bağlı olması gerekiyor; her kablo bir x8 hattını taşıyor
    • PCIe Link Speed zorla Gen4 olarak ayarlanıyor
    • Blackwell Gen5 aygıtları Gen4 switch üzerinden otomatik anlaşma yaparken eğitim başarısız olup Gen1’e düşebiliyor
    • ASPM Disabled olarak ayarlanıyor
    • ASPM L1, boşta olan bağlantıları 2.5GT/s seviyesine düşürüyor
    • lspci içinde Gen1’e düşürülmüş gibi görünmesinin nedeni buydu, ancak yük altında Gen4 olarak çalışıyor
    • Re-Size BAR Enabled olarak ayarlanıyor
    • Tam 96GB VRAM BAR görünürlüğü ve GPU P2P için gerekli
    • SR-IOV Disabled olarak ayarlanıyor
    • Bu, bare-metal çıkarım ortamında IOMMU ek yükü ve P2P’ye müdahaleyi önlemek için seçilmiş
    • Preferred IO Auto olarak bırakılıyor
    • c-payne switch bus’ı 81 elle atanırsa küçük bir gecikme iyileştirmesi mümkün olabilir; ancak bu bir düzeltme değil optimizasyon ve BIOS değişikliklerinden sonra bus numarası değişebilir
  • Redriver ve kablolar

    • c-payne’in tavsiyesine göre c-payne tool ile redriver gain seviyesi lvl 3e düşürülmüş
    • Gain seviyesi, SAS konnektör kablolarının uzunluğuna göre değişiyor
    • c-payne’den yeterince kablo sipariş edilmediği için Amazon’dan benzer görünen SAS kabloları alınmış, ancak ufak farklar sorun çıkarınca yeniden sipariş verilmiş

Kernel, ACS ve güç sınırları

  • GRUB ve NVIDIA UVM

    • /etc/default/grub içinde şu kernel parametreleri ayarlanıyor
    GRUB_CMDLINE_LINUX="iommu=off amd_iommu=off nomodeset"
    sudo update-grub
    
    • iommu=off olmazsa çoklu GPU P2P sırasında NCCL takılıyor
    • NVIDIA UVM P2P düzeltmesi için şu ayar uygulanıyor
    echo 'options nvidia_uvm uvm_disable_hmm=1' | sudo tee /etc/modprobe.d/uvm.conf
    sudo update-initramfs -u
    
  • ACS’yi devre dışı bırakma

    • ACS varsayılan olarak etkinse P2P trafiği switch fabric içinde kalmıyor, CPU root port üzerinden geçiyor
    • Bu durumda PCIe switch’in etkisi ortadan kalkıyor
    • pcie_acs_override yamalı kernel gerektirdiğinden, ACS çalışma zamanında setpci ile devre dışı bırakılıyor
    • Her önyüklemede systemd oneshot servisiyle /usr/local/bin/disable-acs.sh çalıştırılıyor
    • Doğrulama yöntemi şöyle
    • lspci -vvv | grep ACSCtl çıktısında her şeyin eksi işaretiyle görünmesi gerekiyor
    • nvidia-smi topo -m içinde dört GPU arasının PIX olarak görünmesi, PHB/NODE olmaması gerekiyor
    • ./tools/measure-gpu-speed.sh ile P2P bant genişliği ve gecikme kolayca ölçülebiliyor
  • GPU güç sınırı

    • 220V hat kurmaktan kaçınmak için sistem tek bir 110V hat üzerinde çalıştırılıyor ve GPU gücü sınırlandırılıyor
    • Önyükleme sırasında persistence mode ve güç sınırı systemd ile uygulanıyor
    sudo nvidia-smi -pm 1
    sudo nvidia-smi -pl 350
    
    • GPU güç sınırı kart başına 350W, varsayılan ise 600W
    • 4×350W, toplam 1,400W GPU yüküyle PSU bütçesine uyacak şekilde seçilmiş
    • 240V hatta geçmeden önceki tek 1700W PSU aşamasında GPU’lar yaklaşık 260W seviyesinde çalıştırılmış
    • 4×260W = 1,040W GPU
    • Buna yaklaşık 280W sistem tüketimi eklenince toplam yaklaşık 1,320W oluyor
    • Doğrulama nvidia-smi --query-gpu=index,power.limit,power.draw --format=csv ile yapılıyor

Ölçüm sonuçları ve referanslar

  • CPU yönündeki upstream bağlantı Gen4 x16 ve yaklaşık 30GB/s
  • Switch üzerinden P2P 27.5GB/s tek yönlü, 50.4GB/s çift yönlü
  • Gecikme 0.37–0.45µs, yani Gen4 hat hızı seviyesinde
  • ASPM herhangi bir yerde etkinse lspci, boşta olan downstream GPU bağlantılarını 2.5GT/s (downgraded) olarak gösterebilir
  • Bu gösterim kozmetik; yük geldiğinde bağlantı yeniden Gen4 olarak eğitiliyor
  • Resources

    • local-inference-lab/rtx6kpro: 4, 6 ve 8 adet RTX 6000 Pro kart kullanımına dair sık güncellenen depo
    • c-payne: bu kurulumda kullanılan bağımsız PCI switch üreticisi
    • RTX6kPRO Discord: RTX6kPRO benchmark’ları ve yeni model testlerini ele alan Discord sunucusu

1 yorum

 
GN⁺ 5 시간 전
Hacker News yorumları
  • Yerel LLM’leri çok kullandım ve donanıma da gereğinden fazla para harcadım; beklentiyi düşürmek ve ayrıntılı koşulları iyi okumak gerekiyor.
    Yazıdaki büyük sistemin bütçesi 40 bin dolardan başlıyor ama tanesi 12 bin dolar olan 4 GPU içerdiği için gerçekte 50 bin~55 bin dolara daha yakın.
    Yerel kurulumlar, modeli donanıma uydurmak için sık sık quantization ya da REAP gibi tekniklere dayanıyor. 4 bit quantization’ın kayıpsız olduğuna dair çok iddia var, ama bu küçük derlemlerdeki KL divergence ölçümlerinden çıkan bir şey; uzun bağlamlı kodlama işlerinde kullanınca kalite düşüşü belirgin oluyor. Veri kümesi analizi gibi kodlama dışı işlerde bile 4 bit, 8 bit quantization ve bazen 16 bit orijinal arasında kalite farkı epey ölçülebiliyor.
    Bu yazı REAP model kullanımını da öneriyor; bu da birilerinin modeli küçültmek için bazı ağırlıkları budadığı anlamına geliyor. Belirli işlerde daha az yararlı ağırlıkları kaldırma fikrine dayanıyor, ama genel çıktı kalitesi yine düşüyor.
    Tuzak şu: İnsanlar “GLM-5.2’yi yerelde çalıştırıyorum” dediğinde benchmark’lara bakınca harika görünüyor, ama gerçekte çalıştırdıkları GLM-5.2 değil; bitlerin çoğunu atmış ve bazı uzmanları çıkarmış türev bir model. Çok küçük işler ya da sohbetlerde quantization/REAP modelleriyle orijinal arasındaki fark pek görünmüyor; ancak küçük hataların biriktiği uzun soluklu işlerde fark can yakıcı hale geliyor.
    Sonra zaten 50 bin dolar harcamış olduğunuz için, kaliteyi biraz daha artırıp yatırımı değerli kılmak adına 12 bin dolarlık GPU’dan bir iki tane daha almak yeterli olur gibi kayan bir zemine düşüyorsunuz.

    • RTX4090 üzerinde Qwen3.6 çalıştırıyorum; çoğu durumda gayet iyi işliyor.
      Kodlama işlerinde oturumu birden fazla çağrıya bölmek gerekiyor. https://github.com/aka-rider/orqestra’yı yaptım, ama günümüzde araç çalıştırma ortamı olan hemen her yerde benzerini doğrudan yapabilirsiniz.
      Esas mesele, kodu okuyup araç çağırarak bağlamı tüketen oturumu ayrı tutmak ve halüsinasyonları azaltmak için “ilgili kod ve belgeler burada, dayanak da şu” diyen bir Markdown raporu oluşturmak. Planlama oturumu ayrı tutuluyor; küçük model ayrıntıları atladığı için eleştirmen ve tasarımcıyı 1~3 tur karşılıklı konuşturuyor, aynı nedenle çalışan ve doğrulayıcıyı da karşılıklı çalıştırıyorum.
      Qwen3.6 salt okunur modda karmaşık bug’ları saatlerce arayabiliyor ve çoğunlukla buluyor. Önerdiği düzeltme muhtemelen hacky olacaktır, ama Sonnet de öyle.
      Qwen3.6, Opus’un hazırladığı plana göre mekanik biçimde kod yazabiliyor. Sonrasında “Kendi değişikliğini bizzat incele. Bug var mı? Orijinal planla çapraz doğrula; eksik bir şey var mı? CLAUDE.md ihlali var mı?” gibi prompt’lamak gerekiyor. Ama bunu Sonnet’e de aynen yapmak gerekiyor.
      Yerel LLM’i bilgi tabanını yeniden indekslemek için de kullanıyorum. Ticket düzenlemede “hata render’ı için tek panel, tüm hata mesajlarını taşı” gibi ham notlar bıraksanız bile, hedefi ve bağlamı eklenmiş, %90 kadar tamamlanmış bir spesifikasyonla geri dönebiliyor.
    • Kendi bilgisayarımda 8 bit quantization’lı, MoE olmayan, 26B Qwen’i yerelde çalıştırdığımda da benzerdi.
      Küçük işler için gerçekten iyi, ama ilk büyük işi verdiğimde agent çalıştırma ortamının ne olduğunu unuttu ve araç çağırma formatını yanlış yazmaya başladı. Pi üzerinde çalışıyordu ama kendisinin Claude’da çalıştığına inanıp var olmayan Claude araçlarını çağırmaya çalıştı.
    • RAM fiyatları çıldırmadan önce aldığım MBP’de ds4 çalıştırıyorum; epey yararlı.
      Tek başına tüm uygulamayı yazmıyor, ama tailnet’te kendi başıma anlamaya ne vaktim ne de hevesim olan can sıkıcı bir ağ sorununu çözdü; ayrıca basit ama araştırma maliyeti yüksek olduğu için yapmadığım işlere de sık sık el atmamı sağlıyor. Opus değil ama faydalı ve abonelik ücreti ya da API maliyetine değip değmediği konusunda endişelenmem gerekmiyor.
    • “Yerelde çalıştırma” yazılarının ve yorumlarının, karşılaştırma için aynı açık benchmark’ları yeniden çalıştırmış sonuçları da beraber vermesini isterdim.
    • Tamamen doğru. Kodlama LLM’lerini yerelde çalıştırma furyası, amaca göre yapılmış küçük dil modellerinin gerçekten yararlı olabileceği yerel AI alanına aslında zarar verdi.
      Doğal dil işleme, konuşma sentezi, görüntü işleme, ses mühendisliği, sinyal işleme, Krita için diffusion eklentileri gibi küçük araçlar yerel kurulumlar için çok uygun. Birkaç gün önce bu konuda kısa bir yazı da yazmıştım[1].
      [1] https://abishekmuthian.com/multiple-20-ai-plans-are-better-t...
  • “Yaklaşık 40 bin dolara model zekâsı bir seviye yukarı çıkıp Claude Opus’a oldukça yakın bir düzeye geliyor” demek, aylık 200 dolar üzerinden Claude Opus 4.8 veya Codex GPT 5.5’i 16,8 yıl kullanmanın maliyetine eşit
    Yerel model çalıştırmayı gerçekten seviyorum ama hâlâ akıl almaz derecede pahalı, kalitesi daha düşük ve içinde arka kapı varsa tehlikeli de olabilir. Keşke gerçekten böyle olmasa

    • Aylık 200 dolar, tüm API fiyatını ödemeniz gereken durumlar için; örneğin bir “enterprise” şirketiyseniz zaten aylık 4.000 dolara daha yakın. O zaman eşdeğer maliyet 10 aya düşüyor
      Ancak yerel donanımın gerçekten aylık 4.000 dolarlık API kullanımına denk bir yükü işleyip işleyemeyeceğinden şüpheliyim. Çünkü yerel donanım, Anthropic’in birden fazla veri merkezi kadar çok prompt’u paralel ve verimli şekilde çalıştırmakta zorlanır
    • Ana fikre katılıyorum ama bu hesap LLM fiyatlarının hep sabit kalacağı varsayımına dayanıyor
      OpenAI ve Anthropic gibi şirketler hâlâ risk sermayesinin gücüyle sübvanse edilen fiyatlarla plan satıyor ve o sermaye bir gün getiri isteyecek
    • Öncü modellerin arka kapılı olduğu iddiası mantıklı değil. Arka kapılı tek bir model bile duymadım; keşfedilirse Hugging Face’ten hızla kaldırılır. Bu bir sorun değil
    • Donanımda, aylık 200 dolarlık plandan çok daha fazla token kullanabilirsiniz
      OEM spark ile ilk ay 1 milyar token kullandım; Opus bazında bu 1.000 dolardan fazla eder. Token örüntüleri farklı olduğu için adil bir karşılaştırma değil ama ardından vLLM iyileştirmeleri, özellikle MTP sayesinde hız da 2-3 kat arttı. DiffusionGemma, normal Gemma’dan yaklaşık 4 kat daha hızlı
    • Yerelde çalıştırmaya uğraşmayın, bulut GPU kiralayın yeter
      Fiber hattın sahibi de değilsiniz; öyleyse neden hızla değer kaybeden, pahalı ve zahmetli bir varlığa daha sahip olmak isteyesiniz ki?
      Bulut GPU kiralarsanız devasa bir hobi tipi Frankenstein kutusu inşa etmeden sahiplik kültürüne, veri kontrolüne, fiyat kontrolüne ve hacker kültürüne katılabilirsiniz. O kutu pahalı, damıtıldıkça pratikte daha az işe yarar hale geliyor ve bakımı da baş ağrısı
  • “40 bin dolara neredeyse Opus” deniyor ama GLM 5.2 “neredeyse Opus” ise rahat çıkarım için en az 8xH200 gerekir; bu da 40 bin dolardan çok 400 bin dolara daha yakın
    Yazı değiştirilmiş bir model kullanmayı öneriyor: “REAP ile budanıp uzmanların yaklaşık %22’si çıkarılmış, Int8-mix NVFP4 ile kuantize edilmiş GLM-5.2, yaklaşık 594B parametre”
    Benchmark dışında gerçekte nasıl davranacağını merak ediyorum. Qwen3.6 bile 6-bit kuantizasyonda çıkarım sırasında sık sık döngüye giriyor; burada ise uzmanların bir kısmı da çıkarılmış. Bazen 8-bit veya 16-bit küçük bir model, beyin lobotomisi yapılmış büyük bir modelden daha akıllı olabiliyor. Kodlama için 8-bit’in altına inilmemesi gerektiği yönünde bir uzlaşı var gibi
    Ayrıca beyin lobotomisi yapılmış modeli 4 adet RTX 6000’e sığdırırken kullanılabilir bağlamın ne kadar kaldığı da belirsiz. 100k’nin altı, gerekli bağlamı toplamadan sıkıştırmaya takıldığı için çoğu zaman neredeyse kullanılamaz. Depoda kontrol ettim; bağlam 240k idi

    • GLM 5.2’yi yalnızca tek bir H200 ile çalıştırınca ne olduğunu merak ediyorum
      Hiç çalışmıyor mu, yoksa kullanılamayacak kadar yavaş mı, bilmek isterim. Yerelde son seviye modellerin derlemesini ve konseptini doğruladıktan sonra, 18-24 ay sonra GPU fiyatları ciddi biçimde düşerse kalanını tamamlamak istiyorum
    • Bunun ölçeklenebilirlikle nasıl örtüştüğünü merak ediyorum
      Yani aynı anda yüzlerce prompt çalıştırılabiliyor mu diye düşünüyorum
    • Döngüler, LLM ile ilgili çoğu olgu gibi bir örnekleme sorunudur ve DRY cezasıyla kolayca çözülebilir
      llamacpp içinde var. heretic’i yapan kişi, en güncel döngü önleme ve çeşitlendirme stratejilerini de yaptı
    • 8x RTX6000 üzerinde lukealonso NVFP4 kuantizasyonu kullanılırsa 1M bağlam da mümkün; en az 400k’ye kadar tutarlılık ve kullanışlılık korunuyor
      Sırf öyle yapmak istediğiniz için değilse 8x H200 çalıştırmaya pratikte gerek yok. Düzenli olarak çok sayıda eşzamanlı kullanıcıya veya ajana hizmet vermeniz gerekiyorsa bu istisna
  • Ara seçenekler de var. 128GB VRAM sağlarsanız, birleşik bellek mimarisiyle bu kapasiteyi elde edebileceğiniz artık birkaç seçenek var ve DwarfStar üzerinden DeepSeek V4 flash’ı iyi hızda çalıştırabilirsiniz
    Ben para harcamazdım ama birçok kişi için bunun uygun bir uzlaşma noktası olacağını düşünüyorum

    • m4 max 128’de yeni yeni denemeye başladım; bu makineyi 1 yıl önce aldığımdan beri ilk kez yerel LLM’in oldukça iyi kodlama için öylece çalıştığı hissine kapıldım
      Ancak Pi kullanmak gerekiyor. claude code’un bootstrap bağlamı çok fazla olduğu için her şey çok daha yavaşlıyor
  • “İki adet RTX 3090 ile toplam 48 GB VRAM’e sahip olursanız Qwen3.6-27B’yi çalıştırabilirsiniz ve harika bir model” deniyor ama 3 bin dolara 48 GB paylaşımlı belleğe sahip bir M5 MacBook Pro alınabilir; üstelik devasa bir kutu da değil.
    Ya da o parayı bulut barındırma sağlayıcılarına harcamak da düşünülebilir. En azından bir ölçüde, belki de çok daha ucuz olabilir. Elbette modeli yerelde çalıştırabilmek harika bir şey.

    • Yaşamadığım durumları hayal edemeyen bir aptal olduğum için, yerel LLM’lerin peşinden gitmeye değmeyen oyuncaklar olduğunu hep düşünmüştüm.
      Ama Gemma 4 31B ve Qwen 3.6 27B gibi düzgün şeyleri bir kez kullanınca ne kadar faydalı olduklarını anladım.
      Hassas bilgileri paylaşıyor muyum diye endişelenmeyi bırakıyorsunuz, token’larım biter mi diye kaygılanmıyorsunuz ve uzaktaki yapay zekanın erişilebilirliğini de düşünmüyorsunuz. Yerel LLM’ler çok değerli.
    • 3090’ın harika tarafı bellek bant genişliği. Token üretiminde darboğaz çoğunlukla bellek bant genişliği.
      İki 3090 toplamda 1,87 TB/s, kart başına 0,936 TB/s bellek bant genişliği sunarken M5 MacBook Pro yalnızca 0,3 TB/s sunuyor. Max çip en fazla 0,63 TB/s’ye çıkıyor ama o konfigürasyon 10 bin dolarlık bir makine.
      Bu yüzden Qwen 27B iki 3090 üzerinde gerçek işler için yeterince hızlı çalışırken MacBook Pro’da acı verecek kadar yavaş hissettiriyor. Ayrıca MacBook Pro’da büyük modeller çalıştırınca arayüz takılıyor ve klavye ısınıyor. Bodrumda iki 3090 bulundurup MacBook’tan bağlanmak çok daha iyi.
    • Bende hem M5 MacBook Pro hem de model çalıştırmak için ayrı bir GPU konfigürasyonu var; hız farkı büyük.
      Sadece token üretim hızı değil, ilk token’a kadar geçen süre, yani prompt işleme süresi de farklı. M5 donanımı kendi başına harika ama GPU hâlâ çok daha hızlı.
      Modeli GPU kutusunda çalıştırınca dizüstünü sıcak bir tabağa çevirmeden kucağınızda kullanabilmek gibi bir avantaj da var.
    • Qwen3.6-27B’yi tek bir 24 GB GPU’da 80 token/sn hızla çalıştırıyorum, bu yüzden iki karta bile gerek yok.
    • Mantıklı bir tercih, ama M5 Pro’nun bellek bant genişliğinin yaklaşık 1/3, M5 Max’in de yaklaşık 2/3 düzeyinde olduğunu bilmek gerek. M5 Max’in en düşük konfigürasyonu bile 4.100 dolar.
      Dolayısıyla FLOPS’a bağlı prefill de, bant genişliğine bağlı decode da ikisi de yavaş olacaktır.
  • Bu hafta yerel LLM’i yeni kurdum; kendi deneyimimi de ekleyeyim. Intel’in Arc B70 adlı 32 GB kartını seçtim; 3090’dan ucuz ve RAM’i daha fazla ama bellek veri yolu daha yavaş.
    Bunu seçmemin nedeni, kullanmak istediğim modellerin 24 GB’a rahatça sığmak için biraz büyük olması ve otomatik tamamlama ile konuşma tanıma için birkaç küçük modeli daha yükleyecek alana da ihtiyaç duymamdı. Ayrıca zaten ucuz bir sunucum vardı; çift GPU kullanmak için anakartı, güç kaynağını ve muhtemelen kasayı da değiştirmem gerekecekti.
    Kurulum epey zahmetliydi. Intel hattında SYCL’i, kabaca Intel’in CUDA’sı gibi bir şeyi desteklemek için “level zero” adlı bir sürücü paketi gerekiyor ve bunu düzgün çalıştırmak zordu. llama.cpp’yi Docker konteynerinde çalıştırıyorum; konteynerin kartı görmesini sağlamak da biraz uğraştırdı. Son birkaç ay içinden bir çekirdek de gerekiyor.
    Bir kez çalışmaya başlayınca 1.000 dolarlık yatırım için sonuçlar çok etkileyici. Qwen 3.6 35B’yi q4 quantization ile çalıştırınca RAM’in yaklaşık 3/4’ünü kullanıyor ve yaklaşık 88 token/sn veriyor. Ucuza makul boyutta bir model istiyorsanız bu bir yöntem.

    • Bu yanlış. İkisi de GDDR6.
      B70, 256 bit veri yolunda 2375 MHz ve 608 GB/s; 3090 ise 384 bit veri yolunda 2438 MHz ve 936 GB/s. Daha yavaş değil, kanal sayısı daha az; yani genişliği daha dar.
  • qwen3.6-27b’nin q4 varyantı, tek bir 3090 üzerinde toplam yaklaşık 250K bağlamla da çalıştırılabiliyor.
    Sinir bozucu olmayacak kadar yeterince hızlı olduğu için iki 3090’ın getireceği hız artışı benim için değerli değil. İki kartta q6’yı yarı hızda ve daha küçük bağlamla çalıştırma seçeneği de var ama zaten en yeni nesil modellerle rekabet edemeyeceğinden, elinizde hâlihazırda iki 3090 yoksa mevcut fiyatlarda tek kartın en iyi yatırım olduğunu düşünüyorum. İyi yapılandırılmış bir çalıştırma ortamınız varsa pek çok iş için yeterli.

    • Tek bir 3090’da qwen3.6-27b çalıştırırken KV cache’i de q4’te mi tutuyorsun?
      Benim deneyimime göre o hassasiyette uzun bağlamdan geri çağırma doğruluğu ciddi şekilde düşüyor. KV cache’i q8’de tutup 120k bağlamla çalışmak daha iyiydi.
    • 250k bağlam, Q4 model, 24 GB VRAM hesabı ancak K/V cache de q4 quantization olduğunda tutuyor; bu da muhtemelen iyi bir fikir değil.
  • Bununla ilgili olarak, şu anda kullanılabilecek en iyi izolasyon sisteminin ne olduğunu merak ediyorum. Tam anlamıyla ağır bir VM’e kadar gitmek mi gerekir, yoksa Firecracker benzeri bir şey yeterli olur mu, emin değilim.
    Olası seçeneklerin her birinde ayağınızı uçurmanızı kolaylaştıran ince tuzaklar var gibi ve pratikte hiç güvenlik yokmuş hâle gelmek kolay görünüyor. VM’i, güvenliğin bu teknolojinin temel ilkesi olduğuna gerçekten güvenebildiğimiz için kullanırız; “şu 20 bayrağı kullanıp gözlerini kısarsan sorun olmaz” tarzı bir yaklaşım değil bu.

    • MacOS’ta yerleşik seatbelt sandbox var. Linux’ta ise namespace’lerin üzerine SELinux veya benzeri bir yardımcı araç koyan Docker kullanılabilir.
      Önce saldırı vektörlerini modellemek gerekir. rm -rf yazma kısıtlarıyla engellenir; curl malware.sh | sh için de yazılabilir dizinlerde çalıştırmayı kısıtlamak yeterli olur (seatbelt/SELinux). Hassas dizinlere yazmayı kısıtlamak bile çoğu kötü amaçlı yazılımı büyük ölçüde etkisiz bırakabilir.
      Kimlik bilgisi sızıntısı için ortam değişkenlerini temizlemek, .ssh, .aws vb. için okumayı yasaklamak ve LLM’i işletim sisteminin yakınına koymamak yeterlidir.
      MacOS için küçük bir yardımcı araç olan https://github.com/aka-rider/leash’i yaptım, ama bash betiğiyle de yapılabilir.
    • Ne için olduğuna bağlı. Güvenlik modeliniz ajanı PC’nizi mahvetmemesi için bir sandbox içine kapatmaksa seçenek çok.
      Hafif bir şey istiyorsanız bubblewrap[1] gibi bir şey kullanabilir veya libkrun[2] gibi bir microVM tercih edebilirsiniz; ilgili araçları da istiyorsanız tam Docker’a kadar gidebilirsiniz.
      [1] https://github.com/containers/bubblewrap
      [2] https://github.com/libkrun/libkrun
    • Herkese uyan kullanıma hazır bir yapılandırma olmayacak gibi. Çünkü herhangi bir güvenlik sınırında, her sertleştirme katmanı kullanılabilirlikten ödün vermeyi beraberinde getirir.
      Her şeyin gerçekten sıkıca kilitlendiğini nasıl bileceğiniz konusundaki belirsizliği anlıyorum.
      Şahsen doğru yolun VM veya microVM olduğunu düşünüyorum. Konteynerlerin aksine bunlar gerçek güvenlik sınırları olarak tasarlanmış şeyler. bubblewrap ile karşılaştırınca da, ajana tüm dosya sistemini verip YOLO modunda çalıştırabilirsiniz; oysa bubblewrap’te her geliştirme aracının kullanılabilirliğini tek tek başlatıp yapılandırma dizinlerini, paket önbelleklerini vb. güvenli şekilde mount etmeniz gerekir ve yine de sürekli izin hatalarıyla karşılaşmanız olasıdır. İzolasyonu da çok daha zayıftır.
      Çalıştırma ortamı desteği sınırlı olsa da, çalıştırma ortamı sürecini host üzerinde çalıştırıp tüm araç çağrılarını ve dosya sistemi etkileşimlerini VM’e devretmek oldukça mantıklı görünüyor. Böylece oturum verilerini ve kimlik doğrulama anahtarlarını ana makinede tutup bağlamın içine asla girmemelerini sağlayabilirsiniz. Buna karşılık çalıştırma ortamının kendisi güvenlik sınırının bir parçası hâline gelir; ödün de bu.
      Veriyi VM’in içine ve dışına nasıl taşıyacağınız da kullanılabilirlik sorunu oluyor. Yerel git deposunu VM’e itip sonra uzaktaki bir depo gibi geri çeken betikler kullanıyorum; böylece VM host’a bağlantı başlatamıyor ve git kimlik bilgilerine de sahip olması gerekmiyor. Ama ajanın doğrudan GitHub’a push etmesini isteyen biri için bu fazla zahmetli olabilir.
      VM tarafında denediğim veya gördüğüm seçenekler qemu + libvirt, crun-vm ve libkrun ailesi. qemu + libvirt’i ayarlamak uğraştırıyor ama çok sınanmış ve çok yapılandırılabilir. crun-vm, podman ile qemu arasında yüksek seviyeli bir entegrasyon katmanı PoC’si; terk edilmiş gibi görünüyor ama mevcut araçlara ve standartlara odaklandığı için ilginç. libkrun daha yeni bir oyuncu ve microsandbox, smolvm, krunvm gibi sarmalayıcıları var. Bunların hepsi Linux için.
    • GPU passthrough eklenmiş ağır bir VM’e, yalnızca CPU kullanan bir VM’den çok daha az güvenirim.
  • LLM kullanmak için bu kadar uğraşmak bana tuhaf geliyor. Özellikle bu şekilde en son teknoloji peşinde koşmak daha da öyle.
    Claude gibi şeyler yarın ortadan kaybolsa gözümü bile kırpmam.
    İnsanların neden beyin kıvrımlarını slop makinesine erişim hakkıyla takas ettiğini anlamıyorum. İyi bir benzetme gerekirse, usta bir marangoza Ikea’dan bir iki kademe daha düşük kalitede mobilya çıkaran bir makine vermeye benziyor olabilir. İşi görüyor mu? Çoğunlukla evet. Marangoz bu süreçten keyif alıyor mu? Hayır.

  • Benim deneyimime göre q4 gibi ağır şekilde kuantize edilmiş ya da bir ölçüde değiştirilmiş modelleri çalıştırıp “vay, gerçekten harika” dediğim olmadı. Aksine, birkaç prompt denedikten sonra çöpe gittiler.
    96GB’lık bir RTX 6000 PRO’m var; rahatça çalıştırabildiklerim Qwen 3.6 27B veya MoE, Gemma 4 31B civarında. Modeli tam hassasiyet ve maksimum bağlam uzunluğuyla çalıştırırken sınır burası.
    Bunlar iyi performans gösteriyor ve kodlama, internet araştırması gibi birçok amaç için kullanılabiliyor. Hesapladığınızda Anthropic’e yılda 2.400 dolardan fazla harcayacaksanız böyle bir kart almak mantıklı olabilir, ama kalite düşüşünü kabul etmeniz gerekir. Zaten 5 yıl sonra insanların hâlâ kod yazıp yazmayacağı da ayrı bir soru.