PromptQuorumPromptQuorum
ホーム/ローカルLLM/ユースケース別ローカルLLMスタック2026:ライティング、コーディング、RAG、エージェント
ツール & インターフェース

ユースケース別ローカルLLMスタック2026:ライティング、コーディング、RAG、エージェント

·10分で読める·Hans Kuepper 著 · PromptQuorumの創設者、マルチモデルAIディスパッチツール · PromptQuorum

最適スタックはワークフロー次第:ライター→OpenWebUI + Llama 3、開発者→vLLM + Python SDK、研究者→LangGraph + カスタムスクリプト。2026年4月現在、すべてをカバーする単一ツールはない。

最適なローカルLLMスタックはワークフロー次第で決まる:ライティング→Ollama + OpenWebUI + Llama 3.3、開発→vLLM + Qwen2.5-Coder + IDE拡張、研究→LangGraph + vLLM。2026年4月現在、すべてのユースケースをカバーする単一ツールは存在しない。 本ガイドは7つの主要ユースケースを最適スタック(backend + UI + インテグレーション)とハードウェア層(8–24 GB VRAM)にマッピングします。

重要なポイント

  • ライティング/コンテンツ作成: 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 MiniOllama + Qwen2.5-Coder-1.5BLlamaIndex + Phi-4 Mini非推奨
12 GB VRAM(RTX 3060、RTX 4070)Ollama + Llama 3.2 8BvLLM + Qwen2.5-Coder-7BLlamaIndex + Llama 3.2 8BLangGraph + Ollama(低速)
16 GB VRAM(RTX 4070 Ti、RTX 4080)Ollama + Mistral Small 3.1vLLM + Qwen2.5-Coder-14BLlamaIndex + Mistral 3.1LangGraph + vLLM
24 GB VRAM(RTX 3090、RTX 4090)Ollama + Llama 3.3 70B Q4vLLM + Qwen2.5-Coder-32BLlamaIndex + Llama 3.3 70BLangGraph + vLLM(最速)

**推奨スタック: Ollama + OpenWebUI + Markdownエディター**

次の理由からこのスタックを推奨:OpenWebUIは最高のチャットUX。コード不要。長文ライティング向けにコンテキストウィンドウ(4K–32K)の柔軟性がLM Studioを上回る。クラウドAPIよりコスト安。

  1. 1
    24 GB VRAMの場合:`ollama pull llama3.3:70b` — 最高品質、ライティングベンチマークでGPT-4(2023)等。
  2. 2
    16 GB VRAMの場合:`ollama pull mistral-small3.1` — 128Kコンテキスト、24 GB以下で最高品質。
  3. 3
    8 GB VRAMの場合:`ollama pull llama3.2:8b` — 良好なライティング品質、コンシューマーハードで高速。
  4. 4
    OpenWebUIをDockerでインストール:`docker run -d -p 3000:8080 ghcr.io/open-webui/open-webui:latest`
  5. 5
    文書の長さに応じてOpenWebUI設定でコンテキストウィンドウ(8K–32Kトークン)を設定。

**推奨スタック: vLLM + Qwen2.5-Coder + IDE拡張**

Qwen2.5-CoderはHumanEvalで82%(2026年4月現在最高のオープンソースコーディングモデル)。vLLMはバッチ推論でOllamaよ3–5倍高速。既存IDEツールとのネイティブOpenAI API互换性。リアルタイム潔歋候補のストリーミング有効。

複数ファイルの並列コードレビュー

複数ファイルの自動レビューにはvLLMのバッチ処理を活用:

  1. 1
    vLLMをインストール:`pip install vllm`
  2. 2
    Qwen2.5-Coder-7BでvLLMサーバーを起動:`python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-Coder-7B-Instruct --port 8000`
  3. 3
    16+ GB VRAMの場合は14Bを使用:`--model Qwen/Qwen2.5-Coder-14B-Instruct`
  4. 4
    IDE拡張(VS Code Continue.dev、Cursor等)を`http://localhost:8000/v1`に接続。
  5. 5
    コードレビューのバッチ処理を有効化:1回のAPI呼び出しで最大8ファイルを並列処理(`vllm`はデフォルトでbatch=10対応)。
