التوكنات في الثانية: كيف تقيس سرعة النموذج التي تهم مستخدمك؟

ما الذي يقيسه معدل التوكنات في الثانية؟

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

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

عند قياس أداء التطبيق، افصل بين المقاييس التالية:

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

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

تتكوّن العملية الأساسية من مرحلتين: معالجة المدخلات الأولية (prefill)، التي يُعالَج فيها البرومبت، وفك الترميز (decode)، التي يُولَّد فيها النص اللاحق. يتتبّع شرح الاستدلال في النماذج اللغوية الكبيرة هذه العملية داخل منظومة تشغيل النموذج وتقديم استجاباته.

لماذا لا يكفي رقم واحد للحكم على السرعة؟

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

طول البرومبت والسياق المخزّن مؤقتًا

محادثة دعم تتضمن سؤالًا قصيرًا تختلف عن المحادثة نفسها حين تحمل سجلًا طويلًا ووثائق سياسات جرى استرجاعها. زيادة المدخلات تغيّر العمل الذي يسبق الإجابة. وتذكر Groq في دليل تقليل زمن الاستجابة أن حجم المدخلات من العوامل المؤثرة في TTFT.

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

الاستدلال الذي يسبق الإجابة

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

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

تجميع الطلبات والحمل المتزامن

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

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

المنطقة ومسار وصول الاستجابة

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

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

قياس التوكنات في الثانية بحسب وحدة GPU

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

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

كيف يعلن المزوّدون عن سرعاتهم؟

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

Cerebras: سرعة منشورة مع قيد على استخدام بيئة التشغيل

تعرض Cerebras، وهي مزوّد لخدمات الاستدلال، سرعة “~3000 tokens/s” لنموذج OpenAI GPT-OSS 120B في جدول فئة Developer. وتوضح الصفحة نفسها أن الأداء يختلف بحسب النموذج والإعدادات، وأن الوصول عبر Developer مخصّص للتقييم وليس للاستخدام الإنتاجي. المصدر: أسعار Cerebras.

السؤال المفيد هو ما إذا كانت بيئة التشغيل المتاحة للشراء تستطيع خدمة عبء عملك بالاستجابة والسعة المطلوبتين. والجدول وحده لا يجيب عنه.

سرعة Groq: اقرأ الصف الخاص بالنموذج

تعرض Groq، وهي مزوّد لخدمات الاستدلال، الرقم “500” لنموذج OpenAI GPT-OSS 120B تحت عنوان “SPEED (T/SEC)” في جدول النماذج المدعومة. هذا هو الرقم الذي تنشره Groq لذلك الصف تحديدًا. المصدر: النماذج المدعومة لدى Groq.

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

وللموازنة بين السرعة والتكلفة، قارن تكلفة المهمة الناجحة والسعة التي تحتاج إليها بالاستعانة بـدليل أسعار Cerebras ودليل أسعار Groq.

أين تجد قياسات مستقلة؟

توفّر Artificial Analysis، وهي خدمة مستقلة لاختبارات الأداء، نقطة بداية مفيدة لمقارنة النماذج ومزوّدي الاستدلال. افتح لوحة ترتيب المزوّدين، ثم افحص نقطة النهاية وعبء العمل اللذين أُنتجت بهما النتيجة.

تحدّد منهجية اختبارات الأداء الحالية ما يلي:

• عبء عمل افتراضي يتضمن نحو 10,000 توكن إدخال وما لا يقل عن 1,500 توكن للإجابة.
• تُعرض نتائج أعباء العمل المعتادة باستخدام الوسيط خلال آخر 72 ساعة.
• يقع خادم الاختبار الأساسي في منطقة us-central1-a التابعة لـGoogle Cloud.
• تُوحَّد أعداد التوكنات المستخدمة في قياس الأداء باستخدام o200k_base، بدلًا من أداة تقسيم النص إلى توكنات الخاصة بكل نموذج.

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

بالنسبة إلى نماذج الاستدلال التي تخفي بعض توكنات الاستدلال، تحسب Artificial Analysis سرعة الإخراج اعتمادًا على آخر 80% من دفعات الإجابة. لا يعيد السكربت البسيط أدناه تطبيق هذه المنهجية أو عبء الاختبار الكامل؛ بل يقيس تدفّق النص كما ترصده أنت.

