تسعير الاستدلال بالدفعة (Batch Inference) لواجهات برمجة تطبيقات الذكاء الاصطناعي (AI API): متى توفر المهام غير المتزامنة (Asynchronous Jobs) المال

يعمل تسعير الاستدلال بالدفعة (Batch Inference) من خلال مقايضة زمن استجابة الطلب مقابل سعر أقل لكل رمز (token): حيث تقوم بإرسال وظيفة، ويقوم المزود بمعالجتها ضمن نافذة زمنية محددة (غالباً ما تصل إلى 24 ساعة)، وتدفع أقل مما كنت ستدفعه مقابل استدعاء متزامن وفوري. تعتمد جدوى هذه المقايضة كلياً على ما إذا كان عبء العمل الخاص بك يمكنه تحمل الانتظار.

تقارن هذه المقالة بين الاستدلال بالدفعة (غير المتزامن) واستدعاءات واجهة برمجة التطبيقات (API) المتزامنة القياسية، بناءً على وثائق واجهة برمجة تطبيقات الدفعة المنشورة من قبل OpenAI وGoogle، وتضع إطار عمل لاتخاذ القرار بشأن متى يوفر المسار غير المتزامن المال لمنتجك فعلياً.

أبرز النقاط

• توفر كل من OpenAI وGemini واجهة برمجة تطبيقات للدفعة تقبل وظائف للمعالجة غير المتزامنة بسعر مخفض مقارنة بالاستدعاءات المتزامنة؛ تأكد من نسبة الخصم الحالية الدقيقة على صفحة التسعير الخاصة بكل مزود قبل وضع الميزانية، حيث يمكن أن تتغير الأسعار.
• يناسب الاستدلال بالدفعة أعباء العمل التي تتحمل نافذة زمنية للإنجاز بدلاً من الحاجة إلى استجابة فورية: مثل التصنيف الضخم، وتوليد التضمينات (embeddings)، والتقييم دون اتصال (offline)، وتصنيف مجموعات البيانات، ووظائف التعبئة الخلفية (backfill).
• لا تناسب تسعير الدفعة عادةً الدردشة في الوقت الفعلي، ووكلاء البرمجة، وميزات المنتج التفاعلية، لأن نافذة المعالجة تجعلها غير صالحة للاستخدام في التفاعل المباشر مع المستخدم.
• تأتي أكبر المدخرات التراكمية عادةً من الجمع بين خصومات الدفعة واختيار النموذج وعمل كفاءة الأوامر (prompt efficiency)؛ راجع /models/rankings ودليل خفض تكاليف واجهة برمجة تطبيقات الذكاء الاصطناعي لمعرفة العوامل الأخرى.

ماذا يعني الاستدلال بالدفعة فعلياً؟

تعيد استدعاءات واجهة برمجة التطبيقات المتزامنة استجابة بمجرد انتهاء النموذج من توليدها، عادةً في غضون ثوانٍ. أنت تدفع سعراً لكل رمز مرتبط بهذه الفورية. يقلب الاستدلال بالدفعة النموذج: بدلاً من تبادل طلب واستجابة واحد، تقوم بإرسال ملف أو قائمة من الطلبات كوظيفة. يقوم المزود بوضع الوظيفة في قائمة الانتظار، ويعالجها خلال نافذة زمنية يتحكم فيها، ويجعل النتائج متاحة لك لاستردادها بمجرد اكتمالها.

هذه ليست تقنية استدلال جديدة داخل النموذج. إنها عقد تجاري وتشغيلي مختلف. يحصل المزود على فرصة لجدولة عبء العمل الخاص بك مقابل سعة احتياطية أو خارج أوقات الذروة، وفي المقابل يفرض سعراً أقل لكل رمز مما يفرضه مقابل طلب يجب عليه خدمته فوراً.

توثق كل من OpenAI وGoogle هذا النمط لواجهات برمجة التطبيقات الخاصة بهما:

• يصف مرجع Batch API الخاص بـ OpenAI إنشاء كائن دفعة من ملف طلبات مرفوع، وتتبع حالته، واسترداد المخرجات بمجرد اكتمال الوظيفة (platform.openai.com/docs/api-reference/batch/object).
• تصف وثائق Gemini Batch API من Google نموذجاً مشابهاً: إرسال دفعة من الطلبات، وتعمل الوظيفة بشكل غير متزامن، ويتم استرداد النتائج بعد المعالجة (ai.google.dev/gemini-api/docs/batch-api).

