Ortalama iyi görünüyordu: bir yıllık LLM servis izi

Kapasite raporlarının en sevilen grafiği toplam istek eğrisidir. Tek çizgi, düzgün bir trend, yönetim sunumuna hazır. Temmuz başında arXiv'e düşen bir çalışma, o tek çizginin neyi sakladığını bir yıllık üretim verisiyle gösteriyor.

Kaynağı baştan net koyayım. Çalışma arXiv:2608.13573: "A Year in LLM Serving: Workload Evolution, Caching and Load-Balancing". Nixon, Durbin, Standhartinger, Gunawi ve Yang imzalı; ilk sürümü 3 Temmuz 2026'da yayımlandı. İki şerhi baştan düşüyorum. Birincisi: bu bir preprint, hakem denetiminden geçmedi. İkincisi: iz tek bir sağlayıcıdan geliyor; serverless bir LLM çıkarım platformu olan Chutes'un üretim trafiği bu. Künye izi Chutes'a bağlarken makale gövdesi şirketi anonim anıyor; beş yazardan ikisi bu şirkette çalışıyor. Bulguları sektör ortalaması olarak değil, bir sağlayıcının bir yıllık deseni olarak oku.

Ne oldu

Ölçek, istek sayısında ve model çeşitliliğinde yazarların karşılaştırma tablosundaki önceki izlerin hepsinden büyük: 11 Nisan 2025 ile 12 Nisan 2026 arasında 6,12 milyar istek, 314.970 kullanıcı, 9.174 model; örneklenmemiş, istek düzeyinde kayıt. Yazarlar izi makaleyle birlikte yayımlayacaklarını söylüyor.

Merkez bulgu tek cümle: toplam görünüm, model ve kullanıcı düzeyindeki yapıyı saklıyor.

Yıl içinde günlük aktif model sayısı 100'ün altından zirvede 400'ün üstüne çıkıyor. Baskın modeller el değiştiriyor: yılın başında trafiğe hükmeden modeller sona doğru geriliyor, "diğerleri" dilimi büyüyor. Çıktılar kısalıyor; aylık medyan çıktı, izin başındaki birkaç yüz token'dan sona doğru 100 token'ın altına iniyor. Girdi medyanı toplamda binler mertebesinde stabil duruyor; ama kullanıcılar katılım tarihine göre ayrıştırılınca yeni kohortların daha uzun prompt gönderdiği görülüyor. Yani aynı istek sayısı, yılın başında ve sonunda aynı iş yükü demek değil.

Kullanıcı tarafı da tekdüze değil. Modellerin çoğu, yoğun kullanılanlar dahil, trafiğinin büyük bölümünü az sayıda kullanıcıdan alıyor. Kullanıcıların çoğu birkaç modelde yaşarken küçük bir güç kullanıcısı kuyruğu çok sayıda modele istek dağıtıyor; yazarlar bunların otomasyon, model yönlendirici veya ajan iş yükleri olabileceğini not ediyor. Önbellek deseni çarpıcı: bir isteğin cache isabeti ya sıfıra ya tama yakın, arası neredeyse boş. Aynı kullanıcı-model çiftinin tekrar isteklerinin yüzde 99'u, önceki isteğin 15 dakikası içinde geliyor. Ve web dünyasından taşınan gelişmiş cache politikaları, yazarların iz üzerinde koştuğu simülasyonlarda çoğu zaman en basit FIFO ve LRU ile ya benzer sonuç veriyor ya onların gerisine düşüyor.

Neden önemli

Türkiye'de kurumsal AI harcaması büyüdükçe kapasite ve bütçe kararları bu tür izlerle verilecek. Tehlike şu: LLM kapasite planlaması, servis yönetiminin yıllar önce düştüğü çukura yeni bir kılıkla düşmek üzere. Tek ortalama, tek trend, tek pano.

Makalenin tespiti net: kısa ölçüm pencereleri kapasite planlaması için yetersiz. Gerekçesi bulguların kendisinde. Bir yıl içinde baskın modeller el değiştiriyor, istek karakteri kayıyor; yük model ve kullanıcı ekseninde ayrı ayrı yapı taşıyor. Bir aylık pilot ölçümüyle yıllık GPU bütçesi bağlayan kurum, yıl ortasında baskın modelin değiştiği ve istek profilinin kaydığı bir gerçekle karşılaşabilir.

Saha yorumum: ortalama, mağduru saklar

20+ yıllık servis yönetimi tecrübem tek cümleye iner: ortalama, mağduru saklar. Aylık raporda ortalama yanıt süresi hedefin altındayken, kritik bir servisin müşterisi o ay kesinti yaşamış olabilir. Bu yüzden rapora ortalamayı tek başına koymam: yanında yüzdelik dilimler, servis bazlı kırılım ve en kötü on olay durur. Makalede beni durduran şey, aynı refleksin LLM operasyonuna bire bir taşınması: uzun kuyruktaki modeller, seyrek ama ısrarlı kullanıcılar, patlamalı trafik. Hepsi toplam eğride görünmez; faturada ve gecikmede görünür.

İç katmandan bir gözlem ekleyeyim, dış bulguyla karıştırmadan. Kendi makinemde tamamen yerel çalışan bir LLM düzeneği işletiyorum. Orada da ders aynıydı: ortalama cevap süresini ölçseydim düzenek sağlıklı görünürdü. Sorunlar olay düzeyinde çıktı. Bekleme süresi dolduğunda model bellekten düşüyor, sonraki istek soğuk başlıyor. Bağlam penceresi aşıldığında girdi sessizce kırpılıyor, cevap hatasız ama eksik dönüyor. İkisi de log satırında görünüyor, ortalamada görünmüyor. Bu tek makinelik bir PoC gözlemi; makalenin bir yıllık iziyle aynı terazide tartılmaz. Ama ikisinin işaret ettiği yön aynı: yapı, ortalamanın altında yaşar.

Ne yapmalı

Üç somut adım:

• Panoya kırılım ekle: LLM maliyet ve kapasite panonda tek toplam eğri varsa yanına model bazında ve ekip bazında kırılımı koy. Ortalamanın yanına P90 ve P99'u yaz.
• Ölçüm pencerene güvenme: bu iz, istek karakterinin yıl içinde değiştiğini gösteriyor. Pilot dönemin ölçümünü yıllık plana çevirmeden önce çeyrek başlarında ölçümü tazele.
• Basitten başla: tekrar kısa pencerede yoğunlaşıyor ve yazarların simülasyonunda basit cache politikaları çoğu zaman yetti. Süslü çözüm satın almadan önce kendi izinde ölç.

Asıl soru şu: panondaki o tek sağlıklı eğri, hangi ekibin kötü gününü saklıyor?