«تخمین بیش از حد هزینه»؛ عاملی برای فروپاشی عملیات مدل‌های زبانی

تصور کنید برای جلوگیری از یک صورت‌حساب پنج‌رقمی، کل کارخانه خود را با یک شیر اطمینان حساس مجهز کرده‌اید، اما حالا همین شیر در عادی‌ترین شرایط، جریان تولید را کاملاً قطع می‌کند. این دقیقاً همان اتفاقی است که برای سرویس Klorn رخ داد؛ جایی که یک سیستم کنترل هزینه، به جای محافظت از بودجه، به یک کلید خاموش‌کن (Kill-switch) تبدیل شد.

به نقل از گزارش منتشر شده در ۱۸ آگوست ۲۰۲۶، توسعه‌دهنده فاش کرد که یک باگ در تطبیق رشته‌های متنی (Substring matching) در جدول قیمت‌ها باعث شد سرویس طبقه‌بندی ایمیل‌های این شرکت به‌طور کامل از دسترس خارج شود، در حالی که هزینه واقعی مصرف‌شده حتی به یک دلار هم نرسیده بود.

بسیاری از توسعه‌دهندگان به سقف هزینه (Cost Cap) به چشم یک ابزار حسابداری ساده نگاه می‌کنند؛ یعنی سقفی تعیین می‌کنید و وقتی بودجه تمام شد، سیستم متوقف می‌شود. اما در محیط‌های عملیاتی، این سقف یک وابستگی زمان-اجرا (Runtime dependency) است. هر درخواست ارسالی باید ابتدا از این سقف اجازه عبور بگیرد تا بتواند ادامه یابد. این چالش مدیریت بودجه در لحظه، یادآور راهکارهای مشابهی است که پلتفرم Burnix برای جلوگیری از جهش‌های ناگهانی هزینه‌های LLM به کار گرفته است.

این وضعیت شبیه به یک شیر اطمینان روی لوله است؛ اگر نشت کند، شما مقداری آب (پول) از دست می‌دهید. اما اگر کالیبراسیون آن چنان بد باشد که در جریان عادی بسته شود، کل کارخانه (Uptime) متوقف می‌شود. این تفاوت میان «شکست باز» (Failing open) و «شکست بسته» (Failing closed) است.

زمینه: معماری سقف هزینه

سرویس Klorn هر ایمیل ورودی را دقیقاً در یکی از چهار سطح طبقه‌بندی می‌کند. هر عملیات طبقه‌بندی مستلزم یک فراخوانی مدل زبانی بزرگ (LLM) است. از آنجا که حجم ایمیل‌ها خارجی و غیرقابل کنترل است، توسعه‌دهنده سه سقف مجزا در فایل packages/api/src/config.ts تعریف کرده بود تا از هزینه‌های خارج از کنترل جلوگیری کند:

• DAILY_COST_CAP_CENTS: یک دلار برای هر کاربر در روز.
• FREE_DAILY_COST_CAP_CENTS: ۱۰ سنت در روز برای سطح رایگان.
• GLOBAL_DAILY_COST_CAP_CENTS: ۵۰ دلار در روز برای کل ناوگان سرویس.

در حالی که سقف‌های هر کاربر به عنوان محافظ اصلی عمل می‌کنند، سقف جهانی به عنوان «آخرین خط دفاعی در برابر صورت‌حساب‌های مرگبار» طراحی شده بود. هدف این بود که اگر یک حلقه تکرار بی‌نهایت (Runaway loop) رخ داد، توسعه‌دهنده هنگام خواب با صورت‌حسابی پنج‌رقمی بیدار نشود.

مکانیسم‌های اندازه‌گیری (Metering)

از آنجا که صورت‌حساب‌های لحظه‌ای (Real-time invoices) از سوی ارائه‌دهندگان در دسترس نیستند، سیستم نمی‌تواند یک صورت‌حساب واقعی را در لحظه اندازه‌گیری کند. در عوض، هزینه را با ضرب تعداد توکن‌ها در نرخ هر مدل تخمین می‌زند و سپس این مقدار را در یک دفتر کل (Ledger) جمع می‌کند.