تختلف الآليات قليلاً بين المزودين (الإرسال القائم على الملفات، كائنات الوظائف، استطلاع الحالة، استرداد المخرجات)، لكن الشكل الأساسي متسق: أرسل الآن، واجمع لاحقاً، وادفع أقل لكل رمز مقارنة بالمكافئ المتزامن. تحقق من وثائق كل مزود الحالية لمعرفة نافذة المعالجة الدقيقة ونسبة الخصم التي تنطبق على حسابك ونموذجك، حيث أن هذه التفاصيل خاصة بالمزود وقابلة للتغيير.

كيف تعمل واجهات برمجة تطبيقات الدفعة الموثقة

على مستوى الآلية، يتبع كلا المزودين دورة حياة متشابهة:

1. تجهيز الطلبات. تقوم بتجميع طلبات الاستدلال الفردية التي تريد معالجتها، وعادة ما يتم تنسيقها كملف (تقبل OpenAI ملفاً من الطلبات مُعرفاً بمعرف مخصص؛ وتقبل Gemini دفعة من الطلبات المهيكلة).
2. إرسال الوظيفة. تقوم بإنشاء كائن دفعة أو مورد وظيفة يشير إلى مدخلاتك المرفوعة.
3. استطلاع أو انتظار الاكتمال. تنتقل الوظيفة عبر حالات (في قائمة الانتظار، قيد المعالجة، مكتملة، أو فشلت) حتى ينهي المزود المعالجة ضمن نافذته الموثقة.
4. استرداد المخرجات. بمجرد الاكتمال، تقوم بتنزيل أو جلب ملف المخرجات أو مجموعة النتائج، ومطابقة كل استجابة مع طلبها الأصلي حسب المعرف.

لا يقوم أي من المزودين بمعالجة وظائف الدفعة فوراً. هذا هو جوهر نموذج التسعير: تعمل الوظيفة وفق جدول المزود، وليس جدولك، وأنت تقبل تأخيراً محدوداً مقابل سعر أقل. إذا كان منتجك لا يتحمل هذا التأخير، فإن تسعير الدفعة غير متاح لك بغض النظر عن مقدار ما ستوفره على الورق.

متى يوفر تسعير الدفعة المال: قائمة تحقق للقرار

استخدم قائمة التحقق هذه قبل توجيه عبء عمل إلى نقطة نهاية للدفعة:

• هل يتمتع عبء العمل بشكل غير تفاعلي بطبيعته؟ تناسبه عمليات التصنيف عبر مجموعة بيانات، أو توليد التضمينات لمجموعة مستندات، أو عمليات الإشراف على المحتوى، أو وظائف التلخيص الليلية.
• هل يمكن لمنتجك تحمل نافذة المعالجة الموثقة؟ إذا كان المستخدم أو النظام التابع يحتاج إلى النتيجة في غضون ثوانٍ أو دقائق، فإن الدفعة لا تناسبك.
• هل الحجم كبير بما يكفي ليحدث فرقاً؟ تنطبق خصومات الدفعة لكل رمز، لذا فإن المدخرات المطلقة تتناسب مع الحجم. لن تؤثر حفنة من الطلبات على فاتورتك بشكل ملموس في أي من الحالتين.
• هل المهمة غير متغيرة (idempotent) أو قابلة لإعادة المحاولة بأمان؟ نظراً لأن وظائف الدفعة تعمل بشكل غير متزامن ويمكن أن تفشل جزئياً، يحتاج خط الأنابيب الخاص بك إلى التعامل مع إعادة الإرسال أو الاكتمال الجزئي دون إفساد الحالة التابعة.
• هل تدعم طبقة التنسيق الخاصة بك بالفعل استطلاع الوظائف غير المتزامنة؟ إذا كنت تبني هذا النمط لأول مرة، فخصص ميزانية زمنية هندسية لإرسال الوظائف، واستطلاع الحالة، ومطابقة المخرجات.

