推論エンジンとは、ローカルLLMをCPUやGPU上で動かす実行基盤である。
ローカルLLMアプリの「LM Studio」が5月29日、「0.4.15(Build 2)」へアップデートされました。目玉は、NVIDIAのCUDA環境でマルチGPUのテンソル並列処理に対応した点。同じモデルを同じGPUで動かしても、どの推論エンジンを使うかで速度も対応できる構成も変わります。今回の対応は「マルチGPUで効くエンジンとそうでないエンジン」の差が、実利益として表れる一例でした。
そこで本記事では、Ollama・llama.cpp・LM Studio・vLLMの4つを横断比較します。当サイトの検証環境(RTX 5080+RTX 5060 Ti のデュアル構成)での実測を交えつつ、ご自身の構成なら何を選ぶべきかを逆引きできる形で整理していきます。
- ・4エンジンは「手軽さ・速度・マルチGPU対応・運用安定性」で住み分かれる
- ・マルチGPUで速くなるのはテンソル並列に対応したエンジンと構成が前提
- ・VRAM容量と運用の安定性が、実際の選定を左右する
4エンジンの立ち位置と、比較のポイント
ローカルLLMを動かす入口は1つではありません。Ollama・llama.cpp・LM Studio・vLLMは、いずれも「LLMをGPU上で走らせる」点では共通しますが、得意分野がはっきり分かれます。1つに絞れないのは、同じモデル・同じGPUでもエンジンによって生成速度や対応できるGPU構成が違うためです。
比べるのは手軽さ・速度・マルチGPU対応の3点です。手軽さは導入の難度やモデル管理のしやすさ、GUIの有無。速度はtokens/secと、初回応答までの体感。マルチGPU対応は複数GPUを束ねて1つの大きなモデルを走らせられるか、テンソル並列に対応するかどうか。以降はこの3点を比較基準にしていきます。
まず全体像を表で確認してください。
| エンジン | 対応OS | GUI | マルチGPU/テンソル並列 | 主な用途 | 導入難度 |
|---|---|---|---|---|---|
| Ollama | Win/Mac/Linux | CLI中心(別途GUIあり) | レイヤー分割・スケジューリングで複数GPU可(明示的なテンソル並列指定はLM Studio/vLLMとは性格が異なる) | 手軽な常用・モデル管理 | 低 |
| llama.cpp | Win/Mac/Linux | CLI | レイヤー分割に加え、CUDA環境ではテンソル並列にも対応 | 低レイヤー制御・軽量実行 | 中〜高 |
| LM Studio | Win/Mac/Linux | GUI | 0.4.15(Build 2)でCUDAテンソル並列対応 | GUIで手軽に試す | 低 |
| vLLM | Linux中心(CUDA前提) | API/CLI | テンソル並列に標準対応 | 高スループットなAPI常駐 | 高 |
Ollamaはモデルの取得・切り替えが1コマンドで完結し、初めてのローカルLLMでもつまずきにくいエンジンです。内部はllama.cppを土台にしており、複数GPUがあればレイヤーを分割して自動配置します。llama.cppはその土台そのもので、最も低レイヤー。ビルドオプションやスレッド数まで自分で握りたい人に向きます。
LM StudioはGUIでモデル検索からチャットまで完結する手軽さが持ち味。今回のテンソル並列対応で、複数GPU構成での立ち位置が一段変わりました。vLLMはLinuxとCUDAを前提とした本番志向のエンジンで、APIサーバーとして常駐させ、複数リクエストをまとめて高速にさばく用途に強みがあります。
GUI重視か、スループット重視か
手軽さの頂点はLM StudioとOllamaです。前者は画面操作だけで完結し、後者はコマンド1つでモデルを呼び出せます。一方、限界までスループットを引き出したいならvLLM。バッチ処理やAPI常駐での同時リクエストさばきは、GUIツールでは届かない領域です。llama.cppはその中間で、軽さと制御の自由度を両取りしたい層に刺さります。
マルチGPU対応の有無が選定を分ける
複数GPUを持っているなら、ここが最大の分岐点。レイヤー分割なら多くのエンジンが対応しますが、テンソル並列はエンジンを選びます。テンソル並列は1つの層の計算を複数GPUで分担する方式で、うまく効けばメモリと計算の両方を束ねられます。llama.cpp自体がCUDA環境でテンソル並列に対応しており、LM Studio 0.4.15 Build 2は、このllama.cpp側のテンソル並列対応をGUI環境から扱いやすくしたアップデートです。
実測で見た速度とVRAM配分
速度の話を、まず数字で押さえておきます。当サイトの検証環境(RTX 5080単体・Ollama、2026-05-20計測)では、モデルサイズが上がるほどtokens/secは素直に下がりました。
| モデル | tokens/sec(Ollama実測) | VRAM使用量 |
|---|---|---|
| Mistral 7B(Ollama: mistral:7b) | 144.8 | 6.6GB |
| Llama 3.1 8B(Ollama: llama3.1:8b) | 131.6 | 7.0GB |
| Gemma 3 12B(Ollama: gemma3:12b) | 85.8 | 10.2GB |
| Qwen3 14B(Ollama: qwen3:14b) | 78.3 | 11.1GB |
| Gemma 4 26B(Ollama: gemma4:26b) | 28.0 | 15.1GB |
7B〜8Bクラスは130〜145 tokens/secと快適で、12B〜14Bでも80前後を維持しました。26BではVRAM 15.1GBに加えてCPUオフロードが発生し、28.0 tokens/secまで落ちました。16GB VRAMの実用上限が、ちょうどこのあたりに見えてきます。
ここで1つ断っておきます。上の数値はOllamaでの計測で、4エンジンを同一条件で並べたクロスベンチは実施していません。エンジン横断の速度差は、各エンジンの特性と公称仕様から述べる方針です。無関係なエンジンの数値を別エンジンの実測値として提示することは避けます。
VRAM配分の挙動も、エンジンで考え方が違います。レイヤー分割方式では、モデルの各層を順番に複数GPUへ割り当てるため、推論中はGPUが交代で動きがち。2枚目が「待ち」になりやすく、性能が足し算にならない場面があります。テンソル並列はこの待ちを減らす方向の技術で、だからこそマルチGPUでの伸びしろが語られます。
マルチGPU・テンソル並列の対応差|LM Studio 0.4.15が変えたこと
今回のアップデートの中身を整理します。LM Studio 0.4.15(Build 2)は5月29日にリリースされ、NVIDIAのCUDA環境でマルチGPUのテンソル並列処理に対応しました。この機能自体はNVIDIAが5月31日に正式発表したもので、複数GPU環境で最大2倍のメモリ容量と1.8倍の計算能力を実現できるとされています。
NVIDIAの発表によれば、マルチGPU環境のテンソル並列処理で最大2倍のメモリ容量と1.8倍の計算能力を実現できる(出典は記事末尾の参考資料)。
ここで押さえるべきは、これが「複数GPU構成でのみ意味を持つ差分」だという点。単一GPUではテンソル並列の恩恵は出ません。RTX 5080+RTX 5060 Ti のように2枚挿しの環境で初めて、メモリと計算を束ねる効果が効いてきます。手元が1枚なら、今回の目玉機能は実質関係しないと考えてよいでしょう。
主要な変更点を旧バージョンとの対比で並べておきます。
| 変更カテゴリ | 変更前 | 変更後 | 影響度 |
|---|---|---|---|
| マルチGPU処理 | レイヤー分割が中心 | CUDAでテンソル並列に対応 | 大(複数GPU環境) |
| バッチ設定 | 物理バッチサイズの詳細指定なし | 詳細ロードオプションを追加 | 中 |
| エンジン更新 | 更新頻度が限定的 | Engine Protocol Beta 2で頻繁な更新が可能(Build 1) | 中 |
| 安定性 | 既知の不具合あり | バグ修正を実施 | 小 |
物理バッチサイズの詳細ロードオプションが加わったことで、VRAMと速度のバランスを手元で調整しやすくなりました。バッチを大きくすればスループットは伸びますが、その分VRAMを食います。16GBクラスのGPUでは、ここを詰めすぎるとメモリ不足で落ちる点に注意してください。Build 1で導入された「LM Studio Engine Protocol Beta 2」は、エンジン部分をアプリ本体と切り離して頻繁に更新できる仕組み。新しいモデルや高速化への追従が速くなる土台です。
テンソル並列が活きる構成・活きない構成
テンソル並列が活きるのは、同等クラスのGPUを複数枚揃えた構成。GPU間の連携が増えるため、帯域の細い接続だと効果が削られる場合もあります。当サイトの検証環境(RTX 5080+RTX 5060 Ti のデュアル構成)はGPUの世代こそ揃うものの、CUDAコア数や帯域に差があるため、性能が完全な足し算になるとは限りません。単一GPUユーザーや、種類の異なるGPUを混在させた構成では、今回の機能を理由にアップデートを急ぐ必要は薄いといえます。
運用しやすさ|導入・モデル取得の安定性・メモリ容量の壁
速度や機能と並んで効いてくるのが、運用の安定性です。ここではOllamaのモデル取得まわりと、ハード側のメモリ容量という2つの現実的な論点を扱います。
Ollamaは手軽な反面、一部モデルでpull(取得)に失敗する場面が報告されています。当サイトの検証環境でも、特定の12B〜14Bクラスのモデルで取得が止まる現象を確認しました。原因は単発の障害ではなく、レジストリ側の構造要因にあるケースが多い。具体的には、配信に使われるCloudflare R2経路の不安定さ、タグの廃止(deprecation)、manifest(モデル構成情報)の不整合などです。Ollama公式リポジトリにも、特定モデルの実行に関する既知のissueが立っています。
pull失敗を切り分ける手順
原因の切り分けは、blob URLを直接叩いて確認する方法が手早いです。エラーに出てくるblobのURLを curl -L で取得し、R2へのリダイレクトが正常に返るかを見ます。ここで失敗するなら配信経路側の問題、manifestの取得段階で止まるならタグやmanifest不整合の疑い、と当たりをつけられます。ディスク容量やプロキシ設定が原因のこともあるため、空き容量とネットワーク設定もあわせて確認してください。
GGUF直importという回避ルート
レジストリ経由の取得が安定しないときは、モデルを別ルートで持ってくる手があります。Hugging FaceからGGUF形式のファイルを取得し、ollama create -f Modelfile でローカルにimportする方法です。Modelfileに取得したGGUFのパスを指定して登録すれば、pullを介さずに同じモデルを動かせます。当サイトの検証環境でも、この直importでRTX 5080上での実行を確認できました。手間は増えますが、配信経路に依存しないぶん安定して再現できるのが利点です。
ハード側の論点として、動かせるモデルの規模はメモリ容量で上限が決まります。ここはGPUのVRAMで載せるNVIDIA系(VRAM分離型)と、CPUとGPUで大容量メモリを共有する統合メモリ型で考え方が分かれます。
VRAM分離型は、テンソル並列で複数GPUのメモリを束ねられる点が強み。RTX 5080(VRAM 16GB)とRTX 5060 Ti(VRAM 16GB)のように個別に16GBずつ持つGPUを連携させ、より大きなモデルへ手を伸ばせます。一方の統合メモリ型は、大容量メモリを積みやすく、大型モデルを1台で載せやすい反面、メモリ帯域やソフトウェアエコシステムにトレードオフがあります。海外のRedditコミュニティ(r/LocalLLaMA)でも、大容量の統合メモリ構成なら120bクラスの大型モデルを実行できたという報告がある一方、用途次第で最適解は変わるという議論が続いています。どちらが上というより、束ねるか・載せるかの方針の違いと捉えるのが現実的です。
用途別の使い分け結論|ご自身の構成から逆引きする
ここまでの3点を、構成別の結論に落とし込みます。
手軽に試したい、まず動かしたいならLM StudioかOllama。GUIで完結させたいならLM Studio、コマンド操作とモデル管理の軽さを取るならOllamaが向きます。最軽量で低レイヤーまで握りたい、あるいは独自ビルドで詰めたいならllama.cpp。APIサーバーとして常駐させ、複数リクエストを高速にさばく本番運用ならvLLMが本命です。
単一GPUユーザーの最適解
GPUが1枚なら、テンソル並列の恩恵は基本的に出ません。優先すべきは手軽さと速度のバランスで、LM StudioかOllamaが扱いやすい入口になります。16GB VRAMのGPUなら、実測でも12B〜14Bクラスまでは快適に動きました。それ以上を狙うなら量子化を効かせ、VRAMに収まる範囲で運用するのが現実的です。
デュアルGPU・本番運用の最適解
複数GPUを束ねて使うなら、テンソル並列に対応するエンジンが候補。本番でAPIを叩くならvLLM、GUIで手軽に複数GPUを試すなら今回対応したLM Studio 0.4.15という住み分けになります。RTX 5080+RTX 5060 Ti のようなデュアル構成では、GPU間の性能差や接続帯域が効果を左右するため、テンソル並列をオンにして実際に伸びるかを確かめてから常用設定を決めるのが堅い進め方です。Ollamaでのデュアル運用や、2枚目が遊んでしまう挙動については別記事で扱っています。
よくある質問
Q. マルチGPUにすれば、どのエンジンでも速くなりますか?
いいえ。速くなるかどうかはエンジンと構成に依存します。テンソル並列に対応したエンジン(LM Studio 0.4.15以降やvLLMなど)と、連携できる複数GPUが揃って初めて効果が出ます。レイヤー分割方式では2枚目が待ちになり、性能が足し算にならない場面もあります。
Q. Ollamaでモデルのpullに失敗したらどうすればよいですか?
まずエラーに出るblob URLをcurl -Lで叩き、配信経路(R2リダイレクト)かmanifestのどちらで止まるかを切り分けます。配信側が不安定なら、Hugging FaceからGGUFを取得してollama create -f Modelfileでimportする回避ルートが有効です。当サイトの検証環境でも直importでの実行を確認しています。
Q. vLLMはWindowsで動きますか?
vLLMはLinuxとCUDAを前提とした構成が基本です。Windowsで使う場合はWSL2などのLinux環境を介する形が現実的で、手軽さよりスループットを取りにいくエンジンと考えてください。GUIで手軽に複数GPUを試したいなら、Windows対応のLM Studioが扱いやすい選択肢になります。
Q. RTX 5080単体ではどのくらいのモデルまで動きますか?
当サイトのOllama実測では、12B〜14Bクラスで80前後のtokens/secを維持し、26BになるとVRAM使用量が15.1GBに達して速度も28前後まで落ちました。VRAM 16GBの実用上限は、量子化を前提にすればおおむねこのあたりです。
まとめ
4エンジンは、手軽さ・速度・マルチGPU対応の3点で住み分かれます。手軽さ重視ならLM StudioかOllama、最軽量・低レイヤー制御ならllama.cpp、本番スループットと複数GPUのテンソル並列ならvLLMかLM Studio 0.4.15、という整理です。
今回のLM Studioのテンソル並列対応は、複数GPU構成でこそ効く差分でした。単一GPUなら急いで設定を変える必要は薄く、デュアル構成なら実際に伸びるかを試してから常用へ。運用面ではOllamaの取得安定性をGGUF直importで補える点、動かせるモデル規模がメモリ容量で決まる点も判断材料に入れてください。ご自身の構成(単GPU/デュアル/統合メモリ)から逆引きすれば、選ぶべき1つは絞り込めます。まずは手元のGPU枚数を起点に、今日の用途へ合うエンジンを1つ決めてみてください。
| Ollama | Win/Mac/Linux対応。レイヤー分割・スケジューリングで複数GPU可(明示的なテンソル並列指定はLM Studio/vLLMとは性格が異なる)。手軽な常用・モデル管理向け |
|---|---|
| llama.cpp | Win/Mac/Linux対応。レイヤー分割に加えCUDA環境ではテンソル並列にも対応。低レイヤー制御・軽量実行向け |
| LM Studio | Win/Mac/Linux対応。0.4.15(Build 2)でCUDAテンソル並列に対応。GUIで手軽に試す用途向け |
| vLLM | Linux中心(CUDA前提)。テンソル並列に標準対応。高スループットなAPI常駐向け |
| 検証環境GPU | RTX 5080(VRAM 16GB)+RTX 5060 Ti(VRAM 16GB)の各個別16GB |
参考資料
- LM Studio 公式サイト: リリースノートとダウンロード
- NVIDIA Technical Blog: Accelerating LLMs with llama.cpp on NVIDIA RTX Systems(llama.cppのテンソル並列対応)
- NVIDIA Technical Blog: Build Personal AI Agents on Windows PCs(Microsoft・NVIDIA、LM Studioでのテンソル並列有効化)
- Ollama 公式 GitHub: モデル実行に関する Issue #11598
- vLLM 公式ドキュメント: テンソル並列とサーバー運用
当サイトはAmazonアソシエイト・プログラムの参加者です。Amazonのアソシエイトとして、当サイトは適格販売により収入を得ています。

