زمن وصول OpenRouter على Anthropic: لماذا يعد استخدام مفتاحك الخاص أسرع

كانت الصفحة الرئيسية لـ OpenRouter تشير سابقاً إلى أنها تضيف حوالي 25 مللي ثانية بين المستخدمين وعملية الاستدلال، ولا تزال العديد من الأدلة تكرر هذا الرقم. أما الآن، فتكتفي الصفحة الرئيسية بعبارة "حد أدنى من زمن الاستجابة". لقد قمنا بقياس الوقت المستغرق قبل وصول الرمز الأول (token) في Claude عدة مرات، ووجدنا أن التكلفة الأكبر تظهر بعد ذلك.

تتعلق هذه القياسات بـ Anthropic: مقدار الوقت الذي تضيفه OpenRouter، وأين يذهب هذا الوقت، ولماذا أدى استخدام مفتاح Anthropic الخاص بنا إلى إزالة معظمه. استخدمت إحدى الجولات مطالبات قصيرة، بينما استخدمت الأخرى مطالبات تصل إلى 20,000 رمز. تظهر حدود كلتا الجولتين في القسم الخاص بما لم نقم باختباره، وهي تحدد الأرقام بقدر ما تفعل القيم المتوسطة.

كيف أجرينا القياسات

تم إرسال كل طلب بثلاث طرق: مباشرة إلى واجهة برمجة تطبيقات Anthropic، وعبر OpenRouter باستخدام أرصدة OpenRouter، وعبر OpenRouter باستخدام مفتاح Anthropic الخاص بنا (BYOK). تم تشغيل المطالبات نفسها على كل مسار، مع تبديل الترتيب لكل مطالبة، لضمان تأثر المسارات الثلاثة بالتغيرات في الشبكة بالتساوي. كل مقارنة هي مقارنة مزدوجة: تتم مقارنة كل مطالبة بنفسها عبر مسار آخر، مما يلغي تأثير محتوى المطالبة من فرق التوقيت.

تم تثبيت طلبات OpenRouter على نقطة نهاية Anthropic الخاصة بدلاً من Bedrock أو Vertex، مع إيقاف خيارات التراجع (fallbacks)، وتحققنا مع كل استجابة من نقطة النهاية التي خدمت الطلب وما إذا كانت قد استخدمت مفتاحنا. تم ضبط درجة الحرارة (Temperature) على 0 وإعادة استخدام الاتصالات.

تم إجراء جولتين. في 7 سبتمبر، أجرينا جلستين منفصلتين من 100 مطالبة قصيرة لكل منهما، بطول يتراوح بين 4 إلى 37 رمزاً، مستمدة من مجموعات بيانات عامة. وفي 14 سبتمبر، استخدمنا 99 مطالبة مقسمة إلى ثلاثة أحجام: 200 رمز إدخال مع 100 رمز إخراج، و2,000 مع 500، و20,000 مع 1,000. تم تشغيل كل شيء من حاسوب محمول عبر شبكة واي فاي منزلية من خلال نقطة اتصال OpenRouter في لوس أنجلوس. هذا يضخم زمن الاستجابة المطلق، لذا نحن نكتفي بالإبلاغ عن الفروقات بين المسارات، وهو ما يجعله صالحاً بفضل المقارنة المزدوجة.

مقدار زمن الاستجابة الذي تضيفه OpenRouter للرمز الأول

كانت تكلفة الرمز الأول ثابتة. عند استخدام الأرصدة، بلغت 192 مللي ثانية في الجلسة الأولى و206 مللي ثانية في الثانية، و194 مللي ثانية عند 200 رمز بعد أسبوع. ومع استخدام مفتاحنا الخاص، كانت 119 و124 و102 مللي ثانية. إن الحصول على نتائج متقاربة في حدود 20 مللي ثانية عبر جولتين تفصل بينهما أسبوع وعلى مجموعات مطالبات مختلفة هو أقصى ما يمكن أن يقدمه اختبار من جانب العميل. عبر أربع جلسات حيث تم تشغيل الأرصدة ومفتاحنا الخاص جنباً إلى جنب، كانت الأرصدة أبطأ في الوصول للرمز الأول في كل مرة، بمتوسط يتراوح بين 50 إلى 115 مللي ثانية.

