Ask HN: Günlük kodlamada Claude/GPT yerine yerel model kullanan var mı?

• Veri gizliliği ve LLM’leri ücretsiz kullanma gerekçesiyle bulut modellerini tamamen bırakan geliştiriciler ortaya çıkıyor; konteynerleştirilmiş ve sandbox’lanmış çevrimdışı kodlama harness’leriyle dış ağa çağrı yapmadan çalışmak mümkün
• Öne çıkan modeller Qwen3.6 35B-A3B (3B aktif parametre sayesinde yüksek hız) ve 27B dense model; kodlama doğruluğu ile token üretim hızı arasında bir ödünleşim var
• En çok anılan kombinasyon Pi harness ve llama.cpp; tool calling’in yerel modellerde ilk kez tutarlı çalışması kullanım deneyimini ciddi biçimde iyileştirmiş durumda
• Claude Opus’a kıyasla yerel modeller "yönlendirme gerektiren junior vs birlikte tasarlayan senior" düzeyinde bir fark gösteriyor; hassas prompt’lar ve işi parçalara ayırmak şart
• Bugünkü yerel modeller yaklaşık 8~18 ay önceki frontier seviyesi olarak değerlendiriliyor, ancak ücretsiz kullanım, gizlilik ve kota derdi olmaması gibi somut avantajlar sunuyor

---

Yerel modellere geçiş örnekleri ve donanım yapılandırmaları

• Qwen3.6 35B-A3B, Mac Studio 128GB veya MacBook 36GB RAM üzerinde Pi harness ile çalıştırılarak Django + Wagtail tabanlı bir sitenin ana sayfası ve blogu tamamen yeniden tasarlandı
  • İnternete erişim olmadan, daha az bilinen Wagtail geliştirmelerinde model her zaman ne yapacağını bilmiyor
  • Karmaşık işler için Qwen3.5 122b kullanılıyor, ancak 10B aktif parametre nedeniyle oldukça yavaş
• Strix Halo 128GB birleşik bellek ortamında Pi konteyner içinde izole edilip yalnızca çalışma dizinine erişim veriliyor, kimlik bilgilerine erişim yok
  • Sohbet ve çeviri için Gemma 4 31B, ses için Gemma 4 12B kullanılıyor
  • Qwen 3.5 122B-A10B, Nemotron 3 Super 122B-A12B, Step 3.7 Flash, GPT-OSS 120B gibi birçok model mevcut olsa da kodlama için en iyi seçenek 35B-A3B
• 5 yıl önce yapılmış çift RTX3090 makinede Qwen ve Gemma modelleri UD-Q4_K_XL quantization ile ~150tok/s hızına ulaşıyor; tüm 300k context VRAM içinde işleniyor
  • Bu kurulum aylık $100 Claude aboneliğinin yerini aldı; kişisel kullanımda öncelik ücretsiz çözümler
  • Android TV launcher, k8s yönetim portalı, Home Assistant entegrasyonu, market ve öğün yönetimi gibi farklı projeler gerçekleştirildi
• RTX 6000 ile Qwen 3.6 27b + Open Code kombinasyonu kodlama işlerinin %90’ını karşılıyor, ancak çok karmaşık işler ve UI polishing için Codex’e geri dönülüyor
  • 256k context’te 100k sonrasında kalite ve hız düşüyor, 150k’dan sonra durum ciddileşiyor
• RTX 5090 üzerinde Qwen 3.6 27b (Q6 quantization) + llama.cpp kullanılıyor; GPU gücü 600W→450W ile sınırlandırılarak sessizlik sağlanıyor
  • Branch commit’leri ve PR oluşturma, Stripe CLI ile fatura mutabakatı, Elasticsearch yük analizi gibi günlük işlere kadar genişlemiş durumda

Model türleri ve performans özellikleri

• MoE vs dense model ayrımı kodlama kalitesini doğrudan etkiliyor
  • Qwen3.5-122B aslında 122B-A10B; yani MoE yapısında yalnızca 10B aktif oluyor, Qwen3.6-27B ise 27B’nin tamamının her zaman aktif olduğu dense bir model
  • MoE’de aktif/toplam parametrelerin geometrik ortalamasıyla dense eşdeğeri kalite yaklaşık hesaplanabiliyor: sqrt(35×10)≈18.7
  • MoE, aynı boyutta dense modele göre daha düşük kalite verse de daha hızlı; ayrıca CPU RAM offload ile büyük MoE’ler de çalıştırılabiliyor
• Quantization seviyesi döngü oluşumu ve doğruluğu etkiliyor
  • Q8 quantization daha yavaş ama döngüleri azaltarak toplam süreyi kısaltabiliyor
  • KV cache’in özellikle K kısmı quantization’a çok hassas; F16 K + Q8 V ile döngüler büyük ölçüde azalıyor
• Çift GPU eklemenin amacı inference hızını artırmak değil, VRAM kapasitesi kazanmak
  • Gemma-4 31B dense ile 26B MoE, Q4 quantization’da benzer kalite verirken MoE yaklaşık 3 kat daha hızlı (~150tok/s vs 46tok/s)

Yerel modellerin sınırları ve başa çıkma stratejileri

• Hassas prompt gereksinimi

  • Varsayımları açık bırakırsanız model en kısa yolu seçiyor (ör. HTML içinde CSS) ve bu da mimari açıdan en iyi sonuç olmayabiliyor
  • Mimari belirtilmezse hızlı ve dağınık düzeltmeler yapıyor; debug metinlerini kaldırması söylenmezse bırakıyor
  • Claude Opus kullanıcı niyetini çıkarabiliyor ama küçük Qwen modelleri yalnızca söyleneni yapıyor; tasarım bilgisini açıkça “etkinleştirmek” gerekiyor

• Döngüler ve düzenleme aracı hataları

  • Edit tool çağrılarını sık sık yanlış yapıyor, yeniden denemek yerine düşünme token’ları tüketip dosyayı tekrar okuyor
  • Elle yeniden denemek çoğu zaman edit çağrısını düzeltiyor, ancak model sorunu daha temel sanıp gereksiz token harcıyor
  • Hash tabanlı düzenleme yaklaşımı (her kod satırının hash’iyle referans verme) hataları azaltabiliyor, fakat context kalitesi tükendikten sonra başka biçimde çöküyor
  • AGENTS.md kurallarıyla yeniden yazmak yerine düzenleme yapmak konusunda kısıt koymak kısmi iyileşme sağlıyor

• Context window yönetimi

  • 65.000 pencere yalnızca kod dosyası yapısını okumakla bile aşılabiliyor; 200k+ gerekiyor
  • Qwen3.6-35b, 16GB VRAM’de 256k context’i 128k olarak sorunsuz işleyebiliyor
  • Qwen3.6-27B, 1 milyon token context desteği sunuyor; DGX Spark’ta f16 KV cache ile yaklaşık 100GB bellek istiyor

Prompt caching ve muhakeme koruma sorunu

• Qwen hibrit modelleri prompt caching’i iyi işleyemeyip her turda tüm context’i yeniden işleme sorunu yaşayabiliyor
  • Çoğu yerel model, turlar arasında tam muhakemeyi koruyacak şekilde eğitilmediği için uzun tool calling zincirlerinden sonra muhakeme kaldırılmış halde yeniden işlemek gerekiyor
  • Qwen 3.6, muhakemeyi korumayı öğrendiği için chat-template-kwargs = {"preserve_thinking": true} ayarıyla cache yeniden kullanımı iyileşiyor
• Modern LLM’ler yalnızca full attention kullanmıyor; local attention (sliding window, Mamba-2 state space model) da kullanıyor
  • Full attention O(n²) maliyetli ve zaman içinde değeri değişen muhakemeye karşı zayıf
  • Local attention, snapshot saklayarak cache yeniden hesaplandığında son snapshot’tan başlamayı sağlıyor; ancak snapshot büyürse saklama sınırına takılıyor
  • Qwen 3.5 ve sonrası, attention ile SSM katmanlarını dönüşümlü kullanan Gated DeltaNet yapısını kullanıyor
