高度な設定

推論サーバー（vLLM）の .env 詳細設定。標準利用では不要。変更後はサーバーを再起動する。

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

ツール（function calling）を有効化

VLLM_TOOL_CALL_PARSER の既定は空で、推論サーバーに parser を渡さない。空のままだと、本機で起動した推論サーバーではツールを使う依頼がエラーになる。Linux のインストーラは、入れる Qwen3 系に合う hermes を .env に書く。モデルを替えた時は VLLM_TOOL_CALL_PARSER をモデルカードの vLLM 起動例に従って変える。

Qwen3.5 / Qwen3.6 系の例。

VLLM_TOOL_CALL_PARSER=qwen3_coder

Qwen3 / Qwen2.5 系は VLLM_TOOL_CALL_PARSER=hermes（インストーラが書く値）。

--enable-auto-tool-choice は自動で付く。

モデルカードの vllm serve コマンドは、対応する .env の設定に変換できる。管理画面 > 環境変数 の「vLLM設定」に貼る。

思考（reasoning）を分離表示

<think> … </think> を本文から分離し、最終回答だけを表示する。Qwen3 / Qwen3.5 系は qwen3。

VLLM_REASONING_PARSER=qwen3

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

1 モデルを複数 GPU に分割して載せる。

4 枚で分割する例。

ENGINE_TENSOR_PARALLEL=4

GPU0 のみ使う例。

ENGINE_TENSOR_PARALLEL=1

ENGINE_TENSOR_PARALLEL が空（既定）の時は、検出 GPU 枚数以下の最大の 2 の冪（上限 ENGINE_TENSOR_PARALLEL_MAX、既定 8）
明示値が優先
役割ごとに変える場合は VLLM_EXTRA_ARGS_EMBED などに --tensor-parallel-size を書く

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

GPU ごと・別マシンの複数 vLLM サーバーを、用途（chat / embed / vision）ごとに 1 プールとして束ねる。

接続先を設定する

用途ごとに接続先を書く。

ENGINE_CHAT_ENDPOINTS=http://10.0.0.5:8001,http://10.0.0.6:8001
ENGINE_EMBED_ENDPOINTS=http://10.0.0.7:8002
ENGINE_VISION_ENDPOINTS=http://10.0.0.9:8003

未設定の用途は VLLM_BASE_URL 等を使う。反映には再起動が必要。

管理画面での見え方

モデル管理に用途ごとのプールとして表示する。接続先ごとに次を表示する。

状態・実モデル名
負荷（処理中・待ち件数、KV キャッシュ、TTFT など）
GPU 温度・電力（DCGM exporter 稼働時、DCGM_PORT 既定 9400）

本機で起動した接続先は起動 / 停止できる。外部接続（external）は監視のみ。

モデルの選択と振り分け

全接続先のモデルをチャットのモデル一覧にまとめて表示する。選択モデルを提供する接続先へ振り分ける。同じモデルが複数あればラウンドロビン。

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

OpenAI 互換の /v1/chat/completions（必要に応じて /v1/embeddings）を提供するサーバー（例: LM Studio、Microsoft Foundry Local）をバックエンドにできる。

LLM_BACKEND=vllm
VLLM_BASE_URL=http://<接続先ホスト>:<ポート>
ENGINE_AUTO_START=false
ENGINE_CHAT_MODEL=<接続先が提供するモデル名>
VLLM_EMBED_MODEL=<埋め込み用モデル名>
ENGINE_API_KEY=<必要な場合のみ>

VLLM_BASE_URL: OpenAI 互換エンドポイント
ENGINE_AUTO_START=false: 本機で推論サーバーを起動しない
ENGINE_API_KEY: Bearer 認証

注意

ツール呼び出し・思考の挙動は接続先の実装に依存する。クラウドの商用モデルはクラウド LLM の API キー設定を使う。

キーワード検索（文字の一致）

ナレッジ検索は、意味の近さ（ベクトル検索）と文字の一致（キーワード検索）を統合して候補を集める。

