GLM 5.2 ve Opus

 (techstackups.com)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Aynı tek seferlik prompt ile ham WebGL tabanlı 3D platform oyunu üretmeleri istendiğinde, Opus daha hızlı ve daha yüksek tamamlanmışlık düzeyinde sonuç verdi; GLM-5.2 ise düşük maliyet ve açık ağırlık avantajı sundu
  • GLM-5.2, Z.ai’nin MIT lisanslı açık ağırlık modeli; 1M token bağlamı ve High/Max düşünme düzeyleri sunuyor, ancak yalnızca metin tabanlı olduğu için görsel temelli öz-doğrulamada sınırlı kalıyor
  • Gerçek test maliyeti GLM-5.2 için $5.39, Opus için yaklaşık $21.92 oldu; derleme süresi ise sırasıyla 1 saat 10 dakika 40 saniye ve 33 dakika 30 saniyeydi, yani hız ve maliyet arasında bir tercih ortaya çıkıyor
  • GLM-5.2 çıktısında eksik dokular, çalışmayan dikenler, zafer koşulunun olmaması ve kalan debug overlay gibi temel sorunlar vardı; Opus daha temizdi ama havadaki ince platform kenarı çarpışması ve uzaktan tetiklenen zafer koşulu gibi sorunlar yine de kaldı
  • Benchmark’larda ve dış değerlendirmelerde GLM-5.2 güçlü bir açık ağırlık modeli olarak görülüyor, ancak birçok kodlama ve ajan görevinde Opus önde; seçimde maliyet, açıklık ve görsel değerlendirme belirleyici oluyor

Aynı görevde ortaya çıkan fark

  • GLM-5.2, açık modellerin potansiyelini gösteren yeni bir örnek olsa da, aynı gerçek görevde Claude Opus 4.8 daha hızlı ve daha doğru sonuç üretti
  • Testte iki modele de aynı tek seferlik prompt verildi ve oyun motoru ya da Three.js gibi 3D render kütüphaneleri olmadan, tarayıcı için 3D platform oyununu ham WebGL ile sıfırdan oluşturmaları istendi
  • Her iki çıktı ve kaynak kod da açık durumda
  • Her iki oyun da ücretsiz CC0 varlık paketi Kenney Platformer Kit'i kullanıyor

GLM-5.2’nin yapısı ve yaklaşımı

  • GLM-5.2, Z.ai’nin en yeni amiral gemisi modeli ve MIT lisanslı açık ağırlık olarak sunuluyor
    • İndirip doğrudan çalıştırmak veya Z.ai API üzerinden çağırmak mümkün
    • Ağırlıklar Hugging Face ve ModelScope üzerinde yayımlanmış durumda ve bölgesel kısıtlama yok
    • vLLM, SGLang, Transformers gibi framework’lerle yerelde servis edilebiliyor
  • Model, uzun süreli çok adımlı kodlama ajanı işleri gibi long-horizon görevleri hedefliyor
    • 1M token bağlam penceresi sunuyor
    • High ve Max düşünme düzeyleri var; testte High kullanıldı
  • Belirleyici sınırlama ise yalnızca metin tabanlı olması
    • GLM-5.2 görüntü okuyamıyor
    • Ekran görüntüsü ya da diyagramların doğrudan incelenmesini gerektiren akışlarda Claude Opus gibi multimodal bir model gerekiyor

Fiyatlandırma ve çalışma maliyeti

  • Üretici dokümanlarına göre 1M token başına fiyat GLM-5.2’de Opus’tan daha düşük
    • Claude Opus 4.8: giriş $5, cache okuma $0.50, çıkış $25
    • GLM-5.2: giriş $1.4, cache okuma $0.26, çıkış $4.4
  • Çıkış tokenı bazında GLM-5.2’nin fiyatı Opus’un beşte birinden daha az
  • Gerçek oyun üretim testinde ise zaman ve maliyet farklı yönlere ayrıldı
