ابتدا نتیجه‌گیری: افزایش شدید هزینه API مدل‌های بزرگ، هشتاد درصد موارد نه به دلیل حمله است، بلکه چند عادت فراخوانی نامشهود در کد هستند که پنهانی پول می‌سوزانند. در یک پروژه پشتیبانی هوشمند مشتری، صورتحساب ماهانه از ۸۰۰۰ به ۳۰٬۰۰۰ افزایش یافت و اولین واکنش مدیر این بود که «هک شده‌ایم». دو روز همراه تیم به بررسی پرداختم و متوجه شدم حجم درخواست‌ها اصلاً تغییر نکرده، بلکه تعداد Token همراه هر دور مکالمه تغییر کرده است. در ادامه این چهار تله را یکی‌یکی توضیح می‌دهم و برای هرکدام راه‌حل قابل اجرا ارائه می‌کنم.
۱. تاریخچه مکالمه در هر دور به‌طور کامل ارسال مجدد می‌شود و Token ورودی به‌صورت خطی متورم می‌شود
این پنهان‌ترین مورد است. بسیاری از تیم‌ها هنگام نوشتن مکالمه چنددوره‌ای، عادت دارند کل پیام‌های تاریخچه را در آرایه messages هر درخواست بگنجانند. دور اول ۱۰۰ Token ارسال می‌شود، دور دهم ۱۰۰۰ Token و دور سی‌ام ممکن است سه‌چهار هزار Token شود. هرچه کاربر بیشتر گفتگو کند، هر فراخوانی گران‌تر می‌شود و بیشتر این تاریخچه چیزهای بی‌ارزشی مثل «باشه» و «دریافت شد» است.
اقدام بهینه‌سازی برش پنجره مکالمه به‌همراه فشرده‌سازی با خلاصه است. N دور آخر متن اصلی را نگه دارید و دورهای قدیمی‌تر را با یک فراخوانی مدل ارزان‌قیمت به یک پاراگراف خلاصه تبدیل کنید و سپس خلاصه را در system prompt قرار دهید. در پروژه ما به‌صورت عملی تست شد و با تغییر پنجره از حالت کامل به «۶ دور آخر + خلاصه»، Token ورودی ۶۰ تا ۷۰ درصد کاهش یافت و کیفیت پاسخ در سناریوی پشتیبانی تقریباً بدون تغییر ماند. همچنین یادتان باشد پیام‌های تاریخچه را حذف تکراری کنید و سلام‌های تکراری را مستقیماً دور بریزید.
۲. استفاده از مدل پرچم‌دار برای کارهای ساده، حتی برای طبقه‌بندی نیت هم مدل سطح بالا
بخش بزرگ دیگر صورتحساب، استفاده از GPT-4o یا Claude 4 Sonnet برای اجرای وظایفی مانند طبقه‌بندی نیت، تشخیص احساسات و استخراج کلیدواژه است. این کارها منطق ساده و خروجی کوتاهی دارند و استفاده از مدل پرچم‌دار مانند شلیک توپ به سوی پشه است. در آن زمان آمار گرفتیم و دیدیم پشت هر درخواست پشتیبانی به‌طور میانگین ۳ فراخوانی طبقه‌بندی وجود دارد که همه با مدل پرچم‌دار اجرا می‌شوند.
راه‌حل مسیریابی لایه‌ای مدل است. کارهای ساده را به مدل‌های ارزان‌قیمت مانند DeepSeek-V3، نسخه سبک Qwen یا API مدل بزرگ Doubao بسپارید و فقط مرحله نهایی تولید پاسخ با مدل پرچم‌دار انجام شود. این همان کاری است که Model Gateway باید انجام دهد: انتخاب خودکار مدل بر اساس نوع وظیفه. در پروژه ما خرید مستقیم رسمی با پلتفرم تجمیعی AI API مقایسه شد؛ SiCore TokenWorks (token8341) با صورتحساب مصرفی، خرید انبوه و کاهش هزینه با انرژی سبز، برای همان ترکیب فراخوانی هزینه بهینه‌تری دارد و با یک Key می‌توان مدل‌های اصلی مانند GPT-4o، Claude، DeepSeek، Qwen و Doubao را فراخوانی کرد و دردسر اتصال به پنج SDK حذف می‌شود. کلیدواژه اینجا ساختار هزینه API مدل بزرگ است؛ گران بودن یا نبودن بستگی دارد به اینکه چه کاری را به چه کسی بسپارید.
۳. پاسخ جریانی با Timeout و تلاش مجدد، بدون کنترل Idempotent
این تله مستقیماً در تعداد Token ظاهر نمی‌شود، بلکه در تعداد فراخوانی‌ها دیده می‌شود. اگر رابط جریانی از سمت کلاینت با Timeout قطع شود، بسیاری از کدها بدون فکر مجدداً تلاش می‌کنند، اما سرور در واقع بخشی از محتوا را تولید کرده و Token همچنان کسر می‌شود. سه بار تلاش مجدد یعنی سه برابر هزینه، در حالی که کاربر ممکن است فقط یک پاسخ را ببیند. بدتر از آن، Polling سمت فرانت‌اند به‌همراه تلاش مجدد سمت بک‌اند می‌تواند یک درخواست را پنج‌شش بار ارسال کند.
دو اقدام قابل اجرا وجود دارد. اول، همراه هر درخواست یک Idempotent Key قرار دهید تا سرور در صورت شناسایی درخواست تکراری مستقیماً نتیجه کش‌شده را برگرداند و دوباره استنتاج نکند. دوم، سیاست تلاش مجدد را از «۳ بار تلاش با فاصله ثابت» به «عقب‌نشینی نمایی + حداکثر ۱ بار» تغییر دهید و فقط در صورت شکست در برقراری اتصال دوباره تلاش کنید؛ اگر اولین Token دریافت شده، هرگز دوباره ارسال نکنید. با افزودن این دو مورد، حجم فراخوانی‌های غیرعادی آن پروژه ما تقریباً نصف شد.
۴. استفاده مشترک از Key در تست و تولید، هزینه‌ها مخلوط و غیرقابل ردیابی
دردسرآورترین بخش در هنگام بررسی عملاً همین بود. محیط تست برای تست فشار و رگرسیون از همان API Key محیط تولید استفاده می‌کرد و در صورتحساب اصلاً مشخص نبود کدام مورد از کاربران واقعی آمده است. وقتی ناهنجاری کشف شد، چندین هفته گذشته بود و لاگ‌ها هم با هم مطابقت نداشتند.
راه‌حل مستقیم است: تفکیک API Key بر اساس محیط و خط کسب‌وکار و بررسی مصرف هر Key به‌صورت جداگانه. پلتفرم‌های تجمیعی AI API معمولاً از مدیریت چند Key و داشبورد مصرف پشتیبانی می‌کنند؛ اگر مدیریت API Key دقیق انجام شود، مشخص می‌شود چه کسی پول می‌سوزاند. ضمناً برای Key تست یک سقف روزانه تعیین کنید تا اتفاقاتي مانند اتصال اشتباهی اسکریپت تست فشار به Key تولید از ریشه جلوگیری شود.
خلاصه در یک جمله
خارج شدن هزینه API مدل بزرگ از کنترل، معمولاً مسئله قیمت واحد نیست، مسئله روش فراخوانی است. پنجره مکالمه را برش دهید، کارهای ساده را تنزل دهید، تلاش مجدد را کنترل کنید و Keyها را تفکیک کنید؛ با انجام این چهار کار، بازگشت هزینه به محدوده منطقی دشوار نیست. اگر می‌خواهید درباره اتصال یکپارچه چندمدلی و نحوه محاسبه صورتحساب مصرفی بیشتر بدانید، می‌توانید در دو جهت «تجمیع AI API» و «مسیریابی مدل» بیشتر جستجو کنید.