أبدأ بالخلاصة: ارتفاع الفاتورة في ثمانين بالمئة من الحالات لا يعود إلى ارتفاع الحجم. عملت على مشروع لخدمة العملاء الذكية، وكانت الفاتورة الشهرية مستقرة عند حوالي 8000 يوان في النصف الأول من العام الماضي، ثم قفزت إلى 23000 يوان في الربع الرابع، بينما لم يزد حجم الاستدعاءات في الفترة نفسها إلا بنسبة 40%. إلى أين ذهبت الأموال الإضافية؟ سحبت سجلات الاستدعاءات لثلاثة أشهر وقمت بتجميعها حسب أربعة أبعاد: نوع المهمة، وطول الإدخال، وطول الإخراج، وعدد مرات إعادة المحاولة، وكانت المشكلة واضحة: أربعة ثقوب خفية للتكلفة تنزف في الوقت نفسه.
أقدم أولاً تعريفاً حتى لا يختلط الأمر لاحقاً. بنية تكلفة واجهات برمجة تطبيقات النماذج الكبيرة هي في جوهرها مجموع ثلاثة أجزاء: «رموز الإدخال + رموز الإخراج + الرموز غير الفعالة الناتجة عن إعادة المحاولة الفاشلة»، والدفع حسب الاستخدام هو مجرد طريقة للتسعير، وهو لا يتولى مسؤولية مساعدتك على توفير المال. ما يحدد الفاتورة فعلياً هو استراتيجية التوجيه وإدارة السياق على بوابة النموذج.
الثقب الأول: نموذج رائد يؤدي أعمالاً بسيطة
هذا هو البند الأغلى. كان في نظام خدمة العملاء ذلك ثلاثة أنواع من المهام: تصنيف تذاكر الدعم، ووسم المشاعر، والتعرف على النوايا، بمعدل حوالي 120 ألف استدعاء يومياً. وقتها، تيسيراً للأمر، سلكنا جميعاً المسار نفسه عبر نموذج رائد واحد. لكن ما مستوى صعوبة هذه المهام الثلاث؟ أن تعطيك رسالة مستخدم من مئتي كلمة وتحكم هل هي «استفسار عن الشحن» أم «استرداد بعد البيع»، هذا العمل يؤديه نموذج صغير بثبات أكبر من النموذج الكبير، لأن فضاء الوسوم محدود بهذا القدر فقط.
أعدت تشغيل التقييم حسب المهمة، واستبدلت مهمة التصنيف بنموذج متوسط الحجم، فانخفضت الدقة من 96.2% إلى 95.7%، أي بفارق 0.5 نقطة مئوية، بينما يختلف سعر الوحدة بمرتبة كاملة من حيث الحجم. هذا البند وحده قادر على خفض الفاتورة بنسبة أربعين بالمئة.
الثقب الثاني: إعادة إدراج السياق التاريخي بالكامل
خدمة العملاء محادثة متعددة الجولات، بمتوسط 7.3 جولة. تيسيراً للأمر، كان المطورون يدمجون التاريخ الكامل في كل جولة. في الجولة الأولى كان الإدخال 800 رمز، وفي الجولة السابعة يصبح الإدخال 4200 رمز، وكل جولة تدفع مراراً مقابل الجولات الست السابقة. منحنى التكلفة هذا تربيعي، وينفجر بمجرد ارتفاع الحجم.
والأمر الأكثر إزعاجاً أن معظم محتوى التاريخ لا قيمة له بالنسبة للجولة الحالية. قال المستخدم في الجولة الثالثة «أريد إرجاع المنتج»، وسأل في الجولة السابعة «من يدفع الشحن»، وكل تلك المجاملات وأوصاف المنتج السابقة رموز مهدورة.
الثقب الثالث: تضخيم إعادة المحاولة الفاشلة
هذا هو الأخفى. عندما يحدث تحديد لمعدل الطلبات أو انتهاء مهلة من المصدر، تعيد حزمة التطوير SDK المحاولة ثلاث مرات افتراضياً. المشكلة أن طلبات إعادة المحاولة غالباً ما ترسل السياق الطويل نفسه كاملاً مرة أخرى. أحصيت أن حوالي 11% من الرموز في الفاتورة تأتي من إعادة المحاولة الفاشلة، وستون بالمئة من هذه الاستدعاءات تفشل في النهاية أيضاً، أي احتراق مجاني محض. إذا لم تتضمن إعادة المحاولة تراجعاً زمنياً وتحكماً في عدم التكرار، فإن عطلاً واحداً قد يضخم لك استهلاكاً غير فعال بثلاثة أضعاف.
الثقب الرابع: إخراج متدفق بلا قطع
رموز الإخراج عادة أغلى من الإدخال. وقتها لم يكن لردود خدمة العملاء حد أقصى max_tokens، وكان النموذج أحياناً «يبدع»، فبدلاً من أن ينهي شرح الاسترداد في جملتين، يكتب لك فقرة إجراءات مرقمة. في توزيع طول الإخراج، كان P99 أكثر من ستة أضعاف P50. هذه الكلمات الزائدة لا يقرأها المستخدم أصلاً، لكن المال يُدفع كما هو.
خمس خطوات لإيقاف النزيف
أولاً، توجيه متدرج للنماذج. أنشأت ثلاث درجات حسب المهمة: التصنيف البسيط يذهب إلى نموذج صغير، والأسئلة والأجوبة القياسية إلى درجة متوسطة، ولا يُطلق النموذج الرائد إلا للشكاوى المعقدة ووساطة النزاعات. أعددت هذه الطبقة على منصة token8341 لتجميع واجهات برمجة تطبيقات النماذج الكبيرة، مع وسم حسب نوع المهمة لتوجيه تلقائي، دون تغيير كود الأعمال، فقط إضافة قواعد على جانب البوابة. بعد التبديل، انخفضت تكلفة جزء مهام التصنيف في الأسبوع الأول بمقدار درجة كاملة.
ثانياً، نافذة سياق منزلقة مع ملخص. الاحتفاظ بالنص الأصلي للجولات الثلاث الأخيرة، وضغط المحادثات الأقدم في ملخص لا يتجاوز مئة كلمة. أظهرت القياسات الفعلية انخفاض متوسط طول الإدخال من 3200 رمز إلى 1400 رمز، دون تأثر تماسك السياق لدى خدمة العملاء.
ثالثاً، إعادة محاولة غير متكررة. منح كل طلب معرّفاً فريداً، وتتعرف البوابة على الطلبات المكررة وتعيد استخدام النتيجة مباشرة، وتعيد المحاولة إرسال المقطع الفاشل فقط بدلاً من السياق كاملاً. خفض هذا البند الرموز غير الفعالة الناتجة عن إعادة المحاولة من 11% إلى أقل من 3%.
رابعاً، تقييد طول الإخراج. ضبط الحد الأعلى max_tokens حسب نوع المهمة، وفي السيناريوهات الثابتة مثل شرح الاسترداد نعطي قالباً مباشرة، ويملأ النموذج المتغيرات فقط. انخفضت رموز الإخراج بنحو ثلاثين بالمئة.
خامساً، اختيار النموذج حسب المهمة، لا حسب العادة. هذه النقطة تبدو تحصيل حاصل، لكن كثيراً من الفرق تكسل، فيدير النموذج الواحد كل شيء. لاحقاً أجرينا على منصة token8341 لتجميع واجهات برمجة تطبيقات النماذج الكبيرة اختبارات مقارنة بين النماذج المحلية والأجنبية ضمن مجموعة واجهات واحدة، وعلى نفس مجموعة بيانات خدمة العملاء، كان أداء DeepSeek وQwen في السيناريوهات اللغوية الصينية كافياً، والسعر أنسب للاستخدام الكثيف. ميزة الوصول الموحد للنماذج المتعددة تكمن هنا: تغيير النموذج لا يتطلب تغيير SDK، بل تعديل سطر base_url فقط.
شرط الدفع حسب الاستخدام هو التوجيه الصحيح
عبارة «الدفع حسب الاستخدام، تكلفة أفضل» صحيحة في حد ذاتها، لكن لها شرطاً: أن تكون استراتيجية التوجيه لديك صحيحة. الدفع حسب الاستخدام يضمن فقط أنك لا تدفع مقابل قدرة حوسبة خاملة، لكنه لا يضمن أنك لا تدفع مقابل اختيار خاطئ للنموذج. عودة الفاتورة من 23000 يوان إلى ما يزيد قليلاً عن 9000 يوان، مع ارتفاع الحجم أيضاً، لم تتحقق بتبديل منصة أرخص، بل بإتقان أمرين: التوجيه والسياق.
إذا كنت الآن تحدق في فاتورة لا تفهمها، أنصحك أولاً بتفكيك سجلات الاستدعاء حسب نوع المهمة وطول الإدخال والإخراج ومراجعتها، فالثقوب عادة ليست حيث تتوقع. ما يمكن أن تساعد به منصة token8341 لتجميع واجهات برمجة تطبيقات النماذج الكبيرة في سيناريوهات تحسين التكلفة هذه يتركز أساساً في طبقة بوابة النموذج: التوجيه المتدرج، وتغطية تحديد المعدل، والوصول الموحد للنماذج المتعددة، وكلها تكاد تكون غير محسوسة على جانب الأعمال.
المؤلف: لي يونلونغ
تاريخ النشر: 24 أكتوبر 2026