LiteLLM on Proxmox + opencode 連携

軽量・安価なLLMを opencode から使うため、Proxmox上のLXCにLiteLLMプロキシ(OpenAI互換)を立て、ローカルollama / NVIDIA NIM / AI Studio(Gemma) を集約。Claude Code から重い生成・実装を opencode 経由でオフロードする目的（/implement・/oc スキル、techlead→実装委譲フロー）。

ベンチで絞り込んだ結果、運用は4モデル（ローカル1＋NIM1＋OpenRouter1＋Gemma予備1）。

最終構成（運用モデル）

ローカル : gemma4-12b        (ollama, VRAM常駐, 既定・日常)   難問4/5・66tok/s
NIM      : nim-gpt-oss-120b  (NVIDIA NIM, 難所/escalation)    難問5/5・186tok/s
OpenRouter: or-gpt-oss-120b  (openai/gpt-oss-120b:free)       NIMのフォールバック
予備     : ai-gemma-31b      (AI Studio Gemma, 低速)          難問6/6だが14-90s

opencode 既定 = litellm/gemma4-12b。難所は -m litellm/nim-gpt-oss-120b。

フォールバック設計

• ローカル(gemma4-12b)はフォールバック無し。ollama停止/エラー時は HTTP 500 を即返す(検証: 0.9s)。ローカルエラーの切り分けはClaude Code側で行う方針（時間ベースの誤フォールバックでローカル長生成が切られるのを避けるため）。
• NIM → OpenRouter: nim-gpt-oss-120b 失敗時に or-gpt-oss-120b(無料)へ自動切替（検証: 5.3sでopenai/gpt-oss-120b:freeが応答）。
• 設定: litellm_settings.fallbacks: [{"nim-gpt-oss-120b": ["or-gpt-oss-120b"]}]、num_retries: 0、NIM/OpenRouterは各 timeout: 60、global request_timeout: 120。
• 補足: LiteLLMの cooldown_time/allowed_fails はフォールバック成功が失敗として記録されないため効かず（host-off中の毎回待機を防げない）。timeout(total)は接続/読込を分離できないので、短くすると長生成も切れる点に注意。

Proxmox (192.168.1.10)

• LXC 117 litellm / Debian 13 / unprivileged / nesting=1,keyctl=1
  • メモリ 4GB（当初2GBはLiteLLMがOOM→ワーカー落ち→接続リセット多発。4GBへ増設で解消）
  • 2 core / 8GB disk (ZFS local_data)、--onboot 1、固定IP 192.168.1.40（DHCP予約 MAC BC:24:11:AF:40:F8）
• Docker公式スクリプト導入。/opt/litellm/（compose / config.yaml / .env）
• ghcr.io/berriai/litellm:main-stable、--num_workers 1（2GB時のメモリ対策。4GBなら2でも可）

ollama ホスト (192.168.1.8 / RTX5070 12GB + 64GB RAM)

VRAM 12GBにフル常駐できるのは7–14B級(Q4)まで。24B超はRAMオフロードで低速（MoEなら中速）。 保有: qwen3.5:9b / gemma4:12b / gemma4:26b / qwen3.6:35b(MoE) / qwen3-coder-next(80B)。

ベンチマーク総括（2026-06-18）

計測条件: ローカルはollama直叩き(think:false基本)、tok/sはeval_duration実測(ロードはウォームアップ除外)。クラウドはLiteLLM経由・streamで実測。コードは生成物を実行しテスト、情報収集は抽出/正規化で照合。

ローカル(ollama) — 高難易度5問(正規表現/coin DP/右結合冪乗/word_break/Dijkstra)

モデル / think	正答	tok/s	合計
qwen3.5:9b OFF	2/5	95	6s
qwen3.5:9b ON	1/5	94	176s
gemma4:12b OFF	4/5	66	43s
qwen3.6:35b OFF	5/5	33	69s
qwen3.6:35b ON	5/5	33	582s

• thinkは逆効果: 35bは精度同じで8倍遅い(69→582s)、9bは遅化＋悪化。コード生成はthink OFF。
• qwen3.5:9bは易問・情報収集は満点でも高難易度は不適(2/5)（型注釈import漏れ等）。
• gemma4:12bが実用バランス最良（4/5・66tok/s・常駐）。qwen3.6:35bが local最高精度(5/5)だが低速・非常駐。
• 情報収集(抽出/読解/needle/忠実性)はローカル各モデルとも堅実 → RAG/調査はローカルで可。

NVIDIA NIM — 高難易度5問 + tok/s(stream実測)

モデル	難問	平均tok/s	備考
nim-gpt-oss-120b	5/5	186	満点かつ高速 ★採用
qwen3-next-80b-a3b	5/5	68	満点だが約1/3速
gpt-oss-20b	4/5	401(最速)	word_break失敗
minimax-m3	4/5	11(激遅)	calc失敗・TTFT最大32s
deepseek-v4-flash	5/6(基礎側)	—	eval_expr失敗＋429
qwen3.5-122b-a10b / 397b-a17b	—	—	無料枠で激遅(TTFT82s/timeout)→不採用
kimi-k2.6	3/6	—	反復ループ等で不安定→不採用

• 巨大モデル(a10b/a17b)は無料NIM枠で遅すぎ。active paramが小さい方が速度・安定で有利。
• gpt-oss-120bが精度(5/5)と速度(186tok/s)で最良。

AI Studio Gemma — 高難易度

モデル	コード	情報収集	速度
ai-gemma-31b	6/6	4/5	14–90s
ai-gemma-26b-a4b	4/6	5/5	48–126s
→ 31bが上だが両者とも無料枠で激遅。予備位置づけ。

シークレット

マスターキー / NVIDIA NIM / GEMINI(=Gemma用) キーは コンテナの /opt/litellm/.env（chmod 600）。本KBは公開され得るため鍵は記載しない。

opencode 設定 (Mac)

~/.config/opencode/opencode.json の custom provider litellm（@ai-sdk/openai-compatible、baseURL=http://192.168.1.40:4000/v1、既定 litellm/gemma4-12b）。

ハマりどころ

• LiteLLM OOM: 2GB RAMでは遅い/並行リクエストでワーカーがOOM→Connection reset/Broken pipe多発。4GBへ増設＋--num_workers 1で解消。
• thinkingモデルの空content: qwen3系は思考をmessage.thinkingに出し、num_predictを使い切るとcontentが空(done_reason:length)。コード生成はthink:false必須。
• DHCP予約MAC不一致: 予約が別MACだと.40取得不可。修正後 pct reboot 117（dhclient手動更新では取れず）。
• NIM EOL/可用性: slugは https://integrate.api.nvidia.com/v1/models で確認。
• SSH多層クオート: ssh→pct exec→bash→python はクオートが潰れる。スクリプトはbase64転送が確実。
• ベンチの落とし穴: num_predict不足で出力切れ→誤って不正解判定。コード抽出は閉じフェンス無し/think除去に対応必須。

保守コマンド

ssh root@192.168.1.10 'pct exec 117 -- bash -c "cd /opt/litellm && docker compose up -d --force-recreate"'
curl http://192.168.1.40:4000/v1/models -H "Authorization: Bearer <master-key>"
ssh root@192.168.1.10 'pct exec 117 -- docker logs --tail=50 litellm'