推論ランタイムとは何か

モデルは「楽譜」、ランタイムは「演奏者」

ここでいう推論（inference）は、学習済みの重みを使って答えを出すことです。重みを変える「学習」とは別のイベントで、推論のあいだモデルの中身は一切変わりません（第1章）。

だから「同じモデルなのに、アプリによって速さが全然違う」ということが起きます。速さの差はモデルではなく、ほとんどがランタイムと、その下で使っているハードウェアの差です。

flowchart TD
  A["モデルファイル
重み・トークナイザ"] --> R["推論ランタイム"]
  P["あなたの入力
プロンプト"] --> R
  R --> H["CPU・GPUで計算"]
  H --> R
  R --> O["返事
1トークンずつ"]

ランタイムが毎回やっている5つの仕事

「こんにちは」と送ってから返事が出るまでに、ランタイムの中ではだいたい次の順番で処理が進みます。どのランタイムでも骨格は同じです。

1. 読み込み（ロード） — モデルファイルの重みをメモリ（RAMやGPUのVRAM）に載せます。大きなモデルほど時間がかかるので、多くのランタイムは一度載せたら一定時間そのまま置いておきます。
2. 前処理 — 会話をモデルが学習時に見た書式（チャットテンプレート）に整え、トークナイザで数字の列（トークンID）に変換します。
3. 計算（フォワードパス） — トークン列をモデルに通し、「次に来るトークン」の確率分布を出します。ここが一番重い処理です。
4. サンプリング — 確率分布から1つのトークンを選びます。温度（temperature）や top-p はここで効きます（第2章）。
5. 後処理と出力 — 選んだトークンを文字に戻して画面に流し、3〜5を「終わりの記号」が出るまで繰り返します。

flowchart TD
  L["1 ロード
重みをメモリへ"] --> T["2 前処理
テンプレートとトークン化"]
  T --> F["3 計算
次トークンの確率"]
  F --> S["4 サンプリング
1つ選ぶ"]
  S --> D["5 文字に戻して表示"]
  D --> E{"終わりの記号？"}
  E -- "いいえ" --> F
  E -- "はい" --> Z["返事完成"]

チャット画面で文字がパラパラと流れてくるのは、演出ではなくこのループの結果です。1周ごとに1トークンずつしか決まらないので、出てきた順に表示しているのです。

速さは2種類ある: プリフィルとデコード

プリフィルでは、入力されたトークンをまとめて一気に計算できます。並列に計算できる量が多いので、GPUの計算性能（FLOPS）が効きます。長い文書を貼り付けたときに「最初の1文字が出るまで」待たされるのは、このプリフィルの時間です。

デコードは1トークンずつしか進めません。1トークン作るたびに、モデルの重み全体と、これまでの文脈の情報をメモリから読み出す必要があります。計算そのものは少ないのに読み出しが多いので、効くのはメモリ帯域（1秒あたりに運べるデータ量）です。

デコードの速さの上限は「メモリ帯域 ÷ 1トークンで読み出す重みの量」でざっくり見積もれます。量子化で重みを小さくすると速くなり、MoE（第26章）では使う専門家の分だけ読めばよいので速くなる——その理由が数字で見えます。

Apple シリコンの Mac がローカルLLMで人気なのは、CPUとGPUが同じ大容量メモリを共有でき、帯域も比較的広いからです。ハードウェアの話は第17章でくわしく扱います。

KVキャッシュ: 毎回読み直さないための議事録

デコードのたびに、文章の最初から全部計算し直していたら大変です。そこでランタイムは、計算済みのトークンについて attention で使う中間結果（Key と Value）を保存しておきます。これが KVキャッシュ（KV cache）です。

KVキャッシュの大きさは、文脈の長さ（コンテキスト長）と、同時にさばく会話の数にほぼ比例します。モデルの重みが載っても、長い文脈を使うとKVキャッシュでメモリがあふれる、ということがよく起きます。下で実際に見積もってみてください。

KVキャッシュをどう置き、どう使い回すかは、ランタイムの腕の見せどころです。サーバ向けの vLLM が有名になったのも、このKVキャッシュの管理方法（PagedAttention）がきっかけでした（第9章、第15章）。

ランタイムの中の層: エンジン・バックエンド・ハードウェア

ランタイムの内側も、何層かに分かれています。上の層ほど「人に近く」、下の層ほど「チップに近い」と考えるとわかりやすいです。

flowchart TD
  A["アプリ・API
チャット画面やHTTPサーバ"] --> B["推論エンジン
スケジュールとKVキャッシュ管理"]
  B --> C["計算ライブラリ
ggml・PyTorchなど"]
  C --> D["バックエンド
CUDA・Metal・Vulkanなど"]
  D --> E["ハードウェア
CPU・GPU・NPU"]

たとえば llama.cpp は自前の計算ライブラリ ggml の上に作られ、vLLM は PyTorch の上に作られています。同じ「NVIDIA GPU で動く」でも、通っている道がまったく違うわけです。

1人用と大勢用: ローカル型とサーバ型

ランタイムは大きく2つの系統に分かれます。手元のPCで1人が使うことを重視するローカル型と、データセンターで大勢のリクエストをさばくサーバ型です。

サーバ型の鍵はバッチ処理です。デコードはメモリの読み出しが詰まりどころでした。そこで、何人分もの会話をまとめて1回の読み出しで計算すれば、同じ時間でずっと多くのトークンを作れます。リクエストが来るたびにバッチへ出し入れする「連続バッチ処理（continuous batching）」は、いまのサーバ型ランタイムの基本装備です。

とはいえ境界はゆるやかです。llama.cpp に付属するサーバ（llama-server）も複数ユーザーの並列処理や連続バッチ処理に対応していますし、vLLM も CPU や Apple シリコン向けのプラグインを持っています2026年10月時点。「どちらを主戦場として設計されたか」の違いだと考えてください。

ランタイム・ラッパー・画面: 混ざりやすい用語の整理

「Ollama は推論ランタイムですか？」という質問は、答えるのが意外とむずかしいものです。Ollama は内部で llama.cpp などのエンジンを使い、モデルのダウンロードや管理、APIサーバの機能をかぶせています。このような道具はラッパー（包むもの）と呼ばれることがあります。

ひとつの製品が複数の役割を兼ねることも普通です。LM Studio は画面・管理・APIサーバを1つにまとめ、計算は llama.cpp や MLX に任せています。ローカル向けの道具の整理は第8章で続けます。

どれを選ぶ？ ざっくりした目安

flowchart TD
  Q["誰が使う？"] --> A["自分1人・手元のPC"]
  Q --> B["チームや大勢・GPUサーバ"]
  A --> A1["まず触りたい
Ollama・LM Studio"]
  A --> A2["細かく調整したい
llama.cpp・mlx-lm"]
  B --> B1["汎用で始める
vLLM・SGLang"]
  B --> B2["NVIDIAで攻める
TensorRT-LLM"]

最初の一歩なら、まず Ollama や LM Studio で「手元で動く」体験をするのがおすすめです。慣れてきたら、その中で動いている llama.cpp を直接触ると、ランタイムの設定がどう速さやメモリに効くのかが見えてきます。

次に読む章

• 第7章 llama.cppとは何か — ローカル型ランタイムの代表を分解する
• 第8章 Ollama / LM Studio / Open WebUI / Jan など — エンジンと画面の関係
• 第9章 サーバ向け推論エンジン — vLLM・SGLang などが大勢をさばく仕組み