چرا هزینهها سر به فلک کشید
وقتی تیم برای اولین بار هوش مصنوعی مولد را اضافه کرد، هر درخواست کاربر را به جدیدترین و توانمندترین مدل میفرستاد. با افزایش ترافیک، هزینههای هر درخواست نیز به همان نسبت بالا رفت و در جدول محاسبات مدیر مالی (CFO)، مشخص شد که میزان هزینهها از رشد کاربران پیشی گرفته است. راهکار سریع معمول — «فقط از یک مدل ارزانتر استفاده کن» — در محیط عملیاتی (production) شکست میخورد، زیرا پرسوجوهای مختلف به سطوح استدلال متفاوتی نیاز دارند. اهرم اصلی، نحوه ارسال درخواست است، نه اینکه همیشه از کدام مدل استفاده شود.
ساخت یک لایه مسیریابی برای کاهش هزینهها
مهندس با سرویس استنتاج (inference service) مانند هر بخش عملیاتی دیگری برخورد کرد: تعیین سطوح (tiers)، تنظیم SLAها و اعمال محدودیتهای تأخیر (latency budgets). معماری حاصل دارای چهار بخش متحرک است که در کنار هم، ۹۵٪ کاهش هزینه را رقم میزنند.
مسیریابی سطحی (Tiered routing)
یک فرانتاند سبک، هر درخواست ورودی را بر اساس میزان دشواری دستهبندی میکند. تقریباً ۹۵٪ پرسوجوها در یک سطح «ارزان» قرار میگیرند که یک مدل معمولی را اجرا میکند؛ تنها ۵٪ از سختترینها به یک مدل پرمیوم (premium) ارتقا مییابند. این دستهبندی میتواند مبتنی بر قانون (مثلاً طول متن، وجود کلمات کلیدی تخصصی) یا یادگرفتهشده از دادههای تاریخی ارتقا باشد. با تنظیم پیشفرض روی سطح کمهزینه، هزینه ماهانه چتبات از ۴۲۰ دلار به ۲۸ دلار کاهش یافت.
انتخاب مدل متناسب (Model right-sizing)
تطبیق توانمندی مدل با پیچیدگی وظیفه، بیشترین میزان صرفهجویی را به همراه دارد:
- Simple chat (چت ساده) – استفاده از یک مدل سبک به جای مدل پرچمدار (۹۷.۵٪ صرفهجویی).
- Classification (دستهبندی) – جایگزینی یک مدل میانرده با یک جایگزین ارزانتر (۹۸.۳٪ صرفهجویی).
- Summarization (خلاصهسازی) – جایگزینی مدل سطح بالا با یک مدل میانرده (۹۷.۲٪ صرفهجویی).
نام دقیق مدلها حیاتی نیست؛ اصل کار این است که توانمندترین مدل را برای معدود پرسوجوهایی که واقعاً به آن نیاز دارند، ذخیره نگه داریم.
کشینگ هوشمند (Smart caching)
هر بار که داده از کش (cache hit) خوانده میشود، یک فراخوانی شبکه و یک هزینه API حذف میگردد. یک کش توزیعشده Redis، پاسخهای موفق و همچنین پاسخهای «منفی» (مانند «نمیدانم») را ذخیره میکند. وقتی همان سوال بیپاسخ دوباره تکرار شود، سیستم به جای فراخوانی مجدد مدل، همان پاسخ ذخیرهشدهی «نمیدانم» را برمیگرداند. در طی هزاران درخواست، این کار به تنهایی بخش قابل توجهی از صورتحساب را کاهش میدهد.
فشردهسازی پرامپت (Prompt compression)
پرامپتهای طولانی باعث افزایش مصرف توکن میشوند که مستقیماً به هزینه تبدیل میشود. تیم یک خلاصهساز ارزان را در سمت کلاینت یا در مرحله پیشپردازش اجرا میکند تا یک متن ۲۰۰۰ توکنی را پیش از رسیدن به مدل گرانقیمت، به حدود ۴۰۰ توکن کاهش دهد. کاهش توکنها در تمام درخواستها ضرب میشود و بدون تغییر در تجربه کاربر نهایی، صرفهجویی عظیمی ایجاد میکند.
دستهبندی استراتژیک (Strategic batching)
دستهبندی (Batching)، چندین درخواست مستقل را در یک فراخوانی API واحد گروهبندی میکند. قاعده کلی ساده است: اگر کاربر منتظر پاسخ است، دستهبندی نکنید؛ اگر درخواست در پسزمینه اجرا میشود (گزارشهای شبانه، کارهای زمانبندی شده)، همه چیز را دستهبندی کنید. تنها کارهای دستهای شبانه، ۱۰ تا ۲۰ درصد دیگر از هزینهها را کاهش میدهد.
نظارت بر چرخه بهینهسازی
چیزی را که اندازهگیری نمیکنید، نمیتوانید بهبود دهید. مهندس چهار معیار هفتگی را تنظیم کرد: