TL;DR

  • ローカル LLM は ランタイム（実行環境） と モデル を分けて選ぶと整理しやすいです。
  • Foundry Local はアプリに組み込む単一ユーザー向けのオンデバイス AI。ONNX Runtime ベースで GPU/NPU/CPU を自動選択し、OpenAI 互換 API を備えます。Azure サブスクリプションは不要です。
  • Ollama / LM Studio は手軽さ重視（CLI・GUI）、llama.cpp は低レベルで移植性が高い基盤、vLLM は多人数・本番サーバー向けの高スループット推論です。
  • モデルは Phi・Llama・Qwen・Gemma・DeepSeek・gpt-oss・Mistral が定番。多くは量子化（GGUF / ONNX）で軽量化して動かします。
  • 「単一ユーザーで端末内完結」なら Foundry Local、「とにかく手軽に試す」なら Ollama/LM Studio、「多人数に配信」なら vLLM が目安です。

1. はじめに

クラウドの大型 LLM はパワフルですが、すべての処理をクラウドに流すと トークン課金・レイテンシ・データの外部送信 が課題になります。意図分類や要約のような軽い処理、機密データを扱う処理、オフライン環境での処理では、ローカル LLM が有力な選択肢になります。

一方で「ローカル LLM」と一口に言っても、実行環境（ランタイム）もモデルも多種多様です。本記事では全体像を俯瞰し、迷わず選べる地図を提供します。なお Phi-4 を使ったローカル×クラウドのハイブリッド構成は ローカル LLM × Azure エージェント で詳しく扱っています。

2. ローカル LLM は「ランタイム」と「モデル」を分けて考える

ローカル LLM の構成は、おおまかに次の 4 層に分かれます。重要なのは、ランタイムとモデルは別々に選べるという点です。多くのランタイムは複数のモデルを動かせ、同じモデルが複数のランタイムで動きます。

ローカル LLM の 4 層スタック。上からアプリ／チャット UI、実行ランタイム（Foundry Local・Ollama・LM Studio・llama.cpp・vLLM）、モデルと量子化形式（Phi・Llama・Qwen ほか、GGUF / ONNX）、ハードウェア（CPU・GPU・NPU）。ランタイムとモデルは別軸で選べることを示す図

  • アプリ層: チャット UI やエージェントなど、LLM を利用する側。
  • ランタイム層: モデルを読み込み、推論を実行する実行環境。本記事の比較対象です。
  • モデル層: Phi や Llama などの重み。多くは 量子化（後述）して配布されます。
  • ハードウェア層: CPU・GPU・NPU。ランタイムが最適な実行先を選びます。

3. 主要なローカル LLM 実行環境（ランタイム）の比較

3.1. Foundry Local（Microsoft）

Foundry Local は、Microsoft が提供する エンドツーエンドのオンデバイス AI ソリューションです。アプリケーションに組み込むネイティブライブラリ（Core API）として動作し、モデルの取得・ハードウェア高速化・推論をアプリのプロセス内で完結させます。ランタイムは約 20MB と軽量で、ONNX Runtime を基盤とします。

主な特徴は次のとおりです。

  • 厳選モデルカタログ: チャット用に GPT OSS・Qwen・DeepSeek・Mistral・Phi、音声書き起こしに Whisper を収録。各モデルは量子化・圧縮され、バージョン管理されます。
  • 自動ハードウェア高速化: 端末のハードウェアを検出し、最適な実行プロバイダー（CUDA・WebGPU・Qualcomm/AMD/Intel の NPU など）を自動選択。GPU/NPU がなければ CPU にフォールバックします。
  • OpenAI 互換 API: OpenAI SDK のコードをほぼそのまま流用できます。必要に応じて OpenAI 互換のローカル REST サーバーも起動でき、LangChain や Open WebUI と連携できます。
  • SDK は 4 言語: C#・JavaScript・Python・Rust。Windows 版は Windows ML と統合し、より広いハードウェアアクセラレーションに対応します。
  • 対応プラットフォーム: Windows・macOS（Apple Silicon）・Linux。Azure サブスクリプションは不要で、初回ダウンロード後はオフラインで動作します。

