Skip to content
Published on

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

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

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

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 クラスタ。

  • vLLM — PagedAttention の事実上の標準
  • SGLang — 構造的生成と RadixAttention
  • TGI(Text Generation Inference) — Hugging Face の運用フレンドリーなサーバ
  • NVIDIA Triton + TensorRT-LLM — NVIDIA エコシステムのフルスタック
  • Modular MAX — Mojo チームの新陣営
  • KTransformers — long-context・MoE 最適化

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

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

  • llama.cpp — C++ コア、GGUF フォーマット、CPU/GPU 二刀流
  • MLX(Apple) — Apple Silicon 専用
  • llamafile(Mozilla) — 単一の実行バイナリ
  • Ollama — llama.cpp をラップした最も簡単なローカル LLM
  • LM Studio — GUI ファーストのローカル
  • GPT4All — コミュニティ主導のデスクトップチャット
  • MLC LLM — モバイル・Web GPU・多様なハードウェア

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

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

  • Together AI — OSS モデルホスティングの兄貴分
  • Fireworks AI — 高スループット、強力なカスタムファインチューン
  • Groq — LPU(Language Processing Unit)自社チップ、超低遅延
  • Cerebras — wafer スケールエンジン、巨大な単一チップ
  • SambaNova — RDU 自社チップ
  • Lepton AI — 2025 年に NVIDIA が買収、NVIDIA のクラウドスタックに統合

各陣営は 異なる前提 の下で作られた。データセンター: 「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 の現状:

  • continuous batching — 異なるトークン位置にあるリクエストが同じバッチに乗る。
  • prefix caching — 同じシステムプロンプトや few-shot が繰り返される場合に KV を再利用。
  • speculative decoding — draft model でトークンを先読みし検証。
  • chunked prefill — 長い prefill を細かく分けて decode と並行。
  • disaggregated serving — prefill と decode を別の GPU に分離(P/D split)。
  • multi-modal — vision-language モデルもファーストクラス市民。
  • tool use と structured output — 関数呼び出しと JSON スキーマ強制。

典型的な 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 を使っている。

中核の質感:

  • CPU 推論が本当に実用的 — AVX/AVX2/AVX-512・ARM NEON 最適化、M シリーズでは Metal・Accelerate も。
  • GPU バックエンドが豊富 — CUDA・Metal・Vulkan・SYCL・OpenCL・ROCm・Kompute。Vulkan サポートにより事実上ほぼすべての現代 GPU で動く。
  • GGUF フォーマット — Q4_K_M・Q5_K_M・Q8_0・IQ3_XXS など多様な量子化段階、1 ファイルに重み・メタデータ・tokenizer すべてが入る。
  • メモリマップロード — モデルファイルを mmap で読むため cold start が速く、同じモデルを複数プロセスで共有可能。

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 の長所・短所:

  • 長所: どこでも動く、量子化の標準 GGUF が豊富、依存がほぼゼロ(C++ のみ)、モバイル・組み込みにも入る、コミュニティが量子化バリアントや perf パッチを速く出す。
  • 短所: 複数ユーザのスループットでは vLLM/SGLang に劣る(リクエスト batching が後発・素朴)、MoE や long-context 最適化は KTransformers/vLLM の方が速い。

いつ 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-lm — Hugging Face Hub のモデルを 1 行で取得して推論・ファインチューン。
  • MoE・long-context 加速 — Mistral・Qwen・Llama 系の MoE モデルが速く動く。
  • 量子化 — 4-bit・8-bit・6-bit・grouped quantization が組み込み。
  • 分散 — 複数の Mac を束ねて大きなモデルを推論(MLX distributed)。M3 Ultra 192GB 2 台で 405B モデルを動かす、のように。
  • mlx-vlm — vision-language モデル対応。

典型的な 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 がますます重要か:

  • M3 Ultra 192GB・M4 Max 128GB が 70B〜405B モデルを量子化後に収められるノート・デスクトップとして定着した。NVIDIA H100 80GB 1 枚に入らないモデルが unified memory には入る。
  • 開発者ノートで prototype → サーバへ移住 — MLX で作り、同じ GGUF や別フォーマットで vLLM/llama.cpp サーバに載せるワークフローが普及。
  • ファインチューンが可能 — LoRA/QLoRA が Apple Silicon で動く。CUDA なしで本当にファインチューンができる。

