زمن استجابة LLM مقابل الإنتاجية: كيف يجب على مشتري الـ API قياس السرعة

النموذج الذي أظهر أول رمز (token) مرئي له في أسرع وقت في اختبارنا الأخير كان أيضًا الأبطأ في الانتهاء. في تاريخ 2026-10-03 قمنا ببث مطالبة (prompt) واحدة عبر أربعة نماذج. تصدر النموذج claude-sonnet-5-5 في زمن ظهور أول رمز (2,981 مللي ثانية) وتأخر في الزمن الإجمالي (12,384 مللي ثانية). هذه الفجوة هي جوهر الفرق بين زمن الاستجابة والإنتاجية في نماذج LLM: رقم واحد يخبرك بمدة انتظار المستخدم لرؤية النص، ورقم آخر يخبرك بمدى سرعة إنجاز العمل. يحدد هذا المقال كل مقياس، ويعرض قياساتنا الأولية المحدودة مع حدودها، ويوفر أداة اختبار (harness) يمكنك تشغيلها مقابل TokenLab API.

أبرز النقاط

• ثلاثة أرقام، ثلاث وظائف. زمن الوصول لأول رمز (Time to first token)، والزمن الإجمالي، وعدد الرموز الناتجة في الثانية (output tokens per second) تجيب على أسئلة مختلفة. تعتمد المحادثات، والوكلاء (agents)، ومعالجة الدفعات (batch work) على مقياس مختلف لكل منها.
• افصل بين الحدث الأول وأول رمز مرئي. في نموذج deepseek-v4.1-flash كان الفرق بين الوسيطين للحدثين 2,334 مللي ثانية و3,925 مللي ثانية. يمكن أن تصل دلتا الاستنتاج (reasoning deltas) قبل ظهور أي نص مرئي بوقت طويل.
• رموز الاستنتاج تستهلك ميزانية max_tokens الخاصة بك. عند ضبط max_tokens على 400، أعاد نموذج deepseek-v4.1-flash حوالي 0 رمز مرئي، بينما أعاد gemini-3.8-flash حوالي 14 رمزًا. عند ضبطها على 2000، أجاب كلاهما بالكامل.
• اقرأ عدد الرموز من جزء الاستخدام (usage chunk). لا تقم بتقديرها بناءً على عدد الحروف.
• سرعة النموذج لا ترفع حد الطلبات الخاص بك. حدود المعدل (rate limits)، وحدود الرموز، وسرعة النموذج هي قيود منفصلة.
• عينة قياساتنا صغيرة. تتكون من خمس جولات لكل نموذج، وعميل واحد، ومطالبة واحدة، ويوم واحد. إنها توضح كيفية القياس، وليس من هو الأسرع.

ثلاثة أرقام للسرعة: زمن الاستجابة مقابل الإنتاجية في نماذج LLM عمليًا

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

send request
  -> first stream event          (any SSE chunk; may be a reasoning delta)
  -> first visible content token (first non-empty delta.content)
  -> last token + final usage chunk

زمن الوصول لأول رمز (TTFT) هو الوقت المستغرق من إرسال الطلب حتى وصول أول رمز. نحن نسجل نسختين. حدث البث الأول (first stream event) هو أول جزء SSE من أي نوع. أول رمز محتوى مرئي (first visible content token) هو أول جزء يكون فيه choices[0].delta.content غير فارغ. بالنسبة للنماذج التي تستنتج قبل الإجابة، يمكن أن يكون الحدث الأول عبارة عن دلتا استنتاج (delta.reasoning_content) تصل قبل النص المرئي بوقت طويل. أداة الاختبار التي تراقب فقط delta.content تقيس زمن الوصول لأول رمز مرئي، وليس زمن الوصول لأول بايت. المستخدم يشعر بالرمز المرئي.

الزمن الإجمالي (Total time) يبدأ من إرسال الطلب حتى نهاية البث. يشمل ذلك الاستنتاج، ووقت الشبكة، وأي وقت انتظار لإعادة المحاولة تضيفه أنت.

