إصدارتحليل · على الرادارX: @ArtificialAnlys→ المصدر

GLM-5.3: نقاط النهاية الأسرع في البث تستغرق 18–26 ثانية قبل ظهور أول توكن

لاحظت Artificial Analysis خللاً في تصنيفات سرعة GLM-5.3. في نقاط النهاية الأسرع بثاً يصل أول توكن بعد 18–26 ثانية، بينما يصل لدى معظم البقية بعد 1–3 ثوانٍ. وإذا احتسبنا هذا الانتظار ضمن الزمن الكلي للطلب، يتراجع المزوّدون الذين يبدون الأسرع على الورق تراجعاً حاداً.

معالج بواسطة الذكاء الاصطناعي من X: @ArtificialAnlys؛ بتحرير Hamidun News
GLM-5.3: نقاط النهاية الأسرع في البث تستغرق 18–26 ثانية قبل ظهور أول توكن
المصدر: X: @ArtificialAnlys. كولاج: Hamidun News.
استمع للمقال
بطاقة الحقائق والأرقام
المعيارالتفاصيل
المصدر الأصليX: @ArtificialAnlys ↗
رئيس التحرير
الزمن حتى أول توكن18–26 ثانية مقابل 1–3 ثوانٍ لدى معظم المزوّدين
حقيقة رئيسية #2سرعة البث لا تساوي سرعة الرد التي يشعر بها المستخدم
حقيقة رئيسية #3اختاروا المزوّد وفق الزمن الكلي للطلب لا وفق عدد التوكنات في الثانية

عند اختيار مزوّد لنموذج ما، أول ما ننظر إليه هو سطر «التوكنات في الثانية». كلما زاد الرقم كان أفضل. لكن منشور Artificial Analysis الأخير حول GLM-5.3 يُظهر أن هذا الرقم قد يُضلّل كثيراً بشأن التجربة الفعلية للمستخدم.

ما الذي اكتُشف

في نقاط النهاية الخاصة بـ GLM-5.3 ذات أسرع بث، يظهر أول توكن بعد 18–26 ثانية. أما لدى معظم المزوّدين الآخرين فيبدأ الرد بعد 1–3 ثوانٍ. إذا اعتمدنا سرعة التدفق بعد البدء فقط، يبدو الفريق الأول في الصدارة. أما إذا أضفنا الانتظار إلى الزمن الكلي للطلب، فإنه يتراجع في الترتيب.

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

لماذا يهم هذا عملياً

تخيّلوا روبوت دردشة للدعم. أرسل المستخدم سؤاله وهو ينظر إلى شاشة فارغة. إذا بدأ الرد بعد 20 ثانية، فلا يهم أن النص سينساب بعدها بسرعة 300 توكن في الثانية. فالشخص يكون قد أغلق التبويب أو ضغط «إرسال» مرة أخرى.

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

لذلك ينبغي في المنتجات التفاعلية النظر إلى ثلاثة مقاييس على الأقل:

  • الزمن حتى أول توكن (TTFT)؛
  • سرعة التوليد بعد البدء؛
  • الزمن الكلي للطلب لطول إجابة نموذجي.

ما العمل

أولاً: لا تختاروا المزوّد بناءً على رقم سرعة واحد من موقع تجميعي. افتحوا التفاصيل وانظروا إلى TTFT على حدة.

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

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

رابعاً: ضعوا خطة بديلة (fallback). إذا لم يصل أول توكن خلال 5 ثوانٍ، فانتقلوا إلى نقطة نهاية أخرى.

القيود

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

لكن الدرس عام: «البث السريع» و«الرد السريع» ليسا الشيء نفسه. فما يهم المستخدم هو متى رأى الكلمة الأولى، لا مدى سرعة تدفق التوكنات بعد ذلك.

القصة

أسئلة وأجوبة حول الخبر

ما أبرز التفاصيل حول ما الذي اكتُشف؟

في نقاط النهاية الخاصة بـ GLM-5.3 ذات أسرع بث، يظهر أول توكن بعد 18–26 ثانية. أما لدى معظم المزوّدين الآخرين فيبدأ الرد بعد 1–3 ثوانٍ. إذا اعتمدنا سرعة التدفق بعد البدء فقط، يبدو الفريق الأول في الصدارة. أما إذا أضفنا الانتظار إلى الزمن الكلي للطلب، فإنه يتراجع في الترتيب. لا يشرح المنشور السبب، لذا لا يبقى سوى التخمين. قد يكون السبب طابور انتظار طويلاً، أو بدءاً بارداً، أو معالجة مسبقة ثقيلة للمطالبة، أو استدلال النموذج قبل إصدار الإجابة. ومن دون بيانات من المزوّدين أنفسهم لا يمكن تحديد المتسبب بثقة.

ما أبرز التفاصيل حول لماذا يهم هذا عملياً؟

تخيّلوا روبوت دردشة للدعم. أرسل المستخدم سؤاله وهو ينظر إلى شاشة فارغة. إذا بدأ الرد بعد 20 ثانية، فلا يهم أن النص سينساب بعدها بسرعة 300 توكن في الثانية. فالشخص يكون قد أغلق التبويب أو ضغط «إرسال» مرة أخرى. والأمر نفسه مع الوكلاء (agents). فكل خطوة في السلسلة تضيف تأخيراً قبل أول توكن. ومع عشرة استدعاءات متتالية يتحول الفارق بين ثانيتين و20 ثانية إلى دقائق من الانتظار، لا إلى تفصيل صغير.

ما أبرز التفاصيل حول ما العمل؟

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

ZK
جمال حميدون — مدير المنتجات في Alpina Digital ومدير منتج AlpinaGPT. يبني منتجات الذكاء الاصطناعي منذ 2019. بدأ Hamidun News كمشروع شخصي ثم أصبح مُجمِّعًا إنتاجيًا بأكثر من 6000 قارئ.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
ما رأيك؟
جارٍ تحميل التعليقات…