短所: 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 が意義深いか:

  • 配布の摩擦をほぼゼロ にした — 非技術者・教室・オフライン環境・「一度ダウンロードしてネットを切って使う」に本当に良い。
  • アーカイブ的意味 — 5 年後も同じファイルが動く見込み(APE フォーマット + 自己完結する重み)。
  • CPU 推論も最適化 — Justine Tunney が SIMD matmul カーネルを手書きしたため、同じモデルが普通の llama.cpp より CPU で速いことが多い。

短所: 単一ファイルサイズの制限(以前は 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 の現状:

  • OpenAI 互換エンドポイント — /v1/chat/completions も同時に立ち、既存クライアントコードが差し替えられる。
  • Modelfile — Dockerfile のような形式でシステムプロンプト・温度・LoRA を束ね「自分のモデル」にできる。
  • GGUF 直接インポート — Hugging Face の任意の GGUF を持ってこられる。
  • multi-modal — LLaVA・MoonDream・Llama 3.2 Vision のような vision モデル対応。
  • GPU 自動検出 — Metal・CUDA・ROCm を自動で拾う。
  • Ollama Cloud — 2025 年からクラウドホスティングも開始 — ローカルで始め、負荷が増えたらクラウドへ。

魅力はシンプルさだ。「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:

  • llama.cpp + MLX バックエンド — Apple Silicon では MLX、それ以外では llama.cpp。
  • モデル互換性表示 — RAM/VRAM に収まるかをモデルカードに事前表示。
  • ローカルサーバ — 1 トグルで OpenAI 互換サーバ。
  • multi-model loading — 一度に複数モデルロード。
  • structured output・tool use — JSON スキーマ・function calling。

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

GPT4All

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

2026 年の GPT4All:

  • デスクトップ chat UX が綺麗で、Windows・Mac・Linux で均等に磨かれている。
  • 企業向け GPT4All Enterprise(有料)で社内配備ツールを併売。
  • 「Nomic Atlas」の embedding・可視化と結びついた質感。

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 の強み:

  • agentic・tool-calling ワークロードでは vLLM 比のスループット優位がしばしば観測される(ベンチマークはワークロード依存)。
  • DeepSeek・Qwen・Llama などの MoE モデル最適化 が速く入ってくる。
  • OpenAI 互換サーバ も併せて提供され、既存クライアント互換。
  • disaggregated serving・speculative decoding も最近入った。

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

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

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

  • Hugging Face Hub と直結 — --model-id 1 行で Hub のモデルを取得・サーブ。
  • OpenAI 互換 + Messages API — 標準インターフェース。
  • continuous batching・flash attention・paged KV — 中核の加速はすべて入っている。
  • safetensors・BitsAndBytes・AWQ・GPTQ・EETQ・FP8 — 量子化対応が広い。
  • Hugging Face Inference Endpoints のバックエンド — ホスティングサービスをそのままセルフホストするという質感。
  • Grafana メトリクス・OpenTelemetry trace 組み込み。
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 モデルを動かすこと。

中核のトリック:

  • expert offloading — MoE モデルの expert 重みを CPU RAM に置き、活性化されたときだけ GPU に持ってくる。
  • CPU SIMD 加速(AMX・AVX-512) — sparse activation を CPU で効率的に回す。
  • long-context 最適化 — chunked prefill と local-global attention の組み合わせ。
  • DeepSeek・Qwen MoE 特化 — 671B DeepSeek-V3/R1 級モデルを 24GB のコンシューマ GPU + 大容量 RAM(192GB〜512GB)で動かすデモが話題になった。
# 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 が意義深いか:

  • 2025 年の DeepSeek-V3/R1、2026 年の Qwen3-MoE のような巨大 MoE モデルが OSS で出てきて、これを個人がどう動かすか が実際の課題になった。KTransformers はその答えの一つ。
  • GPU 1 枚 + 大容量 RAM の組み合わせで H100 クラスタなしに巨大モデルを動かす。

短所: 複数ユーザサービング・スループットは 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)の新命令を素早く活用するのが強み。

  • in-flight batching・paged KV・speculative decoding・chunked prefill — vLLM の加速はすべてある。
  • FP8/FP4 加速 — Hopper/Blackwell で大きなスループット向上。
  • multi-GPU・multi-node — Tensor・Pipeline・Expert parallel すべてフル対応。

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 つのグラフコンパイラで推論する という質感で位置づいた。