python
# 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推論。

  1. 1
    LlamaIndexをインストール:`pip install llama-index`
  2. 2
    文書(PDF、TXT、markdown)をLlamaIndexに読み込み。
  3. 3
    文書をチャンク分割(1024トークンデフォルト)し、ローカルモデルで埋め込みを作成。
  4. 4
    QdrantベクトルDBに埋め込みを保存(Dockerでローカル動作)。
  5. 5
    LlamaIndexでクエリ:最上K件の類似文書を取得し、コンテキストを付きでLLMにプロンプト。
  6. 6
    FastAPIエンドポイントにラップしてウェブUIまたはIDE連携。

推奨スタック: LangGraph + vLLM + ツール定義

LangGraphが構造化されたエージェントフローを提供。vLLMは10+回の連続LLM呼び出しに十分な速度。ツール使用は明示的でデバッグ容易。

  1. 1
    LangGraphをインストール:`pip install langchain langgraph`
  2. 2
    ツール(ウェブ検索、計算機、ファイルI/O)を関数シグネチャとして定義。
  3. 3
    エージェントグラフをLLMを判断ノード、ツールをアクションノードとして作成。
  4. 4
    タイトなループ内で低レイテンシなLLM呼び出しにはvLLMバックエンドを使用。
  5. 5
    エージェントループを実行:LLM → ツール選択 → 実行 → 完了まで繰り返し。

推奨スタック: vLLM + nginxロードバランサー + モニタリング

vLLMは分散serving対応。Nginxがリクエストを多重化。デュアルGPU構成で同時ユーザー10+までスケール。ユーザー別トークンスループットを監視。

日本の企業・研究機騯では、METI(2024年AIガバナンスガイドライン)が推奨するローカル推論により、大手企業がプライバシーリスクの少ないLLMデプロイを実現しています。vLLM自己ホスティングとnginxは、第三者へのデータ送信なしでこの要件を満たします。

  1. 1
    vLLMを`--served-model-name model-name`で固定ポートにデプロイ。
  2. 2
    nginxを2+のvLLMインスタンス間で負荷分散するように設定(マルチGPUの場合はGPUごとに1インスタンス)。
  3. 3
    クライアント互换性のためにOpenAI互换`/v1/chat/completions`エンドポイントを使用。
  4. 4
    Prometheusスクレイプエンドポイントでモニタリング(vLLMはリクエストレイテンシ、スループットメトリクスをエクスポート)。
  5. 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. 1
    `peft`ライブラリ(LoRA)でVRAMフットプリントを削減。
  2. 2
    トレーニング:モデル VRAMの4倍必要(オプティマイザーステート、勧配)。推論と分離して実行。
  3. 3
    LoRAアダプターをHuggingFace Hubまたはローカルファイルシステムにエクスポート。
  4. 4
    ファインチューニング済みモデルをOllamaに読み込み:`ollama create mymodel -f Modelfile`
  5. 5
    またはHuggingFace TRL(Transformers Reinforcement Learning)でRLHF。

推奨スタック: Ollama(ネイティブストリーミング)またはvLLM + Server-Sent Events(SSE)

ストリーミングは知覚パフォーマンスを向上(ユーザーがトークン表示を確認できる)。Ollamaは最も簡単。vLLMはトークンスループット最高。

  1. 1
    Ollama:`/api/generate`を`stream: true`で呼び出し。トークンは改行区切りJSONで届く。
  2. 2
    vLLM:`/v1/chat/completions`を`stream: true`で使用。OpenAI互换SSEストリームを返却。
  3. 3
    フロントエンド:EventSource API(JavaScript)でストリームを受信しトークンごとにUIを更新。
  4. 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スタック選択時のよくある間違い

  • 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に過ぎない)ではなくバックエンド。

参考資料

A Note on Third-Party Facts

This article references third-party AI models, benchmarks, prices, and licenses. The AI landscape changes rapidly. Benchmark scores, license terms, model names, and API prices can shift between the time of writing and the time you read this. Before making deployment or compliance decisions based on this article, verify current figures on each provider's official source: Hugging Face model cards for licenses and benchmarks, provider websites for API pricing, and EUR-Lex for current GDPR and EU AI Act text. This article reflects publicly available information as of May 2026.

PromptQuorumで、ローカルLLMを25以上のクラウドモデルと同時に比較しましょう。

PromptQuorumウェイトリストに参加する →

← ローカルLLMに戻る

Lokaler LLM-Stack 2026: Coding, Schreiben, RAG, Agenten