הריצו אפליקציות Dify על endpoint תואם OpenAI-API.

תשובה מהירה: התקינו את הספק, הוסיפו מודלים לפי id.

ב-Dify, פתחו את ההגדרות ועברו ל-Model Provider. מאז Dify 1.0, ספקים הם plugins: מצאו את OpenAI-API-compatible (מפורסם על ידי langgenius) ברשימה או התקינו אותו מה-Marketplace, ואז לחצו Add Model על הכרטיס שלו. הדיאלוג הוא לכל מודל: בחרו את ה-Model Type (LLM למודלי צ'אט), הזינו את ה-id המדויק מהקטלוג ב-Model Name, הדביקו את המפתח שלכם ב-API Key, והגדירו API Base URL ל-https://api.apisrouter.com/v1. השאירו את Completion mode על Chat, ואז הגדירו את Model context size ו-Upper bound for max tokens למגבלות המתועדות של ה-id שאתם מוסיפים. שמרו, והמודל מופיע ברשימת הספק, ניתן לבחירה מכל תפריט מודלים באפליקציה. חזרו על הדיאלוג לכל id שאתם רוצים; שתי דקות למודל, פעם אחת.

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, כ-149K כוכבים) היא פלטפורמת אפליקציות ה-LLM הקוד-פתוח המובילה: workflows חזותיים, צמתי agent, צינורות RAG על בסיסי ידע, ואפליקציות מפורסמות עם ה-API endpoints משלהן. כל צומת LLM בערימה הזו נפתר למודל הרשום תחת ספק כלשהו. ספק ה-OpenAI-API-compatible גנרי במכוון. כל מודל שאתם מוסיפים הוא רשומה עצמאית, id, endpoint, מפתח, מגבלות, ו-Dify שולח בקשות chat-completions סטנדרטיות ל-base URL המוגדר עם Model Name שלכם כמחרוזת המודל. שום דבר בבקשה לא אכפת לו איזה ספק אימן את המודל, כך ש-claude-sonnet-4-6 ו-deepseek-v4-pro תקפים כאן בדיוק כמו כל id של GPT, ומודלים שונים יכולים אפילו להצביע על endpoints שונים אם אי-פעם תצטרכו את זה. הרישום לכל מודל שמרגיש כחיכוך הוא גם משטח הבקרה: ערכי גודל ההקשר ו-max-tokens שאתם מזינים הם מה שהתזמורת של Dify משתמשת בו כדי לתקצב prompts, לגזום היסטוריית שיחה, ולאמת הגדרות צמתים. הזינו מספרים אמיתיים מתיעוד המודל. הגזמה בהקשר מייצרת בקשות שה-endpoint דוחה; הפחתה גוזמת בשקט את ההקשר שצמתי ה-RAG שלכם עבדו כדי לאחזר.

השדות שעושים עבודה אמיתית.

Model Name הוא ערך ה-wire: הוא חייב להתאים לרשימת ה-/v1/models של ה-gateway תו-בתו, מכיוון שהוא נוסע בכל בקשה. שם התצוגה האופציונלי של המודל רק מתייג מחדש את ה-UI. Completion mode צריך להישאר על Chat עבור כל מודל בקטלוג הנוכחי; האפשרות Completion קיימת עבור endpoints מדור text-completion ישן ומייצרת בקשות פגומות מול מודלי צ'אט. Model context size ו-Upper bound for max tokens הם הזוג שאנשים ממהרים בו. גודל ההקשר הוא החלון הכולל של המודל; הגבול העליון מגביל כמה טוקני פלט צומת רשאי לבקש. Dify מגדיר ברירת מחדל לשניהם ל-4096, הרבה מתחת למה שמודלים נוכחיים תומכים בו, והשארת ברירות המחדל משתקת בשקט RAG על מסמכים ארוכים ויצירה ארוכת-טופס. הגדירו אותם מתיעוד המודל, לא מהרגל. בוררי היכולות משנים כשהאפליקציות שלכם משתמשות בהם: Vision Support רק עבור ids שמקבלים קלט תמונה, והגדרת ה-function-call כדי להתאים לתמיכת שימוש-בכלים של המודל, מכיוון שצמתי agent נשענים עליה. טענת יכולת שגויה נכשלת בזמן ריצה בתוך ה-workflow, מקום איטי יותר לדבג מהדיאלוג הזה. אם ה-workspace שלכם משתמש גם במודלי embedding או rerank, אותו ספק רושם אותם תחת רשומות Model Type משלהם מול אותו base URL; ודאו שה-ids הספציפיים מוגשים על ידי ה-endpoint לפני חיווט הגדרות בסיס-הידע אליהם.

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

בחירת מודלים ל-workflows ו-agents.

