Token’lar nereye gidiyor? Cloudflare AI code reviewer maliyetini yüzde 68 nasıl düşürdü
Cutting our inference bill by 68% by being obsessive about optimization · Ryan Skidmore
Cloudflare’in AI code reviewer’ı nisan ayında ortalama 1,19 dolara bir review yapıyordu; ağustos sonunda bu rakam yaklaşık 2,46 dolara çıktı. Mimaride önemli bir değişiklik yoktu: aynı coordinator, aynı specialist reviewer’lar, aynı risk tier’ları. Eylül ortasında agent’lara ‘token’lar nereye gidiyor, agresif biçimde kes’ görevi verildi. Sonuç: kod kalitesi yüksek efor seviyesinde kalarak ortalama review maliyeti en pahalı iki haftanın ortalaması olan 2,43 dolardan 0,77 dolara (yüzde 68) indi; medyan süre 4 dk 09 sn’den 1 dk 32 sn’ye düştü. Tasarrufun yaklaşık yüzde 40’ı reviewer kodundaki değişikliklerden, kalanı hangi modelin ne kadar efor harcadığını denemekten geldi.
Maliyet neden ikiye katlandı? Review başına maliyet mart 1,22 dolardan ağustos 2,32 dolara tırmandı. Küçük bir kısmı en pahalı tier’a (full review) düşen review oranının yüzde 59’dan yüzde 65’e çıkmasıydı (mühendisler daha büyük değişiklikler yapıyor). Asıl artış model değişikliklerinden geldi: ağustos başında tüm reviewer’lar Anthropic modellerine taşındı (eval’lerde bu iş yükünde daha iyi çıktığı için) ve job başına maliyet 1,38 dolardan 2,03 dolara yükseldi. Internal standards reviewer Claude Opus 4.7’ye geçince review başına 0,25 dolardan 0,88 dolara çıktı; coordinator’dan bile pahalı oldu. Cache hit rate yüzde 85,7’den yüzde 97’ye yükseldi ama review başına token sayısı 0,91 milyondan 2,99 milyona çıktığı için ucuz cache read bile toplamı artırdı.
Para nereye gidiyor? Optimizasyondan önce harcama şöyle bölünüyordu: output token’ları yüzde 23, cache write’lar yüzde 43, cache read’ler yüzde 34. Yani paranın çoğu model zaten görmüş ya da tekrar görecek bağlama gidiyordu. Bunun nedeni her LLM çağrısının tüm konuşmayı bağlam olarak yeniden göndermesi: code quality reviewer review başına ortalama 16,6 çağrı yapıyor, 72 bin token cache’e yazıyor ve 1,08 milyon token geri okuyor. Maliyet hem çağrı sayısıyla hem bağlam boyutuyla büyüyor. İki hedef belli oldu: her session’ın ilk isteği cache’e yazmak yerine cache’ten okusun, ve session daha az çağrı yapsın.
1. Cache’lenmiş prefix’i repository’ler arasında paylaşmak. Her session aynı tool tanımlarıyla ve aynı agent prompt’uyla başlıyor (11-21 bin token, tüm repository’lerde özdeş). Yine de ilk isteğin cache’lenmiş bir prefix bulma oranı yalnızca yüzde 14-26 çıktı. Neden: OpenCode v1 system prompt’u tek blok olarak kuruyordu (agent prompt’u, ardından çalışma dizini ve tarihi içeren bir environment bölümü) ve tek cache breakpoint’ini bloğun sonuna koyuyordu. Çalışma dizini ve tarih her job’da farklı olduğundan, ortak kısım hiç cache’lenemiyordu. Çözüm: her agent prompt’unun sonuna bir marker koymak ve bloğu bu marker’dan ikiye bölen bir plugin hook’u eklemek; birinci yarı her job’da aynı baytlarla bitiyor ve kendi breakpoint’ini alıyor. Standards reviewer’ın referans index’i de prompt’a taşındı (daha önce her session ilk üç turunu dosya okuyarak harcıyordu). Birlikte review başına 2,47 dolardan 2,02 dolara düşürdü.
2. Daha az çağrı. Üç küçük değişiklik birlikte review başına yaklaşık 0,20 dolar kazandırdı. Reviewer’ların kullanamadığı bir tool’u (final yorumu gönderen tool) görmemesi sağlandı: sub-reviewer’lar session’ların yüzde 57-76’sında bu tool’u çağırıp sunucu tarafında reddediliyor ve toparlanmak için bir çağrı daha harcıyordu. Dosyalar paralel okundu: code quality reviewer’ın turlarının yüzde 64’ünde model tam bir tool call yapıyordu (genelde tek dosya okumak), artık ortak bağlam ve patch’lerin hepsi ilk yanıtta okunuyor. Re-review’larda gereksiz reviewer’lar atlandı: job’ların yaklaşık üçte ikisi aynı merge request’in ikinci ya da sonraki review’ı ve çoğu zaman üç reviewer’ın bakacak yeni bir şeyi yok.
Güvenli geçiş. Reviewer OpenCode v2’ye taşındı. Hepsi tek seferde geçirilmeden önce her canary repository’de her review hem v1 hem v2 ile shadow mode’da çalıştırıldı; test edilen merge request’lerin yüzde 98’inde onay kararı aynı çıktı. Aynı modellerle full-tier review’lar v2’de yaklaşık yüzde 13 daha hızlı bitti.
Öne çıkanlar
- LLM maliyetini çoğu zaman output değil tekrar gönderilen bağlam (cache write ve read) belirler.
- Prompt cache bir prefix eşleşmesidir: prefix’e giren her değişken (tarih, çalışma dizini) cache’i bozar.
- Sabit olanı prompt’un başına, değişkeni sonuna koy; cache breakpoint’i ortak kısmın sonuna yerleştir.
- Agent’ın kullanamayacağı tool’u ona gösterme: reddedilen çağrı da para ve zaman harcar.
- Yeni sistemi eskisiyle shadow mode’da yan yana çalıştırmak, geçişi güvenli yapar.
Neden önemli?
Agent maliyetleri sessizce büyür: model değişir, bağlam büyür, çağrı sayısı artar ve kimse tek bir kalemi suçlayamaz. Bu yazı ‘önce ölç, sonra kes’ yaklaşımının somut örneği: harcamayı kalemlere ayırıp her kalem için ayrı bir düzeltme yapmışlar.
Pratikte
Kendi LLM çağrılarında hemen yapabileceğin üç şey var. (1) API cevabındaki usage alanlarına (cache_creation_input_tokens, cache_read_input_tokens) bak; cache read sıfırsa cache çalışmıyordur. (2) System prompt’a tarih, kullanıcı adı, çalışma dizini gibi değişkenleri koyuyorsan en sona taşı ya da kullanıcı mesajına al; sabit kısım bir cache breakpoint ile ayrılsın. (3) Agent’a verdiğin tool listesini gözden geçir: o adımda çağıramayacağı tool’u listeden çıkar. Sonra bir haftalık çağrıyı token cinsinden üç kalemde (output, cache write, cache read) ayır; hangisi büyükse önce onu hedefle.
Sözlük
- prompt caching
- Tekrar eden prompt prefix’ini yeniden işlemek yerine cache’ten okuyarak maliyet ve gecikmeyi düşürme.
- cache breakpoint
- Prompt’un hangi noktaya kadar olan kısmının cache’leneceğini belirten işaret.
- shadow mode
- Yeni sistemi gerçek trafikte eskisiyle yan yana çalıştırıp kararlarını etkisiz biçimde karşılaştırma.
- canary
- Bir değişikliği önce küçük bir kullanıcı ya da repository grubunda deneme.
- tool call
- Bir LLM agent’ının dış bir araç ya da fonksiyonu çağırması.