ローカルLLM推論環境比較2026｜LM Studio・Ollama・FreeToken・vLLMを用途別に選ぶ

※ 記事中にプロモーション広告（アフィリエイトリンク）が含まれます。

先に注意：この記事は、同一モデル・同一量子化・同一コンテキスト・同一プロンプトによる性能ベンチマークではありません。LM Studio、Ollama、FreeToken、vLLMについて、異なるモデル規模と異なる環境で確認した結果を整理したものです。ユーザー名、IPアドレス、ファイルパスは構成例なので、ご自身の環境に合わせて読み替えてください。

ローカルLLMを動かすには、モデルをダウンロードするだけでは足りません。モデルの構造を理解してGPUやRAMを扱う推論環境（推論エンジン）を選ぶことが、速度、扱えるモデル、使い勝手に直結します。

2026年時点の主要なローカルLLM推論環境について、導入方法、操作性、API、対応モデル形式、ハードウェア要件、得意な用途、そして今回どこまで確認できたかを整理しました。この記事の目的は、読者が自分の用途に合う環境を選べるようにすることです。

先に結論：用途によって選ぶ環境は変わる

勝者を1つ決める話ではありません。まずは用途から逆引きできる表を置いておきます。

以降で、比較条件、各環境の特徴、確認できた範囲、選び方の順に詳しく説明します。

この記事の比較条件と注意点

• 同条件ベンチマークではない
• 使用モデルの規模と形式が異なる
• tok/sの横並び比較は行わない
• 実測済み、手順確認済み、未測定を分けて記載する

確認状況は、次の3段階で表記します。

ローカルLLM推論環境とは

推論環境は、モデルファイルを読み込み、GPUやCPUへ計算を割り当て、生成したトークンを返す役割を担当します。チャット画面はその入口に過ぎません。

推論環境がなぜ必要か

モデルファイルはパラメータの集合体です。これを実際に動かすには、モデルの構造を理解し、GPUとRAMを効率よく使うソフトウェアが必要になります。環境を変えると、次の点が変わります。

• 速度：1秒あたりに生成できるトークン数
• 回答の傾向：量子化形式や推論精度の扱い
• 導入のしやすさ：GUIかCLIか、必要なランタイム
• メモリの使い方：VRAMだけか、システムRAMやPCIeも使うか
• 対応形式：GGUF、NVFP4、MXFP4、FP8、BF16など
• API：OpenAI互換か、独自APIか、Anthropic互換か

VRAMの必要量は固定値ではない

「この環境なら何GB必要」と固定値を書くことはできません。必要量は次の項目によって変わります。

• モデルとパラメータ数
• Dense（通常モデル）かMoEか
• 量子化形式
• コンテキスト長とKVキャッシュ
• 同時に処理するバッチ数
• GPUオフロード、CPUオフロードの設定
• システムRAMの容量

同じGPUでも、量子化とコンテキスト長を変えるだけで扱えるモデルの大きさは変わります。この記事ではVRAMの下限値を断定しません。

今回確認したハードウェア

もう1つは、自宅のProxmox VEで運用しているAIサーバーです。GTX 1070 8GBをPCIパススルーしたUbuntu Server VM300で、FreeToken-PascalとQwen3.6 35B A3B NVFP4を動かしています。

GPUを選ぶときは、VRAM容量だけでなく、世代、Compute Capability、対応する量子化形式を合わせて確認してください。今回のRTX 3060 12GBは、12GBというVRAM容量を基準に選んだカードです。

GIGABYTE NVIDIA GeForce RTX3060 搭載 グラフィックボード GDDR6 12GB 搭載モデル ギガバイト 【国内正規代理店】 GV-N3060WF2OC-12GD

GIGABYTE

amazonレビューをチェック！

• Amazonで探す
• 楽天市場で探す
• Yahooショッピングで探す

VRAMが足りない分をCPUとシステムRAMで補う構成も選べますが、その場合はPCIe帯域とメモリ帯域も効いてきます。カード単体の数字だけで決まらないところが、ローカルLLMの難しいところですね。

4つの推論環境を用途別に比較

