LabHub

ブログ

LLM サービング & ローカル推論 2026 — vLLM / llama.cpp / MLX / Ollama / LM Studio / SGLang / TGI 徹底比較

2026-05-16 · 34 分で読めます · #llm#model-serving#inference#vllm#llama-cpp#mlx#llamafile#ollama#lm-studio#gpt4all#sglang#tgi#ktransformers#tensorrt-llm#modular-max#quantization#deep-dive#japanese

한국어English日本語

プロローグ — 「モデルをどこで動かすか」が再び重要になった

2023 年には誰もが OpenAI API を使っていた。2024 年に Anthropic・Google・Mistral が参入し、問いは「どの API か」だった。2025 年以降、問いは再び 「どこで動かすか」 に戻った。モデルサイズが小さくなり(8B・30B・70B)、量子化が良くなり(Q4_K_M でも実用的)、ノートに 200GB のメモリが搭載され(M4 Max 128GB・M3 Ultra 192GB)、クラウドのトークン価格が週単位で変動するなか、同じモデルを API・専用サービング・ローカル のどこで回すかが、コスト・遅延・ガバナンスを決めるようになった。

問題は 選択肢が増えすぎた ことだ。vLLM・SGLang・TGI・llama.cpp・MLX・llamafile・Ollama・LM Studio・GPT4All・KTransformers・MLC LLM・Triton・TensorRT-LLM・Modular MAX — それぞれ異なる質感を持ち、異なるワークロードに向き、互いに重なってもいる。さらにクラウド側からは Together・Fireworks・Groq・Cerebras・SambaNova・Lepton(NVIDIA が 2025 年に買収)が「API を呼ぶだけで上手に回す」という質感で参入した。

この記事は 2026 年 5 月時点でその地図を描く。誰が何を上手にやるか、どのワークロードにどの陣営が向くか、そして韓国・日本のモデル生態系とどう交わるかまで。

第 1 章 · 2026 年の LLM サービング地図 — 3 陣営

まずは大局。2026 年の LLM サービング・推論市場はおおむね 3 陣営 に分かれる。

陣営 A · データセンター / 高スループットサービング

エンタープライズ・SaaS・研究所の本番サービング。数十〜数千 RPS、複数ユーザ、GPU クラスタ。

陣営 B · ローカル / シングルユーザ

ノート・ワークステーション・ホームサーバ。1 RPS 未満、シングルユーザ、プライバシー重視。

陣営 C · クラウドサービング SaaS

「モデルを選んで API を呼ぶだけ」— 自前 GPU 運用の負担なし。

各陣営は 異なる前提 の下で作られた。データセンター: 「GPU は高いから稼働率を絞り出そう」。ローカル: 「自分のノートで動かそう」。クラウド SaaS: 「GPU 運用は忘れてトークン単価だけ見よう」。だから同じ問題に見えても、上手に解く人が皆違う。

第 2 章 · vLLM — PagedAttention の標準

vLLM は 2023 年に UC Berkeley(Sky Computing Lab)で始まった OSS 推論サーバだ。2024 年に独立 OSS 組織 vLLM Project になり、2025 年からは Linux Foundation 配下の PyTorch Foundation に合流して、OSS LLM サービングの事実上の基準 になった。

中核の発明は PagedAttention。KV cache を OS のページテーブルのようにブロック単位で管理し、メモリの断片化をなくし、複数同時リクエストの KV cache を同じ GPU に効率よく載せられるようにしたのが出発点だ。結果として単純な batching に対し 2〜4 倍のスループットが普通に出る。

2026 年の vLLM の現状:

典型的な vLLM サービング:

pip install vllm

vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --tensor-parallel-size 4 \
  --max-model-len 32768 \
  --enable-prefix-caching \
  --enable-chunked-prefill

これで OpenAI 互換 HTTP サーバが 8000 ポートに立ち、クライアントは OpenAI SDK をそのまま使えばよい。

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")
resp = client.chat.completions.create(
    model="meta-llama/Llama-3.3-70B-Instruct",
    messages=[{"role": "user", "content": "こんにちは"}],
)
print(resp.choices[0].message.content)

いつ vLLM か: 複数ユーザの本番サービング、OSS モデル、NVIDIA(または AMD ROCm・Intel Gaudi・TPU)GPU が利用可能、スループットとコスト効率が優先。シングルユーザのノートにはオーバーキル。

第 3 章 · llama.cpp — gguf、CPU/GPU 二刀流

