اگر محصولی مبتنی بر مدل‌های زبانی بزرگ عرضه می‌کنید، حاشیه سود شما تنها به اندازه لیست قیمت ارائه‌دهنده شما پایدار خواهد بود. Novita و StreamLake هر دو اخیراً قیمت‌گذاری مدل‌های خود را به‌روزرسانی کرده‌اند، و این بدان معناست که اقتصاد واحد (unit economics) شما، چه متوجه شده باشید و چه نه، تغییر کرده است. این‌ها پنجره‌های تعمیر و نگهداری معمول نیستند. وقتی ارائه‌دهندگان استنتاج (inference)، نرخ هر توکن خود را تغییر می‌دهند، هزینه طبقه‌بندی یک تیکت پشتیبانی، خلاصه‌سازی یک سند یا تولید یک پیشنهاد کد، یک‌شبه تغییر می‌کند. توسعه‌دهندگانی که قیمت‌گذاری API را به عنوان یک نویز پس‌زمینه ثابت در نظر می‌گیرند، معمولاً تنها زمانی متوجه مشکل می‌شوند که صورت‌حساب ماهانه‌شان از راه می‌رسد.

چرا یک تغییر قیمت بی‌سروصدا می‌تواند بودجه را از هم بپاشد

اکثر تیم‌های مهندسی یک ارائه‌دهنده استنتاج را انتخاب می‌کنند، چند بنچمارک تأخیر (latency) را اجرا می‌کنند و سپس به کار خود ادامه می‌دهند. قالب‌های پرامپت (prompt templates) در سیستم کنترل نسخه ثبت می‌شوند، کد کلاینت وارد مرحله تولید می‌شود و تیم مالی یک برآورد ماهانه تقریبی دریافت می‌کند. این گردش کار تا زمانی کار می‌کند که دیگر کار نکند. توکن‌ها یک منبع مصرفی هستند. صورت‌حساب شما با پذیرش کاربر، طول کانتکست (context length) و رفتار تلاش مجدد (retry behavior) مقیاس‌پذیر می‌شود. افزایش نرخی که در یک صفحه گسترده (spreadsheet) جزئی به نظر می‌رسد، می‌تواند حاشیه سود یک قابلیت با حجم بالا را از بین ببرد.

تأثیر آن کاملاً به الگوی مصرف شما بستگی دارد. تیمی که پرامپت‌های طبقه‌بندی کوتاه ارسال می‌کند، ممکن است بدون تغییر در ساختار، با تعدیل قیمت کنار بیاید. تیمی که پنجره‌های کانتکست طولانی را پردازش می‌کند یا کارهای دسته‌ای (batch jobs) را روی هزاران صفحه اجرا می‌کند، ممکن است شاهد افزایش سریع نرخ سوخت سرمایه (burn rate) خود باشد. یک تغییر درصد یکسان، بسته به اینکه میانگین فراخوانی شما دویست توکن باشد یا بیست هزار توکن، تأثیر متفاوتی خواهد داشت. دقیقاً به همین دلیل است که به‌روزرسانی‌های Novita و StreamLake نیازمند بررسی دقیق هستند. شما باید بدانید که آیا میانگین هزینه شما به ازای هر کاربر از پیش‌بینی‌هایتان خارج شده است یا خیر، و آیا زمان تغییر مسیر ترافیک فرا رسیده است یا نه.

به‌روزرسانی قیمت‌گذاری Novita

Novita اخیراً قیمت مدل‌های خود را تعدیل کرده است. این پلتفرم دسترسی به طیفی از مدل‌های زبانی را فراهم می‌کند و هرگونه تغییر در آن مستقیماً بر هزینه‌های عملیاتی تیم‌هایی که از آن به عنوان لایه اصلی استنتاج استفاده می‌کنند، تأثیر می‌گذارد. از آنجایی که Novita میزبان مدل‌های متعددی است، این به‌روزرسانی ممکن است در کل کاتالوگ یکسان نباشد. ممکن است قیمت یک خانواده از مدل‌ها ثابت بماند در حالی که خانواده‌ای دیگر تغییر کند. این جزئیات بیشتر از آنچه یک اعلامیه کلی نشان می‌دهد، اهمیت دارد.

اگر تمام ترافیک خود را از طریق یک شناسه مدل (model ID) واحد هدایت کنید، محاسبه هزینه پیش‌بینی‌شده جدید آسان است. اگر از کاتالوگ Novita به صورت پویا استفاده می‌کنید (یعنی هدایت پرامپت‌های پیچیده به مدل‌های بزرگ‌تر و پرامپت‌های ساده به مدل‌های کوچک‌تر)، میانگین هزینه ترکیبی شما ممکن است به گونه‌ای تغییر کرده باشد که هیچ هشدار تک‌گویه‌ای آن را توضیح ندهد. تنها راه دانستن این است که لاگ‌های مصرف خود را استخراج کنید، آن‌ها را بر اساس مدل گروه‌بندی کنید و تعداد توکن‌های واقعی را در نرخ جدید ضرب کنید. به حافظه خود در مورد قیمت قبلی هر میلیون توکن اعتماد نکنید. آن را یادداشت کنید. یک سابقه تاریخی نگه دارید. آن را به بخشی از چرخه بررسی فصلی خود تبدیل کنید تا تغییر بعدی شما را غافلگیر نکند.

به‌روزرسانی قیمت‌گذاری StreamLake

StreamLake نیز به‌روزرسانی قیمت مدل‌های خود را اعمال کرد. برای تیم‌هایی که با پشته (stack) این سرویس یکپارچه شده‌اند، هرگونه تعدیل در نرخ توکن‌ها، محاسبات مربوط به تحلیل محتوا، بک‌اندهای تبدیل گفتار به متن (transcription)، قابلیت‌های مولد یا هر بار کاری زبانی دیگری که از طریق این پلتفرم اجرا می‌شود را تغییر می‌دهد. اندازه مطلق این تعدیل در درجه دوم اهمیت نسبت به اثر مرکب قرار دارد. حتی یک افزایش اندک در هر توکن، زمانی که روزانه میلیون‌ها توکن را در محیط‌های مختلف پردازش می‌کنید، قابل توجه می‌شود.

سوال واقعی این نیست که قیمت جدید چقدر است، بلکه این است که آن قیمت جدید چه تأثیری بر حاشیه سود ناخالص شما به ازای هر قابلیت دارد. اگر StreamLake قدرت‌بخش یک ابزار خلاصه‌سازی مشتری‌محور یا یک لایه نظارت (moderation) داخلی باشد، هزینه کالای فروخته‌شده (COGS) شما همین حالا تغییر کرده است. شما باید آن هزینه را به وضوح در ابزارهای مشاهده‌پذیری (observability) خود جداسازی کنید. آن فراخوانی‌های API را بر اساس ارائه‌دهنده و قابلیت برچسب‌گذاری کنید تا وقتی صورت‌حساب رسید، بتوانید آن را به دقت تقسیم کنید. اگر یک مورد استفاده از حالت سودده خارج شده است، باید داده‌های لازم را در اختیار داشته باشید تا تصمیم بگیرید آیا آن را محدود (throttle) کنید، به یک مدل کوچک‌تر کاهش دهید، یا آن را به عنوان یک هزینه استراتژیک بپذیرید.

چگونه هزینه‌های استنتاج خود را حسابرسی کنید

پذیرش