كما يزداد هذا الوقت مع حجم المطالبة. من 200 إلى 20,000 رمز إدخال، ارتفع الوقت المضاف للرمز الأول من 194 إلى 303 مللي ثانية عند استخدام الأرصدة، ومن 102 إلى 186 مللي ثانية عند استخدام مفتاحنا الخاص. النمو هنا أقل من خطي، بمقدار 1.6 إلى 1.8 مرة تقريباً مقابل مئة ضعف في الإدخال، ولم يصبح مرئياً إلا عند 20,000 رمز؛ حيث لم يظهر أي شيء في مسح سابق توقف عند 5,000 رمز. أما ضمن جولات المطالبات القصيرة، حيث تراوحت المدخلات بين 4 و37 رمزاً فقط، لم تكن هناك أي علاقة على الإطلاق.

على GPT-4o mini، ظل القياس نفسه ضمن نطاق الضجيج في جميع الظروف، بما في ذلك المطالبات المكونة من 20,000 رمز. كان متوسط الوقت المضاف للرمز الأول 19.7 مللي ثانية عند استخدام الأرصدة، لكن نصف النتائج تراوحت بين 85 مللي ثانية أسرع إلى 157 مللي ثانية أبطأ من الاتصال المباشر، لذا فإن الرقم الحقيقي أصغر مما يمكن لإعداداتنا رصده.

Take control of your LLM traffic

Route models, enforce budgets, and monitor every request from your own infrastructure.

Book a demo

تكلفتان، لا واحدة

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

مع استخدام مفتاحنا الخاص، أضافت OpenRouter حوالي 120 مللي ثانية قبل الرمز الأول ولا شيء بعده. تدفق مفتاحنا بمعدل 115 و116 رمزاً في الثانية في الجلستين، مقابل 115 و113 عند الاتصال المباشر. أياً كانت هذه التكلفة، فهي تُدفع مرة واحدة في البداية.

عند استخدام الأرصدة، تدفقت الإجابات نفسها بشكل أبطأ، بمعدل 94 و95 رمزاً في الثانية، أي أبطأ بنحو 17%. لم تكن الاستجابات أطول: كان متوسط المخرجات حوالي 290 رمزاً في كل مسار. في إجابة من 290 رمزاً، يضيف هذا التدفق الأبطأ حوالي 520 مللي ثانية، بالإضافة إلى تكلفة الرمز الأول. الحسابات متطابقة: 290 رمزاً بمعدل 94 بدلاً من 114 رمزاً في الثانية تعادل حوالي 540 مللي ثانية، بالإضافة إلى حوالي 200 مللي ثانية للرمز الأول، مقابل 711 و730 مللي ثانية التي قمنا بقياسها للاستجابة الكاملة.

كانت عقوبة التوليد هذه حقيقية في كلتا الجولتين ولكنها لم تكن بنفس الحجم. في 14 سبتمبر، كان الوقت الإضافي بعد الرمز الأول حوالي 130 و215 و280 مللي ثانية لإجابات مكونة من 100 و500 و1,000 رمز، وهي أصغر بكثير مما كانت عليه في 7 سبتمبر. تأتي هذه الأرقام من القيم المتوسطة بدلاً من الفروقات المزدوجة، لذا تعامل معها كأرقام تقريبية، لكن الاتجاه واضح: تكلفة الرمز الأول ظلت ثابتة عبر الأيام وأحجام المطالبات، بينما تباينت عقوبة التوليد.

السبب: البوابة والحساب

تشير التكلفتا إلى سببين مختلفين.

تظهر تكلفة الرمز الأول (first-token) عند استخدام مفتاحنا الخاص وكذلك عند استخدام الأرصدة، لذا فهي مرتبطة بمسار OpenRouter إلى Anthropic وليس بالحساب الذي يتم الدفع من خلاله. الاحتمالات الأكثر ترجيحاً هي عملية ترجمة طلب بتنسيق OpenAI إلى تنسيق الرسائل الخاص بـ Anthropic وترجمة البث مرة أخرى، بالإضافة إلى مسار الشبكة من حافة OpenRouter إلى Anthropic. يتناسب النمو مع حجم المطالبة (prompt) مع الاحتمال الأول، حيث تتناسب أعمال الترجمة طردياً مع الطلب. لا يمكن لبياناتنا الفصل بين الاثنين، كما أن غياب أي تكلفة ملموسة على نموذج GPT-4o mini، الذي لا يحتاج إلى ترجمة تنسيق، يتوافق مع كلا الاحتمالين. إن إرسال نفس الطلبات عبر نقطة نهاية Anthropic الأصلية في OpenRouter، /api/v1/messages، هو التجربة التي ستحسم الأمر، ولم نقم بإجرائها بعد.