主要な比較軸をまとめます。ここでも速度の横並び比較はしません。列が多いため、操作性とAPIの表、導入と確認状況の表に分けています。

導入難度は環境と前提で変わります。「何分で導入できるか」のような断定はしません。同じ環境でも、ドライバー、CUDA、Python、モデルの入手元によって手間は変わります。

LM Studio：GUIとローカルAPI

LM Studioは、モデルの検索、ダウンロード、ロード、チャットをGUIで操作できる環境です。チャット専用ではなく、ローカルAPIサーバーとしても使えます。

公式ドキュメントでは、OpenAI互換のエンドポイントとして/v1/models、/v1/responses、/v1/chat/completions、/v1/embeddings、/v1/completionsが案内されています。接続先の例はhttp://localhost:1234/v1です。トークン毎秒やTTFTといった統計はREST API v0側で確認できます。

# ローカルサーバーの起動例（アプリの画面から開始してもよい）
lms server start

# OpenAI互換エンドポイントへ問い合わせる例
curl http://localhost:1234/v1/models
curl http://localhost:1234/v1/chat/completions -H "Content-Type: application/json" -d '{"model":"使用するモデルID","messages":[{"role":"user","content":"Say this is a test"}]}'

LM Studioの確認状況

Windows 11 Pro環境（RTX 3060 12GB）で、モデルの検索、ダウンロード、ロード、チャット、APIサーバー機能を確認しました。速度とVRAM使用量は記録していません。「実測済み」ではなく「手順・起動確認済み」として扱います。

2Bから7Bという限定はしません。実際に扱えるモデル規模は、VRAM、システムRAM、量子化形式、GPUオフロードの設定によって変わります。

Ollama：CLIとモデル管理

Ollamaは、CLIとAPIを中心に扱いやすい環境です。モデルの取得と管理が簡単で、ローカルサーバーとして公開できます。ローカルサーバーの既定ポートは11434です。

公式ドキュメントには「OllamaはOpenAI APIのサブセット（一部）をサポートする」と記載されています。つまり完全なOpenAI API互換ではありません。独自APIとOpenAI互換エンドポイントは別物として扱ってください。

OpenAI互換エンドポイントはhttp://localhost:11434/v1/です。公式のサンプルではapi_keyにollamaのような値を渡していますが、これはクライアント側が要求するためで、ローカルサーバーでは無視される場合があります。

# モデルの取得と実行
ollama run llama3

# サーバーとして起動
ollama serve

# OpenAI互換エンドポイントの確認
curl http://localhost:11434/v1/chat/completions -H "Content-Type: application/json" -d '{"model":"llama3","messages":[{"role":"user","content":"Say this is a test"}]}'

Ollamaの確認状況

Windows 11 Pro環境で、導入、モデルのダウンロード、モデルの起動、API公開を確認しました。速度とVRAM使用量は記録していません。こちらも「手順・API確認済み」として扱います。

7Bから8B専用という限定もしません。扱えるモデル規模は、GPU、RAM、量子化形式に依存します。

FreeToken：VRAM超えのMoEを扱う

FreeTokenは、MoE（Mixture of Experts）モデルを、GPU、CPU、システムRAM、PCIeを組み合わせて扱う推論環境です。VRAMへ収まらないモデルを動かすことが主な特徴で、Expertキャッシュの一部をGPUに置き、残りをCPU側で処理します。

公式ドキュメントでは、サーバーはOpenAI API（/v1/chat/completions、/v1/responses、/v1/models）とAnthropic API（/v1/messages、/v1/messages/count_tokens）を提供すると記載されています。既定の待ち受けは127.0.0.1:1919です。キャッシュ方式はradixが既定で、MoEの扱いはfused、offload、cpu、hybridから選べます。

インストール要件も公式に明記されています。CLI版はLinux x86_64、NVIDIA GPU、ドライバーr580以降（CUDA 13）、Python 3.10以降が前提で、初回利用時にCUDAカーネルがJITコンパイルされます。Windows中心の環境では、この要件を先に確認してください。

# インストール（uv推奨）
uv venv && source .venv/bin/activate
uv pip install "freetoken[accel]"

