Uruchom Onyx na niestandardowym dostawcy LLM kompatybilnym z OpenAI.

Szybka odpowiedź: Add Custom LLM Provider w panelu administracyjnym.

Dokumentacja Onyx wprost mówi, że niestandardowy dostawca działa, dopóki eksponuje endpointy kompatybilne z OpenAI, a jej przykładowy kształt Base URL to dokładnie styl bramki https://yourprovider.com/v1. Przepływ: otwórz Admin Panel z ikony profilu, przejdź do Configuration, potem Language Models, i wybierz Add Custom LLM Provider. W tym formularzu liczą się cztery decyzje. Display Name jest kosmetyczne. Provider Name musi zgadzać się z kluczem dostawcy LiteLLM, ponieważ Onyx kieruje wywołania modeli przez LiteLLM pod spodem; dla bramki kompatybilnej z OpenAI to openai. Base URL to endpoint bramki, łącznie z sufiksem /v1. A sekcja Model Configurations to miejsce, gdzie rejestrujesz każdy identyfikator modelu, który chcesz mieć dostępny, zapisany dokładnie tak, jak obsługuje go katalog. Zapisz, wybierz domyślny i czaty od razu kierują ruch przez bramkę.

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

Gdzie LLM siedzi w architekturze Onyx.

Onyx (onyx-dot-app na GitHubie, około 31 tys. gwiazdek, dawniej Danswer) to open-source'owa platforma AI dla wiedzy firmowej: indeksuje źródła, takie jak Slack, Google Drive, Confluence i dziesiątki innych konektorów, potem odpowiada na pytania na ich temat przez UI czatu, asystentów i workflow agentów. To jeden z najczęściej wdrażanych self-hostowanych stosów wyszukiwania enterprise, dlatego dokładnie jego rachunek za LLM zasługuje na decyzję routingową, a nie domyślną. Pipeline dzieli się czysto na dwie części. Indeksowanie i retrieval, łącznie z embedowaniem dokumentów i rerankiem, działają na własnym serwerze modeli Onyx z lokalnymi modelami domyślnie; nic z tego nie dotyka Twojego dostawcy LLM. Generowanie odpowiedzi to druga połowa: gdy retrieval złoży odpowiednie fragmenty, LLM je czyta i pisze uziemioną odpowiedź, a to wywołanie idzie przez LiteLLM do dowolnego dostawcy skonfigurowanego przez administratora. Przepływ niestandardowego dostawcy zamienia cel dokładnie tej połowy. Ponieważ LiteLLM przekazuje identyfikator modelu jako zwykły string do dostawcy typu openai, identyfikatory, które rejestrujesz w Model Configurations, mogą być dowolne, obsługiwane przez endpoint za Base URL: Claude do starannych uziemionych odpowiedzi, DeepSeek do wolumenu, Gemini do bardzo długich kontekstów źródłowych. Różni asystenci mogą domyślnie używać różnych modeli, więc asystent wsparcia i asystent inżynieryjny mogą jeździć na różnych punktach cenowych przez ten sam wpis dostawcy.

Pełna konfiguracja i co pozostaje nietknięte.

Formularz dostawcy to cała integracja; nie ma pliku konfiguracji do edycji ani kontenera do przebudowania. Po zapisaniu ustaw domyślny model dla workspace i opcjonalnie nadpisz model per asystent tam, gdzie chcesz różnych poziomów jakości. Co celowo pozostaje nietknięte: konektory zachowują własne poświadczenia, indeks pozostaje niedotknięty, a model embeddingu skonfigurowany do wyszukiwania się nie rusza. Ten podział warto wyartykułować, ponieważ czyni to zmianą niskiego ryzyka. Gdyby bramka zachowała się źle, wyszukiwanie i źródła nadal by działały; zawodziłoby tylko generowanie odpowiedzi, a przełączenie domyślnego z powrotem na poprzedniego dostawcę to jedna rozwijana lista. Dla zespołów automatyzujących wdrożenia tę samą definicję dostawcy można zaseedować przez API Onyx zamiast klikać przez UI, ale ścieżka panelu administracyjnego to udokumentowana i stabilna powierzchnia, a jednorazowa konfiguracja rzadko uzasadnia więcej.

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

Dobór modeli do uziemionych odpowiedzi enterprise.

Ewaluacja modeli wewnątrz Onyx jest niezwykle konkretna: zadaj to samo pytanie tym samym konektorom z dwoma różnymi domyślnymi asystentami i porównaj, która odpowiedź cytuje właściwe fragmenty. Log użycia per klucz wycenia obu kandydatów na Twoim rzeczywistym miksie pytań.

