GLM-5.3 Workers AI Modelinde İstekler Arası KV Önbellek Sızıntısı ve SGLang ile Çözümü (155 Yanıt)
Kaynak: Hacker News
İçindekiler 2 başlık
8 Eylül 2026 tarihinde, Knostic'ten güvenlik araştırmacısı Gadi Evron tarafından Cloudflare Workers AI üzerinde barındırılan GLM-5.3 (@cf/zai-org/glm-5.3) modelini etkileyen bir kiracı izolasyonu (tenant isolation) sorunu bildirildi. 27 Ağustos 2026'da başlayan bu sorun hızla giderildi ve model 9 Eylül'de tekrar devreye alındı. Yapılan incelemelerde Workers AI üzerindeki başka hiçbir modelin bu durumdan etkilenmediği doğrulandı.
27 Ağustos ile 9 Eylül tarihleri arasında GLM-5.3 modelini kullanan az sayıda müşteri, kendilerinden hemen önce aynı modele yapılan diğer müşteri isteklerine ait verileri içeren yanıtlar aldı. Toplamda 681.280 tokendan uzun istemlere (prompt) verilen 155 yanıt bu durumdan etkilendi. Araştırmacının ve Cloudflare'in kendi testleri hariç tutulduğunda, tespit edilen isteklerin zamanlama ve hacim açısından kasıtlı bir istismardan ziyade olağan uzun bağlam (long-context) kullanımıyla tutarlı olduğu görüldü. Kasıtlı bir saldırı veya istismara dair herhangi bir kanıt bulunmadı.
Bu rapor, kullanılan açık kaynaklı çıkarım (inference) motoru SGLang ekibinin yazısıyla eşgüdümlü bir açıklama (coordinated disclosure) olarak yayımlandı. Yazılım geliştirme ve LLM sunumu açısından kritik dersler barındıran bu olay; hatanın kök nedenini, müdahale sürecini ve üretim ortamındaki SGLang dağıtımlarında yapılan sıkılaştırma çalışmalarını detaylandırmaktadır.
Ne Oldu?#
Z.ai tarafından ajan tabanlı kodlama (agentic coding) iş akışları için geliştirilen GLM-5.3, Workers AI üzerinden sunulan metin üretim modellerinden biridir. Gadi Evron, 8 Eylül'de HackerOne programı aracılığıyla modele gönderilen çok uzun istemlerin bazen başka kullanıcıların oturumlarına ait metinler döndürdüğünü bildirdi. Cloudflare ekibi ertesi sabah sorunu yeniden üretti (reproduce) ve olay ilan edildikten sonraki 40 dakika içinde modeli çevrimdışı konuma getirdi. Ardından düzeltilmiş yapılandırma ve yamalanmış çıkarım motoru devreye alınarak servis aynı gün içinde yeniden kullanıma açıldı.
İstekler arası KV önbellek sızıntısına yol açan bu durum, birbiriyle örtüşen iki sorunun birleşimiyle meydana geldi:
- Yapılandırma Uyumsuzluğu ve Varsayımlar: İlk sorun, Cloudflare tarafından kullanılan açık kaynaklı SGLang çıkarım motorunun yanlış yapılandırılmasıydı. GLM-5.3 modeli 1.048.576 tokenlık bir bağlam penceresiyle (context window) devreye alınmıştı ancak ön doldurma (prefill) GPU'larındaki KV önbellek havuzunda yalnızca 681.280 token için yer vardı. Ekip lansmandan önce bu uyumsuzluğun farkındaydı ancak motorun işleyemediği uzunluktaki istemler için doğrudan hata döndüreceğini varsaymıştı. Uzun bağlam testleri de başarılı yanıtlar döndürdüğü için bunun bir sorun yaratmayacağı düşünüldü.
- Ayrıştırılmış Prefill/Decode Modunda SGLang Hatası: İkinci sorun, SGLang'in ayrıştırılmış (disaggregated) prefill/decode modunda kapasiteyi aşan bu istekleri işleme biçimindeki bir hataydı. Havuza sığmayan bir istem dahili olarak reddedildi şeklinde işaretlenip tek tokenlık bir yer tutucu (placeholder) ile değiştirildi. Ancak isteği iptal edip istemci hatası döndürmek yerine, prefill aşaması bu tek tokenlık yer tutucu için KV önbelleği oluşturdu ve bunu decode düğümüne aktardı. Decode düğümü "aktarım tamamlandı" mesajını aldığında, prefill aşamasının önceki isteklerden kalan KV önbelleğinin tamamını yeni istemle ezdiğini (üzerine yazdığını) varsaydı. Oysa önceki durumun büyük bir kısmı olduğu gibi kalmıştı. Sonuç olarak decode düğümü, hala önceki isteklerin verilerini tutan eski (stale) önbellek sayfaları üzerinden yanıt üretti ve 681.280 tokendan uzun istemlere verilen yanıtlarda diğer kullanıcıların oturum verileri sızdı.
Acil Müdahale ve Geliştiriciler İçin Çıkarımlar#
Model devre dışı bırakıldıktan hemen sonra hem yapılandırma düzeltildi hem de SGLang yamalandı. Bu olay, LLM altyapısı ve yazılım mühendisliği açısından şu kritik dersleri sunmaktadır:
- Sessiz Geri Dönüşlerden (Silent Fallbacks) Kaçının: Kapasite aşımı gibi sınır durumlarında (edge-case) sistemin isteği tek tokenlık bir yer tutucuya dönüştürerek devam etmesi yerine, hızlı ve açık bir şekilde hata vererek işlemi sonlandırması (fail-fast) gerekir.
- Bellek İzolasyonu ve Sıfırlama: Çok kiracılı (multi-tenant) GPU çıkarım sistemlerinde, paylaşılan KV önbellek sayfalarının yeni bir işleme tahsis edilmeden önce tamamen temizlendiğinden veya geçersiz kılındığından emin olunmalıdır.
- Test Kapsamı: Uzun bağlam testlerinde yalnızca yanıtın "başarılı" dönmesi değil, dönen içeriğin doğruluğu ve bellek sınırlarının üzerindeki davranışlar da doğrulanmalıdır.
Bu konuyu derinlemesine öğrenmek isterseniz: Ölçeklendirme ve Optimizasyon modülüne göz atın.
Kaynak ve atıf
Bu yazı, Hacker News üzerinde yayımlanan içerikten yararlanılarak Edumints tarafından yapay zekâ desteğiyle Türkçe hazırlandı. Ayrıntılar ve yazarların kendi anlatımı için orijinaline bakabilirsin:
- blog.cloudflare.com/kv-cache-exposure-remediation