TokenLab توسع دعم GPT Image Edit API

قامت TokenLab بتوسيع واجهة برمجة تطبيقات (API) الخاصة بتعديل الصور لدعم أحدث سير عمل لتعديل الصور عبر GPT، بما في ذلك مدخلات الصور المتعددة واستطلاع المهام غير المتزامن (async task polling) لنموذج gpt-image-2. إذا كنت تقوم ببناء ميزات تعديل تعتمد على نماذج GPT Image، فإن نقطة نهاية التعديل (edit endpoint) تتعامل الآن مع كل من عمليات الرفع متعددة الأجزاء (multipart uploads) ومراجع الصور بتنسيق JSON، مع توفر وضع غير متزامن (async mode) للمهام الأكبر أو الأبطأ.

أبرز النقاط

• تقبل نقطة نهاية تعديل الصور كلاً من عمليات رفع الملفات متعددة الأجزاء ومراجع الصور بتنسيق JSON لعائلات النماذج المدعومة.
• يدعم gpt-image-2 صوراً مصدرية متعددة في طلب تعديل واحد.
• يعيد الوضع غير المتزامن (Async mode) مرجعاً للمهمة يمكنك استطلاع حالتها لمعرفة اكتمالها، وهو المسار الموصى به لعمليات التعديل التي تتضمن صوراً متعددة أو ذات زمن وصول مرتفع.
• تستمر عمليات التكامل الحالية المبنية على نقطة نهاية التعديل القياسية في العمل دون تغيير؛ دعم الوضع غير المتزامن هو إضافة جديدة.

ما الذي تغير

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

يعالج هذا التحديث هذه المشكلة بشكل مباشر. تتعرف نقطة النهاية /images/edit الآن على ما إذا كان الطلب موجهاً إلى gpt-image-2 وتوفر مسارين: مكالمة متزامنة قياسية لتعديلات الصور البسيطة والمفردة، ووضع غير متزامن لأي عمليات أكثر تعقيداً. الطلبات التي تحتوي على صور مصدرية متعددة، أو لوحات عمل (canvases) أكبر، أو تعليمات نصية أكثر ثقلاً هي مرشحات طبيعية للوضع غير المتزامن، لأنها تستغرق وقتاً أطول للاكتمال ولا ترغب في بقاء اتصال العميل مفتوحاً في انتظارها.

هذا ليس تغييراً جذرياً (breaking change). إذا كان تكاملك الحالي يستدعي نقطة نهاية التعديل بشكل متزامن، فسيستمر في العمل. المسار غير المتزامن اختياري، يتم تفعيله بواسطة معامل طلب، وشكل الاستجابة للمكالمات المتزامنة يظل دون تغيير.

عمليات الرفع متعددة الأجزاء مقابل مراجع الصور بتنسيق JSON

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

عمليات الرفع متعددة الأجزاء (Multipart form uploads): إذا كان تطبيقك يمتلك بالفعل بايتات الصورة، سواء من رفع مستخدم أو من أصل تم إنشاؤه مسبقاً، يمكنك إرسالها مباشرة كبيانات نموذج متعددة الأجزاء. هذا هو المسار الأبسط للكود من جانب الخادم الذي يقوم بتمرير ملف مباشرة من رفع العميل.

مراجع الصور بتنسيق JSON: إذا كانت صورك موجودة بالفعل في مكان يمكن الوصول إليه عبر رابط URL، أو قمت بإنشائها مسبقاً في طلب TokenLab ولديك مرجع لإعادة استخدامه، يمكنك تمرير هذا المرجع في نص JSON بدلاً من ذلك. هذا يتجنب إعادة رفع البايتات التي تمتلكها بالفعل وهو الخيار الأفضل عموماً لخطوط الإنتاج التي تربط خطوات الإنشاء والتعديل.

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

تعديلات الصور المتعددة مع gpt-image-2

الإضافة الوظيفية الأكبر هي دعم الصور المتعددة لنموذج gpt-image-2. بدلاً من تعديل صورة مصدرية واحدة، يمكنك الآن تمرير صور متعددة في طلب تعديل واحد والسماح للنموذج باستخدامها معاً، على سبيل المثال دمج صورة موضوع مع خلفية مرجعية، أو تطبيق نقل النمط باستخدام صورة ثانية كدليل.

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