رموز الإخراج في الثانية (Output tokens per second) هي رموز الإخراج مقسومة على الزمن الإجمالي. خذ عدد الرموز من usage.completion_tokens، والذي يتضمن رموز الاستنتاج. نحن نقسم على الزمن الإجمالي، وليس على نافذة العرض المرئي. بعض النماذج في عينتنا قدمت النص المرئي في بضع كتل كبيرة، لذا فإن المعدل القائم على النافذة سيكون مضللاً.

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

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

ما قمنا بقياسه في 2026-10-03

الطريقة. هذا قياس أولي من TokenLab، تم رصده في 2026-10-03، مقابل POST https://api.tokenlab.sh/v1/chat/completions (المصدر). استخدم كل طلب stream=true و stream_options.include_usage=true. أجرينا 5 جولات متسلسلة لكل نموذج من عميل واحد في شرق آسيا، باستخدام fetch في Node 24. كانت المطالبة هي "اشرح كيف يقلل HTTP keep-alive زمن الاستجابة لعملاء API. اكتب حوالي 200 كلمة." استخدم كل نموذج إعدادات الاستنتاج الافتراضية. التوقيتات هي توقيت العميل، وقد نجحت جميع الجولات (5/5) لكل صف أدناه.

النموذج (max_tokens 2000)	وسيط أول حدث بث	وسيط أول رمز مرئي	وسيط الزمن الإجمالي	وسيط رموز الإكمال (الاستنتاج)	رموز/ثانية تقديرية
deepseek-v4.1-flash	2,334 مللي ثانية	3,925 مللي ثانية	5,204 مللي ثانية	453 (225)	87
gemini-3.8-flash	6,892 مللي ثانية	6,892 مللي ثانية	8,626 مللي ثانية	826 (528)	96
claude-sonnet-5-5	2,981 مللي ثانية	2,981 مللي ثانية	12,384 مللي ثانية	418 (غير مُبلغ عنه)	34
gpt-5.6-luna	3,262 مللي ثانية	3,262 مللي ثانية	8,183 مللي ثانية	313 (42)	38

عمود الرموز/ثانية هو تقديرنا الخاص: وسيط رموز الإكمال مقسومًا على وسيط الثواني الإجمالية، على سبيل المثال 453 ÷ 5.204 ≈ 87. إنها نسبة بين الوسيطين، وليست وسيطًا لمعدلات كل جولة.

ما تظهره الأرقام، ولا شيء غير ذلك:

• الترتيب حسب أول رمز مرئي (claude-sonnet-5-5، gpt-5.6-luna، deepseek-v4.1-flash، gemini-3.8-flash) يختلف عن الترتيب حسب الزمن الإجمالي (deepseek-v4.1-flash، gpt-5.6-luna، gemini-3.8-flash، claude-sonnet-5-5). لا يمكن لمقياس واحد أن يحل محل الآخر.
• كان لدى deepseek-v4.1-flash فجوة قدرها 1,591 مللي ثانية بين الحدث الأول وأول رمز مرئي. كان وسيط مخرجاته المرئية حوالي 228 رمزًا، تم تسليمها في 87 حدثًا على مدار 1,304 مللي ثانية.
• بالنسبة لـ gemini-3.8-flash، يتشارك الحدث الأول وأول رمز مرئي في وسيط قدره 6,892 مللي ثانية. جاء نصه المرئي في وسيط قدره 11 حدثًا على مدار 1,734 مللي ثانية، لذا كان البث متقطعًا وليس رمزًا تلو الآخر.
• أرسل claude-sonnet-5-5 وسيطًا قدره 371 حدثًا على مدار 9,186 مللي ثانية، وأرسل gpt-5.6-luna 265 حدثًا على مدار 4,901 مللي ثانية.

التكلفة تقع بجانب السرعة. الأسعار أدناه مأخوذة من TokenLab model API، تم رصدها في 2026-10-03، مع تحديث الأسعار في 2026-10-02T16:53:30.068Z. العمود الأخير هو تقدير: وسيط رموز الإكمال مضروبًا في معدل الإخراج، جانب الإخراج فقط. تحقق من سجلات الاستخدام لمعرفة الرسوم الفعلية.