# サーバー起動と確認
ft serve --model ~/models/Qwen3.6-35B-A3B
curl http://127.0.0.1:1919/v1/models

RTX 3060 12GBのDesktop版確認

Windows 11 Pro（RTX 3060 12GB）では、FreeToken Desktop版の動作を確認しました。GUIでモデルを読み込み、チャットとAPIの導線を確認できる範囲です。詳しい手順と画面は、既存のFreeToken解説記事で確認できた内容の範囲にとどめます。CLI版の要件（Linux x86_64）とは前提が異なる点に注意してください。

VM300でのPascal実測

FreeToken-Pascalは、FreeToken本家をPascal世代のGPUへ対応させるforkです。GTX 1070のsm_61やTesla P100のsm_60を対象に、pre-Volta環境でもJITカーネルをコンパイルできるよう調整されています。PascalではCUDAの__grid_constant__が使えないため、条件付きマクロでPascal側だけ指定を外し、Volta以降では本来の処理を維持する設計です。

この構成では、Proxmox VE上のUbuntu Server VM300へGTX 1070 8GBをPCIパススルーし、Qwen3.6 35B A3B NVFP4をAPIサーバーとして起動しました。APIは構成例として127.0.0.1:8082で待ち受け、/v1/modelsと/v1/chat/completionsを利用しています。

確認できたのは、Pascal向けJITカーネルのビルド、API Ready、/v1/modelsの応答、短い直接API、ストリーミング、OpenCode接続、構造化tool_calls、WebFetch、WebSearch、Radixキャッシュ、自動Compaction、SSHトンネルの自動再接続です。

ここまで一気に動いたわけではありません。Pascal向けJITカーネルのビルドに加えて、hc.pyのLinear処理でBFloat16入力とHalf重みのdtype不一致が発生しました。さらに、明示した--moe-cache-size 0が内部的にmoe_cache_auto=Trueへ変換される問題があり、args.pyを局所修正して明示的な0を尊重するようにしています。修正後は回帰テスト63件がPASSし、その後に/v1/models、API Ready、OpenCode接続まで到達しました。

性能値は次のとおりです。短い直接APIは1回目が約4.01秒（prompt tokens 17、completion tokens 2）、2回目が約2.36秒でした。ストリーミングはHTTP 200で、time_starttransferが約0.027秒、time_totalが約2.346秒です。同一prefixのRadixキャッシュ試験では、1回目41秒（new-token 310、cached-token 0）から2回目13秒（new-token 54、cached-token 256）へ短縮し、約68％の改善を確認しました。

ただし、FreeTokenが常に数秒で答えるわけではありません。OpenCode経由のWebFetchでは、最終回答まで約8分56秒かかった例があります。WebFetch自体は成功しており、その後のPrefillが4,680トークン、cached-tokenは0でした。ツール定義、ドキュメント、Web取得結果、会話履歴が入力へ加わると、キャッシュが効かずPrefillが重くなります。

整理すると、短い直接APIとストリーミングは数秒、同一prefixではRadixキャッシュが効く、cache miss時のPrefillは重い、OpenCodeでは数分かかる場合がある、という挙動です。GTX 1070で35Bモデルが爆速という話ではありません。

GTX 1070のTDPは150Wで、長時間の連続推論では電力と冷却の余裕も効いてきます。電源ユニットに余裕がないと、負荷が上がった瞬間に再起動やスロットリングが起きることがあります。

MSI MAG A850GL PCIE5 WHITE PC電源ユニット 850W ATX3.1/PCIe 5.1対応 80PLUS GOLD認証 フルモジュラー 7年保証 PS1368

MSI

amazonレビューをチェック！

• Amazonで探す
• 楽天市場で探す
• Yahooショッピングで探す

古いGPUを再利用する場合も、電源、冷却、PCIeスロットの世代と幅を合わせて見ておくと、切り分けが楽になります。

vLLM：高スループットAPIサーバー

vLLMは、高スループットのAPIサービングに強い推論環境です。Continuous Batchingと効率的なKVキャッシュ管理を利用できるため、複数リクエストを同時にさばく用途に向いています。70B以上専用ではなく、モデル次第で小型から大型まで扱えます。

