LLM ajan performansı aslında bir dağıtık sistem problemi

FixBugs ekibi, bug raporlarını, logları, kodu ve ekran görüntülerini işleyen bir AI debug ajanı geliştirirken LLM çağrılarının gecikmesini bir dağıtık sistemler problemi gibi ele almanın gerektiğini fark etmiş. Yazı önce 'time to first token' ile toplam token verimini ayırıyor: girdi tokenleri prefill aşamasını, dolayısıyla ilk yanıt süresini etkilerken, çıktı tokenleri decode hızına bağlı. Debug ajanları genelde çıktı ağırlıklı olduğu için bu ayrım kritik hale geliyor.

En büyük darboğaz, hangi dosyaların bug ile ilgili olduğunu tek bir devasa promptla sormakmış. Bu yaklaşım 50 dosyalık bir repoda ~10 dakika sürerken, dosyaları bağımsız parçalara bölüp 16 paralel çağrıyla işlemek bu süreyi ~40 saniyeye indirmiş; klasik MapReduce mantığının LLM ajanlarına uygulanmasına iyi bir örnek. Ancak 'reduce' aşaması -log kayıtlarını zaman sırasına, span'e veya servise göre birleştirmek- basit 'chunk' işleminden çok daha zorlu olabiliyor.

Streaming, kullanıcı deneyimini büyük ölçüde iyileştiriyor (TTFT 13 saniyeden 2.4 saniyeye düşüyor) ama toplam token verimini düşürebiliyor (486'dan 244 tok/s'ye); bu yüzden FixBugs kullanıcıya dönük aşamalarda streaming, arka plan işçi aşamalarında toplam iş tamamlama süresini kullanıyor. Ayrıca eşzamanlılığın da bir tavanı olduğu, belli bir noktadan sonra paralel işçi eklemenin toplam throughput'u pek artırmadığı ama bireysel kullanıcı gecikmesini kötüleştirdiği vurgulanıyor. Son olarak, çok aşamalı ajan iş akışlarında (analiz, tekrar üretme, kök neden, düzeltme, doğrulama) senkron bir istek zinciri yerine olay kuyruklarıyla bağımsız aşamalar kullanmanın sistemi daha dayanıklı hale getirdiği anlatılıyor.