Sade anlatım
Model yanıtını token token yazar. Streaming yokken uygulama son token yazılana kadar her şeyi bekletir, sonra metnin tamamını bir kerede gösterir. Streaming varken her parça oluştuğu anda iletilir; sohbet asistanlarında yanıtın gözünüzün önünde yazılıyormuş gibi görünmesinin nedeni budur. Model iki durumda da aynı hızda çalışır; siz yalnızca okumaya daha erken başlarsınız.
Neden önemli
Streaming, algılanan hızı artırmanın en ucuz yoludur: toplam süre aynı kalır, bir şey görünene kadar geçen bekleme saniyelerden yaklaşık bir saniyeye iner ve insanlar kötü giden bir yanıtı erkenden durdurabilir. Sohbette varsayılandır. Bedeli de vardır. Metin, kimse tamamını denetleyemeden kullanıcıya ulaşır; çıktı filtreleri bu yüzden akan metin üzerinde çalışmak ya da gösterilmiş kelimeleri geri almak zorunda kalır. Hatalar yanıtın ortasında gelebilir. Eksiksiz bir sonuca, örneğin bir JSON nesnesine ihtiyaç duyan programlar ise streaming'den bir şey kazanmaz.
Örnek
Bir hukuk araştırma asistanının 600 token'lık bir yanıtı yazması 12 saniye sürüyor. Streaming yokken avukat 12 saniye boyunca dönen bir simgeye bakıyor. Streaming varken ilk cümle 0,8 saniye sonra görünüyor ve metin akmaya devam ediyor; avukat 3 saniye sonra sorunun yanlış anlaşıldığını görüyor, yanıtı durduruyor ve soruyu yeniden yazıyor. Yanıtın tamamı yine 12 saniye sürecekti.
Bununla en çok karıştırılan kavram
Streaming ve Batch processing (toplu işleme) arasındaki fark
İkisi aciliyetin iki ucunda durur. Streaming, şu anda bekleyen ve yanıtın oluşmasını izlemek isteyen kişiye hizmet eder. Toplu işleme, kimsenin başında beklemediği işe hizmet eder: binlerce istek birlikte teslim edilir, saatler içinde tamamlanır ve çoğunlukla yarı fiyatına gelir. Veri mühendisliğinde “streaming ve batch” ayrımı başka bir şeyi, verinin iş hatlarından nasıl aktığını anlatır; buradaki konu ise model yanıtının nasıl iletildiğidir.
Teknik katman
Model API'lerinin çoğu server-sent events (SSE) üzerinden akış yapar: istemci bir streaming bayrağı açar, sunucu HTTP bağlantısını açık tutar ve her biri bir metin parçası taşıyan küçük olaylar gönderir; sonda durma nedenini ve token kullanımını bildiren bir olay gelir. Ses gibi çift yönlü, gerçek zamanlı arayüzler WebSocket ya da WebRTC kullanır. Geliştiricinin ele alması gerekenler: parçaları birleştirmek (son parça gelene kadar geçersiz kalan yarım araç çağrıları ve yarım JSON dahil); yanıtın ortasında kopan bağlantılar; yanıtı tamponlayıp akışı fark ettirmeden bozan proxy'ler ve gateway'ler; bir de iptal. Çoğu sağlayıcıda iptal üretimi durdurur ve yalnızca o ana kadar üretilen token'lar faturalanır. Moderasyon ve guardrail'ler akışı parça parça denetler ya da kısa bir tamponu bekletir. Faturalama, akışsız çağrıyla aynıdır. Streaming, kullanıcının yaşadığı ilk token süresini iyileştirir, toplam gecikmeyi değiştirmez. Sağlayıcılar uzun çıktılı isteklerde streaming önerir, çünkü model çalışırken boşta bekleyen bir bağlantı zaman aşımına uğrayabilir.