Günlük kanarya testi, bazı LLM API rotalarının binlerce gizli input token eklediğini ortaya çıkardı

107 rota boyunca 90 token'lık bir kanarya

LLM API'lerini listeleyip istekleri bunlara yönlendiren bir servis olan UplinkSwitch, her gün kataloğundaki her modelin her rotasına yaklaşık 90 token'lık sabit bir prompt gönderiyor ve her rotanın döndürdüğü usage.prompt_tokens değerini kaydediyor. Şirketin dev.to'daki yazısına göre temiz bir rota, bu prompt için mesajın kendisi artı chat-template yükü dahil 76 ile 127 arasında input token bildiriyor. Yüzlerce ya da binlerce yanıt veren bir rota, çağıran tarafın hiç göndermediği metni sayıyor demektir.

12 Ekim 2026'da kontrol, adı açıklanmayan dört sağlayıcıdaki 107 rotayı kapsadı ve bunlardan en az 30'u 200'den fazla input token bildirdi. Dağılım genişti. En büyük sağlayıcıda 66 rotanın 17'si eşiği aştı; GPT rotaları yaklaşık 4.469, Gemini rotaları 352 ve bir Gemini rotası 2.213 bildirdi. İkinci bir sağlayıcıda 32 rotanın 11'i eşiğin üzerindeydi; bunlar arasında 4.280 ile 4.469 arasındaki GPT rotaları, 380 ve 540 değerindeki Claude rotaları, 289'daki bir Grok rotası ve 1.325'teki bir Grok 4.7 rotası vardı. Yazıya göre geliştiricinin kendi ağırlıkları yerine üçüncü taraf değiştirilmiş sürümleri sunan o sağlayıcıdaki iki GLM rotası, örneklemdeki en yüksek değer olan 14.111 input token bildirdi. Sekiz rotalı bir sağlayıcıda 8.938'de bir GPT rotası vardı ve tek rotalı bir sağlayıcı 1.171 bildirdi.

UplinkSwitch, aynı modellerin diğer rotalardan ulaşılınca yaklaşık 89 token bildirdiğini ve GPT değerlerinin iki ayrı sağlayıcıda 4.469 civarında kümelenttiğini belirtiyor.

Ödediğiniz bir önek

Yazıya göre en basit açıklama, sağlayıcının her isteğe, modele ulaşmadan önce kendi system prompt'unu eklemesi. Modelin tokenizer'ı bu metni sayar ve token başına fiyatlanan bir API'de müşteri her çağrıda bunun bedelini öder. Aritmetik çarpıcı: 300 token'lık bir isteğe eklenen 4.400 token'lık bir önek, input faturasının yüzde 93'ünü oluşturur ve daha kısa isteklerde eklenen metin gerçek yükü çok geride bırakır.

Böyle bir uygulama yalnızca faturalandırmayı değil, model davranışını da değiştirirdi. Çağıran tarafın system prompt'u artık context window'daki ilk şey olmazdı ve ondan önceki talimatlar başka birine ait olurdu.

Yazı bilinçli olarak temkinli: hiçbir sağlayıcı adlandırılmıyor, yazar bulguları bir suçlamadan başka bir şey olarak çerçeveliyor ve şişmiş bir sayımın başka nedenleri de olabilir. Temel iddia, etkinin ölçülebilir olduğu ve ölçümünün neredeyse hiçbir şeye mal olmadığı.

Kendi sağlayıcınızı nasıl test edebilirsiniz

Önerilen prosedür tek bir istek gerektiriyor. max_tokens 1 olarak ayarlanmış minimal bir prompt gönderin ve yanıttaki usage.prompt_tokens değerini okuyun. Birkaç token, prompt artı chat template'tir; yüzlerce ya da binlerce, sağlayıcının bir şey eklediğini gösterir. Aynı çağrıyı aynı model için birinci taraf bir endpoint'e yapmak bir taban çizgisi verir. Kontrolü her gün tekrarlayıp sayıları kaydetmek, bir rotanın ne zaman değiştiğini ortaya çıkarır.

UplinkSwitch buna yanıt olarak kendi servisini de ayarladığını söylüyor: bir rota ne bildirirse bildirsin müşterilerden, isteklerinin içerebileceğinden daha fazla input token için ücret alınmıyor, günlük kararlar herkese açık bir proof endpoint'i üzerinden yayınlanıyor ve bir rotanın kendi prompt'undan daha küçük istekler artık önce daha temiz bir rotaya gönderiliyor.

Ölçümün sınırları

Yazı kendi uyarılarını da listeliyor. Bir sayım yalnızca rotanın bildirmeyi seçtiği şeydir; dolayısıyla temiz bir sayım, rotanın adını verdiği modeli çalıştırdığını kanıtlamaz; aynı aileden daha küçük bir model ya da quantize edilmiş ağırlıklar bu şekilde görünmez. Günde rota başına tek örnek de örnekler arasında değişen her şeyi kaçırır. Yazar, sonuçların kanıt değil kanı oluşturduğunu söylüyor.

Ayrıca yayıncının hem ölçümü yürüttüğünü hem de sorunu hafifleten yönlendirme servisini işlettiğini, yani sayıların çıkar sahibi bir taraftan geldiğini belirtmek gerekir. Ancak yöntem, herkesin bağımsız olarak yeniden üretebileceği kadar basit.

Neden önemli

Token başına fiyatlandırma, yalnızca token sayımlarının anlamlı olduğu kadar anlamlıdır. Bir rota kendi metninden binlerce token'ı sessizce ekleyebiliyorsa, liste fiyatları neredeyse anlamsızlaşır: 90 token'lık bir prompt için 4.500 input token faturalandıran bir rotadaki ucuz token fiyatı, dürüstçe sayan daha pahalı bir rotadan çok daha maliyetli olabilir. Gizli önekler ayrıca context window alanını tüketir ve bir geliştiricinin özenle sıralanmış talimatlarını yerinden eder; bu da model çıktısını hata ayıklaması zor şekillerde değiştirebilir. Daha geniş çıkarım şu: token muhasebesi tek bir istekle denetlenebilir ve bütçe ya da üçüncü taraf API sağlayıcıları kullanan geliştiriciler bu kontrolü rutin hale getirmeli.