• Vulkan, ROCm’den paradoksal biçimde daha hızlı olabiliyor ve llama.cpp’nin güncel tutulması yeniden işleme sorunlarını çözmek için önemli
• Autoregressive üretim token’larının prefill aşamasında farklı parse edilmesine yol açan tokenizer divergence sorunu ise çözülmesi zor bir problem

Maliyet ve güç ekonomisi tartışması

• 2x RTX3090 yaklaşık $4400; bu da aylık $100 Claude baz alındığında 3,6 yıllık maliyete denk geliyor, üstelik elektrik ve diğer parçalar hariç
  • 3,6 yıl sonra bile yüksek kapasiteli GPU fiyatlarının yüksek kalması muhtemel
  • Elektriğin pahalı olduğu bazı bölgelerde başa baş noktası yaklaşık 1 yıl olabiliyor
• Güç tüketimi beklenenden düşük
  • 1.2kw tam yükte yaklaşık $0.12/saat, güneş enerjisine bağlıysa daha da ucuz
  • Inference yükü oyun yükünden farklı olduğu için güç sorunu sınırlı; sistem boşta 200W, inference sırasında 350-450W seviyesinde
• Donanım satın alma zamanı konusunda
  • Şu an iyi bir alım zamanı değil; bir sonraki uygun pencerenin 24-36 ay sonra gelmesi bekleniyor
  • 48GB birleşik RAM’li M4 Pro Mac mini (~$2k), bütçe dostu inference cihazı olarak öneriliyor; ~150tok/s ile önümüzdeki 10 yıl kullanılabilir deniyor
  • AMD R9700 32GB VRAM (~$1200-1400), AI kullanımında 2x 9070’e göre daha avantajlı görülüyor
• Kiralama (bulut aboneliği) da meşru bir strateji; herkes donanıma büyük para ayıramaz

Frontier modellere kıyasla değerlendirme

• Yerel modellerin “8~12 ay önceki üst seviye model kalitesi” sunduğu değerlendirmesi sıkça tekrar ediliyor
  • Benchmark’larda Qwen 3.6 35B-A3B, Claude 4 Opus’u geçiyor görünse de bazı açık kaynak modellerde benchmark odaklı aşırı optimizasyon olabileceği söyleniyor
  • Bir YouTube browser OS testinde Qwen 3.6, Claude 4 Opus’tan daha fazla çalışan özellik üretmiş
  • Ancak bunun 1 yıl önceki frontier düzeyi olduğu, 3B aktif MoE’nin güncel Opus ve Sonnet ile kıyaslanamayacağı yönünde güçlü itirazlar da var
• “Opus seviyesinde” tanımındaki anlaşmazlık tartışmanın merkezinde
  • İsimlendirme 2024’te Claude 3 Opus’tan beri kullanılıyor; yine de en yeni Opus 4.8 ve 4.6 modelleriyle arada fark sürüyor
  • Geçen yıl kasımdaki Opus 4.5 ve GPT 5.2 ile frontier modellerde kademeli bir sıçrama yaşandı; genelde “Opus seviyesi” ifadesi 4.5 sonrasını ima ediyor
  • En büyük açık ağırlıklı modeller 8x H100 sınıfı sunucu donanımı gerektiriyor; ev tipi modeller hâlâ bu seviyenin altında
• Bazıları yerel modelleri Haiku 4.5 ile Sonnet 4.5 arası olarak değerlendiriyor; mikroyönetimle iyi sonuç alınabiliyor
• Frontier ile yerel arasındaki farkın her zaman var olacağı düşünülüyor, ancak birçok kullanıcı için yerel modeller şimdiden pratik düzeyde

Harness ve iş akışı stratejileri

• Pi harness en çok önerilen seçenek; bir agent geliştirme kiti gibi görülüyor, “Claude’un VS Code’una karşı neovim” benzetmesi yapılıyor
  • Temel araçlar (dosya erişimi, düzenleme, bash) sağlıyor; MCP adapter ve web search genişletmeleri eklenebiliyor
  • /tree komutuyla başarısız tool çağrısından önceki context’e dönülebiliyor, /new ile context sıfırlanabiliyor
• Katmanlı ve rol paylaşımlı workflow ile sınırlar telafi ediliyor
  • Frontier modelle spec, tasarım ve yürütme planı hazırlanıp uygulama yerel modele bırakılıyor
  • Agent’lar role göre zincirleniyor (proje yöneticisi, schema agent, coding agent); orchestrator ve Playwright ile yalnızca hata sonraki aşamaya aktarılıyor
  • İşler atomik TODO’lara bölünüp referans dosyalar açıkça belirtilerek context tasarrufu sağlanıyor
• OpenCode, her turda system prompt’u değiştirerek KV cache ile uyumsuzluk yaratabiliyor; yerel LLM desteği manuel ve karmaşık ayarlanıyor
• Ollama, bulut model ekleme ve gelir modeli nedeniyle eleştiriliyor; bunun yerine llama.cpp ve llama-swap öneriliyor, macOS’te llm-mlx %10-15 daha hızlı

Paylaşılan somut yapılandırma örnekleri

• AMD 7900xtx 24GB + 5950x + 64GB DDR4 ortamında Qwen3.6-27B-MTP-UD-Q4_K_XL, llama.cpp Vulkan ile çalıştırılıyor
  • Başlıca bayraklar: -ngl 99 (tüm katmanları GPU’ya offload), -c 80000 (80K context), --cache-type-k q8_0 --cache-type-v q8_0 (8-bit KV cache), -fa on (flash attention), --spec-type draft-mtp (MTP draft)
  • Sampling: --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0 (Qwen kodlama için önerilen değerler)
  • Performans: token üretimi ~65t/s, prompt işleme ~600t/s, cold start ~30 saniye
  • Crush harness + Headroom + Exa MCP web search kombinasyonuyla kişisel Claude Code aboneliği iptal edildi
• V100 32GB üzerinde Qwen3.6-27B-UD-Q4_K_XL + Pi kullanılıyor; llama-cpp-turboquant fork’u ve MTP patch uygulanmış
  • 200.000 context, --spec-type mpt --cache-type-k turbo3 --cache-type-v turbo3 ile 45-60 t/s
• Strix Halo 128GB üzerinde Qwen3.6-35B-A3B, prompt işleme ~800tps ve token üretimi 50tps sunuyor; boşta neredeyse hiç güç tüketmiyor
  • 122B sürümünün çıkmamış olması eksiklik olarak görülüyor; birleşik bellek ortamında dense modeller bellek bant genişliği sınırı yüzünden yavaş
• Ayrıca ayrıntı eksikliğinden şikâyet edenler de var; quantization, parametre, context, GPU, VRAM ve harness yapılandırmalarının açıkça belirtilmesi isteniyor

[b89kim]

Pi-coding-agent+Qwen3.6-27B-MTP-GGUF kullandığımda performans Sonnet 4.5 civarındaydı. Basit uygulamalar yapmak için yeterliydi ve gerektiğinde ara sıra ücretsiz API’ler (GLM5.1 vb.) ekleyerek kullandım. 4090/5090 sınıfı GPU’ların güç tüketimi yüksek, ama düzgün yazılmış bir agent ise saatlerce çalıştırmanız gereken durum çok olmuyor.

[GN⁺]

Hacker News görüşleri