• Uziemione odpowiadanie jest input-heavy: model czyta pobrane fragmenty, które przyćmiewają odpowiedź, którą pisze. Cena per token wejściowy ustala więc Twój koszt per pytanie bardziej niż cena wyjścia.
• claude-sonnet-4-6 to silny domyślny wybór dla workspace: zdyscyplinowany co do pozostawania wewnątrz pobranych źródeł i odporny na wymyślanie polityki, której nie ma w dokumentach.
• Asystenci wysokiego ruchu (helpdesk IT, FAQ HR) dobrze działają na claude-haiku-4-5-20251001 albo deepseek-v4-pro, gdzie ceny wolumenowe utrzymują koszt per stanowisko przewidywalny.
• Długie dokumenty źródłowe faworyzują identyfikatory o długim kontekście; warto przetestować gemini-3.1-pro-preview dla asystentów, którzy wciągają do kontekstu duże dokumenty projektowe albo umowy.
• Zarejestruj kilka identyfikatorów w jednym wpisie dostawcy i przypisz je per asystent. Poziomy jakości per zespół biją jeden globalny model kompromisowy.

Płatność za użycie · poniżej cen oficjalnych

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

Tryby awarii charakterystyczne dla Onyx.

Provider Name to nie dowolna etykieta tekstowa. Musi zgadzać się z kluczem dostawcy LiteLLM, a dla bramki tym kluczem jest openai. Wymyślona nazwa zawodzi w momencie żądania błędem dostawcy LiteLLM, mimo że formularz zapisał się bez problemu. Base URL chce sufiksu /v1. Własna dokumentacja Onyx pokazuje kształty endpointów kończące się na /v1; bez niego ścieżka chat-completions rozwiązuje się źle, a żądania dają 404 na bramce. Identyfikatory modeli żyją w Model Configurations. Model, którego tam nigdy nie zarejestrowałeś, nie może zostać wybrany jako domyślny, a literówka w zarejestrowanym identyfikatorze ujawnia się jako błąd model-not-found przy pierwszym użyciu, nie w momencie zapisu. Listing /v1/models bramki jest autorytatywnym zapisem. Jeśli w Twoim UI administracyjnym brakuje pola Base URL na formularzu custom-models, trafiłeś na zgłoszoną regresję UI w niektórych wydaniach 2026, a nie brakującą funkcję; upgrade przywraca to pole. I pamiętaj, którą połowę przeniosłeś: jeśli wyniki wyszukiwania wyglądają źle albo nieaktualnie, to indeksowanie i konektory, które nigdy nie dotykają niestandardowego dostawcy. Przez bramkę kierowane są tylko wygenerowane odpowiedzi.

Kto kieruje Onyx przez bramkę.

• Self-hostowane zespoły zastępujące konta per dostawca jednym endpointem, jednym kluczem i użyciem per klucz, które czysto mapuje się na workspace albo dział.
• Przedsiębiorstwa, które zestandaryzowały się na Onyx do wewnętrznego wyszukiwania i chcą uziemionych odpowiedzi jakości Claude bez osobnej relacji rozliczeniowej z Anthropic.
• Zespoły platformowe prowadzące kilku asystentów na różnych poziomach jakości, wycenianych per asystent przez zarejestrowane identyfikatory modeli u jednego dostawcy.
• Ewaluatorzy porównujący jakość odpowiedzi między rodzinami modeli na identycznych korpusach, gdzie każdy kandydat to zarejestrowany identyfikator, a nie nowa integracja dostawcy.
• Deweloperzy bez dostępu do rozliczeń danego dostawcy. Dostęp oparty na doładowaniu, bez wymogu karty, usuwa zależność od rejestracji u każdego dostawcy z osobna.

Zweryfikuj endpoint i debuguj pierwszy czat.

Dwie powyższe kontrole curlem pokrywają połowę dotyczącą bramki, zanim dotkniesz formularza: identyfikatory, które planujesz zarejestrować, muszą pojawić się w /v1/models, a bezpośrednie chat completion powinno odpowiedzieć. Wewnątrz Onyx awarie lokalizują się szybko. Błąd dostawcy wymieniający LiteLLM oznacza, że Provider Name nie jest ważnym kluczem; ustaw go na openai. Błąd uwierzytelniania przy pierwszym czacie oznacza, że API Key nie należy do endpointu w Base URL. Błąd model-not-found to niezgodność identyfikatora między Model Configurations a katalogiem. Odpowiedzi, które się generują, ale ignorują Twoje dokumenty, to problem retrievalu albo konektora, całkowicie wyżej w łańcuchu niż dostawca LLM. Gdy czaty już płyną, konsola APIsRouter pokazuje model per żądanie, liczbę tokenów i wydatki. Dla narzędzia workspace, gdzie każde pytanie niesie pobrany kontekst, ta liczba tokenów per pytanie to uczciwa podstawa planowania pojemności, a jeden klucz per workspace zamienia log użycia w raport kosztów na poziomie działu.

Częste pytania