中核アイデア:

  • Mojo で書かれたカーネル — Python のように書いて C/CUDA レベルの性能。matmul や attention のような中核カーネルを Mojo で書くと複数アクセラレータにコンパイル可能。
  • MAX Engine — グラフコンパイラ。PyTorch/ONNX モデルを受け、NVIDIA/AMD/Apple GPU に最適化。
  • MAX Serve — OpenAI 互換 LLM サーバ。
  • ハードウェア lock-in 解消 — 「CUDA なしでも NVIDIA GPU で速く」がスローガン。
pip install modular
max serve --model-path meta-llama/Llama-3.3-70B-Instruct

2026 年の Modular の位置:

  • NVIDIA・AMD GPU の両方で vLLM 競合圏のスループット が一部ワークロードで出始めた。
  • 一部クラウド(Lambda・かつての Lepton)でバックエンド採用。
  • 学術・OSS コミュニティでの採用は vLLM/SGLang ほどではないが、「Mojo + MAX」が次世代陣営として認知されている。

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

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

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

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

GGUF(llama.cpp 系)

  • llama.cpp が作った統合フォーマット。重み + メタデータ + tokenizer を 1 ファイル。
  • 量子化段階が豊富 — Q2_K・Q3_K_S/M/L・Q4_K_S/M・Q5_K_S/M・Q6_K・Q8_0・IQ2_XXS・IQ3_XXS・IQ4_XS。
  • 実務推奨: 7B〜70B では Q4_K_M が品質・サイズのスイートスポットという合意が多い。より小さくは IQ3_XXS(2〜3-bit imatrix)、より大きくは Q5_K_M・Q6_K。
  • どこで動くか: llama.cpp・Ollama・LM Studio・llamafile・KTransformers。

AWQ(Activation-aware Weight Quantization)

  • 2023 年 MIT Han Lab 論文。activation 分布を見て重要な重みを保持しつつ 4-bit に量子化。
  • 品質維持が良いと評価され、GPU 推論に最適化されている。
  • どこで: vLLM・SGLang・TGI・TensorRT-LLM すべてが AWQ をファーストクラスでサポート。

GPTQ

  • 2022 年 ETH Zürich 論文。layer-wise OBS(Optimal Brain Surgeon)で 4-bit 量子化。
  • AWQ より早く出て一時は標準だった。2026 年には AWQ にシェアの一部を譲った雰囲気だが、今も広く使われる。
  • どこで: vLLM・SGLang・TGI・AutoGPTQ。

FP8

  • 8-bit 浮動小数点。Hopper(H100)・Ada(L40S)で初めてハードウェアとして入り、Blackwell では FP4 まで。
  • 「量子化」と呼ばれるが、訓練に近い数値精度 を保つと評される。大規模本番でスループットが大幅に上がる。
  • どこで: TensorRT-LLM・vLLM・SGLang の FP8 経路。

NVFP4 / MXFP4

  • 2024〜2025 年に NVIDIA・OCP(Open Compute)で標準化された 4-bit 浮動小数点。Blackwell GPU の新命令と結びつく。
  • 2026 年には一部の本番モデルが NVFP4/MXFP4 サービングへ移り始めた。

1 行のおすすめ:

  • ノート・ローカル → GGUF Q4_K_M
  • vLLM/SGLang に OSS 70B を載せるとき → AWQ 4-bit(または GPTQ)
  • H100 本番 → FP8
  • B100/B200 → NVFP4 / FP8 ミックス

第 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 行比較

  • 最速(低遅延) → Groq(または Cerebras)
  • OSS モデル幅最大 → Together
  • ファインチューン・structured output 品質 → Fireworks
  • 巨大モデル単一チップ → Cerebras・SambaNova(エンタープライズ)
  • NVIDIA 生態系統合 → Lepton(NVIDIA) + NIM

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

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