این دفتر کل به‌طور کامل به یک جدول نگاشت (Mapping table) متکی است که شناسه‌های مدل (Model IDs) را به قیمت‌ها مرتبط می‌کند. تمام بخش‌های پایین‌دستی به این جدول اعتماد می‌کنند. اگر این جدول غلط باشد، سیستم محافظتی یا بی‌فایده است یا مخرب. در واقع، تکیه بر مدل‌های توکن-محور برای کنترل هزینه‌ها در سیستم‌های حساس، محدودیت‌های ساختاری دارد؛ موضوعی که Oxlo.ai با جداسازی هزینه استنتاج از توکن‌ها برای اتوماسیون صنعتی سعی در حل آن داشت.

شکست اول: زیر-تخمین هزینه (Under-Billing)

در ابتدا، سیستم از یک نرخ واحد برای تمام مدل‌های پولی استفاده می‌کرد که تقریباً با قیمت‌های Gemini Flash همخوانی داشت. این موضوع یک شکاف خطرناک ایجاد کرد؛ زمانی که سیستم به مدل‌های گران‌تری مثل Claude Sonnet سوییچ می‌کرد (که هزینه ورودی آن ۱۰ برابر و هزینه خروجی آن ۶ برابر بیشتر است)، دفتر کل هزینه‌ای بسیار کمتر از واقعیت را ثبت می‌کرد.

در این سناریو، سقف هزینه هرگز فعال نمی‌شد و محافظت صرفاً جنبه تزئینی داشت. این همان حالت شکستی است که اکثر مهندسان پیش‌بینی می‌کنند: زیر-تخمین هزینه که منجر به ضررهای مالی غیرمنتظره می‌شود.

شکست دوم: حرکت در جهت «ایمن»

برای رفع این مشکل، توسعه‌دهنده یک سیاست «ایمن» را اجرا کرد: هر مدل ناشناخته‌ای باید به‌طور پیش‌فرض با نرخ گرانِ Sonnet محاسبه شود. در کد، یک DEFAULT_MODEL_RATE معادل ۳.۰۰ دلار برای ورودی و ۱۵.۰۰ دلار برای خروجی به ازای هر میلیون توکن تعریف شد. منطق این بود که بیش-تخمین رایگان است؛ زیرا فقط باعث می‌شود بودجه زودتر از حد لازم تمام شود. اگر توسعه‌دهنده اشتباه می‌کرد، اشتباهش در جهتی بود که هزینه را زودتر متوقف کند، نه دیرتر.

اما مشکل اینجا بود که Klorn از یک زنجیره مدل‌های جایگزین (Fallback) از نوع SKUهای واقعاً ارزان استفاده می‌کرد (زمانی که مدل‌های اصلی با محدودیت نرخ مواجه می‌شدند یا از دسترس خارج می‌شدند). این مدل‌ها نه تنها «ارزان‌تر»، بلکه چنان ارزان بودند که کل محاسبات را تغییر می‌دادند. چون جدول قیمت‌ها از تطبیق رشته‌ای (Substring matching) استفاده می‌کرد — جایی که اولین ردیفی که «کلمه کلیدی» در شناسه مدل پیدا شود برنده است — این مدل‌های ارزان به‌اشتباه شناسایی شدند یا به نرخ پیش‌فرض گران برخورد کردند:

• openai/gpt-oss-120b: نرخ واقعی ۰.۰۳۷/۰.۱۷ دلار $ \rightrightarrows $ محاسبه شد ۲.۵۰/۱۰.۰۰ دلار (به دلیل تطبیق با ردیف کلی "gpt"). این یک بیش-تخمین حدود ۶۷ برابری برای ورودی و ۵۹ برابری برای خروجی بود.
• qwen/qwen3.7-flash: نرخ واقعی ۰.۰۳/۰.۱۳ دلار $ \rightrightarrows $ محاسبه شد ۳.۰۰/۱۵.۰۰ دلار (برخورد به پیش‌فرض Sonnet). این یک بیش-تخمین حدود ۱۰۰ برابری برای ورودی و ۱۱۵ برابری برای خروجی بود.
• mistralai/mistral-nemo: نرخ واقعی ۰.۰۱۹/۰.۰۳ دلار $ \rightrightarrows $ محاسبه شد ۲.۰۰/۶.۰۰ دلار (تطبیق با ردیف کلی "mistral"). این یک بیش-تخمین حدود ۱۰۵ برابری برای ورودی و ۲۰۰ برابری برای خروجی بود.

