GPT-5.5 Codex'te akıl yürütme token kümelenmesi performans düşüşüne yol açabilir

 (github.com/openai)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • OpenAI Codex issue #30364, gpt-5.5 yanıtlarındaki reasoning_output_tokens değerlerinin 516, 1034, 1552 gibi sabit değerlere yığılması olgusunun karmaşık Codex görevlerinde kalite düşüşüyle ilişkili olabileceğini bildiriyor
  • Analiz, 1 Şubat 2026-27 Haziran 2026 UTC arasındaki Codex token_count metadata'sını kapsıyor; 390.195 yanıt kaydı ve 865 oturum içinde exact 516 olayı olarak 3.363 örnek tespit edildi
  • gpt-5.5, tüm yanıtların %19,3'ünü oluşturmasına rağmen exact-516 olaylarının %82,0'ını oluşturdu; reasoning_output_tokens >= 516 içinde exact 516 oranı %44,0 iken non-GPT-5.5 için bu oran %1,3'ten çok daha yüksekti
  • Aylık exact-516 oranı Şubat 2026'da %0,11 iken Mayıs'ta %53,30, Haziran'da %35,84'e yükseldi; ancak aynı dönemde ortalama ve P90 akıl yürütme token sayıları düştüğü için bu durum yalnızca akıl yürütme token kullanımının artmasıyla açıklanamıyor
  • Sonraki yorumlarda Codex CLI, Codex Desktop ve OpenCode'da benzer 516 kümelenmesi ve bazı yanlış yanıt tekrarları paylaşıldı; geçici önlem olarak 518·n−2 desenini tespit edip akıl yürütmeyi sürdüren bir yerel proxy de önerildi

Sorunun özü

  • Codex issue #30364, gpt-5.5 yanıtlarının token_count metadata'sında reasoning_output_tokens = 516 etrafında aşırı yoğunlaşan bir desen bildiriyor
  • Ayrıca 1034, 1552 civarında da sabit sınırlar gibi görünen sıçramalar ortaya çıktığı söyleniyor
  • Öne sürülen kapsam, gizli chain-of-thought kesildiğini kanıtlama iddiası değil
    • Daha dar iddia, Codex telemetry'sinde gpt-5.5e özgü bir sabit token kümelenmesi anomalisinin görüldüğü
    • Sorun, bu desenin eşik tabanlı akıl yürütme bütçesi davranışıyla tutarlı göründüğü düzeyinde dile getiriliyor
  • İlgili issue #29353, gpt-5.5 çalışmasının tam olarak 516 reasoning token'da bitip yanlış yanıt döndürdüğü bir görev düzeyi tekrar üretimini ele almıştı; bu issue ise daha uzun bir döneme ait toplu kanıtlar ekliyor

Analiz ortamı ve veriler

  • Ürün Codex, en ilgili model ise gpt-5.5
  • Veri kaynağı Codex token_count metadata'sı
  • Analiz dönemi 1 Şubat 2026-27 Haziran 2026 UTC
  • Toplu sayılar:
    • Yanıt düzeyi token kayıtları: 390.195
    • Oturumlar: 865
    • exact reasoning_output_tokens = 516 olayları: 3.363
    • gpt-5.5in toplam yanıt payı: %19,3
    • gpt-5.5in exact-516 olaylarındaki payı: %82,0
    • gpt-5.5 exact-516 / >=516 oranı: %44,0
    • non-GPT-5.5 exact-516 / >=516 oranı: %1,3