llama.cpp は Georgi Gerganov が 2023 年に始めた C/C++ 推論エンジンだ。「外部依存なしに 1 つのバイナリで LLM を動かそう」という野心から始まり、2026 年には ローカル・組み込み LLM 推論のベースレイヤー になった。Ollama・LM Studio・llamafile・GPT4All のようなユーザフレンドリーなツールはほぼすべて内部で llama.cpp を使っている。

中核の質感:

llama-server で OpenAI 互換サーバを立てられる。

./llama-server \
  --model models/Llama-3.3-70B-Q4_K_M.gguf \
  --n-gpu-layers 99 \
  --ctx-size 8192 \
  --host 0.0.0.0 --port 8080

2026 年の llama.cpp の長所・短所:

いつ llama.cpp か: 個人・少人数ローカル、組み込み・エッジ、GGUF 量子化を活用したい、「1 バイナリで終わらせたい」質感。

第 4 章 · MLX(Apple) — Apple Silicon 推論

MLX は 2023 年 12 月に Apple ML Research が公開した OSS の配列・機械学習フレームワークだ。NumPy + PyTorch に似た API を持ち、Apple Silicon の unified memory をファーストクラス市民として扱う。M1/M2/M3/M4 シリーズでは CPU と GPU が同じメモリを見て、MLX はその上でデータコピーなしに計算を流す。

2026 年の MLX の現状:

典型的な MLX の使い方:

pip install mlx mlx-lm

mlx_lm.generate \
  --model mlx-community/Llama-3.3-70B-Instruct-4bit \
  --prompt "Apple Silicon で LLM を動かす理由は" \
  --max-tokens 200

Python から直接:

from mlx_lm import load, generate

model, tokenizer = load("mlx-community/Llama-3.3-70B-Instruct-4bit")
text = generate(model, tokenizer, prompt="こんにちは", max_tokens=200)
print(text)

なぜ MLX がますます重要か:

短所: Apple Silicon 専用。複数ユーザのサービングは vLLM ほど洗練されていない。

いつ MLX か: Mac でのローカル LLM 開発・ファインチューン・prototype、M シリーズのノート・デスクトップに縛られたワークロード。

第 5 章 · llamafile(Mozilla) — 単一バイナリ

llamafile は 2023 年 11 月に Mozilla(Mozilla Innovation Group)が公開したプロジェクトだ。中核アイデア: モデルの重み + 推論エンジン + tokenizer を 1 つの実行ファイルに束ね、どの OS・CPU アーキでもダブルクリックで動く LLM を作る。

技術的トリックは Justine Tunney(Cosmopolitan libc も同じ人)が書いた Actually Portable Executable(APE) フォーマットだ。1 つのファイルが Linux 上は ELF、macOS 上は Mach-O、Windows 上は PE として動き、さらに FreeBSD/OpenBSD/NetBSD でも動く。そこに llama.cpp 推論エンジンと GGUF の重みを束ねた。

典型的な使い方:

curl -L -o llava-v1.5.llamafile \
  https://huggingface.co/Mozilla/llava-v1.5-7B-llamafile/resolve/main/llava-v1.5-7b-q4.llamafile
chmod +x llava-v1.5.llamafile
./llava-v1.5.llamafile

これで OpenAI 互換 HTTP サーバが立ち、同じファイルを Mac/Linux/Windows に移してもそのまま動く。2026 年現在も Mozilla が LLaMA・Mistral・Phi・Gemma・Qwen など主要 OSS モデルの llamafile バリアントを Hugging Face に出し続けている。

なぜ llamafile が意義深いか:

短所: 単一ファイルサイズの制限(以前は 4GB、2024 年以降は ZipAlign・外部重みで回避)、本番サービングは質感が違う。

いつ llamafile か: 非技術者ユーザに LLM を「渡す」状況、オフライン配布、教室・ワークショップ、アーカイブ。

第 6 章 · Ollama — 最も簡単なローカル LLM

Ollama は 2023 年 6 月に始まったローカル LLM ランタイムだ。内部では llama.cpp を使うが、Docker のように綺麗な UX(モデルを pull・run・push、Modelfile でカスタマイズ)を被せ、2026 年現在 ローカル LLM の事実上のデフォルトエントリポイント になった。

# インストール(Mac/Linux/Windows)
curl -fsSL https://ollama.com/install.sh | sh

# モデルを取得してすぐチャット
ollama run llama3.3

# バックエンドサーバモード
ollama serve

