Onyx を、カスタムの OpenAI 互換 LLM プロバイダーで動かす。

早わかり: 管理パネルで Add Custom LLM Provider。

Onyx のドキュメントは、カスタムプロバイダーが OpenAI 互換のエンドポイントを公開している限り機能すると明記しており、その例に挙がる Base URL の形は、まさにゲートウェイ風の https://yourprovider.com/v1 です。フローはこうです。プロフィールアイコンから Admin Panel を開き、Configuration に進み、Language Models、そして Add Custom LLM Provider を選びます。 そのフォームでは、4つの決定が重要になります。Display Name は見た目だけの問題です。Provider Name は LiteLLM のプロバイダーキーと一致していなければなりません。Onyx は裏側でモデル呼び出しを LiteLLM 経由でルーティングしているからです。OpenAI 互換のゲートウェイの場合、それは openai です。Base URL は、/v1 サフィックスを含むゲートウェイのエンドポイントです。そして Model Configurations セクションが、利用可能にしたい各モデル id を、カタログが提供するとおりの綴りで登録する場所です。保存し、デフォルトを選べば、チャットはすぐにゲートウェイ経由でルーティングされます。

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

Onyx のアーキテクチャの中で、LLM がどこに位置するか。

Onyx(GitHub 上では onyx-dot-app、スター数はおよそ31K、旧 Danswer)は、企業の知識のためのオープンソース AI プラットフォームです。Slack・Google Drive・Confluence など数十のコネクタからソースをインデックス化し、チャット UI・アシスタント・エージェントワークフローを通じてそれらについての質問に答えます。最も多くデプロイされているセルフホスト型のエンタープライズ検索スタックの1つであり、だからこそ、その LLM の請求は、デフォルトのままにするのではなくルーティングの決定に値するのです。 パイプラインはきれいに2つに分かれています。インデックス作成と検索(ドキュメントのエンベディングとリランクを含む)は、Onyx 自身のモデルサーバー上で、デフォルトではローカルモデルで動作し、そのどれもあなたの LLM プロバイダーには触れません。回答生成はもう半分です。検索が関連する文章を組み立てたら、LLM がそれらを読んでグラウンデッドな応答を書き、その呼び出しは LiteLLM を経由して、管理者が設定したプロバイダーに向かいます。カスタムプロバイダーのフローが差し替えるのは、まさにこの半分の行き先です。 LiteLLM はモデル id を、openai タイプのプロバイダーに対してプレーンな文字列として転送するため、Model Configurations に登録する id は、Base URL の背後にあるエンドポイントが提供するものなら何でも構いません。丁寧なグラウンデッドの回答には Claude、ボリュームには DeepSeek、非常に長いソース文脈には Gemini、といった具合です。アシスタントごとに異なるモデルをデフォルトにできるため、サポートアシスタントとエンジニアリングアシスタントが、同じプロバイダーのエントリを通じて異なる価格帯に乗ることができます。

フルセットアップと、触れずに残るもの。

プロバイダーのフォームが統合のすべてです。編集すべき設定ファイルも、再構築すべきコンテナもありません。保存後、ワークスペースのデフォルトモデルを設定し、異なる品質ティアを求める場合は、任意でアシスタントごとにモデルを上書きしてください。 意図的に触れずに残るものはこうです。コネクタは自身の認証情報を保ち、インデックスは影響を受けず、検索用に設定されたエンベディングモデルも動きません。この分離を明記する価値があるのは、それがこの変更を低リスクなものにするからです。もしゲートウェイがおかしな挙動をしても、検索とソースは動き続け、エラーになるのは回答生成だけであり、デフォルトを以前のプロバイダーに戻すのはドロップダウン1つで済みます。 デプロイを自動化するチーム向けには、同じプロバイダーの定義を、UI でクリックする代わりに Onyx の API を通じてシードすることもできますが、管理パネルの経路がドキュメント記載済みで安定した面であり、一度きりのセットアップに、それ以上は滅多に必要ありません。

# 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 の中でのモデル評価は、格別に具体的です。同じコネクタに対して同じ質問を、2つの異なるアシスタントのデフォルトで尋ね、どちらの回答が正しい文章を引用しているか比較してください。キーごとの利用ログが、あなたの実際の質問構成に基づいて、両方の候補に価格をつけてくれます。

