LLM推論とは？仕組みと高速化の手法・推論基盤の選び方を実装視点で解説【2026年】

LLM推論（inference）とは、学習済みの大規模言語モデルがプロンプトを受け取り、トークンを1つずつ生成して応答を返す実行フェーズのことです。チャットの応答速度もAPI利用料も、この推論処理の効率でほぼ決まります。本記事では、PrefillとDecodeの2段階からなる処理の流れ、KVキャッシュ・連続バッチング・量子化といった高速化手法、vLLMをはじめとする推論エンジンとマネージドAPIの選び分けを実装者の視点で整理しました。紛らわしい「推論モデル（reasoning model）」との意味の違いにも触れます。

まとめ：LLM推論の要点と基盤選定の結論

LLM推論は「重みを固定したモデルに入力を与え、次トークン予測を繰り返して文章を得る処理」であり、学習とは計算の性質も費用構造も別物です。処理は入力全体を一括で扱うPrefillと、1トークンずつ生成するDecodeに分かれ、後者の速度はGPUのメモリ帯域とKVキャッシュ管理でほぼ決まります。

高速化は、基盤側のKVキャッシュ管理・連続バッチング・投機的デコーディングと、モデル側の量子化・SLM採用という二本立てで考えると整理しやすくなります。推論基盤の選定は、試作段階や月間トークン量が小さいうちはマネージドAPI、機密データを社外に送信できない場合や利用量が恒常的に大きい段階でvLLM等によるセルフホストを検討する、という順番が定石です。この判断基準は後半の章で条件付きで言い切ります。

LLM推論の基本的な仕組み：学習との違いとトークン生成の流れ

大規模言語モデルの全体像や学習フェーズの仕組みはLLMの仕組み・生成AIとの違いと企業導入の判断基準で扱っており、本記事はその実行段階である推論に絞って掘り下げます。

学習と推論の違い：モデルの重みを固定したまま応答を生成する処理

学習（トレーニング）はモデルのパラメータ（重み）を更新する工程で、推論は更新済みの重みを読み取り専用で使い、入力から出力を計算する工程です。大規模モデルの学習は数千枚規模のGPUを長期間占有しますが、推論は1リクエストあたり数秒〜数十秒で完結し、その代わり利用者の数だけ絶え間なく発生します。

費用の性質も対照的です。学習費用は一度きりの先行投資に近く、推論費用はリクエスト量に比例して積み上がる運転資金に近い構造を持ちます。LLMを組み込んだサービスの原価を左右するのは、ほぼ推論側の設計です。

PrefillとDecode：入力処理と1トークンずつの逐次生成

推論は2つのフェーズで進みます。Prefillでは入力プロンプト全体を並列に処理し、各トークンの注意（Attention）計算の結果をKVキャッシュとしてGPUメモリに保存します。続くDecodeでは直前までの文脈を踏まえて次の1トークンを予測し、出力に追加してはまた次を予測する自己回帰生成を、終了トークンが出るまで繰り返す流れです。

体感速度に直結する指標も2つに分かれます。最初の1文字が出るまでの時間（TTFT：Time To First Token）はPrefillの性能を、その後の文字が流れる速さ（トークン毎秒）はDecodeの性能を反映する指標です。チャットUIで冒頭だけ待たされるのか、生成全体が遅いのかを切り分ければ、どちらのフェーズを改善すべきか当たりが付きます。

デコード戦略とパラメータ：temperatureとtop-pの実務設定

次のトークンは確率分布から選ばれます。最も確率の高い候補だけを選ぶ貪欲法では同じ表現の繰り返しが起きやすいため、実務では確率上位からサンプリングする方式が標準です。temperatureは分布の尖り具合を制御するパラメータで、0に近づけるほど出力が決定的になり、上げるほど多様になります。

