LLM Çıktı Akışı (Streaming): Canlıda Isıran Uç Durumlar
- Akışlı ve yapısal çıktı (JSON) birlikte kullanıldığında basit metin birleştirici değil, artımlı (incremental) ayrıştırıcı gerekir.
- Akış ortasındaki hatalar şeffafça kaldığı yerden yeniden denenemez; kısmi sonuç yönetimi için tasarım yapın.
- Token düzeyinde akış insan arayüzleri içindir; sunucu tarafı makineden makineye işlemlerde çıktıyı sonuna kadar tamponlayın.
- İstemci sekmesini kapattığında sunucu tarafı model çağrısını iptal etmezseniz kimsenin okumadığı tokenların parasını ödersiniz.
Yapay zeka özelliğine token akışı (streaming) ekleyen bir ekip, kısa süre içinde destek kutusunun “asistan bana yarım cevap verdi” şikayetleriyle dolduğunu gördü. İncelediğimizde üç hatanın birleştiğini bulduk: sağlayıcı tarafındaki zaman aşımları, yük dengeleyicideki ağ sıfırlamaları ve henüz tamamlanmamış JSON çıktısını standart JSON.parse ile okumaya çalışan ön yüz kodu.
Temel kural basittir: çıktıyı bir insan izliyorsa akıtın (stream); bir makine tüketiyorsa tamamlanana kadar tamponlayın (buffer). İnsan arayüzlerinde akışı üretime hazır hale getirmek stream=True parametresinden çok daha fazlasını gerektirir.
Uç Durum 1 ve 2: Parçalı JSON ve Akış Ortası Kopmalar
Modelden JSON istediğinizde ve yanıtı token token akıttığınızda standart ayrıştırıcılar metin bitene kadar hata verir. Çözüm ya metni arayüze düz yazı olarak akıtıp yalnızca akış bittiğinde JSON.parse çağırmak ya da gerçek zamanlı kart güncellemesi gerekiyorsa partial-json-parser gibi artımlı (incremental) bir ayrıştırıcı kullanmaktır.
İkinci kritik tuzak akış ortası kopmalardır. Model 600 token ürettikten sonra bağlantı koparsa, hiçbir LLM sağlayıcısı “600. tokendan devam et” özelliğini desteklemez. Yeniden deneme sıfırdan başlayan yeni bir istektir. En tehlikeli hata, yeni denemenin çıktısını eski yarım yanıtın sonuna sessizce eklemektir; kullanıcı ekranda cümlenin ortasında kendiyle çelişen bozuk bir metin görür. İlk kopmada tamponu sıfırlayarak bir kez yeniden deneyin; yine koparsa kullanıcıya açıkça bildirin.
Uç Durum 3 ve 4: Geri Basınç ve İptal Edilen Akışlarda Token Sızıntısı
Sunucu tarafı akış hatlarında üretici (model) tüketiciden hızlıysa tamponlar şişer; ara durumları atlayarak (throttling) veya sınırlı tamponla geri basınç uygulayın. Son olarak, kullanıcı uzun bir yanıt sırasında tarayıcı sekmesini kapattığında (request.is_disconnected()), sunucunun sağlayıcı SDK’sındaki cancel/abort sinyalini tetiklediğinden emin olun. İptal sinyali bağlanmamış sistemlerde LLM faturasının %10 ila %20’sinin kapatılmış sekmelerdeki hayalet akışlardan geldiğini defalarca gördük.
Sıkça sorulan sorular
Streaming eklediği bu karmaşıklığa gerçekten değiyor mu?
Sohbet tarzı arayüzler için kesinlikle evet; ilk token 200-500 ms içinde belirdiğinde algılanan gecikme keskin biçimde düşer. Ancak makineden makineye arka plan hatlarında genellikle değmez; tamamlanana kadar tamponlayıp tek seferde ayrıştırın.
Yapısal JSON çıktısını güvenli bir şekilde akıtabilir miyim?
Evet, kısmi nesneleri işleyebilen durum makinesi tabanlı artımlı (incremental) bir JSON ayrıştırıcı ile mümkündür. Standart JSON.parse tam metin beklediği için her tokenda hata fırlatır.
Model akışın ortasında durursa ne yapılmalı?
Ağ kopması, sağlayıcı zaman aşımı veya token sınırı nedeniyle bu sık yaşanır. Alınan kısmı kaydedin, kesilmeyi loglayın ve ya baştan temiz bir yeniden deneme yapın ya da kullanıcıya 'yanıt yarım kaldı, tekrar denensin mi?' seçeneği sunun.