הריצו את Onyx על ספק LLM מותאם אישית תואם OpenAI.

תשובה מהירה: Add Custom LLM Provider בפאנל הניהול.

התיעוד של Onyx מפורש שספק מותאם אישית עובד כל עוד הוא חושף endpoints תואמי OpenAI, וצורת ה-Base URL לדוגמה שלו היא בדיוק בסגנון-gateway https://yourprovider.com/v1. הזרימה: פתחו את Admin Panel מסמל הפרופיל שלכם, עברו ל-Configuration, ואז Language Models, ובחרו Add Custom LLM Provider. ארבע החלטות חשובות בטופס הזה. Display Name הוא קוסמטי. Provider Name חייב להתאים למפתח ספק LiteLLM, מכיוון ש-Onyx מנתב קריאות מודל דרך LiteLLM מתחת למכסה; עבור gateway תואם OpenAI זה openai. Base URL הוא ה-endpoint של ה-gateway כולל הסיומת /v1. וסעיף Model Configurations הוא היכן שאתם רושמים כל model id שאתם רוצים זמין, מאוית בדיוק כפי שהקטלוג משרת אותו. שמרו, בחרו ברירת מחדל, וצ'אטים מנתבים דרך ה-gateway מיד.

Admin Panel -> Configuration -> Language Models
  -> Add Custom LLM Provider

Display Name:   APIsRouter
Provider Name:  openai            (LiteLLM provider key)
Base URL:       https://api.apisrouter.com/v1
API Key:        sk-YOUR-APISROUTER-KEY
Model Configurations:
  claude-sonnet-4-6
  claude-haiku-4-5-20251001
  deepseek-v4-pro

איפה ה-LLM יושב בארכיטקטורה של Onyx.

Onyx (onyx-dot-app ב-GitHub, כ-31K כוכבים, לשעבר Danswer) היא פלטפורמת AI קוד-פתוחה לידע חברה: היא מאנדקסת מקורות כמו Slack, Google Drive, Confluence, ועשרות מחברים אחרים, ואז עונה על שאלות מעליהם דרך UI צ'אט, עוזרים, ו-workflows של agent. זו אחת מערימות החיפוש הארגוני self-hosted הפרוסות ביותר, וזו בדיוק הסיבה שחשבון ה-LLM שלה ראוי להחלטת ניתוב ולא לברירת מחדל. הצינור מתפצל בבירור לשניים. אנדקסציה ואחזור, כולל הטמעת מסמכים ו-reranking, רצים על שרת המודל של Onyx עצמו עם מודלים מקומיים כברירת מחדל; שום דבר מזה לא נוגע בספק ה-LLM שלכם. יצירת תשובה היא המחצית השנייה: ברגע שאחזור מרכיב את הקטעים הרלוונטיים, LLM קורא אותם וכותב את התשובה המעוגנת, וקריאה זו הולכת דרך LiteLLM לספק שהמנהל הגדיר. זרימת הספק המותאם אישית מחליפה את היעד בדיוק של המחצית הזו. מכיוון ש-LiteLLM מעביר את ה-model id כמחרוזת פשוטה לספק מסוג openai, ה-ids שאתם רושמים ב-Model Configurations יכולים להיות כל דבר שה-endpoint מאחורי ה-Base URL משרת: Claude לתשובות מעוגנות זהירות, DeepSeek לנפח, Gemini להקשרי מקור ארוכים מאוד. עוזרים שונים יכולים לבחור מודלים שונים כברירת מחדל, כך שעוזר תמיכה ועוזר הנדסה יכולים לרכוב על נקודות מחיר שונות דרך אותה רשומת ספק.

הגדרה מלאה, ומה שנשאר בלי לגעת.

טופס הספק הוא כל האינטגרציה; אין קובץ הגדרה לערוך או container לבנות מחדש עבורו. אחרי השמירה, הגדירו את מודל ברירת המחדל ל-workspace, ואופציונלית דרסו את המודל לכל עוזר היכן שאתם רוצים רמות איכות שונות. מה שנשאר במכוון בלי לגעת: מחברים שומרים על האישורים שלהם, האינדקס לא מושפע, ומודל ה-embedding המוגדר לחיפוש לא זז. הפרדה זו שווה לפרט מכיוון שהיא הופכת את זה לשינוי בסיכון נמוך. אם ה-gateway היה מתנהג לא כשורה, חיפוש ומקורות עדיין היו עובדים; רק יצירת תשובות הייתה נכשלת, והחלפת ברירת המחדל בחזרה לספק קודם היא תפריט נפתח אחד. לצוותים שמאוטמים פריסות, אותה הגדרת ספק יכולה להיזרע דרך ה-API של Onyx במקום להיקלק דרך ה-UI, אבל נתיב פאנל הניהול הוא המשטח המתועד והיציב, והגדרה חד-פעמית לעיתים רחוקות מצדיקה יותר.

# confirm the gateway lists the ids you plan to register
curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

# confirm a chat completion works end to end
curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-4-6",
       "messages":[{"role":"user","content":"ping"}]}'

בחירת מודלים לתשובות ארגוניות מעוגנות.