韓国

  • Upstage Solar — Upstage が作る Solar シリーズ(Solar 10.7B・Pro モデルなど)。小サイズで韓国語・英語両方の性能が良いと評価され、MoE・long-context バリアントが活発。Hugging Face との協業、AWS Marketplace 進出など enterprise チャネルを強くつかんだ。
  • KT Mi:dm(믿:음) — KT が作る韓国語大規模モデル。2024 年から公開・拡張され、2026 年には数十億パラメータの韓国語特化ラインナップで定着。政府・金融・通信のような規制産業で on-prem 採用が増えている。
  • NAVER HyperCLOVA X — 直接の OSS は限定的だが、NAVER Cloud Platform と束ねられ韓国エンタープライズ市場の大きな軸。multi-modal や HCX-DASH のような小型バリアントも活発。
  • LG ExaOne — LG AI Research の ExaOne ラインナップ。一部バリアントが Hugging Face で OSS 公開。

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

日本

  • Sakana AI — David Ha・Llion Jones(Transformer 共同著者)らが創業。「evolutionary model merging」で知られるラインナップ、日本語特化小型モデルや vision モデルを OSS で公開。2025 年 NVIDIA・政府支援とともに日本 AI ラインの象徴的企業。
  • NTT つづみ — NTT の日本語特化 LLM。on-prem・国内データ residency のようなガバナンス要求が大きい政府・通信市場で採用。
  • ELYZA — 東京大学発スタートアップ。Llama・Qwen など OSS ベースに日本語 continued pretraining を施し、ELYZA-japanese-Llama など OSS シリーズを継続的に公開。2024 年に KDDI 子会社化後も OSS ラインを維持。
  • Preferred Networks PLaMo — PLaMo 100B のような日本発 OSS ベースモデルライン。

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

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

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

個人 / 趣味

  • Mac ノート → MLX または LM Studio(MLX バックエンド)。量子化は Q4_K_M または 4-bit MLX。
  • Windows/Linux ノート → Ollama または LM Studio。量子化は GGUF。
  • 5 分で始める → Ollama の 1 行インストール。
  • GUI 派 → LM Studio。
  • 非技術者に渡す → llamafile。

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

  • API から始め、コスト爆発時に自前サービングへ — 最初は Together・Fireworks・OpenAI・Anthropic の API。トークンコストが月 5,000 ドルを超えたら vLLM セルフホストを比較。
  • セルフホスト開始点 → vLLM on AWS/GCP/Azure GPU(H100・L40S)。OSS モデルは AWQ・FP8。
  • agentic・tool use ヘビー → SGLang を候補に。
  • ローカル prototype + クラウド本番 → Mac で MLX/Ollama で作り、同じモデルを vLLM サーバに載せて本番。

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

  • on-prem サービング → vLLM または TGI。NVIDIA Triton + TensorRT-LLM も NVIDIA ラインなら。
  • 韓国語特化 → Upstage Solar / KT Mi:dm / HyperCLOVA X on vLLM。
  • 日本語特化 → ELYZA / Sakana / つづみ on vLLM または NTT 内部スタック。
  • 運用メトリクス・標準化 → TGI または Triton(既に NVIDIA)。
  • モデル多様性(LLM + vision + tabular) → Triton(multi-framework)。

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

  • NVIDIA H100/B100 フルスタック → TensorRT-LLM + Triton(あるいは trtllm-serve)。FP8/NVFP4。
  • OSS ファースト・多様なアクセラレータ → vLLM(NVIDIA・AMD・Intel・TPU 同時対応)。
  • structured / agentic → SGLang。
  • シングルユーザ巨大 MoE → KTransformers。

ハードウェア lock-in 回避

  • NVIDIA・AMD・Apple まで一緒に → vLLM(幅広い)または Modular MAX(コンパイラ)。
  • Apple のみ → MLX。
  • CPU 中心 / 組み込み → llama.cpp。

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

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

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

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

参考 / References

Discuss on Twitter • View on GitHub