# 別のターミナルから API 呼び出し
curl http://localhost:11434/api/generate -d '{
  "model": "llama3.3",
  "prompt": "こんにちは",
  "stream": false
}'

2026 年の Ollama の現状:

魅力はシンプルさだ。「Mac にインストールして 5 分以内に量子化された 70B モデルとチャット」が本当に成立する。結果として LangChain・LlamaIndex・n8n・VS Code 拡張など、ほぼすべての OSS LLM ツールが「Ollama 互換」をデフォルトで備えている。

短所: 複数ユーザのスループット・高度な batching は vLLM/SGLang に劣る。Modelfile DSL が薄い。モデルライブラリが Ollama Hub に寄りがち(GGUF インポートは可能)。

いつ Ollama か: 個人のノート・ホームサーバ・「5 分で始めたい」とき、OSS ツールとの即時連携。

第 7 章 · LM Studio / GPT4All — GUI オプション

CLI よりも GUI を好むユーザのための陣営。

LM Studio

2023 年に始まったデスクトップアプリ(Mac/Windows/Linux)。モデル検索・ダウンロード・チャット・サーバモードが 1 つの .app に収まる。Hugging Face Hub から GGUF モデルを検索・フィルタ・ダウンロードし、チャット UI でそのまま使うか、OpenAI 互換のローカルサーバを立てるかができる。

2026 年の LM Studio:

ライセンス変更で商用利用が無料になった(個人・企業ともに)ため、社内デモ・POC で頻繁に使われる。

GPT4All

2023 年初頭に Nomic AI が始めた OSS プロジェクト。デスクトップアプリ + Python SDK + モデルライブラリ。「どんなノートでも動く LLM」をモットーに、CPU 推論と小モデル(3B・7B・13B)に強い。ローカル文書検索(LocalDocs)のような RAG 機能がデスクトップアプリに統合されている。

2026 年の GPT4All:

LM Studio と GPT4All の 1 行比較: LM Studio は「Hugging Face モデル探索に強い GUI」、GPT4All は「デスクトップ chat + LocalDocs RAG に強い GUI」。

いつ GUI か: 非技術者ユーザ、デモ・教育・社内ツール、「マウスで完結したい」とき。

第 8 章 · SGLang — 構造的生成

SGLang は LMSYS・UCB・Stanford 共同で 2024 年初頭に公開された推論システムだ。vLLM と同じ「高スループットサービング」陣営だが、構造的生成 と RadixAttention という 2 枚のカードを持って入ってきた。

RadixAttention

PagedAttention が「メモリ断片化」を解いたとすれば、RadixAttention は 複数リクエスト間の prefix を radix tree で共有する。同じシステムプロンプトを使う 1000 リクエストがあれば、その部分の KV cache は 1 回だけ計算され自動的に共有される。agentic ワークロード(同じツール仕様や few-shot が繰り返される)で効果が大きい。

Frontend DSL — 構造的生成

SGLang は Python DSL で LLM 呼び出しを書くが、分岐・反復・並列・制約 がファーストクラスだ。

import sglang as sgl

@sgl.function
def multi_turn_question(s, question):
    s += sgl.system("You are a helpful assistant.")
    s += sgl.user(question)
    s += sgl.assistant(sgl.gen("answer", max_tokens=256))
    s += sgl.user("Was that answer correct?")
    s += sgl.assistant(sgl.gen("verification", choices=["yes", "no"]))

state = multi_turn_question.run(question="What is the capital of France?")
print(state["answer"], state["verification"])

sgl.gen(..., choices=...) や JSON スキーマ制約は backend で constrained decoding により強制される。つまりモデルが「yes」/「no」以外のトークンを出せない。

2026 年の SGLang の強み:

いつ SGLang か: structured output・tool use がヘビーなワークロード、prefix が頻繁に共有される agentic サービング、vLLM と一緒に候補にして自分のワークロードでベンチ。

第 9 章 · TGI(Hugging Face) — 運用フレンドリー

TGI(Text Generation Inference) は Hugging Face が作った推論サーバだ。2022 年末に始まり、2026 年には vLLM/SGLang ほど学術的話題性はないが、運用フレンドリー な機能で地位を確立した。

docker run --gpus all -p 8080:80 \
  -v $PWD/models:/data \
  ghcr.io/huggingface/text-generation-inference:latest \
  --model-id meta-llama/Llama-3.3-70B-Instruct \
  --quantize bitsandbytes-nf4

ライセンスは 2024 年に一時 HFOIL に制限されたあと、Apache 2.0 に戻った経緯がある。2026 年現在は再び自由な OSS。