公式のインストールガイドでは、OSはLinux、Pythonは3.10から3.13、NVIDIA GPUはCompute Capability 7.5以上が案内されています。また「vLLM does not support Windows natively（Windowsをネイティブサポートしない）」と明記され、Windowsで使う場合はWSLかコミュニティforkが案内されています。NVIDIA以外にもAMD ROCm、Intel XPU、Apple Silicon（vLLM-Metal）の選択肢があります。

vLLMの確認状況（今回は未測定）

今回のRTX 3060 12GB・Windows環境では、vLLMについて比較条件を揃えた測定を行っていません。したがって未測定として扱います。

RTX 3060のCompute Capabilityは要件を満たしますが、OSがWindowsであること、モデル規模、コンテキスト長、量子化形式の条件が合わず、今回の構成では70Bクラスのモデルを起動できませんでした。これはvLLM自体が使えないという意味ではなく、公式要件と今回の環境が合わなかったという整理です。Linuxと対応GPUを用意できれば、検討する価値は十分あります。

# Linux環境での起動例
uv venv --python 3.12 --seed --managed-python
source .venv/bin/activate
uv pip install vllm
vllm serve <モデル名またはパス> --port 8000

OpenAI互換APIの違い

「OpenAI互換」と一言で言っても、対応するエンドポイントの範囲は環境ごとに異なります。比較しやすいように表にまとめます。

接続時にapi_keyを求められる場合でも、ローカルサーバーでは値が無視される場合があります。また、互換と名乗っていても、対応するパラメータやレスポンスの項目は環境ごとに差があります。クライアント側の機能を使う前に、公式ドキュメントで対応範囲を確認してください。

モデル形式と量子化形式の違い

量子化は、モデルの精度を一部落として、メモリ使用量と計算量を減らす技法です。ここで混同しやすいのが、GGUFのQ4_K_MとNVFP4のような別方式です。

• GGUFのQ4_K_M：llama.cpp系のランタイムで扱われる形式で、LM StudioやOllamaで使われることがあります
• NVFP4：今回のFreeToken-Pascal構成で使用した形式です
• MXFP4、FP8、BF16：FreeTokenが扱う形式の例です

量子化方式が違えば、ファイル形式、必要なランタイム、GPU要件、速度、メモリ使用量も変わります。今回のFreeToken-Pascalで確認したモデルは、Qwen3.6 35B A3B NVFP4 candidateです。GGUF Q4_K_MとNVFP4を同じ量子化形式として扱うことはできません。

MoE（Mixture of Experts）

MoEモデルは、パラメータを複数のExpertへ分け、入力ごとに一部のExpertだけを計算します。総パラメータが大きくても、1トークンあたりの計算量を抑えられる設計です。ただし、モデル全体の重みはVRAM、システムRAM、ストレージのどこかに保持する必要があります。

そのため、VRAMへ収まらないMoEモデルでは、システムRAMの容量が扱えるモデルの余裕につながります。増設する場合は、マザーボードの対応規格とスロット数、ホスト側に残す分を合わせて確認してください。

CFD販売 デスクトップPC用メモリ DDR5-5600 (PC5-44800) 16GB×2枚 (32GB) 相性保証 288pin シー・エフ・デー販売 CFD Standard W5U5600CS-16G

シー・エフ・デー販売

amazonレビューをチェック！

• Amazonで探す
• 楽天市場で探す
• Yahooショッピングで探す

メモリを増やしても、GPU側の計算が速くなるわけではありません。ボトルネックがPrefillにあるのか、Expert転送にあるのか、PCIeにあるのかを切り分けてから増設を検討すると無駄がありません。

導入難度を比較

難度は「起動して動かすまで」の目安です。実運用では、ログの確認、キャッシュ設定、量子化形式の選定、ドライバー更新の影響確認が加わります。

ローカル推論のプライバシーと外部通信

ローカル推論の利点は、推論先をローカルAPIだけに限定できることです。プロンプトをクラウドのLLMへ送らずに運用できます。

