أُغلق التدفق قبل الاكتمال
أربعة أسباب، وطريقة واحدة قفزة بقفزة
تنقطع استجابة بث في منتصف الطريق مع نص الخطأ «stream closed before completed» — وهناك أربعة أسباب شائعة، وهي ليست من النوع نفسه إطلاقًا؛ والفحص قفزة بقفزة هو الطريقة الوحيدة للعثور على السبب الصحيح.
آخر تحديث 2026-11-14
مفتاح واحد لـ Claude وGPT وأبرز النماذج الصينية، والفوترة حسب token، ويعمل خلال دقائق.
- الفوترة حسب token — الأسعار المباشرة على /models
- الدفع بالبطاقة (Visa / Mastercard) أو Apple Pay أو Google Pay أو العملات الرقمية
- خدمة ذاتية: شحن الرصيد والتفعيل فورًا
أربع حقائق أساسية
أربعة أسباب شائعة
إطار حد معدل الطلبات من جانب النموذج، أو عدم تطابق المهلات في السلسلة، أو انقطاع العميل، أو طبقة إعادة كتابة تبتلع حدث الإنهاء — تبدو متشابهة لكن أسبابها الجذرية مختلفة تمامًا.
جوهر طريقة التشخيص
يمر المسار من العميل إلى خدمة النموذج عادةً بعدة قفزات (العميل ← البوابة ← موازن الأحمال ← خدمة النموذج)؛ عليك فحص كل قفزة لتحديد موضع الانقطاع الفعلي.
ما إذا كان حدث الإنهاء يصل
تحدد كثير من بروتوكولات البث الانتهاء الطبيعي بحدث إنهاء (مثل [DONE])؛ وإذا انقطع التدفق قبل ظهور ذلك، فهذا يعني أنه قُطع قبل أوانه بدل أن يكتمل بشكل طبيعي.
السبب الأكثر شيوعًا في إغفاله
يضبط العملاء والبوابات وموازنات الأحمال عادةً مهلة خاصة بكل منها؛ وإذا كانت مهلة أي قفزة مفردة أقصر من زمن التوليد الفعلي لدى النموذج، فستقطع تلك القفزة التدفق قسرًا.
حقيقة كل سبب من الأسباب الأربعة
أولًا، إطار حد معدل الطلبات من جانب النموذج: تبلغ خدمة النموذج حد معدل الطلبات أثناء التوليد، فتُدرج إشارة مقاطعة تُنهي التوليد مبكرًا — لا يرى العميل سوى انقطاع التدفق قبل الانتهاء. ثانيًا، عدم تطابق المهلات: يعبر الطلب عدة قفزات — العميل، والوكيل، والبوابة، وموازن الأحمال — وإذا كانت مهلة أي قفزة مضبوطة أقصر من زمن التوليد الفعلي لدى النموذج، فستقطع تلك القفزة الاتصال فعليًا رغم أن جانب النموذج ما يزال يولّد بشكل طبيعي. ثالثًا، انقطاع العميل (غياب العميل): أغلق المستخدم الصفحة أو ألغى الطلب في منتصف الطريق، أو استُعيدت حاوية العميل/عمليته — ويترك هذا النوع من الانقطاع عادةً إدخالًا من نمط «peer closed connection» في سجلات الخادم، ويشير إلى اتجاه معاكس للسببين الأولين. رابعًا، طبقة إعادة الكتابة التي تبتلع حدث الإنهاء: تُعاد معالجة جسم استجابة البث بواسطة بعض الوكلاء العكسية، أو شبكات CDN، أو برمجيات إعادة الكتابة الوسيطة، وإذا كان في تنفيذها خلل، فقد تمرر المحتوى الفعلي بشكل سليم بينما تُسقط حدث الإنهاء الذي يشير إلى «اكتمال التوليد بشكل طبيعي» (مثل [DONE] في SSE) — حينها يظن العميل أن الاتصال انقطع بشكل غير طبيعي، بينما يكون جانب النموذج قد أنهى التوليد بشكل سليم فعليًا.
لماذا يجدر تذكّر طريقة التشخيص هذه
من بين الأسباب الأربعة، السببان الأولان (إطار حد معدل الطلبات، وعدم تطابق المهلات) هما الأكثر تعرّضًا للتشخيص الخاطئ على أنهما «شبكتنا غير مستقرة». أما الثالث (انقطاع العميل) فيُلام عليه خطأً غالبًا من جانب الخادم على أنه «النموذج غير موثوق». والرابع (طبقة إعادة الكتابة التي تبتلع حدث الإنهاء) هو الأكثر خفاءً، لأن المحتوى الذي يتلقاه العميل يبدو مكتملًا — لكنه يفتقد فقط إشارة الإغلاق الدالة تلك — لذا غالبًا ما يُستبعد على أنه «خلل عشوائي» بدل أن يُعامل كمسألة نظامية.
الجدول الزمني
استجابات البث (SSE والبروتوكولات المشابهة) وآلية حدث الإنهاء فيها تصميم معياري قائم منذ زمن طويل؛ وقد وُجدت أسباب الانقطاع الأربعة جميعها منذ أن أصبح البث شائعًا.
تزيد سير عمل الوكلاء من عدد عمليات التوليد المتدفقة طويلة الأمد، مما يجعل المهلات سيئة الضبط في أي موضع من السلسلة أكثر عرضة للظهور.
يظهر السبب الأكثر خفاءً — طبقة إعادة كتابة تبتلع حدث الإنهاء — بصورة أكثر تكرارًا مع تزايد تعقيد البرمجيات الوسيطة للوكلاء العكسية/CDN.
مؤكد مقابل سوء فهم شائع
مؤكد
تظهر رسالة «stream closed before completed» بانتظام في نقاشات المطورين العامة؛ وكل سبب من الأسباب الأربعة (إطار حد معدل الطلبات، وعدم تطابق المهلات، وانقطاع العميل، وطبقة إعادة الكتابة التي تبتلع الحدث) موثّق بشكل مستقل ويتطلب تشخيصًا منفصلًا.
سوء فهم شائع
كثيرًا ما يكون الانطباع الأول لدى كثيرين عند انقطاع التدفق هو «النموذج غير موثوق» أو «خدمة المزوّد معطلة» — لكن في الممارسة، تشكل حالات عدم تطابق المهلات وخلل طبقة إعادة الكتابة، وكلاهما مسألة إعداد أو تنفيذ من جانب العميل/البرمجيات الوسيطة، نسبة كبيرة من الحالات.
كيف تميّز بين الأسباب الأربعة
انقطاع من جانب الخادم (إطار حد معدل الطلبات / مهلة)
ستُظهر سجلات الخادم أن هذا التوليد تعرّض لتقييد معدل الطلبات أو أن مهلة إحدى القفزات تسبّبت في القطع؛ العلامة الفارقة هي أن الطلب نفسه يكتمل غالبًا بلا مشكلة في وقت مختلف أو مع تزامن أقل.
مشكلة من جهة العميل (انقطاع الاتصال / طبقة إعادة كتابة تبتلع الحدث)
تُظهر سجلات الخادم أن التوليد اكتمل فعليًا بشكل طبيعي — المشكلة هي أن العميل يقطع الاتصال مبكرًا جدًا، أو أن طبقة إعادة كتابة وسيطة تفشل في تمرير الحدث النهائي. يتطلب ذلك فحص إعدادات العميل/الوكيل، لا خدمة النموذج.
منهج الفرز قفزةً بقفزة
الخطوة 1: افحص سجلات الخادم — هل جرى هذا التوليد فعليًا حتى الاكتمال، وهل تعرّض لتقييد معدل الطلبات؟ إذا أظهرت سجلات الخادم أنه اكتمل بشكل طبيعي، فالمشكلة على الأرجح في إحدى القفزات بين العميل والخادم. الخطوة 2: افحص إعدادات المهلة قفزةً بقفزة — مهلة العميل، ومهلة CDN/البوابة، ومهلة موازن الحمل — وحدّد أيّها أقصر من زمن التوليد الفعلي للنموذج. الخطوة 3: إذا اشتبهت في أن طبقة إعادة كتابة تبتلع الحدث، فقارن مباشرةً التدفق الخام الذي أرسله الخادم بما استلمه العميل فعليًا، وافحص ما إذا كان الحدث النهائي قد ضاع في المنتصف. الخطوة 4: إذا كان العميل يقطع الاتصال عمدًا (مثل أن يلغي المستخدم يدويًا)، فليس ذلك عطلًا على الإطلاق — كل ما تحتاج إليه هو التعامل مع حالة الإلغاء تلك بشكل صحيح في منطق تطبيقك بدلًا من تفسيرها خطأً على أنها عطل في النظام.
ما العمل على QCode
تضبط عقد الحافة لدى QCode المهل الخاصة بالاستجابات المتدفقة، ما يقلّل الحالات التي تقطع فيها مهلة غير متطابقة في إحدى القفزات توليدًا طويل الأمد عن طريق الخطأ؛ وإذا كان لديك وكيل أو وسيط إعادة كتابة يعاني مشكلة مشابهة، فيمكنك أيضًا التوجيه عبر نقطة نهاية QCode كحل مؤقت أثناء تشخيصها.
الأسئلة الشائعة
كيف أعرف ما إذا كان انقطاع التدفق من جهتي؟
افحص سجلات الخادم أولًا إن أمكنك الحصول عليها: إذا أظهرت أن التوليد اكتمل بشكل طبيعي، فالمشكلة على الأرجح في إحدى القفزات بين العميل والخادم (إعدادات المهلة، طبقة إعادة كتابة، إلخ) — وهو أمر يمكنك تشخيصه وإصلاحه.
لماذا ينجح الطلب نفسه أحيانًا وينقطع أحيانًا أخرى؟
السبب الأكثر شيوعًا هو عدم تطابق المهلة: يتفاوت زمن التوليد بطبيعته، وكلما تجاوز بالصدفة أقصر حد مهلة في أي موضع من السلسلة، ينقطع ذلك الطلب، بينما تكتمل الطلبات الأسرع بلا مشكلة.
هل يُعد قطع العميل للاتصال عطلًا؟
بالمعنى الدقيق، لا — فهو سلوك مستخدم طبيعي (إلغاء طلب، إغلاق الصفحة) أو تغيّر في بيئة العميل (استعادة النظام للعملية)؛ وكل ما يلزم هو تحديده والتعامل معه بشكل صحيح في منطق تطبيقك، لا ملاحقته باعتباره عطلًا في النظام.
ما أسرع طريقة لتشخيص طبقة إعادة كتابة تبتلع الحدث النهائي؟
التقط حركة المرور أو أضف تسجيلًا يقارن مباشرةً ما بثّه الخادم فعليًا بما استلمه العميل في النهاية — إذا أرسل الخادم الحدث النهائي لكن العميل لم يستلمه أبدًا، فالمشكلة في طبقة إعادة كتابة/تمرير وسيطة.
ما الذي ينبغي أن أفحصه أولًا عند مصادفة هذا الخطأ؟
افحص أولًا سجلات الخادم بحثًا عن حدود معدل الطلبات أو الأخطاء؛ إذا لم تجد شيئًا هناك، فافحص إعدادات المهلة لدى العميل والبوابة وموازن الحمل — هاتان الخطوتان تستبعدان ثلاثًا من الأسباب الأربعة.
هل هذا هو نفسه 429/529؟
لا. تعني 429/529 أن الطلب يُرفض قبل أن يبدأ التوليد أصلًا؛ أما إغلاق التدفق قبل اكتماله فيعني أن التوليد بدأ بالفعل وأن التدفق كان مفتوحًا بالفعل، لكنه انقطع قبل الاكتمال — يحدث الأمران في مرحلتين مختلفتين تمامًا.
المصادر
جُمعت الأسباب الأربعة من النقاشات العامة للمطورين، والسلوك المعياري لبروتوكولات التدفق مثل SSE، والممارسة التشغيلية العامة لفرز المهل قفزةً بقفزة؛ ولا تقدم هذه الصفحة أي ادعاءات بشأن التنفيذ الخاص لأي مزوّد بعينه. جُمع في 2026-08-27.
ينبغي ألا تبطئ انقطاعات التدفق التسليم.
تضبط عقد الحافة لدى QCode المهل الخاصة بالاستجابات المتدفقة، ما يقلّل من انقطاعات التوليدات الطويلة الناتجة عن عدم تطابق المهل في القفزات.
قراءات ذات صلة
تجاوز طول السياق: الدليل الكامل
خطأ آخر كثيرًا ما يُشخّص خطأً — مقارنة مفيدة.
الدليل الكامل للاستعلام عن استخدام مفتاح API الخاص بك
كيف تراجع سجل استدعاءاتك والشذوذات الخاصة بك بشكل منهجي.
magpie لا يعمل: أخطاء 401 و405 وإصلاحاتها (2026-11)
السبب الرسمي والإصلاح لأخطاء magpie الشائعة: مفتاح لا يُطبّق، و401 في Docker، و405 في ZCode، و400 في اختبار المزوّد والنماذج المفقودة.
دليل الدفع بالعملات المشفرة
تسع عملات، و56 شبكة، وبدون رسوم منصة لرصيد API للبرمجة بالذكاء الاصطناعي.
هذه الصفحة شرح تقني عام يشمل عدة مزوّدين، ولا يقدّم أي ادعاءات بشأن التنفيذ الداخلي الخاص بأي مزوّد واحد. يعتمد السلوك الفعلي على النموذج والعميل وسلسلة الوسطاء التي تستخدمها.