تختلف عقوبة التوليد (generation penalty). تمر الأرصدة ومفتاحنا الخاص عبر نفس البوابة، ونفس عملية الترجمة، ونفس نقطة نهاية Anthropic. ما يختلف هو حساب Anthropic الذي يقف خلف الطلب: سواء كان حساب OpenRouter المشترك بين عملائه، أو حسابنا الخاص. تفسيرنا الأفضل هو أن الطلبات التي تتم عبر حساب OpenRouter يتم تقديمها بسعة أقل من الطلبات التي تتم عبر حسابنا، وأن هذه الكمية تختلف باختلاف الطلب، وهو ما يفسر أيضاً سبب انخفاض العقوبة بين تجربتينا. هذا استنتاج، حيث لا تنشر OpenRouter ولا Anthropic كيفية تصنيف الحسابات.

على OpenAI، انعكس النمط. ففي نموذج GPT-4o mini، وصلت الأرصدة إلى الرمز الأول أسرع بـ 23 إلى 50 مللي ثانية من مفتاحنا الخاص في جميع الجلسات الثلاث التي تم تشغيل كليهما فيها، وفي الجلسة التي قارنا فيها سرعة البث، تم التوليد بنفس المعدل. الحساب الذي يخدم طلبك يؤثر بالفعل على السرعة، ويعتمد الحساب الأسرع على المزود. لا يمكنك معرفة المستوى الذي تقع فيه من الخارج، يمكنك فقط قياسه.

الذيول والاستجابات الكاملة

منتصف التوزيع يمثل الطلب النموذجي. الذيول مهمة للعمل الموجه للمستخدم. في جلستي المطالبات القصيرة، كان الوقت عند النسبة المئوية 95 للوصول إلى الرمز الأول حوالي 700 مللي ثانية عند الاتصال المباشر، و950 إلى 985 مللي ثانية عند استخدام الأرصدة، و885 إلى 905 مللي ثانية عند استخدام مفتاحنا الخاص. اتسعت النسبة المئوية 99 بشكل أكبر بكثير في كلا مساري OpenRouter، من حوالي 750 إلى 765 مللي ثانية مباشرة إلى 1.2 إلى 2.6 ثانية عند استخدام الأرصدة، ولكن عند 100 طلب لكل جلسة، فإن النسبة المئوية 99 هي فعلياً ثاني أبطأ طلب، لذا اعتبرها مؤشراً على ذيل أثقل بدلاً من كونها رقماً دقيقاً.

بدون بث، الصورة هي نفسها. عند مقارنتها بالاتصال المباشر، أضافت الأرصدة 548 و629 مللي ثانية إلى الاستجابة الكاملة في جلستين، وأضاف مفتاحنا الخاص 42 و56 مللي ثانية.

ما لم نختبره

تغطي هذه النتائج نموذجاً واحداً، وهو Claude Haiku 4.5، على نقطة نهاية Anthropic الخاصة. لم نختبر Sonnet أو Opus، أو Claude على Bedrock أو Vertex عبر OpenRouter، أو حواف OpenRouter الأخرى، أو أوقات مختلفة من اليوم. عمليات التشغيل ذات المطالبات القصيرة قابلة للتكرار من خلال أدواتنا المنشورة. كانت عملية التشغيل ذات المطالبات المبطنة جلسة منفصلة. لم نقم بإجراء مسح للتزامن على أرصدة Anthropic، وهو الاختبار الأكثر مباشرة لتفسير السعة المشتركة، أو اختبار /api/v1/messages الموصوف أعلاه. وكل شيء تم تشغيله من عميل واحد، وهو أمر جيد للفروق بين المسارات ولكنه لا يخبرنا شيئاً عن زمن الوصول المطلق من بنيتك التحتية.

ما الذي يجب فعله حيال ذلك