• Greenpants: Veri gizliliği ve ücretsiz LLM’ler önemli olduğu için Pi coding harness’ını konteyner/sandbox içine koyup tamamen çevrimdışı kullanıyorum
  Mac Studio 128GB ya da MacBook 36GB üzerinde Qwen3.6 35B kullanıyorum; etkin parametre sayısı 3B olduğu için oldukça hızlı. Django + Wagtail ile ana sayfa ve blogu baştan tasarladım ama Wagtail daha az bilindiği için, internet olmadan ajan bunu her zaman iyi bilmiyor
  Daha karmaşık işler için Qwen3.5 122B de kullandım ama etkin 10B olduğu için çok daha yavaş. Claude gibi büyük modellerle karşılaştırınca soruları çok net sormak gerekiyor ve boş bırakılan varsayımları genelde kolay yoldan çözüp CSS’yi HTML’e gömmek gibi mimari açıdan zayıf seçimler yapıyor
  Düzenleme aracı çağrılarını da sık sık yanlış yapıyor ve döngüye giriyor. Qwen3.6 35B genel bilgiye sahip ama sürekli yönlendirilmesi gereken bir junior gibi; Claude Opus ise mimariyi birlikte düşünen bir senior’a daha yakın. Opus 15 kat hızlandırma sağlıyorsa, tamamen çevrimdışı Qwen yaklaşık 5 kat sağlıyor ama ücretsiz olduğunu düşününce yine de şaşırtıcı

  • lambda: Benzer şekilde Pi’yi konteyner içinde çalıştırıyorum ve başka bir konteynerdeki llama.cpp’ye bağlayarak kullanıyorum
    Ağ erişimine izin veriyorum ama kimlik bilgilerini engelliyorum; sadece çalışma dizinine ve ~/.pi konumuna erişmesine izin veriyorum. Strix Halo 128GiB birleşik belleğe sahip bir dizüstü kullanıyorum; özel araçlarla programlamayı tercih etmediğim için frontier modellerle ciddi bir karşılaştırma yapamıyorum
    Hâlâ bir AI şüphecisi olduğum için, gerçek kullanımdan çok modelleri zorlayıp güçlü ve zayıf yönlerini incelemeye zaman harcıyorum ama ajan tabanlı kodlama için en sık Qwen 3.6 35B-A3B seçiyorum. Genel sohbet/çeviri için Gemma 4 31B, ses için de sık sık Gemma 4 12B kullanıyorum
    Qwen 3.5 122B-A10B, Qwen 3.6 27B, Nemotron 3 Super 122B-A12B, Step 3.7 Flash, Minimax M2.7 ve GPT-OSS 120B de elimde var ama bu kurulumda kodlama için şu anda sweet spot’a en yakın olan Qwen 3.6 35B-A3B
  • geophile: Ben de neredeyse aynı deneyimi yaşadım. Planı çok dikkatli yapmak, işi küçük ve bağımsız adımlara bölmek gerekiyor; tasarımı da insanın açıkça yazması lazım
    Detayları qwen’in kendi başına doldurmasına izin verirsen, yazmaya başlamadan hemen önce döngüye giriyor. Düzenleme yapamama sorunu da garipti; bu yüzden AGENTS.md içinde yeniden yazmak yerine düzenlemeyi kısıtlayacak şekilde değiştirdim ve biraz faydası oldu
  • adyavanapalli: Düzenleme araçları için, her kod satırını hash’leyip değiştirirken o hash ile referans veren hash tabanlı bir yaklaşım düşünmeye değer
    Yaklaşımı https://blog.can.ac/2026/02/12/the-harness-problem/ adresinde görebilirsiniz. Bunu düzgün şekilde benchmark etmedim ama hissedilir biçimde düzenleme hatalarını azalttı; ortama göre değişebilir

• horsawlarway: Kişisel kullanım için aylık 100 dolarlık Claude aboneliğini iptal ettim ve bunu unsloth studio’ya işaret eden pi harness ile Qwen ve Gemma modelleriyle değiştirdim
  Yaklaşık 5 yıl önce kurduğum çift RTX3090’lı makinede unsloth/Qwen3.6-35B-A3B-MTP-GGUF ve unsloth/gemma-4-26B-A4B-it-GGUF modellerini UD-Q4_K_XL quantization ile çalıştırıyorum; ikisi de yaklaşık 150tok/s ve 300k tam bağlamı VRAM içinde işliyor
  Claude kadar iyi değil ama ücretsiz ve kişisel kullanımda bu fark büyük bir sorun yaratmıyor. Aynı çıkarım sunucusuna OpenClaw da bağlayıp kullanıyorum; yerel modeller için oldukça uygun bir kullanım alanı
  Örneğin Android TV için alternatif launcher, k8s servisleri için yönetici portalı, Home Assistant entegrasyon ve otomasyonları, alışveriş/yemek planı yönetimi, ComfyUI ile 3D varlık üretim iş akışları yaptım. Para kazandıran bir yazılımsa hâlâ ücretli sağlayıcıları öneririm ama yerel modeller de oldukça havalı işler yapabiliyor

  • rootlocus: İki RTX3090 yaklaşık 4.400 dolar ediyor; elektrik ve diğer parçaları saymasan bile aylık 100 dolarlık Claude’a göre 3,6 yıllık maliyet demek
  • kpw94: gemmayı UD-Q4_K_XL ile quantize edip çalıştırıyorsanız, unsloth/gemma-4-26B-A4B-it-qat-GGUF gibi QAT modellerine de bakmaya değer
    https://huggingface.co/unsloth/gemma-4-26B-A4B-it-qat-GGUF ve https://blog.google/innovation-and-ai/technology/developers-... bağlantılarına bakın. 9 Haziran güncellemesiyle MTP desteği de eklendi
  • twothreeone: Aynı unsloth/Qwen3.6-35B-A3B-MTP-GGUF modelini tek bir 3090, 128k bağlam ve Q4_K quantization ile çalıştırdım; yaklaşık 40~60tok/s gördüm
    Beni en çok rahatsız eden şey, orta karmaşıklıktaki gerçek kodlama işlerinde çıktı kalitesi oldu. Sürekli “prompt’la itekleme” ile “doğrudan kendim uygulama” arasında gidip gelmek zorunda kaldım; bu da bilişsel geçiş yükü yaratıyordu ve birkaç dakikada bir sorunun benim yanlış yönlendirmemden mi yoksa modelin yetersizliğinden mi kaynaklandığını değerlendirmem gerekiyordu
    Düşük seviyeli uygulama detaylarından yüksek seviyeli tasarıma geçmekte de iyi değil; tablo gibi şeyleri bile kolayca render edemiyor. Claude’da bu sorunlar yok, bu yüzden şu an için bir alternatif olarak görmüyorum ama birkaç ay içinde mümkün olmasını umuyorum. Claude CLI yerine aider kullanmaya başladım ama bu seçim de en iyi seçenek olmayabilir

