Yerel Qwen daha kötü bir Opus değil, farklı bir araç

 (blog.alexellis.io)
2 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Yerel Qwen 3.6 27B, müşteri verileri ve dahili telemetri gibi buluta yüklenmesi zor işler için somut değer üretiyor, ancak buluttaki SOTA modellerin yerini tutmuyor
  • Yerel modellerin güçlü yanı, en yüksek performanslı modellerle puan yarışına girmekten çok sabit maliyet, gizlilik koruması ve satıcı riskini azaltma; fark özellikle yoğun kullanım ve SaaS içi özelliklerde ortaya çıkıyor
  • SWE-Bench Verified'da Qwen 3.6 27B 77,2 puan, Claude Opus 4.8 ise %88,6 alıyor; bu yüzden "yerel model SOTA'nın yalnızca %12 gerisinde" iddiası, benchmark ayarı yapılabilmesini ve Go gibi gerçek alan farklarını göz ardı ediyor
  • Yaklaşık 12.000 dolara alınan RTX 6000 Pro Blackwell 96GB donanımı, müşteri lisanslarının eksik bildirildiğini tespit ederek sağlanan gelir geri kazanımı sayesinde maliyetini tek başına çıkardı
  • En büyük sınırlama, uzun görevlerde tekrarlayan çıktı ve halüsinasyon üreten loop sorunu; bu nedenle yerel Qwen, uzun süreli gözetimsiz kodlamadan çok müşteri desteği, dar kapsamlı bakım, kod tabanını okuma ve açıklama için daha uygun

Yapay zeka kullanımının arka planı ve iş bağlamı

  • OpenFaaS ile başlayıp SlicerVM, Actuated, Inlets gibi düşük seviyeli altyapı ve Linux primitive'leri odaklı ürünleri küçük bir ekip işletiyor
    • Konteynerler, Firecracker microVM, ağ protokolleri, tüneller, CLI ve Kubernetes temelli; çoğunlukla Go ile yazılmış, kısmen React UI içeriyor
  • VS Code sekme tamamlama döneminden beri yapay zeka araçları kullanılıyor; bugün kodun büyük kısmını Claude veya Codex yazıyor, elle kod yazma ise neredeyse yok
  • tmux içinde uzun süreli çalışma akışını yönetmek için Superterm.dev geliştirildi; oturum ve not yönetimi ile kodlama ajanlarının görsel geri bildirimi için kullanılıyor

Frontier zekâsında dönüm noktası

  • 2025 Kasım ile 2026 Ocak arasında bir kırılma yaşandı; X üzerinde birçok geliştirici, Claude Opus'un kendi işlerinin tamamını yürütebildiğini söylemeye başladı
  • En üst seviye kodlama planlarının maliyeti kişi başı aylık yaklaşık 200 USD seviyesinde oturdu; aşırı gözetimsiz işlerden kaçınılırsa haftalık 5 saat sınırı içinde kullanılabiliyor

Yerel modeller neden ilgi çekici

  • 2026, herkesin tek bir abonelikle bir fikri bir gecede kopyalayabildiği bir dönem; SlicerVM ve Superterm de klon örnekleri yaşadı
    • Yazılım maliyetinin sıfıra yaklaştığı bir pazarda, kritik nokta "ücretsiz ve yeterince iyi" olabilir
  • Öncü modellerin 0,5~2T parametre aralığında olduğu tahmin ediliyor; bu, yerel donanımın en üst seviyesinden bile bambaşka bir ölçek

  • Benchmaxxing

    • Benchmark'lar herkese açık olduğu için puanı yükseltecek şekilde ayarlanabiliyor; bu yüzden mutlak ölçüt olarak güvenmek zor
    • SWE-Bench Verified Python sorunlarına dayanıyor; ancak kodun büyük bölümü tek iş parçacıklı ve senkron, buna karşılık Go dağıtık sistemlerinde channel, context ve struct'lar geniş bir çalışma alanına yayılıyor
    • Sadece benchmark puanına bakıp “yerel model SOTA'dan %12 geride” demek zor; gerçek işte başarıyı dil ve sistem özellikleri ciddi biçimde etkiliyor

  • Maliyet

    • “Yerel modelin konusu maliyet değil” sözü herkes için geçerli değil
    • Kişisel kodlama planları aylık 200 dolara yüksek kullanım ve SOTA düzeyi zekâ sunuyor, ancak bu kodlama planlarının sübvansiyonlu bir yapıya sahip olduğu düşünülüyor
    • GitHub Copilot, aylık 39 dolara 1.500 istek sunan modelden token bazlı ücretlendirmeye geçti ve bu büyük tepki çekti
    • API token maliyetiyle ücretlendirme yapılırsa başa baş noktası hızla gelebilir
      • Uber, geliştirici başına araç başına aylık 1.500 dolar ile yapay zeka harcamasını sınırlandırıyor
      • Uber'de medyan maaşın 330.000 dolar olduğu düşünülürse, bir geliştirici iki aracı limite kadar kullanırsa bu maaşın yaklaşık %12'sine denk geliyor
    • Büyük hacimli kullanım, loop'lar, ajan analizi ve SaaS içine gömülü özelliklerde open-weight ve yerel modeller ciddi değer sunuyor

  • Egemenlik ve gizlilik

    • Müşteri verileri ve sözleşme koşulları nedeniyle bazı durumlarda veriyi bulut planlarına yüklemek zor olabiliyor
    • ChatGPT Pro ve Claude Max için 30 günlük saklama süresi ayarlanabiliyor, ancak bunun bile müşteri sözleşmelerini geçersiz kılabileceği düşünülüyor
    • Anthropic'in Fable 5 modelinin ABD dışındaki kullanıcılardan bir gecede kaldırılması, satıcı riski olarak görülüyor
    • Yerel modeller, "frontier laboratuvarı X yaparsa ne olur?" sorusuna bir çözüm sunuyor