Model ve ay bazlı desenler

  • Model bazında exact 516 / >=516 oranı en belirgin şekilde gpt-5.5te görülüyor
    • gpt-5.5: 75.401 kayıt, %44,0
    • gpt-5.4: 25.214 kayıt, %19,8
    • gpt-5.2: 247.575 kayıt, %0,34
    • gpt-5.3-codex: 13.333 kayıt, %0,0
    • gpt-5.3-codex-spark: 26.179 kayıt, %0,0
  • Aylık exact-516 kümelenmesi Mayıs 2026'da sert biçimde arttı
    • Şubat: %0,11
    • Mart: %2,45
    • Nisan: %4,25
    • Mayıs: %53,30
    • Haziran: %35,84
  • Aynı dönemde genel akıl yürütme token yoğunluğu düştü
    • Ortalama reasoning token: Şubat 268,1 → Mayıs 106,9 → Haziran 168,5
    • P90 reasoning token: Şubat 772 → Mayıs 344 → Haziran 515
  • Bu kombinasyon nedeniyle, exact-516 artışının yalnızca akıl yürütme token kullanımındaki artışla açıklanmasının zor olduğu belirtiliyor

Talep edilen iç doğrulama maddeleri

  • Codex ekibinden, gpt-5.5in akıl yürütme bütçesi, routing, kesme, fallback ve scheduler davranışlarının 516/1034/1552 civarında bitişe yol açıp açmadığını araştırması istendi
  • Davranış kasıtlıysa, exact 516'nın normal bir bitiş noktası mı, bütçe üst sınırı mı, degraded tier mı yoksa başka bir iç eşik mi olduğunun açıklanması da talep edildi
  • Önerilen doğrulama prosedürü:
    • Model bazında reasoning_output_tokens içeren token_count event'lerini sorgulama
    • 0, 516, 1034, 1552 exact-value sayımlarını karşılaştırma
    • Model ve gün bazında count(reasoning_output_tokens = 516) / count(reasoning_output_tokens >= 516) hesaplama
    • gpt-5.5 ile gpt-5.2, gpt-5.4 ve Codex'e özel varyantları karşılaştırma
    • GPT-5.2 ve GPT-5.5'te karmaşık görevleri yeniden çalıştırıp exact-516 yanıtlarla daha uzun reasoning yanıtlarını ayırarak kalite değerlendirmesi yapma

Yorumlarda gelen ek tekrarlar ve çapraz veriler

  • GitHub Actions, ilgili olası duplicate aday olarak #29353'ü işaretledi
  • Birden fazla kullanıcı aynı sorunu yaşadığını yorumlarda belirtti; bir kullanıcı da bu issue'nun önceki issue'ya göre daha veri temelli bir rapor olduğunu söyledi
  • sinnet3000, Codex CLI ve OpenCode'un yerel oturum depolarından çapraz istemci verileri sundu
    • Codex ~/.codex/sessions ve archived_sessions içindeki yaklaşık 22,7k token_count event'inde gpt-5.5 için records 4.300, >=516 156, exact 516 88, oran %56,4
    • OpenCode opencode.db içindeki yaklaşık 32,1k assistant message'da gpt-5.5 için records 6.977, >=516 126, exact 516 90, oran %71,4
    • Kimi, DeepSeek, MiMo, MiniMax, Gemini, Qwen, GLM gibi hacmi anlamlı non-OpenAI modellerin toplam yaklaşık 24k record'unda exact 516 sayısı 0
    • Bu verilerin yanıtların doğru mu yanlış mı olduğunu değerlendirmediği, yalnızca exact 516 kümelenmesinin varlığını doğruladığı notu düşüldü
  • kyleboddy, Windows 11 üzerinde Codex Desktop'ta ilişkili davranış farkı bildirdi
    • 5 adet fresh, projectless Codex Desktop thread'inde aynı candy prompt çalıştırıldı
    • Hızlı direct-final_answer çalışmaları 29 döndürdü ve yanlıştı
    • Daha yavaş ve önce commentary çıkan çalışmalarda 21 döndü ve doğruydu
    • fresh Windows-host Desktop thread'lerinden exact reasoning_output_tokens çıkarılamadığı için bu yanlış çalışmaların tam olarak 516 olduğunu söyleyemediğini belirtti
  • Aynı kullanıcı, yerel oturum metadata'sında gpt-5.5 / xhigh için sabit değer kümelenmesini de topladı
    • records 16.141, sessions 51, ortalama reasoning 149,7, P90 429
    • =516 438 olay, >=516 1.298 olay, oran %33,74
    • =1034 52 olay, =1552 14 olay, =2070 16 olay, =2588 12 olay, =3106 5 olay