Metrik GLM-5.2 (Pi/OpenRouter) Opus (Claude Code)
Duvar saati bazlı derleme süresi 1 saat 10 dakika 40 saniye 33 dakika 30 saniye
Çıkış tokenı 131,000 216,809
En yüksek bağlam kullanımı 1M’in %16’sı 1M’in %19’u
Araç çağrısı 128 153
Maliyet $5.39 gerçek fatura yaklaşık $21.92 tahmin
  • Opus işi yaklaşık yarı sürede bitirdi, GLM-5.2 ise çok daha düşük maliyetle tamamladı

Test görevi: ham WebGL 3D platform oyunu

  • Görev, basit bir landing page üretmekten daha karmaşıktı
    • GLB model ayrıştırıcısı
    • matris ve vektör matematiği
    • GLSL shader’ları
    • skinning destekli iskelet animasyonu
    • sabit zaman adımlı döngü
    • çarpışma işleme
    • takip kamerası
  • İki model de aynı prompt’u, aynı varlıkları ve ipucusuz tek bir denemeyi aldı
  • Tamamlama koşulları şunlardı
    • ham WebGL tabanlı 3D motor ve render sistemi
    • sağlanan 3D karakter ve dünya modelleri için loader
    • yerçekimi ve çarpışma içeren karakter hareketi ve zıplama
    • takip kamerası ve klavye kontrolü
    • tek komutla tarayıcıda çalıştırılabilen tam oyun
  • Her iki model de GLB ikili ayrıştırıcısı, matris/quaternion matematiği, WebGL2 render’ı, GLSL skinning shader’ı ve alt adımlı AABB çarpışmasını önemli ölçüde doğrudan uyguladı
  • Derleme kayıtları da açık durumda

Oynanış sonuçları ve kalan hatalar

  • Her iki oyun da üçüncü şahıs bakış açısına sahip 3D platform oyunu formuna ulaştı
    • WASD veya yön tuşlarıyla hareket
    • Space ile zıplama
    • Shift ile koşma
    • fare sürükleme ile kamera döndürme
    • tekerlek ile yakınlaştırma/uzaklaştırma
    • para toplama, dikenlerden kaçınma ve bayrağa ulaşma hedefi
    • haritanın dışına düşüldüğünde başlangıç noktasına dönme

  • GLM-5.2 sonucu

    • GLM-5.2’nin oyunu genel olarak kaba bir tamamlanmışlık sergiledi
    • Karakterin bazı materyalleri eksikti ve karakter yürürken hareket yönünün tersine dönüyordu
    • Diken tuzakları karakteri öldürmüyor ya da sıfırlamıyordu; bayrağa ulaşıldığında da zafer koşulu tetiklenmiyordu
    • Kamera hareket ettiğinde kafa kayboluyor, ayrıca debug overlay ekranda kalıyordu
    • Yayımsı yüzeye basınca karakterin bir sonraki platforma sıçraması ise iyi çalışıyordu
    • Kenney modelleri ayrı bir dosyadaki ortak renk paletine referans veriyor, ancak GLM-5.2’nin render sistemi bu dosyayı yüklemediği için düz renkler kullanıldı

  • Opus sonucu

    • Opus’un oyunu daha temizdi ve daha iyi çalışıyordu
    • Kamera ve kontrol sistemi işliyordu, dikenlerin oyuncuyu öldürme mantığı da çalışıyordu
    • Dokular doğru uygulanmıştı, animasyonlar akıcıydı ve bayrağa ulaşınca kazanmak mümkündü
    • Kalan hatalar temel işlevlerden çok kenar durumlarına yakındı
    • Karakter platformun yanındaki havada kısa süre durabiliyordu; bunun nedeni, kenardan ayrıldıktan hemen sonra da zıplamaya izin veren coyote-time toleransının fazla yüksek ayarlanmış olmasıydı
    • Bayraktan hâlâ oldukça uzakken bile zafer koşulu tetiklenebiliyordu