البعد	واجهة برمجة تطبيقات متزامنة	واجهة برمجة تطبيقات الدفعة (غير متزامنة)
زمن الاستجابة	ثوانٍ، عادةً	دقائق إلى ساعات، مقيدة بنافذة المزود الموثقة
التسعير	سعر قياسي لكل رمز	سعر مخفض لكل رمز مقارنة بالمتزامن، حسب وثائق المزود
أفضل ملاءمة	الدردشة، الوكلاء، ميزات المنتج المباشرة	التصنيف الضخم، التضمينات، التقييم دون اتصال، التعبئة الخلفية
التعامل مع الفشل	خطأ فوري في الاستدعاء	حالة على مستوى الوظيفة؛ ممكن حدوث فشل جزئي داخل الدفعة
النفقات الهندسية	طلب-استجابة بسيط	تتطلب منطق إرسال الوظيفة، والاستطلاع، واسترداد المخرجات
ترتيب المخرجات	يطابق ترتيب الاستدعاء	تتم مطابقتها حسب معرف الطلب المخصص، وليس ترتيب الاستدعاء

متى لا يناسب تسعير الدفعة؟

يعد الاستدلال بالدفعة خياراً سيئاً لأي شيء ينتظر فيه شخص أو نظام تابع الاستجابة. ويشمل ذلك:

• وكلاء المحادثة ومنتجات الدردشة. يتوقع المستخدم رداً في ثوانٍ، وليس بعد نافذة معالجة.
• مساعدو البرمجة وسير عمل البرمجة الوكيلية. تعتمد الأدوات المبنية حول نماذج مثل Claude Sonnet 5 أو Kimi K2.7 Code على حلقات تغذية راجعة ضيقة بين المطور والنموذج؛ سيؤدي التجميع (batching) إلى كسر التفاعل تماماً.
• توليد المحتوى في الوقت الفعلي للميزات الموجهة للمستخدم، بما في ذلك توليد الصور أو الفيديو عند الطلب من خلال واجهات برمجة تطبيقات مثل Nano Banana Pro أو Veo 3، حيث يشاهد المستخدم مؤشر تقدم.
• أي شيء يتطلب مستوى خدمة زمن استجابة معين، حتى لو كان هذا المطلب مرناً (مثلاً، أقل من دقيقة). تُقاس نوافذ الدفعة عادةً بالساعات، وليس بالثواني.

إذا كان جزء من خط الأنابيب الخاص بك يعمل في الوقت الفعلي وجزء آخر لا يعمل، فقم بتقسيم العمل. وجه الجزء التفاعلي عبر واجهة برمجة التطبيقات المتزامنة وادفع الجزء الضخم الذي يتحمل التأخير (إعادة الفهرسة الليلية، إعادة تصنيف مجموعات البيانات، عمليات التقييم) إلى نقطة نهاية الدفعة.

شكل طلب عملي

يختلف المخطط الدقيق بين كائن دفعة OpenAI وواجهة برمجة تطبيقات دفعة Gemini، لذا تعامل مع ما يلي كشكل توضيحي بدلاً من نسخة حرفية من تنسيق طلب أي من المزودين. تحقق من أسماء الحقول ونقاط النهاية الدقيقة مقابل الوثائق الحالية قبل تنفيذ ذلك.

# 1. تجهيز ملف من الطلبات، كل منها بمعرف مخصص
{"custom_id": "req-001", "method": "POST", "url": "/v1/chat/completions",
 "body": {"model": "your-selected-model", "messages": [{"role": "user", "content": "Classify this ticket."}]}}
{"custom_id": "req-002", "method": "POST", "url": "/v1/chat/completions",
 "body": {"model": "your-selected-model", "messages": [{"role": "user", "content": "Classify this ticket."}]}}

# 2. إرسال وظيفة الدفعة
POST /v1/batches
{
  "input_file_id": "file-abc123",
  "endpoint": "/v1/chat/completions",
  "completion_window": "24h"
}

# 3. استطلاع حالة الوظيفة
GET /v1/batches/{batch_id}
# يعيد الحالة: queued | in_progress | completed | failed

# 4. استرداد المخرجات بمجرد الاكتمال
GET /v1/files/{output_file_id}/content
# مطابقة كل استجابة مع طلبها حسب custom_id

نمط الهندسة الأساسي هو نفسه بغض النظر عن المزود: قم ببناء ملف الطلبات الخاص بك بمعرفات ثابتة، وأرسل الوظيفة، واستطلع الاكتمال، وطابق المخرجات مع قائمة طلباتك الأصلية. قم ببناء منطق إعادة المحاولة حول حالات الفشل الجزئي على مستوى الوظيفة، حيث يمكن أن تكتمل الدفعة مع فشل بعض الطلبات الفردية حتى لو نجحت الوظيفة نفسها.

الجمع بين خصومات الدفعة واختيار النموذج