• إذا كان زمن الوصول على Claude مهماً بالنسبة لك، فاستخدم مفتاح Anthropic الخاص بك. في اختباراتنا، أدى ذلك إلى إزالة عقوبة التوليد بالكامل وحوالي 40% من تكلفة الرمز الأول. كما أنه عادة ما يكون أرخص.
• تحقق من نقطة النهاية التي خدمتك فعلياً. أرسل X-OpenRouter-Experimental-Metadata: enabled واقرأ openrouter_metadata في الاستجابة، والتي تخبرك بنقطة النهاية التي قدمت الخدمة وما إذا كان قد تم استخدام مفتاحك الخاص. بدون ذلك، أنت تعتمد فقط على التخمين.
• ثبّت المزود إذا كنت بحاجة إلى زمن وصول متوقع. فخدمة Claude المقدمة من Anthropic وBedrock وVertex هي مسارات مختلفة.
• قم بالقياس بناءً على حركة المرور الخاصة بك باستخدام الاقتران. أرسل كل مطالبة عبر كلا المسارين، وبدّل الترتيب، واطرح النتائج لكل مطالبة، ثم سجل متوسط الفرق مع النطاق الربيعي. إذا كان النطاق يتقاطع مع الصفر، فأنت لم تقم بقياس حمل إضافي، بل قمت بقياس ضجيج. إن نظرتنا العامة حول كيفية توجيه OpenRouter للطلبات تغطي بقية مسار الطلب.

تعد حدود المعدل (Rate limits) سبباً شائعاً آخر لشعورك ببطء Claude عبر OpenRouter، ومنشورنا حول حدود معدل OpenRouter يشرح كيفية التمييز بين الاستجابة البطيئة والاستجابة المقيدة.

نهج TrueFoundry في هذا الشأن

تعمل بوابة TrueFoundry للذكاء الاصطناعي داخل سحابتك الخاصة (VPC) أو مركز بياناتك، وتتصل بـ Anthropic مباشرة باستخدام مفتاحك وعقدك الخاص، لذا لا تتشارك الطلبات أبداً في حساب المنبع مع عملاء آخرين، ولا توجد قفزة لطرف ثالث بين شبكتك والمزود. الرقم الذي نشرناه هو حوالي 3 إلى 4 مللي ثانية كحمل إضافي للبوابة، مع معالجة أكثر من 350 طلباً في الثانية على وحدة معالجة مركزية افتراضية واحدة (vCPU).

رقم 3 إلى 4 مللي ثانية هو المعيار المنشور لـ TrueFoundry. لم نقم بقياسه باستخدام أداة الاختبار المذكورة في هذا المنشور. إذا كنت ترغب في مقارنة البوابات، فإن طريقة الاقتران المذكورة أعلاه هي الطريقة التي نتبعها، وهي تعمل مع أي نقطة نهاية متوافقة مع OpenAI، بما في ذلك بوابتنا.

Try TrueFoundry AI Gateway

Connect your models and start managing LLM traffic through one API.

Sign up

قراءات ذات صلة

• التخزين المؤقت للمطالبات (Prompt Caching) في OpenRouter، بما في ذلك ذاكرة التخزين المؤقت للاستجابات في OpenRouter، والتي أجابت على الطلبات المتكررة في حوالي 59 مللي ثانية
• بدائل OpenRouter، مقارنة بين الخيارات المتاحة لفرق العمل في بيئات الإنتاج
• أفضل بوابات الذكاء الاصطناعي لتحسين استنتاج النماذج اللغوية الكبيرة (LLM)، حول كيفية تعامل البوابات مع التوجيه وزمن الوصول
• ما هي بوابة النماذج اللغوية الضخمة (LLM Gateway)؟، البنية العامة لها

الخلاصة

يتكون زمن وصول OpenRouter على Anthropic من جزأين. تكلفة الرمز الأول (first-token) تتراوح بين 100 إلى 300 مللي ثانية تقريباً وتزداد مع حجم المطالبة وتظهر بغض النظر عن الحساب الذي تستخدمه، بالإضافة إلى توليد أبطأ عند استخدام أرصدة OpenRouter، مما أضاف أكثر من نصف ثانية إلى إجابة نموذجية في إحدى التجارب وأقل في تجربة أخرى. أدى استخدام مفتاحك الخاص إلى إزالة التوليد الأبطأ في اختباراتنا، مع بقاء تكلفة الرمز الأول كما هي. الطريقة الوحيدة لمعرفة تكلفة هذا الانتظار الإضافي على مطالباتك هي قياسه بالطريقة التي اتبعناها، وهي الاقتران.

للاتصال بـ Anthropic باستخدام مفتاحك الخاص، ومن شبكتك الخاصة، دون حساب منبع مشترك، اطلع على كيفية اتصال بوابة TrueFoundry للذكاء الاصطناعي بـ Anthropic مباشرة.