設計思想として、Foundry Local は 単一ユーザーがアプリ内で使うシナリオに最適化されています。多人数の同時推論をサーバーで捌く用途には、後述の vLLM などを使い分けます。

3.2. Ollama

Ollama は、ローカル LLM を最も手軽に動かせるツールの一つです。ollama run <model> のワンコマンドでモデルの取得から対話までを完結でき、OpenAI 互換の REST API も提供します。OpenClaw・Claude Code・Codex などのエージェント／ツールとの連携例が豊富で、ローカルで動かしつつ必要に応じてクラウドの大型モデルへスケールする選択肢も用意されています。手軽さと OSS エコシステムの広さが魅力です。

3.3. LM Studio

LM Studio は、GUI 中心でモデルの検索・ダウンロード・チャットができるデスクトップアプリです。家庭利用・業務利用ともに無料で、プログラミング不要で試せる敷居の低さが特徴です。開発者向けには JavaScript / Python SDK、lms CLI、OpenAI 互換 API、Apple の MLX エンジン対応、GUI なしでサーバー／CI に展開する llmster も提供されます。「まず触ってみたい」非エンジニアから開発者まで幅広く使えます。

3.4. llama.cpp

llama.cpp は、依存のない C/C++ 実装でローカル推論を実現する OSS 基盤です（GitHub で 11 万スター超）。Apple Silicon（Metal）、NVIDIA（CUDA）、AMD（HIP）、Vulkan、SYCL など極めて広範なバックエンドに対応し、1.5〜8 ビットの整数量子化で省メモリに動かせます。モデルは GGUF 形式を使い、llama-cli（対話）と llama-server（OpenAI 互換 HTTP サーバー）を提供します。Ollama や LM Studio など多くのツールが内部で利用する、エコシステムの土台でもあります。低レベルで柔軟に制御したい場合の第一候補です。

3.5. vLLM

vLLM は、多人数・本番サーバー向けの高スループット推論エンジンです（GitHub で 8 万スター超、Apache-2.0）。PagedAttention・連続バッチング・プレフィックスキャッシュなどにより、多数の同時リクエストを効率よく捌きます。Hugging Face の 200 以上のモデルアーキテクチャに対応し、OpenAI 互換 API に加えて Anthropic Messages API・gRPC もサポートします。GPU を備えたサーバーで「社内・サービス向けに LLM を配信する」用途に適します。

3.6. 比較表

ランタイム 主な形態 想定利用者 同時利用 API 代表的な強み
Foundry Local アプリ組み込み SDK + 任意のローカルサーバー アプリ開発者 単一ユーザー OpenAI 互換 ONNX Runtime と NPU/GPU 自動選択、配布のしやすさ
Ollama CLI + ローカルサーバー 開発者・個人 単一〜少数 OpenAI 互換 圧倒的な手軽さとエコシステム
LM Studio GUI アプリ + SDK 非エンジニア〜開発者 単一〜少数 OpenAI 互換 GUI でモデル探索・チャットが完結
llama.cpp ライブラリ + CLI/サーバー 開発者・組み込み 単一〜少数 OpenAI 互換 移植性と量子化、エコシステムの基盤
vLLM サーバー プラットフォーム運用 多人数 OpenAI 互換 ほか 本番のスループットと並列処理

4. ローカルで動く主要なオープンモデル

ランタイムを決めたら、動かすモデルを選びます。2026 年時点でローカル実行の定番となっている主なオープンモデル（オープンウェイト）は次のとおりです。多くは数 B〜十数 B パラメータの 小規模言語モデル（SLM） で、量子化すればコンシューマー向けハードウェアでも動きます。