キーワード検索に使うのは、質問中の英数字の語（型番・ID など）と、漢字・カタカナが続く語。どちらも既定は 3 文字以上（pg_trgm の索引が効く長さ）
珍しい語ほど重く見て（IDF）並べる。ベクトル検索の結果と順位で統合する（RRF）
索引は PostgreSQL 標準の pg_trgm。追加の導入は不要

設定と条件は次のとおり。

DB のロケールが C の場合、pg_trgm が日本語を扱えない。日本語の語は使わず英数字の語だけで探す
質問から使う語の数は、英数字と日本語を合わせて RAG_HYBRID_MAX_TERMS（既定 8）
語の最短の長さは、英数字が RAG_HYBRID_MIN_ALNUM_CHARS、日本語が RAG_HYBRID_MIN_JAPANESE_CHARS（既定各 3）
図面の D1・X1 のような 2 文字の記号を拾うなら 2 にする。索引が効かずナレッジの全件を読むので、件数が多いと遅くなる

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

ナレッジ検索の候補をリランカー（cross-encoder）で再採点し、上位を選び直す。文書数が多い環境で有効。既定モデル BAAI/bge-reranker-v2-m3 は VRAM 消費が小さく、既存 GPU に同居できる。

補足

vLLM 版はワンクリックインストーラで自動化できる。以下は手動構成。状態確認・停止・起動はモデル管理 › 補助サーバー。

リランカーサーバーを起動する。

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

.env に設定し、API サーバーを再起動する。

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

ナレッジを選択してチャットで質問し、参照元が返ることを確認する。

設定	用途
`RERANK_TOP_N`	再採点にかける候補数（既定 30）
`RERANK_TIMEOUT`	タイムアウト秒（既定 30）

補足

リランカー停止時は従来の順序で検索を継続する。無効化は RERANK_ENABLED=false。インストーラーで入れたサーバーの削除: curl -fsSL https://pub-a2cab4360f1748cab5ae1c0f12cddc0a.r2.dev/vite-scripts/install-reranker.sh | bash -s -- --remove

GPU メモリ・文脈長の調整

GPU メモリと文脈長は次の設定で調整する。

設定	用途
`VLLM_GPU_MEMORY_UTILIZATION_CHAT` / `_EMBED`	サーバーごとの GPU メモリ割当
`LLM_CONTEXT_LENGTH`	最大文脈長（OOM 時は下げる）
`VLLM_EXTRA_ARGS_CHAT` / `_EMBED` / `_VISION`	`vllm serve` への追加引数（`--quantization` 等）

量子化モデルで必要な追加フラグはモデルカードで確認する。

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

症状に応じて引き上げる設定。環境変数の編集画面から変更し、再起動する。

症状	上げる設定	標準値
SQL テーブル閲覧の 1 回の読み込みを増やしたい	`SQL_TABLE_MAX_ROWS`	1000 行
複数人が同時に SQL を使う・ワークフローの SQL ステップが重なると待たされる / 失敗する	`SQL_POOL_SIZE` / `SQL_POOL_MAX_OVERFLOW`	空（SQLAlchemy の既定 5 / 10）
重いクエリを時間で止めたい	`SQL_STATEMENT_TIMEOUT_MS`	空（接続先の既定）
ページ全体の動作がもたつく（多人数アクセス）	`DB_POOL_SIZE` / `DB_POOL_MAX_OVERFLOW`	10 / 20
BI キーの REST (`/v1/data/query`) の結果が切れる	`GATEWAY_QUERY_MAX_ROWS`	10000 行

注意

接続は使う時だけ開く。ただし実接続数は SQL 画面とワークフローのそれぞれで最大 SQL_ENGINE_CACHE_MAX（標準 20）×（SQL_POOL_SIZE + SQL_POOL_MAX_OVERFLOW、空なら 5 + 10）になりうる。接続先の max_connections を超えそうな時は小さい値を入れる。

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

日数を入れると、それより古いログ・使用量データを毎日自動で削除する。標準は 0（無期限、削除しない）。

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

監査ログは削除前に AUDIT_ARCHIVE_DIR（標準 ~/.local/db/audit-archive/）へ JSONL で退避する。