يعد تسعير الدفعة عاملاً واحداً. وهو يتكامل مع، بدلاً من أن يحل محل، قرارات النموذج ومستوى الأوامر المغطاة في معيار توجيه نموذج الذكاء الاصطناعي ودليل خفض تكاليف واجهة برمجة تطبيقات الذكاء الاصطناعي. إن عبء العمل المؤهل للدفعة والذي يتم خدمته بواسطة نموذج منخفض التكلفة، مثل DeepSeek V4 Flash أو GLM-5.2 أو Gemini 3.5 Flash للمهام الصديقة للتوجيه، سيشهد عادةً مدخرات مطلقة أكبر من تطبيق أي من العاملين بمفرده. قبل الالتزام بوظيفة ضخمة لنموذج واحد وطبقة تسعير واحدة، تحقق من التسعير الحالي لكل نموذج وموقعه في /models/rankings، حيث تتغير الأسعار النسبية بين النماذج الرائدة والنماذج منخفضة التكلفة مع تحديث المزودين لتشكيلاتهم.

بالنسبة للفرق التي تقيم ما إذا كانت ستبني دعماً للدفعة على الإطلاق، فإن الحساب مباشر: قدر حجم الرموز الشهري للمهام التي تتحمل التأخير، وقارن خصم الدفعة الموثق مقابل إنفاقك المتزامن الحالي على نفس الحجم، وازن ذلك مقابل التكلفة الهندسية لبناء منطق إرسال الوظائف والاستطلاع. إذا كان الحجم صغيراً، فقد لا يعوض الخصم التعقيد المضاف.

القيود

تستند هذه المقارنة إلى الآليات العامة الموثقة من قبل OpenAI وGoogle لواجهات برمجة تطبيقات الدفعة الخاصة بهما كما لوحظ في 2026-07-14. نسب الخصم الدقيقة، وأطوال نافذة المعالجة، وتوافر كل نموذج، ومتطلبات تنسيق الملف هي أمور خاصة بالمزود، وتتغير بمرور الوقت، ولا يتم إعادة ذكرها هنا كأرقام ثابتة. تحقق من تسعير الدفعة الحالي والشروط مباشرة مقابل وثائق كل مزود قبل وضع الميزانية أو البناء. لا تغطي هذه المقالة أيضاً دعم الدفعة من كل مزود نموذج؛ تحقق مما إذا كان النموذج والمزود اللذان اخترتهما ينشران نقطة نهاية للدفعة على الإطلاق قبل التخطيط حولها.

الأسئلة الشائعة

ما مدى رخص الاستدلال بالدفعة مقارنة بالاستدعاءات المتزامنة؟ توثق كل من OpenAI وGoogle خصماً لمعالجة الدفعة بالنسبة لسعرها المتزامن القياسي، لكن النسبة المئوية الدقيقة خاصة بالمزود والوقت. تحقق من صفحة التسعير الحالية للمزود والنموذج الخاص بك قبل تقدير المدخرات.

ماذا يحدث إذا لم تنته وظيفة الدفعة الخاصة بي ضمن نافذة المعالجة؟ تصف وثائق المزود حالات الوظيفة (مثل queued، in_progress، completed، وfailed). راجع وثائق كل مزود حول كيفية تعامله مع الوظائف التي تتجاوز نافذة الاكتمال، حيث يمكن أن يختلف السلوك حسب المزود وهو قابل للتغيير.

هل يمكنني استخدام الاستدلال بالدفعة لميزات الدردشة في الوقت الفعلي؟ لا. تتم معالجة وظائف الدفعة بشكل غير متزامن ضمن نافذة يمكن أن تتراوح من دقائق إلى ساعات عديدة، مما يجعلها غير مناسبة لأي عبء عمل ينتظر فيه مستخدم أو نظام استجابة فورية. استخدم واجهة برمجة التطبيقات المتزامنة للميزات التفاعلية واحتفظ بنقاط نهاية الدفعة للمهام ذات الحجم الكبير التي تتحمل التأخير.

إذا كنت تقيم ما إذا كان تسعير الدفعة يناسب عبء العمل الخاص بك، فقارن الأسعار والتصنيفات الحالية لكل نموذج، ثم ابدأ برسم خرائط لمهامك التي تتحمل التأخير مقابل قائمة التحقق أعلاه قبل أن تلتزم بوقت هندسي لمنطق إرسال الوظائف والاستطلاع.