top-p（nucleus sampling）は累積確率が閾値以内の候補だけに絞る方式です。RAG検索や分類のように再現性が欲しい処理はtemperature 0〜0.3、文章生成やアイデア出しは0.7前後から調整を始めると手戻りが減ります。temperatureとtop-pを同時に変更すると挙動の切り分けが難しくなるため、動かすのはどちらか一方ずつが定石です。

「推論」が指す2つの意味：処理としての推論と推論モデルの違い

日本語の「LLM推論」は文脈によって別々の概念を指すため、技術選定の会話が噛み合わない原因になりがちです。最初にここを切り分けます。

処理としての推論（inference）：APIやGPUで動く実行フェーズ

本記事の主題であるinferenceは、モデルを動かす計算処理そのものです。「推論サーバー」「推論コスト」「推論の高速化」という言葉で使われる推論はすべてこちらで、GPUのメモリ容量・帯域、バッチ処理、キャッシュ効率といったインフラ寄りの話題に接続します。英語圏の技術文書ではinference servingやmodel servingと表記される領域です。

能力としての推論（reasoning）：o3やDeepSeek-R1系の推論モデル

もう一方のreasoningは、筋道を立てて答えを導くモデルの能力を指します。OpenAIのo1・o3系や、2025年1月に重みが公開されたDeepSeek-R1のように、回答前に思考過程のトークンを長く生成して多段の論理問題の正答率を高めたモデルが「推論モデル（reasoning model）」と呼ばれます。検索語の「LLM 推論モデル」が指すのは通常こちらです。

両者は無関係ではなく、推論モデルは思考トークンを大量に生成するぶんinferenceの計算量も増える、という関係にあります。回答までの待ち時間とトークン費用が通常モデルの数倍になり得るため、推論モデルの採用はinferenceコストの再見積もりとセットで判断する必要があります。

推論を速く・安くする高速化手法：KVキャッシュ・バッチング・量子化

推論の高速化は、推論基盤（サービング層）で効く手法と、モデル自体を軽くする手法に大別できます。前者は出力品質を落とさず、後者は精度との交換になる点が実務上の分かれ目です。

KVキャッシュとPagedAttention：メモリ管理が速度を決める

Decodeのたびに過去の全トークンを計算し直すと、処理量が文脈長の2乗で膨らみます。そこで計算済みの注意情報（KeyとValue）をGPUメモリに保持して再利用する仕組みがKVキャッシュです。長い文脈や同時接続が増えるほどこのキャッシュがメモリを圧迫し、推論スループットの上限を決める主因になります。キャッシュの内部構造とメモリ削減の実装判断はKVキャッシュの仕組みとメモリ削減・実装判断で個別に解説しています。

推論エンジンvLLM（2026年7月時点でv0.2x系）が実装したPagedAttentionは、KVキャッシュをOSの仮想メモリのような固定サイズブロックに分割して配置する手法で、メモリの断片化を抑えて同時処理数を引き上げました。2023年発表の論文に由来する技術ですが、現在は同種の仕組みが各推論エンジンへ広がり、サービング基盤を選ぶ際の前提機能になっています。

連続バッチングと投機的デコーディング：スループット向上の定石

GPUは同時に多くの系列を処理するほど効率が上がるため、複数リクエストをまとめて処理するバッチングが基本手段になります。生成の終わったリクエストの席をすぐ次のリクエストへ割り当てる連続バッチング（continuous batching）は、固定バッチに比べてGPUの遊休を減らし、同時アクセスの多いチャットサービスで特に効きます。

投機的デコーディング（speculative decoding）は、小型のドラフトモデルに数トークン先まで下書きさせ、本命モデルが一括で検証して採否を決める手法です。出力の確率分布を変えずに生成を数割速められる場合がある一方、下書きの採択率が低いタスクでは効果が出にくいため、対象ワークロードでの実測を挟んでから本採用する運びが安全です。

量子化・SLM・エッジ実行：モデル側を軽くする3つのアプローチ

