Barındırılan LLM endpoint'leri model kartına bakılmaksızın context'i sessizce 32K'da kesebiliyor, geliştirici raporluyor

Gönderinin iddia ettikleri

dev.to'da yazan bir geliştirici, açık ağırlıklı modeller için barındırılan endpoint'lerin, model kartlarında yazılı olandan çok daha küçük bir context penceresi sunduğunu sıkça gözlemlediğini bildiriyor. Grunz adlı barındırılan bir sohbet ve kodlama agent'ı geliştiren yazar, test edilen endpoint'lerin çoğunun yaklaşık 32K token sunduğunu, birkaçının 256K'ya ulaştığını ve hiçbirinin sürüm duyurularında yer alan 1M token rakamlarını gerçekte sunmadığını söylüyor.

Gönderinin yaptığı ayrım, ağırlıkların desteklediği context uzunluğu ile bir operatörün sunmayı seçtiği uzunluk arasındaki farka dair. Yazar, sınırlamanın kendisini savunulabilir buluyor: KV-cache belleği context uzunluğuyla büyüyor ve eşzamanlılığı dengeleyen bir sağlayıcı için her isteğe azami uzunlukta context sunmak sürdürülebilir olmazdı. Sorun, gönderinin ortaya koyduğu şekliyle, etkin limitin neredeyse hiçbir zaman belgelenmemesi ve bu limitin aşılmasının hiçbir hata üretmemesi.

Kendini hiç belli etmeyen kesme

Gönderiye göre, izin verilenden büyük bir istek 413 döndürmüyor ya da uyarı vermiyor. İstek, hangi tavan düşükse ona göre karşılanıyor ve context'in başlangıcı haber verilmeksizin atılıyor. Bir sohbet ürününde bu durum, modelin uzun bir konuşma boyunca kademeli olarak tutarlılığını yitirmesi olarak görünür ve çoğu kişi bunu modelin kendisine atfeder.

Agent'lar için gönderi daha yıkıcı bir örüntü tanımlıyor: uzun bir build çalışması tavana ulaşır, compaction devreye girer, özgün hedef ifadesi belirsiz bir şeye özetlenir ve model ardından kendi sıkıştırılmış notlarından çalışır, ne yaptığına dair hassasiyetini yitirir ve hiçbir sinyal vermeden planını yeniden başlatır. Görünür belirti, uzun görevlerde kötü görünen bir modeldir; asıl neden ise serving yapılandırmasıdır.

Gerçek tavanı tespit etmek

Yazarın deneyimine göre ne sağlayıcı belgeleri ne de model kartları bu konuda güvenilirdi ve gönderi iki manuel yöntem öneriyor. İlki, bilerek çok büyük bir prompt göndermek — örneğin 1M iddia eden bir endpoint'e 500K token — ve hata metnini incelemek; bu metin, belgelerde geçmese bile çoğu zaman gerçek azami değeri ortaya çıkarır. İkincisi, uzun bir çalışmada en eski içeriğin çıktıyı etkilemeyi bıraktığı noktayı bulmak ve ardından geriye sayarak kesmenin nerede başladığını tahmin etmek.

Zincirleme etkileri

Gönderi üç sonuç çıkarıyor. Benchmark'lar, bir modeli soyut anlamda değil, belirli bir sunulan context uzunluğunda ölçer; çünkü aynı ağırlıklar 32K'da ile 200K'da farklı davranır. Bu nedenle sunulan tavanı sabitlemeden sağlayıcıları token başına fiyat üzerinden karşılaştırmak eşdeğer bir karşılaştırma değildir.

İkincisi, fallback yönlendirmesi yapan gateway'ler tavanı oturum ortasında değiştirebilir. 200K'lık bir sağlayıcıda başlayan ve 32K'lık birine geçen bir çalışma hata vermez, keser; böylece bir kapasite detayı, yanıtta hiçbir şeyin ortaya çıkarmadığı sessiz bir doğruluk sorununa dönüşür.

Üçüncüsü, model kartındaki varsayılan bir bütçeye göre ayarlanmış RAG pipeline'ları sessizce geçersiz hale gelebilir. Chunk boyutu, top-k ve reranking gibi retrieval parametreleri 128K için ayarlanmışsa ama gelen sadece 32K ise sistem aşırı retrieve eder, üst chunk'lar kesilir ve yanıtlar yanıltıcı bir otoriteyle, yanlış bir şekilde gelir; bu da ekipleri, hiç suçu olmayan embedding modellerini yeniden ayarlamaya yönlendirir.

Neden önemli

Bulgular sistematik bir araştırmadan değil, tek bir operatörün testlerinden geliyor; ancak barındırılan açık ağırlıklı modeller üzerine inşa yapan herkesin kontrol edebileceği ve etmesi gerektiği, duyurulan ile sunulan context arasındaki doğrulanabilir bir boşluğa işaret ediyorlar. Yazarın kapanış talebi, sağlayıcılardan her istek için etkin sunulan context'i model metadata'sı ya da bir response header'ı aracılığıyla açığa çıkarmaları; bunu her istemciye hata dizilerinden tersine mühendislik yaptırmak yerine. Buna benzer bir şey var olana kadar, benchmark yapmadan, retrieval ayarlamadan veya fiyat karşılaştırmadan önce gerçek tavanı ölçmek, her şey gibi görünen ama aslında öyle olmayan arızalara karşı ucuz bir güvencedir.