شغّل تطبيقات Dify على نقطة نهاية متوافقة مع OpenAI API.

إجابة سريعة: ثبّت المزوّد، أضف النماذج بالمعرّف.

في Dify، افتح Settings واذهب إلى Model Provider. منذ Dify 1.0، المزوّدون إضافات: ابحث عن OpenAI-API-compatible (المنشورة بواسطة langgenius) في القائمة أو ثبّتها من Marketplace، ثم انقر Add Model على بطاقتها. الحوار لكل نموذج: اختر Model Type (LLM لنماذج المحادثة)، أدخل معرّف الكتالوج الدقيق في Model Name، الصق مفتاحك في API Key، واضبط API Base URL على https://api.apisrouter.com/v1. اترك Completion mode على Chat، ثم اضبط Model context size وUpper bound for max tokens على الحدود الموثَّقة للمعرّف الذي تضيفه. احفظ، ويظهر النموذج في قائمة المزوّد، قابلاً للاختيار من قائمة النموذج المنسدلة في كل تطبيق. كرّر الحوار لكل معرّف تريده؛ دقيقتان لكل نموذج، مرة واحدة.

Model Type:                LLM
Model Name:                claude-sonnet-4-6
API Key:                   sk-YOUR-APISROUTER-KEY
API Base URL:              https://api.apisrouter.com/v1
Completion mode:           Chat
Model context size:        200000
Upper bound for max tokens: 64000

كيف يتحدث Dify إلى مزوّد متوافق.

Dify (langgenius على GitHub، بنحو 149 ألف نجمة) هو منصة تطبيقات LLM مفتوحة المصدر الرائدة: تدفقات عمل مرئية، عُقَد وكلاء، أنابيب RAG فوق قواعد معرفة، وتطبيقات منشورة بنقاط نهاية API خاصة بها. كل عُقدة LLM في تلك المجموعة تحل نموذجاً مسجَّلاً تحت مزوّد ما. مزوّد OpenAI-API-compatible عام عمداً. كل نموذج تضيفه سجل قائم بذاته، معرّف، نقطة نهاية، مفتاح، حدود، ويرسل Dify طلبات chat-completions قياسية إلى base URL المُعَدّ بـ Model Name الخاص بك كسلسلة النموذج. لا شيء في الطلب يهتم بأي بائع دَرَّب النموذج، لذا claude-sonnet-4-6 وdeepseek-v4-pro صالحان هنا مثل أي معرّف GPT، ويمكن حتى لنماذج مختلفة أن تشير إلى نقاط نهاية مختلفة إذا احتجت ذلك يوماً. التسجيل لكل نموذج الذي يبدو احتكاكاً هو أيضاً سطح التحكم: قيم حجم السياق والحد الأقصى لـ tokens التي تدخلها هي ما يستخدمه منسّق Dify لموازنة الموجّهات، وتقليم سجل المحادثة، والتحقق من إعدادات العُقَد. أدخل أرقاماً صادقة من توثيق النموذج. المبالغة في السياق تنتج طلبات ترفضها نقطة النهاية؛ التقليل منه يُقلِّم بصمت السياق الذي عملت عُقَد RAG على استرجاعه.

الحقول التي تقوم بعمل حقيقي.

Model Name هو قيمة الشبكة: يجب أن يطابق قائمة /v1/models الخاصة بالبوابة حرفاً بحرف، لأنه يسافر في كل طلب. اسم عرض النموذج الاختياري يعيد فقط تسمية الواجهة. يجب أن يبقى Completion mode على Chat لكل نموذج في الكتالوج الحالي؛ خيار Completion موجود لنقاط نهاية إكمال النص القديمة وينتج طلبات مشوَّهة مقابل نماذج المحادثة. Model context size وUpper bound for max tokens هما الزوج الذي يتسرّع الناس فيه. حجم السياق هو نافذة النموذج الكاملة؛ الحد الأقصى يحدّ عدد tokens المُخرَج الذي قد تطلبه عُقدة. يضبط Dify كليهما افتراضياً على 4096، وهو أقل بكثير مما تدعمه النماذج الحالية، وترك الافتراضات يُعطِّل بهدوء RAG للمستندات الطويلة والتوليد الطويل. اضبطهما من توثيق النموذج، لا من العادة. محدِّدات القدرة تهم عندما تستخدمها تطبيقاتك: Vision Support فقط للمعرّفات التي تقبل مدخل صور، وإعداد استدعاء الدالة ليطابق دعم النموذج لاستخدام الأدوات، لأن عُقَد الوكلاء تعتمد عليه. ادّعاء قدرة خاطئ يفشل وقت التشغيل داخل تدفق العمل، وهو مكان أبطأ للتصحيح من هذا الحوار. إذا استخدمت مساحة عملك نماذج تضمين أو إعادة ترتيب أيضاً، يسجّلها نفس المزوّد تحت مُدخَلات Model Type الخاصة بها مقابل نفس base URL؛ تأكّد من أن نقطة النهاية تخدم المعرّفات المحددة قبل ربط إعدادات قاعدة المعرفة بها.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50
# register these ids verbatim as Model Name entries

اختيار النماذج لتدفقات العمل والوكلاء.

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

