Ollama・LM Studio ― ローカルでLLMを動かす技術スタック

「APIを呼ぶこと」と「モデルを動かすこと」は、別の問題です。

APIを呼ぶときは、トークン課金・レイテンシ・ハイパーパラメータだけ考えていれば済みます。モデル自体は「どこかのH100で誰かがちゃんと回してくれている」状態で、気にしなくていい。

ところが、同じモデルを自分のMacBookやRTX 3090で動かそうとした瞬間、視点が一気に変わります。

• GGUFって何なのか
• Q4_K_Mがなぜ「スイートスポット」なのか
• コンテキストを伸ばすとなぜVRAMが爆発するのか
• 推論エンジンによって速度が違うのはなぜか

こういうことを無視して進めません。ローカルLLMはモデルというよりも スタック なんです。

この記事は「5分でOllamaセットアップ」系のチュートリアルではありません。インストールはREADME一読で終わります。代わりに、なぜそう動くのか、どういう選択肢があるのか をエンジニア目線で見ていきます。

順番:

1. Ollama vs LM Studio ― コア比較
2. GGUF量子化のしくみ ― ビット vs 品質
3. 2026年の人気モデル別メモリ要件
4. KVキャッシュの罠 ― コンテキストを伸ばすとVRAMが爆発
5. OpenAI互換APIの意味
6. その他のランタイム6種 (llama.cpp · vLLM · mlx-lm · koboldcpp · TGI · LocalAI)
7. いつOllama / LM Studio / vLLMか
8. FAQ

---

1. Ollama vs LM Studio ― コア比較

2026年のローカルLLMは3強体制です。

• Ollama: CLI + REST API、スクリプト中心、開発者のデファクト
• LM Studio: GUI + CLI + REST、Apple SiliconでMLXバックエンドにより最速
• vLLM: プロダクション向けサーバー、PagedAttention + Continuous Batching、同時リクエスト処理

ひとまず開発者ワークステーション用の2つ(Ollama・LM Studio)を先に切り分けます。

いくつか押さえておくポイントがあります。

Ollamaの現在地

Ollamaは2026-03にv0.6.2が出て、Llama 4 Scout 8B・Gemma 4 MLX・Flash Attention v2.7・M4 Metal 3最適化が入りました。rcとしてはv0.21.1-rc0(2026-04-21)が回っています。マイナーリリースごとにバックエンド(llama.cpp派生)とApple Silicon最適化が更新されるペースです。

一番重要なのは、Ollamaが OpenAI互換APIを標準で公開する こと。インストールした瞬間から http://localhost:11434/v1/chat/completions が開いています。これがスタック全体の意味を変えます ― 5節で別途。

LM StudioのApple Silicon優位

LM StudioがMacで速いのは、MLXバックエンド を標準採用しているからです。MLXはAppleが2023年に公開したApple Silicon向けネイティブMLフレームワーク。M3 UltraでGemma 3 1Bを回したとき、LM Studioが237 tok/s、Ollamaが149 tok/sという実測報告があります(ソース欄にリンク)。同じハードウェアで約1.5倍。

加えて2026-02に入った LM Link ― Tailscaleベースのリモート接続が標準装備になりました。デスクトップでサーバーを立てて、ノートPCから呼ぶ構成がほぼ設定なしで成立します。

選び方

一行でまとめると:

• スクリプト・バックエンドに埋め込むならOllama (CLI・REST・OpenAI互換が標準)
• Macで複数モデルを実験するならLM Studio (MLX速度 + GUI)
• プロダクション同時リクエストならvLLM (7節で別扱い)

---

2. GGUF量子化のしくみ ― ビット vs 品質

ローカルLLMを深く理解するには GGUF は避けて通れません。

GGUFはllama.cppプロジェクトが作ったモデル形式で、Ollama・LM Studio・koboldcpp・LocalAIは全部内部でllama.cppを使っています。だからローカルLLMの事実上の標準フォーマットです。

GGUFそのものより重要なのが 量子化(quantization) です。

量子化は何をしているのか

Llama 3.3 70BのようなモデルはFP16(16ビット浮動小数点)で訓練されます。パラメータ700億個 × 2バイト = 約140GB。MacBookどころかRTX 6000 Ada 48GB一枚にも載りません。

量子化は、このパラメータを より少ないビット数で表現する 技法です。FP16の2バイトを4ビットに縮めると、サイズが1/4。品質はある程度落ちますが、重要なのは 品質の低下がサイズの低下よりずっと緩やか という点。

ビット別トレードオフ (13Bモデル基準)

注目すべき数字:

• Q4_K_M = FP16比でサイズ -70%、速度 +87%、品質95%
• Q5_K_Mはサイズがやや大きいが品質97%

