OpenRouter: كيف يمكن أن تصبح شركة بقيمة مليار دولار من خلال "محطة نقل النماذج"؟

المؤلف: تشانغ آيلا

اليوم سنتحدث عن المحطات الوسيطة.

ببساطة، المحطة الوسيطة للنماذج هي ربط نماذج مختلفة مثل OpenAI وClaude وGemini وDeepSeek بنفس المدخل، مما يتيح للمطورين استخدام واجهة واحدة وحساب واحد وفاتورة موحدة لاستدعاء نماذج متعددة، والاختيار والتبديل والاحتياط بين النماذج والمزودين المختلفين.

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

هذا ما يفهمه الجميع، ولن نتحدث كثيرًا عن المحطات الوسيطة المحلية، سنقدم اليوم بشكل أساسي OpenRouter.

بحلول عام 2026، جمعت OpenRouter تمويلًا من الفئة ب بقيمة 113 مليون دولار، ووصل تقييمها إلى ما يقرب من 1.3 مليار دولار.

أي أنها أصبحت شركة وحيدة القرن.

دعنا نحلل لماذا يمكن لمحطة وسيطة للنماذج "لا تصنع نماذج" أن تساوي هذا المبلغ الكبير؟

ما الذي يفعله OpenRouter بالضبط؟

يصّف OpenRouter رسميًا نفسه بأنه: واجهة موحدة للنماذج الكبيرة.

يدعم OpenRouter حاليًا أكثر من 400 نموذج وأكثر من 70 مزودًا للنماذج.

يكشف الموقع الرسمي أيضًا أن معالجة المنصة الشهرية بلغت 100 تريليون توكن، وأكثر من 10 ملايين مستخدم عالميًا.

في إعلان تمويل الفئة ب في مايو 2026، تم ذكره أيضًا أن OpenRouter زادت معالجته الأسبوعية من 5 تريليون توكن إلى 25 تريليون توكن خلال الأشهر الستة الماضية، ويخدم أكثر من 8 ملايين مطور.

تشير هذه الأرقام إلى شيء واحد:

OpenRouter لم يعد أداة مطورين صغيرة، بل أصبح بوابة اتصال كبيرة للذكاء الاصطناعي.

طريقة استخدام المطورين له بسيطة جدًا أيضًا.

في السابق، كان عليك الاتصال بشكل منفصل بـ OpenAI وAnthropic وGoogle وDeepSeek وMistral وxAI وغيرها من النماذج.

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

بعد استخدام OpenRouter، يمكن للمطورين استدعاء نماذج مختلفة من خلال نفس الواجهة.

في كثير من الأحيان، الكود الذي كان يستخدم واجهة OpenAI سابقًا، يحتاج فقط إلى تغيير رابط base URL، ومفتاح API، وتحديد اسم النموذج، لاستدعاء نماذج أخرى عبر OpenRouter.

هذا هو أحد الأسباب التي جعلت نموه سريعًا في البداية: تكلفة الانتقال منخفضة.

لماذا لا يتصل المطورون مباشرة بشركات النماذج؟

يبدو أن المطورين يمكنهم تجاوز OpenRouter تمامًا والذهاب إلى موقع شركة النموذج لفتح API.

لكن في التطوير الفعلي، الأمر ليس بهذه البساطة.

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

على سبيل المثال، أداة كتابة بالذكاء الاصطناعي قد تحتوي على عدة أنواع من المهام:

توليد العناوين، يكفي نموذج رخيص؛

كتابة مقالات طويلة، تحتاج قدرات نصية أقوى؛

تحليل المواد، تحتاج نموذج سياق طويل؛

مراجعة المحتوى، تحتاج قدرة تصنيف منخفضة التكلفة وعالية الاستقرار؛

عملاء الشركات يطلبون عدم الاحتفاظ بالبيانات، فيجب اختيار مزود يتوافق مع سياسات البيانات؛

في أوقات الذروة يتم تقييد النماذج، فيجب التبديل تلقائيًا إلى نموذج احتياطي.

في هذه الحالة، المشكلة ليست مجرد "الاتصال بـ API واحد".

يحتاج الفريق إلى صيانة نظام كامل لاستدعاء النماذج:

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

الأكثر إزعاجًا هو أن سوق النماذج يتغير بسرعة كبيرة.

اليوم Claude مناسب لكتابة الكود، وغدًا سياق Gemini الطويل له ميزة، وبعد غد DeepSeek أو نموذج مفتوح المصدر يخفض السعر.