Öz-doğrulamada fark yaratan multimodal ayrım

  • Her iki modele de işi bitirmeden önce sonucu doğrulama talimatı verildi
  • Opus multimodal bir model olduğu için oyunu render ettikten sonra alınan ekran görüntülerini doğrudan inceledi
    • Ekranda kalan debug işaretlerini görüp kaldırdıktan sonra işi tamamladı
    • Son sahnede bloklar, merdivenler, paralar, mücevherler, dikenler, bayrak, karakter, skor HUD’u, ışıklandırma ve geometriyi kontrol etti
  • GLM-5.2 görüntü okuyamadığı için ekran görüntülerini doğrudan göremedi
    • Bunun yerine ham piksel verisini okuyup renklerin beklenen değerlere kabaca uyup uymadığını kontrol eden dolaylı bir yöntem kullandı
    • Kaydedilmiş görüntüde grass green, dirt brown, coin gold, flag red, character bluish, half-Lambert lit, no black gibi renk koşullarını kontrol etti
  • Bu yöntem gerçek ekrandaki sorunları kaçırdı
    • Karakter gri görünüyordu ve dokular eksikti
    • Debug overlay hâlâ ekranın üzerinde duruyordu
  • Görsel çıktının önemli olduğu işlerde, görüntüyü anlayabilen multimodal doğrulama gerçek kalite farkına dönüşüyor

Benchmark’larda görülen konum

  • Z.ai’nin model kartı benchmark’larında GLM-5.2, en üst kapalı modellerin hemen arkasında yer aldığı birçok ölçümde göründü; bazı akıl yürütme benchmark’larında ise öne geçti
  • Başlıca sayılar şöyle
    • HLE: GLM-5.2 40.5, Opus 4.8 49.8
    • HLE with tools: GLM-5.2 54.7, Opus 4.8 57.9
    • AIME 2026: GLM-5.2 99.2, Opus 4.8 95.7
    • IMOAnswerBench: GLM-5.2 91.0, Opus 4.8 83.5
    • SWE-bench Pro: GLM-5.2 62.1, Opus 4.8 69.2
    • NL2Repo: GLM-5.2 48.9, Opus 4.8 69.7
    • ProgramBench: GLM-5.2 63.7, Opus 4.8 71.9
    • SWE-Marathon: GLM-5.2 13.0, Opus 4.8 26.0
    • MCP-Atlas public: GLM-5.2 76.8, Opus 4.8 77.8
    • Tool-Decathlon: GLM-5.2 48.2, Opus 4.8 59.9
  • ArtificialAnalysis’in bağımsız çalıştırma sonuçları da GLM-5.2’yi güçlü bir açık ağırlık modeli olarak değerlendiriyor
    • Intelligence Index v4.1 puanı 51
    • MiniMax-M3 44, DeepSeek V4 Pro 44, Kimi K2.6 43’ten daha yüksek
    • TerminalBench v2.1 skoru %78; bu, model kartındaki 81 veya 82.7’den farklı bir harness kullanıyor
    • Görev başına çıkış tokenı yaklaşık 43k ve bu, GLM-5.1’in 26k seviyesinden daha yüksek
  • Benchmark eğilimi gerçek testle benzer
    • GLM-5.2, açık ağırlık modeller arasında ön sıralarda ve akıl yürütmede bazı alanlarda rekabetçi
    • Opus, birçok kodlama ve ajan benchmark’ında önde

Dış tepkiler

  • Simon Willison, GLM-5.2’yi “muhtemelen en güçlü yalnızca metin tabanlı açık ağırlık LLM” olarak değerlendirdi
    • Onun SVG testinde GLM-5.2, bisiklete binen bir pelikanı tamamen animasyonlu biçimde üretti ve kırık bir kısmı yoktu
    • Scooter kullanan opossum testi ise önceki GLM-5.1’den daha kötüydü; yani performans tamamen tutarlı değil
  • Artificial Analysis, GLM-5.2’yi kendi Intelligence Index’inde lider açık ağırlık modeli olarak değerlendiriyor
    • Aynı seviyedeki en ucuz model olduğunu ve maliyet/zeka sınırında yer aldığını düşünüyor
    • Ancak görev başına yaklaşık 43k çıkış tokenı kullanan, token tüketimi yüksek bir model olarak da işaretliyor
  • Nathan Lambert, LMArena lider tablosuna göre GLM-5.2’nin Gemini’den daha iyi bir ajan olarak görülebileceğini söyledi ve MIT lisanslı açık model olarak bunu “serious accomplishment” diye niteledi
    • En üst ABD modelleri genel olarak hâlâ önde, ancak Çinli araştırma laboratuvarlarının daha az hesaplama ile yüksek skorlara ulaştığını vurguladı