הערכת מודלים בתוך Onyx קונקרטית באופן חריג: שאלו את אותה שאלה מול אותם מחברים עם שתי ברירות מחדל עוזר שונות והשוו איזו תשובה מצטטת את הקטעים הנכונים. לוג השימוש לפי מפתח מתמחר את שני המועמדים על תמהיל השאלות האמיתי שלכם.

• מענה מעוגן עתיר-קלט: המודל קורא קטעים מאוחזרים שמגמדים את התשובה שהוא כותב. מחיר לטוקן-קלט לכן קובע את העלות שלכם לשאלה יותר ממחיר הפלט.
• claude-sonnet-4-6 הוא ברירת מחדל חזקה ל-workspace: ממושמע להישאר בתוך המקורות המאוחזרים ועמיד בפני המצאת מדיניות שלא נמצאת במסמכים.
• עוזרים בתעבורה גבוהה (helpdesk IT, שאלות נפוצות HR) רצים היטב על claude-haiku-4-5-20251001 או deepseek-v4-pro, שם תמחור נפח שומר על עלות-למשתמש צפויה.
• מסמכי מקור ארוכים מעדיפים ids בהקשר-ארוך; gemini-3.1-pro-preview שווה בדיקה עבור עוזרים ששואבים מסמכי עיצוב גדולים או חוזים להקשר.
• רשמו כמה ids ברשומת ספק אחת והקצו אותם לכל עוזר. רמות איכות לכל צוות מנצחות מודל פשרה גלובלי אחד.

תשלום לפי שימוש · מתחת למחיר הרשמי

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

מצבי כשל ספציפיים ל-Onyx.

Provider Name אינה תווית טקסט חופשי. היא חייבת להתאים למפתח ספק LiteLLM, ועבור gateway המפתח הזה הוא openai. שם מומצא נכשל בזמן הבקשה עם שגיאת ספק LiteLLM גם אם הטופס נשמר בסדר. ה-Base URL רוצה את הסיומת /v1. התיעוד של Onyx עצמו מציג צורות endpoint שמסתיימות ב-/v1; בלעדיה, נתיב ה-chat-completions נפתר לא נכון ובקשות 404 ב-gateway. model ids חיים ב-Model Configurations. מודל שמעולם לא נרשם שם לא יכול להיבחר כברירת מחדל, וטעות הקלדה ב-id רשום עולה כשגיאת model-not-found בשימוש ראשון, לא בזמן השמירה. רשימת ה-/v1/models של ה-gateway היא האיות הסמכותי. אם ה-admin UI שלכם חסר את שדה ה-Base URL בטופס המודלים-המותאמים-אישית, נתקלתם ברגרסיית UI מדווחת בכמה שחרורים של 2026 ולא בפיצ'ר חסר; שדרוג משחזר את השדה. וזכרו איזו מחצית הזזתם: אם תוצאות חיפוש נראות שגויות או מיושנות, זו אנדקסציה ומחברים, שאף פעם לא נוגעים בספק המותאם אישית. רק תשובות שנוצרות מנותבות דרך ה-gateway.

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

• צוותים self-hosted שמחליפים חשבונות לכל ספק ב-endpoint אחד, מפתח אחד, ושימוש לפי מפתח שממופה בבירור ל-workspace או מחלקה.
• ארגונים שהתקנו את Onyx כתקן לחיפוש פנימי ורוצים תשובות מעוגנות באיכות Claude בלי יחסי חיוב נפרדים עם Anthropic.
• צוותי פלטפורמה שמריצים כמה עוזרים ברמות איכות שונות, מתומחרים לכל עוזר דרך model ids רשומים על ספק אחד.
• מעריכים שמשווים איכות תשובה בין משפחות מודלים על corpora זהים, שם כל מועמד הוא id רשום ולא אינטגרציית ספק חדשה.
• מפתחים ללא גישה לחיוב של ספק נתון. גישה מבוססת-הטענה בלי דרישת כרטיס מסירה את התלות בהרשמה לכל ספק.

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

שתי בדיקות ה-curl למעלה מכסות את מחצית ה-gateway לפני שאתם נוגעים בטופס: ה-ids שאתם מתכננים לרשום חייבים להופיע ב-/v1/models, והשלמת צ'אט ישירה צריכה לענות. בתוך Onyx, כשלים ממוקמים במהירות. שגיאת ספק שמזכירה LiteLLM אומרת ש-Provider Name אינו מפתח תקף; הגדירו אותו ל-openai. שגיאת אימות בצ'אט הראשון אומרת ש-API Key לא שייך ל-endpoint ב-Base URL. שגיאת model-not-found היא חוסר-התאמה בין Model Configurations לקטלוג. תשובות שנוצרות אבל מתעלמות מהמסמכים שלכם הן בעיית אחזור או מחבר, מעל ספק ה-LLM לגמרי. ברגע שהצ'אטים זורמים, קונסולת APIsRouter מציגה מודל לכל בקשה, ספירות טוקן, והוצאה. עבור כלי workspace שבו כל שאלה נושאת הקשר מאוחזר, מספר הטוקנים-לשאלה הזה הוא הבסיס הכן לתכנון קיבולת, ומפתח אחד לכל workspace הופך את לוג השימוש לדוח עלות ברמת מחלקה.

שאלות נפוצות