• bluejay2387: Kodlamanın yaklaşık %90’ını Qwen 3.6 27B, Open Code, özel beceriler ve Semble ile hallediyorum
  CC ya da Codex kadar zeki değil ama işlerin çoğunu bitirebiliyor. RTX 6000’im var, bu yüzden TPS yeterince hızlı ve aslında bu GPU başlangıçta başka işler içindi
  Bunun, frontier modellere ne kadar yaklaşabildiğini görmek için bir denemeydi ama yeterince iyi çıkınca kullanmaya devam ettim. Gerçekten karmaşık işler ya da UI rötuşları için hâlâ Codex’e dönüyorum; UI tarafı Qwen’in en zayıf olduğu alan gibi görünüyor
  Tavsiye ettiğim bir kurulum değil. RTX 6000 sahibi çok kişi yok ve maliyeti birkaç yıllık MAX CC ya da Codex aboneliğine denk geliyor. Yine de burada bir potansiyel var; birkaç yıl sonra pratik hâle gelebilir
  256k bağlamda compact target’ı %75’e ayarladım; konuşma 100k’yi geçince kalite ve hız düşmeye başlıyor, 150k’den sonra ise ciddi şekilde sorunlu oluyor. Qwen 3.5 122B’yi de denedim ama kodlamada 3.6 27B’den çok daha kötüydü. Gemma 4 31B başka işler için iyi ama kodlamada Qwen önde, Nemotron Super 120B’nin de kodlamada Qwen’den kötü olması şaşırtıcıydı

  • heipei: RTX 5090’da llama.cpp ile Qwen 3.6 27B Q6 çalıştırıyorum ve artık sadece pi agent kullanıyorum
    Yerel olduğu için token fiyatı, kota, saat dilimi ya da veri hassasiyeti konusunda hiç endişelenmem gerekmiyor. GPU gücünü 600W’tan 450W’a sınırlandırdım; böylece çıkarım sırasında bile gayet sessiz çalışıyor
    Sadece kodlama için değil, günlük angarya işler için de çok kullanıyorum. Bir branch’e commit atıp PR açmak, Stripe CLI ile tahsil edilmemiş/gecikmiş faturaları alıp banka CSV’siyle karşılaştırmak, Elasticsearch kimlik bilgileriyle mevcut yükün nedenini özetlemek, kod tabanının X’i destekleyip desteklemediğini ve bunun nerede uygulandığını bulmak gibi işleri yaptırıyorum
  • bo1024: Qwen3.5-122B aslında Qwen3.5-122B-A10B
    A10B bir mixture-of-experts modeli; yani aynı anda yalnızca 10B parametre etkin oluyor. Qwen3.6-27B ise tüm 27B parametrenin her zaman etkin olduğu yoğun bir model. Bu yüzden birçok görevde 27B yoğun model, 122B-A10B’den daha iyi olabilir
  • user43928: İşte Qwen 3.6 27B’yi kullanmaya zorlanıyorum ve bana göre neredeyse işe yaramaz
    Kendim yapmam daha iyi; ya implementasyonu berbat ediyor ya da debug işini tamamen yanlış yapıyor. Daha akıllı bir arama özelliği olması dışında, Sonnet altındaki her şey zaman kaybı gibi geliyor
    Codex’i UI rötuşu için kullanmak da tuhaf. Codex, kötü UI’siyle biliniyor ve Claude Opus’un epey gerisinde. Altman da bir sonraki modelde bunu iyileştirmeye çalıştıklarını yazmıştı

• pierotofy: Llama.cpp + Qwen3.6-35B(MTP) + OpenCode kombinasyonu tek bir RTX 3090 üzerinde oldukça yetenekli ve çoğu bulut modelinden daha hızlı
  Kalite olarak 8–12 ay önceki edge modelleri kullanıyormuş gibi hissettiriyor. Kurulumu https://github.com/pierotofy/LocalCodingLLM/ adresinde derledim

  • jacobgold: “8–12 ay önceki edge model kalitesi” hobi amaçlı kullanım için harika ama profesyonel bir geliştiricinin kodlama ajanı için birincil araç olarak kullanması açısından, Opus 4.6 çıktığında yaklaşık 6 ay önce kritik eşik aşılmıştı diye düşünüyorum
  • trueno: 128GB M4 Max MacBook Pro’m var ve bununla oynamak istiyorum ama pek zaman bulamıyorum
    Benzer bir kurulum kullanan Mac kullanıcılarının deneyimlerini merak ediyorum. Yerel tarafla ilgili çok tartışma görüyorum ama referans noktası sürekli değişiyor ve terimlere de çok hâkim değilim. Yerel tarafa geçince neyi kaybedip neyi kazandığınıza dair nesnel izlenimleri duymak isterim
  • atomicnumber3: Artık Claude kullanmaya hiç niyetim yok

• codinhood: Bu soruya çok fazla “gerçek” cevap geleceğini sanmıyorum. Şu anda en yeni/en iyi modelleri kullanmamanın fırsat maliyeti fazla yüksek
  Her ay araştırıyorum ve sonuç hep aynı. Yerel modelleri ve çevresindeki kodlama araçlarını Claude Code’daki Sonnet/Opus seviyesine yaklaştırmak için gereken zaman, emek ve maliyet şimdilik buna değmiyor
  Değseydi şimdiye kadar haber olacak kadar yıkıcı bir gelişme olurdu. Birinin bunu çözmüş olabileceğini inkâr etmiyorum ama derin bir tavşan deliğine düşmemek için Occam’ın usturasına daha yakın geliyor

  • pyeri: O fırsat maliyeti FOMO treni de bir noktada doyuma ulaşacak; bence hatta çoktan ulaştı
    Mythos seviyesindeki modeller muhakemede en ileri noktada olabilir ama çoğu geliştiricinin çözmeye çalıştığı problem alanlarında çok da işe yaramıyor. Sonuçta şu anki Sonnet/Opus ailesinin yaklaşık 4.8 civarı seviyesi, kurumsal tarafta yaygın olarak kullanılan düzey olacak gibi görünüyor
    Yerel modeller henüz o seviyede değil ama DeepSeek, Kimi, GPT, MiniMax ailesini NVIDIA, OpenRouter, Groq gibi API’ler üzerinden ucuza kullanabiliyorsunuz ve bunlar Sonnet seviyesine epey yakın
  • mark_l_watson: Aynı sonuç bana da doğru görünüyor. Yerel, OpenCode + DeepSeek v4 flash gibi ticari API’ler ve DeepSeek v4 Pro arasında giden katmanlı bir sisteme geçmek istiyorum
    Böylece gereken işleri yapmaya devam ederken giderek daha fazlasını yerel tarafa taşıyabilirsin. Aynı donanımda bile yerel kurulum 2 ay öncesine göre çok daha iyi; 6 ay öncesiyle kıyaslayınca ise dramatik biçimde ilerledi
  • gunapologist99: Occam’dan çok Pareto açısından düşünmek daha anlamlı olabilir
    Birkaç yıl içinde bunun o noktaya geleceğine gerçekten inanıyorsan, şimdiden kurcalamaya başlamak daha iyi; özellikle kısa ya da küçük projelerde ve iyi modülerleştirilmiş büyük projelerde oldukça şaşırabilirsin

• sosodev: Bu soru, yetenek ve beklenti aralığı açısından fazla geniş. Sadece 8B model çalıştırıp vibe coding ya da tek seferde çözüm beklersen zor.
  Yaklaşık 30B sınıfı bir model çalıştırabiliyorsan, kapsamı uygun ve iyi tanımlanmış işlerde oldukça iyi. Şu anda bu aralıkta Gemma4-31B ve Qwen3.6-27B en iyi görünenler
  Daha hızlı çıkarım istiyorsan MoE modellere geçebilirsin ama çoğu işte gözle görülür biçimde geriye düşüyorlar. Kapsamı küçük işlerde tek seferde çözüm ve vibe coding de mümkün, ama yine de yönlendirme olursa çok daha iyi oluyor
  Frontier düzeyi yetenek istiyorsan en az 128GB bellek ve büyük hesaplama gücü ya da bol sabır gerekiyor. Çoğu kişide ya para ya da sabır eksik. Yerel modellerde sabır, sadece token beklemek değil; kendi iş akışına ve donanımına göre ayarlayıp düzgün çalıştırmak için gereken emeği de kapsıyor

  • argee: M4 Pro, 48GB RAM MacBook üzerinde Gemma 4 26B A4B ile Rust çalışıyor ve çeşitli soruları yanıtlıyorum
    IDE ya da harness içinde çok ufak değişiklikler dışında tek seferde iyi iş çıkaracağına inanmıyorum. Yine de direksiyonda insan varsa, yola bakıyorsa ve hız sınırının altında gidiyorsa, küçük ve orta bağlamlı işler için copilot olarak hızlı ve yeterince iyi
    Birkaç yıl öncesiyle kıyaslayınca inanılmaz; bu olmasaydı muhtemelen yapay zekayla neredeyse hiç kod yazmazdım. İnternet bağlantısı kesildiğinde aptallaşmış ya da tıkanmış hissetmekten hoşlanmıyorum
  • user43928: Küçük bir modele, özellikle GPT 5.4 Mini'ye, 10~20 satırlık bir kod değişikliğini başka bir dosyaya taşımayı söyledim; ikinci denemede bile kodu değiştirip hata ekledi
    Kusursuz güvenilirlik beklemiyordum ama farkı gösterince en azından ikinci seferde doğru yapmasını beklerdim. Gerçekte ise kodun artık aynı olduğunu kendinden emin şekilde söyleyip bir de başka ince bir hata ekledi
    Bu kadar çöp seviyesinde modeller için hangi işlerin yeterince uygun olduğunu bilmiyorum. Birkaç dakika boyunca yetkinmiş gibi görünebilirler ama sonuç eninde sonunda yanlış çıkıyor. Olsa olsa daha akıllı arama ya da otomatik tamamlama için uygundur diye düşünüyorum

