OllamaからvLLMへの移行設計｜ローカルLLMで複数モデルを同時運用する構成

社内AI基盤で複数モデルを同時運用する際は、API互換性、GPUメモリの割り当て、推論サーバーの管理を検討する必要があります。DigitalBaseでの構築知見をもとに、Ollama から vLLM へ移行する際の設計と手順を整理します。

アーキテクチャ比較

Ollamaのアーキテクチャ

Ollamaは、llama.cppをバックエンドに持つ統合型エンジンです。

┌─────────────────────────────────────────┐
│              Ollama Server              │
│  ┌─────────────────────────────────┐    │
│  │     Model Manager               │    │
│  │  (pull / run / list / ps)       │    │
│  ├─────────────────────────────────┤    │
│  │     Inference Engine            │    │
│  │     (llama.cpp / ggml)          │    │
│  ├─────────────────────────────────┤    │
│  │     REST API                    │    │
│  │  /api/chat  /api/generate       │    │
│  │  /api/embed /api/tags           │    │
│  └─────────────────────────────────┘    │
│                                         │
│  ・1プロセスで全機能を提供              │
│  ・モデルの自動ダウンロード・管理       │
│  ・GGUFフォーマット（量子化対応）       │
│  ・単一モデルの逐次推論が基本           │
└─────────────────────────────────────────┘

特徴

• シングルサーバー構成：1つの ollama serve が全リクエストを処理
• 独自API：/api/chat、/api/generate、/api/embed など（別途 /v1 配下に OpenAI 互換エンドポイントも提供）
• モデル管理の統合：ollama pull で自動ダウンロード、Modelfileでカスタマイズ
• メモリ管理：モデルをロード/アンロードし、OLLAMA_NUM_PARALLEL で並列数を制御

vLLMのアーキテクチャ

vLLMは、GPUメモリ効率を重視するPython製の推論エンジンです。

┌───────────────────────────────────────────────────────┐
│                    vLLM Architecture                   │
│                                                        │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐ │
│  │ Chat Server  │  │ Embed Server │  │Vision Server │ │
│  │  :8080       │  │  :8081       │  │  :8082       │ │
│  │              │  │              │  │  (optional)  │ │
│  │ Qwen2.5      │  │ E5-large     │  │ Qwen2-VL     │ │
│  │ -1.5B-Inst   │  │ -instruct    │  │              │ │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘ │
│         │                 │                 │          │
│  ┌──────┴─────────────────┴─────────────────┴───────┐ │
│  │           GPU Memory (PagedAttention)             │ │
│  │  ┌─────────────┐ ┌──────────┐ ┌───────────────┐  │ │
│  │  │ Chat: 55%   │ │Embed:35% │ │ Vision: 10%   │  │ │
│  │  │ GPU VRAM    │ │GPU VRAM  │ │ GPU VRAM      │  │ │
│  │  └─────────────┘ └──────────┘ └───────────────┘  │ │
│  └───────────────────────────────────────────────────┘ │
│                                                        │
│  ・モデルごとに独立プロセス                            │
│  ・OpenAI互換API (/v1/chat/completions)               │
│  ・GPUメモリの割合を個別に制御                         │
│  ・Continuous Batchingで高スループット                 │
└───────────────────────────────────────────────────────┘

特徴

• マルチサーバー構成：用途ごとに独立したサーバープロセスを起動
• OpenAI互換API：/v1/chat/completions、/v1/embeddings、/v1/models
• PagedAttention：GPUメモリをページ単位で管理し、KVキャッシュの無駄を最小化
• Continuous Batching：複数リクエストを動的にバッチ処理し、スループットを最大化
• HuggingFaceモデルの直接利用：ダウンロードからロードまで自動

OllamaとvLLMの比較

Ollamaの特性

vLLMの特性

比較表

OllamaからvLLMへの移行

DigitalBaseの社内AI基盤の本番化で実装した移行作業を、5つのステップに整理します。

Step 1: APIクライアント層の変更

最も大きな変更は、Ollama独自APIからOpenAI互換APIへの切り替えです。

主な変更点

Step 2: Embeddingサーバーの分離

