高度な設定

推論サーバー（vLLM）の挙動を .env で細かく調整するための設定です。標準の利用では不要ですが、ツール呼び出し・思考表示・マルチ GPU などを使う場合に設定します。変更後はサーバーを再起動してください。

対象:管理者必要権限:管理者ロールエディション:vLLM

ツール（function calling）を有効化

vLLM 版は tool parser を自動注入しないため、VLLM_EXTRA_ARGS_CHAT で明示します。parser 名はモデルごとに異なるので、モデルカードの vLLM 起動例に従ってください。

# 例: Qwen3.5 系
VLLM_EXTRA_ARGS_CHAT=--enable-auto-tool-choice --tool-call-parser qwen3_coder
# 例: Qwen3 / Qwen2.5 系は hermes
# VLLM_EXTRA_ARGS_CHAT=--enable-auto-tool-choice --tool-call-parser hermes

思考（reasoning）を分離表示

思考対応モデルで <think> … </think> を本文から分離し、最終回答だけを表示するには reasoning parser を設定します（Qwen3 / Qwen3.5 系は qwen3）。未設定だとタグが本文に生のまま出ます。

VLLM_REASONING_PARSER=qwen3

複数 GPU で 1 モデルを動かす（tensor parallel）

1 枚の GPU に載らない大きいモデルは、VLLM_TENSOR_PARALLEL に枚数を指定して全 GPU で分割します（既定 1 = GPU0 のみ）。

VLLM_TENSOR_PARALLEL=4    # 例: 4枚で分割

補足

NVLink の無い環境でも、A3B などの軽量 MoE は PCIe で問題なく分割できます。1 枚に載るモデルを純粋に台数ぶん速くしたい場合は、GPU ごとに vLLM を分けて下記「エンドポイントプール」で束ねる構成も選べます。

複数の推論サーバーをまとめて使う（エンドポイントプール）

GPU ごと、あるいは別マシンに立てた複数の vLLM サーバーを、用途（chat / embed / vision）ごとに 1 つのプールとして束ねられます。NVLink の無い環境で GPU 1 枚ごとに vLLM を分けて立てた場合や、既存の GPU サーバーを追加でつなぐ場合に使います。

接続先を設定する

.env に、用途ごとの接続先 URL をカンマ区切りで指定します。

VLLM_CHAT_ENDPOINTS=http://10.0.0.5:8001,http://10.0.0.6:8001
VLLM_EMBED_ENDPOINTS=http://10.0.0.7:8002
VLLM_VISION_ENDPOINTS=http://10.0.0.9:8003

未設定の用途は、従来どおり単一の VLLM_BASE_URL 等を使います（後方互換）。設定を反映するにはサーバーを再起動します。

管理画面での見え方

モデル管理に、用途ごとのプールとして各接続先が一覧表示されます。接続先ごとに次を確認できます。

状態・実モデル名 — 各サーバーに問い合わせて、稼働状態と実際に提供中のモデルを表示します。
負荷 — 処理中・待ち件数、KV キャッシュ使用率、スループット、応答時間（TTFT など）。
GPU（温度・電力） — 接続先で DCGM exporter（既定ポート 9400、DCGM_PORT で変更可）が動作している場合に表示します。取得できない場合は「—」と表示します。
操作の可否 — 本機で起動した接続先は起動 / 停止を行えます。外部接続（external）は監視のみで、操作はできません。

補足

取得はページを開いたときと [更新] を押したときだけ行います（自動更新はしません）。多数の接続先を常時監視して負荷をかけることを避けるためです。

モデルの選択と振り分け

接続したすべての接続先のモデルが、チャットのモデル一覧にまとめて表示されます。

接続先ごとに異なるモデル を提供している場合は、チャットで選んだモデルを提供する接続先へ自動的に振り分けます。
同じモデルを複数の接続先 で提供している場合は、それらへ順番に振り分けます（ラウンドロビン）。

接続に失敗した接続先は一定時間、自動的に振り分け対象から外れ、復帰すると再び使われます。

補足

NVLink がある複数 GPU は、1 つの vLLM をテンソル並列で動かすため、外部からは 1 つの接続先として扱われます（プールには 1 件として並びます）。

OpenAI 互換の推論サーバーにつなぐ（vLLM 以外）

接続先は vLLM に限りません。OpenAI 互換の /v1/chat/completions（および必要に応じて /v1/embeddings）を提供するサーバーであれば、同じ仕組みでつなげます。既存の GPU サーバーや、他の推論基盤（例: LM Studio、Microsoft Foundry Local など）を DigitalBase のバックエンドにできます。

.env を次のように設定します。

LLM_BACKEND=vllm
VLLM_BASE_URL=http://<接続先ホスト>:<ポート>   # OpenAI 互換エンドポイント
VLLM_AUTO_START=false                          # 本機で推論サーバーを起動しない（外部で管理）
VLLM_CHAT_MODEL=<接続先が提供するモデル名>
VLLM_EMBED_MODEL=<埋め込み用モデル名>           # 埋め込みが別サーバーなら VLLM_EMBED_ENDPOINTS で指定
VLLM_API_KEY=<必要な場合のみ>                    # 接続先が Bearer 認証を要求する場合

LLM_BACKEND=vllm は「OpenAI 互換サーバーへ接続するモード」を指します（接続先が vLLM 本体である必要はありません）。
VLLM_AUTO_START=false にすると、本機では推論サーバーを起動せず、指定した URL を外部接続として使います。
認証が必要なら VLLM_API_KEY を設定します（未設定なら認証ヘッダーを付けません）。
用途ごとに別サーバーへ振り分けたい場合は、上記のエンドポイントプール（VLLM_CHAT_ENDPOINTS など）に OpenAI 互換 URL を並べても同様に動きます。