كيف تقيس تدفّق النص في تطبيقك؟

أجرِ القياس لدى العميل الذي يستقبل الاستجابة، وعُدّ توكنات النص بدلًا من أحداث التدفّق. فقد لا يحتوي الحدث على نص، أو قد يحمل دفعة من النص؛ وعدّ الأحداث يقيس الدفعات في الثانية.

يستخدم مثال Python التالي واجهة Groq API للتدفّق ومكتبة tiktoken لتقسيم النص إلى توكنات. ويعرض تأخر أول دفعة نصية، والزمن من إرسال الطلب إلى وصول آخر نص، وزمن اكتمال التدفّق، وتقديرًا لمعدل توكنات الإخراج في الثانية بعد توحيد طريقة العدّ.

ثبّت المكتبات المطلوبة:

python3 -m pip install groq tiktoken

اضبط متغير البيئة GROQ_API_KEY. واضبط GROQ_MODEL على نموذج نصي لا يستخدم الاستدلال، متاح لحسابك ومدرج في قائمة النماذج المدعومة لدى Groq، ثم ضع برومبت يمثّل استخدام تطبيقك في ملف prompt.txt. احفظ الكود التالي باسم measure_stream.py، ثم شغّله بالأمر python3 measure_stream.py.

import os
from pathlib import Path
from time import perf_counter

import tiktoken
from groq import Groq

encoder = tiktoken.get_encoding("o200k_base")
prompt = Path("prompt.txt").read_text(encoding="utf-8")
model = os.environ["GROQ_MODEL"]
parts = []
first = last = None

with Groq(max_retries=0) as client:
    start = perf_counter()
    stream = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        stream=True,
    )
    for event in stream:
        now = perf_counter()
        if not event.choices:
            continue
        text = event.choices[0].delta.content or ""
        if not text:
            continue
        if first is None:
            first = now
        last = now
        parts.append(text)
    end = perf_counter()

if first is None:
    raise SystemExit("No text received; no text-speed measurement.")

# Tokenize after timing; never count events as tokens.
count = lambda text: len(encoder.encode(text, disallowed_special=()))
total_tokens = count("".join(parts))
post_first_tokens = total_tokens - count(parts[0])
span = last - first

print(f"First text chunk / TTFT estimate (s): {first - start:.3f}")
print(f"Request to last text (s): {last - start:.3f}")
print(f"Stream complete (s): {end - start:.3f}")
print(f"Normalized output tokens: {total_tokens}")
if span > 0 and post_first_tokens > 0:
    print(f"Post-first output tok/s (estimate): {post_first_tokens / span:.1f}")
else:
    print("Output tok/s unavailable: insufficient text delivery intervals.")

تتيح حزمة Groq SDK تعطيل إعادة المحاولة تلقائيًا. يعطّلها هذا المثال حتى لا تُحتسب فترات انتظار إعادة المحاولة ضمن عيّنة ناجحة من دون أن يتضح ذلك؛ فالطلب الفاشل ينبغي تسجيله بوصفه فشلًا.

يستبعد حساب المعدّل الدفعة النصية الأولى من عدد التوكنات ومن الفترة الزمنية لوصولها معًا. ويتبع بذلك الصيغة القائمة على الدفعات في تعريفات Artificial Analysis. كما يتجاهل البيانات الوصفية اللاحقة عند تحديد وقت وصول آخر نص.

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

ما الذي توضحه حاسبات السرعة وأدوات المحاكاة؟

قد تساعد أداة تخطيط على توضيح افتراض زمني، لكنها لا تستطيع اكتشاف التأخر الفعلي عند نقطة النهاية التي تستخدمها.

محاكاة معدل التوكنات في الثانية

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

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

ما معدل التوكنات في الثانية المناسب؟

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

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

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

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

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

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

أين تبدأ المبالغة في الحديث عن سرعة النماذج اللغوية؟

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

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

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

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

خطوتك التالية في تطوير التطبيق

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

للحصول على أدلة عملية لبناء تطبيقات ذكاء اصطناعي مفيدة، اشترك في النشرة البريدية.