いつ TGI か: Hugging Face Hub への依存が強いチーム、Hugging Face Endpoints とのモード統一、「運用メトリクス・標準 docker コンテナ」の質感を好むとき。

vLLM/SGLang vs TGI を 1 行で: 学術的な加速イノベーションは vLLM/SGLang から先に出て、TGI の強みは「運用化」。

第 10 章 · KTransformers(Tsinghua) — long-context 最適

KTransformers は清華大学(Tsinghua University)MADSys 研究室から 2024 年に公開された推論フレームワークだ。焦点は明確 — コンシューマ GPU 1 枚で巨大 MoE モデルを動かすこと。

中核のトリック:

# DeepSeek-V3 を RTX 4090 + 大きなシステム RAM で
git clone https://github.com/kvcache-ai/ktransformers
cd ktransformers
pip install -e .
python -m ktransformers.local_chat \
  --model_path /path/to/DeepSeek-V3-GGUF \
  --gguf_path /path/to/DeepSeek-V3-GGUF \
  --cpu_infer 32

なぜ KTransformers が意義深いか:

短所: 複数ユーザサービング・スループットは vLLM の方が良い。インストール・チューニングの学習コストがある。

いつ KTransformers か: 巨大 MoE モデルをシングルユーザで動かしたいが GPU クラスタがないとき、long-context ワークロード。

第 11 章 · NVIDIA Triton + TensorRT-LLM — データセンター標準

NVIDIA 陣営のフルスタック。この 2 つは一対のように一緒に使われることが多い。

TensorRT-LLM

NVIDIA の OSS LLM 推論ライブラリ。PyTorch モデルを TensorRT エンジン(NVIDIA 専用 IR)にコンパイルし、FP16・INT8・INT4・FP8・NVFP4 のような NVIDIA が推す精度で加速する。Hopper(H100/H200)や Blackwell(B100/B200・GB200)の新命令を素早く活用するのが強み。

Triton Inference Server

NVIDIA の汎用推論サーバ。LLM だけでなく vision・tabular・custom モデルまで multi-framework で 1 つのサーバから出す。TensorRT-LLM バックエンド経由で LLM サービングモードで使うこともでき、TensorRT-LLM の OpenAI 互換サーバ(trtllm-serve)を直接立てることもできる。

# モデルを TensorRT-LLM エンジンにビルド
trtllm-build --checkpoint_dir ./llama3-70b \
  --output_dir ./engines/llama3-70b \
  --gemm_plugin auto \
  --max_batch_size 32

# trtllm-serve で起動(OpenAI 互換)
trtllm-serve ./engines/llama3-70b --port 8000

vLLM vs TensorRT-LLM を 1 行で: vLLM は OSS、多様な GPU(NVIDIA・AMD・Intel・TPU)対応、入りやすい。TensorRT-LLM は NVIDIA 専用だが NVIDIA GPU の最後の一滴まで絞り出す(特に FP8/FP4)。本番ではこの 2 つを並べて自分のワークロードでベンチするチームが多い。

いつ TensorRT-LLM/Triton か: NVIDIA Hopper/Blackwell GPU クラスタ、本番でスループット・レイテンシが絶対的、運用チームが NVIDIA エコシステムに慣れている。

第 12 章 · Modular MAX(Mojo チーム) — 新陣営

Modular は Chris Lattner(LLVM・Swift・Clang の原作者)が 2022 年に創業した会社だ。Mojo(Python 互換を狙う高性能システム言語)と MAX(Modular Accelerated Xecution、AI 推論プラットフォーム)を作る。2024 年から MAX の OSS 化を始め、2026 年には NVIDIA・AMD・Intel・Apple まで同じ 1 つのグラフコンパイラで推論する という質感で位置づいた。

中核アイデア:

pip install modular
max serve --model-path meta-llama/Llama-3.3-70B-Instruct

2026 年の Modular の位置:

短所: Mojo の OSS 化が段階的でコミュニティはまだ小さい。モデル互換性・機能幅は vLLM の方が広い。

いつ MAX か: AMD GPU で vLLM の ROCm バックエンドより速い道を探したいとき、Mojo 生態系を早期採用したいとき、NVIDIA 一辺倒の lock-in を避けたいとき。

第 13 章 · 量子化 — GGUF / AWQ / GPTQ / FP8

サービングフレームワークを選ぶ際に切り離せない 1 つの軸が 量子化フォーマット だ。2026 年現在の主流 5 つ。

