هزینهی توکن از کنترل خارج شده؟ راهحل، روتینگ هوشمنده
هوش مصنوعیخلاصهٔ کاملتر
نویسنده با این نکته شروع میکنه که یه درخواست تکی به یه مدل زبانی معمولاً ارزونه، ولی یه ایجنت که روی همون مدل ساخته شده اصلاً ارزون نیست. دلیلش دو چیزه: ایجنت بهجای یه فراخوانی، کلی فراخوانی میکنه و معمولاً همهشون رو هم به گرونترین مدلهای موجود میفرسته.
به گفتهی مقاله، ریشهی گرونی تو ماهیت «حلقهی ایجنت»ـه. ایجنت تسک رو میخونه، یه اکشن مثل اجرای ابزار یا خوندن فایل انجام میده، به نتیجه نگاه میکنه و تصمیم میگیره قدم بعدی چیه. چون خود مدل حافظهی مستقل نداره، تو هر قدم باید همهچیز، یعنی دستورها، سؤال، اسکیمای ابزارها، فراخوانیها و نتیجههاشون و حتی فکرکردن میانی مدل، دوباره تو کانتکست بستهبندی و فرستاده بشه. برای همین کانتکست هر قدم بزرگتر میشه و فراخوانیهای آخر میتونن بالای صد هزار توکن حمل کنن.
نویسنده میگه چون نمیشه واقعاً توکن کمتری فرستاد، تنها چیزی که میتونی عوضش کنی اینه که کدوم مدل اون توکنها رو دریافت کنه؛ و کارِ روتینگ دقیقاً همینه. یه روتر به هر درخواست نگاه میکنه، تصمیم میگیره کدوم مدل بهقدر کافی خوبه و درخواست رو همونجا میفرسته. یه روتر دو چیز لازم داره: یه نقطهی ورود واحد که فرمت درخواست رو استاندارد کنه و به همهی پروایدرها ترجمهش کنه، و یه لایهی تصمیم که بگه هر درخواست به کدوم مدل بره.
به گفتهی مقاله، لایهی تصمیم دو روش داره. روش اول روتینگ روی یه سیگنالیه که از قبل داری: اگه سیستم بدونه نوع کار چیه، نوع کار رو به یه مدل نگاشت میکنه؛ این روش قابلاعتماد و تقریباً رایگانه چون فقط یه lookupـه. روش دوم پیشبینی سختی کار از روی خود متن درخواسته که حتی بدون سیگنال قبلی هم کار میکنه، ولی باید از داده یاد گرفته بشه و بهروز نگه داشته بشه و یه حدس اشتباه میتونه یه کار سخت رو به مدل ضعیف بفرسته.
نویسنده برای ملموسشدن بحث، مطالعهی موردی شرکت Kilo رو میاره که یه ایجنت کدنویسی متنباز داره و کل ترافیکش رو از یه لایهی روتینگ به اسم Kilo Gateway رد میکنه. این گیتوی جلوی بیش از پونصد مدل یه فرمت درخواست واحد میذاره. Kilo از روش اول استفاده میکنه: ایجنتش همیشه میدونه تو چه مودیه (planning، نوشتن کد، دیباگ) و همون مود رو با هر درخواست میفرسته؛ گیتوی هم مود رو به یه مدل نگاشت میکنه. این مود یه سیگنال قابلاعتماد از سختی کاره. روتینگ تو تیرهایی سازماندهی شده که کاربر انتخاب میکنه؛ مثلاً تیر بالا کارهای سنگین مثل planning رو به قویترین مدل و ویرایش معمولی کد رو به یه مدل ارزونتر میفرسته.
طبق عددهایی که Kilo از ترافیک واقعی سهماههی اول ۲۰۲۶ منتشر کرده، وقتی بهجای انتخاب دستی مدل، خود گیتوی روتینگ میکرد، میانگین هزینهی هر درخواست حدود یکسوم کم شد. Kilo فهمیده ۸۰ تا ۹۰ درصد درخواستها اصلاً مدل فرانتیر نمیخوان. غافلگیری بزرگتر این بود که برای کار یکسان، تیر ارزون «balanced» بیش از ده برابر کمتر از تیر بالا هزینه داشت. مقاله به یه مطالعهی مشهور از UC Berkeley و Anyscale هم اشاره میکنه که توش روتر حدود نصف هزینه رو کم کرد و در عین حال ۹۵٪ کیفیت مدل فرانتیر رو حفظ کرد.
نویسنده چندتا درس کلی میگیره: برای کل بار کاری یه بودجهی ماهانهی ثابت بذار و هدف رو «بیشترین کار مفید تو اون بودجه» بدون، نه کمترین قیمت هر درخواست؛ قبل از بهینهسازی اندازه بگیر، یعنی توکن هر درخواست رو لاگ کن و با نوع کار و فیچر فرستنده برچسب بزن؛ و روی قویترین سیگنالی که از قبل داری روتینگ کن. به گفتهی اون، روتینگ دیگه فقط یه بهینهسازی هزینه نیست، بلکه داره به چیزی تبدیل میشه که اصلاً تعیین میکنه اجرای یه ایجنت بلندپروازانه ممکن و مقرونبهصرفه هست یا نه.
نکات کلیدی:
- ایجنتها چون کانتکست رو هر قدم دوباره میفرستن، توکن زیادی میسوزونن
- روتینگ یعنی فرستادن هر درخواست به ارزونترین مدلی که از پسش برمیاد
- میشه روی سیگنالی که از قبل داری (مثل مود کار) روتینگ کرد یا سختی رو از متن پیشبینی کرد
- در عمل ۸۰ تا ۹۰ درصد درخواستها به مدل فرانتیر نیاز ندارن
- روتینگ تو مطالعات تا حدود نصف هزینه رو با حفظ کیفیت کم میکنه
