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

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 呼び出しを書くが、**分岐・反復・並列・制約** がファーストクラスだ。

@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

- vLLM — [github.com/vllm-project/vllm](https://github.com/vllm-project/vllm) / [docs.vllm.ai](https://docs.vllm.ai/)

- vLLM PagedAttention 論文 — ["Efficient Memory Management for Large Language Model Serving with PagedAttention"](https://arxiv.org/abs/2309.06180)

- llama.cpp — [github.com/ggerganov/llama.cpp](https://github.com/ggerganov/llama.cpp)

- MLX(Apple) — [github.com/ml-explore/mlx](https://github.com/ml-explore/mlx) / [ml-explore.github.io/mlx](https://ml-explore.github.io/mlx/build/html/index.html)

- mlx-lm — [github.com/ml-explore/mlx-lm](https://github.com/ml-explore/mlx-lm)

- llamafile(Mozilla) — [github.com/Mozilla-Ocho/llamafile](https://github.com/Mozilla-Ocho/llamafile)

- Justine Tunney "LLaMA Now Goes Faster on CPUs" — [justine.lol/matmul](https://justine.lol/matmul/)

- Ollama — [ollama.com](https://ollama.com/) / [github.com/ollama/ollama](https://github.com/ollama/ollama)

- LM Studio — [lmstudio.ai](https://lmstudio.ai/)

- GPT4All(Nomic AI) — [gpt4all.io](https://www.nomic.ai/gpt4all) / [github.com/nomic-ai/gpt4all](https://github.com/nomic-ai/gpt4all)

- SGLang — [github.com/sgl-project/sglang](https://github.com/sgl-project/sglang) / [lmsys.org/blog/2024-01-17-sglang](https://lmsys.org/blog/2024-01-17-sglang/)

- TGI(Hugging Face) — [github.com/huggingface/text-generation-inference](https://github.com/huggingface/text-generation-inference)

- KTransformers(Tsinghua) — [github.com/kvcache-ai/ktransformers](https://github.com/kvcache-ai/ktransformers)

- MLC LLM — [github.com/mlc-ai/mlc-llm](https://github.com/mlc-ai/mlc-llm) / [llm.mlc.ai](https://llm.mlc.ai/)

- NVIDIA TensorRT-LLM — [github.com/NVIDIA/TensorRT-LLM](https://github.com/NVIDIA/TensorRT-LLM)

- NVIDIA Triton Inference Server — [github.com/triton-inference-server/server](https://github.com/triton-inference-server/server)

- Modular MAX — [docs.modular.com/max](https://docs.modular.com/max/) / [modular.com](https://www.modular.com/)

- AWQ paper — ["AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration"](https://arxiv.org/abs/2306.00978)

- GPTQ paper — ["GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers"](https://arxiv.org/abs/2210.17323)

- FP8 Formats for Deep Learning — [arxiv.org/abs/2209.05433](https://arxiv.org/abs/2209.05433)

- Together AI — [together.ai](https://www.together.ai/)

- Fireworks AI — [fireworks.ai](https://fireworks.ai/)

- Groq — [groq.com](https://groq.com/)

- Cerebras — [cerebras.ai](https://www.cerebras.ai/)

- SambaNova — [sambanova.ai](https://sambanova.ai/)

- Lepton AI(NVIDIA 買収、2025) — [news.crunchbase.com Lepton coverage](https://news.crunchbase.com/ai/nvidia-acquires-lepton-jia/) / [lepton.ai](https://www.lepton.ai/)

- NVIDIA NIM — [nvidia.com/en-us/ai/](https://www.nvidia.com/en-us/ai/)

- Upstage Solar — [upstage.ai](https://www.upstage.ai/) / [huggingface.co/upstage](https://huggingface.co/upstage)

- KT Mi:dm — [kt.com AI](https://www.kt.com/) / [huggingface.co/KT-AI](https://huggingface.co/KT-AI)

- NAVER HyperCLOVA X — [clova.ai](https://clova.ai/) / [ncloud.com HyperCLOVA X](https://www.ncloud.com/product/aiService/clovastudio)

- LG ExaOne — [lgresearch.ai exaone](https://www.lgresearch.ai/exaone) / [huggingface.co/LGAI-EXAONE](https://huggingface.co/LGAI-EXAONE)

- Sakana AI — [sakana.ai](https://sakana.ai/)

- NTT つづみ — [group.ntt tsuzumi](https://group.ntt/en/newsrelease/2023/11/01/231101a.html)

- ELYZA — [elyza.ai](https://elyza.ai/) / [huggingface.co/elyza](https://huggingface.co/elyza)

- Preferred Networks PLaMo — [preferred.jp](https://www.preferred.jp/en/) / [huggingface.co/pfnet](https://huggingface.co/pfnet)