نظرة عامة
يتيح البث استلام الخرج تدريجيًا. استخدم Responses streaming عندما يعلن النموذج عن عقد Responses الأصلي وتوجد قناة upstream من البروتوكول نفسه؛ وإلا استخدم Chat Completions أو البروتوكول الأصلي الذي يعلنه النموذج.الموصى به: Responses Streaming
حدود Responses وGemini المتدفقة
تحافظ TokenLab في Responses SSE على أسماء أحداث upstream وترتيبها وحقولها، وتقرأ usage والحالة النهائية خارج المسار من دون تغيير wire. بعد تسليم أول حدث لا تُعاد المحاولة على قناة أو credential أخرى. يقبل Responses WebSocket أحداثresponse.create الرسمية فقط. يكون stream ضمنيًا، ولا تتوفر background أو response.cancel على هذا النقل؛ تعمل background عبر HTTP فقط. كل اتصال تسلسلي، لا يدعم multiplex، وحده الأقصى 60 دقيقة.
يحافظ Gemini SSE على الأجزاء الأصلية. أحداث metadata فقط، والأجزاء الوسيطة بلا finishReason، وEOF الطبيعي حالات صحيحة، ولا تضيف TokenLab علامة Chat [DONE].
بث Chat Completions
إذا كان إطار العمل لديك لا يزال يتوقع مقاطع SSE من/v1/chat/completions، فهذا يعمل أيضًا:
شروط انتهاء البث
شروط الإكمال المعتادة:response.completedلتدفقات Responses APIfinish_reason: "stop"لتدفقات Chat Completionsfinish_reason: "length"عند الوصول إلى حد token- أحداث استدعاء الأداة/الدالة عندما يريد النموذج استخدام الأدوات
نمط تطبيق الويب
أفضل الممارسات
فضّل Responses streaming في الإنشاءات الجديدة
فضّل Responses streaming في الإنشاءات الجديدة
استخدم
/v1/responses إذا كان SDK أو التطبيق لديك يدعمه بالفعل. واحتفِظ ببث /v1/chat/completions لعمليات التكامل التي تتطلب التوافق.ادفع المخرجات تدريجيًا
ادفع المخرجات تدريجيًا
ألحِق مقاطع delta بواجهة المستخدم أو الطرفية عند وصولها بدلًا من انتظار الاستجابة الكاملة.
تعامل مع انقطاعات الاتصال وإعادات المحاولة
تعامل مع انقطاعات الاتصال وإعادات المحاولة
اعتبر انقطاع الشبكة وانفصال المصدر العلوي أوضاع فشل طبيعية، وأعِد الاتصال بحذر للجلسات طويلة التشغيل.