الوضع غير المتزامن: متى وكيف تستخدمه

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

استخدم الوضع غير المتزامن عندما:

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

التزم بالوضع المتزامن عندما:

• تقوم بتعديل بسيط لصورة واحدة مع مطالبة قصيرة.
• لدى تطبيقك بالفعل ميزانيات مهلة قصيرة ويفضل الفشل السريع بدلاً من الاستطلاع.

قائمة التحقق للتكامل

قبل تحويل سير العمل إلى تعديلات gpt-image-2، راجع ما يلي:

• تأكد من استهداف نقطة النهاية /images/edit وتحديد النموذج الصحيح.
• قرر ما إذا كان من الأفضل إرسال صورك كعمليات رفع متعددة الأجزاء أو مراجع JSON، بناءً على مكان وجودها حالياً في خط الإنتاج الخاص بك.
• إذا كان تعديلك يتضمن أكثر من صورة مصدرية واحدة، فقم بتمكين الوضع غير المتزامن بدلاً من افتراض استجابة متزامنة.
• قم بتنفيذ حلقة استطلاع مع تراجع معقول (reasonable backoff) للمهام غير المتزامنة بدلاً من الاستطلاع المكثف.
• تعامل مع حالة "المهمة قيد الانتظار" (task-pending) بشكل صريح في كود العميل الخاص بك، بشكل متميز عن حالة الخطأ النهائي أو النجاح.
• اختبر مع أكبر عدد متوقع من الصور وطول المطالبة قبل النشر في بيئة الإنتاج.

مثال على الطلب

curl -X POST https://api.tokenlab.sh/v1/images/edit \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2",
    "images": ["ref://your-image-reference-1", "ref://your-image-reference-2"],
    "prompt": "combine these into a single edited scene",
    "async": true
  }'

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

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

هل يغير الوضع غير المتزامن جودة المخرجات أو تنسيق تعديلات gpt-image-2؟ لا. يغير الوضع غير المتزامن فقط كيفية استرجاع النتيجة. يعالج النموذج الطلب بنفس الطريقة؛ أنت ببساطة تستطلع الصورة النهائية بدلاً من الانتظار على اتصال مفتوح.

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

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

المصادر والحداثة

يعكس هذا التحديث سلوك TokenLab API المرصود اعتباراً من 2026-07-07. للحصول على مرجع نقطة النهاية الحالية، راجع وثائق واجهة برمجة تطبيقات تعديل الصور ودليل إنشاء الصور. للمقارنات الأوسع بين النماذج، راجع أفضل واجهة برمجة تطبيقات لنماذج صور الذكاء الاصطناعي 2026.

ابدأ الآن

إذا كنت تبني ميزات تعديل الصور وتريد واجهة برمجة تطبيقات واحدة عبر GPT Image وNano Banana Pro ونماذج الصور الأخرى، فإن TokenLab تمنحك نقطة تكامل واحدة مع دعم لكل من سير العمل المتزامن وغير المتزامن. تحقق من الوثائق واحصل على مفتاح API لبدء اختبار تعديلات gpt-image-2 اليوم.

قراءة ذات صلة والخطوة التالية

إذا كنت تقرر كيف يتناسب GPT Image Edit مع خط إنتاج الصور الأوسع الخاص بك، يمكن أن تساعدك بعض الموارد. ابدأ بـ دليل أفضل واجهة برمجة تطبيقات لنماذج صور الذكاء الاصطناعي: كيفية اختيار نماذج إنشاء وتعديل الصور للحصول على مقارنة بين المزودين الرائدين وقدرات التعديل لديهم. إذا كنت توازن بين عرض OpenAI وعرض Google، فإن GPT Image API مقابل Gemini Image API: كيفية الاختيار يحلل نقاط القوة وهياكل التسعير وحالات الاستخدام لكل منهما. وإذا كنت تريد خيار تعديل سريع ومنخفض التكلفة بجانب GPT Image، فإن دليل Nano Banana API: إنشاء وتعديل الصور من خلال TokenLab يغطي الإعداد والأمثلة العملية.

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

هل أنت مستعد للبدء في البناء؟ أنشئ مفتاح API واختبر GPT Image Edit بجانب النماذج الأخرى المدعومة في دقائق.