Token faturasını düşürmenin sessiz yolu: tekrarlı işleri betiğe, basit anlamayı yerel modele
AI kod asistanlarıyla uzun süre çalışınca fatura ya da kota tablosu bir şey söylemeye başlıyor: token'ın büyük kısmı zor problemlere değil, her gün aynı biçimde tekrarlanan işlere gidiyor. Dosya okumak, derleme çıktısını baştan sona bağlama almak, rapor şablonunu her seferinde yeniden kopyalamak gibi işler bunlar.
Bu yazıda kendi çalışma ortamımda üç günlük araç çağrısı kaydını (yaklaşık on iki bin çağrı) inceleyerek vardığım sonucu paylaşıyorum. Kısacası şu: tekrarlı işlerin çoğu deterministik. Onlar için model gerekmiyor, bir betik ve disiplin yetiyor. Gerçekten "anlama" gerektiren küçük işler ise yerel bir modele devredilebilir.
İşleri üç kovaya ayırmak
Envanteri çıkarırken her işe tek bir soru sordum: Bu işin sonucu her seferinde aynı kurala göre mi üretiliyor?
- Betik kovası: Görev durumunu değiştirmek, bir rapor iskeleti oluşturmak, derleme ve test çalıştırmak, doğrulama komutunu koşturmak. Bunlar kurala bağlı işler. Model bu adımları her seferinde yeniden kurduğunda hem token harcıyor hem de bazen bir adımı unutuyor.
- Yerel model kovası: Kısa bir metni birkaç maddeye özetlemek, bir mesajı "istek / geri bildirim / rapor" gibi kaba sınıflara ayırmak, ses transkriptindeki yazım ve noktalama hatalarını düzeltmek. Anlama gerektiriyor ama derin akıl yürütme gerektirmiyor.
- Büyük model kovası: Tasarım kararı, çok adımlı hata ayıklama, kod yazma ve son doğrulama. Burada tasarruf etmeye çalışmak kaliteyi düşürür.
İlk bakışta şaşırtıcı olan, birinci kovanın ne kadar dolu olduğuydu. Aynı "görevi incelemeye gönder" adımı günde onlarca kez, her seferinde elle kurulan komutlarla tekrarlanıyordu.
En büyük kazanç: bağlama ne girdiği
Tek tek komutlardan daha önemli bir kalem var: açılış bağlamı. Bir alt ajan işe başlarken kendi tanımını, hafızasını, kuralları ve görev dosyasını tam okuyorsa, daha ilk satırı yazmadan on binlerce token harcamış oluyor.
Bunun çözümü yeni bir araç değil, paketleme. Göreve gerçekten gereken parçaları (görev metni, kabul kriterleri, ilgili kuralların özeti, dokunulacak dosyalar) tek bir paket hâlinde ve bir token bütçesine sığdırarak vermek. Zorunlu bölümler önce sığar, sığmayanlar "sonra oku" listesine düşer.
Burada öğrendiğim bir ders daha oldu: aynı işi yapan ikinci bir komut yazmadan önce, mevcut araçların arasında zaten benzeri var mı diye bakmak gerekiyor. Benim ortamımda karakter sınırıyla çalışan bir paketleyici zaten vardı. Doğru hamle ona token bütçesi eklemekti. Sıfırdan paralel bir araç yazmak, zamanla birbirinden sapan iki kaynak demek.
Derleme ve test çıktısını kısmak
Başarılı bir derleme binlerce satır çıktı üretebilir ve bunların neredeyse hiçbiri modelin işine yaramaz. Basit bir sarmalayıcı bu sorunu çözüyor:
- Derleme başarılıysa tek satır yaz: "OK (12 sn)".
- Başarısızsa yalnız
error:veFAILEDsatırlarını göster. - Tam log her ihtimale karşı diskte dursun.
Bu kural zaten yazılıydı ama zorlanmadığı için uygulanmıyordu. Kural bir araca dönüşünce uygulanması da garanti oluyor.
Yerel model denemesi
Anlama gerektiren küçük işler için makinemde kurulu iki yerel modeli denedim: qwen2.5-coder:7b ve qwen3.5:9b (ikisi de Ollama üzerinde). Örneklem küçüktü; bir özetleme ve beş sınıflandırma. Bu yüzden sonuçları istatistik değil, yön gösterici olarak okumak gerekiyor.
- 7B kodlama modeli, sınıflandırmayı çağrı başına yarım saniyenin altında yaptı ve beş örneğin beşinde makul cevap verdi. Türkçe özette sayıları doğru aktardı ve "en fazla 4 madde" sınırına uydu.
- 9B "düşünen" model aynı işlerde onlarca saniye, bir denemede iki dakikayı aşkın süre harcadı. Bir kez boş cevap döndü, özet isteğinde de istenenin kat kat uzununu üretti.
Buradan çıkan pratik sonuç şu: kısa ve mekanik işler için "düşünme" modu olan modeller yanlış araç. Küçük, hızlı ve söz dinleyen bir model daha iyi iş görüyor. Düşünme modunu kapatmanın sonucu değiştirip değiştirmeyeceğini denemedim. Bu hâlâ açık bir soru.
İki kural da koydum. Yerel modelin çıktısı hiçbir zaman otomatik olarak "onaylı" sayılmıyor, yalnız öneri olarak bir sonraki adıma geçiyor. Ayrıca yerel model sunucusu kapalıysa araç onu kendiliğinden başlatmıyor, açık bir hata veriyor.
Token'ı nasıl sayacaksınız?
Bütçe koyabilmek için ölçmek gerekiyor. Sağlayıcının gerçek sayacı ağ ve API anahtarı istediği için, çevrimdışı bir tahmin yöntemi aradım. Türkçe bir örnek dosyada "bayt sayısı bölü 3" sezgiseli, açık kaynak tiktoken kütüphanesinin o200k_base sayımıyla neredeyse aynı sonucu verdi. Yine de bunun bir tahmin olduğunu unutmamak lazım. Asıl modelin sayacıyla çapraz doğrulama yapmadım. Pratikte iki sayıyı yan yana göstermek, tek ve yanıltıcı bir sayıdan daha dürüst.
Özet: nereden başlamalı?
- Bir haftalık araç çağrısı kaydını açın ve en sık tekrarlanan on işi sayın.
- Kurala bağlı olanları tek komutluk betiklere çevirin. Çıktıları kısa olsun.
- Açılış bağlamını bir token bütçesine sığdırın.
- Özet ve sınıflandırma gibi küçük anlama işlerini hızlı bir yerel modele verin, ama sonucu hep öneri olarak ele alın.
- Zor işi büyük modelde bırakın. Tasarruf, kaliteden ödün vermeden yapılabildiği yerde anlamlı.