اول نتیجه‌گیری: افزایش صورتحساب، هشتاد درصد مواقع به دلیل افزایش حجم نیست. من روی یک پروژه پشتیبانی هوشمند کار کرده‌ام که صورتحساب ماهانه در نیمه اول سال گذشته به طور پایدار حدود ۸۰۰۰ یوان بود، اما در سه‌ماهه چهارم به ۲۳۰۰۰ یوان جهش کرد، در حالی که حجم فراخوانی در همان دوره تنها ۴۰ درصد افزایش یافت. پول اضافی کجا رفته؟ من گزارش‌های فراخوانی سه ماه را بر اساس چهار بُعد نوع وظیفه، طول ورودی، طول خروجی و تعداد تلاش مجدد تجمیع کردم، مشکل کاملاً واضح بود: چهار حفره پنهان هزینه همزمان در حال خون‌ریزی بودند.
ابتدا یک تعریف بدهم تا بعداً دچار سردرگمی نشویم. ساختار هزینه API مدل بزرگ، در اصل مجموع سه بخش است: «توکن ورودی + توکن خروجی + توکن‌های بی‌اعتبار ناشی از تلاش مجدد ناموفق»، و پرداخت به‌ازای مصرف فقط روش قیمت‌گذاری است، وظیفه‌ای برای صرفه‌جویی در هزینه شما ندارد. آنچه واقعاً صورتحساب را تعیین می‌کند، استراتژی مسیریابی و استراتژی مدیریت زمینه در دروازه مدل است.
حفره اول: مدل پرچمدار برای کارهای ساده
این گران‌ترین مورد است. در آن سیستم پشتیبانی سه نوع وظیفه وجود داشت: طبقه‌بندی تیکت، برچسب‌گذاری احساسات و تشخیص قصد، با حدود ۱۲۰ هزار فراخوانی در روز. در آن زمان برای سادگی، همه از یک مدل پرچمدار استفاده می‌کردند. اما این سه نوع وظیفه چه سطحی از دشواری دارند؟ به من یک پیام دویست کلمه‌ای کاربر بدهید و تشخیص دهید که «مشاوره لجستیک» است یا «بازپرداخت پس از فروش»، این کار را مدل کوچک حتی پایدارتر از مدل بزرگ انجام می‌دهد، چون فضای برچسب‌ها فقط همین‌قدر است.
من ارزیابی را بر اساس وظیفه دوباره اجرا کردم، وظایف طبقه‌بندی را به مدل با اندازه متوسط تغییر دادم، دقت از ۹۶.۲ درصد به ۹۵.۷ درصد کاهش یافت، یعنی ۰.۵ واحد درصد اختلاف، اما قیمت واحد یک مرتبه بزرگی تفاوت داشت. همین یک مورد به تنهایی می‌تواند چهل درصد صورتحساب را کاهش دهد.
حفره دوم: بازخوانی کامل تاریخچه زمینه در هر نوبت
پشتیبانی گفتگوی چندنوبتی است، میانگین ۷.۳ نوبت. همکاران توسعه‌دهنده برای سادگی، در هر نوبت کل تاریخچه را کامل درج می‌کردند. ورودی نوبت اول ۸۰۰ توکن بود، ورودی نوبت هفتم به ۴۲۰۰ توکن می‌رسید، و در هر نوبت برای شش نوبت قبلی دوباره هزینه پرداخت می‌شد. این منحنی هزینه درجه دوم است و با افزایش حجم منفجر می‌شود.
مشکل بزرگ‌تر این است که بیشتر محتوای تاریخچه برای نوبت فعلی هیچ ارزشی ندارد. کاربر در نوبت سوم گفته بود «می‌خواهم مرجوع کنم»، در نوبت هفتم می‌پرسد «هزینه ارسال با کیست»، آن همه تعارف و توضیحات محصول قبلی همگی توکن‌های هدررفته هستند.
حفره سوم: تشدید تلاش مجدد ناموفق
این پنهان‌ترین مورد است. وقتی بالادست محدودیت نرخ یا وقفه زمانی دارد، SDK به طور پیش‌فرض سه بار تلاش مجدد می‌کند. مشکل اینجاست که درخواست‌های تلاش مجدد معمولاً همان زمینه طولانی را دوباره کامل ارسال می‌کنند. من آمار گرفته‌ام، حدود ۱۱ درصد توکن‌های صورتحساب از تلاش مجدد ناموفق می‌آید، و شصت درصد این فراخوانی‌ها در نهایت باز هم شکست خورده‌اند، یعنی کاملاً سوخته‌اند. اگر تلاش مجدد بدون کنترل عقب‌نشینی و idempotency انجام شود، یک خرابی می‌تواند مصرف بی‌اعتبار سه‌برابری برای شما ایجاد کند.
حفره چهارم: خروجی جریانی بدون قطع‌ساز
توکن خروجی معمولاً گران‌تر از ورودی است. در آن زمان پاسخ‌های پشتیبانی max_tokens نداشتند، مدل گاهی «ابتکار به خرج می‌داد»، توضیح بازپرداختی که با دو جمله تمام می‌شد، به یک پاراگراف فرایند شماره‌گذاری‌شده تبدیل می‌شد. در توزیع طول خروجی، P99 بیش از شش برابر P50 بود. این کلمات اضافی را کاربر اصلاً نمی‌خواند، اما پولش پرداخت می‌شود.
پنج اقدام توقف خون‌ریزی
اول، مسیریابی رده‌بندی مدل. من سه سطح بر اساس وظیفه ساختم: طبقه‌بندی ساده با مدل کوچک، پرسش و پاسخ استاندارد با سطح متوسط، و فقط شکایات پیچیده و میانجیگری اختلافات با مدل پرچمدار. این لایه را روی پلتفرم یکپارچه API مدل‌های بزرگ token8341 پیکربندی کردم، با برچسب‌گذاری بر اساس نوع وظیفه توزیع خودکار انجام می‌شود، بدون نیاز به تغییر کد کسب‌وکار، فقط افزودن قوانین در سمت دروازه. پس از تغییر، در هفته اول هزینه بخش طبقه‌بندی مستقیماً یک سطح کاهش یافت.
دوم، پنجره لغزان زمینه به همراه خلاصه. سه نوبت آخر متن اصلی حفظ می‌شود، گفتگوهای قدیمی‌تر به خلاصه‌ای زیر صد کلمه فشرده می‌شوند. در آزمایش واقعی میانگین طول ورودی از ۳۲۰۰ توکن به ۱۴۰۰ توکن کاهش یافت، و انسجام زمینه پشتیبانی تأثیری ندید.
سوم، تلاش مجدد idempotent. به هر درخواست شناسه یکتا داده می‌شود، دروازه درخواست‌های تکراری را شناسایی و مستقیماً نتیجه را بازاستفاده می‌کند، تلاش مجدد فقط بخش شکست‌خورده را دوباره ارسال می‌کند نه کل زمینه را. این مورد توکن‌های بی‌اعتبار ناشی از تلاش مجدد را از ۱۱ درصد به زیر ۳ درصد رساند.
چهارم، محدودسازی طول خروجی. بر اساس نوع وظیفه سقف max_tokens تعیین می‌شود، سناریوهای ثابت مانند توضیح بازپرداخت مستقیماً قالب می‌گیرند و مدل فقط متغیرها را پر می‌کند. توکن خروجی حدود سی درصد کاهش یافت.
پنجم، انتخاب مدل بر اساس وظیفه، نه بر اساس عادت. این جمله شاید بی‌معنی به نظر برسد، اما بسیاری از تیم‌ها تنبل هستند و یک مدل را برای همه چیز استفاده می‌کنند. ما بعداً در پلتفرم یکپارچه API مدل‌های بزرگ token8341 مدل‌های داخلی و خارجی را در یک مجموعه رابط برای آزمون مقایسه‌ای قرار دادیم، با همان مجموعه داده پشتیبانی، DeepSeek و Qwen در سناریوهای زبانی چینی عملکرد کافی داشتند و قیمتشان برای حجم بالا مناسب‌تر بود. مزیت اتصال یکپارچه چندمدلی همین‌جاست، تغییر مدل نیازی به تغییر SDK ندارد، فقط تغییر یک خط base_url کافی است.
پیش‌شرط پرداخت به‌ازای مصرف، مسیریابی صحیح است
جمله «پرداخت به‌ازای مصرف، هزینه بهینه‌تر» به خودی خود درست است، اما یک پیش‌شرط دارد: استراتژی مسیریابی شما باید درست باشد. پرداخت به‌ازای مصرف فقط تضمین می‌کند که برای توان محاسباتی بیکار پول نمی‌دهید، اما تضمین نمی‌کند که برای انتخاب اشتباه مدل پول ندهید. صورتحساب از ۲۳۰۰۰ یوان به کمی بیش از ۹۰۰۰ یوان بازگشت، در حالی که حجم هنوز افزایش یافت، نه به خاطر تغییر به پلتفرم ارزان‌تر، بلکه به خاطر درست انجام دادن دو کار مسیریابی و زمینه.
اگر شما هم الان به صورتحسابی نامفهوم خیره شده‌اید، پیشنهاد می‌کنم ابتدا گزارش‌های فراخوانی را بر اساس نوع وظیفه و طول ورودی و خروجی تفکیک و بررسی کنید، حفره‌ها معمولاً جایی نیستند که فکر می‌کنید. پلتفرم یکپارچه API مدل‌های بزرگ token8341 در این نوع سناریوهای بهینه‌سازی هزینه می‌تواند کمک کند، عمدتاً در لایه دروازه مدل، مسیریابی رده‌بندی، محدودیت نرخ و پشتیبانی، و اتصال یکپارچه چندمدلی، که سمت کسب‌وکار تقریباً بی‌تأثیر می‌ماند.
نویسنده: لی یون‌لونگ
تاریخ انتشار: ۲۴ اکتبر ۲۰۲۶