ملاحظة الكاتب: نستعرض بنية فاتورة Token للمهام الطويلة التي ينفذها الوكيل، ونوضح لماذا تستحوذ رموز الإدخال على معظم الاستهلاك، وكيف يمكن تنظيم السياق لزيادة الاستفادة من ذاكرة التخزين المؤقت للبادئة.
بعد دمج وكيل متعدد الخطوات في منتجاتها، تكتشف فرق كثيرة المشكلة عند مراجعة الفاتورة في نهاية الشهر: المستخدم قدّم طلبًا واحدًا فقط، لكن استهلاك Token بلغ عشرات أضعاف استهلاك محادثة عادية. غالبًا ما يكون رد الفعل الأول هو أن «مخرجات النموذج مطوّلة أكثر من اللازم»، فتتجه الفرق إلى تقليصها. لكن الجزء الأكبر من الاستهلاك يأتي في الواقع من الإدخال، وتحديدًا من سجل السياق الذي يُعاد إرساله في كل جولة.
هذا ليس مجرد تخمين مبني على الخبرة. فقد عرضت مشاركات هندسية منشورة مؤخرًا أرقامًا محددة: في سيناريوهات الإنتاج المحلية، يؤدي طلب المستخدم الواحد إلى نحو 7.2 استدعاء للنموذج في المتوسط؛ وفي سلسلة من 50 خطوة، تشكل رموز الإدخال نحو 99.4%، مقابل نحو 0.6% فقط للمخرجات. وتصف فرق محركات الاستدلال أحمال عمل الوكلاء بصورة مشابهة: بادئات طويلة، ومخرجات قصيرة، ودورات متعددة.
ما الذي ستستفيده؟ بعد قراءة المقال، ستفهم بنية فاتورة Token للمهام الطويلة التي ينفذها الوكيل، ولماذا يساعد التخزين المؤقت للبادئة على خفض التكلفة، وستتعرف على 5 طرق لتنظيم السياق يمكنك تطبيقها على مستوى التطبيق.
أبرز النقاط حول فاتورة الرموز في مهام الوكيل الطويلة
يلخّص الجدول التالي نتائج المقال، ثم تتناول الأقسام اللاحقة كل نقطة بالتفصيل.
| النقطة | التوضيح | فائدتها لك |
|---|---|---|
| يتضاعف عدد الاستدعاءات | يتطلب طلب المستخدم الواحد نحو 7.2 استدعاءات للنموذج في المتوسط، وليس من النادر أن تتجاوز المهام المعقدة 50 خطوة | قدّر التكلفة لكل «مهمة»، لا لكل «طلب» |
| المدخلات تستحوذ على معظم التكلفة | في سلسلة من 50 خطوة، تشكّل المدخلات نحو 99.4% والمخرجات نحو 0.6% | ابدأ بتقليل المدخلات؛ فتقليل المخرجات أثره محدود |
| السياق المتكرر هو السبب الرئيسي | يُعاد تمرير السياق السابق في كل خطوة، وتُحتسب تكلفة المحتوى نفسه مرارًا | تعرّف على المصدر الحقيقي للتكلفة |
| يمكن إعادة استخدام ذاكرة التخزين المؤقت للبادئة | إذا وُجد الجزء المتطابق من البادئة في ذاكرة التخزين المؤقت، يمكن تجنّب تكرار حسابات المعالجة المسبقة (prefill) | السياق ذو البنية المستقرة أقل تكلفة |
| البنية تحدد معدل الاستفادة من ذاكرة التخزين المؤقت | ثبّت الموجهات وبنية الأدوات، وضع المعلومات المتغيرة في النهاية، واضغط السجل عند الحاجة | خفّض التكلفة دون تغيير النموذج |
شرح تكاليف الرموز في مهام الوكيل الطويلة
أكبر فرق بين الوكيل والمحادثة العادية هو «الحلقة المتكررة». لنأخذ إعداد عرض PPT مثالًا: يقرأ النظام المواد، ويخطط للمحتوى، وينشئ الشرائح واحدة تلو الأخرى، ويستخدم الأدوات لإعداد العرض، ثم يتحقق من النتيجة. تبدو هذه مهمة واحدة للمستخدم، لكنها داخل النظام تتضمن جولات متعددة من الاستدلال واستدعاءات الأدوات. وفي كل خطوة قد يُعاد قراءة السياق، وإذا لم تكن النتيجة مرضية، يعود النظام لتعديلها.
في كل استدعاء، يتلقى النموذج «موجه النظام + تعريفات الأدوات + السجل الكامل حتى تلك اللحظة + المعلومات الجديدة في هذه الجولة». يزداد السجل طولًا مع كل جولة، بينما تكون الإضافات الجديدة محدودة. وبعد عشرات الجولات، تُحتسب تكلفة البادئة نفسها عشرات المرات. هكذا تصل نسبة المدخلات إلى 99.4%.
لماذا يفوق عدد رموز الإدخال رموز الإخراج في مهام الوكيل الطويلة؟
تتضح الصورة أكثر من منظور محرك الاستدلال. يضرب فريق TokenSpeed مثالًا بوكيل برمجي: يواصل النموذج التفكير، ويستدعي الأدوات، ويحصل على النتائج، ثم يستأنف التفكير. وتتكون العملية كلها من حلقات متتابعة من الطلبات القصيرة. قد يحمل الطلب الأول سياقًا افتتاحيًا يبلغ عشرات الآلاف من الرموز، بينما يقتصر خرج كل حلقة لاحقة غالبًا على بضع مئات من الرموز.
يقارن الجدول التالي بين أعباء عمل الدردشة وأعباء عمل الوكيل، لمساعدتك على تحديد الفئة التي ينتمي إليها تطبيقك.
| المعيار | عبء عمل الدردشة التقليدية | عبء عمل مهام الوكيل الطويلة |
|---|---|---|
| شكل الطلب | سؤال وجواب، مع توليد الرد كاملًا دفعة واحدة | حلقات متعددة من الطلبات القصيرة تتخللها استدعاءات للأدوات |
| طول البادئة | قصير عادةً | قد يبدأ بعشرات الآلاف من الرموز ويزداد مع كل حلقة |
| خرج كل جولة | طويل نسبيًا | غالبًا بضع مئات من الرموز فقط |
| إعادة استخدام السياق | يُحمّل مرة واحدة ثم يُحرّر | تُرسل البادئة نفسها مرارًا خلال المهمة |
| العنصر المسيطر على التكلفة | لكل من الإدخال والإخراج وزن مؤثر | يستحوذ الإدخال، وخاصة البادئة المتكررة، على معظم التكلفة |
كيف تعمل ذاكرة التخزين المؤقت للبادئة في مهام الوكيل الطويلة؟
يعالج محرك الاستدلال الطلب على مرحلتين: في مرحلة المعالجة المسبقة (prefill)، يحسب المدخلات كاملةً وينشئ ذاكرة المفاتيح والقيم المؤقتة (KV Cache)؛ ثم يولّد رموز الإخراج واحدًا تلو الآخر في مرحلة فك الترميز (decode). في سيناريوهات الوكلاء، تحتاج بادئة تضم عشرات الآلاف من الرموز إلى المعالجة المسبقة في كل جولة، وهنا تكمن التكلفة. أما إذا كانت البادئة نفسها قد حُسبت سابقًا وما زالت نتيجتها في الذاكرة المؤقتة، فيمكن إعادة استخدامها مباشرةً وتجنب تكرار هذا الحساب.
يرى فريق محرك الاستدلال أن معدل إعادة استخدام KV Cache عامل حاسم في تكلفة الاستدلال. ووفقًا لما ورد في العرض، يُقال إن معدل إعادة استخدام الذاكرة المؤقتة لدى DeepSeek يتجاوز 99%، بينما يتراوح حاليًا بين 70% و80% في معظم أنظمة القطاع. أما في أعباء عمل الوكلاء، فعادةً ما يتجاوز معدل العثور على البادئة في الذاكرة المؤقتة أثناء المعالجة المسبقة 90%، وعند العثور عليها لا يلزم سوى حساب بضع مئات من الرموز الإضافية.
وهناك تفصيل يسهل إغفاله: تتم مطابقة البادئة المخزنة مؤقتًا من البداية، جزءًا بعد جزء. في مراحله الأولى، استلهم TokenSpeed من SGLang واستخدم شجرة Radix Tree لإدارة ذاكرة البادئة المؤقتة؛ إذ تمثل كل عقدة في الشجرة جزءًا من تسلسل الرموز، وتبدأ مطابقة الطلب من الجذر. ورغم الانتقال لاحقًا إلى تصميم Flat KV، ظلت إعادة الاستخدام تتم بوحدات من الكتل المنطقية ثابتة الحجم، وتضم كل منها 128 رمزًا. والخلاصة لمطوري التطبيقات مباشرة: يكفي اختلاف رمز واحد في البداية حتى يتعذر إعادة استخدام المحتوى الذي يليه.
كيفية تنظيم السياق لرفع معدل الاستفادة من ذاكرة التخزين المؤقت للبادئة في المهام الطويلة للوكيل
بعد فهم آلية مطابقة ذاكرة التخزين المؤقت، يصبح اتجاه التحسين واضحًا: اجعل بداية كل طلب طويلة قدر الإمكان وحافظ على ثباتها. يعتمد فريق WorkBuddy على تثبيت الموجه وبنية الأدوات، ووضع المعلومات المتغيرة في نهاية السياق، ثم ضغط السجل عندما يطول السياق. فيما يلي 5 ممارسات قابلة للتنفيذ.
| الممارسة | الإجراء | أمثلة شائعة على ما يجب تجنبه |
|---|---|---|
| 1. تثبيت موجه النظام | إبقاء موجه النظام ثابتًا حرفيًا، وإصدار تغييرات النسخ بشكل مجمّع | إدراج الوقت الحالي أو اسم المستخدم أو أمثلة عشوائية في البداية |
| 2. تثبيت بنية الأدوات | الحفاظ على ترتيب قائمة الأدوات وأوصاف المعاملات دون تغيير | إضافة الأدوات أو حذفها حسب الحاجة في كل جولة، أو تغيير ترتيب تسلسلها |
| 3. وضع المعلومات المتغيرة في النهاية | إلحاق الطوابع الزمنية وملاحظات الجولة الحالية والحالة الديناميكية في النهاية | كتابة «التقدم الحالي» في أعلى موجه النظام |
| 4. إلحاق السجل دون إعادة كتابته | إبقاء السجل المرسل كما هو، وإلحاق المحتوى الجديد فقط | إعادة تنسيق الرسائل السابقة أو ترتيبها في كل جولة |
| 5. ضغط السجل على مراحل | ضغط السجل مرة واحدة عند نقطة تحقق عندما يصبح السياق طويلًا، ثم متابعة إلحاق المحتوى | إعادة توليد الملخص في كل جولة، مما يؤدي إلى تغير البادئة باستمرار |
تثبيت الموجهات وبنية الأدوات في مهام الوكلاء الطويلة
من السهل إغفال النقطتين الأولى والثانية. تضيف أطر عمل كثيرة التاريخ الحالي إلى موجه النظام، أو تختار الأدوات ديناميكيًا بحسب المرحلة. وفي الحالتين، تتغير بداية الطلب في كل جولة، فلا تعود ذاكرة التخزين المؤقت للبادئة صالحة، بدءًا من أول رمز (Token). والأفضل أن يقتصر موجه النظام على القواعد والأدوار، وأن تُضاف معلومات مثل التاريخ في رسالة عادية في النهاية. كذلك، اعرض قائمة الأدوات الكاملة دفعة واحدة، واستخدم الموجه لتحديد الأدوات المسموح بها في كل مرحلة، بدلًا من تغيير القائمة نفسها.
انتبه أيضًا إلى طريقة التسلسل. فقد يختلف ترتيب حقول JSON لتعريف الأداة نفسه بين العمليات، ما ينتج عنه بادئتان مختلفتان على مستوى البايتات. يُنصح بترتيب تعريفات الأدوات ترتيبًا ثابتًا قبل إرسالها، وتسجيل قيمة التجزئة للبادئة في السجلات، لتسهيل تشخيص الحالات التي لا تتحقق فيها إصابة لذاكرة التخزين المؤقت رغم عدم تغيير التعريف.
المفاضلة بين ضغط السجل وإعادة استخدام ذاكرة التخزين المؤقت في مهام الوكلاء الطويلة
تتضمن النقطة الخامسة مفاضلة مهمة. يقلل ضغط السجل طول المدخلات، لكنه يغيّر البادئة، ما يؤدي حتمًا إلى عدم الاستفادة من ذاكرة التخزين المؤقت في تلك الجولة. وإذا ضغطت السجل في كل جولة، فأنت تتخلى عن إعادة استخدام الذاكرة المؤقتة في كل مرة. لذا من الأفضل وضع حد للضغط، كأن تُجريه عندما يصل السياق إلى طول معين أو عند انتهاء مهمة فرعية. بعد ذلك، استخدم النسخة المضغوطة كبادئة ثابتة جديدة، واكتفِ بإضافة المحتوى دون إعادة كتابة ما سبق.
قد لا يبدو فرق يُذكر بين الترتيبين في الرسم عند النظر إلى طلب واحد، لكن الفارق في التكلفة يصبح واضحًا في مهمة طويلة تمتد لعشرات الجولات. ولمعرفة أي الترتيبين يستخدمه تطبيقك، فإن أبسط طريقة هي متابعة تغيّر رموز الإدخال في كل جولة عبر سجلات الاستدعاءات. توفر APIYI apiyi.com فوترة موحدة وإحصاءات للاستخدام وسجلات للاستدعاءات، ما يتيح مقارنة بيانات نماذج متعددة في مكان واحد، ويساعد في تشخيص بنية التكاليف.
دليل سريع لتحسين فاتورة الرموز في مهام الوكيل الطويلة
لا يتناول هذا القسم أي شفرة برمجية، بل يقدم خطوات عملية للتشخيص يمكنك تنفيذها بالترتيب.
الخطوة الأولى: تقسيم فاتورة الرموز حسب المهمة
- أنشئ معرّفًا لكل مهمة مستخدم، وأدرجه في سجل كل استدعاء للنموذج ضمن تلك المهمة.
- سجّل عدد رموز الإدخال والإخراج من معلومات
usageفي كل استجابة. يعيد بعض المزوّدين أيضًا عدد الرموز المستفيدة من الذاكرة المؤقتة بشكل منفصل؛ راجع الوثائق الرسمية لمعرفة أسماء الحقول الدقيقة. - اجمع ثلاثة مؤشرات لكل مهمة: عدد الاستدعاءات، ونسبة رموز الإدخال إلى الإخراج، ونسبة الرموز المستفيدة من الذاكرة المؤقتة.
إذا كنت تستدعي نماذج من عدة مزوّدين، فغالبًا ما تختلف طريقة تسجيل البيانات بينهم. عند الوصول إليها جميعًا عبر APIYI، يمكنك الاطلاع على تفاصيل استخدام كل نموذج وسجلات استدعائه من لوحة تحكم واحدة. وبالربط مع معرّفات المهام التي سجّلتها، تحصل على صورة كاملة لتكلفة كل مهمة والخطوة التي صُرفت فيها.
الخطوة الثانية: تحديد موضع تغيّر البادئة
- اختر طلبين متتاليين من المهمة نفسها، وقارن موجه النظام وتعريفات الأدوات والرسائل السابقة جزءًا بجزء، للتحقق من تطابقها حرفيًا.
- ركّز على مواضع ظهور الحقول المتغيرة، مثل الطوابع الزمنية والأرقام العشوائية وحالة المستخدم.
- تحقق من ثبات ترتيب تسلسل تعريفات الأدوات والرسائل بين الطلبات المتعددة.
الخطوة الثالثة: إجراء التعديلات وفق الممارسات الخمس وإعادة الاختبار
- انقل المحتوى المتغير إلى النهاية، وثبّت موجه النظام وقائمة الأدوات.
- حدّد عتبة لضغط السجل، واجعل الضغط عند نقاط تحقق بدلًا من إجرائه في كل جولة.
- شغّل مجموعة المهام الاختبارية نفسها على الإصدارين قبل التعديل وبعده، ثم قارن عدد رموز الإدخال ونسبة إصابات ذاكرة التخزين المؤقت لكل مهمة.
🚀 نصيحة للبدء: احرص على استخدام مجموعة المهام نفسها والنموذج نفسه في المقارنة قبل التعديل وبعده، وإلا فلن تكون البيانات قابلة للمقارنة. بفضل الواجهة الموحدة من APIYI، يمكنك إعادة الاختبار بنموذج آخر دون تكييف كل واجهة على حدة، كما تُجمع إحصاءات الاستخدام في مكان واحد، مما يسهل مراقبة أثر كل من «تحسين البنية» و«اختلاف النموذج» على حدة.
حدود تقديرات التكلفة
قدّمت WorkBuddy تقديرًا يستند إلى حجم مهامها والأسعار المعلنة للفئة الرائدة من TokenHub: عند وصول معدل الاستفادة من ذاكرة التخزين المؤقت إلى 90%، يمكن أن تنخفض التكلفة المقدّرة للمهمة الواحدة من نحو 21.06 يوان إلى نحو 3.36 يوان. لكن هذه الأرقام ترتبط بطول سياق وشروط تسعير محددة لم يُكشف عنها بالكامل، لذا لا يمكن إعادة حسابها، كما لا يمكن تطبيقها مباشرةً على تطبيقك.
| العامل المؤثر | لماذا يغيّر النتيجة | ما الذي تحتاج إلى التحقق منه |
|---|---|---|
| طول السياق | كلما طالت البادئة، زاد التوفير الناتج عن إعادة استخدام ذاكرة التخزين المؤقت | متوسط طول البادئة في مهامك |
| طريقة احتساب تكلفة التخزين المؤقت | يختلف الخصم على الجزء المستفاد منه من ذاكرة التخزين المؤقت بين المزوّدين | أسعار التخزين المؤقت في الوثائق الرسمية للنموذج المستهدف |
| شروط تفعيل التخزين المؤقت | تختلف قواعد الحد الأدنى للطول ومدة الصلاحية وغيرها | قواعد التفعيل وانتهاء الصلاحية في الوثائق الرسمية |
| الفاصل بين الاستدعاءات | إذا طال الفاصل بين جولتين، فقد تنتهي صلاحية ذاكرة التخزين المؤقت | مدى توافق وقت تنفيذ الأدوات مع مدة صلاحية ذاكرة التخزين المؤقت |
| عدد خطوات المهمة | كلما زاد عدد الخطوات، زاد الأثر التراكمي لتكرار البادئة | توزيع عدد الخطوات في المهام الفعلية |
ممارسات إضافية لخفض تكلفة الرموز في مهام الوكلاء الطويلة
إلى جانب تنظيم السياق، تضمنت المشاركة نفسها استراتيجيتين على مستوى التطبيق يمكن استخدامهما مع التخزين المؤقت للبادئة.
- اختيار النموذج حسب الخطوة: ذكر فريق WorkBuddy أن نحو 80% من الخطوات البسيطة يمكن إسنادها إلى نموذج خفيف، ما يخفض تكلفة المهمة الواحدة بنحو 57%. فخطوات مثل تنظيم المعلومات وتحويل التنسيقات لا تحتاج بالضرورة إلى نموذج رائد.
- معالجة الإخفاقات حسب السبب: عند انتهاء المهلة أو رفض الطلب أو حدوث عطل لدى المزوّد، يمكن إعادة المحاولة بعدد محدود، أو تعديل السياق، أو تبديل النموذج بحسب سبب المشكلة. أما إعادة المحاولة بلا حدود فقد تؤدي إلى احتساب تكلفة البادئة الطويلة نفسها مرارًا.
تجدر الإشارة إلى أن تبديل النموذج يعني استخدام ذاكرة تخزين مؤقت مختلفة، وبالتالي يبدأ إعادة استخدام البادئة من الصفر. لذا، عند تصميم آلية التوجيه، يُفضّل إبقاء الخطوات المتتابعة للمهمة الفرعية نفسها على النموذج ذاته قدر الإمكان، وتأجيل التبديل إلى الحدود الفاصلة بين المهام الفرعية.
الأسئلة الشائعة FAQ
س1: ما التخزين المؤقت للبادئة في مهام الوكيل الطويلة؟
يعني التخزين المؤقت للبادئة أن خدمة الاستدلال تحفظ بادئة الإدخال التي سبق حسابها في ذاكرة KV Cache، وتعيد استخدامها مباشرةً عندما تبدأ الطلبات اللاحقة بالبادئة نفسها، مما يوفر حسابات مرحلة التعبئة المسبقة (prefill). وبما أن الوكيل يحمل سجلًا طويلًا ومتكررًا في كل جولة، فهو مناسب بشكل خاص للاستفادة من هذه الآلية.
س2: ما الفرق بين التخزين المؤقت للبادئة وضغط السياق السابق؟
لا يقلل التخزين المؤقت للبادئة محتوى الإدخال، بل يجعل حساب الأجزاء المتكررة أقل تكلفة. أما ضغط السجل فيختصر الإدخال مباشرةً، لكنه يغيّر البادئة، مما يمنع الاستفادة من ذاكرة التخزين المؤقت في تلك الجولة. لذا يُفضّل الجمع بينهما: إضافة المحتوى فقط أثناء العمل للحفاظ على فرص الاستفادة من الذاكرة المؤقتة، ثم ضغط السجل عند الوصول إلى نقطة تحقق.
س3: هل تنطبق نسبة الإدخال البالغة 99.4% على جميع الوكلاء؟
ليس بالضرورة. هذا الرقم مأخوذ من تجربة منشورة لسلسلة استدعاءات من 50 خطوة. قد تكون نسبة الإدخال أقل في المهام ذات الخطوات الأقل أو المخرجات الأطول في كل جولة. لكن عندما تتكون المهمة من «بادئة طويلة، ومخرجات قصيرة، وجولات متكررة»، فعادةً ما يشكّل الإدخال الحصة الأكبر. ويُنصح بالتحقق من ذلك باستخدام سجلات تطبيقك.
س4: ما سيناريوهات الوكلاء الأكثر استفادة من تحسين التخزين المؤقت للبادئة؟
– **وكلاء البرمجة**: سياق المستودع طويل، وتتكرر دورات قراءة الملفات وتعديل الشفرة وتشغيل الاختبارات.
– **إنشاء المستندات أو عروض PPT**: تُقرأ المواد أولًا، ثم تُنشأ الصفحات تباعًا، مما يجعل البادئة شديدة التكرار.
– **وكلاء تحليل البيانات**: تبقى بنية الجداول وأوصاف المؤشرات ثابتة، وتُضاف نتائج الاستعلامات فقط في كل جولة.
س5: كيف أفهم بسرعة توزيع رموز الإدخال والإخراج في تطبيقي؟
أبسط طريقة هي تجميع بيانات الاستخدام (usage) لكل جولة بحسب معرّف المهمة. وإذا كان تطبيقك يستخدم عدة نماذج، يمكنك استدعاؤها جميعًا عبر APIYI على apiyi.com. توفر المنصة إحصاءات الاستخدام وسجلات الاستدعاءات، مما يسهل مراجعة توزيع الإدخال والإخراج حسب النموذج والفترة الزمنية. أما دعم المنصة للتخزين المؤقت للموجهات في كل نموذج وطريقة احتسابه، فارجع إلى التوضيحات الواردة في وثائق المنصة.
س6: ما القيود المعروفة للتخزين المؤقت للبادئة؟
– تختلف شروط تفعيله بين المزوّدين، مثل الحد الأدنى للطول ومدة الصلاحية، لذا يجب مراجعة الوثائق الرسمية لكل منهم.
– إذا استغرق تنفيذ الأداة وقتًا طويلًا، فقد تنتهي صلاحية الذاكرة المؤقتة قبل الجولة التالية.
– يؤدي تغيير النموذج أو تعديل موجه النظام إلى إبطال الذاكرة المؤقتة بالكامل.
– يختلف الخصم على الأجزاء المستفيدة من الذاكرة المؤقتة بحسب النموذج، لذا يجب قياس التوفير فعليًا.
أهم النقاط حول فاتورة التوكنات في مهام Agent الطويلة
- احسب التكلفة لكل مهمة: يتضمن الطلب الواحد نحو 7.2 استدعاء، وقد تتجاوز المهمة الطويلة 50 خطوة.
- المدخلات هي العامل الأكبر: في سلسلة من 50 خطوة، تشكّل المدخلات نحو 99.4%، لذا فإن تقليص المخرجات محدود الأثر.
- تبدأ مطابقة ذاكرة التخزين المؤقت من البداية: اختلاف توكن واحد في البداية يمنع إعادة استخدام كل ما يليه.
- بنية السياق أهم من النموذج: ثبّت الموجهات وبنية الأدوات، وضع المعلومات المتغيرة في النهاية.
- اضغط السياق على فترات: اضغطه مرة عند نقاط المراجعة، وتجنب إعادة كتابة البادئة في كل جولة.
- لا تعمّم التقديرات: تعتمد أرقام التكلفة المنشورة على أطوال وأسعار محددة، لذا عليك إعادة القياس بنفسك.
- راقب أولًا ثم حسّن: استخدم إحصاءات الاستخدام وسجلات الاستدعاء في APIYI لتحليل مكونات الفاتورة.
الخلاصة
أهم الاستنتاجات حول فاتورة التوكنات في مهام Agent الطويلة:
- بنية الفاتورة: تأتي معظم التكلفة من سياق المحادثة السابق الذي يُعاد تضمينه في كل جولة، وتشكل توكنات المدخلات النسبة الأكبر.
- مبدأ خفض التكلفة: يتيح التخزين المؤقت للبادئة تجنّب إعادة حساب مرحلة التهيئة المسبقة (prefill) للبادئات المتكررة، ويتحدد معدل الاستفادة منه بحسب بنية السياق.
- التطبيق العملي: ثبّت الموجهات والأدوات، وضع المعلومات المتغيرة في النهاية، واكتفِ بإضافة المعلومات إلى السجل، واضغطه على مراحل، مع اختيار النموذج المناسب لكل خطوة.
يُنصح بتخصيص أسبوع أولًا لتحليل السجلات حسب المهمة، والتحقق من نسبة المدخلات ومعدل الاستفادة من ذاكرة التخزين المؤقت لديك، ثم تطبيق الممارسات الخمس الواردة في هذا المقال واحدة تلو الأخرى. وعند استخدام عدة نماذج، يمكنك ربطها عبر APIYI على apiyi.com، والاطلاع على بيانات الاستخدام وسجلات الاستدعاء في مكان واحد، لتقييم الأثر الفعلي لكل خطوة تحسين باستخدام البيانات نفسها.
📚 المراجع
- بناء الجيل القادم من محركات استدلال نماذج اللغة الكبيرة للتفكير القائم على الوكلاء: ملخص عرض TokenSpeed في مؤتمر AICon 2026 في شنتشن
- الرابط:
infoq.cn/article/YwAayF1ylWb7oN4P0lyC -
الوصف: يستعرض خصائص أحمال عمل الوكلاء من حيث «البادئة الطويلة والمخرجات القصيرة»، ومعدل إعادة استخدام ذاكرة KV Cache، والتصميم الهيكلي للتخزين المؤقت للبادئات.
-
من استدعاء النموذج إلى إنجاز المهمة: كيف تدخل MaaS مرحلة الإنتاج للوكلاء؟: ملخص جلسة Tencent Cloud المخصصة لـ MaaS
- الرابط:
infoq.cn/article/zZutPTX8bsr6NWQYNC3A - الوصف: يتضمن بيانات شاركتها WorkBuddy حول عدد الاستدعاءات، ونسبة المدخلات، والتخزين المؤقت للبادئات، وتوجيه الطلبات إلى النماذج.
الكاتب: الفريق التقني في APIYI
التواصل التقني: للاستفسار عن استدعاء نماذج متعددة وتحليل الاستخدام، يمكنكم التواصل معنا عبر APIYI على apiyi.com. ولمزيد من الموارد، تفضلوا بزيارة مركز التوثيق docs.apiyi.com.
