Framework'ler neden ölçekte tıkanıyor
Çoğu agent framework'ü tek bir çalışmayı modeller: bir LLM döngüsü araçları çağırır, bir transcript'e ekler ve bir durma koşulu sağlandığında sonlanır. Bu soyutlama bir notebook için yeterlidir ve üretimde yanıltıcıdır. Bir üretim sistemi tek bir çalışma değildir; aynı kıt kaynaklar için rekabet eden birçok eşzamanlı çalışmadır — model rate limit'leri, araç eşzamanlılığı, retrieval bant genişliği ve kuyruğu izleyen operatörlerin dikkati. Framework'ün işi bir çalışmayı tanımlamaktır. Sistemin işi hangi çalışmaların gerçekleşeceğine, hangi sırayla ve kimin pahasına olacağına karar vermektir.
Bunlar zamanlama problemleridir ve konteynerler için onlarca yıl önce çözülmüştür. Admission control bir isteğin kabul edilip, kuyruğa alınıp yoksa reddedilip edilmeyeceğine karar verir. Kotalar bir tenant'ın tüketebileceği kaynağı sınırlar. Preemption, daha yüksek öncelikli işe yer açmak için daha düşük öncelikli işi iptal eder. Back-pressure, bir şey devrilene kadar aşırı yükü absorbe etmek yerine yukarı akışa yayar. Bu kavramların hiçbiri Kubernetes ile ortaya çıkmadı, ancak Kubernetes onlara mühendislerin zaten anladığı bir sözlük ve bir API yüzeyi verdi.
Yakınsama araçlarda görünür. Google'ın açık kaynaklı AX orkestratörü, endüstrinin agent koordinasyonunu bir prompting problemi yerine bir control-plane problemi olarak ele aldığının bir işaretidir. İlginç mühendislik, agent'ları tanımlamak için yeni bir DSL değil; onların ne zaman çalışacağına karar veren zamanlayıcıdır.
Kontrol primitiflerini eşleme
Konteyner orkestrasyonundan agent orkestrasyonuna eşleme metaforik değildir. Yapısaldır ve faydalıdır.
Admission control
Bir çalışma gönderildiğinde, zamanlayıcı maliyetini projekte eder: beklenen token tüketimi, sınıfa göre araç çağrısı sayısı ve duvar saati süresi. Projeksiyon o tenant veya küme için kalan bütçeyi aşarsa, çalışma reddedilir veya kuyruğa alınır. Projeksiyonun kesin olması gerekmez; muhafazakâr ve ucuz olması gerekir. Basit bir mekanizma, prompt boyutundan, bildirilen araç setinden ve araç sınıfı başına tarihsel bir çarpandan türetilen çalışma başına maliyet tahminidir. Zamanlayıcı bu tahmini bir token bucket ile karşılaştırır. Bucket boşsa, çalışma bekler.
Bu, namespace'in izin verdiğinden daha fazla bellek isteyen bir pod'u reddeden bir Kubernetes admission webhook'u ile aynı mantıktır. Fark, kaynağın misli olmamasıdır: başarısız bir çalışmada harcanan token gitmiştir ve harici bir yan etkisi olan bir araç çağrısı geri alınamaz.
Kotalar
Kotalar dispatch'ten önce uygulanır, sonra değil. Bir tenant'ın üç bütçesi vardır: pencere başına token, sınıfa göre pencere başına araç çağrısı ve eşzamanlı çalışmalar. Zamanlayıcı admission anında üçünü de kontrol eder. Herhangi biri tükenmişse, çalışma başlatılmak yerine kuyruğa alınır. Bu kasıtlı olarak sıkıcıdır ve bir tenant'ın kontrolden çıkan döngüsünün diğer tüm tenant'ları aç bırakmasını önlemenin en etkili tek mekanizmasıdır.
Ödünleşim gecikmedir. Katı bir kota, kümenin boş kapasitesi olsa bile bir çalışmayı bekletir, çünkü kota global değil tenant başınadır. Alternatif — adil pay ağırlıklandırmalı global zamanlama — daha verimlidir ve akıl yürütmesi çok daha zordur. Çoğu ekip katı kotalarla başlamalı ve bunları yalnızca veriye sahip olduğunda gevşetmelidir.
Preemption
Preemption, framework'lerin nadiren uyguladığı ve üretim sistemlerinin sonunda gerektirdiği primitiftir. Yüksek öncelikli bir çalışma şu anda düşük öncelikli bir çalışma tarafından tutulan bir araca ihtiyaç duyduğunda, zamanlayıcı düşük öncelikli çalışmayı iptal edebilir ve aracı serbest bırakabilir. İptal edilen çalışma kaybolmaz, yeniden kuyruğa alınır.
Preemption güçlüdür ve tehlikelidir. Yalnızca preempt edilen çalışma yan etkileri tekrarlamadan bir checkpoint'ten devam ettirilebildiğinde güvenlidir. Bu koşul her zaman karşılanmaz, bu yüzden preemption ilk değil, en son tanıtılması gereken primitif olmalıdır.
Neyin aktarılmadığı
Agent çalışmalarının üç özelliği pod'lara temiz eşlemeyi bozar.
Agent çalışmaları stateless değildir. Bir pod öldürülüp yeniden zamanlanabilir çünkü durumu bir volume'da veya veritabanında yaşar. Bir agent çalışmasının durumu transcript'inde, araç çağrısı geçmişinde ve çalışma belleğinde yaşar. Checkpointing üçünü de yakalamalı ve devam ettirme zaten çağrılan araçlara göre idempotent olmalıdır. Bu gerçek 
Araç çağrılarının harici yan etkileri vardır. Bir çalışmayı araç çağrısının ortasında iptal etmek çağrıyı geri almaz. Bir ödeme, bir ticket, bir e-posta, bir veritabanı yazımı — bunlar kalıcıdır. Bu nedenle preemption yalnızca kalan işi yan etkisiz olan çalışmalar veya kompanzasyonu destekleyen araçlar için güvenlidir. Zamanlayıcının araç başına bir sınıflandırmaya ihtiyacı vardır: preempt etmek güvenli, kompanzasyonlu veya terminal. Bu sınıflandırma olmadan preemption, gerçekleşmeyi bekleyen bir doğruluk hatasıdır.
Observability trajectory'leri yakalamalıdır. Bir konteyner orkestratörü exit code'ları ve kaynak kullanımını önemser. Bir agent orkestratörü kararların sırasını önemser: hangi araç çağrıldı, hangi argümanlarla, ne döndü ve çalışma neden o dalı aldı. Exit-code observability yetersizdir çünkü bir çalışma yanlış şeyi yapmış olmasına rağmen başarıyla sonlanabilir. Zamanlayıcı her çalışma için yapılandırılmış bir trajectory kaydı yaymalıdır ve bu kayıt log satırı değil, debugging birimi olmalıdır.
Bir geçiş yolu
Ekiplerin ilk günden tam bir zamanlayıcı benimsemesine gerek yoktur. Yol kademelidir ve geri döndürülebilirdir.
Birinci adım: her çalışma için bir zamanlama kaydı yayın. Herhangi bir uygulamadan önce, sistemi kendini tanımlamaya zorla. Her çalışma öncelik, bütçe tahmini, bağımlılıklar ve araç sınıflarını içeren bir kayıt yayar. Bu kontrol değil observability'dir ve güvenlidir. Aynı zamanda keyfi olmayan kotalar belirlemek için gereken veriyi üretir.
İkinci adım: preemption'dan önce kotaları tanıt. Kotalar geri döndürülebilirdir: bir limite ulaşan tenant bekler ve limit yükseltilebilir. Preemption geri döndürülemez: iptal edilen bir çalışma zaten bir yan etkiye neden olmuş olabilir. Önce kotaları tanıt, kuyruk davranışını ölç ve ancak o zaman iptal edilmesi güvenli olan çalışma alt kümesi için preemption'ı düşün.
Üçüncü adım: zamanlayıcıyı maliyet ve politikanın buluştuğu tek yer olarak ele al. Admission mantığı API gateway'de, kota mantığı worker'da ve öncelik mantığı prompt'ta yaşıyorsa, hiç kimse bir çalışmanın neden beklediğini yanıtlayamaz. Kararı merkezileştirmek sistemi denetlenebilir ve politika değişikliklerini test edilebilir kılar. Zamanlayıcı, "bu çalışma neden başlamadı?" sorusunun yanıtına sahip olan bileşen haline gelir.
Dürüst ödünleşim
Bir zamanlayıcı gecikme ve yeni bir hata alanı ekler. Her çalışma bir admission kontrolü öder ve zamanlayıcıdaki bir hata tüm filoyu durdurabilir. Framework'ler bir control plane'e sahip olmayarak bundan kaçınır; problemi operatöre iterler. Bu küçük sistemler için meşru bir seçimdir. Eşzamanlı çalışmaların, tenant'ların veya araç sınıflarının sayısı manuel hakemliği imkânsız kıldığında meşru olmaktan çıkar. O noktada seçim bir framework ile bir zamanlayıcı arasında değil; açık bir zamanlayıcı ile retry mantığı, rate-limit işleme ve on-call yargısı arasına dağılmış kazara bir zamanlayıcı arasındadır.
Açık bir zamanlayıcı inşa etmesi daha zor ve işletmesi daha kolaydır. Ödünleşim budur. Üretimdeki agent sürüleri için doğru olan budur.