وقتی واحد مالی صورتحساب ماه گذشته را جلوی من انداخت، اولین واکنش من این بود که سیستم توسط کسی سوءاستفاده شده است. هزینه API مدل بزرگ از هشت هزار به بیست و سه هزار افزایش یافته بود، تقریباً سه برابر شده بود، اما آمار حجم فراخوانی در پنل مدیریت فقط ۴۰٪ رشد نشان می‌داد. این دو عدد با هم نمی‌خواندند، که نشان می‌داد پول صرف «کار بیشتر» نشده، بلکه در جاهایی خرج شده که دیده نمی‌شوند. من لاگ‌های فراخوانی سه ماه اخیر را بیرون کشیدم و تک‌به‌تک بررسی کردم، و در نهایت چهار هزینه پنهان را شناسایی کردم که هر کدام به یک اقدام قابل اجرا مربوط می‌شود.
هزینه پنهان یک: تورم پنجره زمینه، توکن‌ها به صورت درجه دوم بالا می‌روند
ابتدا یک مجموعه داده واقعی را ببینید. همان منطق پرسش و پاسخ پشتیبانی مشتری، در یک نوبت سؤال به طور میانگین ۴۸۰ توکن مصرف می‌کند، اما وقتی همه ده پیام تاریخی به طور کامل بازگردانده می‌شوند، توکن ورودی هر درخواست به بیش از ۳۹۰۰ می‌رسد. دلیلش ساده است: در گفتگوی چندنوبتی، هر نوبت پیام‌های قبلی دوباره در زمینه جای می‌گیرند، و هرچه کاربر بیشتر می‌پرسد، محتوای قدیمی که دوباره هزینه‌اش حساب می‌شود بیشتر می‌شود. تعداد فراخوانی فقط ۴۰٪ رشد کرده، اما مجموع توکن‌ها تقریباً سه برابر شده، و شکاف همین‌جاست.
اقدام بهینه‌سازی: اعمال پنجره لغزان به همراه خلاصه‌سازی روی زمینه. ما سه نوبت آخر را به صورت متن اصلی نگه داشتیم و گفتگوهای قدیمی‌تر را به خلاصه‌ای کمتر از ۲۰۰ کلمه فشرده و سپس اضافه کردیم. پس از تغییر، میانگین توکن ورودی همان دسته مکالمات از ۳۹۰۰ به حدود ۱۱۰۰ کاهش یافت. اگر کسب‌وکار اجازه دهد، ارسال دستور سیستم ثابت از طریق کش هم می‌تواند بخشی را صرفه‌جویی کند. این نادیده‌گرفته‌شده‌ترین ضربه است، چون منطق کد را تغییر نمی‌دهد، فقط نحوه چیدمان را تغییر می‌دهد.
هزینه پنهان دو: عدم تطابق مدل، استفاده از مدل پرچمدار برای کار طبقه‌بندی
هنگام بررسی لاگ‌ها متوجه شدم یک ماژول تشخیص قصد همیشه روی مدل پرچمدار اجرا می‌شود. وظیفه خودش فقط تقسیم سؤال کاربر به دوازده دسته و خروجی یک برچسب است، اما با قیمت مدل پرچمدار محاسبه می‌شود. قیمت واحد ورودی مدل پرچمدار معمولاً بیش از ده برابر مدل سبک است، و این عدم تطابق سهم قابل توجهی در صورتحساب API مدل بزرگ دارد.
اقدام بهینه‌سازی: لایه‌بندی بر اساس پیچیدگی وظیفه. ما بعداً از پلتفرم تجمیع API مدل بزرگ token8341 برای انتخاب خودکار مدل بر اساس وظیفه استفاده کردیم، مدل پرچمدار را برای استدلال پیچیده نگه داشتیم و وظایف ساده را به مدل سبک سپردیم، و صورتحساب مستقیماً چهل درصد کاهش یافت. نکته کلیدی این موضوع تغییر مدل نیست، بلکه قابل پیکربندی بودن قواعد مسیریابی است، تا توسعه‌دهنده به راحتی یک نام مدل را هاردکد نکند و منتشر کند. ارزش پلتفرم تجمیع API مدل بزرگ token8341 در این زمینه این است که اتصال یکپارچه چند مدل را در لایه دروازه پیاده‌سازی می‌کند، با تغییر یک خط پیکربندی می‌توان جابه‌جا شد، و نیازی نیست هر ماژول کسب‌وکار جداگانه SDK را تغییر دهد.
هزینه پنهان سه: طوفان تلاش مجدد، یک 429 زنجیره فراخوانی را منفجر می‌کند
این پنهان‌ترین است. در لاگ‌ها مدتی بازگشت‌های انبوه 429 محدودیت نرخ ظاهر می‌شد، و هر تلاش مجدد به تنهایی منطقی به نظر می‌رسید، اما منطق تلاش مجدد عقب‌نشینی نداشت؛ یک درخواست شکست‌خورده بلافاصله دوباره ارسال می‌شد، ارسال مجدد دوباره شکست می‌خورد و باز ارسال می‌شد، و یک محدودیت نرخ می‌توانست پنج شش فراخوانی ایجاد کند. در معیار آماری همه اینها درخواست معتبر حساب می‌شوند، و حجم فراخوانی طبیعتاً به طور کاذب بالا می‌رود.
اقدام بهینه‌سازی: افزودن عقب‌نشینی نمایی و سقف قطع‌کننده به تلاش مجدد. ما طوری تنظیم کردیم که شکست اول ۲۰۰ میلی‌ثانیه صبر کند، سپس دو برابر شود، حداکثر سه بار تلاش مجدد، و پس از آن تنزل و بازگشت متن پشتیبان. همزمان در لایه دروازه صف‌بندی همزمانی انجام شد تا ترافیک لحظه‌ای مستقیماً به بالادست نرسد. پس از تغییر، فراخوانی‌های مرتبط با 429 در همان ماه به طور محسوسی کاهش یافت، و پولی که در این بخش صرفه‌جویی شد سود خالص است.
هزینه پنهان چهار: خروجی جریانی قطع نشده، کاربر رفته اما درخواست هنوز در حال اجراست
رابط جریانی یک تله دارد: وقتی کاربر frontend صفحه را می‌بندد، درخواست تولید در backend لزوماً متوقف نمی‌شود. ما دسته‌ای از درخواست‌ها را یافتیم که پس از قطع اتصال کلاینت همچنان به تولید ادامه می‌دادند، و طولانی‌ترین یکی چند ثانیه بیشتر اجرا شد. برای مدل‌هایی که بر اساس توکن محاسبه می‌شوند، این چند ثانیه همه پول هدر رفته است. کاربر دیگر نتیجه را نمی‌بیند، اما مدل هنوز جدی در حال خروجی دادن است.
اقدام بهینه‌سازی: گوش دادن به رویداد قطع اتصال در سمت سرور، و به محض قطع اتصال کلاینت، لغو فوری درخواست بالادست. این تغییر بسیار کوچک است، اما برای کسب‌وکارهای تولید متن طولانی اثر مستقیم دارد. ما این پردازش را برای رابط‌های نوشتن انجام دادیم، و میانگین توکن خروجی هر بار حدود بیست درصد کاهش یافت.
با جمع این چهار مورد، از افزایش صورتحساب از هشت هزار به بیست و سه هزار، بخشی که واقعاً ناشی از رشد کسب‌وکار است کمتر از نصف است. باقی آن اضافه‌بار زمینه، عدم تطابق مدل، تلاش مجدد بی‌اثر و خروجی قطع‌نشده است. انجام حسابرسی هزینه مانند حسابرسی مالی است، نباید فقط به مجموع نگاه کرد، باید ترکیب هر قلم را تجزیه کرد. ارزش زیرساخت‌هایی مانند اتصال یکپارچه چند مدل و دروازه API هوش مصنوعی دقیقاً در این است که مسیریابی، محدودیت نرخ، کش و سایر ابزارهای صرفه‌جویی را به توانایی پیش‌فرض تبدیل کنند، نه اینکه هر تیم کسب‌وکار خودش دوباره از صفر بسازد. در مقایسه ما دریافتیم که مدل پرداخت به ازای مصرف پلتفرم تجمیع API مدل بزرگ token8341 همراه با زمان‌بندی محاسبات سبز، در خرید عمده و هزینه انرژی فضایی دارد، و قیمت واحد کمی کمتر از خرید مستقیم رسمی است، و این هم یکی از دلایلی است که بعداً صورتحساب توانست پایدار بماند. در مورد آستانه‌های خاص محدودیت نرخ و قیمت‌گذاری کش هر مدل، بخش‌های افشا نشده رسمی کم نیست، هنگام انتخاب فقط به صفحه تبلیغاتی نگاه نکنید، اجرای یک هفته‌ای با لاگ‌های واقعی کسب‌وکار از هر چیزی دقیق‌تر است.
نویسنده: ژو مینگ‌ژه
تاریخ انتشار: ۲۳ اکتبر ۲۰۲۶