• mgsram: Yaklaşık 1 yıldır yerel LLM kullanıyorum ve artık Mac Studio 512GB RAM üzerinde Qwen3.6 27B yoğun GGUF, OpenCode, llmster(LM Studio) kombinasyonunda karar kıldım
  Qwen 3.6 35B-A3B'yi de denedim ama yoğun modelin doğruluğu bir seviye daha yüksek, karşılığında token/saniye feda ediyorsun. Qwen3.6 27B genelde 25~40tok/s veriyor
  Başta basit araçlar için kullanıyordum ama son 3~4 aydır C/C++ otomotiv yazılım yığını ve Python araçlarında prodüksiyon seviyesinde kodlama için gerçekten kullanıyorum. Düşük hız bile aslında uygun tempoda ilerlememi sağlıyor
  Yeni geliştirme ve yeniden yazımlarda Sonnet ile birlikte tasarım, mimari, akıl yürütme ve ayrıntılı uygulama planı çıkarıyorum; sonra bunu parçalara bölüp hassas prompt'larla veriyorum. Mevcut kod üzerinde çalışırken muhakeme gerekiyor ve yerel modelin sınırlarını hissedersem Claude Code'a dönüyorum
  Son dönemde Qwen 3.6 ile mevcut C++ kodunu referans alan C tabanlı bir güç yönetimi servisinin tamamını yeniden yazdım, karmaşık bir Excel spesifikasyon ayrıştırıcısı yaptım ve CJK içeriğini İngilizceye çevirip KG'ye koyan bir araç oluşturdum

  • russelg: 512GB varsa deepseek4 çalıştırmayı da değerlendirebilirsin: https://github.com/antirez/ds4

• 3abiton: Herkes Qwen'den söz etmiş, ben de Qwen 3.6 35B Q8(MTP) modelini Strix Halo ve llama.cpp ile çalıştırıyorum
  Yaklaşık 40~50t/s alıyorum ve performans gerçekten çok iyi. zsh içinde forge-code ile doğrudan kullandım; uzun bağlamda 150k üstüne çıkınca kalite düşüyor ve unutmaya başlıyor

• wsintra2022: Buradaki yorumları okuyunca, bunların yapay zeka sağlayıcıları adına yereli caydırmaya çalışan botlar mı, yoksa yerel yapay zeka modelleriyle gerçekten kötü deneyim yaşamış insanlar mı olduğunu ayırt etmek zor
  Mac Studio 64GB üzerinde Qwen 3.6 27B 8k quantization çalıştırmak frontier düzeyi her şeyi yapan bir süper güç değil; sadece iyi. Ücretsiz, özel ve usta bir mühendisi tembellikten daha fazla tembelliğe taşıması da sihirli tarafı
  llama.cpp ve opencode kullanıyorum; kod değişikliklerini planlayıp uygulatıyorum, sonra hamakta uzanıyorum, bulaşık yıkıyorum ya da başka bir şey yapıyorum. tmux ve ssh ile bağlanıp kontrol ediyorum. Asıl şaşırtıcı olan nokta bu

  • epolanski: Yazılım “mühendisliği” sektöründe çoğu zaman MIT Leetcode ninjaları React+Tailwind ile bellek sızdıran, kullanılamaz çöp yazıyor; yani taban seviye çok düşük

• garethsprice: Ada 4000 20GB VRAM üzerinde OpenCode + OhMyOpenCode + Qwen 3.6 35B-A3B Q_4_KM kullanıyorum ve üretim hızı yaklaşık 55tok/s
  OpenCode çok fazla bağlam eklediği için hissedilen hız rakamlardan daha düşük. Pi de çok anıldı, yakında ona da bakacağım
  Opus ile plan çıkarıp yerel ajanı ona uyduruyor, sonra yine Opus ile doğruluyorum. %100 yerel değil ama bu modeller giderek prodüksiyon iş akışının bir parçası oluyor
  Henüz hobi olarak zaman ve para harcayıp kurcalamayı sevmeyen biri için uğraşmaya değer olmayabilir. Opus ya da başka frontier modeller kadar iyi değiller ama tekrar eden işlerin arttığı aralıkta “yeterince iyi”ler
  Rolls Royce'un olmasa da ikinci el bir Corolla ile süpermarkete gidebilirsin. Frontier LLM'lerle maliyeti zorlayacak yeni iş akışları da mümkün hale geliyor. Gece boyunca Chrome devtools MCP ile kullanıcı gibi fuzz testi yaptırdım, hatta multimodal olarak ekran görüntülerini de kontrol ettirdim; Claude+ekran görüntüsü maliyetini düşününce şaşırtıcı
  “Frontier'ın 12~18 ay gerisinde” sözü doğru gibi görünüyor. 12~18 ay sonra 5 bin doların altında yerelde Opus seviyesinde bir model çalıştırmak mümkün olabilir, ama frontier modeller de o zamana kadar daha ileri gitmiş olur

• arjie: Yerel de değil, etkileşimli kodlama da değil ama iki adet RTX Pro 6000 Blackwell ile DeepSeek V4 Flash çalıştırıyorum
  Ham hız 160tok/s ama bu bir akıl yürütme modeli. Benim kullanımım otomatik kod yazımı ve diğer sistemlerin otomatik incelemesi. Pi ile ara sıra kod da yazdırıyorum; çok hızlı ama alışkanlıktan çoğunlukla CC ve Codex kullanmaya devam ediyorum

  • akersten: RTX Pro 6000 Blackwell'i nereden bulduğunu merak ediyorum
    Bulduğum sitelerin hepsi ya stok dışıydı ya sadece şirketlere satıyordu ya da şüpheli görünüyordu
  • leptons: Bu donanımın güç tüketimini ölçtün mü diye merak ediyorum. Aylık maliyetin ne olacağını önemsiyorum

• stymaar: Qwen3.6-35B-A3B modelini Strix Halo 128GB Bosgame M5 üzerinde çalıştırıyor
  Bu modele kıyasla VRAM fazlasıyla bol, ama Qwen donanımıma en uygun olacak 122B sürümü olan Qwen3.6’yı çıkarmadı. Bunun yerine elektrik faturası neredeyse göz ardı edilebilir düzeyde. Sonuçta bu aslında dizüstü çipi, boşta neredeyse hiç tüketmiyor; prompt işleme sırasında bile biraz 120W üstünde kalıyor
  Qwen3.6 beklenmedik şekilde etkili, bu yüzden Claude’u sadece ara sıra, toplam ihtiyacımın yaklaşık %10’u kadar kullanıyorum. En ucuz planda bile kotanın altında kalabiliyorum. Hız olarak prompt işleme yaklaşık 800tps, token üretimi 50tps ve speculative decoding kullanmıyorum

  • manmal: 27B dense sürümünü de denedin mi merak ettim. Kodlama için çok daha iyi

