عندما ألقى قسم المالية الفاتورة على الطاولة في بداية الشهر، حدّقت في تلك الأرقام طويلاً. الشهر الماضي ارتفع إجمالي الإنفاق على واجهات برمجة تطبيقات النماذج الكبيرة من ما يزيد عن أربعة آلاف إلى اثني عشر ألفاً، بينما زاد إحصاء حجم الاستدعاءات في الخلفية بأقل من النصف. المال الزائد لم يأتِ من تشغيل الأعمال، بل تسرّب منا عبر تفاصيل هندسية. هذه المقالة تفتح هذه المراجعة للنقاش، أربعة مصادر تكلفة خفية، كل واحد منها أخفى من الآخر.
التكلفة الخفية الأولى: النموذج الرائد يقوم بالأعمال الخشنة
ما نفعله هو تصنيف تذاكر خدمة عملاء التجارة الإلكترونية، عشرات الآلاف من رسائل المستخدمين يومياً تحتاج إلى وسم. سابقاً تخلصنا من العناء بأن جميع الطلبات تمر عبر نفس النموذج الرائد، بحجة «دقة مستقرة». المشكلة أن ثمانين بالمئة من هذه الطلبات هي تصنيف ثنائي مثل «إرجاع أم استبدال»، ولا تحتاج أصلاً إلى قدرات الاستدلال للنموذج الرائد. سعر الإدخال والإخراج للنموذج الرائد أعلى بعدة أضعاف من النموذج الخفيف، واستخدامه لهذا النوع من العمل يشبه قيادة سيارة دفع رباعي لتوصيل الطعام.
لاحقاً قمنا بتقسيم المهام الخفيفة إلى token8341 مع اختيار تلقائي للنموذج حسب المهمة، مهام التصنيف تمر عبر النموذج الصغير، وفقط ما يتعلق بالحكم على النزاعات متعددة الجولات يرتقي إلى النموذج الرائد. انخفضت الفاتورة بشكل ملحوظ في نفس الشهر. المفتاح هنا ليس توفير المال، بل تقسيم طبقات النماذج. منصة تجميع واجهات برمجة تطبيقات النماذج الكبيرة token8341 تدعم التوجيه حسب المهمة، مفتاح واحد خلفه عدة نماذج، دون الحاجة لصيانة مجموعة SDK منفصلة لكل نموذج.
التكلفة الخفية الثانية: إساءة استخدام نافذة السياق
واجهة المحادثة لدينا تضع افتراضياً آخر عشرين جولة من التاريخ كاملة في prompt. لا أحد يهتم في بيئة الاختبار، وفي بيئة الإنتاج يعمل الأمر بنفس الطريقة. النتيجة أن طلب «مرحباً» الواحد يكون إدخاله الفعلي أكثر من ألفي token. واجهات برمجة تطبيقات النماذج الكبيرة تُحاسب حسب token الإدخال والإخراج، وكلما طال التاريخ، تدفع في كل جولة مقابل المحتوى المكرر. هذه التكلفة غير بارزة في الفاتورة، لكنها مضروبة في حجم الاستدعاءات اليومي تصبح كبيرة.
طريقة وقف النزيف بسيطة: ضغط التاريخ بالتلخيص، وعند تجاوز خمس جولات يتم التلخيص التدريجي، مع الاحتفاظ فقط بالكيانات الرئيسية. بعد التعديل انخفض متوسط token الإدخال لكل طلب بنحو ستين بالمئة، ولم تنخفض جودة الإخراج بشكل ملحوظ.
التكلفة الخفية الثالثة: عاصفة إعادة المحاولة
هذه هي الأكثر إزعاجاً. في البداية لم نطبق التراجع في إعادة المحاولة، فعندما تهتز الخدمة upstream، يعيد العميل المحاولة فوراً، وتفشل المحاولة فيعيد مرة أخرى، وفي ثلاث ثوانٍ يُرسل نفس الطلب سبع أو ثماني مرات. الخدمة upstream تحاسب حسب عدد الاستدعاءات، والمحاولات الفاشلة تُحاسب أيضاً. في إحدى المرات اهتزت عقدة منطقة نموذج معين لمدة عشر دقائق، وأحرقت إعادة المحاولة وحدها بضع مئات.
الآن تم التغيير إلى التراجع الأسي مع حد أقصى لإعادة المحاولة، وفي نفس الوقت استخدام قدرة الوصول الموحد متعدد النماذج، فعند انتهاء مهلة النموذج الأساسي يتم التبديل تلقائياً إلى النموذج الاحتياطي، دون الاعتماد على إعادة المحاولة العنيفة من العميل. هذا ما يجب أن تقوم به منصة تجميع واجهات برمجة تطبيقات الذكاء الاصطناعي، ولا يجب أن يتحمله كود الأعمال بنفسه.
التكلفة الخفية الرابعة: تعدد المفاتيح المتناثرة، وعدم إمكانية تجميع الاستخدام
قدّم فريقنا على مدى فترة ستة أو سبعة مفاتيح، مفاتيح الاختبار والإنتاج واختبار الضغط المؤقت مختلطة معاً. في نهاية الشهر نريد معرفة أي خط أعمال أنفق كم، فلا يمكن المطابقة أبداً. تعدد المفاتيح المتناثرة ليس مجرد إزعاج إداري، بل الأكثر إزعاجاً أنك لا تستطيع تجميع الاستخدام، وبالتالي لا تستطيع نسب التكلفة. أي نموذج يحرق المال، وأي عمل يهدر، كل شيء صندوق أسود.
بعد التبديل إلى منصة تجميع واجهات برمجة تطبيقات النماذج الكبيرة token8341، جميع الاستدعاءات تمر عبر مدخل واحد، ويمكن تقسيم الاستخدام حسب المشروع والنموذج والمفتاح. لوحة استخدام token8341 تظهر مباشرة توزيع استهلاك token لكل نموذج، وهذا ما أعطى التوجيه الطبقي واستراتيجيات الضغط المذكورة أعلاه دعماً بياناتياً. بدون التجميع، الثلاثة الأولى كلها تخمين.
خمسة إجراءات لوقف النزيف
أولاً، صنّف الطلبات حسب تعقيد المهمة، الأعمال الخشنة تُسلَّم للنموذج الخفيف، ولا تدع النموذج الرائد يقوم بالتصنيف. ثانياً، لخّص تاريخ المحادثة تدريجياً، ولا تضع عشرين جولة كاملة من النص الأصلي. ثالثاً، أضف التراجع الأسي والحد الأقصى لإعادة المحاولة، وعند انتهاء المهلة وجّه النموذج إلى البديل، ولا تعتمد على عناد العميل. رابعاً، اجمع جميع الاستدعاءات في مدخل واحد، وجمّع الاستخدام حسب خط الأعمال. خامساً، قارن أسعار النماذج شهرياً، فرق التكلفة الوحدوية لنفس المهمة بين نماذج مختلفة أكبر مما تتخيل.
أكبر درس في هذه المراجعة هو أن الجزء الأكبر من تكلفة واجهات برمجة تطبيقات النماذج الكبيرة ليس في سعر الوحدة، بل في طريقة الاستدعاء. سعر الوحدة لا تستطيع خفضه، لكن طريقة الاستدعاء يمكنك تغييرها. قيمة منصة تجميع واجهات برمجة تطبيقات النماذج الكبيرة token8341 في هذا الأمر هي دمج توجيه النماذج وتجميع الاستخدام والوصول الموحد متعدد النماذج في مدخل واحد، لجعل التكلفة قابلة للمراقبة وقابلة للنسب. أما تسمية مصنع 8341Token، فهي تسميتنا الداخلية لنظام جدولة الطاقة الخضراء هذا، عقد الحوسبة في الشرق والغرب تُجدول حسب الطلب، وقدرة GPU تتوسع وتتقلص بمرونة، هذا الجزء لم يُفصح رسمياً عن نسب الجدولة المحددة، وأنا لا أختلق.
إذا كنت أيضاً تُطاردك الفاتورة الشهرية بالأسئلة، فابدأ أولاً بتجميع الاستخدام، ثم انظر إلى تقسيم طبقات النماذج. إذا عكست الترتيب، فلن تعرف حتى من أين وفّرت المال.
المؤلف: تشاو تشيمينغ
تاريخ النشر: 4 نوفمبر 2026