モデル側の軽量化で第一候補になるのが、重みを16bitから8bit・4bitへ圧縮する量子化です。必要GPUメモリをおよそ2分の1〜4分の1に抑えられる一方で精度低下との綱引きになるため、GPTQ・AWQ・GGUFといった方式ごとの特性と選び方はLLM量子化の仕組みと方式の違い・採用判断で個別に解説しています。

タスクを絞れるなら、最初から小さいモデル（SLM）を選ぶ手もあります。分類・抽出・定型応答のような用途では、7B前後のモデルで足りるケースが少なくありません。さらに通信させず端末側で推論するエッジ実行という選択肢もあり、遅延要件や通信環境の制約が厳しい現場で検討対象になります。

推論基盤の選択肢：マネージドAPIとセルフホスト推論エンジンの比較

推論をどこで動かすかの選択肢は、事業者のAPIを呼ぶ形態と、自前のGPU環境で推論エンジンを運用する形態に分かれます。それぞれの内訳を見たうえで、観点別に比較します。

マネージドAPIの選択肢：OpenAI・Anthropic・Bedrockの課金構造

OpenAI APIやAnthropic APIは、入力・出力トークン数に応じた従量課金で、インフラの用意なしに最新モデルを呼び出せます。AWS BedrockやAzure OpenAI Service、Google CloudのVertex AIといったクラウド経由の提供形態を使うと、既存クラウドの請求・権限管理・閉域網接続に載せられるため、企業システムからの利用ではこちらが選ばれる場面が目立ちます。

従量課金は初期費用がない反面、リクエスト量に厳密に比例して費用が伸びます。プロンプトの共通部分を再利用して入力単価を下げるプロンプトキャッシュや、応答を急がないジョブ向けのバッチ実行割引など、各社の割引メニューの使い方しだいで実効単価が大きく変わるため、モデル単価表だけの比較は判断を誤らせます。

セルフホスト推論エンジン：vLLM・llama.cpp・Ollamaの使い分け

自前のGPUサーバーで推論を担う場合、サービング基盤の実質標準になりつつあるのがvLLMです。PagedAttentionと連続バッチングを備え、OpenAI互換APIを公開できるため、API利用からの載せ替え先としてまず候補に挙がります。NVIDIAのTensorRT-LLMは同社GPUに特化した高速化が持ち味で、高負荷の本番環境を中心に採用されています。

llama.cppはGGUF形式の量子化モデルをCPUや家庭用GPUでも動かせる軽量実装で、その使い勝手を整えたOllamaは手元検証の定番になりました。ローカル環境の必要スペックと構築手順はローカルLLMの必要スペックとOllamaでの構築手順にまとめています。

マネージドAPIとセルフホストの比較：費用・データ・運用の違い

両者の違いを検討観点ごとに並べると次の通りです。

費用の形とデータの置き場所が二大論点です。この2つを自社の条件に当てはめる判断基準を、次の章で具体化します。

自前の推論基盤を持つべき企業とAPI利用で足りる企業の判断基準

ここまでの整理を踏まえ、どちらを選ぶかを条件付きで言い切ります。

セルフホストを選ぶ条件：月間トークン量・データ要件・運用体制

セルフホストが割に合うのは、次の3条件のうち2つ以上に当てはまる場合と判断しています。

• 規程・契約上の制約で、機密データを社外のAPIへ送信できない
• 推論量が恒常的に多く、API従量課金がGPUサーバーの月額運用費を上回り続けている
• GPUサーバーの監視・障害対応・モデル更新を担える技術者を確保できる

逆に、どれか1つだけ、たとえば費用だけを理由にした移行は、運用負荷の見積もり漏れで失敗しやすいパターンです。量子化済みの7B〜32Bクラスを1〜2枚のGPUで動かす構成なら初期投資を抑えられますが、その規模で品質が足りるかはタスク次第のため、ローカルLLMでの事前検証を挟む段取りを推奨します。