ریاضیات یک قطعی (Outage)

در مقیاس ۱۰۰ کاربر که روزانه ۱۰۰ ایمیل پردازش می‌کنند، سیستم ۱۰,۰۰۰ عملیات طبقه‌بندی انجام می‌دهد. یک طبقه‌بندی معمولی حدود ۱,۰۰۰ توکن ورودی و ۱۰۰ توکن خروجی مصرف می‌کند. با نرخ‌های واقعی مدل اصلی، هزینه این کار حدود ۵.۵۰ دلار در روز است (یا حدود ۷ دلار در روز اگر پیش‌نویس‌های پاسخ و گزارش‌ها را هم در نظر بگیریم).

در برابر سقف جهانی ۵۰ دلاری، این مقدار فضای امن (Headroom) ۷ برابری مورد نظر را ایجاد می‌کند. حالا روزی را تصور کنید که مدل اصلی محدود شده و کل سیستم به qwen/qwen3.7-flash سوییچ می‌کند. هزینه واقعی همان حجم کار به تقریباً ۰.۴۳ دلار در روز کاهش می‌یابد. اما دفتر کل — که آن را با نرخ پیش‌فرض Sonnet (۳/۱۵ دلار) قیمت‌گذاری می‌کند — این هزینه را ۴۵ دلار در روز ثبت می‌کند.

با ثبت ۴۵ دلار در برابر سقف ۵۰ دلاری، سیستم در یک روز سقف جهانی را می‌زند. در روزهایی که حجم ایمیل‌ها بیشتر از حد متوسط باشد، این اتفاق حتی در وسط صبح رخ می‌دهد. سرویس طبقه‌بندی ایمیل را برای تمام کاربران متوقف می‌کند؛ نه به این دلیل که بودجه تمام شده، بلکه چون یک تطبیق رشته‌ای شکست خورده است. صورت‌حساب سالم بود، اما محصول مُرد.

راهکار مهندسی

رفع این مشکل مستلزم تغییر از تطبیق رشته‌های کلی به ردیف‌های صریح و مرتب‌شده بود، به‌طوری که SKUهای خاص در بالای خانواده‌های کلی لیست شوند. چون اولین تطبیق برنده است، ردیف‌های خاص باید بالای ردیف‌های کلی بمانند تا خطاهای قیمت‌گذاری ۶۰ تا ۱۰۰ برابری حذف شوند.

منطق به‌روز شده جدول نرخ‌ها

توسعه‌دهنده اکنون قیمت‌ها را بین ۱.۲ تا ۳.۳ برابر رُند می‌کند تا تغییرات کاتالوگ ارائه‌دهندگان بدون ایجاد قطعی مدیریت شود. این یک سیاست رُند کردن عمدی در برابر یک هدف متغیر است. جدول به‌روز شده شامل ورودی‌های خاصی است مانند:

• gpt-oss: ۰.۰۵ ورودی / ۰.۲ خروجی
• qwen: ۰.۱ ورودی / ۰.۳ خروجی
• mistral, nemo: ۰.۰۵ ورودی / ۰.۱ خروجی
• nemotron: ۰.۱ ورودی / ۰.۴ خروجی

برای جلوگیری از بازگشت باگ، سیستم اکنون از یک تست مبتنی بر جدول در مسیر packages/api/src/__tests__/model-fallback.test.ts استفاده می‌کند. این تست نرخ‌های مدل‌هایی مثل google/gemini-3.1-flash-lite (۰.۲۵/۱.۵) و openai/gpt-5-nano (۰.۱/۰.۴) را پین می‌کند. همچنین صراحتاً تست می‌کند که مدل‌های ناشناخته (مثلاً acme/brand-new-frontier) همچنان به پیش‌فرض سطح Sonnet برخورد کنند تا از زیر-تخمین هزینه جلوگیری شود.