النموذج	الإدخال لكل مليون	الإخراج لكل مليون	أقصى رموز إخراج	تقدير جانب الإخراج، جولة وسيطة	المصدر
deepseek-v4.1-flash	$0.15 خارج الذروة، $0.30 ذروة	$0.60 خارج الذروة، $1.20 ذروة	384,000	453 × $0.60 / 1M ≈ $0.00027 خارج الذروة، ≈ $0.00054 ذروة	model API
gemini-3.8-flash	$0.375	$1.875	65,536	826 × $1.875 / 1M ≈ $0.00155	model API
claude-sonnet-5-5	$0.60	$3	128,000	418 × $3 / 1M ≈ $0.00125	model API
gpt-5.6-luna	$0.06	$0.36	128,000	313 × $0.36 / 1M ≈ $0.00011	model API

بالنسبة لـ gpt-5.6-luna، تنطبق هذه الأسعار عندما يكون الإدخال بحد أقصى 272 ألف رمز. فوق ذلك، يستخدم الطلب الكامل ضعف أسعار الإدخال و1.5 ضعف أسعار الإخراج.

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

رموز الاستنتاج و max_tokens: لماذا أعاد 400 لا شيء تقريبًا

قمنا أيضًا بتشغيل نفس المطالبة مع ضبط max_tokens على 400. نفس الطريقة، نفس الجولات الخمس، نفس التاريخ (المصدر).

النموذج (max_tokens 400)	وسيط رموز الإكمال	وسيط رموز الاستنتاج	الإخراج المرئي (تقريبي)	وسيط أول رمز مرئي	وسيط الزمن الإجمالي
deepseek-v4.1-flash	400	400	0 رمز	3,795 مللي ثانية	4,693 مللي ثانية
gemini-3.8-flash	396	382	14 رمز	4,199 مللي ثانية	4,240 مللي ثانية
claude-sonnet-5-5	400	غير مُبلغ عنه	400 رمز	3,088 مللي ثانية	11,078 مللي ثانية
gpt-5.6-luna	317	42	275 رمز	3,040 مللي ثانية	8,083 مللي ثانية

يتم حساب الوسائط لكل عمود، لذا لا تحتاج أعمدة الصف الواحد إلى وصف جولة واحدة. لهذا السبب يظهر deepseek-v4.1-flash وقت ظهور أول رمز بجانب وسيط صفر من الأحداث المرئية.

النتيجة واضحة. أنفق deepseek-v4.1-flash و gemini-3.8-flash تقريبًا كامل ميزانية الـ 400 رمز على الاستنتاج ولم يعيدا أي نص مرئي تقريبًا. أدى رفع max_tokens إلى 2000 إلى إنتاج إجابات كاملة. تُحتسب رموز الاستنتاج داخل usage.completion_tokens. يتم الإبلاغ عنها بشكل منفصل في usage.completion_tokens_details.reasoning_tokens.

عندما رأينا أول نتيجة بـ 400 رمز، بدا الفشل كإجابة فارغة، وليس مشكلة ميزانية. ثلاثة فحوصات تجعلها مرئية:

1. اقرأ جزء الاستخدام النهائي، الذي تم تمكينه بواسطة stream_options={"include_usage": True}. إذا كان reasoning_tokens قريبًا من completion_tokens وكان النص فارغًا، فقد ذهبت الميزانية إلى الاستنتاج.
2. تحقق من finish_reason. يسرد دليل البث (الذي تم رصده في 2026-10-03) length كقيمة عند الوصول إلى حد الرموز.
3. قارن مع أقصى إخراج للنموذج. على سبيل المثال، يسرد model API 384,000 لـ deepseek-v4.1-flash و 65,536 لـ gemini-3.8-flash، لذا كان 400 شريحة صغيرة مما تسمح به النماذج.