なぜ4ビットが「大衆スイートスポット」かというと、それ以下(Q3)から品質劣化が線形じゃなく 加速 するからです。Q3_K_Mで品質90%、Q2では85%以下に落ちることがよくある。逆に4→5→6→8と上げても品質改善は鈍化していく。まさに「コスパ」がピタリ当てはまる区間です。

K_Mって何

Q4_K_Mの「K」はK-quantsという量子化方式、「M」はmedium precision。同じQ4でもQ4_0・Q4_K_S・Q4_K_Mがあり、後ろに行くほどメタデータを精緻に持つため品質が上がります。実務では Q4_K_Mを基準 にして、メモリに余裕があればQ5_K_M、足りなければQ3_K_Mに落とすのが定石。

(解釈) なぜ4ビットで品質95%も保てるのか

公式の説明ではありませんが、業界通説は ― LLMのパラメータは「絶対値」より「相対配置」が効きます。隣接パラメータの比率が保たれていれば、値そのものが2%ずれても出力品質はほぼ変わらない。量子化はこの性質を利用して値を近似値に押し込んでいる、と。(業界の解釈 · 公式な定量説明ではない)

---

3. 2026年の人気モデル別メモリ要件

量子化の原理より実務的には「自分のハードで何が動くか」が先です。

現実チェック

70Bはローカルの最前線。 Q4_K_M基準で39GB。RTX 6000 Ada(48GB)一枚、もしくは2×3090(各24GB → 計48GB、テンソル並列)で回ります。Macは M3 Max 64GB以上。Q8_0まで上げると74GBで、H100 80GB一枚かM3 Ultra 128GBが必要。

32Bがデスクトップのスイートスポット。 Qwen 2.5 32B Q4_K_Mが~20GB。一般人が買える最大GPUのRTX 4090(24GB)にちょうど収まります。Q5_K_Mは24GBカツカツなのでOS分も考えるとRTX 5090(32GB)が安全圏。

8Bはノートで日常使い。 Q4_K_Mで6GB。M2/M3 16GB MacでOS・ブラウザを動かしながら余裕。速度も十分です。「個人AIアシスタント」用として現実的なラインになります。

DeepSeek V3 671Bはローカルの外。 Mixture of Expertsで全パラメータ671B、活性化は37Bと言われていますが、weight全体をロードする必要があるのでQ4でも~400GB。個人がローカルで回すモデルではありません(fireworks · togetherのようなホスティングサービス経由が現実的)。

---

4. KVキャッシュの罠 ― コンテキストを伸ばすとVRAMが爆発

ここがチュートリアルに載らない部分です。

先ほどの表は モデルweightのみ の数字です。実際にローカルで動かすときは KVキャッシュ が別途VRAMを食います。これを知らないと「70Bが入るって言ったのに、なぜOOM?」という事態になります。

KVキャッシュとは

Transformerがトークンを1つずつ生成するとき、過去トークンの KeyとValueベクトル を使い回すためにメモリに蓄積します。これがKVキャッシュです。無いと、1トークン生成するたびに全過去トークンのattentionを再計算することになり、速度が二乗で遅くなります。

なのでキャッシュしているわけですが、このサイズがコンテキスト長に正比例 します。

計算

ざっくりした式 ― KVキャッシュVRAMは

KV_cache = 2 × num_layers × hidden_size × context_length × batch × bytes_per_value

Llama 3.3 70B基準で (80層 × 8192 hidden × FP16):

• 2Kコンテキスト → 約 1.6 GB
• 32Kコンテキスト → 約 26 GB
• 128Kコンテキスト → 約 42 GB 追加

ここで重要なのは、128Kを使いたければ 39GB(weight) + 42GB(KV) = 81GB が必要という点。RTX 6000 Ada 48GB一枚で70B Q4_K_Mを「回せる」のは 短いコンテキスト限定 です。

実務的な対処

1. 短く使う ― ほとんどの作業は8K〜32Kで足ります。128Kが本当に必要な場面は意外と少ない
2. KVキャッシュの量子化 ― llama.cpp/OllamaはKVキャッシュを4bit/8bitに量子化可能。Flash Attention v2.7(Ollama v0.6.2標準適用)と組み合わせると効果大
3. Grouped Query Attention (GQA) ― Llama 3以降のモデルはこの構造で、KVキャッシュが元の約1/8に縮まっている。それでも長コンテキストでは大きい
4. バッチサイズ1 ― ローカル個人利用はすでにbatch=1なので、これは既定

結論: 長コンテキストを使う予定なら、モデルweightメモリに加えてKVキャッシュVRAMを別途計算してマージンを取るべき。 ローカルLLMを初めて回すとき最も踏みやすい罠です。

---

5. OpenAI互換APIの意味

この節がこの記事でたぶん一番実務的なところです。

OllamaはOpenAI互換エンドポイントを標準で開きます。これが実際に何を意味するかというと ―