اضافه کردن یک مدل به زنجیره جایگزین بدون به‌روزرسانی جدول نرخ‌ها در packages/api/src/llm/model-fallback.ts اکنون به عنوان یک «باگ پنهان در دسترس بودن» تلقی می‌شود، نه صرفاً یک بهینه‌سازی فراموش شده. قانون عملیاتی اکنون مطلق است: هر مدلی که به زنجیره جایگزین اضافه شود، باید در همان تغییر کد، به جدول نرخ‌ها نیز اضافه گردد.

تحلیل: مقدار در برابر جهت

این مورد مطالعه، این فرض را که «بیش-تخمین همیشه مسیر امنی در زیرساخت‌های AI است» تغییر می‌دهد. وقتی یک کنترل مالی در مسیر درخواست (Request path) قرار می‌گیرد، بودجه خطا دو محور دارد: پول و در دسترس بودن.

• زیر-تخمین هزینه پول می‌گیرد: سیستم «باز» شکست می‌خورد. محصول به کار خود ادامه می‌دهد در حالی که صورت‌حساب رشد می‌کند.
• بیش-تخمین هزینه در دسترس بودن را می‌گیرد: سیستم «بسته» شکست می‌خورد. صورت‌حساب سالم است، اما محصول متوقف می‌شود.

برای یک توسعه‌دهنده، این بدان معناست که هر روش ابتکاری که بر اساس «جهت» تعریف شود (مثلاً «فقط تخمین زیاد بزنید»)، یک ریسک است. خطر، جهت خطا نیست، بلکه «مقدار» (Magnitude) آن است. یک بیش-تخمین ۳ برابری، یک سیاست رُند کردن است؛ اما یک بیش-تخمین ۱۰۰ برابری، یک قطعی برنامه‌ریزی‌شده است.

مانیتورینگ و فضای امن (Slack)

علاوه بر این، مانیتورینگ کل هزینه کافی نیست. داشبورد هزینه ۴۵ دلاری شبیه به یک روز شلوغ به نظر می‌رسد. تنها راه شناسایی سریع این باگ در عرض چند دقیقه، ابزارگذاری نسبت «هزینه اندازه‌گیری شده» به «تخمین عقلانی هزینه واقعی» است. اگر این نسبت به ۱۰۰ رسید، شما یک باگ دارید، فارغ از اینکه زیر سقف بودجه باشید یا نه.

یک ریسک مرتبه دوم نیز در مورد «فضای امن» یا Slack وجود داشت. توسعه‌دهنده پیش از این سقف جهانی را از ۱۰ دلار به ۵۰ دلار افزایش داده بود تا فضای مانور بیشتری داشته باشد، زیرا ۱۰ دلار در برابر وضعیت پایدار ۷ دلاری، فضای بسیار کمی برای روزهای شلوغ می‌گذاشت. در حالی که این کار برای عملیات عادی درست بود، اما در واقع باعث شد باگ مدت بیشتری پنهان بماند. با سقف ۱۰ دلاری، خطای ۱۰۰ برابری در عرض یک ساعت سیستم را می‌بست و باگ فوراً آشکار می‌شد. فضای امن در سیستم، به باگ‌ها زمان می‌دهد تا دوام بیاورند.

اگر فراخوانی‌های LLM خود را پشت یک سقف هزینه قرار داده‌اید، همین امروز ارزان‌ترین مدل‌های جایگزین خود را بررسی کنید. مدل‌های گران همان‌هایی هستند که یادتان بود قیمت‌گذاری کنید؛ اما مدل‌های ارزان همان‌هایی هستند که پایداری سرویس شما را می‌شکنند.

گام بعدی شما

• جدول قیمت‌های مدل‌های جایگزین (Fallback) خود را با نرخ‌های فعلی API بررسی کنید.
• به جای تکیه بر سقف بودجه، سیستمی برای هشدار در صورت فاصله زیاد بین هزینه تخمینی و واقعی پیاده کنید.
• تست‌های واحد (Unit Tests) را برای اطانت از صحت تطبیق مدل‌ها با نرخ‌هایشان اضافه کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.