モデル 提供元 特徴
Phi Microsoft 小規模ながら推論・数理に強い SLM。phi-4-mini などエッジ向け軽量版あり
Llama Meta ローカル LLM 普及の立役者。派生モデルとツール対応が豊富
Qwen Alibaba 多言語・コーディングに強く、軽量版から幅広いサイズを展開
Gemma Google 軽量で扱いやすく、品質とサイズのバランスが良い
DeepSeek DeepSeek 推論特化（R1 系）。蒸留版は小サイズでも高い推論力
gpt-oss OpenAI OpenAI のオープンウェイトモデル。MXFP4 量子化に対応
Mistral / Mixtral Mistral AI 高効率。Mixtral は MoE（Mixture-of-Experts）構成

どれを選ぶかは「タスクの種類（チャット・コード・推論）」「必要な品質」「動かせるサイズ」で決めます。まずは軽量モデルで動作確認し、品質が足りなければ大きめのモデルへ段階的に上げるのが安全です。

5. 量子化とハードウェア要件の基礎

ローカル実行で避けて通れないのが 量子化 です。量子化はモデルの重みを 16 ビット浮動小数点から 8/4 ビットなどの低精度へ圧縮し、メモリ使用量と必要 VRAM を削減して推論を高速化します。代表的な形式に、llama.cpp 系で使う GGUF と、Foundry Local（ONNX Runtime）が使う ONNX があります。

ハードウェアの目安は次のとおりです。

  • CPU のみ: どの環境でも動きますが、サイズが大きいモデルは低速。軽量モデル向け。
  • GPU（VRAM）: 量子化したモデルサイズが VRAM に収まると快適。4 ビット量子化なら必要 VRAM を大きく減らせます。
  • NPU: 省電力で推論を高速化。Foundry Local は Qualcomm・AMD・Intel の NPU に対応する実行プロバイダーを自動選択します。

「量子化後のモデルサイズが、利用可能なメモリ（VRAM）に収まるか」が、まず確認すべき最重要ポイントです。

6. ユースケース別の選び方

ランタイム選びは、次の問いに答えると絞り込めます。

ローカル LLM 実行環境の選定フロー。多人数にサーバー配信なら vLLM、アプリへ組み込み単一ユーザーなら Foundry Local、GUI で手軽に試すなら LM Studio、CLI で手軽に試すなら Ollama、低レベルで細かく制御したいなら llama.cpp へ分岐する判断フロー図

  • 多人数に配信したい（サーバー運用） → vLLM。GPU サーバーで高スループットに捌けます。
  • アプリに組み込み、端末内で完結させたい（単一ユーザー） → Foundry Local。OpenAI 互換 API と NPU/GPU 自動選択で、配布まで見据えられます。
  • GUI でまず触ってみたい → LM Studio。プログラミング不要で探索できます。
  • CLI でサッと試したい・エージェントに繋ぎたい → Ollama。導入が速く連携例も豊富です。
  • 低レベルで細かく制御したい・移植性が要る → llama.cpp。量子化と幅広いバックエンドが強みです。

なお機密データを端末外に出せない要件では、Foundry Local・Ollama・LM Studio・llama.cpp いずれもオフライン動作が可能です。プライバシー要件と「単一ユーザー or 多人数」の軸で、まず大きく方向性を決めましょう。

7. まとめ

  • ローカル LLM は ランタイム × モデル × 量子化 × ハードウェア の組み合わせで考えると整理できます。
  • Foundry Local はアプリ組み込み・単一ユーザー・OpenAI 互換・NPU/GPU 自動選択が強みで、配布まで見据えたオンデバイス AI に向きます。
  • 手軽さなら Ollama / LM Studio、基盤の柔軟性なら llama.cpp、本番の多人数配信なら vLLM が目安です。
  • まず軽量モデルで動作確認し、必要に応じて品質・サイズを上げるのが安全です。
  • 次のアクション: Foundry Local で作るローカルチャットアプリ（107） で、実際に動くチャットアプリを作ってみましょう。

8. 参考リンク

この記事の執筆にあたり、AI の支援を受けています。