דפי הסקירה של Dify עצמם מציגים טוקנים לכל אפליקציה, אבל תצוגת השימוש לפי מפתח בקונסולת APIsRouter מוסיפה את הפיצול לפי מודל על פני כל האפליקציות באותו עמוד, וזה המספר שמחליט איזה id שומר על המקום.

• צמתי LLM ב-workflow הם נפח: סיווג, חילוץ, ניתוב, שלבי סיכום שיורים בכל הרצה. claude-haiku-4-5-20251001, gpt-5.4-mini, ו-gemini-3.5-flash שומרים על עלות-להרצה שטוחה.
• צמתי agent ושלבי נימוק מורכבים מרוויחים claude-sonnet-4-6, ושימוש הכלים האמין שלו חשוב יותר ב-agents מציוני benchmark גולמיים.
• צמתי תשובה של RAG נושאים הקשר מאוחזר בכל קריאה, אז תמחור הקלט שולט; deepseek-v4-pro שווה בדיקה היכן שהאחזור כבד והתשובות ארוכות.
• רשמו id מהיר ו-id חזק לאותו תפקיד ובצעו 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.

ספק חסר ברשימה אומר שה-plugin לא מותקן: מאז Dify 1.0 ספק ה-OpenAI-API-compatible מגיע כ-plugin של Marketplace, ומופעים self-hosted טריים מתחילים בלעדיו. התקינו אותו פעם אחת לכל workspace. מודל שנשמר אבל נכשל בשימוש ראשון הוא בדרך כלל אחד משלושה דברים: Model Name שלא תואם את האיות בקטלוג, base URL שחסר לו ה-/v1 (Dify מוסיף נתיבי route כמו /chat/completions למה שאתם מזינים), או ערכי הקשר/max-token מעבר למה שהמודל מקבל. השגיאה עולה בלוג האפליקציה או ה-workflow; התיקון חוזר לדיאלוג Add Model. צמתי agent שנכשלים בעוד צמתי צ'אט רגילים עובדים מצביעים על הגדרת יכולת ה-function-calling, או על מודל ששימוש הכלים שלו לא עומד במה שאסטרטגיית ה-agent מצפה. בדקו agents מול claude-sonnet-4-6 קודם כדי להפריד בעיות הגדרה מבחירת מודל. ובמופעים self-hosted מאחורי כללי egress קפדניים, זכרו שה-container של Dify api הוא זה שחייב להגיע ל-endpoint, לא הדפדפן שלכם; curl מתוך ה-container הזה מיישב שאלות קישוריות במהירות.

מי מנתב את Dify דרך gateway.

• צוותים שבונים אפליקציות LLM ורוצים ש-Claude, GPT, Gemini, ו-DeepSeek יהיו ניתנים לבחירה לכל צומת בלי לתחזק חשבון ספק לכל provider.
• self-hosters שמריצים Dify לכלים פנימיים, שם מפתח אחד בספק אחד שומר את כל ההוצאה בענן של ה-workspace על לוג שימוש בודד.
• בונים שמשווים מודלים על workflows אמיתיים: כל מועמד הוא דיאלוג Add Model והחלפת תפריט נפתח, לא אינטגרציה חדשה.
• מפתחים ללא גישה לחיוב של ספק נתון. גישה מבוססת-הטענה בלי דרישת כרטיס מסירה את התלות בהרשמה לכל ספק.
• סוכנויות שמשגרות אפליקציות לקוחות על Dify וזקוקות למפתחות לכל פרויקט כך שהוצאת המודל של כל לקוח מדווחת את עצמה.

אמתו את ה-endpoint ובצעו דיבוג להרצה הראשונה.

בצעו curl לרשימת המודלים קודם ורשמו ids מהפלט שלה; Model Names שהוקלדו ידנית הם הגורם המוביל לשגיאות not-found מכיוון שהשדה הוא טקסט חופשי. לאחר מכן הריצו השלמת צ'אט אחת מול ה-id שרשמתם, עם אותו מפתח. בתוך Dify, בדקו באפליקציית טיוטה לפני חיווט workflows של production: הוסיפו צומת LLM, בחרו את המודל החדש, הריצו פעם אחת. שגיאות אימות מצביעות על שדה ה-API Key; not-found על Model Name; שגיאות חיבור על ה-base URL או egress של ה-container; שגיאות אורך על ערכי ההקשר וה-max-token. ברגע שהרצות זורמות, קונסולת APIsRouter מציגה מודל לכל בקשה, ספירות טוקן, והוצאה. workflows מכפילים קריאות LLM בדרכים שקשה לאמוד בעין מהעורך, ולוג השימוש הוא המקום שבו פרופיל הטוקנים האמיתי של צינור בן חמישה צמתים הופך גלוי, לפי מודל, ליום.

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"}]}'

שאלות נפוצות