Codex Linux CLI tekrar üretim sonuçları

  • kyleboddy, Codex Linux CLI'da da aynı candy prompt ile tekrar üretim yaptığını söyledi
  • Ortam:
    • Ürün: Codex CLI
    • Sürüm: codex-cli 0.142.5
    • Platform: Ubuntu Linux 6.8.0-111-generic, x86_64
    • Node: v24.14.0
    • Kimlik doğrulama modu: ChatGPT
    • Test modeli: gpt-5.5
    • reasoning efforts: xhigh, high
    • Karşılaştırma modeli: gpt-5.4 xhigh
  • Prompt, harici araç kullanmadan, dokunarak shape ayırt edilebilen bir candy bag probleminde minimum draw sayısını soruyor
  • Beklenen yanıtın brute-force enumeration ile bağımsız olarak 21 olduğu doğrulandı
    • Shape'in dokunarak ayırt edilebilmesi sayesinde 9 round + 12 star candy planlanabileceği açıklaması da yer alıyor
  • Sonuçlar:
    • gpt-5.5 xhigh ile tamamlanan 4 çalışmanın tamamında reasoning_output_tokens = 516 görüldü ve son yanıtlar 23, 26, 28, 15 oldu; hepsi yanlıştı
    • gpt-5.5 high ile 3 çalışmanın tamamı yine 516 oldu; yanıtlar 22, 21, 27 idi ve yalnızca 1'i doğruydu
    • gpt-5.4 xhigh ile 3 çalışma 6211, 12274, 10876 reasoning token kullandı ve hepsi 21 ile doğru sonuç verdi
  • Bu sonuçlar, gpt-5.5in Codex'te sabit 516-token yoluna girebildiği ve bu yolun görev kalitesindeki düşüşle ilişkili olabileceği yönündeki dar iddiayı güçlendiriyor