Bıçak dövme benzetmesi — yerel modelin özü

  • Çeliğin ısıl işleminde bir aşamayı fazla kaçırınca baştan başlamak gerekmesi gibi, yerel model de çok fazla ısındığında hedefi aşıp loop'a giriyor
    • Tek çözüm, harness'i durdurup boşaltılmış bir context ile farklı bir sonuç ummak
  • Nasıl ki bıçak dövme süreci gözetimsiz bırakılmazsa, Qwen 3.6 27B'ye de uzun ufuklu görevler bırakılmıyor

  • Aradığım şey

    • Hedef; gizlilik, sabit maliyet ve satıcı riskine karşı korunmaydı
    • Yerel modeli Claude ve Codex ile aynı şekilde ele alınca hayal kırıklığı doğdu
    • Claude, kısa talimatlarla ("do it and test it end to end") 5~15 dakika içinde PR hazırlama, otomatik kod inceleme ve yineleme içeren verimli loop'lar kurabiliyor

3090'dan çıkarılan dersler

  • 2023'te tek bir 3090 ile başlandı; modeli yüklemek ve yeterli context sağlamak için ikinci karta ihtiyaç duyuldu
    • Qwen 3.5'in ajan olarak gerçek bir işi yapabildiğinin ilk görüldüğü an buydu
  • “Makineyi her açıdan inceleyip adli analiz raporu yaz” talimatı verildiğinde, model tüm dosyaları tek tek okuyup context'i doldurdu ve dosya adı ile tool call halüsinasyonu üretti (~/faas-netes→~/faaned)
    • Görev alanı daraltılıp “kısaca göz at” denince yaklaşık 40~50 tok/s hızında net bir rapor üretti
  • 27B model, tek bir 3090'a tam hassasiyetle sığmadığı için ayarlanabilen değişkenler ağırlık kuantizasyonu, context uzunluğu ve KV cache sıkıştırması oldu
    • KV cache'in key kısmında Q4_0 ile sorun çıktığı genel kabul görüyor; en agresif durumda bile keys için Q8_0, values için Q4_0 kullanıldı
  • vLLM + NVLink + tensor parallelism denemelerinde de üretim hızı llama.cpp'den saniyede 3 token daha yavaştı; ayrıca loop oluştu ve ağırlıkların yüklenmesi dakikalar sürdü
    • vLLM büyük ölçekli eşzamanlı servis için uygun, ancak prosumer ortamında açılış süresi, sadelik ve tek kullanıcı gecikmesi daha önemli

Büyük harcama — RTX 6000 Pro alımı

  • Müşteri destek biletlerini hızlı çözmek için yaklaşık 12.000 USD'lik RTX 6000 Pro Blackwell (96GB VRAM) satın alındı
    • Daha sonra fiyat yaklaşık 15.400 USD'ye yükseldiği için ikinci kart eklemek zorlaştı
    • PCI lane, bant genişliği, kart aralığı ve PSU yükü gibi nedenlerle tüketici sınıfı bir makineye basitçe eklenemiyor
  • Hesaplı bir bahis olarak işe yaradı, ancak Claude aboneliğinin yerini tutmadı