from openai import OpenAI

# OpenAIクラウド
client = OpenAI(api_key="sk-...")
client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "hello"}]
)

# Ollamaローカル (base_urlだけ差し替え)
client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"  # 任意の文字列でOK
)
client.chat.completions.create(
    model="llama3.1:8b",
    messages=[{"role": "user", "content": "hello"}]
)

既存のOpenAI SDKコードからbase_urlとmodelの2行だけ変えれば ローカルに移せます。それだけ。

なぜこれが重要か ―

1) 既存のコード資産が死なない

社内ですでにOpenAI SDKで書いたエージェント・RAGパイプラインがあれば、base_urlを1つ変えるだけでローカルモードに切り替わります。フレームワーク移行不要。LangChain・LlamaIndex・Haystackのような主要フレームワークも全部OpenAI互換をファーストクラスで扱います。

2) コストがゼロになる

API呼び出しが多いワークロード ― 例えば「1万件の文書をLLMで分類」「実験用のプロンプトスイープ」 ― をローカルに寄せると、トークン課金がまるごと 消えます。電気代とハードウェア減価だけが残る形。

3) プライバシー

機密データを外部APIに送れないドメイン ― 医療・法律・社内データ ― でローカルLLMが唯一解になるケースが多いです。OpenAI互換なので既存のワークフローをそのまま持ち込めるのが、ここで決定的。

4) オフライン

飛行機の中、海外出張の不安定な回線、社内ファイアウォール。ネットが不安定でも同じコードが動きます。

注意 ― 互換性は「ほとんど」で「100%」ではない

• Tool use(function calling)のフォーマットはモデル差がある(最近のモデルはほぼ互換)
• Structured outputs (JSON schemaの強制)対応はモデル差
• Streamingフォーマットは一致
• Vision(画像入力)はモデル側の対応次第

実務コードのほとんどはそのまま動きます。エッジケースはモデルのdocsを確認。

---

6. その他のランタイム6種 ― いつ何を選ぶ

Ollama・LM Studio以外にも、ローカル・サーバーLLMスタックで押さえるべきツールがいくつかあります。用途が全部違います。

llama.cpp

すべてのベース。 Ollama・LM Studio・koboldcpp・LocalAIは中身がllama.cpp。llama-serverを直接回すと :8080/v1 でOpenAI互換APIが開きます。細かな制御が必要なとき(カスタムサンプリング・ログ確率へのアクセス)、依存を最小にしたいときに。C++単一バイナリ。

vLLM

プロダクションサーバー用。 UCバークレー発の高性能サービングエンジン。肝は2つ。

• PagedAttention: OSの仮想メモリのようにKVキャッシュをページ単位で管理。メモリ断片化を解消
• Continuous Batching: リクエストを動的にバッチング。同時に数百リクエスト処理可能

Ollamaは「一度に1リクエストをしっかり回す」設計。vLLMは N人が同時に叩く社内サービス 用。:8000/v1 OpenAI互換。チーム規模のセルフホスティングならvLLM。

mlx-lm (Apple MLX)

Apple Silicon向けネイティブフレームワーク。LM Studioが標準採用しているバックエンドを直接使う形です。Pythonで pip install mlx-lm。Hugging FaceのMLX変換モデルを直接ロード。Macで最速の経路ですが、開発者向けなのでGUIはなし。セットアップ自由度は高いです。

koboldcpp

llama.cppフォーク、単一実行ファイル で配布。特徴はAPI3つを同時公開 ― KoboldAI・OpenAI・Ollama互換。内蔵Web UIもあり、「GUIもCLIも大げさ」という人向けの中庸ポジション。

TGI (Text Generation Inference)

HuggingFaceのプロダクションサービング。Docker中心のデプロイで、HF生態系とがっちり噛み合います。vLLMとポジションは被りますが、「HF Hub + Docker + K8s」スタックならTGIが自然。

LocalAI

マルチバックエンドアダプタ。GGUF・MLX・Diffusion・Whisperを1プロセスで扱います。2026-01に Anthropic API互換 が追加され、Claude SDKで書いたコードをローカルに持ち込める唯一の経路になりました。(OllamaはOpenAI互換のみ)

一行まとめ

• llama.cpp: C++で全部制御
• vLLM: プロダクション同時リクエスト
• mlx-lm: MacでMLX直接
• koboldcpp: 単一ファイル + 3重互換
• TGI: HF + Docker生態系
• LocalAI: OpenAI + Anthropic両互換

---

7. いつOllama / LM Studio / vLLMか

要約ディシジョンツリー。

個人開発者、MacBookだけ

→ LM Studio から (GUIでモデルを複数ダウンロードしておき、MLX速度の恩恵)
→ スクリプト化する段階で Ollama 追加 (REST + OpenAI互換)