ただし「ローカルLLMなら完全オフライン」「情報が絶対に外へ出ない」とは言えません。次の要素は外部通信する可能性があります。

• モデルのダウンロード
• ソフトウェアの更新確認
• Gitの操作
• WebFetch、WebSearch
• MCPサーバー
• プラグインや拡張機能
• 外部APIとの連携
• テレメトリ
• ライセンス確認
• クラウドモデルの利用

推論そのものをローカルへ閉じ込めつつ、どこで外へ出るかを把握しておくのが現実的です。エージェント用途ではWeb取得が入りやすく、その分だけ入力トークンも増えます。

用途別の選び方

LM Studioが向く人

• GUIを使いたい
• モデルを検索して手軽に試したい
• チャットとローカルAPIを同じアプリで使いたい
• 初めてローカルLLMを試す

Ollamaが向く人

• CLIで簡単にモデル管理したい
• APIをすぐ公開したい
• 開発ツールやスクリプトと連携したい
• ModelfileやOllamaのライブラリを使いたい

FreeTokenが向く人

• VRAMに収まりにくいMoEモデルを扱いたい
• GPU、CPU、RAM、PCIeを組み合わせたい
• Qwen3.6などの大型MoEを試したい
• OpenAI互換APIをOpenCodeなどへ接続したい
• 起動調整やログ確認ができる

FreeToken-Pascalが向く人

• GTX 10シリーズ、Tesla P100などPascal世代を再利用したい
• 本家の対応範囲外のGPUを試したい
• ソースビルド、JIT、パッチ、回帰テストを自分で扱える
• 実験的な構成を理解して運用できる

vLLMが向く人

• 複数ユーザーまたは複数リクエストを扱う
• 高スループットのAPIサーバーが必要
• Linuxと対応GPUを用意できる
• コンテナ、CUDA、モデルサービングを管理できる

確認できたこと・高確率・未確認

記事内の情報を、確からしさで分けておきます。

ローカルLLM推論環境のよくある質問

まとめ

2026年時点の主要なローカルLLM推論環境を、導入方法、操作性、API、対応モデル形式、ハードウェア要件、得意な用途、確認状況の観点で整理しました。同条件の性能ベンチマークではないため、tok/sの横並び比較はしていません。

今回の確認では、LM StudioとOllamaは手順とAPIの確認まで、FreeTokenはRTX 3060のDesktop版とVM300のFreeToken-Pascalで実測まで、vLLMは未測定という整理になりました。FreeToken-Pascalでは、Pascal向けJITカーネル、dtype不一致、MoEキャッシュ設定を一つずつ切り分け、API Ready、tool calling、WebFetch、WebSearch、Radixキャッシュ、自動Compactionまで到達しています。

短い直接APIは数秒で返りますが、OpenCodeのように文書やWeb結果が入力へ加わる使い方では数分かかる場合があります。用途と入力の大きさをセットで見ておくと、期待値のずれを避けられます。

推論先をローカルAPIだけに限定すれば、クラウドLLMへプロンプトを送らない構成にできます。ただしモデル取得、更新確認、Web取得、プラグインなどは外部通信する可能性があるため、どこで外へ出るかを把握したうえで使ってください。

参考資料

• LM Studio 公式ドキュメント（ローカルサーバー）
• LM Studio 公式ドキュメント（OpenAI互換エンドポイント）
• Ollama 公式ドキュメント
• Ollama 公式ドキュメント（OpenAI互換の範囲）
• FreeToken GitHubリポジトリ
• FreeToken-Pascal GitHubリポジトリ
• vLLM 公式インストールガイド
• FreeToken-PascalでGTX 1070 8GBな古めグラボでQwen3.6 35Bが動作！自作AIサーバでローカルLLMバイブコーディング術
• FreeTokenでローカルLLMが超進化！RTX 3060 12GB + 32GB RAMで大型MoEを動作させてみた

公開前の確認：Classic Editorのテキストタブへ貼り付けた後、公開前にビジュアルタブとの往復でコード、URL、引用符、JSONが変更されていないか確認してください。