• Kostic: Kişisel kullanım için VSCode ile llama.cpp’yi bağlayıp Qwen 3.6 27B veya Gemma 4 31B çalıştırıyorum; bulut aboneliğini bırakacak kadar yeterli
  Qwen ilk GPU’da q4@176k context ile, MTP sayesinde 70~50tok/s civarında, yani kodlama için oldukça iyi. Gemma ise iki GPU’yu da kullanıyor ve q8@64k context ile belge duygu analizi, özetleme, düzeltme ve çeviriyi 25tok/s hızında yapıyor
  Toplu iş akışları için biraz yavaş ama yine de kullanılabilir. llama.cpp tensor split modunda MTP’yi desteklerse biraz daha artabilir gibi görünüyor
  İş yerinde maliyeti ben ödemediğim için hâlâ frontier LLM’ler kullanıyorum ve doğal olarak daha iyiler. Yaklaşık 1 yıl içinde Sonnet 4.6/Opus 4.5 seviyesinde 30B bir model çıkmasını umuyorum
  Prompt işleme 800t/s ile başlayıp 400t/s’ye düşüyor. Başlangıç prompt’um genelde 16k~24k token olduğu için işlenmesi 60~90 saniye sürüyor; harika değil ama kabul edilebilir

• jodoherty: RTX Pro 6000 Blackwell üzerinde Pi ile Gemma 4 31B çalıştırıyor ve tüm agent tabanlı kodlama işlerinde kullanıyor
  Faydalı buluyorum ve bu yan proje, işte projelerin kapsamını belirleyip ele alış biçimime benziyor: https://git.theodohertyfamily.com/wg-wrap.git/tree/README.md https://git.theodohertyfamily.com/wg-wrap.git/tree/CASE_STUD...
  Dikkatli mimari ve bolca TDD uygulamak gerekiyor. Zor kısımları başta çözerek bunları basit ve kullanımı kolay arayüzlerle sarıyor, böylece teknik riski ortadan kaldırıyor
  Bazı projelerde kendim yazmaya kıyasla 2~3 kat daha hızlı oluyor; sıkıcı ya da kapsamı geniş projelerde ise fikirleri hızla toplayıp denememe yardım ederek zamanı 5~10 kat azaltıyor
  Kurulumumda nvidia/Gemma-4-31B-IT-NVFP4 kullanan vLLM ve MTP’li unsloth/gemma-4-31B-it-qat-GGUF kullanan llama.cpp var. GPU gücünü 400W ile sınırlıyorum. Mevcut llama.cpp yapılandırması, MTP draft kabul oranına bağlı olarak 60~150t/s, prefill ise context uzunluğu ve derinliğine göre 1500~4000t/s veriyor

• jborak: Dört RTX 5070 ve 1. nesil AMD Threadripper 1950X ile llama.cpp üzerinde Qwen3.6 27B MTP Q6_K çalıştırıyorum ve Pi’yi günlük ana sürücü olarak gayet iyi kullanıyorum
  Hız yaklaşık 50~60tok/s. OpenWeb UI gibi başka uygulamaları da bağlıyorum; son zamanlarda model erişimi için varsayılan giriş noktası olarak LLM gateway Bifrost’u ayarladım
  Qwen3.6 35B A3B’yi de denedim ama kodlama için 27B daha uygun. Dense model olduğu için daha yavaş ama kalite çok daha iyi görünüyor. 35B A3B, MTP olmadan 130~140tok/s ile çılgınca hızlı
  Qwen3.6 27B çalıştırmak için dört 5070 şart değil; üç tane, hatta belki iki tane de yeterli olabilir. Ama 27B’yi hızlandırmak için MTP kullanırsanız draft model kendi context’ini istediğinden daha fazla bellek tüketiyor
  Araçların system prompt’unun da her konuşmada modele yüklendiğini akılda tutmak gerekiyor. Pi’yi açtığımda başlangıçta çok hızlı tepki veriyor ama Hermes CLI ile etkileşime girince her prompt skills, tools vb. yüzünden context’e çok şey yüklüyor ve bunlar konuşmanın sonuna kadar kaldığı için çok daha yavaşlıyor
  Gizlilik güzel ama kota olmaması ve kullanım miktarını dert etmemek de hoşuma gidiyor. Gelecek “loop engineering” ise bulut modellerinde token ve para yakarsınız. Sistemim boşta 200W, yüksek çıkarım yükünde 350~450W çekiyor; decoding çok verimli olmadığından GPU’lar düşündüğünüzden daha sık boşta kalıyor. Diffusion gibi gelişmeler decoding’i hızlandırıp boşta kalan GPU kullanımını artırabilir

  • zakisaad: 4 kartlık kurulumda neden özellikle 5070 seçtiğini merak ettim
    İlk bakışta hesaplama tarafına ağırlık verip VRAM’i zayıf bırakıyor gibi; oyuncular için iyi ama LLM çalıştırmak için çok uygun görünmüyor. Ben de masaüstümde 5070 kullanıyorum

• cuttysnark: Yerel modellerde, birden fazla agent’ı iş akışı içinde birbirine bağlayarak bir ölçüde başarı elde ettim
  Her agent, rolüne göre farklı prompt’lar ve farklı ollama modelleri kullanıyor. Proje yöneticisi ya da şema agent’ı (qwen3:14b), kodlama agent’ıyla (qwen2.5-coder:7b) aynı modeli kullanmıyor
  Her aşama arasında bir orkestratör ve Playwright görevleri var; amaç, bir önceki kod bloğunu üreten agent’a hataları görünür kılmak. Hatasız bloklar ancak ondan sonra bir sonraki aşamaya geçiyor
  En büyük iyileşme, backend-for-agents servis tanımını ekleyip şema agent’ının sadece görev tabanlı bir manifest oluşturup bunu sonraki agent’a aktarmasını sağlamak oldu. Kısacası, iş akışını tanımlayıp agent’ları yalnızca çok belirli işler yapacak şekilde bölüyor ve sonraki adıma devrediyorum. Böylece raydan çıkmıyorlar ve %25 ya da %90 başarıya ulaşmış akışlara insanın müdahil olacağı noktalar da oluşuyor

  • pianopatrick: Böyle iş akışı benchmark’ları ve yarışmalar olsa neyin iyi çalıştığını anlayabilirmişiz gibi geliyor
    Mesela “yalnızca bu tüketici GPU’sunu kullan, istediğin model ve iş akışını seç, sonra xyz benchmark’ını ne kadar iyi çözdüğüne bak” gibi. Katılımcılara en fazla 1 saat verilip yanıtlanan oran, doğruluk ve toplam süre puanlanan bir “The Local AI challenge” formatı güzel olurdu
  • sowbug: Agent’ları birbirine karşı yarıştırmayı denedin mi diye merak ediyorum
    Örneğin aynı kodlama görevini iki modele ya da aynı modelin farklı seed’lerine verip, sonra bir değerlendiricinin daha iyi sonucu seçmesi gibi. İnsan beyninin de durumu biraz farklı gören binlerce mini kortikal sütunun çoğunluk oylamasıyla çalıştığını savunan görüşler var

• HappySweeney: Optane ve bol RAM ile, yaklaşık 0.7t/s hızında neredeyse tam modele yakın bir modeli gece boyunca fonksiyon yazımı için kullanmayı denedim
  Şu anki test, bir Scala fonksiyonunu AVX512 kullanan bir bit matris transpozisyonu fonksiyonuyla değiştirmek. Bulut modeller bunu kolayca hallediyor ama Kimi 2.6 ve GLM 5.1 feci şekilde başarısız oluyor

• etoxin: Henüz yerini tutmuyor. İş projelerinde openspec kullanıyorum ve büyük para harcamadan yerel donanımı taklit etmek için en yeni popüler yerel modellerin barındırılan sürümlerine para ödüyorum
  Küçük yerel modellerin çoğu araç çağırma işini düzgün yapamıyor, ama daha büyük modeller artık bunu genelde doğru yapıyor. Yerel tarafta hâlâ yeterince hesaba katılmayan şey, üretken mühendislerin genelde git worktree ile birlikte aynı anda birden fazla CLI sohbeti çalıştırması. Ben genelde 3 worktree ve sohbeti açık tutuyorum