Geçici çözüm önerisi

  • dzshzx, upstream fix beklenirken Codex'in önüne konulabilecek yerel bir Responses proxy'si olan codexcomp'u önerdi
  • Çalışma biçimi, 518·n−2 desenini bir kesilme olarak görüp akıl yürütmeyi sürdürmek üzerine kurulu
    • reasoning_tokens == 518·n − 2, yani 516, 1034, 1552 gibi değerlerde biten round'lar truncated olarak ele alınıyor
    • Tentative output atılıyor, ilgili round'un reasoning item'ları ve encrypted_content bir sonraki girdiye yeniden oynatılıyor
    • Buna phase:"commentary" ve "Continue thinking..." mesajı birlikte ekleniyor
    • Tüm round'lar tek bir downstream response içine katlanıyor, böylece Codex'e tamamlanmış tek bir yanıt gibi görünüyor
  • Yapılandırma resmi üst düzey openai_base_url anahtarını kullanıyor
    • Örneğin: openai_base_url = "http://127.0.0.1:8787/v1";
    • Yerleşik openai provider korunuyor; böylece session grouping, remote compaction ve remote-control çalışmaya devam ediyor
  • Gerçek log örneği, art arda iki kez 516'dan sonra üçüncü round'da temiz biçimde bitip nihai yanıtın doğru olduğu bir vakayı gösteriyor
    • round 1: reason=516 → continue
    • round 2: reason=516 → continue
    • round 3: reason=291 → clean
  • Uyarılar:
    • Bu, resmi olmayan bir geçici çözüm ve upstream'in sözleşmeye bağlı olmayan davranışına dayanıyor
    • Continuation round'ları ek gerçek token tüketiyor
    • n window ve 3-continuation cap ile sınırlandırılmış
    • Yalnızca loopback, auth passthrough; credentials okumadığı veya saklamadığı belirtiliyor

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News yorumları

  • Bu oldukça ciddi görünüyor ve codex cli ile de kolayca yeniden üretilebiliyor.
    Akıl yürütme gerektiren bir bulmaca prompt’u verdiğinizde bazen aniden kesilmiş gibi tam olarak 516 düşünce token’ı kullanıp yanlış cevap veriyor.
    6000–8000 düşünce token’ı kullandığı durumlarda doğru cevabı veriyor.
    Uyarlamalı düşünme (adaptive thinking) tarafında bir sorun olabilir; ayrıca yerel modellerde sessiz sunucu tarafı değişiklikleri konusunda endişelenmek gerekmemesi de onlara bir artı puan daha yazdırıyor.
    Aynı prompt’u 10 kez çalıştırdım; 4’ünde bu 516 token sorunu vardı ve bu 4’ünün hepsi yanlış yanıttı. Örneklem küçük ama 5.5 xhigh’ın neredeyse yarı yarıya kısa kesilip performansının düşebileceği görünüyor.

    • Uyarlamalı düşünmede felsefi olarak da bir sorun olduğunu düşünüyorum. Düşünmeden önce düşünce bütçesinin ne kadar ayrılacağını tahmin eden bir yaklaşım; LLM bağlamında ise gereken düşünme miktarını, yani token üretim miktarını önceden bilmenin neredeyse hiç yolu yok gibi.
      Problem uzayı sonsuz geniş ve yalnızca prompt’lar arasındaki benzerliğe bakarak ne kadar düşünmek gerektiğine karar vermek zor. Model zaten düşünce bütçesine ulaşmadan önce de düşünmeyi bırakıyor.
      Uyarlamalı düşünmeyi uygulamak için neden bu kadar çok çaba harcandığını bilmiyorum; bunun yerine modeli düşünce sonlandırma token’ını daha iyi üretecek şekilde eğitmek gerekmiyor mu diye düşünüyorum.
      Yama gibi hissettiriyor. Model uygun miktarda akıl yürütme yapacak şekilde eğitilmeli: akıl yürüt → kalan belirsizliği tahmin et → devam edip etmeyeceğine karar ver → daha fazla akıl yürüt → tekrarla.
    • Yerel modellerde de yapılandırma hataları konusunda endişelenmek gerekir. Uzmanlar da hata yaptığı için sağlayıcıdan sağlayıcıya yerel model performansı dalgalanıyor.
    • Saat dilimine veya haftanın günlerine göre yapılan testlerde bir örüntü görünüp görünmediğini merak ediyorum. Örneğin iş saatleri yoğunluğunda kısa kesilme olgusunun daha sık yaşanıp yaşanmadığına bakılabilir.
    • O boşa harcanan token’ların parasını da kullanıcı ödüyorsa, iade talebi göndermek iyi olabilir.

  • Neredeyse her gün kalitenin basamak basamak düştüğünü yaşadım ve genelde xhigh kullanıyordum.
    Yılın başlarında Codex’in olağanüstü titiz kodlamasına dayanma deneyimi artık yok oldu; arada sırada akıl almaz derecede aptalca uygulamalar çıkmaya başladı ve OpenAI bu sorunu ciddiye alana kadar Claude’a geçtim.
    Kişisel olarak bunu aylardır görüyorum; OpenAI’nin bunu ciddiye alıyormuş gibi görünmediğini düşündüm.

    • 3 ay önce Claude aşırı aptallaştığı için Codex’e geçmiştim; 6 ay önce ise tam tersiydi. Codex de olsa Claude da olsa bir gün ikisi de insanı yolda bırakıyor. Yine de Codex muhtemelen biraz daha az kötü.
    • Haziran başından beri 5.5’in güvenilirliğinin kendi deneyimimde Claude seviyesine düştüğünü hissettim.
      Bu yüzden 5.5 high → 5.5 xhigh → 5.4 high şeklinde geçiş yaptım.
      5.4 high son 3 haftadır tamamen istikrarlıydı ve şu anda ondan memnunum.
      Ara sıra işimi 5.5 xhigh ile çalıştırıp %100 istikrarlı hâle dönüp dönmediğini kontrol ediyorum ama şu an bu güvenilirlik sorununu düzeltmektense 5.6’nın çıkmasını bekleyeceklerini düşünüyorum.
    • Bunun teknik bir sorun olduğuna inanmıyorum. Düzeltmesi çok pahalı, kullanıcılar da yeterince çok ödeme yapmıyor; bu yüzden bunun performansı düşürmeye yönelik bir iş kararı olduğunu düşünüyorum.

  • Déjà vu gibi. Nisan ayındaki Claude Code performans gerilemesiyle birebir aynı görünüyor. O zaman Claude aboneliğimi iptal edip Codex’e geçmiştim.
    Şimdi ikisini de token başına ücretlendirmeyle kullanmayı, işlerin çoğunda Fireworks’ün GLM 5.2’sini kullanıp yalnızca gerektiğinde büyük modellere para harcamayı düşünüyorum. Yine de başa baş noktasının tutup tutmayacağından emin değilim.

    • Token başına ücretlendirme konusunda benim tepkim de aynıydı; ancak iki laboratuvar için de müşterileri token başına tüketime taşımak ekonomik olarak avantajlı olduğu için prensip olarak bundan kaçınmak istiyorum.
      Kasıtlı olmasa bile, kalitesi düşmüş bir üründen kâr elde edilen bir yapıyı kabul etmek ya da mümkün kılmak istemiyorum.
      ChatGPT’nin çıkışından bu yana her zamankinden daha fazla açık kaynak modeller ve açık çalıştırma ortamları, örneğin Pi gibi şeyler, çok daha cazip görünüyor.
    • Doğru. Ben de o olay yüzünden Claude Code’u bırakıp Codex’e geçtim.
      Şimdi bu saçmalıklar için yeniden endişelenmemek adına 65.000 doları nasıl ek olarak kazanabileceğimi düşünüyorum. OpenRouter gibi şeylerin ekonomisini biliyorum.
      2008 civarında “bulut”un bir pazarlama terimi olarak öne çıktığı zamanları hatırlatıyor. Zengin istemcilere dair beklentileri düşürüp yerel sahipliği aşındıran abonelik modelleriyle şirket marjlarını büyütmenin ambalajı gibi görünüyordu.
      Sonra “gerçek özgür/açık kaynak yazılım”a yönelik coşku ve mutlakçılıktan bıkıp genç olduğumu düşünüp geçmiştim.
      Aslında birçok abonelik modelini bir ölçüde anlayabiliyor ya da tolere edebiliyorum. Yazılım üretmek pahalı ve 2026’da Photoshop’un yıllık yükseltme değerini 200 dolar olarak görmek adil olmayabilir. Ama 20 yıldır iyi çalışan bir UI’ı keyfi şekilde değiştirmek ve klasik renk örnekleri gibi şeyleri tamamen kaldırmak aptalca.
      O zaman ayda 200 dolar ödediğim iş açısından kritik aracım Codex ile klasik örnekler eklentisi yapabilirim.
      Token kullanımım için ayda 200 dolar adil mi? Çok yoğun kullandığım aylarda belki 1 milyar token civarı kullanmış olabilirim.
      Ama sorun da tam olarak bu. Bunlar hangi kârlılık düzeyinin uygun olduğunu somut olarak bilmeden durmaksızın kolları çekip duracak; borç vadeleri gibi fal bakma işaretlerine bakılırsa bu en azından 2030 ya da 2032’ye kadar sürecek gibi.
      Bunları hiç düşünmek istemiyorum. Model tercihlerini ve performans düşüşlerini değerlendirmek; gerçekten para karşılığı üretip bakımını yaptığım çıktılarda kullanılan sonuçlara etki eden gizemli arka uç deneylerine göre yapay zekâya nasıl konuştuğumun nüanslarını sürekli güncellemek istemiyorum.
      Yapay zekâ, araç ile işbirlikçi arasında bir yerde; akıl yürütme aşamasında pek iyi anlaşılmayan düğme ve kollarla oynanmasından kaynaklanan değişken “kişilik” değişimleri insanı çıldırtıyor. Bu yüzden köşedeki kutuyu gösterip, benden başka kimsenin değiştirmediği çıktı kalitesini tam olarak bilmek istiyorum.
    • Fireworks?
    • “Hisse dayalı” Claude Code performans gerilemesi denen şey, evet. Deterministik olmayan sistemlerde tutarlı performans beklememek gerekir. Performans düşüşünü destekleyen hiçbir ampirik veri yok.
      Son zamanlarda basamak basamak değişen şey model performansı değil, kodcuların mızmızlanma ve şikâyet miktarı.

  • Codex’in açık kaynak olması sayesinde bu tür sorunların kamuya açık biçimde ortaya çıkıp ele alınabilmesi güzel

    • Ama bu model davranışıyla ilgili; herkese açık bir issue tracker olması, kodu eksik olan Claude Code’dan farklı değil gibi geliyor. Bu tür sorunlarda https://github.com/anthropics/claude-code ile ne farkı var bilmiyorum
      Codex’in açık kaynak olmasına genel olarak minnettarım, ama bu tür problemlerde model hâlâ kapalı olduğu için bunun pek anlamı yok gibi görünüyor
    • OpenAI genel olarak Anthropic’ten çok daha açık ve gerçek bir şirket gibi hissettiriyor. Anthropic ise düpedüz kara kutu

  • Hafızam yanıltıyor olabilir ama token kullanımı ve kod kalitesi ölçütlerine göre 5.3 en iyisiydi sanırım. 5.5 daha iyi çalışıyor ama token’ları resmen öğütüp bitiriyor

    • Sadece ben böyle düşünmüyorum. 5.3-codex’in çıktı kalitesi ile maliyet dengesi açısından harika bir model olduğunu düşünüyorum
      5.5 veya Opus’un aksine neredeyse her işte kullanılabilecek kadar ucuz ve verimliydi, buna rağmen oldukça iyiydi; Sonnet’e tercih ediyordum
    • Birkaç hafta önce 5.3 benim için kullanılamaz hâle geldi. Ya öylece takılıyor ya da berbat yanıtlar veriyordu

  • Birkaç gün önce burada biri OpenAI’ın çığır açan bir optimizasyonla hesaplama maliyetini yarıya indirdiğini söylemiş gibiydi; bu o mu?

    • O The Information’daki bir haberdi, ama iyi yazılmış bir metin gibi görünmüyordu. Yazarın, LLM’lerin nasıl çalıştığını yeterince bilen ve içeriden söylentileri güvenilir biçimde değerlendirebilecek bir teknik uzman olduğu izlenimini almadım: https://www.theinformation.com/newsletters/ai-agenda/openai-...
      Haberde, konudan haberdar bir kişiye göre “OpenAI mühendisleri bu ayın başında bazı meslektaşlarına, yeni keşfedilen bir optimizasyon sayesinde mevcut modelleri çalıştırmanın, yani çıkarım maliyetini yarıdan fazla azaltmanın bir yolunu bulduklarını söyledi” deniyordu
    • Ben o söylentiyi OpenAI’ın kendisinden değil, olaylardan sonra OpenAI’dan ayrılan gruplardan birinin, muhtemelen Thinking Machines’in bir atılım yaptığı ve bunu OpenAI’a teklif ettiği şeklinde anlamıştım. OpenAI’ın bunu henüz fiilen uyguladığını sanmıyorum

  • Benim durumumda bu etki, şifrelenmiş akıl yürütme içeriğine base64 dizesi uzunluğu olarak bakınca görünüyor. Ama sunucunun raporladığı akıl yürütme token’larında görünmüyor
    Bu yüzden bunun tamamen şifreleme veya obfuscation’ın bir parçası olduğunu düşündüm, gerçek bir sorun olmadığını varsaydım
    GPT’nin en büyük eksiği, düşünme sürecinin şifrelenmiş olması nedeniyle Kimi, GLM ve DeepSeek’e kıyasla daha da kara kutu olması. Yine de düşünce özeti alınabildiği için tuhaf olsa da kullanılabiliyor

  • Nadiren de olsa “modeli aptallaştırdılar” sözü, her zamanki kullanıcı paranoyası değil de gerçekten modelin aptallaştırıldığı bir durum mu?

    • Bu daha çok çıkarım motorunda ya da ajan çalışma ortamında bir kusur veya yapılandırma hatası gibi görünüyor
      Issue ayrıntıları kasıtlı gizli zayıflatmanın kanıtı değil; hatta daha çok tersine işaret ediyor. Kök neden kaba saba ve sıradan bir kullanıcının bağımsız olarak doğrulanabilir, net ayrıntılarla rapor edebileceği kadar da pek gizli değil
      “Her zamanki kullanıcı paranoyası” ifadesi ne adil ne de hoşuma gidiyor. Elinizde yalnızca bağlam penceresini yutup devam eden çıktıyı tüküren sihirli lavabo gibi bir API endpoint’i varsa geriye öznel yargı, tahmin ve şüpheden başka pek bir şey kalmıyor
      Standartlaştırılmış model test paketleri olsa bile, gizli zayıflatma iddiası eninde sonunda şirketteki insanların niyetini okumaya dayanıyor. Açık bir niyet veya temel altyapı düşürmesi olmadan da model kalitesi düşebilir
      Şaka yollu komplo teorileri kurmak ya da gerçek zayıflatma ihtimalini değerlendirmek kendi başına akıl hastalığı değil. Psikolojik tanı terimlerinin bu şekilde kötüye kullanılmasından hoşlanmıyorum
      Elbette bu tür yargılarda aşırı emin olan insanlar da vardır ve bu onlar için geçerli olabilir, ama onlar azınlık. Sonuçta bu sadece abartı ve kimseye faydası yok

  • Frontier model aboneliği satıp zaman geçtikçe hızlıca nerf’lemeleri ve kimsenin bundan bahsetmemesi komik
    Sunucu tarafında sessizce akıl yürütme yoğunluğunu düşürüyorlarsa indirim de yapmaları gerekir
    Öte yandan ben 5.5-high’ı her gün paralel çoklu iş akışlarında kullanıyorum ve haftalık kotayı ancak kıl payı tüketiyorum. Planlama ve uygulamanın tamamını takip edip okuyacak kadar hızlı bir Human-as-a-Service değilim. İşin o yönü de var

  • İşlem hacmini optimize etmek için akıl yürütme çıkarımını 512 token katları hâlinde gruplayıp batch işledikleri açık görünüyor

    • İlk düşüncem, llama.cpp açısından bakınca akıl yürütme bütçesi parametresi ayarının böyle bir sonuç doğurmuş olabileceğiydi. Ama OpenAI’dan bir açıklama gelmeden tam olarak bilmenin yolu yok
      Yoğun saat talebine göre ölçeklenmenin çok dürüst olmayan bir yolu da olabilir. Bu konuda model performansı algısının öznelliğiyle dalga geçen insanlar olduğunu biliyorum, ama en azından mayıs ayı boyunca yaptığım testlerde ABD’nin çevrimiçi olduğu saatlerde model daha az akıllı görünüyordu
      Birkaç hafta önce şirket blog yazımda da çakışan saatlerde daha tutarlı bir kalıp olarak hissedildiği için buna değinmem gerektiğini düşündüm. Ek analiz için oturum günlüklerini saklamalıydım https://webesque.agency/blog/2026-06-19-llms.html
    • Standart olan continuous batching kullanmak değil mi? Continuous batching kullanıyorlarsa üretilen token uzunluğu neden önemli ve neden uzunluğa göre grupluyorlar, merak ediyorum. Kullanmıyorlarsa da neden kullanmadıklarını ve bunun getirdiği ödünleşimleri merak ediyorum