۵. هزینه، تأخیر و جدول معیارها

هزینه و تأخیر

مدلی که خروجی باکیفیت می‌دهد ولی کند و گران است، به کار نمی‌آید. خیلی از شرکت‌ها آگاهانه مدل ضعیف‌تری را انتخاب می‌کنند چون ارزان‌تر و سریع‌تر است. بهینه‌سازی هم‌زمان چند هدف شاخه‌ای به اسم بهینه‌سازی پارتو است. اولین قدمش روشن کردن این است که روی چه چیزی نمی‌شود کوتاه آمد: اگر تأخیر خط قرمز است، اول مدل‌هایی را که به تأخیر لازم نمی‌رسند حذف کنید، بعد از بقیه بهترین را بردارید.

برای تأخیر چند سنجه هست: زمان تا اولین توکن (TTFTTime To First Tokenزمان تا اولین توکن)، زمان هر توکن (TPOTTime Per Output Tokenزمان به‌ازای هر توکن خروجی)، زمان بین توکن‌ها، زمان کل هر پرسش و… بدانید کدام برایتان مهم است. تأخیر فقط به مدل بستگی ندارد؛ به پرامپت و تنظیمات نمونه‌برداری هم. مدل‌های زبانی توکن‌به‌توکن تولید می‌کنند، پس خروجی بلندتر یعنی انتظار بیشتر. با پرامپت («کوتاه جواب بده»)، شرط توقف (فصل ۲) و روش‌های فصل ۹ می‌شود کنترلش کرد.

هزینه هم دو حالت دارد. API‌ها به‌ازای توکن پول می‌گیرند — توکن ورودی و خروجی بیشتر، هزینهٔ بیشتر. اگر مدل را خودتان میزبانی کنید، هزینه (غیر از نیروی مهندسی) محاسبه است. خیلی‌ها بزرگ‌ترین مدلی را برمی‌دارند که روی دستگاهشان جا شود؛ کارت‌های گرافیک معمولاً ۱۶، ۲۴، ۴۸ یا ۸۰ گیگابایت حافظه دارند و تصادفی نیست که خیلی از مدل‌های محبوب ۷ یا ۶۵ میلیارد پارامتر دارند. نکتهٔ مهم: هزینهٔ هر توکن در API با بزرگ شدن مقیاس تقریباً ثابت می‌ماند، ولی در میزبانی خودتان ارزان‌تر می‌شود — خوشه‌ای که روزی یک میلیارد توکن می‌تواند سرو کند، چه یک میلیون سرو کند چه یک میلیارد، همان هزینه را دارد. پس در هر مقیاس باید دوباره پرسید کدام به‌صرفه‌تر است.

همه با هم: جدول معیارها

این نمونهٔ کتاب از جدول معیارهای یک اپلیکیشن خیالی است. هر ردیف یک شرط سخت دارد (کمتر از آن قبول نیست) و یک حالت ایده‌آل:

«صدک ۹۰» یعنی ۹۰٪ درخواست‌ها از این عدد سریع‌ترند — میانگین ممکن است چند درخواست خیلی کند را پنهان کند. ردیف «مقیاس» مخصوصاً برای API‌ها مهم است: سرویسی لازم دارید که حجم شما را تحمل کند. در پروژهٔ این فصل، جدول شرط‌های سخت ذهن‌یار را دقیقاً به همین شکل در کد می‌نویسیم.

خودآزمایی