• blurbleblurble: Bence şu anki sınır modelin kendisinden çok, kuyruk yönetimi, kesme, alt ajanlar, hedefler gibi şeylerin garip şekilde eksik olduğu alternatif harness'ların kullanılabilirliği

  • coder543: Kesinlikle katılıyorum. OpenCode'un yerel LLM'leri gerçekten desteklemeye çalışmaması da sinir bozucu
    OpenCode'u çalıştırmak mümkün ama kurulum çok manuel ve kaba. llama-server ayarlarını OpenCode ayarına otomatik çeviren bir betik yazdım ve yardımcı oluyor ama ideal değil
    Boş zamanımda bir kodlama harness'ı daha yapmayı ciddi ciddi düşündüm. Daha iyi hale getirmek için birkaç fikrim var
  • horsawlarway: Pi fena değil
    Claude, Cursor, Pi'nin CLI ajanı, kendim yazdığım özel harness'lar ve gastown dahil hepsini kullandım; Pi gayet yeterli. Yapması gereken işi yapıyor, varsayılan araçları iyi, diğer araçlarla iyi entegre oluyor ve daha az uğraştırıyor
    Eğer 30B civarı modelleri makul hızda çalıştırabiliyorsanız, Pi ile birçok kişi epey şaşırır. https://pi.dev/packages/pi-mcp-adapter?name=mcp ve https://pi.dev/packages/pi-web-access?name=search gibi eklentilerle web araçları, perplexity araması, Chrome kontrolü için https://browsermcp.io/, Firefox için https://github.com/mozilla/firefox-devtools-mcp gibi MCP erişimi de kazanıyorsunuz
    Sübvansiyonlu en üst seviye modeller kadar iyi değil ama ücretsiz ve yine de yetenekli. Ben şahsen https://pi.dev/docs/latest/sdk ile de çok eğleniyorum; diğer sağlayıcılar bu tür API erişimi için ayda binlerce dolar istiyor
  • Insanity: pi.dev hakkında iyi şeyler duydum ama henüz denemedim. Bahsettiğiniz eksik özelliklerin bir kısmını çözebilir

• _bobm: Claude/GPT modeli derken o “model”in gerçekte ne olduğunu düşünmek gerekiyor
  GPT'nin düşünme kısmını nasıl parça parça gönderdiğini ve düşünce bloklarının kendisine Markdown başlık özetleri ekleyebildiğini düşünün. API uç noktasını ve çıktı davranışını gözlemlerseniz, sözde SOTA modeller göründükleri şey değil ve altyapı açısından yerel modellerle hiç karşılaştırılabilir değiller
  Bu ölçekte işletimin arkasında muazzam bir orkestrasyon var ve bunun kısıtları söylenmeyen yeniliklere yol açıyor. Bunun yakalanamayacağını düşünmüyorum ama llama ya da vLLM ile yerel model sunmak alfabenin A, B, C'si kadar temel bir seviye
  Bence asıl gereken, yukarıda ima edilen orkestrasyonun kopyalanması. SOTA “model” tek bir model değil, birlikte çalışan birçok modelin derin bir orkestrasyonu. Bu yüzden tek bir model, eğitimde ve mimaride bu orkestrasyonu kopyalayana kadar yetişemeyecek
  Genel tüketiciye sunulan bu orkestrasyon yapısındaki tek bir model bile muhtemelen Qwen 3.6'dan o kadar da üstün değildir. Bakış açısını değiştirince “büyü”nün ölçeği görünmeye başlıyor

  • XCSme: SOTA modellerin neden birçok modelin derin orkestrasyonu olduğunu düşündüğünü anlamıyorum
    GPT'nin düşünme kısmını Markdown başlık özetleriyle gönderdiği örneğini de daha somut görmek isterim

• cheekygeeky: Yazılım geliştiricimiz tanıdığım en zeki insanlardan biri ve açık kaynak modellerle birlikte OpenCode ve Tmux kullanıyor
  Kodlama için en çok DeepSeek'i tercih ediyor ve ona “oldukça iyi” diyor. i9, 128GB RAM ve iki adet 3090 üzerinde çalıştırıyor. https://www.msn.com/en-us/news/technology/china-s-open-deeps...

• pianopatrick: Bu tür iş akışları için benchmark ve yarışmalar olsa neyin iyi çalıştığını görebilirdik gibi geliyor
  Mesela “yalnızca şu tüketici GPU'sunu kullanarak, istediğin model ve iş akışıyla xyz benchmark'ını ne kadar iyi çözebiliyorsun” gibi. Katılımcılara en fazla 1 saat verildiği ve yanıt oranı, doğruluk ve tamamlama süresine göre puanlanan “The Local AI challenge” tarzı bir yarışma görmek isterim

• bravetraveler: Neredeyse tamamen “doğal beslenme” gibi kullanıyorum ve az miktardaki LLM kullanımımın tamamı da yerel
  128GB Strix sistemde daha seyrek Qwen veya Gemma varyantları 50~80tok/s çıktı veriyor. Anthropic/OpenAI vb. abonelik düşünmüyorum; bu son yerel modelim olsa bile ihtiyaç duymam. Model içi araç kullanımı güncellik endişesini kapatıyor

• GodelNumbering: Gün boyu LLM'lerle konuşan biri olarak, açık kaynak frontier modeller + iyi bir harness kombinasyonunun şimdiden yeterli olduğunu düşünüyorum
  Yerel dağıtıma tamamen geçmek için bir ya da iki donanım nesli daha lazım. Yine de donanım şirketleri veri merkezi tarafına güçlü öncelik verdiği için o gün beklenenden daha geç gelebilir

• milchek: 36GB MacBook Pro’da denedim ama çok temel işleri aşınca büyük bir başarı elde edemedim
  Küçük modeller kullansam bile bağlam çabuk tükeniyordu ve yavaşlık sorun oluyordu. Bir noktada düzgün performans almak için 128GB bellek gerekiyor gibi görünüyor ve donanım maliyeti ciddi biçimde artıyor
  Sonuçta mesele, frontier modellere abonelik mi kullanacaksın yoksa o parayı ekipmana mı gömeceksin sorusuna dönüyor. Tabii gizlilik önemliyse üst düzey donanıma para harcamaktan başka pek seçenek yok

• acc_297: Orta ölçekli modellere her promptta RLHF’yi rutin olarak uygulayıp kişisel kullanım alışkanlıklarına göre ince ayar yapmanın faydalı olup olmayacağını merak ediyorum
  Modeli elle ince ayar yapmanın işi bozup bozmayacağını ya da iyileştirip iyileştirmeyeceğini bilmiyorum. Dürüst biçimde geri bildirim verirsem aşırı yağcılık, laf kalabalığı, benzetmelerle açıklamaya çalışma gibi genel amaçlı modellerin sinir bozucu tiklerini azaltmak güzel olurdu ama tek bir kişinin prompt geri bildiriminin yeterli olup olmayacağından emin değilim
  İç dokümanlarla ince ayar yapılmış şirket içi ajanların da garip davrandığını ve standart modellerden mutlaka daha kullanışlı olmadığını duydum. Ajanın bütün yanıtlarını düzenleyebilsem ve özgün sürümle düzenlenmiş sürüm arasındaki farkla ince ayar yapabilsem iyi olurdu
  Kişisel olarak çok sayıda sıfatı çıkarıp yanıtı özüne indirgerdim ama Owain Evans gibi hizalama araştırmacılarının çalışmalarına bakınca böyle ayarların modeli öngörülemez eğilimlere itmesinden endişe ediyorum

  • htrp: Cursor bunu yapıyor. Muhtemelen sağlayıcı olarak Fireworks kullanıyor: https://cursor.com/blog/real-time-rl-for-composer
  • rolisz: Benzer bir şeyi OpenClaw ajanında denemek isterdim
    Owain Evans’ın çalışması galiba SFT idi. Twitter’da birileri RL’nin onun gösterdiği olguya daha az hassas olduğunu söylüyordu, o yüzden kendim denemek istiyorum