GGUF(llama.cpp 系)

AWQ(Activation-aware Weight Quantization)

GPTQ

FP8

NVFP4 / MXFP4

1 行のおすすめ:

第 14 章 · クラウドサービング SaaS — Together / Fireworks / Groq / Cerebras / Lepton

自前 GPU 運用が負担のチームのための陣営。OSS モデルを 1 つの API で呼ぶ 質感。

Together AI

OSS モデルホスティングの兄貴分。Llama・Mistral・Qwen・DeepSeek など 200+ モデルを OpenAI 互換 API で。ファインチューン・dedicated endpoint・dedicated deployment まで。学術との協業(RedPajama や Stripedhyena などのモデル共同学習)も強み。

Fireworks AI

高スループットと関数呼び出し・structured output 品質で評価されている。自社学習・ファインチューンツールも強力。Mixture-of-Experts と long-context に最適化された推論スタックを併売。

Groq

自社チップ LPU(Language Processing Unit)。巨大 SRAM・決定論的(deterministic)実行で同じモデルを 圧倒的低遅延(秒間数百トークン)でサーブ。OSS Llama・Mixtral が中心、モデル幅は限定的だが速度ではほぼ常にトップ候補。

Cerebras

wafer スケールエンジン — ウェハ 1 枚が 1 チップ(WSE-3 で約 4 兆トランジスタ)。巨大な単一チップなので H100 クラスタ比でモデル分割・通信オーバヘッドが少ない。inference cloud で高速スループットを謳い、一部の政府・研究所用の巨大学習にも使われる。

SambaNova

自社チップ RDU(Reconfigurable Dataflow Unit)。データフロー アーキテクチャで LLM の dense・sparse ワークロードに最適。エンタープライズ・政府市場が中心。

Lepton AI(NVIDIA 買収、2025)

Jia Yangqing(Caffe の原作者、Meta・Alibaba)らが創業したクラウド推論プラットフォーム。NVIDIA が 2025 年に買収し、NVIDIA のクラウド生態系における推論レイヤー に入った。NVIDIA DGX Cloud・NIM(NVIDIA Inference Microservices)と統合され、「NVIDIA が直接運用する OSS モデル推論」の質感で定着しつつある。

1 行比較

第 15 章 · 韓国 / 日本 — Upstage Solar / KT Mi:dm / Sakana / NTT つづみ / ELYZA

英語圏モデルだけ見ていると半分を見落とす。韓国・日本の OSS・半 OSS モデル陣営も 2026 年に確固たる位置を得た。

韓国

これらのモデルは vLLM・SGLang・llama.cpp の fork やブランチで、韓国語 tokenizer や specific カーネル向けのパッチと共に回っている。OSS 互換性はモデルごとに異なり、ライセンス(研究用・商用限定・完全 OSS)も分かれるので導入前にライセンス確認は必須。

日本

運用観点では韓・日のモデルは概ね ローカルサービング(llama.cpp・Ollama・vLLM) と OSS ホスティング(Together・Fireworks ほか各地のクラウド) どちらでも動く GGUF・safetensors バリアントを一緒に出すのが標準になった。政府・銀行のような規制産業は on-prem vLLM/TGI がほぼデフォルトの選択。

第 16 章 · 誰が何を選ぶべきか

これまでの 12 陣営を 状況別の推奨 にまとめる。

個人 / 趣味

スタートアップ(10〜50 名)

エンタープライズ(規制産業・金融・政府)

データセンター / ハイパースケール

ハードウェア lock-in 回避

エピローグ — モデルはコモディティになり、インフラが差別化要因

2023 年には「どのモデルを使うか」が問いだった。2026 年には 「どこで、どう動かすか」 が問いだ。モデルは豊富になり(OSS 70B・MoE 巨大モデルまで)、価格は時間単位で変動し、量子化品質は 1 年前とは別水準になり、GPU 1 枚がノートに刺さる時代になった。

この記事の結論はシンプルだ — 自分のワークロードで直接ベンチせよ。スループット・遅延・コスト・運用複雑さはワークロードごとに違って出るので、推奨より測定が常に正しい。そして、その測定のための 12 陣営が 2026 年にすべて OSS で揃っているということが、もしかするとこの記事の本当のメッセージかもしれない。

今やるべきは GPU を速く回すことではなく、どの陣営が自分たちの問題に合うかを 1 週間以内に決めること だ。

参考 / References

コメント

まだコメントはありません。

ログインするとコメントできます