• グラウンデッドな回答は入力量の多い作業です。モデルは、自身が書く回答をはるかに上回る、検索された文章を読みます。したがって、入力トークンあたりの価格の方が、出力価格よりも質問あたりのコストを左右します。
• claude-sonnet-4-6 は、強力なワークスペースのデフォルトです。検索されたソースの範囲内にとどまることに規律があり、ドキュメントにないポリシーをでっち上げにくいという特性があります。
• トラフィックの多いアシスタント(IT ヘルプデスク、人事 FAQ)は、claude-haiku-4-5-20251001 や deepseek-v4-pro でよく機能し、ボリューム価格が座席あたりのコストを予測可能に保ちます。
• 長いソースドキュメントには、長文脈対応の id が有利です。大きな設計ドキュメントや契約書を文脈に取り込むアシスタントには、gemini-3.1-pro-preview を試す価値があります。
• 1つのプロバイダーのエントリに複数の id を登録し、アシスタントごとに割り当ててください。チームごとの品質ティアの方が、1つのグローバルな妥協モデルよりも優れています。

従量課金 · 公式価格より安い

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 のプロバイダーキーと一致していなければならず、ゲートウェイの場合そのキーは openai です。適当に作った名前は、フォームは問題なく保存されても、リクエスト時に LiteLLM のプロバイダーエラーで失敗します。 Base URL には /v1 サフィックスが必要です。Onyx 自身のドキュメントは、/v1 で終わるエンドポイントの形を示しています。それがないと、チャット補完のパスが正しく解決されず、リクエストはゲートウェイで 404 になります。 モデル id は Model Configurations の中にあります。そこに一度も登録していないモデルは、デフォルトとして選択できず、登録した id のタイプミスは、保存時ではなく初回使用時に model-not-found エラーとして表面化します。ゲートウェイの /v1/models の一覧が正しい綴りの拠り所です。 管理 UI のカスタムモデルフォームに Base URL フィールドが見当たらない場合、それは機能の欠落ではなく、2026年の一部リリースで報告されている UI の退行に当たったということです。アップグレードすればそのフィールドは戻ります。そして、自分がどちらの半分を動かしたかを忘れないでください。検索結果がおかしい、あるいは古く見える場合、それはインデックス作成とコネクタの問題であり、カスタムプロバイダーには一切触れていません。ゲートウェイ経由になるのは、生成された回答だけです。

ゲートウェイ経由で Onyx を使うのは誰か。

• ベンダーごとのアカウントを、1つのエンドポイント、1つのキー、ワークスペースや部門にきれいに対応するキーごとの利用状況に置き換える、セルフホストのチーム。
• 社内検索に Onyx を標準採用し、別途 Anthropic との請求関係を持つことなく Claude 級のグラウンデッドな回答を求めるエンタープライズ。
• 異なる品質ティアで複数のアシスタントを運用するプラットフォームチームで、1つのプロバイダー上の登録済みモデル id を通じて、アシスタントごとに価格を設定する人。
• 同一のコーパスに対してモデルファミリー横断で回答品質を比較する評価者で、各候補が新しいプロバイダー統合ではなく登録済みの id で済む人。
• 特定ベンダーの請求手段にアクセスできない開発者。チャージ制でカード不要のアクセスなら、プロバイダーごとのサインアップという依存を取り除けます。

エンドポイントを検証し、最初のチャットをデバッグする。

フォームに触れる前に、上記の2つの curl チェックがゲートウェイ側をカバーします。登録する予定の id は /v1/models に現れなければならず、直接のチャット補完は応答するはずです。 Onyx の中では、失敗は素早く切り分けられます。LiteLLM の名前を挙げるプロバイダーエラーは、Provider Name が有効なキーではないということです。openai に設定してください。最初のチャットでの認証エラーは、API Key が Base URL のエンドポイントに属していないということです。Model-not-found エラーは、Model Configurations とカタログの間の id の不一致です。回答は生成されるもののドキュメントを無視する場合、それは検索かコネクタの問題であり、LLM プロバイダーよりも上流の話です。 チャットが流れ始めたら、APIsRouter コンソールがリクエストごとのモデル、トークン数、支出を表示します。すべての質問が検索された文脈を伴うワークスペースツールにとって、その質問あたりのトークン数こそが、容量計画の正直な基礎であり、ワークスペースごとにキーを1つにすれば、利用ログは部門レベルのコストレポートになります。

よくある質問