İlk Token Süresi (TTFT)

İlk token süresi (time to first token), bir LLM'e istek gönderilmesi ile yanıtının ilk token'ının alınması arasındaki gecikmedir. Prefill aşamasının egemenliğindedir — model bir şey üretebilmek için önce girdinin tamamını işlemek zorundadır — bu yüzden TTFT prompt uzunluğuyla büyür: 50 token'lık bir soru neredeyse anında yanıtlanırken, 100 bin token'lık bir bağlamda ilk kelimenin görünmesi saniyeler alabilir. Token'lar arası gecikmeden (ilkinden sonraki token'ların temposu) ayrı ölçülür ve ikisi kullanıcı deneyimini farklı biçimlendirir: TTFT arayüzün ne kadar süre donmuş hissettirdiğini, token'lar arası hız ise akışın ne kadar akıcı hissettirdiğini belirler. TTFT'yi düşürmenin pratik kaldıraçları: prompt önbellekleme (ortak bir öneki yeniden işlemeyi atlamak), getirilen bağlamı kırpmak, kısa sorguları daha küçük modellere yönlendirmek ve çıktı var olduğu anda kullanıcıya göstermek için akışla (streaming) sunmak. Algılanan hız, çoğu zaman toplam tamamlanma süresinden daha önemlidir. İki açıklama, TTFT'nin yanlış okunmasını engeller. Toplam yanıt gecikmesiyle aynı şey değildir: bir model hızlı başlayıp uzun bir yanıtı tamamlamakta hâlâ çok vakit alabilir; bir başkası yavaş başlayıp başladıktan sonra hızla bitirebilir — dolayısıyla yalnızca toplam gecikmeye bakılarak verilen bir ürün kararı çoğu zaman deneyimin yanlış yarısını iyileştirir. Ayrıca sadece model boyutunun bir fonksiyonu da değildir. Altyapı tercihleri — toplu işleme stratejisi, donanım kuşağı, önceki turdan bir KV önbelleğinin yeniden kullanılıp kullanılamayacağı — TTFT'yi hangi modeli seçtiğinizden bağımsız olarak belirgin biçimde oynatır; aynı modelin bir sağlayıcıda ağır, başka birinde anlık hissettirmesinin nedeni budur. Pratik kaldıraç prefill ilişkisidir: ilk token görünmeden önce prompt'un tamamı işlenmek zorunda olduğundan TTFT girdi uzunluğuyla büyür ve önbelleğe alınmış önek durumunu yeniden kullanmak, bu prefill maliyetini iki kez ödememenin en etkili tek yoludur. Prompt ve bağlam önbelleklemesinin görünmez bir optimizasyon değil de fiyatlandırılmış bir ürün özelliği olarak var olmasının sebebi tam da bu bağlantıdır. Sohbet ve ses arayüzlerinde metrik neredeyse belirleyicidir — hiçbir çıktı görünmeden geçen süre, yavaş ama başlamış bir çıktının asla vermediği bir tepkisizlik hissi verir — bu yüzden gecikme panolarınızda uçtan uca süreden ayrı bir satır olarak yer almalı ve ortalama yerine yüksek bir yüzdelik dilimde ölçülmelidir, çünkü özelliğin nasıl algılandığını isteklerin yavaş kuyruğu biçimlendirir. Ürün tarafında birkaç ucuz hile de işe yarar: kullanıcı beklerken bir yükleniyor göstergesi yerine kısmi bir durum mesajı göstermek, uzun bir bağlamı arka planda önceden ısıtmak veya ilk cümleyi daha küçük bir modelden alıp gerisini büyük modele devretmek algılanan TTFT'yi ölçülen değerden bağımsız olarak iyileştirir. Ölçülen ile algılanan gecikme aynı şey değildir ve kullanıcı yalnızca ikincisini yaşar.