قدرات النماذج والأسعار وأطوال السياقات وسياسات المزودين، كلها تتغير باستمرار.

هنا تكمن قيمة OpenRouter.

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

ليس مجرد سوبرماركت نماذج، بل طبقة جدولة للنماذج

إذا فهمنا OpenRouter فقط على أنه "سوبرماركت نماذج"، فإننا نقلل من شأنه.

السوبرماركت يحل مشكلة "هناك العديد من النماذج، يمكنك الاختيار".

لكن القدرة الحقيقية لـ OpenRouter هي الجدولة بين النماذج والمزودين.

نفس النموذج قد يتم تقديم خدمة الاستدلال بواسطة مزودين مختلفين.

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

في وثائق OpenRouter، هناك قدرة تسمى provider routing، أي توجيه المزودين.

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

كما يدعم fallback، أي عند فشل نموذج أو مزود معين، يتحول النظام تلقائيًا إلى الخيار الاحتياطي.

بالنسبة للمطورين، فإن OpenRouter يمثل إخراج "اختيار النموذج" و"معالجة الأعطال" من كود الأعمال وتسليمها إلى منصة متخصصة.

لماذا تحتاج الشركات إلى هذه الطبقة؟

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

قد يكون داخل الشركة العديد من الفرق التي تستخدم الذكاء الاصطناعي.

فريق التسويق لكتابة المحتوى، فريق خدمة العملاء للرد على المستخدمين، فريق البحث والتطوير لكتابة الكود، فريق التشغيل لتحليل البيانات، فريق الشؤون القانونية لمعالجة العقود.

إذا كان كل فريق يتصل بالنماذج بنفسه، فإن المشاكل تزداد:

الفواتير غير واضحة؛ اختيار النماذج غير موحد؛

سياسات البيانات غير شفافة؛ تكرار الاتصال بين فرق مختلفة؛

في حالة حدوث مشكلة، لا أحد يعلم أي استدعاء هو المسؤول؛

عندما يتغير مزود النموذج، يصعب تعديل النظام بشكل موحد.

توفر OpenRouter مساحات العمل، والتحكم في الميزانية، وسجلات الاستدعاء، وسياسات المزودين، وتوجيه عدم الاحتفاظ بالبيانات، كلها تعالج هذه المشاكل.

مثل عدم الاحتفاظ بالبيانات.

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

تدعم وثائق OpenRouter Zero Data Retention، أي عدم الاحتفاظ بالبيانات.

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

مثال آخر هو prompt caching، أي تخزين مؤقت للتحفيز.

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

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

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

كيف يكسب OpenRouter المال؟

نموذج عمل OpenRouter واضح جدًا: يكسب المال بناءً على حجم الاستخدام.

يشتري المطورون رصيد المنصة أولاً، ثم يدفعون بناءً على النماذج والتوكنات التي يتم استدعاؤها فعليًا.

يكتب OpenRouter رسميًا بوضوح:

تفرض المنصة رسومًا بنسبة 5.5% عند شراء الرصيد، بحد أدنى 0.8 دولار؛ أسعار النماذج الأساسية من المزودين تمرر للمستخدمين بالسعر الأصلي، دون إضافة رسوم إضافية على سعر استدلال النموذج.

هذا عمل نموذجي "رسوم مرور".

ميزة هذا النموذج هي أن الإيرادات مرتبطة بالاستخدام.

كلما زاد استدعاء المطورين، زاد دخل المنصة؛ كلما زادت تطبيقات الذكاء الاصطناعي واستهلاك التوكنات، زادت أعمال OpenRouter.

ولكن لها أيضًا خاصية: العمولة لكل استدعاء ليست عالية، لذا يجب الاعتماد على الحجم.

ولهذا السبب تعتبر معالجة التوكنات مهمة جدًا لـ OpenRouter.

مؤشرها الأساسي ليس عدد المستخدمين المسجلين، بل كم عدد التوكنات التي تمر عبرها أسبوعيًا وشهريًا.

في عام 2025، زادت معالجة OpenRouter السنوية من حوالي 10 تريليون توكن إلى أكثر من 100 تريليون توكن.

بحلول عام 2026، وصلت OpenRouter إلى حوالي 1.5 كوادريليون توكن سنويًا.

هذا هو المنطق الأساسي لهذا العمل.

طالما أن المزيد من تطبيقات الذكاء الاصطناعي تعمل على أنظمة متعددة النماذج، يمكن لـ OpenRouter استخلاص رسوم الخدمة باستمرار من هذه الاستدعاءات.

