deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak dev.to (home feed)

Dört harness hatası, bir ajanın Codex CLI'nin token'larının 3,1 katını neden harcadığını açıklıyor

Bir dev.to post-mortem incelemesi, 3,1 kat token aşımını açıklamak için 150 eşleştirilmiş benchmark izini inceleyiyor; bir replay hatası, hatalı biçimlendirilmiş bir status talimatı, ölü bir confidence gate ve faturalandırılan boşluklar buluyor.

Dört harness hatası, bir ajanın Codex CLI'nin token'larının 3,1 katını neden harcadığını açıklıyor

Octomind ajanını benchmark eden ekipten bir üyenin dev.to'da yayımladığı bir post-mortem, istemcilerinin en kötü görevlerde Codex CLI'nin token'larının 3,1 katını nasıl tükettiğini ve 150 yürütme izinin elle okunmasının israfın gerçekte nereden geldiğini neyi ortaya çıkardığını anlatıyor.

Ne ölçüldü

dev.to gönderisine göre ekip, Octomind 0.70.1 ile Codex CLI 0.167.0'yı GOLD benchmark'ında karşı karşıya getirdi: 65 görev ve 150 eşleştirilmiş çalıştırma, iki istemci de aynı modeli, gpt-6.1-sol'u kullandı. Eşleştirme, her görevin farklı günlerde değil, aynı zaman penceresi içinde iki istemciye de gitmesi anlamına geliyor.

Ortalamalar sağlıklı görünüyordu ama altı görev sıkıştı: token'da 3,1 kata, duvar saati süresinde 2,3 kata kadar kullanıldı. İz analizinin tetiklediği düzeltmelerden sonra görev başına oranlar 0,75x token, 0,87x maliyet ve 1,08x süre olarak yerleşti. Tam bir tur, Codex CLI'nın 122,4 milyona karşı 76,6 milyon token tüketti; reasoning token'ları tur başına Codex'in 196K'sına karşı 96K oldu.

Yazar metodolojik bir uyarı ekliyor: 65 görevin yalnızca 38'ini iki istemci de çözdü ve bu örtüşme, token verimliliğini karşılaştırmanın tek adil temeli. Erken vazgeçen bir çalıştırma yanlış nedenle ucuz görünür; dakikalarca debelenip başarısız olan bir çalıştırma ise verimlilikle ilgisiz nedenlerle pahalı görünür.

Bir ekstra çağrı bir kalem değil, bir çarpan

Analizin çerçeveleyen içgörüsü bir hata değil, aritmetik. Durumsuz (stateless) bir completions API'sına karşı ajan döngüsündeki her çağrı tüm konuşmayı yeniden gönderir. Bu nedenle uzun bir görevin başındaki gereksiz bir çağrı tek seferlik bir masraf değildir: biriken prompt o çağrıda ve sonrasındaki her çağrıda yeniden faturalandırılır, çünkü ekstra tur geçmişin parçası haline gelir.

İzlerin ortaya çıkardığı dört sorun

İlkü bir replay hatasıydı. Konuşmaları yeniden yapılandırıp modele geri veren bir kod yolu, modelin hiç üretmediği asistan turları ekliyordu. Model, hiç kullanmadığı bir üslupta yazılmış bir transkripti uzlaştırmak zorunda kalıyor, bu da sonraki her çağrıda reasoning token'larını yükseltiyordu. Yazar bunu, gönderileni izin alınan olarak kaydettiğiyle karşılaştırarak buldu.

İkincisi, modelden bir araç çağrısı (tool call) eklenmeden devam eden bir çalışma (work-in-progress) durum mesajı yaymasını isteyen bir harness talimatıydı. Araç çağıran bir döngüde, araç çağrısı olmayan bir asistan mesajı bir turun bittiği anlamına gelir; talimat bu yüzden döngünün sonlandırma kurallarıyla çelişti ve modeli temiz bir çıkış olmadan çalışmaya mahkûm etti. Codex CLI'nın 241 mesajında yapılan bir grep, bu örüntünün tek bir örneğini bile bulamadı; basitçe因为 Codex hiçbir zaman bu talimatı almıyor.

Üçüncüsü, modelin zaten emin olduğu işi kısa devre yapması gereken, 0,8'e ayarlanmış bir confidence gate'ti. 40 çalıştırmada bir kez bile tetiklenmedi; yani kod yolu ölüydü ve yazarın gated olarak akıl yürüttüğü her çalıştırma aslında değildi. Verilen tavsiye: herhangi bir eşiğin yakınından geçen değerleri loglayın ve histogramı bir tarafta boş olan bir gate'i silin ya da taşıyın.

Dördüncüsü timeout yönetimiydi. Çağrılar 300 saniyelik bir timeout'a çarptığında, halihazırda stream edilen token'lar yine de faturalandırılıyordu ve çalıştırmalar boyunca bunların yaklaşık 14.000'i boşluktu (whitespace). İlgili bir askıda kalma (hang) sorunu hâlâ açık: bir çalıştırma, onu koruması gereken timeout'tan daha uzun süre, 336 saniye boyunca sessiz bir stream üzerinde oturdu; henüz bir teşhis yok.

Ajanın hâlâ kaybettiği yerler

Runtime hâlâ 1,08x ve token tasarrufu bunu düzeltmedi, çünkü duvar saatini token hacminden çok gidiş-dönüşler ve sağlayıcı gecikmesi belirliyor. Bir görev, Pydantic, düzeltmelerden sonra token'da 1,57x'e geriledi; yazar, ekstra çağrıların kaldırılmasının geçmişi yeniden şekillendirdiğini ve bu görevi daha uzun bir yola ittiğini düşünüyor ama bunu açıkça bir tahmin olarak etiketliyor.

Bir benchmark tuzağı

Eşleştirilmiş çalıştırmalardan önce iki istemci bir hafta arayla karşılaştırılmış ve Octomind için model çağrısı başına ortalama 11,9 saniye, Codex CLI için 7,2 saniye gösterilmişti. Yazar bu farkı istemcilerden çok değişen sağlayıcı yüküne ve yönlendirmeye bağlıyor ve ekibin, başkasının altyapısına ait bir gecikmeyi optimize etmek için bir hafta harcamaya yakın geldiğini söylüyor.

Neden önemli

LLM ajanları geliştiren veya değerlendiren ekipler için bu gönderi, maliyet aşımının çoğu zaman modelde değil harness tasarımında yattığına dair somut bir vaka. Talimat formulation' döngü sonlandırma kurallarıyla sessizce çatışabilir, ölü gate'ler mimari illüzyonu yaratır, stream edilen token'lar takılmalar hiçbir şey üretmese bile faturalandırılır ve ortalamalar hataların bulunduğu kuyruğu gizler. En az bunun kadar önemlisi, farklı zaman pencerelerinden ajan çalıştırmalarını karşılaştırmak istemciyi değil sağlayıcıyı ölçer; güvenilir benchmark yöntemi eşleştirilmiş, aynı penceredeki çalıştırmalardır.

  • #llm-agents
  • #benchmarking
  • #token-usage
  • #debugging
  • #cost-optimization

İlgili yazılar