APIで足りる場面と自前推論基盤が過剰投資になる失敗パターン

試作・PoC段階、月間の推論量が小さい社内ツール、要求品質が高く最上位モデルが必要な用途では、マネージドAPIで足ります。この段階でGPUサーバーを先に買う判断は、利用が伸びなかったときに固定費だけが残る典型的な過剰投資です。まずAPIで小さく当て、実測トークン量が数か月分たまってからセルフホストを試算する順番を採るべきと考えています。

どのモデル・どの基盤を選ぶ場合でも、自社データでの精度検証と負荷試験は避けて通れません。株式会社一創では、モデル選定から推論基盤の構築・業務システムへの組み込みまでを生成AI導入支援サービスとして請け負っており、APIとセルフホストの試算比較の段階からの相談にも対応しています。

よくある質問

LLM推論について検索で尋ねられることの多い質問に回答します。

LLMの推論と学習は何が違いますか？

学習は大量のテキストからモデルの重み（パラメータ）を更新して能力を作り込む工程で、推論は出来上がった重みを固定したまま入力に応答を返す工程です。学習は一度きりの大規模計算、推論はリクエストのたびに発生する継続的な計算という違いがあり、サービス運用の費用はほぼ推論側で決まります。既存モデルに自社知識を反映したい場合は、学習のやり直しではなくRAGやファインチューニングを検討する段取りが一般的です。

推論モデル（reasoning model）は通常のLLMと何が違いますか？

推論モデルは、回答の前に思考過程にあたるトークンを長く生成し、多段の論理が必要な問題の正答率を高めたモデルです。OpenAIのo1・o3系やDeepSeek-R1が該当します。内部的には通常のLLMと同じ次トークン予測で動くため、処理としての推論（inference）の仕組みは変わらず、思考トークンの分だけ応答時間と費用が増える特性があります。単純な要約や分類に使うと費用対効果が合いません。

KVキャッシュとは何ですか？

Decodeフェーズで過去トークンの注意計算の結果（KeyとValue）を保存しておき、次トークンの生成時に再利用するGPUメモリ上の領域です。これが無いと文脈長の2乗に比例する再計算がトークンごとに発生します。一方で文脈が長くなるほどキャッシュ自体がGPUメモリを圧迫するため、PagedAttentionのようなブロック管理や、キャッシュを量子化して節約する手法が使われています。

LLM推論の高速化はどこから手を付ければよいですか？

現状の測定が先です。TTFT（最初のトークンまでの時間）とトークン毎秒を分けて測り、前者が遅ければプロンプト長の削減やプロンプトキャッシュ、後者が遅ければバッチング設定・量子化・GPU増強という順に対処します。API利用なら出力トークン数の上限設定と軽量モデルへの振り分け、セルフホストならvLLM等の連続バッチング対応が効きます。測定なしのチューニングは効果検証のしようがない点に注意してください。

推論コストはAPIとセルフホストのどちらが安いですか？

月間の推論量しだいです。少量ならインフラ費も運用人件費も掛からないAPIが安く、推論量が恒常的に大きい場合はGPU費用が定額に近いセルフホストが逆転し得ます。境目は使うモデルの規模・GPU価格・割引メニューの使い方で大きく動くため、実測トークン量にもとづく試算が前提です。データを社外に出せない要件がある場合は、費用に関係なくセルフホストか閉域接続型のクラウド提供を選ぶことになります。

関連記事

• GGUFとは？量子化モデルフォーマットの仕組みとGPTQ・AWQとの違い・採用判断を解説【2026年版】：セルフホスト推論で扱う量子化フォーマットの詳細
• SLMとは？小規模言語モデルの仕組み・LLMとの違いと実装判断を解説：モデル選定側から推論コストを下げる選択肢
• エッジAIとは？クラウドAIとの違い・仕組み・実装の判断基準を解説：端末側で推論を実行する構成の判断基準