• heisenbit: Kurulum işi gerekiyor ama bu süreçte çok şey öğreniyorum
  48GB M4 MBP’de çoğunlukla qwen/qwen3.6-35b-a3b mlx kullanıyorum; Docker dev-container ve temel işler için ancak biraz boş alan kalıyor. LM Studio ile çalıştırıp VSCode’da kullanıyorum
  Sistem promptunu değiştirip araç entegrasyonunu iyileştirmek büyük fark yarattı. Önceden değişiklikleri uygulamak yerine kodu yeniden üretmeye çalışıyor, yardımcı olmaktan çok bozuyordu
  Gürültü ve ısıdan kaçınmak için çoğu zaman prize takılıyken bile düşük güç modunda kullanıyorum. En yüksek performansta hız yaklaşık iki katına çıkıyor ama güç tüketimi iki kattan fazla artıyor
  Yapabildiği şeyler daha çok bir sayfanın basit yeniden düzenlemesi düzeyindeydi; Pinia store’u ayırma işinde başarısız oldu. GPT-5.4 ise bu işi sorunsuz yaptı. Araç kullanım rehberini ve çevredeki destek araçlarını biraz daha ayarlarsam performansın artabileceğini düşünüyorum

• nfrankel: Denedim ve teoride çalışıyor: https://blog.frankel.ch/tokensparsamkeit-coding-assistants/#...
  Sonuçlar modele göre değişiyor ve nihayetinde sınır bilgisayarın kendisi oluyor. Benim makinem ne yazık ki bunun altından kalkamadı

• K0balt: qwen 3.6 27b dense ile oldukça iyi sonuçlar alıyorum
  İşe göre Claude Haiku 4.5’e benziyor, hatta bazen Sonnet seviyesine yaklaşıyor olabilir

  • kadoban: Bu işi hangi araçla yürüttüğünü merak ediyorum
  • kandros: Kodlama işleri için Haiku’ya sormaktansa kasaba sorarım

• jderekw: Günlük cihaz olarak AMD Lemonade kullanıyorum
  Ollama ile başlayıp LMStudio’ya geçtim, şimdi ise cRAM, CPU, GPU ve gRAM izleme konusunda yardımcı olduğu için AMD Lemonade üzerinde standartlaştım. Lemonade’in çoklu model özelliği sayesinde LLM, speech-to-text, NPU ve görüntü üretim yığınını kolayca çalıştırabiliyorum
  Platform Nvidia, Apple, Intel ve AMD yonga setlerinde de çalışıyor

• redox99: Evde çalıştırılabilen Qwen 35B gibi modeller Opus veya GPT 5.5’e hiç yaklaşmıyor
  Buna yakın açık modeller yaklaşık 1T parametre civarında, yani evde çalıştırmayı unutmak lazım. Eski döküntü bir arabayı kullanmaya benziyor; seni A noktasından B noktasına götürdüğü için bunun yeterli ve iyi olduğunu savunanlar çıkabilir ama değil
  Gizliliğe mutlak ihtiyaç duymuyorsan, eğlencesine yapmıyorsan ya da uçak gibi özel bir durumda değilsen mantıklı bir gerekçe yok. Codex için ağır sübvanse edilmiş 20 doları bile veremiyorsan, Çin modellerinin API’larını kullanmak bu küçük modelleri ezer geçer

  • pbasista: “Qwen 35B gibi evde çalıştırılabilen modellerin Opus veya GPT 5.5’e hiç yaklaşmadığı” değerlendirmesinin hangi nesnel olguya veya benchmark’a dayandığını merak ediyorum
  • xgulfie: İşe gitmek için Ferrari gerekmez

• sj_tech: Mac Mini 128GB üzerinde GitHub Copilot Extension for VSCode ile Qwen 3.6 35B A3B’yi ajan tabanlı kodlama için kullanıyorum
  Model boyutuna göre fena değil ama sorun çok büyüyünce döngüye girdiğini görüyorum. Zaten bildiğin şeyleri yaptırıp zaman kazanmak için iyi

• julianlam: Framework 13, 32GB bellek üzerinde Qwen 3.6 35B-A3B’yi llama.cpp ile çalıştırıyorum ve 15tok/s alıyorum
  Kod ve metni benim okuma hızımdan daha hızlı üretiyor

• moezd: Henüz değil. Saf Apple başarımı ya da iyi bir GPU yoksa, çok RAM ve thread olsa bile alacağın şey 30~50tok/s civarı ve bu da thinking kapalıyken
  Bu tür optimizasyonlar olmazsa model MCP, skills ve ajan açıklamalarını rahat rahat tüketiyor; ilk çıktı tokenını görmeden önce boyanın kurumasını izliyorsun
  Yerel model servisinde bağlam penceresindeki her tokenı idareli kullanmak gerekiyor; bu da Claude/GPT/Copilot’ın sektörü ittiği yönün tam tersi

  • amarshall: thinking çıktı hızını değiştirmez. Anthropic modellerinde medyan çıktı hızı kabaca 40~60t/s civarında

• mitchell_h: Denedim ama bağlam penceresi yeterince büyük değildi

  • coder543: Qwen3.6-27B, 1 milyon token bağlam penceresini destekliyor
    Tabii böyle bir bağlam penceresini çalıştırabilecek donanım gerekiyor ve benim DGX Spark’ta q4_k_xl modelini tam f16 KV cache ile kullanınca yaklaşık 100GB bellek gerekiyor
  • lysace: Ben de benzer sonuç aldım. RTX 4070’imde yalnızca 12GB var; 24/32GB’ın gerçekten anlamlı derecede iyileştirip iyileştirmediğini merak ediyorum
  • deadbabe: Bunu açık uçlu bir soru gibi sormak yerine daha doğrudan promptlayabilirsin

• drnick1: Üst seviye tüketici GPU'larında çalıştırılabilecek mevcut en iyi kodlama modelinin ne olduğunu merak ediyorum.
  RTX 3090/4090 olduğunu varsayarsak hangi stack'i önerirsiniz, onu da merak ediyorum. Llama.cpp + OpenCode gibi bir kombinasyon mu, öğrenmek istiyorum

• bijowo1676: Uygulamanın spesifikasyonları, ürün gereksinimleri, mimari gibi Markdown belgelerini pahalı frontier modellerle yazıp güncelledikten sonra, bu spesifikasyonları daha ucuz ya da yerel modellerle uygulatma kurgusu ilginç gelmişti.
  Markdown, yüzlerce kaynak dosyaya kıyasla bilgiyi daha iyi sıkıştırıp bağlam penceresine daha iyi sığıyor; ancak pürüzlü kısımları düzeltmek için ikinci ve üçüncü geçişler gerekiyor. Bunu bu şekilde deneyen biri olup olmadığını merak ediyorum

• grmnygrmny2: OpenAI veya Anthropic ürünlerini kullanmaya yönelik etik çekincelerim olduğu için LLM benimseme fikrine de baştan mesafeli durmuştum.
  Yerel modeller, ahlaki itirazlarımın büyük kısmını giderdi; bu yüzden yaklaşık bir aydır işte ve kişisel projelerde kullanıyorum. Elimdeki donanım 32GB Mac'ler ve 10GB 3080 oyun PC'si olduğu için çeşitli kuantizasyonlarda Qwen3.6-35B-A3B civarı üst sınırım, ama yeterli oluyor.
  Yaklaşık 200~400 PP ve 20~30 TG alıyorum; ayrıca bunu iyi kullanmayı öğrenmek biraz zaman aldı. Bazı işlerde göz kulak olmanız ya da yön vermeniz gerekiyor ama yine de oldukça faydalı.
  CC'yi hiç kullanmadım, bu yüzden kıyaslayamam; ama embedded C++'tan Vue'ya kadar iyi bir yardımcı ya da pair programmer gibi davranıyor. 27B çalıştırabilsem güzel olurdu; bazen bu model bir şeyi neredeyse anlayacakmış gibi olup yapamadığı anlar oluyor, ama bunlar nadir.
  Birçok görevde ciddi zaman kazandırıyor ve oldukça muğlak talimatlarla bile bug'ların içine girip düzeltme konusunda iyiydi. Harness olarak Pi kullanıyorum.