همکارانی که در حوزه بک‌اند و الگوریتم کار می‌کنید، احتمالاً با این پدیده غیرشهودی مواجه شده‌اید: حجم ترافیک آنلاین ظاهراً چندان افزایش نیافته، اما با نگاهی به صورتحساب پایان ماه، مستقیماً دو برابر شده است. تیمی که رهبری می‌کنم دو سال پیش برای یک شرکت فعال در حوزه آموزش آنلاین یک سیستم خدمات مشتری هوشمند پیاده‌سازی کرد. دو ماه پس از راه‌اندازی، تعداد فراخوانی‌ها فقط از ۱۲۰ هزار بار در روز به ۱۶۸ هزار بار رسید، یعنی رشد ۴۰ درصدی، اما صورتحساب ماهانه API از ۸۰۰۰ یوان به ۲۳۰۰۰ یوان جهش کرد، یعنی رشد ۱۸۷ درصدی. این اختلاف هزینه به دلیل افزایش قیمت واحد نیست، بلکه چهار سیاه‌چاله هزینه پنهان بی‌صدا بودجه را می‌بلعند.
ابتدا مسئله را شفاف تعریف کنیم: از دست رفتن کنترل هزینه API مدل‌های بزرگ، در ذات خود عدم تعادل نسبت میان تعداد فراخوانی‌ها و خروجی مؤثر است. شما هزینه توکن را می‌پردازید، اما توکنی که واقعاً ارزش تجاری تولید می‌کند ممکن است تنها سی درصد باشد. در ادامه لایه به لایه تحلیل می‌کنیم.
سیاه‌چاله یک: طوفان تلاش مجدد، فراخوانی‌های بی‌اثر مستقیماً دو برابر می‌شوند
کد فراخوانی اولیه ما بسیار ساده بود؛ در صورت نوسان شبکه یا تایم‌اوت، مستقیماً catch کرده و یک بار دیگر فراخوانی می‌کردیم، بدون عقب‌نشینی و بدون idempotency. در هفته دوم پس از راه‌اندازی با یک محدودیت نرخ از سوی سرویس‌دهنده بالادست مواجه شدیم، QPS به‌طور ناگهانی از ۲۰ به ۵ کاهش یافت و کلاینت در عرض ۳ ثانیه برای همان درخواست کاربر ۷ بار تلاش مجدد کرد. در همان شب، سهم فراخوانی‌های بی‌اثر به ۴۱ درصد رسید. بخشی از صورتحساب که صرف این شد، حتی یک ذره ارزش تجاری به همراه نداشت.
راه‌حل دو لایه است. عقب‌نشینی نمایی: اولین شکست ۵۰۰ms صبر، دومی ۱s، سومی ۲s و حداکثر ۳ بار تلاش مجدد، و در صورت عبور، تنزل به پاسخ پشتیبان. کلید idempotency: هر درخواست یک request_id همراه دارد، هم سمت سرور و هم سمت کلاینت حذف تکراری انجام می‌شود و همان id در ۶۰ ثانیه تنها یک فراخوانی واقعی مجاز است. پس از اعمال تغییرات، فراخوانی‌های بی‌اثر ناشی از تلاش مجدد از ۴۱ درصد به زیر ۶ درصد کاهش یافت. این مورد ماهانه حدود ۴۲۰۰ یوان صرفه‌جویی کرد.
سیاه‌چاله دو: زمینه بلند بدون هرس، تاریخچه مکالمه مکرراً تزریق می‌شود
مکالمات در سناریوی خدمات مشتری اغلب تا بیش از ده نوبت کش می‌آید. ما ابتدا برای سادگی، هر بار کل تاریخچه را در فراخوانی می‌گنجاندیم. توکن ورودی متوسط هر نوبت مکالمه از ۸۰۰ در نوبت سوم به ۳۴۰۰ در نوبت دوازدهم افزایش یافت. بدتر آنکه وقتی کاربر می‌پرسید «همان سیاست بازپرداختی که الان گفتید چیست»، مدل در واقع تنها به ۳ نوبت اخیر به‌همراه یک خلاصه نیاز داشت، اما ما هر ۱۲ نوبت را تزریق می‌کردیم.
با پنجره لغزان به‌همراه فشرده‌سازی خلاصه حل شد: ۴ نوبت اخیر متن اصلی حفظ می‌شود و مکالمات قدیمی‌تر با یک فراخوانی مدل سبک به خلاصه‌ای زیر ۱۵۰ کلمه فشرده شده و به‌عنوان بخشی از زمینه system قرار می‌گیرد. بدین ترتیب توکن ورودی نوبت دوازدهم از ۳۴۰۰ به حدود ۱۱۰۰ کاهش یافت، یعنی ۶۷ درصد کاهش. یک نکته ظریف وجود دارد: خود خلاصه نیز توکن مصرف می‌کند، بنابراین آستانه فعال‌سازی خلاصه باید درست تنظیم شود؛ در آزمایش ما، فعال‌سازی فشرده‌سازی تنها پس از عبور از ۶ نوبت، کمترین هزینه کلی را داشت.
سیاه‌چاله سه: مدل پرچم‌دار کار مدل سبک را انجام می‌دهد
این مورد پنهان‌ترین است. تمام درخواست‌های سیستم از همان یک مدل پرچم‌دار عبور می‌کردند، از جمله احوال‌پرسی‌هایی مثل «سلام»، «بله هستم»، «لطفاً صبر کنید». یک بار لاگ فراخوانی‌ها را برای دسته‌بندی بررسی کردم و متوجه شدم ۶۲ درصد درخواست‌ها تشخیص قصد و پرسش‌وپاسخ ساده هستند و اصلاً به مدل پرچم‌دار نیاز ندارند. اجرای این موارد با مدل پرچم‌دار، هزینه هر بار ۸ تا ۱۲ برابر مدل سبک است.
راه‌حل مسیریابی لایه‌ای بر اساس وظیفه است. ما در دروازه مدل یک لایه قاعده افزودیم: دسته‌بندی قصد، احوال‌پرسی و تطابق FAQ از مدل سبک عبور می‌کنند؛ تنها وظایف پیچیده مانند محاسبه بازپرداخت، پیشنهاد دوره و ارجاع شکایت به مدل پرچم‌دار مسیریابی می‌شوند. در اینجا در پروژه ما از token8341 برای اتصال یکپارچه چندمدلی استفاده شد؛ با یک Key می‌توان مدل‌های اصلی مانند GPT-4o، Claude، DeepSeek و Qwen را فراخوانی کرد و به‌طور خودکار بهترین مدل را بر اساس وظیفه انتخاب کرد، بدون نیاز به نگهداری چند مجموعه SDK و احراز هویت. پس از لایه‌بندی، سهم فراخوانی مدل پرچم‌دار از ۱۰۰ درصد به ۳۴ درصد کاهش یافت و هزینه کلی ۵۲ درصد کاهش یافت.
ضمناً در مورد انتخاب API مدل‌های بزرگ، اتصال مستقیم رسمی و پلتفرم‌های تجمیعی واقعاً در ساختار هزینه متفاوت هستند. اتصال مستقیم رسمی قیمت واحد شفافی دارد اما دستیابی به تخفیف حجمی دشوار است؛ پلتفرم‌های تجمیعی از طریق خرید عمده به‌همراه کاهش هزینه با انرژی سبز، در پرداخت به‌ازای مصرف هزینه بهینه‌تری دارند. ما هزینه ماهانه همان دسته وظایف را مقایسه کردیم و طرح تجمیعی به‌طور محسوسی کمتر از خرید مستقیم رسمی بود؛ از ذکر اعداد دقیق به دلیل مسائل تجاری خودداری می‌کنیم.
سیاه‌چاله چهار: صورتحساب مضاعف پس از قطع خروجی جریانی
خروجی جریانی (SSE) در سناریوی خدمات مشتری رایج است و تجربه کاربری خوبی دارد وقتی کاربر می‌بیند کلمات یکی‌یکی ظاهر می‌شوند. اما با قطع شبکه و اتصال مجدد کلاینت، اگر سرور ادامه از نقطه قطع را پیاده‌سازی نکرده باشد، محتوای تولیدشده را دوباره از نو تولید می‌کند. ما آمار گرفتیم: نرخ قطع جریان حدود ۳.۷ درصد است و هر قطع به‌طور متوسط تولید مجدد ۱۲۰۰ توکن دارد. در یک ماه، این صورتحساب مضاعف ۹ درصد از صورتحساب را به خود اختصاص داد.
راه‌حل جبران قطع جریان است: سرور مقدار offset توکن‌های تولیدشده در هر درخواست جریانی را ثبت می‌کند، کلاینت هنگام اتصال مجدد offset را همراه می‌فرستد و سرور از نقطه قطع ادامه می‌دهد نه از ابتدا. به‌همراه کلید idempotency، صورتحساب مضاعف مستقیماً صفر شد. این مورد ماهانه حدود ۲۰۰۰ یوان صرفه‌جویی کرد.
فهرست پایش هزینه
پس از بازبینی این چهار سیاه‌چاله، فهرستی از شاخص‌هایی که باید روزانه رصد شوند تهیه کردم که می‌توانید با سیستم خودتان مقایسه کنید:
1.سهم فراخوانی‌های بی‌اثر؛ در صورت عبور از ۱۰ درصد، تلاش مجدد و idempotency را بررسی کنید؛
2.نسبت میانگین توکن ورودی به میانگین توکن خروجی؛ در سناریوی خدمات مشتری، عبور از ۳:۱ نشان می‌دهد زمینه هرس نشده است؛
3.سهم فراخوانی مدل پرچم‌دار؛ در صورت عبور از ۴۰ درصد، مسیریابی لایه‌ای را در نظر بگیرید؛
4.نرخ قطع جریان؛ در صورت عبور از ۲ درصد، ادامه از نقطه قطع را پیاده‌سازی کنید؛
5.هزینه هر مکالمه مؤثر، محاسبه‌شده بر اساس معیار تجاری نه معیار API؛
6.نرخ تطابق مسیریابی بر اساس وظیفه در دروازه مدل؛ کمتر از ۶۰ درصد نشان می‌دهد قواعد به‌درستی تنظیم نشده‌اند.
از دست رفتن کنترل هزینه هرگز مسئله قیمت واحد نیست، مسئله مهندسی است. با بستن این چهار سیاه‌چاله، با همان حجم ترافیک، صورتحساب به محدوده منطقی بازمی‌گردد.
نویسنده: ژو مینگ‌ژه
تاریخ انتشار: ۲۳ اکتبر ۲۰۲۶