يسرد مرجع إنشاء إكمال المحادثة (الذي تم رصده في 2026-10-03) أيضًا max_completion_tokens و reasoning_effort. ويقول إن القيم المدعومة تعتمد على النموذج، لذا اقرأ صفحة النموذج قبل ضبط أي منهما. لم نختبرهما، وقمنا بتشغيل كل صف بإعدادات الاستنتاج الافتراضية. حدد السقف من مطالبتك الخاصة: في جولتنا، أنتجت إجابة من 200 كلمة ما بين 228 إلى 418 رمزًا مرئيًا، وما يصل إلى 528 رمز استنتاج فوق ذلك.

أداة قياس لعنوان TokenLab الأساسي

يستخدم هذا البرنامج النصي عنوان TokenLab الأساسي، ويقرأ عدد الرموز من جزء الاستخدام، ويسجل حدث البث الأول بشكل منفصل عن أول رمز محتوى مرئي. كما أنه يحتفظ برؤوس الاستجابة لتصحيح الأخطاء لاحقًا. إنه يتبع إعدادات العميل في المستندات (timeout=30.0، max_retries=0) حتى لا تضيف SDK عمليات إعادة محاولة مخفية إلى توقيتاتك. معرف النموذج هو واحد مما قمنا بقياسه؛ استبدله بأي معرف تتضمن تنسيقات طلبه المقبولة openai_chat_completions.

import json
import os
import statistics
import time

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["TOKENLAB_API_KEY"],
    base_url="https://api.tokenlab.sh/v1",
    timeout=30.0,
    max_retries=0,
)

PROMPT = "Explain how HTTP keep-alive reduces latency for API clients. Write about 200 words."

def measure(model: str, max_tokens: int = 2000) -> dict:
    start = time.perf_counter()
    raw = client.chat.completions.with_raw_response.create(
        model=model,
        messages=[{"role": "user", "content": PROMPT}],
        max_tokens=max_tokens,
        stream=True,
        stream_options={"include_usage": True},
    )
    headers = raw.headers
    first_event = first_visible = None
    visible_events = 0
    usage = None
    finish_reason = None

    for chunk in raw.parse():
        now = time.perf_counter() - start
        if first_event is None:
            first_event = now
        if chunk.usage is not None:
            usage = chunk.usage
        if not chunk.choices:
            continue
        choice = chunk.choices[0]
        if choice.delta.content:
            visible_events += 1
            if first_visible is None:
                first_visible = now
        if choice.finish_reason:
            finish_reason = choice.finish_reason

    total = time.perf_counter() - start
    details = getattr(usage, "completion_tokens_details", None)
    completion = usage.completion_tokens if usage else None
    return {
        "model": model,
        "request_id": headers.get("x-request-id"),
        "routing_time_ms": headers.get("x-routing-time-ms"),
        "first_event_s": first_event,
        "first_visible_s": first_visible,
        "total_s": total,
        "completion_tokens": completion,
        "reasoning_tokens": getattr(details, "reasoning_tokens", None),
        "visible_events": visible_events,
        "finish_reason": finish_reason,
        "tokens_per_s": completion / total if completion else None,
    }

if __name__ == "__main__":
    runs = [measure("gemini-3.8-flash") for _ in range(5)]
    print(json.dumps(runs[0], indent=2))
    print("median total_s:", statistics.median(r["total_s"] for r in runs))

بعض الملاحظات حول قراءة المخرجات:

• يتم تشغيل first_event_s عند أي جزء، بما في ذلك جزء الدور فقط أو جزء الاستنتاج. يتم تشغيل first_visible_s فقط عند delta.content غير فارغ. إذا اختلف الاثنان بثوانٍ، فإن النموذج يستنتج قبل أن يجيب.
• تأتي أعداد الرموز من جزء الاستخدام النهائي. يحتوي ذلك الجزء على قائمة choices فارغة، ولهذا السبب تتحقق الحلقة من chunk.usage قبل تخطيه.
• قم بتشغيله خمس مرات أو أكثر، وسجل المنطقة، وأبلغ عن الوسائط جنبًا إلى جنب مع حجم العينة.
• بالنسبة للنماذج التي تسرد openai_responses، يظهر دليل البث استجابات تبث مع أحداث response.output_text.delta و response.completed. ينطبق نفس التقسيم: قم بتوقيت الحدث الأول، ثم دلتا النص الأولى.
• تعامل مع البث الذي يغلق قبل response.completed أو سبب إنهاء stop على أنه غير مكتمل، وليس كنجاح سريع.