Ollamaでは1つのサーバーでChatもEmbeddingも処理しますが、vLLMではEmbeddingを専用サーバーとして分離します。

サーバー分離には次のメリットがあります。

• メモリの独立管理：Chat 55%、Embedding 35%のようにGPUメモリを用途別に割り当て
• 独立したスケーリング：Embeddingの負荷が高い場合、そのサーバーだけスケールアウト可能
• 障害の分離：Chatサーバーがクラッシュしても、Embedding処理を継続できる

RAGパイプラインでは、検索のためのEmbedding生成とChat推論が同時に走ります。この分離は、社内ドキュメント検索を伴う用途で特に効果が大きい設計です。

Step 3: Vision APIの移行

画像認識もAPIフォーマットが異なります。

Ollama版

# Ollama: imagesフィールドにbase64画像を配列で渡す
response = await client.post(
    f"{OLLAMA_BASE_URL}/api/chat",
    json={
        "model": vision_model,
        "messages": [{
            "role": "user",
            "content": prompt,
            "images": [image_b64]  # Ollama独自形式
        }],
        "stream": False
    }
)

vLLM版

# vLLM: OpenAI形式のcontent配列にimage_urlブロックを含める
content = [
    {"type": "text", "text": prompt},
    {
        "type": "image_url",
        "image_url": {"url": f"data:image/png;base64,{image_b64}"}  # OpenAI形式
    },
]
response = await client.post(
    f"{VLLM_BASE_URL}/v1/chat/completions",
    json={
        "model": vision_model,
        "messages": [{"role": "user", "content": content}],
        "max_tokens": 4096,
    }
)

Step 4: インフラ層（プロセス管理）の変更

Ollamaは ollama serve の1プロセスで完結しますが、vLLMは用途別にプロセスを起動します。

実装上の要点は起動順序です。vLLMはモデルロード時にGPUメモリを確保するため、メモリ使用量の大きいChatサーバーを先に起動して完了を待ち、その後にEmbeddingサーバーを起動する必要があります。順序を誤るとメモリ確保が競合し、起動に失敗します。

Step 5: SSEストリーミングパーサーの実装

OllamaはNDJSON（1行1JSON）でストリーミングしますが、vLLMはSSE（Server-Sent Events）形式です。パーサーの差し替えが必要になります。

vLLMサーバーの起動コマンド

移行後のvLLMサーバーの起動コマンドを示します。

Chatサーバー

python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2.5-1.5B-Instruct \
  --host 0.0.0.0 \
  --port 8080 \
  --gpu-memory-utilization 0.55 \
  --tensor-parallel-size 1

Embeddingサーバー

# vLLM 0.15.0以降: --convert embed を使用（旧 --task embed）
python -m vllm.entrypoints.openai.api_server \
  --model intfloat/multilingual-e5-large-instruct \
  --host 0.0.0.0 \
  --port 8081 \
  --gpu-memory-utilization 0.35 \
  --convert embed

Visionサーバー（オプション）

python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2-VL-7B-Instruct \
  --host 0.0.0.0 \
  --port 8082 \
  --gpu-memory-utilization 0.10

--gpu-memory-utilization の合計が単一GPUの容量を超えないよう、各サーバーの割り当てを設計時に確定させておく点が重要です。

エンジンの使い分け

Ollamaが適するケース

vLLMが適するケース

まとめ

OllamaからvLLMへの移行は、次のステップで進められます。

1. APIエンドポイントの変更：独自API → OpenAI互換API
2. Embeddingの分離：同一サーバー → 専用サーバー
3. Vision APIの変更：images配列 → OpenAI content配列
4. プロセス管理の変更：単一プロセス → マルチプロセス（起動順序に注意）
5. ストリーミング形式の変更：NDJSON → SSE

移行時は、APIエンドポイントとストリーミング形式の変更に加え、Embedding・Visionを含む各サーバーのGPUメモリ割り当てと起動順序を確認します。

下記のお悩みなら、ご相談ください

PoC から商用化に進むには、次の 3 点が必要になります。統合型 AI エージェント基盤「DigitalBase」は、 これらを 1 つの製品で提供しています。お気軽にご相談ください。