注意

チャットと埋め込みの基本動作は OpenAI 互換であればそのまま利用できます。一方で、ツール呼び出し（Function Calling）や思考（reasoning）の詳細な挙動は接続先の実装に依存するため、エージェント機能を使う場合は接続先がこれらに対応しているかを事前にご確認ください。クラウドの商用モデル（OpenAI / Anthropic / Gemini / xAI）を使う場合は、この設定ではなくクラウド LLM の API キー設定をご利用ください。

検索リランカー（reranker）で RAG の精度を上げる

ナレッジ（RAG）検索は、類似検索（＋キーワード併用）で候補を広めに集めたあと、リランカー（cross-encoder）が候補を再採点して上位を選び直す 2 段構成に対応しています。文書数が多い環境（数千ファイル以上）では、参照元の上位精度が向上します。

リランカーは chat / embed とは別の推論サーバーとして起動します。既定モデル BAAI/bge-reranker-v2-m3（多言語、約 0.6B）は VRAM 消費が小さく、既存 GPU の空きに同居できます。

リランカーサーバーを起動します（ポートは例。必要な起動フラグはモデルカードを確認してください）。

vllm serve BAAI/bge-reranker-v2-m3 --port 8082 --gpu-memory-utilization 0.10

起動すると /v1/rerank エンドポイント（Cohere / Jina 互換）が提供されます。

.env に 2 つの変数を設定し、API サーバーを再起動します。

RERANK_ENABLED=true
VLLM_RERANK_BASE_URL=http://localhost:8082

ナレッジを選択してチャットで質問し、参照元が返ることを確認します。以降の検索は自動で 2 段構成になります。

設定	用途
`RERANK_TOP_N`	再採点にかける候補数（既定 30。増やすと精度寄り・遅延増）
`RERANK_TIMEOUT`	リランカー呼び出しのタイムアウト秒（既定 30）

補足

リランカーが停止・タイムアウトしても検索は止まりません。自動的に従来の順序（ハイブリッド検索順）に戻ります。無効化は RERANK_ENABLED=false にするか VLLM_RERANK_BASE_URL を空にするだけです。

GPU メモリ・文脈長の調整

設定	用途
`VLLM_GPU_MEMORY_UTILIZATION_CHAT` / `_EMBED`	サーバーごとの GPU メモリ割当（同一 GPU に複数サーバーを載せる時に調整）
`VLLM_MAX_MODEL_LEN`	最大文脈長（長いほど KV キャッシュを消費。OOM 時は下げる）
`VLLM_EXTRA_ARGS_CHAT` / `_EMBED` / `_VISION`	`vllm serve` への追加引数（`--quantization`、`--enforce-eager` 等）

注意

量子化モデルは追加フラグが要ることがあります（例: 一部の GPTQ MoE は --quantization moe_wna16）。必要な引数はモデルカードを確認し、VLLM_EXTRA_ARGS_CHAT に追記してください。

大規模運用（データ量・同時利用が増えたとき）

利用が増えて動作が重くなったり、上限に当たったりした場合は、症状に応じて次の環境変数を引き上げます。すべて環境変数の編集画面から変更でき、変更後はサーバーを再起動してください。標準値のままでも通常規模では問題ありません。

症状	上げる設定	標準値
SQL テーブル閲覧が途中で切れる	`SQL_TABLE_MAX_ROWS`	1000 行
複数人が同時に SQL を使うと待たされる / 失敗する	`SQL_POOL_SIZE` / `SQL_POOL_MAX_OVERFLOW`	2 / 3
大きなクエリがタイムアウトする	`SQL_STATEMENT_TIMEOUT_MS`	30000 (30秒)
ページ全体の動作がもたつく（多人数アクセス）	`DB_POOL_SIZE` / `DB_POOL_MAX_OVERFLOW`	10 / 20
RAG 取込で PDF が途中ページで切れる	`RAG_MAX_PAGES`	200 ページ
ワークフローの CSV 取込が途中で切れる	`TOOL_CSV_MAX_ROWS`	100000 行
API ゲートウェイのクエリ結果が切れる	`GATEWAY_QUERY_MAX_ROWS`	10000 行

注意

SQL_POOL_SIZE を上げるときは、同時に接続する DB の最大接続数に注意してください。実際に使われる接続数は「接続キャッシュ数（SQL_ENGINE_CACHE_MAX、標準 20）×（SQL_POOL_SIZE + SQL_POOL_MAX_OVERFLOW）」まで増えます。接続先 PostgreSQL の max_connections を超えない範囲で調整してください。

ログ・使用量データの保持期限

システムログ・監査ログ・API 使用量は自動で記録され続けます。表示画面はありませんが、放置すると DB のディスクを消費し続けるため、既定で古いデータを毎日自動削除します。ディスクが逼迫している場合は日数を短く、長く残したい場合は日数を長く設定してください。

設定	対象	標準値
`LOG_RETENTION_DAYS`	システムログ（警告以上）	30 日
`AUDIT_RETENTION_DAYS`	監査ログ（操作履歴）	365 日
`USAGE_RETENTION_DAYS`	API 使用量の明細	90 日
`RETENTION_SWEEP_HOUR`	自動削除を実行する時刻	3 時

いずれも 0 を設定すると無期限（自動削除しない）になります。

補足

監査ログは削除前に JSONL ファイル（AUDIT_ARCHIVE_DIR、標準 ~/.local/db/audit-archive/）へ退避してから DB を軽くします。コンプライアンス上の記録は失われません。監査ログを DB から一切消したくない場合は AUDIT_RETENTION_DAYS=0 にしてください。