Hangi modeli seçmeli?

  • GLM-5.2, Opus fiyatının bir kısmına güçlü performans sunan bir açık ağırlık modeli
    • Maliyet ve açıklığın önemli olduğu, işin ağırlıklı olarak metin ve mantık odaklı olduğu durumlara uygun
    • İndirilebilir ağırlıklar, kapalı modeller gibi aniden emekliye ayrılıp kısıtlanamaz
  • Opus testte daha hızlı, daha temiz ve daha doğru sonuç verdi
    • Görsel çıktıları doğrudan görüp doğrulayabiliyor
    • Doğruluk, polish ve görsel muhakemenin önemli olduğu ve maliyetin karşılanabildiği işler için daha uygun
  • GLM-5.2, Opus’un yerine geçecek ana modelden çok; ucuz, her zaman erişilebilir ve güçlü bir yardımcı modele daha yakın

İlgili okumalar

1 yorum

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

  • Tek seferlik promptlama neden bu kadar büyük olay oluyor gerçekten anlamıyorum
    Tanım gereği tek bir prompt, bir yazılım projesinin karmaşıklığını taşıyamaz. Sonuçta model, eğitim külliyatındaki mevcut koda dayanarak çeşitli varsayımlar yapıp bir sonuç üretiyor
    Ben daha çok, insan tarafından gözden geçirilmiş bir spesifikasyonun korkuluklarına ve kodlama teamüllerine uyarak plan dosyasının adımlarını tam olarak izleyen bir kodlama ajanı görmek isterim. Ayrıca, insanın belirlediği hedef için ajan döngüsünün korkulukların dışına çıkmadan ve savrulmadan hedef tamamlanana kadar ilerleyip ilerlemediğinin de doğrulanması gerekir
    Ayrıca, oluşturulmak istenen kullanım senaryosunun bağlamını kavrayıp mevcut kodda hata ya da performans iyileştirme fırsatlarını bulma ve refaktör önerme yeteneği çok daha değerli bir ölçüttür

    • Bu deney, modelin biraz belirsiz ve açık uçlu bir spesifikasyonla bile öznel olarak iyi değerlendirilecek bir sonuç üretip üretemeyeceğini görmek açısından ilginç
      Bu, çıktının girdiye uyup uymadığına bakan bir benchmark'tan çok, çıktının kendi içinde tutarlı olup olmadığına bakmaya daha yakın. Oyun örneğinde, hedefe ulaşıldığında bitip bitmediğine, dikenlere değince ölüp ölmediğine ya da hareket ederken garip sınır durumları oluşup oluşmadığına bakmak gibi
      Yine de aynı çalışma ortamını kullanıp deneyi birkaç kez tekrarlayarak sonuçların varyansına da bakmak gerekirdi diye düşünüyorum
    • Sorun tek seferlik olmasında değil, boş bir projeden başlayan greenfield durumunda
      Eskiden bir framework'ün README'sini izleyip boş bir projede test ettikten sonra “bu framework bizim 10 yıllık production uygulamamız için en iyisi” diyen mühendislerle dalga geçerdim. Greenfield tarzı düşünme, tüm sorunların çözümü olduğu kadar tüm çözümlerin de sorunudur
      Tek seferlik yetenek de önemli bir öz ölçüm metriği, o yüzden ölçülmeli; ama yerleşmiş bir büyük ölçekli kod tabanı üzerinde ölçülmeli
    • Şu anda hiç kimse ciddi işleri tek seferde yaptırmaya çalışmıyor ama yine de önemli bir gösterge
      Claude Code ve Opus'un büyük ilgi görmesinin nedeni, yürütme ortamının gelişmesi sayesinde kullanıcı girdisi olmadan da birçok hatayı kendi kendilerine düzeltebilir hale gelmeleri. Uzun vadede en büyük ilerleme muhtemelen saatler ölçeğinde özerklik ve öz-düzeltme yeteneğinde olacak
    • Tek seferlik yaklaşım test edilmeye değer, ama ancak “bunu bu spesifikasyona göre yap” gibi çok büyük promptlar olduğunda anlamlı
      Birkaç giriş token'ıyla milyonlarca token üretmenin çok anlam aktardığını düşünmüyorum
    • Model, giderek karmaşıklaşan talimatlar alıp insan müdahalesi olmadan gereksinimleri karşılayabiliyorsa genel performansını değerlendirmek oldukça kolay olur
      Daha iyi modelleri değerlendirmek için işe daha fazla gereksinim eklersiniz. Gerçekçi bir kullanım senaryosu olmasa bile yararlı bir yöntem olduğunu düşünüyorum
      Elbette bir yazılım mühendisi yönlendirirse model çok daha iyi sonuçlar üretebilir. Mühendise göre daha kötü de olabilir

  • “Aynı tek seferlik promptla Claude Opus 4.8'i kafa kafaya yarıştırdım: saf WebGL ile sıfırdan 3D platform oyunu yapmak” tarzı tek bir seferlik çalıştırma benchmark değildir ve gerçek kullanımı da temsil etmez
    Ajan kullanımının çoğu işbirlikçidir; bu yüzden bir görevi verdiğinizde test sonuçlarını uydurmadan tamamlayıp tamamlamadığı gibi güvenilirliği ve talimatlarınızı mı izlediği yoksa kendi bildiğini mi yaptığı gibi yönlendirilebilirliği test etmek gerekir

    • Yazarıyım ve tamamen katılıyorum. Bu kez bir benchmark olarak değil, bir vibe test olarak yaptım; gerçek benchmark'ları ise ayrıca listeledim
      Bu test, her iki modele de uzun süren ve teknik olarak zor bir tek seferlik görev verdiğinizde neler yapabildiklerini gösteriyor
      İşbirliği, görev devri, tamamlama, test güdümlü geliştirme ve yönlendirilebilirliği inceleyen formatların gelecekte kesinlikle denenmeye değer iyi testler olduğunu düşünüyorum
    • Tersine, az önce Raspberry Pi ajanına GPT 5.5 bağlayıp açıkça tanımlanmış uzun soluklu bir görevi gece boyunca çalıştırdım; yaklaşık 10 saattir çalışıyor ve neredeyse bitmek üzere. Böyle kullanım senaryoları da geçerli
      Düşününce, benim yaptığım ajan işlerinin çoğu, ana oturum içinde kendi promptlarıyla çalışan alt ajanlardan oluşuyor. Bunlar da tam özerk çalışmanın kısa birer versiyonu sayılabilir
    • Bu yüzden resmi benchmark'ları, yan yana uzun analizleri ve güvendiğiniz birden fazla kişinin değerlendirmelerini birlikte görmek gerekir
      Yazıda da bunlardan söz ettim; bunu kendi başına resmi bir benchmark olarak tasarlamadım. Resmi benchmark zaten yeterince var

  • Anthropic sürekli 529 Overloaded döndürdüğü için dün GLM 5.2'ye kaydolup denedim
    Hoşuma gitti ama GLM 5.2'nin xhigh ayarında, tek bir oturumda sadece 2 promptla 5 saatlik sıfırlama penceresindeki light plan kullanımımın %22'sini yedi
    Sonuçtan memnun kaldım ve kalite de iyiydi. İkisini de kullanmak istiyorum; keşke Anthropic ve GLM'i birlikte kullanabileceğim birleşik bir abonelik planı olsa

  • Birkaç projede GLM 5.2 kullanınca edindiğim izlenim, kod yazmaya başlamasının epey zaman aldığı ve asla hızlı bir model olmadığı yönünde
    Keşif ve planlama aşamasında sık sık yoldan çıkıyor ama sonra toparlıyor; yönlendirmesi de kolay değil, çünkü sonradan uymayacağı şeyleri halüsinasyon olarak üretiyor. Yine de çıktı kalitesi oldukça iyi
    Örneğin Swift+Zig kod tabanında render'ı optimize ettim ama 5 bin veri öğesinde takılı kaldım. GLM 5.2, benchmark oluşturup veri çıkarmak için 20 dakika harcadı; ben de sinirlenip düzenleme dışındaki araç erişimini kapatıp başından ayrıldım. Yaklaşık 30 dakika sonra döndüğümde, önceden hazırladığı benchmark ve birkaç “sonuç” temelinde üç darboğazı optimize etmişti; ayrıca şüphelerini doğrulayamadığı için daha fazla veriye ihtiyaç olduğunu da söylemişti
    Uygulama iyi çalışıyordu, deyim yerindeyse idiomatiktı ve müdahaleci değildi. Hatta aynı depoda GPT 5.5'in ürettiği sonuçtan daha idiomatik olduğunu bile söyleyebilirim. Daha çok kullanmak isterdim ama GPT genelde aynı isteği 5 kat daha hızlı bitiriyor
    GLM 5.2 sayesinde izole konteynerler ve JJ workspace içinde birden fazlasını paralel çalıştıran bir kurulum hazırlamaya başladım

    • Kısa süre önce önemi düşük bir işte kullandım; diğer modeller çözemiyordu ve Opus 4.8 harcamak istemedim
      Sorun, macOS menü çubuğunda sol tıklamayı yakalamak ve Ctrl+tıklama ya da sağ tıklamanın, belirli koşullarda normal sol tıklama gibi menüyü açmasını sağlamaktı
      Sorun çözme oturumunun ortasında modeli GLM-5.2'ye çevirdim; promptu yeniden bile vermedim, akıl yürütmenin ortasında değiştirdim ve birkaç dakika sonra sorun çözülmüştü. Bunu OpenCode Go'nun abonelik tabanlı kotasıyla kullandım; bu tür bir sorun Opus kullanımını mevcut 5 saatlik pencerenin hatta haftalık sınırın tamamını bile tüketebilirdi
    • Tüm çıkarım izini görebilmek de güzel
      Modelin raydan çıktığını ya da benim söylemediğim bir şeyi keşfettiğini görünce durdurup düzeltebiliyorsunuz. Ya da neden o seçimi yaptığını öğrenebildiğiniz için sonradan kafanızda daha az soru kalıyor

  • Benim deneyimime de benziyor. Pi'de kullanıyorum; akıllı ve çıktısı da iyi ama oraya giden süreç verimli değil

    • Fiyat da sorun. Denemek istemiştim ama Opus'tan yalnızca %30 daha ucuzsa, bu sorunlar varken onu seçeceğimi sanmıyorum

  • “GLM-5.2 görüntü okuyamadığı için sorun burada çıktı. Çünkü multimodal değil. Bu yüzden ekran görüntüsüne bakmak yerine ham piksel verisini okuyup renklerin kabaca beklendiği gibi çıkıp çıkmadığını kontrol eden bir script yazma hilesine başvurdum” deniyor; ama daha iyi yöntem https://github.com/openbmb/MiniCPM-V kullanmak

    • Doğru. Metin LLM'ine yalnızca görsel için bir ajan erişimi verirsen o sorun çözülür
      Gerçekten istersen görseller için Opus'u da çağırabilirsin, yine de maliyetten tasarruf edersin gibi görünüyor

  • Açık kaynak modelleri denemek için Ollama'ya kaydoldum
    Son 3 aydır sürekli deneyip kullanma seviyesindeydim ama GLM, Claude'la birlikte gerçek kodlama işlerinde her gün kullandığım ilk model oldu. Oldukça iyi, o yüzden her gün Ollama kullanım limitimi dolduruyorum

    • İlginç. GLM'i ne tür işler için kullandığını ve Ollama üzerinden faydalı bulduğun başka hangi modellerin olduğunu merak ediyorum

  • GLM daha az token harcıyor ve daha az araç çağrısı yapıyor ama tamamlaması iki katından uzun sürüyor
    Bu süre modelin çalışmasından kaynaklanmıyorsa nerede harcanıyor merak ediyorum
    Tek tek araç çağrıları daha karmaşık olduğu için mi daha uzun sürüyor, yoksa model token başına daha fazla hesaplama yaptığı için saniye başına token sayısı mı daha düşük?

    • Opus ve GPT 5.5, işe göre düşünme ve akıl yürütme yoğunluğunu ayarlamada çok iyi; açık ağırlıklı modellerde ise bu kısmın hâlâ daha zayıf olduğunu hissettim
      Ayrıca GLM 5.2 ya da DeepSeek v4 Pro gibi bazı açık ağırlıklı modellerin token üretim hızı çok daha yavaş, bu da hissedilen gecikmeyi etkiliyor. Yine de GLM 5.2'ye yavaş bir model demek zor; örneğin şu anda Notion içindeki en hızlı modellerden biri
    • En büyük etken büyük ihtimalle modelin çalıştığı veri merkezidir
      Bir diğer olasılık da Opus'un Mixture of Experts gibi bir yaklaşım kullanması; bu durumda belleğe aynı anda alınan model kısmı GLM'den daha küçük olabilir
    • Altyapı kaynaklı olabilir. Anthropic çok daha hazırlıklı görünüyor

  • GLM 5.2'nin anlamlı başarı elde etmesini sınırlayan büyük bir sorun var: kodlama aboneliğinin değeri
    Yalnızca API fiyatına bakarsan GLM 5.2 rakiplerini geçiyor. Ama kodlama işleri için API ücretlendirmesini kullananlar çoğunlukla büyük şirketler ve buralarda da ciddi şekilde sübvanse edilen abonelik ürünleri giderek kayboluyor
    Aynı zamanda bu şirketler çalışanlarına Çin API'leri kullandırmayacaktır
    Bireyler ve küçük ekipler açısından Z.ai'nin kodlama aboneliği Anthropic ve OpenAI'den daha zayıf. Claude'la benzer kullanım miktarı alınabilir belki ama Codex'te ödenen paraya karşılık alınan kullanım kesinlikle daha fazla
    Z.ai'nin GPT5.5 ve Opus 4.8'e ne kadar yaklaştığı tartışılabilir ama hepsinin aynı fiyat olduğu bir dünyada özgürce seçim yapabilseydim GLM'i seçmezdim
    Bu yüzden asıl soru, GLM 5.3 ya da 6 ile Z.ai ürününün ne kadar iyileşeceği ve OpenAI ile Anthropic'in yakın gelecekte mevcut ürünlerini ne kadar kısıtlayacağı

    • ABD dışından bakınca tablo farklı görünüyor. Avrupa şirketleri ABD ihracat kontrolleri yüzünden Fable'ı kaybetti, daha önce de Anthropic verileri 30 gün saklayacağını açıklamıştı
      Bu şirketler için, ellerinden alınamayacak bir yapay zekayı merkeze alarak altyapı kurmanın anında bir değeri var. Avrupa dışındaki diğer ülkeler ise fiyata daha duyarlı ve Çinli şirketlerle ilişki kurma konusunda aynı korkuları taşımıyor
    • API ücretlendirmesini kullananlar sadece büyük şirketler değil, OpenCode gibi üçüncü taraf çalışma ortamlarını kullanan kişiler de buna dahil
      Aynı zamanda, “bu şirketler çalışanlarına Çin API'leri kullandırmaz” diyorsak, GLM sunan Amazon Bedrock'ın kimi hedeflediğini merak ediyorum
      Bireyler muhtemelen DeepInfra gibi daha ucuz ABD sağlayıcılarını seçer. GLM'in önbellekli girdisi 1 milyon token başına $0.18, Opus ise $0.50. Fireworks AI da bir seçenek
    • Bireysel aboneliği zararına verilen bir yem olarak görüyorum. Para kurumsal token sözleşmelerinden kazanılıyor
      20 ya da 100 dolarlık planlarla binlerce dolarlık token tüketerek kod yazmaya alışan çalışanlar ve öğrenciler, kurumsal harcamayı itecektir
      Rekabetçi bir Çin modeli çıkmış olması bu kurumsal harcamanın yerini almaz ama ABD ya da AB'de barındırılan açık modeller alabilir
      GLM 5.2'nin varlığı, OpenAI ile Anthropic'in API erişimi için koyabileceği fiyata bir tavan getiriyor
    • Önemli bir nokta. API fiyatlama modelinin, tıpkı MMS'e para ödemenin ortadan kalkması gibi, sonunda yok olabileceğini düşünüyorum. Eski bir model
      Benim tahminim, işlerin çoğu kodlama planları içinde yapılıyor
      Ama kullanım limiti dışında da planların fazla kısıtlayıcı olması sinir bozucu. Anlaşılır ama rahatsız edici. Pratikte gerçekten katı olanlar sanırım sadece Anthropic ve belki Google
      Anthropic, kullanımın hizmet şartlarına uymadığını düşünürse sonradan API tarifesi üzerinden ücret çıkarabileceğine dair bir politikayla insanları korkuttu. Yersiz bir endişe olabilir ama gerçekten yapabilecekleri hissi verdiği için uzak durmama neden oluyor
    • OpenRouter'da hesabım ve bakiyem vardı; GLM 5.2'yi test ederken daha iyi şartlar umuduyla z.ai aboneliğine de bakmak istedim
      Ama oradaki altyapı açıkça aşırı yüklüydü; 5.2 sohbet istekleri %100 zaman aşımına uğradı. Altyapı model performansına yetişirse daha sonra tekrar denerim; ancak o zaman aboneliğin değerli olup olmadığına karar verebilirim

  • Bugün GLM-5.2'nin estetik duyarlılık ve UI işlerinde GPT-5.5'ten çok daha iyi olmasına şaşırdım
    Şimdilik Conductor üzerinden Claude/Codex kurulumunu koruyacağım ama bu model yüzünden OpenCode'u kurup masaüstü uygulamasını indirdim ve bugünkü işlerin çoğunu orada yaptım

  • “GLM-5.2 çok daha ucuza mal oldu. Opus süreci yarı sürede bitirdi ve daha temiz bir oyun çıkardı” gibi cümleleri görünce hemen LLM tarzı yazım hissediliyor
    Sanki tüm modeller bu yazı stiline yakınsamış gibi ve performans artsa da bu taraf pek değişmiyor gibi görünüyor

    • İyi geri bildirim. Bu tür LLM tarzı anlatım şu anda yaşadığımız ve iyileştirmeye çalıştığımız bir sorun

Teknik yazarlık sektörü şu anda büyük bir darbe alıyor. Şirketler daha kısa sürede daha fazla iş talep ediyor ve kalite ciddi biçimde düşüyor; bu yüzden yazıların cümle kalitesini gündelik olarak cilalamaya ayıracak zaman giderek azalıyor
Biz şu anda bu değişimin en ön hattında çalıştığımız için en büyük etkiyi biz hissediyoruz, ama aynı zamanda değişimi ilk deneyebilen tarafta olmak da hem heyecan verici hem de son derece sinir bozucu

  • Görünüşe göre insanlar artık LLM üslubunu epey benimsemeye başladı
  • Evet. Gerçekten rahatsız edici. Yeni yazılan metinlerin neredeyse yarısı artık aynı “sesle” çıkıyormuş gibi geliyor