Linuxワークステーション + RTX 3090/4090

→ Ollama メイン (CLI・RESTが自然)
→ カスタムサンプリング・詳細オプションが必要なら llama.cpp直叩き

社内チームで共用のセルフホスト

→ vLLM (Continuous Batchingが肝)。Ollamaは同時リクエストに不利
→ Docker/K8s環境なら TGI も選択肢

Macで速度を限界まで絞る

→ mlx-lm直接 (LM Studioが同じバックエンドを使うが、Python制御が必要なとき)

すでにClaude SDKコードがある

→ LocalAI (Anthropic API互換レイヤー)

RAG/エージェントフレームワークに差し込むなら

→ Ollama (OpenAI互換がLangChain・LlamaIndexの既定アダプタと最もなめらか)

---

8. FAQ

Q1. OllamaとLM Studioを両方インストールしても大丈夫ですか?

大丈夫です。ポートが別々 ― Ollamaは :11434、LM Studioは :1234。モデルファイルも別ディレクトリに保存されるので衝突しません。実際 LM Studioでモデル実験 → Ollamaでスクリプトにデプロイ は定番の組み合わせ。ただGGUFファイルを2度ダウンロードすることになるのでディスク容量には注意。

Q2. RTX 4090(24GB)で動かせる最大モデルは?

Qwen 2.5 32B Q4_K_M(~20GB)が安全上限。Q5_K_M(24GB)はコンテキスト短めでのみ回ります。70BはQ3_K_S(~28GB)でも入り切らず現実的じゃない。32Bクラスこそが RTX 4090 のスイートスポット。KVキャッシュまで考慮するとコンテキストは8K〜16Kが目安。

Q3. OllamaがLM Studioより遅いのはなぜ?

Apple Siliconに限った話です。LM StudioはApple MLXバックエンドを標準採用しており、MシリーズチップのANE・Metalをより深く使います。OllamaはllamaCpp(Metalバックエンド)ベース。M3 Ultra + Gemma 3 1B基準で LM Studio 237 tok/s vs Ollama 149 tok/s の報告があります。Linux・NVIDIA環境ではどちらもllama.cpp(CUDA)に近く寄るので差はほぼ無いです。

Q4. プロダクションでOllamaをそのまま使ってはダメ?

個人1名利用なら問題ありません。ただチーム5名以上が同時に叩き始めると、Ollamaのリクエストキューが直列なのですぐに詰まります。そのタイミングでvLLMに移すか、Ollamaインスタンスを複数立ててロードバランサの裏に並べるパターンを採ります。「個人 vs 同時リクエスト」が分岐点。

Q5. クラウドAPIを完全に使わずに済ませられますか?

現実的には無理です。ローカルが勝つ領域(ルーティング・分類・大量バッチ・機密データ)と、クラウドが勝つ領域(最高品質の推論・長コンテキスト・マルチモーダル・複雑なエージェント)があります。2026年の実務の基本は エージェント内部でローカルとクラウドを混ぜる こと。OpenAI互換のおかげで、同じコード中で base_url を条件付きで切り替えるだけで済みます。

---

9. むすび ― Pシリーズ完結

Pシリーズはここで完結です。

• P1: Claudeファミリーのアップグレード
• P2: API呼び出しのしくみ
• P3: オープン vs クラウドLLM
• P4: クローズド4社の技術戦略
• P5: オープンソース3強 (Llama・Qwen・DeepSeek)
• P6: ローカルスタック (Ollama・LM Studio) ← ここ

クラウドAPIから始めて、オープンソースの意味を挟み、自分の機器で動かすところまで降りてきた形です。残るのは一つ ― 何を回すかより、どう組み合わせるか。この軸が次シリーズのテーマです。

お読みいただきありがとうございました。

---

ソースリスト

• Ollama GitHub: https://github.com/ollama/ollama
• Ollama Releases: https://github.com/ollama/ollama/releases
• Ollama ライブラリ: https://ollama.com/library?sort=newest
• Ollama Blog: https://ollama.com/blog
• Ollama OpenAI互換ドキュメント: https://docs.ollama.com/api/openai-compatibility
• LM Studio: https://lmstudio.ai/
• LM Studio GitHub: https://github.com/lmstudio-ai
• llama.cpp量子化ディスカッション: https://github.com/ggml-org/llama.cpp/discussions/2094
• Qwen 2.5 Coder 32B Model Card: https://huggingface.co/Qwen/Qwen2.5-Coder-32B-Instruct
• KVキャッシュ関連論文: https://arxiv.org/html/2601.14277v1

---

ニュースレターCTA

このように「インストール手順ではなく、構造で切り分ける」記事を毎週月曜朝にメールで配信しています。受け取りたい方は ニュースレター会員登録(無料・30秒) からどうぞ。