لماذا النمو سريع جدًا مؤخرًا؟

يمكن تلخيص نمو OpenRouter في استفادته من ثلاثة تغييرات.

التغيير الأول، هو زيادة عدد النماذج.

في السابق، عند بناء تطبيقات الذكاء الاصطناعي، كان العديد من الفرق يبدؤون بـ OpenAI افتراضيًا. الآن الأمر مختلف.

Claude وGemini وDeepSeek وQwen وMistral وLlama وGrok، بالإضافة إلى عدد كبير من النماذج مفتوحة المصدر والوزن المفتوح، كلها لها مزايا في سيناريوهات مختلفة.

هذا ليس سوقًا "يحل أحدهم محل الآخر بالكامل".

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

كلما زادت النماذج، زادت تكلفة الاختيار؛ كلما زادت تكلفة الاختيار، زادت قيمة الطبقة الوسيطة.

التغيير الثاني، هو أن تطبيقات الذكاء الاصطناعي بدأت تهتم بالتكاليف.

العديد من المنتجات في البداية تستخدم أقوى نموذج، لأنهم يحتاجون إلى تحقيق النتائج أولاً.

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

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

الأسلوب الأكثر نضجًا هو تقسيم المهام:

المهام البسيطة تستخدم نموذجًا رخيصًا؛

المهام المعقدة تستخدم نموذجًا قويًا؛

المهام المتكررة تفضل نموذجًا بزمن استجابة منخفض؛

عند الفشل، التبديل إلى نموذج احتياطي؛

عندما تتعلق البيانات الحساسة، فقط توجيهها إلى مزودين متوافقين مع سياسات البيانات.

هذا هو سيناريو استخدام OpenRouter.

ليس بالضرورة أن يساعدك في العثور على "أقوى نموذج"، لكنه يمكنه مساعدتك في تحقيق التوازن بين الفعالية والسعر والسرعة والاستقرار.

التغيير الثالث، هو أن تطبيقات الذكاء الاصطناعي تنتقل من مربع الحوار إلى الوكلاء.

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

بالمقارنة مع الدردشة العادية، يستهلك الوكلاء توكنات أكثر، ويعتمدون أكثر على الاستقرار.

هذا مفيد لـ OpenRouter.

لأنه كلما زاد عدد الاستدعاءات وطول السلسلة، كلما كان المطورون بحاجة إلى التوجيه والاحتياطي والسجلات والتحكم في التكاليف وإدارة المزودين.

ولهذا السبب تؤكد إعلانات تمويل OpenRouter أن الذكاء الاصطناعي ينتقل من التجارب إلى تطبيقات الإنتاج الحرجة وسيناريوهات الوكلاء.

نموها، في جوهره، يأتي من ارتفاع حجم استدعاءات الذكاء الاصطناعي.

هذا العمل له أيضًا مخاطر

موقع OpenRouter جيد، لكنه ليس آمنًا.

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

الخطر الأول، هو أن الشركات الكبيرة قد تقوم ببناء نظامها الخاص.

بالنسبة للفرق الصغيرة، OpenRouter يوفر الراحة.

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

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

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

الخطر الثاني، هو أن مزودي الخدمات السحابية سيبنون أيضًا بوابات للنماذج.

منصات السحابة مثل AWS وGoogle Cloud وAzure، لديها بالفعل عملاء من الشركات، وأنظمة فواتير، وأنظمة أذونات، وقدرات امتثال.

يمكنهم بسهولة جعل الاستدعاء المتعدد للنماذج والتوجيه والمراقبة وإدارة التكاليف جزءًا من خدماتهم السحابية.

ميزة OpenRouter هي الانفتاح والحياد، وتغطية أوسع للنماذج، وسرعة اتصال أسرع.

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

الخطر الثالث، هو العلاقة مع مزودي النماذج.

يجلب OpenRouter حركة المرور لشركات النماذج، لكنه أيضًا يجعل شركات النماذج أبعد عن المطورين النهائيين.

عندما تكبر المنصة، سيكون لديها المزيد من علاقات المستخدمين وبيانات استخدام النماذج.

مزودو النماذج يأملون في التوزيع، لكنهم أيضًا يخشون من إضعاف قوتهم التفاوضية.

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

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

OpenRouter يتقاضى 5.5% كرسوم منصة، وهو حاليًا ليس مرتفعًا.

ولكن إذا ظهرت خدمات مماثلة أكثر، فسيقارن المطورون الأسعار والاستقرار وتغطية النماذج ووظائف الشركات.

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

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