الرؤوس والمعرفات التي يجب تسجيلها لتصحيح أخطاء زمن الاستجابة

من الصعب تصحيح خطأ طلب بطيء إذا احتفظت فقط بالمدة. يذكر مرجع API و دليل استكشاف الأخطاء وإصلاحها، كلاهما تم رصده في 2026-10-03، المعرفات التي تستحق الاحتفاظ بها.

المعرف	أين يظهر	استخدمه لـ
X-Request-ID	رأس الاستجابة، عند توفره	الدعم وتصحيح الأخطاء لطلب واحد
request_id	هياكل الخطأ، سجلات لوحة التحكم، سجلات الاستخدام	دعم مستوى الطلب والمطابقة
X-Routing-Time-MS	رأس الاستجابة، عند توفره	الوقت المستغرق في اختيار التسليم، قبل التوليد
X-Task-ID, task_id, poll_url	استجابات الإنشاء والحالة غير المتزامنة	وظائف الصور، الفيديو، الموسيقى، وثلاثية الأبعاد
X-Billing-Transaction-ID	رأس بعد الفوترة النهائية، عند توفره	مطابقة التكلفة
معرف الوظيفة أو المستخدم الخاص بك	تطبيقك	العثور على الطلب خلف شكوى مستخدم

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

تحذيران. قد تستقر استجابات البث بعد انتهاء البث، لذا يمكن أن يغيب رأس الفوترة حتى عند تسجيل الاستخدام لاحقًا. بالنسبة للمبالغ المفوترة، استخدم سجلات استخدام Management API بدلاً من أعداد رموز الاستجابة وحدها. سجل أيضًا قيمة X-TokenLab-Delivery-Policy إذا قمت بضبط واحدة. يقول المرجع إنه يقبل auto أو verified أو official، وأن القيمة غير الصالحة تعيد 400، وأن الخيار غير المتاح يعيد 503 مع code: delivery_tier_unavailable و retryable: true. لا تسجل أبدًا Authorization، أو مفاتيح API، أو الروابط الموقعة، أو المطالبات الكاملة، أو البيانات الشخصية.

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

حدود المعدل، وإعادة المحاولة، وزمن الاستجابة مقابل الإنتاجية في LLM

سرعة البث الفردي وإنتاجية الحساب هما سقفان مختلفان. يسرد دليل حدود المعدل، الذي تم رصده في 2026-10-03، قيم المستوى القياسي أدناه. ويشير إلى أنها قد تتغير مع التكوين النشط ويتم فرضها لكل مفتاح API.

المستوى	الطلبات في الدقيقة
مستخدم	1,000
شريك	10,000
VIP	10,000

عند تجاوز الحد، تعيد API 429 rate_limit_exceeded مع رأس Retry-After. يحمل هيكل مثال الدليل "retryable": true و "retry_after": 8. يقول الدليل أن تثق بقيم X-RateLimit-Limit و Retry-After المعادة أكثر من أي جدول منسوخ. ويقول أيضًا إن النموذج الأسرع لا يزيد من حد طلبات حسابك.

إليك الحساب الخاص بعمل الدفعات. هذا تقديرنا من الوسائط أعلاه، وليس اختبار حمل. البث المتزامن هو تقريبًا الطلبات في الثانية مضروبة في الثواني لكل طلب. عند 1,000 طلب في الدقيقة (حوالي 16.7 في الثانية):

• مع deepseek-v4.1-flash عند وسيط إجمالي قدره 5.204 ثانية، يتم تشغيل حوالي 87 بثًا في وقت واحد.
• مع claude-sonnet-5-5 عند وسيط قدره 12.384 ثانية، يتم تشغيل حوالي 206 بثًا في وقت واحد.

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

