واجهة برمجة التطبيقات الدفعية: تقليل هدر النطاق الترددي وتحسين كفاءة واجهة برمجة التطبيقات

واجهة برمجة التطبيقات الدفعية: تقليل هدر النطاق الترددي وتحسين كفاءة واجهة برمجة التطبيقات

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

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

[جرّب الاستدلال الدفعي بخصم 50%

قم بتشغيل التنبؤات على نطاق واسع بشكل أسرع وأرخص مع النماذج المدعومة:
qwen/qwen3-vl-235b-a22b-instruct, openai/gpt-oss-120b, deepseek/deepseek-r1-0528, qwen/qwen3-4b-fp8.](https://novita.ai/docs/guides/llm-batch-api)

جرّب الاستدلال الدفعي بخصم 50%

قم بتشغيل التنبؤات على نطاق واسع بشكل أسرع وأرخص مع النماذج المدعومة:
qwen/qwen3-vl-235b-a22b-instruct, openai/gpt-oss-120b, deepseek/deepseek-r1-0528, qwen/qwen3-4b-f

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

واجهة برمجة التطبيقات الدفعية: تجمع طلبات واجهة برمجة التطبيقات المستقلة المتعددة (مثل GET, POST, PUT, DELETE) في طلب HTTP واحد.
بنية الاستجابة: يعيد الخادم نتائج جميع الطلبات الفرعية بالترتيب، مع الإشارة إلى نجاح أو فشل كل منها.

الفرق الرئيسي بين واجهة برمجة التطبيقات الدفعية وواجهات برمجة التطبيقات القياسية

الطلبات العادية

Client
 ├──► Request 1 (/user/1)
 │       └──► Server Response 1
 ├──► Request 2 (/user/2)
 │       └──► Server Response 2
 └──► Request 3 (/order)
         └──► Server Response 3

طلب دفعي

Client
 └──► Single Request (/batch)
          ├─ Sub-request 1: GET /user/1
          ├─ Sub-request 2: GET /user/2
          └─ Sub-request 3: POST /order
          ↓
       Server processes all
          ↓
       Combined Response:
          [Result1, Result2, Result3]

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

تقليل زمن الاستجابة الشبكي من خلال إرسال طلب واحد مجمع بدلاً من العديد من الطلبات.

خفض النفقات العامة للنطاق الترددي والاتصال، حيث يتم مشاركة الرؤوس ورسائل المصافحة.

تحسين أداء العميل، خاصة على الأجهزة المحمولة أو الشبكات البطيئة.

تبسيط منطق المعاملات، مما يتيح معالجة موحدة للأخطاء أو التراجع عن العمليات.

تحسين إنتاجية بوابة واجهة برمجة التطبيقات، ومنع فيض الطلبات.

حالات الاستخدام النموذجية لواجهة برمجة التطبيقات الدفعية

السيناريو الوصف
1. استعلامات البيانات المجمعة استرداد عدة مستخدمين أو منتجات أو منشورات مرة واحدة لتجنب الطلبات المتكررة.
2. الكتابة أو التحديث المجمع إنشاء أو تحديث عدة سجلات في عملية واحدة (مثل التحميل الدفعي، تحديث المخزون).
3. تحسين أداء الواجهة الأمامية تقليل عدد مكالمات HTTP من المتصفحات أو التطبيقات المحمولة لتحقيق أوقات تحميل أسرع.
4. تجميع مهام الخلفية في أنظمة الخدمات المصغرة، دمج عدة طلبات واجهة برمجة تطبيقات داخلية في طلب خارجي واحد.
5. مزامنة البيانات مزامنة حالات عدة موارد أو تنفيذ عمليات دفعية (مثل وضع العلامات، الحذف).
6. تحسين حدود المعدل تقليل حمل بوابة واجهة برمجة التطبيقات وتوفير النطاق الترددي من خلال توحيد الطلبات.

العوامل الرئيسية التي تؤثر على كفاءة واجهة برمجة التطبيقات الدفعية

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

تُظهر تحليلات الصناعة (Growth-onomics) أن التخفيضات في التكاليف تبلغ حوالي 20-45%، ويعود السبب الرئيسي في ذلك إلى عدد أقل من الجولات الشبكية، ونفقات عامة أقل للاتصال، ومعالجة مركزية، على الرغم من أن التوفير الفعلي يعتمد على تكرار الطلبات، وحجم الدفعة، وتصميم النظام.

ماذا عن زمن الاستجابة—هل يمكن لواجهات برمجة التطبيقات الدفعية حقًا الانتهاء “خلال 24 ساعة”؟

تعمل واجهات برمجة التطبيقات الدفعية عادةً بشكل غير متزامن مع زمن استجابة أعلى بكثير من واجهات برمجة التطبيقات في الوقت الفعلي؛ فالعديد من الأنظمة تنفذ العمليات كل ساعة أو كل يوم، لذلك يعتمد “خلال 24 ساعة” على اتفاقية مستوى الخدمة (SLA) بدلاً من كونه مضمونًا.

هل يؤثر حجم الدفعة أو حجم الملف على السرعة؟

نعم. تزيد الدفعات الأكبر حجمًا (مثل المزيد من أسطر JSONL) من وقت النقل والتحليل بشكل شبه خطي؛ وبينما تتحسن الإنتاجية، يزداد الوقت الإجمالي لإكمال كل دفعة.

لماذا تعتبر واجهات برمجة التطبيقات الدفعية أفضل لأحمال العمل ذات الإنتاجية العالية؟

من خلال تجميع آلاف الطلبات في عملية واحدة، تقلل واجهات برمجة التطبيقات الدفعية من النفقات العامة لكل طلب وتتيح التنفيذ المتوازي أو إعادة استخدام التخزين المؤقت، مما يحسن الإنتاجية بنسبة 17-92% في العمليات على نطاق واسع، على الرغم من أن هذا يأتي على حساب زمن استجابة أعلى.

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

واجهة برمجة التطبيقات الدفعية من Novita متوافقة للغاية مع واجهة OpenAI، حيث تدعم /v1/chat/completions و /v1/completions بحيث يمكن إعادة استخدام الكود الموجود مع تغييرات minimal. تقبل ملفات إدخال .jsonl حيث يمثل كل سطر طلبًا فرديًا لنفس النموذج، معرّفًا بمعرف custom_id فريد لتسهيل التتبع. الإخراج أيضًا بتنسيق JSONL، مما يجعل المعالجة اللاحقة على نطاق واسع والتحليل والتكامل بسيطًا وفعالاً.

جرّب خدمة واجهة برمجة التطبيقات الدفعية من Novita AI الآن!

1. إعداد ملف إدخال الدفعة الخاص بك

أنشئ ملف .jsonl، حيث كل سطر هو طلب واجهة برمجة تطبيقات واحد بتنسيق JSON.
مثال (batch_input.jsonl):

{"custom_id": "req-1", "body": {"model": "deepseek/deepseek-v3-0324", "messages": [{"role": "user", "content": "Summarize: batch API basics"}], "max_tokens": 200}}
{"custom_id": "req-2", "body": {"model": "deepseek/deepseek-v3-0324", "messages": [{"role": "system", "content": "You are concise."},{"role": "user", "content": "List 3 batch API use cases"}], "max_tokens": 150}}

القواعد:

  • طلب واحد لكل سطر.
  • يجب أن تستخدم جميع الطلبات نفس النموذج.
  • يجب أن يتضمن كل سطر معرف custom_id فريد.

2. تحميل ملف الإدخال وإنشاء دفعة

استخدم Python أو curl لتحميل الملف وبدء مهمة الدفعة فورًا.

Python

from openai import OpenAI

client = OpenAI(base_url="https://api.novita.ai/openai/v1", api_key="YOUR_API_KEY")

# Upload + create batch
uploaded = client.files.create(file=open("batch_input.jsonl", "rb"), purpose="batch")

batch = client.batches.create(
    input_file_id=uploaded.id,
    endpoint="/v1/chat/completions",
    completion_window="48h"
)

print("file_id:", uploaded.id)
print("batch_id:", batch.id)

curl

export API_KEY="YOUR_API_KEY"

# Upload file
upload_response=$(curl -s -X POST \
  -H "Authorization: Bearer ${API_KEY}" \
  -F 'file=@batch_input.jsonl' -F 'purpose=batch' \
  https://api.novita.ai/openai/v1/files)

# Extract file_id and start batch
file_id=$(echo $upload_response | jq -r '.id')

curl -X POST https://api.novita.ai/openai/v1/batches \
  -H "Authorization: Bearer ${API_KEY}" \
  -H "Content-Type: application/json" \
  -d "{\"input_file_id\": \"$file_id\", \"endpoint\": \"/v1/chat/completions\", \"completion_window\": \"48h\"}"

تحقق من مفتاح API الخاص بك

3. التحقق من حالة الدفعة

يمكنك التحقق من التقدم في أي وقت باستخدام معرف الدفعة.

batch = client.batches.retrieve("batch_xxx")
print(batch.status)

تتضمن الحالات:

  • VALIDATING – جاري فحص ملف الإدخال
  • PROGRESS – قيد التشغيل
  • COMPLETED – انتهى بنجاح
  • FAILED – فشل
  • EXPIRED – تجاوز نافذة 48 ساعة

4. استرداد النتائج

بمجرد الانتهاء، قم بتنزيل ملف النتائج عبر output_file_id:

output = client.files.content("file_xxx")
print(output.read().decode("utf-8"))

كل سطر في الإخراج يتوافق مع إدخال واحد، مطابقًا بمعرف custom_id.

نصائح:

يدعم فقط deepseek/deepseek-r1-0528

ما يصل إلى 50 000 طلب لكل دفعة

حجم ملف الإدخال ≤ 100 ميجابايت

نافذة الإكمال ثابتة عند 48 ساعة

يتم الاحتفاظ بالإخراج لمدة 30 يومًا

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

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

رمز الخطأ الوصف الحل
400 تنسيق طلب غير صالح تحقق من صيغة JSONL والحقول المطلوبة
401 فشل المصادقة تحقق من مفتاح API
404 لم يتم العثور على الدفعة تحقق من معرف الدفعة
429 تم تجاوز حد المعدل قلل من تكرار الطلبات
500 خطأ في الخادم تواصل مع المزود أو أعد المحاولة لاحقًا

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

ما هي نقاط النهاية التي توفرها Novita AI لعمليات واجهة برمجة التطبيقات الدفعية؟

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

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

Novita AI هي منصة سحابية للذكاء الاصطناعي تقدم للمطورين طريقة سهلة لنشر نماذج الذكاء الاصطناعي باستخدام واجهة برمجة التطبيقات البسيطة الخاصة بنا، مع توفير سحابة GPU بأسعار معقولة وموثوقة للبناء والتوسع.

قراءات موصى بها