چرا فریم‌ورک‌ها در مقیاس متوقف می‌شوند
بیشتر فریم‌ورک‌های ایجنت یک اجرای واحد را مدل می‌کنند: یک حلقه LLM ابزارها را فراخوانی می‌کند، به یک رونوشت اضافه می‌کند و وقتی شرط توقف برآورده شود خاتمه می‌یابد. این انتزاع برای یک نوت‌بوک کافی است و در تولید گمراه‌کننده. یک سیستم تولیدی یک اجرا نیست؛ بسیاری از اجراهای همزمان است که برای منابع کمیاب یکسان رقابت می‌کنند — محدودیت‌های نرخ مدل، همزمانی ابزار، پهنای باند بازیابی، و توجه اپراتورهایی که صف را تماشا می‌کنند. کار فریم‌ورک توصیف یک اجرا است. کار سیستم تصمیم‌گیری درباره این است که کدام اجراها اتفاق بیفتند، به چه ترتیبی، و به هزینه چه کسی.
اینها مسائل زمان‌بندی هستند و دهه‌ها پیش برای کانتینرها حل شده‌اند. کنترل پذیرش تصمیم می‌گیرد که یک درخواست پذیرفته، صف‌بندی یا رد شود. سهمیه‌ها منابعی را که یک مستأجر می‌تواند مصرف کند محدود می‌کنند. پیش‌دستی کارهای کم‌اولویت‌تر را لغو می‌کند تا جا برای کارهای با اولویت بالاتر باز شود. فشار معکوس اضافه‌بار را به بالادست منتقل می‌کند به جای جذب آن تا زمانی که چیزی سقوط کند. هیچ‌یک از این مفاهیم از Kubernetes سرچشمه نگرفته، اما Kubernetes به آنها واژگان و سطح API داد که مهندسان از قبل می‌فهمند.
همگرایی در ابزارها قابل مشاهده است. ارکستراتور AX متن‌باز گوگل نشانه‌ای است که صنعت هماهنگی ایجنت را به عنوان یک مسئله صفحه کنترل در نظر می‌گیرد نه یک مسئله پرامپت. مهندسی جالب یک DSL جدید برای توصیف ایجنت‌ها نیست؛ زمان‌بندی است که تصمیم می‌گیرد چه زمانی اجرا شوند.
نگاشت ابزارهای کنترلی
نگاشت از ارکستراسیون کانتینر به ارکستراسیون ایجنت استعاری نیست. ساختاری است و مفید.
کنترل پذیرش
وقتی یک اجرا ارسال می‌شود، زمان‌بند هزینه آن را پیش‌بینی می‌کند: مصرف مورد انتظار توکن، تعداد فراخوانی‌های ابزار بر اساس کلاس، و مدت زمان واقعی. اگر پیش‌بینی از بودجه باقی‌مانده برای آن مستأجر یا برای خوشه فراتر رود، اجرا رد یا صف‌بندی می‌شود. پیش‌بینی نیازی به دقت ندارد؛ باید محافظه‌کارانه و ارزان باشد. یک مکانیسم ساده تخمین هزینه هر اجرا است که از اندازه پرامپت، مجموعه ابزار اعلام‌شده و یک ضریب تاریخی برای هر کلاس ابزار مشتق می‌شود. زمان‌بند آن تخمین را با یک سطل توکن مقایسه می‌کند. اگر سطل خالی باشد، اجرا منتظر می‌ماند.
این همان منطق یک وب‌هوک پذیرش Kubernetes است که پادی را رد می‌کند که بیش از حد مجاز فضای نام حافظه درخواست می‌کند. تفاوت این است که منبع غیرقابل‌تعویض است: توکنی که برای یک اجرای ناموفق خرج شده از بین رفته، و یک فراخوانی ابزار با عوارض جانبی خارجی قابل بازگرداندن نیست.
سهمیه‌ها
سهمیه‌ها قبل از ارسال اعمال می‌شوند، نه بعد از آن. یک مستأجر سه بودجه دارد: توکن در هر پنجره، فراخوانی ابزار در هر پنجره بر اساس کلاس، و اجراهای همزمان. زمان‌بند هر سه را در زمان پذیرش بررسی می‌کند. اگر هر یک تمام شده باشد، اجرا صف‌بندی می‌شود نه شروع. این عمداً خسته‌کننده است و مؤثرترین مکانیسم برای جلوگیری از گرسنگی سایر مستأجرها توسط حلقه فراری یک مستأجر است.
معاوضه تأخیر است. یک سهمیه سخت باعث می‌شود یک اجرا حتی وقتی خوشه ظرفیت اضافی دارد منتظر بماند، زیرا سهمیه به ازای هر مستأجر است نه جهانی. جایگزین — زمان‌بندی جهانی با وزن‌دهی سهم عادلانه — کارآمدتر و بسیار سخت‌تر برای استدلال است. بیشتر تیم‌ها باید با سهمیه‌های سخت شروع کنند و تنها زمانی که داده دارند آنها را شل کنند.
پیش‌دستی
پیش‌دستی ابزاری است که فریم‌ورک‌ها به ندرت پیاده‌سازی می‌کنند و سیستم‌های تولیدی در نهایت نیاز دارند. وقتی یک اجرای با اولویت بالا به ابزاری نیاز دارد که در حال حاضر توسط یک اجرای کم‌اولویت‌تر نگه داشته شده، زمان‌بند می‌تواند اجرای کم‌اولویت‌تر را لغو کند و ابزار را آزاد کند. اجرای لغوشده دوباره صف‌بندی می‌شود، نه از دست می‌رود.
پیش‌دستی قدرتمند و خطرناک است. تنها زمانی ایمن است که اجرای پیش‌دست‌شده بتواند از یک نقطه بازرسی بدون تکرار عوارض جانبی از سر گرفته شود. این شرط همیشه برآورده نمی‌شود، به همین دلیل پیش‌دستی باید آخرین ابزار معرفی‌شده باشد، نه اولین.
چه چیزی منتقل نمی‌شود
سه ویژگی اجراهای ایجنت نگاشت تمیز به پادها را می‌شکند.
اجراهای ایجنت بی‌حالت نیستند. یک پاد می‌تواند کشته و دوباره زمان‌بندی شود زیرا حالت آن در یک حجم یا پایگاه داده زندگی می‌کند. حالت یک اجرای ایجنت در رونوشت، تاریخچه فراخوانی ابزار و حافظه کاری آن زندگی می‌کند. نقطه‌گذاری باید هر سه را ثبت کند و از سرگیری باید نسبت به ابزارهای قبلاً فراخوانی‌شد
فراخوانی‌های ابزار عوارض جانبی خارجی دارند. لغو یک اجرا در میانه فراخوانی ابزار آن فراخوانی را باطل نمی‌کند. یک پرداخت، یک تیکت، یک ایمیل، یک نوشتن در پایگاه داده — اینها باقی می‌مانند. بنابراین پیش‌دستی تنها برای اجراهایی ایمن است که کار باقی‌مانده‌شان بدون عارضه جانبی است، یا برای ابزارهایی که از جبران پشتیبانی می‌کنند. زمان‌بند به یک طبقه‌بندی برای هر ابزار نیاز دارد: ایمن برای پیش‌دستی، قابل جبران، یا پایانی. بدون آن طبقه‌بندی، پیش‌دستی یک باگ صحت در انتظار وقوع است.
قابلیت مشاهده باید مسیرها را ثبت کند. یک ارکستراتور کانتینر به کدهای خروج و مصرف منابع اهمیت می‌دهد. یک ارکستراتور ایجنت به توالی تصمیمات اهمیت می‌دهد: کدام ابزار فراخوانی شد، با چه آرگومان‌هایی، چه چیزی برگشت، و چرا اجرا آن شاخه را انتخاب کرد. قابلیت مشاهده کد خروج ناکافی است زیرا یک اجرا می‌تواند با موفقیت خارج شود در حالی که کار اشتباهی انجام داده است. زمان‌بند باید یک رکورد مسیر ساختاریافته برای هر اجرا منتشر کند و آن رکورد باید واحد اشکال‌زدایی باشد، نه خط لاگ.
یک مسیر مهاجرت
تیم‌ها نیازی نیست در روز اول یک زمان‌بند کامل اتخاذ کنند. مسیر تدریجی و برگشت‌پذیر است.
گام یک: برای هر اجرا یک رکورد زمان‌بندی منتشر کنید. قبل از هر اعمالی، سیستم را وادار کنید خودش را توصیف کند. هر اجرا رکوردی شامل اولویت، تخمین بودجه، وابستگی‌ها و کلاس‌های ابزار منتشر می‌کند. این قابلیت مشاهده است، نه کنترل، و ایمن است. همچنین داده‌های لازم برای تعیین سهمیه‌های غیر دلبخواهی را تولید می‌کند.
گام دو: سهمیه‌ها را قبل از پیش‌دستی معرفی کنید. سهمیه‌ها برگشت‌پذیر هستند: مستأجری که به محدودیت می‌رسد منتظر می‌ماند و محدودیت می‌تواند افزایش یابد. پیش‌دستی برگشت‌پذیر نیست: یک اجرای لغوشده ممکن است قبلاً عارضه جانبی ایجاد کرده باشد. ابتدا سهمیه‌ها را معرفی کنید، رفتار صف را اندازه‌گیری کنید و تنها سپس پیش‌دستی را برای زیرمجموعه‌ای از اجراها که ایمن برای لغو هستند در نظر بگیرید.
گام سه: زمان‌بند را به عنوان تنها جایی که هزینه و سیاست به هم می‌رسند در نظر بگیرید. اگر منطق پذیرش در دروازه API، منطق سهمیه در کارگر و منطق اولویت در پرامپت باشد، هیچ‌کس نمی‌تواند پاسخ دهد چرا یک اجرا منتظر ماند. متمرکز کردن تصمیم سیستم را قابل حسابرسی و تغییرات سیاست را قابل آزمون می‌کند. زمان‌بند به مؤلفه‌ای تبدیل می‌شود که پاسخ به «چرا این اجرا شروع نشد؟» را در اختیار دارد.
معاوضه صادقانه
یک زمان‌بند تأخیر و یک دامنه خرابی جدید اضافه می‌کند. هر اجرا هزینه یک بررسی پذیرش را می‌پردازد و یک باگ در زمان‌بند می‌تواند کل ناوگان را متوقف کند. فریم‌ورک‌ها با نداشتن صفحه کنترل از این اجتناب می‌کنند؛ آنها مسئله را به اپراتور هل می‌دهند. این یک انتخاب مشروع برای سیستم‌های کوچک است. زمانی مشروع بودن را متوقف می‌کند که تعداد اجراهای همزمان، مستأجرها یا کلاس‌های ابزار داوری دستی را غیرممکن کند. در آن نقطه انتخاب بین یک فریم‌ورک و یک زمان‌بند نیست؛ بین یک زمان‌بند صریح و یک زمان‌بند تصادفی پراکنده در منطق تلاش مجدد، مدیریت محدودیت نرخ و قضاوت در زمان فراخوان است.
یک زمان‌بند صریح سخت‌تر برای ساخت و آسان‌تر برای عملیات است. این معاوضه است. برای ازدحام‌های ایجنت در تولید، انتخاب درست است.