كيفية إعادة المحاولة دون إفساد أرقامك:

• احترم Retry-After عند وجوده. بخلاف ذلك، استخدم التراجع الأسي (exponential backoff) مع تذبذب عشوائي وسقف محاولات صارم.
• اضبط SDK على max_retries=0 وأعد المحاولة في مكان واحد. بخلاف ذلك، ستعيد طبقتان المحاولة لنفس المكالمة وستقوم توقيتاتك بحسابها مرتين.
• لا تعد أبدًا محاولة أخطاء التحقق، أو المصادقة، أو الرصيد، أو الأذونات. أعد محاولة استجابات 5xx العابرة مع تراجع قصير.
• بعد وصول الحدث الأول، يكون البث المتقطع غير مكتمل ولا يتم إعادة تشغيله تلقائيًا. قد يؤدي تكرار الطلب إلى إنتاج مخرجات مختلفة ورسوم أخرى.
• سجل عدد مرات إعادة المحاولة ووقت الانتظار بشكل منفصل عن وقت النموذج، حتى لا تبدو الجولة المقيدة كنموذج بطيء.

هذا هو نمط إعادة المحاولة المحدود للدليل:

import random
import time
from openai import RateLimitError

def chat_with_rate_limit_retry(client, model, messages, attempts=4):
    for attempt in range(attempts):
        try:
            return client.with_options(max_retries=0).chat.completions.create(
                model=model,
                messages=messages,
            )
        except RateLimitError as exc:
            if attempt == attempts - 1:
                raise
            header = exc.response.headers.get("Retry-After")
            wait = float(header) if header else min(30, 2 ** attempt + random.random())
            time.sleep(wait)

قم أيضًا بوضع سقف للتزامن، وليس فقط متوسط الطلبات في الدقيقة، وقم بجدولة الطفرات. تتبع استجابات 429 المتكررة لكل مفتاح API حتى لا يتمكن عميل واحد من مزاحمة بقية تطبيقك.

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

هل الرموز الأعلى في الثانية تعني دائمًا تجربة مستخدم أسرع؟

لا. في عينتنا بتاريخ 2026-10-03، أظهر claude-sonnet-5-5 أول رمز مرئي في وقت مبكر (2,981 مللي ثانية) ولكن أطول زمن إجمالي (12,384 مللي ثانية). بدأ deepseek-v4.1-flash النص المرئي لاحقًا (3,925 مللي ثانية) وانتهى أولاً (5,204 مللي ثانية). أيهما يبدو أسرع يعتمد على ما إذا كان المستخدم يشاهد البث أو ينتظر الإجابة الكاملة. لا يمكن لخمس جولات من عميل واحد حسم ذلك لحجم عملك.

لماذا عادت استجابتي المبثوثة بدون نص تقريبًا؟

ربما أنفقت الميزانية على الاستنتاج. عند max_tokens 400، استخدم deepseek-v4.1-flash 400 رمز استنتاج وأعاد حوالي 0 رمز مرئي. تحقق من usage.completion_tokens_details.reasoning_tokens في جزء الاستخدام النهائي و finish_reason. ثم ارفع السقف؛ عند 2000 أجاب كلا نموذجي الاستنتاج في اختبارنا بالكامل.

هل النموذج الأسرع يرفع حد المعدل الخاص بي؟

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

ما هي المعرفات التي يجب أن أرسلها للدعم عندما يكون البث بطيئًا؟

أرسل request_id (أو X-Request-ID)، ونقطة النهاية، والطريقة، والنموذج، والطابع الزمني، ورمز الحالة. أضف task_id و poll_url للعمل غير المتزامن و billing_transaction_id عند توفره. قم بتضمين توقيتات التقسيم الخاصة بك وهيكل الخطأ الآمن، وقم بتنقيح المفاتيح، والمطالبات، والوسائط الخاصة أولاً.

قم بتشغيل أداة الاختبار أعلاه على مطالبتك الخاصة، ثم قارن ما تقيسه مع تصنيفات نماذج TokenLab.