• عُقَد LLM في تدفق العمل حجمية: خطوات تصنيف واستخراج وتوجيه وتلخيص تُطلَق في كل تشغيل. claude-haiku-4-5-20251001 وgpt-5.4-mini وgemini-3.5-flash تُبقي التكلفة لكل تشغيل ثابتة.
• عُقَد الوكلاء وخطوات الاستدلال المعقدة تستحق claude-sonnet-4-6، واستخدام الأدوات الموثوق لديه يهم أكثر في الوكلاء من درجات المعايير الخام.
• عُقَد إجابة RAG تحمل سياقاً مسترجَعاً في كل استدعاء، لذا يهيمن سعر المدخل؛ deepseek-v4-pro يستحق الاختبار حيث يكون الاسترجاع ثقيلاً والإجابات طويلة.
• سجّل معرّفاً سريعاً ومعرّفاً قوياً لنفس الدور واختبرهما A/B لكل عُقدة: في Dify، تبديل نموذج عُقدة هو قائمة منسدلة، لا ترحيل.
• ترث التطبيقات المنشورة اختيارات نموذج عُقَدها، لذا قرار القائمة المنسدلة الذي تتخذه في المحرر هو اقتصاديات الوحدة للتطبيق الذي تشحنه.

ادفع حسب الاستخدام · أقل من السعر الرسمي

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

أنماط الفشل الخاصة بـ Dify.

غياب المزوّد من القائمة يعني أن الإضافة غير مثبَّتة: منذ Dify 1.0 يُشحَن مزوّد OpenAI-API-compatible كإضافة Marketplace، وتبدأ النسخ الجديدة ذاتية الاستضافة بدونه. ثبّته مرة واحدة لكل مساحة عمل. نموذج يُحفَظ لكن يخطئ عند أول استخدام عادة أحد ثلاثة أشياء: Model Name لا يطابق هجاء الكتالوج، أو base URL يفتقد /v1 الخاص به (يُلحِق Dify مسارات مثل /chat/completions بما تدخله)، أو قيم سياق/tokens تتجاوز ما يقبله النموذج. يظهر الخطأ في سجل التطبيق أو تدفق العمل؛ الإصلاح يعود إلى حوار Add Model. عُقَد الوكلاء تفشل بينما عُقَد المحادثة العادية تعمل تشير إلى إعداد قدرة استدعاء الدالة، أو إلى نموذج لا يفي استخدام أدواته بما تتوقعه استراتيجية الوكيل. اختبر الوكلاء مقابل claude-sonnet-4-6 أولاً لفصل مشاكل الإعداد عن اختيار النموذج. وعلى النسخ ذاتية الاستضافة خلف قواعد خروج صارمة، تذكّر أن حاوية api الخاصة بـ Dify هي التي يجب أن تصل إلى نقطة النهاية، لا متصفحك؛ طلب curl من داخل تلك الحاوية يحسم أسئلة الاتصال بسرعة.

من يوجّه Dify عبر بوابة.

• الفرق التي تبني تطبيقات LLM وتريد Claude وGPT وGemini وDeepSeek قابلة للاختيار لكل عُقدة دون حساب بائع لكل مزوّد.
• المستضيفون ذاتياً الذين يشغّلون Dify لأدوات داخلية، حيث يُبقي مفتاح واحد في مزوّد واحد إنفاق السحابة لمساحة العمل بأكملها على سجل استخدام واحد.
• المُنشِئون الذين يقارنون النماذج على تدفقات عمل حقيقية: كل مرشّح حوار Add Model وتبديل قائمة منسدلة، لا تكامل جديد.
• المطورون الذين لا يملكون وصولاً إلى فوترة بائع معيّن. الوصول القائم على تعبئة الرصيد بدون شرط بطاقة يزيل الاعتماد على التسجيل لكل مزوّد.
• الوكالات التي تشحن تطبيقات عملاء على Dify وتحتاج مفاتيح لكل مشروع بحيث يُبلِّغ إنفاق نموذج كل عميل عن نفسه.

تحقق من نقطة النهاية وصحّح أخطاء أول تشغيل.

أجرِ curl على قائمة النماذج أولاً وسجّل المعرّفات من مخرجاتها؛ أسماء Model Name المكتوبة يدوياً هي السبب الرئيسي لأخطاء not-found لأن الحقل نص حر. ثم شغّل إكمال محادثة واحد مقابل المعرّف الذي سجّلته، بنفس المفتاح. داخل Dify، اختبر في تطبيق تجريبي قبل ربط تدفقات عمل الإنتاج: أضف عُقدة LLM، اختر النموذج الجديد، شغّل مرة واحدة. أخطاء المصادقة تشير إلى حقل API Key؛ not-found إلى Model Name؛ أخطاء الاتصال إلى base URL أو خروج الحاوية؛ أخطاء الطول إلى قيم السياق وtokens. بمجرد تدفّق التشغيلات، تعرض لوحة APIsRouter النموذج لكل طلب، وعدد tokens، والإنفاق. تدفقات العمل تُضاعِف استدعاءات LLM بطرق يصعب تقديرها بالعين من المحرر، وسجل الاستخدام هو حيث يصبح ملف tokens الحقيقي لأنبوب من خمس عُقَد مرئياً، لكل نموذج، لكل يوم.

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-haiku-4-5-20251001",
       "messages":[{"role":"user","content":"ping"}]}'

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