ローカルLLMの推論エンジン、結局どれ使う?──Ollama・vLLM・exl3を実際に触って選んだ話【2026】

「ローカルLLM動かすぞ」ってなると、だいたい最初に触るのがOllama。1コマンドで動くし、正直これで9割の人は満足だと思う。

でも自分みたいに「社内で何人かで共有したい」「エージェントで並列にブン回したい」ってなった瞬間、話がガラッと変わる。Ollamaで動く、と、複数人で並列運用できる、は別問題なんだよね。

この記事では、まず世の中にある推論エンジンをざっくり紹介して、そのあと自分が実際に社内サーバーを組んで「vLLMで始めてexl3に落ち着いた」話をする。専門用語は最後にまとめて解説つけたので、途中で「?」ってなっても大丈夫。

そもそも「推論エンジン」って何?

ざっくり言うと、モデルの重み(ggufとかsafetensorsのファイル)を読み込んで、実際に「入力→応答」を計算してくれるソフトのこと。ChatGPTでいう中身の実行部分を、自分のPCやサーバーで動かすやつ。

多くのエンジンがOpenAI互換APIを喋る。だからアプリ側は接続先URLを差し替えるだけで動く…というのが建前で、ここに落とし穴もあるんだけど、それはまた別記事で。まずは「どれを選ぶか」から。

主要な推論エンジンをざっくり

2026年時点でよく名前が挙がるのはこのへん。用途で棲み分けてる感じ。

おおまかには、1人ならOllama、本番の並列ならvLLM、って覚えとけばまず外さない。ただ、この「本番の並列」でGPUがちょっと古いと、自分みたいにハマる。

自分の実体験:vLLMで始めて、exl3に落ち着いた話

社内で何人かがAIを同時に使えるサーバーを組みたくて、最初はvLLMを選んだ。並列といえばvLLM、って評判だったし。

でもここでGPUの世代がネックになった。自分の手元はRTX3090。少し古いAmpere世代なんだけど、vLLMのFP8 KVキャッシュ量子化がAmpereでは非対応だった。これはvLLMのバグとかじゃなくて、FP8のKVキャッシュ圧縮が4090やH100以降のGPUじゃないとハード的に効かない、という話。

何が困るかというと、KVキャッシュを圧縮できない＝VRAMを大量に食う。長いコンテキスト×並列をやろうとすると、すぐVRAMが埋まる。8bitや4bitに圧縮してなんとかしようとしても、3090だとうまくハマらなかった。

そこでexl3(ExLlamaV3)＋TabbyAPIに切り替えた。EXL3は量子化のKVキャッシュが3090でもちゃんと効くのが大きい。結果どうなったかというと——

• Qwen3.6:27B を 128Kコンテキストで 5並列まで快適に回せてる
• デコード速度:50〜70 token/s（後述のMTPあり。MTP無しだと30 token/sくらい）
• プレフィル速度:700〜1200 token/s

この速度アップの立役者がMTP(Multi-Token Prediction)。exl3がMTPに対応してて、有効にするとデコードが50〜70 token/sまで伸びた。MTPを切ると30 token/sくらいなので、体感でほぼ倍違う。ここ、エンジン選びで意外と見落とされがちなポイントだと思う。

※これは自分の環境(RTX3090)での実測なんで、GPUやモデル・設定で普通に変わる。あくまで一例として。

言いたいのは、「Ollamaで動く」と「社内で並列運用できる」は本当に別問題ってこと。そして並列をやるときは、GPUの世代とKVキャッシュの相性で選ぶエンジンが変わる。ここ、意外と情報が少ないんだよね。

用語解説(ここだけ読んでも可)

• 推論エンジン:モデルの重みを読んで「入力→応答」を計算する実行ソフト。Ollamaやv LLMがこれ。
• OpenAI互換API:OpenAIと同じ形式のAPIを喋ること。アプリ側は接続先を変えるだけで繋がる(建前上は)。
• KVキャッシュ:会話の途中経過(過去トークンの計算結果)を保持しておくメモリ。長い文脈・並列で急激に増える。VRAMを食う主犯。
• 量子化(4bit/8bit):モデルやキャッシュの数値の精度を落として容量を減らすこと。GGUF・EXL3などが量子化の形式。多少の劣化と引き換えにVRAMを節約。
• コンテキスト長:一度に扱える文章の長さ(トークン数)。128K=約12万トークン。長いほどKVキャッシュも増える。
• prefill / decode:prefill=入力(プロンプト)をまとめて処理する段階。decode=応答を1トークンずつ生成する段階。速度の単位が違うのはこのため。
• MTP(Multi-Token Prediction):1ステップで複数トークンをまとめて予測して生成を速くする仕組み(投機的デコードの一種)。対応エンジン＋対応モデルの組み合わせで効く。自分の環境ではこれのオン/オフでデコードが30→50〜70 token/sと、ほぼ倍変わった。
• 並列(バッチング):複数リクエストを同時にさばくこと。5並列=5人分を同時処理。vLLMやexl3が得意。
• スループット(token/s):1秒あたり何トークン処理できるか。並列運用ではここが体感速度に直結。
• VRAM:GPUのメモリ。モデル本体＋KVキャッシュがここに乗る。足りないと落ちるか遅くなる。

まとめ:用途で選ぶのが正解

• 1人・お試し → Ollama / LM Studio
• 非力なハードや何でも動かしたい → llama.cpp
• 本番で多人数の並列(新しめのGPU) → vLLM
• エージェント・RAGで共通プロンプトを使い回す → SGLang
• 消費者GPU(3090/4090)で並列＆大きめモデル → exl3 + TabbyAPI ← 自分はここ
• Mac → MLX

次回は、この「OpenAI互換だから差し替えるだけでしょ?」が半分ウソだった話——vLLMに繋いで実際に踏んだ落とし穴——を書く予定。まずはエンジン選びの地図として、この記事が役に立てば。

参考:vLLMのFP8 KVキャッシュがAmpere(3090)で非対応という点は、vLLM公式フォーラム/GitHub Issueでも報告されている(「type fp8e4nv not supported in this architecture」)。エンジン全体の棲み分けは各種2026年比較ガイドを参照。