Veri sızıntısı olmadan kolay müşteri desteği

  • Operatörlerin kolayca çalıştırabildiği "diag" adlı bir CLI aracı yapıldı; OpenFaaS Kubernetes kurulumunun tam bir snapshot'ını alıyor
    • Gelen dump, Slicer'ın oluşturduğu ephemeral VM içindeki air-gapped yerel model tarafından analiz ediliyor

  • Gelir geri kazanımı

    • Telemetri veritabanı yerel modele verildi ve bir müşterinin 12 aydan uzun süredir lisansını eksik bildirdiği, 4~5 kat eksik ödeme yaptığı tespit edildi; sadece bu tahsilat bile kartın maliyetini karşıladı
    • Telemetri ve diag dump'ları, veri saklama politikasından bağımsız olarak hiçbir bulut planına yüklenmiyor
    • ChatGPT Pro ve Claude Max'te 30 günlük saklama ayarı yapılabilse de, bunun bile müşteri sözleşmelerini geçersiz kılma riski var
    • İlk modeller aritmetikte başarısız oldu (27.3K'yi 273.000 diye hesapladı), fonksiyon sayısı az diye sık çalıştırmayı göz ardı edip bunu ayrılma riski olarak yanlış yorumladı
    • Sonuç olarak modeli yorum yapmaktan çok analiz etmeye odaklamak daha iyi

Mevcut kurulum

  • RTX 6000 rig üzerinde Qwopus'un en yeni nesli ile temel Qwen 3.6 27B birlikte çalıştırılıyor; yeni fine-tune ve point release'lere göre değişiyor
    • Qwopus, Qwen üzerine Chain of Thought izleme ekleyerek akıl yürütme ve kodlama performansını artırmayı amaçlayan fine-tune bir model
    • Yakın zamana kadar thinking tamamen kapatılmıştı; yeniden açılması loop artışıyla aynı döneme denk geldi
  • Tam context uzunluğunu korumak için iki bağımsız llama.cpp instance'ı ile servis veriliyor; --parallel 2 context'i yarıya indiriyor
  • Spekülatif decoding (MTP) ile yaklaşık %93 kabul oranı alındı; hız sabit 67 tok/s'den 130~200 tok/s aralığına çıktı ve hissedilir şekilde buluttan daha hızlı oldu
    • Model kartındaki tuning yönergelerine uymak önemli; Qwopus, thinking kapalıyken ve temperature 0.85~1.0 gibi oldukça yüksek ayarlandığında en iyi sonucu veriyor

Tekrarlayan çıktı ve uzun görevlerin sınırları

  • Qwen'in en büyük sorunu, uzun kapsamlı görevlerde loop'a girmesi
  • faas-cli için yeni komut önerisi istendiğinde önce makul öneriler sundu, ancak sonra aynı komut listesini tekrar tekrar yazarak yaklaşık 30 dakika boyunca 600W güç harcadı
  • Tüm get ve list komutlarına --json eklenmesi istendiğinde de ilk bir iki adım inandırıcıydı ve testler yazdı, fakat sonrasında sorunlar büyüdü
  • --json çıktısında http:// uzak endpoint için insecure TLS uyarısını bastırmak amacıyla Python reverse proxy kullandırıldığında, ilk sürüm makuldü ama girintileme yanlıştı; düzeltme sırasında dosyayı bozdu ve sonra takılıp tekrar etmeye başladı
  • Ekipten Han da benzer loop'lar yaşadı; özellikle modelin ya da ajanın yetenek sınırına gelip yardım istemeden orada takılı kalması sık görüldü
  • Bu sorun yüzünden, müşteri desteği ve yenileme amaçlı telemetri ile diag analizi dışında yerel Qwen'e kolayca güvenmek zor

Erişimi ölçme ve dağıtım

  • Başlangıçta tek bir inlets tüneli kullanıldı; aynı llama.cpp instance'ına iki ajan bağlanınca önbelleğe alınmış prefix'ler birbirini geçersiz kılıyor ve tüm prompt yeniden işleniyor
  • Birden fazla kişi kullandığında iş prototip aşamasını aşıyor; kimin hangi instance'ı ne kadar ve hangi modelle kullandığı, elektrik maliyeti ve ayrılma durumunda ne yapılacağı gibi yönetim sorunları doğuyor
  • opencode.json dosyasını elle düzenleyip dağıtmak yerine, opencode için "Toilgate" adlı bir provider yazıldı; model seçicide temel modelden deneysel Qwopus varyantlarına kadar seçim yapılabiliyor
    • Toilgate %100 vibe-coded ve açık kaynak hâline getirilmesi büyük bir yük
  • Duvardaki iki Shelly Plus Plug 2 ile güç tüketimi ölçüldü; RTX 6000 Pro çıkarım sırasında 600W ve sessiz, iki adet 3090 ise toplamda yaklaşık 750W ve çok gürültülü

  • Yanlış karşılaştırma

    • Milyon token başına giriş/çıkış maliyetini GPT-5.5 API fiyatıyla kıyaslamak, mevcut yetenek düzeyi nedeniyle yanlış bir karşılaştırma
    • “Yerel AI” sonunda kimlik, erişim kontrolü, ölçümleme, kota, model yönlendirme ve güç izleme gerektiren bir operasyon sorununa dönüşüyor

Gerçekte işe yarayan kullanım kalıpları

  • Yerel modeli ve harness'i uzmanlaşmış görevlere uyarlamak önemli
    • müşteri desteği
    • kapsamı iyi tanımlanmış bakım işleri
    • uçtan uca testler
  • AGENTS.md içine ayrıntılı talimatlar eklenince yerel model yeni CLI'ları daha hızlı ve verimli ekleyebildi ve bunları kendisi test edebildi
  • Yerel model, doğrudan kod yazmada sınırlı olsa da bir kod tabanını hızlı okuyup açıklamada güçlü
  • Agent Skills da yardımcı oldu; örneğin yerel bir ajan yeni bir mini PC üzerinde Slicer'ı sıfırdan kurdu
  • Aynı görevi hem yerel modelde hem bulut modelinde çalıştırma yaklaşımını genelleştirmek gerekiyor
  • Uzun kapsamlı gözetimsiz ajan işleri kaçınılması gereken bir alan; yaklaşık 15.000 dolarlık donanım bile bu sorunu çözmüyor

Güncel sonuç ve model seçimindeki sınırlar

  • Yerel Qwen, “Opus seviyesine yakın” olmaktan çok belirli görevler ve iş akışlarında değer üreten farklı bir araç
  • Qwen 3.5, kullanılabilir sonuç veren ilk model olarak görülüyor; 3.7 söylentileri var ama devrimden çok kademeli iyileşme bekleniyor
  • 70B modellerin çoğu eski ve nesil olarak geride kabul ediliyor
  • Qwen 35-A3B, MacBook'ta hızlı göründüğü için popüler ama üretim sırasında etkin olan parametre sayısı yalnızca 3B; bu nedenle hız yerine kalite tercih ediliyor
  • GLM 5.2, Kimi 2.7, Minimax M3, Deepseek V4 Flash gibi daha büyük modeller bazı yerel donanımlarda mümkün olsa da, kuantize sürümlerini bile yüklemek için çoğu zaman 4~6 adet RTX 6000 Pro gerekiyor; bu da kapsam dışında
  • Bugün 27B dense modeller bütün gün Go kodu yazacak seviyede değil; sınırlı bilgi ve dikkat, kod incelemesinde hemen ortaya çıkıyor
  • Qwen'e kısa yazması söylendiğinde buna iyi uymuyor; otomatik kod incelemelerinde gereksiz ayrıntılara giriyor ya da eşzamanlılık sorunları ve race condition'ları halüsinasyonla uyduruyor, bu yüzden deneyler hızla sonlandırılıyor
  • Daha ucuz ve daha hızlı olan Grok Coder Fast 1, deprecated edilene kadar birkaç ay boyunca iyi çalıştı
  • İlgili örnekler code review bot ve OpenFaaS'in painless customer support and architecture review yazısında özetleniyor

İlgili okumalar

1 yorum

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

  • Bu modelleri uzun süre kullandığınızda meselenin sadece “X, Y’den daha akıllı” ya da “Y, Z’den daha ucuz” düzeyinde olmadığını fark ediyorsunuz. Bunlar farklı araçlar ve prompt verme biçimleri de farklı; bir enstrüman çalmaya epey benziyor.
    Claude’da bazen uygulamaya renk katmak ya da yaratıcı sonuçlar çıkarmak için bilerek daha az açık ya da daha dolaylı ifade etmek gerekebiliyor. Ve kulağa tuhaf gelebilir ama Claude’a nazik davranırsanız karşılığını alıyorsunuz, sert davranırsanız zararını görüyorsunuz. Claude tonu daha güçlü biçimde taklit ettiği için olumsuz bir döngüye girmemek iyi oluyor.
    GPT’de net olmak ve belirsizliği azaltmak gerekiyor. GPT, “X’i yapayım ama Y olmasın” gibi bir min-max yaklaşımıyla belirsizliği çözmeye çalışıyor; kapsamı açıkça belirtmezseniz tüm sınır durumlarını yakalamaya çalışıp aşırı tasarıma kaçma eğilimi gösteriyor.
    Qwen’de önce yapıyı vermek, sonra içini doldurtmak gerekiyor. Qwen XML, JSON ve listeleri seviyor; önceki işlerden bol örnek gösterirseniz iyi sonuç veriyor. Bu hiç bilimsel bir şey değil, tamamen hissiyat; sonuçlar değişebilir.

    • “Bilimsel değil, sadece hissiyat” kısmı tam da sorun. Keşke her modelin güçlü ve zayıf yönlerini yazan bir ürün kılavuzu olsa da “böyle bir iş için X modelini seç”, “Y modelini Z şekilde kullan” gibi bir karar ağacı sunsa.
      Ama dışarıdan bakınca hepsi birbirine benziyor; hangisinin nerede biraz daha iyi olduğunu anlamak için geniş kapsamlı, zaman alan ve muhtemelen pahalı testleri bizzat yapmak gerekiyor.
    • Eskiden aynı girdiye aynı promptu tekrar çalıştırıp ya da anlamsal olarak aynı olduğunu düşündüğüm ama ifade veya yapısı farklı girdiler verip sonuçların ne kadar ayrıştığını çok test ettim. Bunu özellikle Sonnet ile Opus arasında ve çeşitli Qwen modelleri arasında çok yaptım.
      Herkese denemesini tavsiye ederim; zaten kullandığınız verinin dışında özel bir veri gerekmiyor ve sonuçlar oldukça sarsıcı. Düşündüğünüzden çok daha fazla rastlantısallık ve kararsızlık var; daha iyi prompt teknikleri ya da özellikle iyi veya kötü diye gördüğünüz sonuçlar aslında sadece tesadüf ya da model sürümü/boyutuna göre değişen davranışlar olabilir. Girdideki küçük farklar sonucu ciddi biçimde eğebilir. Şirkette bunların bir kısmına sihirli kelimeler diyoruz; belli teknik terimlerden, referanslardan ya da yöntemlerden sadece söz etmek bile sonucu büyük ölçüde iyileştirebiliyor.
      Burada bir teknik de var. Model, ajan döngüsünde hile veya kestirme kullanmasının zor olduğu bir öz değerlendirme yapısına giriyor ve öğrendiği yapı ya da alanla uyuşursa çok iyi çalışıyor. Ama en iyi noktayı bulmak zor. Bir ipucu vereyim: Opus 4.8’den bir PyTorch modelini ONNX’e ya da kuantize edilmiş bir modele dönüştürmesini veya başka donanımda çalıştırmasını isterseniz, gerçekten özel bir yeteneği açılmış gibi çok iyi iş çıkarıyor. Buna karşılık, genel dil veya formatlar için EBNF biçimselleştirmesini hile yapmadan doğru biçimde yazdırıp test ettirmeyi bir türlü başaramıyorum.
      En kötüsü, bu tür bilginin çok sık değişmesi; bu yüzden gerçekten modeli eğiten kişilerden biri değilseniz çok derine inmenin faydası neredeyse yok. Keşke çıktıların istikrarı eğitimde daha çok öne çıkarılsa da davranış daha öngörülebilir hale gelse. Aşırı öğrenmeye ya da keşif-kullanım döngüsünü bozmadan bunu yapmak zor olabilir ama toplu işleri daha istikrarlı şekilde yürütebilseydim LLM’lere çok daha fazla para harcardım.
    • Bu, enstrüman çalmaktan ziyade slot makinesi çevirmeye ve gerisini hayal etmeye daha yakın görünüyor.
    • Çoğuna katılıyorum ama bir noktada farklı düşünüyorum. Claude’a doğru anda sert çıkmak bazen inanılmaz etkili olabiliyor. Özellikle F-bomb, bazen Claude’un takılıp kaldığı yerden çıkmasına epey yardımcı oluyor gibi.
    • GLM 5.2’den eski bir C#/XNA oyununu HTML5’e port etmesini istedim; kodu neredeyse birebir taşıdı, yalnızca JS’de olmayan operator overloading kısımlarını hariç tuttu ve çalışması için ek kod ekledi.
      Aynı isteği Claude Sonnet 4.6’ya yaptığımda ise sanki oyun baştan JS ile yazılmış gibi bir sonuç çıktı. Üstelik nedense bunu tek bir HTML dosyası olarak hazırladı, tüm asset’leri kaldırdı, grafikleri ve müziği dinamik olarak üretti, hatta daha iyi yeni bir arka plan bile yaptı.
      Ben sadece oyunun port edilmesini istemiştim, o yüzden şaşırdım. Yaptığı seçimleri oldukça beğendim ama bu davranışı nasıl açıp kapatacağımı bilmiyorum. Bazen yaratıcılık gerekiyor, bazen de gerçekten söylediğimi aynen yapmasını istiyorum.

  • Bu yazı ve aldığı övgüler bana çıplak kral durumunu hatırlatıyor. Daha şu cümleden itibaren bir şeyler oturmuyor:
    “These products use very low level Linux primitives like containers, Kubernetes, Firecracker microVMs, and networked protocols.”
    “Düşük seviye Linux primitive’leri” denebilecek şeyler arasında olsa olsa ağ protokolleri bir şekilde savunulabilir. Ayrıca metin bariz biçimde yapay zeka üretimi gibi görünüyor. İçeriğe güvenebilsek sorun değil ama güvenemiyorum.

    • Bugünlerde düşük seviye, TypeScript yerine JavaScript demek.
    • O cümlenin fazla sıkıştırılmış olduğu doğru. Yeniden ifade ettim ve anlamı aynı kaldı.
      Yazı yapay zeka üretimi değil; kodu yapay zekayla üretiyorum ama yazıyı kendim yazıyorum. Hangi kısmın anlaşılmadığını merak ediyorum. Bu yazı bizim kendi deneyimimizi ve yolculuğumuzu anlatıyor; belli iddialar için de memnuniyetle dayanak sunabilirim.

  • Yapay zekanın gücünün, sonunda sonsuza kadar para ödemek zorunda olduğunuz ve zamanla şirket hissedarlarının açgözlülüğünü doyurmak için daha da kötüleşen bir başka bulut hizmeti olmasından değil, yerelde güvenli ve özel biçimde uygulandığında ortaya çıktığına hâlâ inanıyorum
    ChatGPT ya da Anthropic’in sağlık verilerimi kendi sistemlerine kilitlemesine asla izin vermem, ama yapay zekanın benim kaçıracağım veri kalıplarını bulma yeteneğine hâlâ güveniyorum. Bu yüzden Qwen ya da Gemma gibi şeylere verileri güvenli ve gizli biçimde açıp işletebilen yalnızca yerel bir ekosisteme acilen ihtiyaç var
    Akıllı ev ve kişisel asistanlar için de aynı durum geçerli. A şirketinin B şirketinde tutulan verilere eriştiği, D ve E şirketlerinin bunları işlediği, ardından reklamverenlere ve veri broker’larına sattığı ama benim bunu kendi yerel donanımımdan çıkarma ya da görme imkânımın olmadığı kurumsal yaklaşım, bu tür özel kullanım alanları için sürdürülebilir değil. Verilerim benim koşullarımla sahip olunmalı, kontrol edilmeli ve açığa çıkarılmalı; önce benim hayatımı iyileştirmek için kullanılmalı, başkasının kâr-zarar tablosunu iyileştirmek için değil. Teknolojinin bana yeniden zaman kazandırmasını ve sonuçları iyileştirmesini istiyorum; Big Tech’ten fazlasıyla darbe yediğim için de Hizmet Olarak Yapay Zeka iş modelinde asalet ya da kamu yararı olduğu varsayımını kesin biçimde reddediyorum
    Yetenek zaten var; yerel modellerin potansiyelini destekleyen ve açığa çıkaran yerel araçlar yapan insanların doğru yönde olduğunu düşünüyorum. Onların yaptıklarını görmek hoşuma gidiyor

    • “Yerel” modellerin özü genelde açık ağırlıklar olmasıdır; bazen açık kaynak da olurlar. Bu yüzden yerelde kullanılabildikleri gibi bağımsız sağlayıcılar tarafından da barındırılabilirler
      Qwen, DeepSeek gibi modelleri kullanırsanız tek bir şirkete bağlı kalmaz, daha iyi gizlilik güvenceleri de sunabilecek bağımsız sağlayıcılar arasında geçiş yapabilirsiniz. Böylece internet bağlantısı olduğu sürece modeli doğrudan çalıştıramayan cihazlarda da kullanabilirsiniz
      Yapay zekanın gücü açık kaynak modellerde yatıyor. Sağlayıcı bağımlılığından kaçınmalı, hem yerel kullanımı hem de bağımsız sağlayıcı barındırmasını mümkün kılan modeller kullanmalıyız

  • Güzel bir yazı. Ancak iyileşme olasılığını küçümsüyor gibi görünüyor
    Yazarlar da 1 yıl önceki yerel modellerle bugünkünü karşılaştırmanın anlamlı olmadığını kabul ediyor. Nitekim insanlar, geçen kasımdaki Opus 4.5’i, yani 8 ay öncesini, frontier barındırmalı modellerde bile ajan tabanlı kodlamanın yaygın biçimde mümkün hâle geldiği ilk an olarak görüyor
    O hâlde şu anda yerel modellerin neyi iyi yapıp neyi yapamadığına dair kavramı neden özellikle sabitleyelim? Bugün ne varsa, muhtemelen 1 yıl sonra farklı olacak. Tüketici ve profesyonel donanımda uzun menzilli görevlerin de mümkün olacağını düşünmek saf bir iyimserlik olabilir, ama şimdiye kadar kazanan hep o saf iyimserler oldu

    • Doğru. Opus 4.5 8 ay önce ajan tabanlı kodlama için yeterli hâle geldiyse, açık ağırlıklı modeller ne kadar geride? 8 aydan da mı fazla? Ne kadar fazla? Birkaç ay içinde Opus 4.5 seviyesine ulaşırlar mı, 1 yıl içinde mi, yoksa asla mı?
    • Büyük ölçüde eksik olan şey harness karşılaştırması. Bunun etkisi çok büyük. forge kullanıyorum; yerel modellerin tüm sınırlamalarına rağmen başarılabilen şeyler etkileyiciydi
    • Yazar belirli bir modeli ele aldığı için, o modelin ya da genel olarak yerel modellerin zamanla nasıl iyileşeceğini yok saymanın sorun olmadığını düşünüyorum
      Bu biraz araba satın almaya benziyor. O arabayı sürer ve özelliklerine alışırsınız; o arabanın ya da benzer arabaların gelecekte nasıl iyileşeceğini düşünmezsiniz. Bu benim aracım ve ondan mümkün olan en yüksek verimi almak istiyorum
      Elbette yerel modeli değiştirme maliyeti teknik olarak çok düşük, ama o modelden en yüksek performansı çıkarmak için ciddi zaman gerekiyor ve o emek yeni sürümde işe yaramayabilir
    • Claude 4.5’in ajan tabanlı kodlamada bir dönüm noktası olduğu konusunda %100 katılıyorum. O model yüzünden fikrim tamamen değişti

  • İlginç bir yazı. Şahsen yazarın iki şeyi daha iyi yapmasını isterdim
    Birincisi, llama.cpp yerine vLLM kullanmalıydı. NVIDIA donanımında çok kullanıcılı yük ve önbelleklemede vLLM farkı devasa. İki ya da daha fazla kullanıcının modeli kullandığı ya da önbelleğin kaybolmasından şikâyet edilen kısımlarda “tabii ki öyle olur” diye düşündüm
    İkincisi, tek karta harcanan bütçe SPARK üzerinde çok daha iyi değerlendirilebilirdi. 2 x GX10 kümesi kullanılabiliyor; toplam maliyet bugün bile yazarın ödediğinin yarısından daha düşük ve vLLM ile Deepseek v4 Flash çalıştırılıyor. Qwen ile karşılaştırınca fark çok büyük. Döngüye girdiğini hiç görmedim ve şimdiye kadar denediklerim içinde Sonnet’e en çok benzeyen model. Antirez de aynı fikirde gibi; sanırım bu yüzden ds4 fork’unu yaptı
    2 adet GX10 üzerinde nasıl kurulduğu burada: https://forums.developer.nvidia.com/t/deepseek-v4-flash-offi...
    Performans ön doldurmada 2K token/sn, bu yüzden devasa bağlam pencerelerine büyük miktarda kaynak kodu koyarken çok kullanışlı; pi.dev harness ile kod yazarken üretim yaklaşık 50–60 token/sn. Yazarın ödediği parayla 4 adet GX10 alınabilirdi ve vLLM tensör paralelleştirmede neredeyse doğrusal ölçeklendiği için her iki sayı da iki katına çıkarılabilirdi

    • 3090’da da vLLM denedim. Bizim gibi bir kişiden birkaç kullanıcıya kadar olan kullanım deseninde üretim yaklaşık 3 token/sn daha yavaştı, nicemleme esnekliği daha düşüktü ve başlangıç süresi de tek haneli saniyeler yerine gerçekten birkaç dakika sürüyordu
      İleride tekrar daha fazla kurcalayabilirim ama sonsuz vakit ayırıp ince ayar yapamam; şimdiye kadarki yolculuğumu ve değerlendirmemi paylaşıyorum
      Eşzamanlı toplu servis için vLLM doğru tercih, barrkel’in aşağıda söylediği de tam isabet. Ama bizim kullanım biçimimizde llama.cpp hâlâ daha iyi
      Spark/GX10 yolu gerçekten farklı bir bahis ve sayıları paylaştığın için teşekkürler. Daha birkaç ay öncesine kadar genel hava, GX10’un yalnızca ince ayar için olduğu ve performans rakamlarının ciddi biçimde düşük kaldığı yönündeydi
      Ayrıca o kartlar kesinlikle Claude Max aboneliğinin yerine geçsin diye alınmadı. Asıl satın alma amacımız olan işlerde zaten 140–200 token/sn alıyoruz ve önemli olan da bu

  • Yazı uzundu ama yazarın asıl ne söylemeye çalıştığını hâlâ anlamadım. Başlıktan çıkarılabilenin ötesinde bir şey yok
    Yine de yazarın fiziksel şeyler de yapan, yazılım da geliştiren oldukça havalı biri olduğunu ve başka insanların ona para verdiğini öğrenmiş oldum. Bunun başlığın ima ettiği konuyla ilgili olup olmadığını bilmiyorum

    • Artık her şey reklam. Yazı tamamen faydasız değildi ama sunduğu bilgi miktarı düşünüldüğünde iki paragraf yeterli olurdu

  • Bu yazı yerel modelleri iyi özetliyor. Bazen kodlama ve ajan tabanlı yerel işler için harika bir araçmış gibi abartılsa da, gerçekte oldukça sınırlılar; uzun ya da karmaşık işlerde zayıflar ve döngüye girme ya da görevi unutma eğilimleri vardır
    Yazıda eksik kalan nokta, maliyetin de epey yüksek olması. Sadece donanım maliyeti değil, elektrik faturası da var. 3090 ya da 5090 makinesi çok güç tüketiyor ve bu makinelerde modeller oldukça yavaş çalıştığı için token başına enerji tüketimi daha da artıyor
    Parladıkları noktalar ise denetlenebilirlik, gizlilik ve öngörülebilirlik. Örneğin fotoğraf ve video kütüphanelerini sınıflandırmak gibi tekrar eden işlerde iyiler ve elektrik fiyatına bağlı olarak maliyet açısından da avantaj sağlayabilirler

    • Yerel modellerin kişisel bilgisayarın vazgeçilmez bir uzantısı olduğuna inanıyorum. İlk kişisel bilgisayarlar için de benzer eleştiriler yapılmış olmalı
    • Hayalim, günlük işlerin yaklaşık %80'ini halledebilen bir yerel model. Örneğin “X Handler, Y storage'a nasıl bağlanıyor?” ya da “O özelliği commit et ama ödeme ile ilgili kısmı çıkar” gibi işler
      Araç çağrısının %99 güvenilir olması gerekir ve her şeyden önemlisi, “Bu görev benim kapasitemin dışında” deyip bunu bir yerde dev bir veri merkezinde çalışan çevrimiçi yüksek performanslı modele devredebilmelidir
      Böylece basit işler cihaz üzerinde halledilirken veri toplanır ve sorunun bağlamı anlaşılır; kolay işler bittikten sonra da akıllı model devreye girip problemi çözer
      Yerel modelin %100 yapabildiği bir /commit tekniğinin çevrimiçi modeli çağırması gerçekten saçma hissettiriyor. Ama bu çoğunlukla bir harness sorunu, yani büyük ölçüde çözülebilir
    • Yerel modeller birçok kullanım için gerçekten harika ve çoğu insanın en ileri seviye modele ihtiyacı olmadığını düşünüyorum. Küçük bir 4070 12GB üzerinde Qwen modelini kişisel e-posta ajanımda çalıştırırken her şeyden önce gizlilik önemli
      Gayet iyi iş çıkarıyor ve kodlama işlerinde de büyük planları bir kerede önüne atmak yerine nasıl kullanılacağını biliyorsanız çok başarılı oluyor
    • MTP değişikliği geldikten sonra 350W ile sınırlandırılmış bir 4090 üzerinde qwen3.6:27b ile 40~50 token/saniye alıyorum. Üst sınır baz alındığında yaklaşık 8.75J/token ediyor
      Bunun diğerleriyle kıyaslandığında nasıl olduğunu bilmiyorum ama 5090'ın aynı güç sınırında daha hızlı olacağı için biraz daha ucuz olmasını bekliyorum
    • Bunlar bugünkü donanım için geçerli. Peki gelecekteki donanım nasıl olacak? Çıkarım optimizasyonlu donanım nasıl olacak? Belirli bir modeli çalıştırmaya optimize edilmiş donanım nasıl olacak?

  • vLLM'in llama.cpp'den daha yavaş diye kenara atılması ilginçti
    Benim deneyimimde vLLM, llama.cpp'den epey daha hızlı ve özellikle eşzamanlı yükte batch işleme tarafında ezici üstünlük sağlıyor. Eksisi ise ayar esnekliğinin dramatik biçimde daha düşük olması. Kuantize ağırlıkları çalıştırmak için çok az seçenek var ve hesaplama grafiğini optimize ettiği için başlangıç süresi çok daha uzun sürüyor. Bu yüzden donanıma göre biraz büyük bir modeli tek kullanıcının denediği senaryolarda vLLM bunaltıcı gelebilir

    • Şöyle de denebilir: vLLM, daha kötü bir Llama.cpp değil, farklı bir araç
    • vLLM sürekli batch işleme ve production model serving için harika, ama prosumer kategorisinde çok daha az çok yönlü olan bambaşka bir şey
      “Kenara attı” ifadesi sert ama daha ayrıntılı söylersem, 2x 3090 kurulumunda yükleme 4 dakikadan uzun sürdü ve tek bir istekte 3 token/saniye daha yavaştı
      En kötü tarafı, kurup ince ayar için onca emek verdikten sonra hâlâ döngüye girmesiydi. Oradan buradan duyulan “sadece vLLM kullan” tavsiyesinin sihirli çözüm olmasını ummuştum
      Burada dikkat edilmesi gereken bir nokta da insanların Ollama'ya yaptıkları gibi llama.cpp'yi küçümsemeye başlamaması. llama.cpp son derece yetkin bir araç ve bizim bu kartları fiilen kullanmak istediğimiz amaç için daha uygun
      Büyük bir ekip Claude aboneliğinin yerine bir şey koyacaksa vLLM tek seçenek olabilir ama GLM 5.2 gibi bir şeyi ayağa kaldırmak için herhâlde 5 tane daha RTX 6000 kart eklemek gerekir
    • Hatırladığım kadarıyla genel fikir birliği, tek kullanıcı için llama.cpp, çok kullanıcılı ya da kurumsal kullanım için vLLM yönündeydi. Benzerler ama kullanım amaçları farklı
    • Birden çok kullanıcı modeli kullandığında cache prefix'in bozulduğundan şikâyet edip yine de llama.cpp kullanmaya devam edip vLLM'e geçmemeleri biraz şaşırtıcıydı

  • “Model fazla sıcak çalışıp hedefi aşıyor ve döngüye giriyor” denirken, devamında vLLM'in son deney olarak ayarlandığı ama NVLink ve tensor parallelism açık olsa bile llama.cpp'den üretimde 3 token/saniye daha yavaş olduğu söyleniyor
    Benim bütün testlerimde vLLM kullanmak buna değdi. Döngü sorunu, ajanın saçmalaması, göreve odak kaybı ve uzun bağlamın fiilen işe yaramaz hâle gelmesi sorunlarına en büyük katkıyı sağlayan tek unsur buydu
    vLLM'de FP8 model ve kuantize edilmemiş cache kullanıldığında genel deneyim diğer tüm yığınlara göre bir seviye yükseliyor. Ondan sonra ayarlarla oynamayı bırakıp modeli başka işlerde kullanmaya odaklanabiliyorsunuz

    • Bu kısım gerçekten merakımı çekti. Katılmadığımdan değil, ajanın saçmalamasını önlemek istediğim için. vLLM'i sadece kendiniz için mi, ekip için mi, yoksa uygulama için mi kullandığınızı merak ediyorum
      Ayrıca vLLM'in bu şekilde yararlı olması için asgari bir donanım gereksinimi olduğunu düşünüp düşünmediğinizi de merak ediyorum. Hafta sonu projesi olarak eski veri merkezi parçalarıyla ev tipi bir çıkarım sunucusu kurmayı planlıyorum ve nihai yapılandırmayı kafamda sürekli yeniden şekillendiriyorum
    • Neden Q8 yerine kuantize edilmemiş cache kullandığınızı merak ediyorum

  • Kendi AI donanımını satın alıp kurmak isteyenlere, önce çeşitli çıkarım sağlayıcılarından birine bağlanıp farklı modelleri bir süre bizzat kullanmalarını tavsiye ederim
    Maliyeti neredeyse yok ama kendi donanımınızla neler elde edebileceğinize dair oldukça iyi bir ön izleme sağlıyor. Sadece dostça bir tavsiye