重要なポイント
- ライティング/コンテンツ作成: Ollama + OpenWebUI。設定不要、美しいチャットUI、コンテキストウィンドウ調整可能。
- コーディング/コードレビュー: vLLM + FastAPI + VS Code拡張。バッチ処理、並列推論、ストリーミング対応。
- ローカルRAG: LlamaIndex + Ollama/vLLM + QdrantベクトルDB。チャンク分割、埋め込み、検索を一体化。
- AIエージェント: LangGraph + vLLMバックエンド。ツール使用、メモリ、計画ループ。学習曲線はやや高め。
- マルチユーザーAPI: nginxロードバランサー配後vLLM。同時リクエスツ10+堆。最もスケーラブルな構成。
- ファインチューニング: HuggingFace Transformers + LoRA + Ollama(推論)。トレーニングとservingは分離。
- リアルタイムストリーミング: Ollama(ネイティブストリーミング)またはvLLM + トークンストリーミングエンドポイント。チャットボットのUX最強。
ハードウェア別判断テーブル(2026年4月)
GPU/VRAMに合わせた最適スタックを選択。実ベンチマークで検証済みの組み合わせ。コーディング・エージェントは大型モデルの恩恵が大きい。RAGはLLMサイズより埋め込み品質が重要。
| お使いのハード | ライティング | コーディング | RAG | エージェント |
|---|---|---|---|---|
| 4–8 GB VRAM(GTX 1660、RTX 3050) | Ollama + Phi-4 Mini | Ollama + Qwen2.5-Coder-1.5B | LlamaIndex + Phi-4 Mini | 非推奨 |
| 12 GB VRAM(RTX 3060、RTX 4070) | Ollama + Llama 3.2 8B | vLLM + Qwen2.5-Coder-7B | LlamaIndex + Llama 3.2 8B | LangGraph + Ollama(低速) |
| 16 GB VRAM(RTX 4070 Ti、RTX 4080) | Ollama + Mistral Small 3.1 | vLLM + Qwen2.5-Coder-14B | LlamaIndex + Mistral 3.1 | LangGraph + vLLM |
| 24 GB VRAM(RTX 3090、RTX 4090) | Ollama + Llama 3.3 70B Q4 | vLLM + Qwen2.5-Coder-32B | LlamaIndex + Llama 3.3 70B | LangGraph + vLLM(最速) |
**推奨スタック: Ollama + OpenWebUI + Markdownエディター**
次の理由からこのスタックを推奨:OpenWebUIは最高のチャットUX。コード不要。長文ライティング向けにコンテキストウィンドウ(4K–32K)の柔軟性がLM Studioを上回る。クラウドAPIよりコスト安。
- 124 GB VRAMの場合:`ollama pull llama3.3:70b` — 最高品質、ライティングベンチマークでGPT-4(2023)等。
- 216 GB VRAMの場合:`ollama pull mistral-small3.1` — 128Kコンテキスト、24 GB以下で最高品質。
- 38 GB VRAMの場合:`ollama pull llama3.2:8b` — 良好なライティング品質、コンシューマーハードで高速。
- 4OpenWebUIをDockerでインストール:`docker run -d -p 3000:8080 ghcr.io/open-webui/open-webui:latest`
- 5文書の長さに応じてOpenWebUI設定でコンテキストウィンドウ(8K–32Kトークン)を設定。
**推奨スタック: vLLM + Qwen2.5-Coder + IDE拡張**
Qwen2.5-CoderはHumanEvalで82%(2026年4月現在最高のオープンソースコーディングモデル)。vLLMはバッチ推論でOllamaよ3–5倍高速。既存IDEツールとのネイティブOpenAI API互换性。リアルタイム潔歋候補のストリーミング有効。
複数ファイルの並列コードレビュー
複数ファイルの自動レビューにはvLLMのバッチ処理を活用:
- 1vLLMをインストール:`pip install vllm`
- 2Qwen2.5-Coder-7BでvLLMサーバーを起動:`python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-Coder-7B-Instruct --port 8000`
- 316+ GB VRAMの場合は14Bを使用:`--model Qwen/Qwen2.5-Coder-14B-Instruct`
- 4IDE拡張(VS Code Continue.dev、Cursor等)を`http://localhost:8000/v1`に接続。
- 5コードレビューのバッチ処理を有効化:1回のAPI呼び出しで最大8ファイルを並列処理(`vllm`はデフォルトでbatch=10対応)。
# Review 10 files in parallel using vLLM batch processing
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
code_files = [
("utils.py", open("utils.py").read()),
("models.py", open("models.py").read()),
# ... up to 10 files
]
# vLLM processes all 10 in parallel (1 batch request)
reviews = []
for filename, code in code_files:
prompt = f"Review this code for bugs, style, and performance:
{code}"
response = client.chat.completions.create(
model="Qwen2.5-Coder-7B-Instruct",
messages=[{"role": "user", "content": prompt}],
temperature=0.2, # Deterministic for review tasks
)
reviews.append((filename, response.choices[0].message.content))
for filename, review in reviews:
print(f"=== {filename} ===
{review}
")推奨スタック: LlamaIndex + Ollama/vLLM + Qdrant + FastAPI UI
LlamaIndexがチャンク分割・検索を歋当。Qdrantは高速・ローカル・プライベート。Ollamaで埋め込みを生成(無料)、またはvLLMでLLM推論。
- 1LlamaIndexをインストール:`pip install llama-index`
- 2文書(PDF、TXT、markdown)をLlamaIndexに読み込み。
- 3文書をチャンク分割(1024トークンデフォルト)し、ローカルモデルで埋め込みを作成。
- 4QdrantベクトルDBに埋め込みを保存(Dockerでローカル動作)。
- 5LlamaIndexでクエリ:最上K件の類似文書を取得し、コンテキストを付きでLLMにプロンプト。
- 6FastAPIエンドポイントにラップしてウェブUIまたはIDE連携。
推奨スタック: LangGraph + vLLM + ツール定義
LangGraphが構造化されたエージェントフローを提供。vLLMは10+回の連続LLM呼び出しに十分な速度。ツール使用は明示的でデバッグ容易。
- 1LangGraphをインストール:`pip install langchain langgraph`
- 2ツール(ウェブ検索、計算機、ファイルI/O)を関数シグネチャとして定義。
- 3エージェントグラフをLLMを判断ノード、ツールをアクションノードとして作成。
- 4タイトなループ内で低レイテンシなLLM呼び出しにはvLLMバックエンドを使用。
- 5エージェントループを実行:LLM → ツール選択 → 実行 → 完了まで繰り返し。
推奨スタック: vLLM + nginxロードバランサー + モニタリング
vLLMは分散serving対応。Nginxがリクエストを多重化。デュアルGPU構成で同時ユーザー10+までスケール。ユーザー別トークンスループットを監視。
日本の企業・研究機騯では、METI(2024年AIガバナンスガイドライン)が推奨するローカル推論により、大手企業がプライバシーリスクの少ないLLMデプロイを実現しています。vLLM自己ホスティングとnginxは、第三者へのデータ送信なしでこの要件を満たします。
- 1vLLMを`--served-model-name model-name`で固定ポートにデプロイ。
- 2nginxを2+のvLLMインスタンス間で負荷分散するように設定(マルチGPUの場合はGPUごとに1インスタンス)。
- 3クライアント互换性のためにOpenAI互换`/v1/chat/completions`エンドポイントを使用。
- 4Prometheusスクレイプエンドポイントでモニタリング(vLLMはリクエストレイテンシ、スループットメトリクスをエクスポート)。
- 5ユーザーごとのレート制限をトークンバケットアルゴリズムで設定。
推奨スタック: HuggingFace Transformers + LoRA + Ollama(推論)
LoRAはVRAMフットプリントを10分の1に削減。Ollamaはファインチューニング済みモデルを簡単に読み込み。モジュール式:トレーニングとservingを分離。
注意(2026年4月): MetaはLlama 2の商用ファインチューニングを非推奨。Llama 3.2(`meta-llama/Llama-3.2-1B`以上)またはQwen2.5(`Qwen/Qwen2.5-7B`)のApache 2.0ライセンスを選択。両方ともLoRAとOllama読み込みに対応。
- 1`peft`ライブラリ(LoRA)でVRAMフットプリントを削減。
- 2トレーニング:モデル VRAMの4倍必要(オプティマイザーステート、勧配)。推論と分離して実行。
- 3LoRAアダプターをHuggingFace Hubまたはローカルファイルシステムにエクスポート。
- 4ファインチューニング済みモデルをOllamaに読み込み:`ollama create mymodel -f Modelfile`
- 5またはHuggingFace TRL(Transformers Reinforcement Learning)でRLHF。
推奨スタック: Ollama(ネイティブストリーミング)またはvLLM + Server-Sent Events(SSE)
ストリーミングは知覚パフォーマンスを向上(ユーザーがトークン表示を確認できる)。Ollamaは最も簡単。vLLMはトークンスループット最高。
- 1Ollama:`/api/generate`を`stream: true`で呼び出し。トークンは改行区切りJSONで届く。
- 2vLLM:`/v1/chat/completions`を`stream: true`で使用。OpenAI互换SSEストリームを返却。
- 3フロントエンド:EventSource API(JavaScript)でストリームを受信しトークンごとにUIを更新。
- 4最小レイテンシのためバッチ処理を無効化(batch=1)。
OllamaとvLLMはどちらを使うべきですか?
OllamaはチャットUI + シンプルさ向け。vLLMはAPIサーバー + バッチ処理 + パフォーマンス向け。相互排他ではない。両方並行実行可能。
Ollamaを本番環境のAPIに使えますか?
使えますが、vLLMの方が高速(3–5倍のスループット)。Ollamaは<10 req/s向け。vLLMは10+ req/s向け。
コードレビューに最適なローカルLLMは?
vLLM + Qwen2.5-Coder-7B-Instruct。Qwen2.5-CoderはHumanEvalで82%(オープンソース最高)。vLLMは10ファイルを並列分。RTX 3060 12GBで絀30–50 tok/s。
簡単なRAGにベクトルDBは必要ですか?
<100文書の場合はインメモリ埋め込み(np.ndarray)で十分。>100文書の場合はQdrantまたはWeaviateを推奨。
LangGraphはシンプルなチャットボットには过剰ですか?
はい。OllamaまたはvLLM単体で十分。LangGraphはマルチステップワークフロー(エージェントループ、計画)向け。
OllamaとvLLMのバックエンドを並行使用できますか?
できます。例:OllamaでチャットUI、vLLMでバッチAPI。同一マシンで別ポートで動作可能。
関連記事
- コーディング向きローカルLLM 2026 — Qwen2.5-Coder vs DeepSeek-CoderのHumanEvalランキング。
- ローカルRAG設定 2026 — LlamaIndex + Qdrant + Ollamaの完全実装ガイド。
- ローカルLLMエージェント(LangGraph) — ステップごとのエージェントワークフローフレームワーク。
- Ollama vs LM Studio — バックエンド比較:CLI vs GUI、速度、バッチ処理。
- Open WebUI vs SillyTavern — チャットUI比較:プロフェッショナル vs ロールプレイ。
- ローカルLLMに必要なVRAMは? — モデルサイズとユースケース別ハードウェア要件。
LLMスタック選択時のよくある間違い
- vLLMなしでOllamaを本番環境APIに使用: Ollamaは<10 req/sが上限。10+同時ユーザーの本番環境ではvLLMが必須。デプロイ前に負荷下でスループットをテスト。
- vLLMバックエンドなしでLangGraphを実行: LangGraphエージェントは10+回の連続LLM呼び出し。Ollamaはレイテンシのボトルネックになりやすい。サブ秒の応答時間にはLangGraph + vLLMの組み合わせが必須。
- メモリ管理なしに同じGPUでOllama + vLLMを混在: 両ツールがVRAMに重みを読み込む。70Bモデルを2インスタンス実行するとVRAM 32 GB消費。GPUを分けるか、Q2高圧縮で充分なスペースを確保。
- ライティング用に不適切なコンテキストウィンドウを選択: デフォルトの4Kコンテキストはブレインストーミングセッションに制約。長文ライティングではOpenWebUIのコンテキストウィンドウをトークン16K–32Kに設定。トレードオフ:トークンごとの推論速度が2–3倍低下。
- すべてのバックエンドが同じ速度だと誤解: vLLMとOllamaは異なるカーネルを使用。同じハードウェアで、vLLMは推論速度が2–3倍高い。速度の違いはフロントエンド(OpenWebUI、LM StudioはUIに過ぎない)ではなくバックエンド。
参考資料
- Ollama GitHub — 公式ドキュメント、ストリーミングAPI仕様、モデルライブラリ。
- vLLM GitHub — OpenAI API互换性、バッチ処理、連続バッチングのドキュメント。
- Qwen2.5-Coder技術レポート — Alibaba Qwen。HumanEval 82%、コーディング特化。Apache 2.0ライセンス。
- LlamaIndexドキュメント — 文書インデックス、チャンク分割、RAG検索フレームワーク。
- LangGraphドキュメント — エージェントワークフロー、ステートマシン、ツール使用パターン。
- Qdrantドキュメント — ローカル埋め込み保存用ベクトルDB、Docker対応、Apache 2.0。
- Continue.devドキュメント — ローカルLLMバックエンドを使用するVS Code / JetBrains用IDE拡張。