Post
JA EN

LLM推論を速く・軽くする技術カタログ——ボトルネック別に効く手法を比較する

Posted
By
56 min read
LLM推論を速く・軽くする技術カタログ——ボトルネック別に効く手法を比較する
  • 想定読者： ローカルやクラウドでLLMを動かし、「遅い」「VRAMに載らない」「コストが高い」のどれかに悩んでいるエンジニア
  • 前提知識： Transformerの推論の大枠とGPUメモリの基本。各技術は本文で補足する
  • 所要時間： 約25分

概要

LLMが遅い、あるいはVRAMに載らない。そう感じたとき、「とりあえず量子化すれば速くなる」「GPUを足せばいい」と手当たり次第に試しても、効くときと効かないときがある。理由は単純で、LLM推論のボトルネックは1つではないからだ。容量が足りないのか、1トークンを返すのが遅いのか、同時リクエストを捌けないのか、長いプロンプトの初動が遅いのか。問題が違えば効く手も違う。

この記事の背骨になる事実が1つある。LLMの生成（デコード）は、計算ではなくメモリ帯域に律速される1。1トークン作るたびにモデルの全重みをVRAMから読み出す必要があり、読み出した重みに対して行う計算はごくわずかだからだ。だから量子化（重みのビット数を減らす）も、小さいモデルに替えることも、KVキャッシュを圧縮することも、結局は「1トークンあたりに動かすバイト数を減らす」という同じ理屈で速くなる。逆に、計算そのものを速くする工夫は、デコードではあまり効かない。

ただしこれは低バッチ（対話のような低レイテンシ運用）での話で、同時リクエストを束ねて大バッチにすると、重みの読み出しが多数のトークンで償却され、今度は計算側が効いてくる1。つまり最適化は「自分のワークロードがどのフェーズのどのボトルネックに当たっているか」を見極めてから選ぶものだ。

本記事では、量子化・KVキャッシュ削減・投機的デコード・バッチング・モデル圧縮・並列化という主要技術を、「メモリ容量」「デコード帯域（レイテンシ）」「スループット」「prefill（初動）」のどの軸に効くかで整理し、メリットと落とし穴を比較する。そのうえで、クラウド本番・ローカル単一GPU・エッジ・マネージドAPIといった環境ごとに、2026年前半時点での現実的な落としどころを示し、ボトルネック別の選び方とサービングフレームワークの選択まで通しで見ていく。先に結論を一言で言えば、まず量子化、載らないならKV削減とオフロード、対話を速くしたいなら投機的デコード、たくさん捌きたいなら連続バッチング、という優先順位になる。

まず原則：ボトルネックはどこにあるか

最適化を語る前に、推論が2つのフェーズに分かれることを押さえておく。

prefillはプロンプトを処理するフェーズで、入力トークンをまとめて1回で計算する。行列積が大きく、GPUの演算器が埋まる。ここは計算律速（compute-bound）だ。一方decodeは1トークンずつ生成するフェーズで、1ステップごとに全重みとKVキャッシュをVRAMから読み出して1トークン分の計算をする。計算量に対して読み出すデータが多すぎるので、メモリ帯域律速（memory-bandwidth-bound）になる1。

これがなぜ重要か。Roofline（演算強度を横軸、達成性能を縦軸に取る性能モデル）で見ると、Llama-2-7Bの各層の演算強度はおおむね1 OPs/byte前後で、変曲点を大きく下回る帯域律速の領域に位置する1。帯域律速の領域では、性能は「動かすバイト数」で決まる。だから重みをFP16からINT4にすれば転送量がおよそ4分の1になり、デコードのトークン生成がほぼそれに比例して速くなる1。「量子化すると速い」「小さいモデルは速い」の正体はこれだ。

注意点を先に書いておく。「decode=帯域律速」はバッチサイズに依存する。リクエストを束ねて大バッチにすると、1回読み出した重みを多数のトークンで使い回せるので演算強度が上がり、計算律速に近づく1。低レイテンシのオンライン推論と、大バッチの高スループット運用とでは、効く技術が変わる。以下ではこの軸を意識しながら各技術を見ていく。

量子化：いちばん効く一手

重みやデータをFP16より少ないビットで表す量子化は、メモリ容量を直接減らし、帯域律速のデコードを速くする。効果が大きく、まず試す価値がある。ただし「何を量子化するか」で効く場面が変わる。

重みだけを4bitにするweight-only系がGPTQ・AWQ・GGUFだ。GPTQは層ごとに二次情報を使って丸め誤差を補正するPTQ（事後量子化）で、175Bモデルを約4 GPU時間で4bit化でき、FP16比でおよそ3.25倍（A100）から4.5倍（A6000）の高速化を報告している2。AWQは活性化の分布から重要な約1%のチャネルを見つけて保護する方式で、専用カーネル上でFP16比3倍前後の速度とメモリ削減を出す3。ローカルで定番のGGUF（llama.cpp）は、ビット配分を変えた多数の型を持つ。7Bモデルの一例では、バランス型のQ4_K_Mがファイル3.80GB・perplexity増分+0.05程度、Q8_0なら6.70GB・ほぼロスレスという具合だ4。weight-onlyはデコードの帯域を減らすのが主目的なので、大バッチやprefillの計算スループットはあまり上がらない点に注意したい。

活性化も一緒に8bitにするW8A8（INT8やFP8）なら、Tensor Coreを使えるので計算律速なprefillや大バッチでも効く。SmoothQuantは外れ値を等価変換で重み側へ逃がしてINT8化を成立させ、最大1.56倍の高速化と2倍のメモリ削減を出す5。FP8はHopper（H100）以降のネイティブ対応が前提で、メモリ約2倍削減・スループット最大1.6倍を、精度への影響を最小に抑えて得られる6。逆に言えばA100世代ではFP8の恩恵はほぼ受けられない。

学習側ではQLoRA（4bitで凍結したベースにLoRAを乗せる）がメモリを大きく削るが、これは推論を速くするより学習を軽くする技術なので、詳細は姉妹記事の学習編に譲る7。

長文でメモリを食うのが重みではなくKVキャッシュなら、KVキャッシュ量子化が効く。KVQuantは3bit量子化でperplexity劣化を0.1未満に抑えつつ、LLaMA-7Bで単一A100-80GBに最大100万トークンの文脈を載せられると報告している8。重みの量子化とは独立に効かせられるので、長文・大バッチで併用する価値がある。

KVキャッシュとattentionを軽くする

KVキャッシュは、過去の全トークンのKey/Valueを保持するメモリだ。サイズは「系列長 × 層数 × KVヘッド数 × ヘッド次元」で増えるので、長文ではモデル本体の重みより大きくなり、しかもデコードのたびに全体を読み直すので帯域も食う9。ここを設計レベルで削るのが、attentionの変種だ。

MQAは全クエリヘッドで1組のKVを共有し、KVキャッシュをヘッド数分の1に減らす10。削減は大きいが品質が落ちやすい。その中間としてGQAは、クエリヘッドをグループに分けてグループごとに1組のKVを共有する。既存のMHAモデルを元の学習計算の約5%で変換でき、MQA並みの速度でMHAに近い品質を保てる9。いまのオープンモデル（Llama系やMistralなど）の事実上の標準だ。MLAはDeepSeek-V2で導入された方式で、KeyとValueを低ランクの潜在ベクトルに圧縮してキャッシュする。前世代比でKVキャッシュを93.3%削減し、最大生成スループットを5.76倍に引き上げたと報告している11。これらはモデルアーキテクチャ側の選択なので、自分で学習・変換しない限りは「そういう設計のモデルを選ぶ」という形で恩恵を受ける。

サービング側でKVキャッシュを効率化するのがPagedAttention（vLLM）だ。attentionの計算式は変えず、KVキャッシュをOSの仮想メモリのように固定サイズのブロックで管理して断片化をほぼゼロにする。空いたメモリでより多くのリクエストを同時に詰め込めるので、FasterTransformerやOrca比で2〜4倍のスループットを出す12。

attentionの計算そのものを速くするのがFlashAttentionの系統だ。N×Nのattention行列をVRAMに書き出さずタイル単位でオンチップ計算することで、メモリをO(N²)からO(N)へ落としつつ高速化する（GPT-2で約3倍）13。後継のFlashAttention-2でA100の利用率を上げ、FlashAttention-3はHopper向けにさらに1.5〜2.0倍速くしFP8にも対応した13。attentionはprefillで重いので、これは初動（TTFT）の改善に効く。

デコードのステップ数を減らす：投機的デコード

帯域律速のデコードでは、「重みを読み出す回数（=生成ステップ数）」を減らせれば速くなる。そのための技術が投機的デコード（speculative decoding）だ。共通の発想は、軽いモデルやヘッドが複数トークンを先読みドラフトし、本体モデルが1回の前向き計算でまとめて検証する、というもの。ここが肝心で、検証にrejection samplingなどを使う方式は出力が無劣化（本体単独と同じ分布）になる。速いが品質が落ちる技術ではなく、同じ出力を少ないステップで得る技術である。

いくつか系統がある。原典のdraftモデル方式は別の小さなモデルにドラフトさせる方法で、2〜3倍の高速化を出力無劣化で達成する14。別モデルを用意するのが手間なら、本体に複数の予測ヘッドを足すMedusaがあり、追加ドラフトモデルなしで2.2〜3.6倍を出す15。現行で速いのがEAGLE系で、本体の中間特徴を使って軽量ヘッドが予測する。EAGLE-3は最大6.5倍を報告している16。ドラフトモデルもヘッド学習もいらないLookahead Decodingは、Jacobi反復でn-gram候補を作る方式で、最大1.8倍程度と利得は控えめだが導入が軽い17。

落とし穴は2つ。1つは速度がacceptance rate（ドラフトの当たり率）に強く依存すること。ドメインがずれて当たらないと利得が出ない。もう1つはバッチサイズで、投機的デコードは低バッチで最も効き、大バッチではGPUがすでに飽和しているため利得が縮む（EAGLE-3はこの弱点の改善を狙った世代だ）16。要約や編集のように入力と出力の語彙が重なるタスクなら、プロンプト中の文字列一致から候補を引くn-gram系（prompt lookup）も軽量で効く。

スループットを上げる：バッチングとキャッシュ

同時に多数のリクエストを捌きたいなら、見る軸はレイテンシではなくスループットになる。

連続バッチング（continuous batching）は、静的バッチのように全リクエストの完了を待たず、シーケンスが終わるたびに新しいリクエストをイテレーション単位で投入してGPUのアイドルをなくす。Anyscaleのベンチでは、素朴な静的バッチ比で単体約8倍、PagedAttentionと併用して最大23倍のスループットを報告している18。ただしこの倍率は「素朴な実装」が基準で、すでに最適化された動的バッチが相手ならもっと小さい。

プレフィックスキャッシュは、共通するプロンプト冒頭のKVキャッシュを再利用してprefillをスキップする。システムプロンプトが共通の場合やマルチターン会話、同じ長文ドキュメントへの繰り返し質問で効き、TTFTを下げる19。ここで効くのはprefillだけで、生成（decode）フェーズは1ミリ秒も短くならない点は公式も明記している19。共通プレフィックスがなく生成が長いワークロードでは利得はゼロだ。商用APIのprompt cachingも原理は同じで、課金トークンの削減とTTFT短縮をもたらす。

モデルを小さく・分散する

技術で絞り切れないときは、モデルそのものに手を入れるか、複数GPUに分ける。

蒸留（distillation）は大きい教師モデルの出力分布を小さい生徒に学ばせる。DistilBERTはサイズ40%減・推論60%高速化で性能97%維持という代表値を出している20。枝刈り（pruning）は重要度の低い重みを削る。ヘッドやニューロン単位で削る構造化枝刈りはハードで素直に速くなるが、個々の重みを削る非構造化スパース性は専用カーネルがないと実速度に乗りにくい21。

MoEはFFNを複数expertに分け、トークンごとに一部だけを活性化する。Mixtral 8x7Bは総46.7Bパラメータのうちトークンあたり12.9Bだけを使い、70Bクラス並みの性能をおよそ6倍速い推論で出す22。ただし注意したいのは、MoEはメモリ容量を減らさないこと。推論時はどのexpertが選ばれるか分からないので全expertをVRAMに載せる必要があり、むしろ容量は大きい。速いのは「1トークンで読む重み（active params）が少ない」からで、これも帯域律速の原則の表れだ。

単一GPUに載らないときは並列化になる。Tensor Parallelism（TP）は各層の重みを複数GPUで横分割し、レイテンシを下げられるが、層ごとにall-reduceが走るのでNVLinkのような高速インターコネクトが前提だ。Pipeline Parallelism（PP）は層をステージに分けて配置し、通信はステージ間の隣接転送だけなので帯域の細い環境（複数ノードやPCIe）に向くが、パイプラインのバブルで単一リクエストのレイテンシは増える23。実運用ではノード内TP×ノード間PPのハイブリッドが一般的だ。どうしてもVRAMに収まらないなら、llama.cppの部分オフロードでGPUに載せる層数を指定し、残りをCPUで回す手もある。ただしVRAMから溢れた瞬間にスループットが急落する「帯域の崖」があり、CPU RAMの遅い帯域に全体が律速される23。これも帯域律速の原則そのものだ。

一覧で比較する

ここまでの技術を、効く軸・代表的な数値・品質への影響・主な制約で並べる。倍率はいずれもモデル・ハード・ワークロード依存で、各出典が報告した代表値である点に注意してほしい。

技術主に効く軸代表的な数値品質への影響主な制約・欠点
量子化 (weight-only INT4)容量・デコード帯域FP16比 3〜4.5倍、メモリ約1/423軽微（型・ビット数依存）4大バッチ/prefillは効きにくい、専用カーネル前提
量子化 (W8A8 INT8/FP8)容量・計算スループット1.5〜1.6倍、メモリ約2倍減56軽微FP8はHopper以降が前提6
KVキャッシュ量子化長文の容量3bitでppl劣化<0.18軽微短文・小バッチでは効果薄
GQA / MQA / MLAKV容量・デコード帯域MLAでKV 93.3%減・5.76倍11MQAは劣化、GQAは小、MLAは同等以上911モデル設計側の選択（自前変換は要学習）
PagedAttentionスループット（KV断片化）2〜4倍12無劣化カーネルの実装複雑性
FlashAttentionprefill速度・activation容量O(N²)→O(N)、GPT-2で3倍13無劣化（厳密計算）GPU世代依存（FA3はHopper）
投機的デコードデコードレイテンシ2〜6.5倍141516無劣化（分布一致）acceptance rate依存、大バッチで縮む
連続バッチングスループット単体8倍、PagedAttn併用23倍18無劣化素朴実装比の値、同時数に依存
プレフィックスキャッシュTTFT・prefillプレフィックス長次第（固定倍率なし）19無劣化decodeには無効、共通prefix前提
蒸留容量・帯域・レイテンシ40%減・60%速・97%維持20多少劣化しうる別途学習が必要
枝刈り容量・（構造化なら）計算スパース率次第高スパースで劣化21非構造化は専用カーネル要
MoE計算・デコード帯域Mixtralで約6倍22設計依存容量は減らない（全expert常駐）
TP / PP容量・レイテンシ/スループット環境依存23無劣化TPは高速接続必須、PPはバブル

投機的デコード・PagedAttention・連続バッチング・プレフィックスキャッシュ・FlashAttentionが「無劣化」で並ぶ点に注目したい。これらは出力を変えずに速くする技術なので、品質トレードオフを気にせず積める。一方、量子化・蒸留・枝刈り・MoEは多かれ少なかれ品質と引き換えになる。

フレームワークが効きどころを束ねる

個別技術を1つずつ実装する必要はない。サービングフレームワークが主要な最適化をまとめて積んでくれる。選ぶ基準は「どの環境で動かすか」だ。

クラウドやサーバGPUで高スループットのエンドポイントを立てるならvLLMが定番で、PagedAttentionと連続バッチングを核に、量子化・プレフィックスキャッシュ・投機的デコード・torch.compileまで一通り積める1224。NVIDIA GPUで性能を限界まで引き出すならTensorRT-LLMだが、NVIDIA専用で構築コストは高い。共通プレフィックスの再利用（RadixAttention）や構造化生成・エージェント用途に強いのがSGLangで、近年のベンチではvLLMと同等以上を出す場面もある23。ローカルやエッジ、CPU混在の制約環境ならllama.cppで、GGUF量子化とCPU+GPUオフロードで幅広いハードに対応する。その上に乗るOllamaは、個人や開発時の手軽さが売りだ。なお、かつて定番だったHugging FaceのTGIは2026年時点で保守モードに入っており、新規採用の第一候補にはしにくい23。

環境別の現実解（2026年前半）

ボトルネックの話とは別に、「どこで動かすか」でも落としどころが変わる。この分野は動きが速く、半年で序列が入れ替わるので、以下はあくまで2026年前半時点の定番として読んでほしい。最後は自分のワークロードで計測するのが前提だ。

クラウド・サーバGPUで多人数に提供する本番なら、まずvLLMが無難な標準だ。連続バッチングとPagedAttentionでスループットを稼ぎ、weight量子化（H100世代ならFP8、それ以外はAWQ）とプレフィックスキャッシュ、投機的デコードを乗せる。RAGやマルチターンのように共通プレフィックスが多いワークロード、あるいはreasoning系モデルでは、RadixAttentionを持つSGLangがvLLMを上回ることがある。両者は互いに追い越し合っている関係なので、候補を2つに絞って自分の負荷で比べるのが正攻法だ25。NVIDIA固定でモデルが安定していて、十数%から3割ほどの上積み（ベンチによる）のためにコンパイル待ちと特殊化の手間を許容できるならTensorRT-LLMが最速になる25。逆に、その手間に見合わないなら多くのチームはvLLMで十分だ。

ローカルの単一GPU（24GB以下、開発・個人利用）では、速さより「載るか」が先に来る。GGUFのQ4_K_Mあたりで量子化してllama.cppで動かすのが定石で、手軽さを優先するならその上のOllamaがいい。モデル選びの段階でGQAやMLA設計のものを選んでおくと、長文でKVキャッシュに詰まりにくい。

CPUのみ・Apple Silicon・エッジといった非NVIDIA環境では、選択肢は実質llama.cpp系になる。低ビットのGGUFと部分オフロードで動かすが、VRAM（やRAM）から溢れた瞬間にスループットが急落する帯域の崖に注意する。低同時実行の社内ツールやオフライン用途には十分だが、顧客向けの規模には向かない25。

自前でサーバを運用したくないなら、prompt cachingに対応したマネージドAPIを使うのが現実的だ。共通プレフィックスのキャッシュで課金トークンとTTFTを下げられる。複数モデルをコスト・品質で使い分けたいなら、その手前にルーティング層を置く手もある。

モデルが単一GPUに載らない規模なら、マルチGPUの並列化に進む。ノード内はNVLink前提のTensor Parallelism、ノードをまたぐならPipeline Parallelism、というハイブリッドをvLLMやTensorRT-LLMで組むのが一般的だ。

環境現時点の定番主に効かせる技術
クラウド本番（多人数・高スループット）vLLM / SGLang連続バッチング・PagedAttention・FP8/AWQ・投機的デコード
NVIDIA固定で性能最優先TensorRT-LLM上記 + FP8 + コンパイル最適化（手間とトレードオフ）
ローカル単一GPU（開発・個人）llama.cpp / OllamaGGUF Q4量子化・GQA/MLAなモデル選択
CPU・Apple Silicon・エッジllama.cpp低ビットGGUF・部分オフロード（帯域の崖に注意）
自前運用なし（API/マネージド）prompt caching対応APIプレフィックス/プロンプトキャッシュ・ルーティング
単一GPUに載らない大規模vLLM / TensorRT-LLM + 並列化ノード内TP × ノード間PP

ボトルネック別の選び方

優先順位を実務の流れで言うとこうなる。

まずVRAMに載るかを量子化で解決する。weight-only INT4（GGUF/AWQ/GPTQ）はメモリを約4分の1にしつつデコードも速くなるので、ほぼ常に最初の一手だ。それでも載らないなら、長文ならKVキャッシュ量子化、それでも足りなければオフロードや並列化に進む。ただしオフロードは帯域の崖に注意する。

対話のように1トークンの速さが効くなら、weight-only量子化に加えて投機的デコードを乗せる。出力が無劣化なので品質の心配がいらないのが強い。さらに速くしたいなら、そもそも小さい（蒸留・GQA/MLA設計の）モデルに替える。

たくさんのリクエストを捌きたいなら、レイテンシより連続バッチングとPagedAttentionだ。共通プロンプトがあるならプレフィックスキャッシュでprefillを削る。この領域は自前実装よりvLLMやSGLangに任せるのが早い。

長いプロンプトの初動（TTFT）が遅いなら、FlashAttention対応のフレームワークを使い、プレフィックスが共通なら再利用する。W8A8/FP8はprefillの計算も速くする。

迷ったら、量子化済みモデルをvLLMかllama.cppで動かすところから始め、計測してから次の一手を決めるのがいい。ボトルネックは測らないと分からないし、測れば次に効く技術はおのずと決まる。

注意点と限界

ここまでの数値は、すべてモデル・ハードウェア・カーネル・ワークロードに依存する。出典が報告した代表値であって、自分の環境で同じ倍率が出る保証はない。最初に計測環境を用意し、変更前後を同じ条件で比べることが何より大事だ。

いくつか誤解しやすい点を改めて挙げておく。「decode=帯域律速」は低バッチ前提で、大バッチでは計算側も効いてくる。MoEはメモリ容量を減らさない（active paramsが減るだけ）。プレフィックスキャッシュはprefillにしか効かない。FP8はHopper以降が前提でA100では使えない。weight-only量子化の速度は専用カーネルがあって初めて出る。これらを取り違えると、効かない技術に時間を使うことになる。

そして大前提として、ここで挙げた技術は「いまのモデルを速く・軽くする」ための工夫であって、必要な品質が出ないモデルを救うものではない。最適化に入る前に、そもそも用途に足るモデルを選べているかを確かめておきたい。

まとめ

LLM推論の最適化は、単一の「速くするボタン」ではなく、ボトルネック別の手当てだ。デコードがメモリ帯域に律速されるという1つの原則が、量子化・KV削減・小型化・投機的デコードがなぜ効くのかを貫いて説明する。

最優先で解きたい問題第1の手次の手
VRAMに載らないweight-only INT4量子化KV量子化 → オフロード/並列化
1トークンが遅い（対話）量子化 + 投機的デコード蒸留/GQA・MLA設計の小型モデル
同時リクエストを捌けない連続バッチング + PagedAttentionプレフィックスキャッシュ
長文プロンプトの初動が遅いFlashAttentionプレフィックス再利用 / W8A8・FP8

今日試すなら、手元のモデルを4bit量子化（GGUFかAWQ）してvLLMかllama.cppで動かし、量子化前と後でトークン生成速度とVRAM使用量を測ってみるのがいい。帯域律速がどう効くか、数字で一度見ておくと、次にどの技術へ進むべきかの判断がぶれなくなる。

この記事はモデルを「運用する」側の最適化に絞った。自分で学習やfine-tuneまで手がけるなら、コストの出どころが変わる。MoEが同じ計算予算でなぜ大きなモデルを学習できるのか、QLoRAや蒸留が学習リソースをどう削るのかは、姉妹記事「LLMの学習・fine-tuneを軽くする技術カタログ」で扱う。

関連記事

このテーマに関連する他の記事もご覧ください：

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。倍率・削減率は各出典が特定の条件下で報告した値であり、環境により変動します。

  1. LLM Inference Unveiled: Survey and Roofline Model Insights - Zhihang Yuan et al. (2024). prefillは計算律速・decodeはメモリ帯域律速であることをRooflineモデルで定量的に示し、量子化がメモリアクセスを減らして高速化する理屈を解説。【信頼性: 中〜高（サーベイ論文・プレプリント）】 ↩︎ ↩︎2 ↩︎3 ↩︎4 ↩︎5 ↩︎6

  2. GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers - Elias Frantar et al. (2022). 二次情報を使う重みのみPTQ。175Bを約4 GPU時間で3〜4bit化、FP16比3.25〜4.5倍。【信頼性: 中〜高（ICLR 2023採択）】 ↩︎ ↩︎2

  3. AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration - Ji Lin et al. (2023, MLSys 2024 Best Paper). 活性化分布から重要チャネルを保護する4bit量子化。専用カーネルでFP16比3倍前後。【信頼性: 中〜高（査読付き受賞論文）】 ↩︎ ↩︎2

  4. llama.cpp quantize README / 7B量子化ベンチ - ggml-org. GGUF各型のサイズとperplexity増分（7B例: Q4_K_M 3.80GB/+0.0535, Q8_0 6.70GB/+0.0004）。【信頼性: 中（公式リポジトリのベンチ）】 ↩︎ ↩︎2

  5. SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models - Guangxuan Xiao et al. (2022, ICML 2023). 外れ値を等価変換で重みへ移しW8A8（INT8）化。最大1.56倍・メモリ2倍減。【信頼性: 中〜高（査読付き）】 ↩︎ ↩︎2

  6. FP8 W8A8 Quantization (vLLM公式ドキュメント) - vLLM. FP8でメモリ約2倍削減・スループット最大1.6倍、Hopper（H100）/Ada以降が前提。【信頼性: 中〜高（公式ドキュメント）】 ↩︎ ↩︎2 ↩︎3

  7. QLoRA: Efficient Finetuning of Quantized LLMs - Tim Dettmers et al. (2023, NeurIPS 2023). NF4・double quant・paged optimizerで65Bを単一48GB GPUで16bit相当の品質でfine-tune。【信頼性: 中〜高（査読付き）】 ↩︎

  8. KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization - Coleman Hooper et al. (2024). KVキャッシュの3bit量子化でppl劣化<0.1、LLaMA-7Bで単一A100に最大100万トークン文脈。【信頼性: 中（プレプリント）】 ↩︎ ↩︎2

  9. GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints - Joshua Ainslie et al. (2023, EMNLP 2023). クエリヘッドをグループ化してKVを共有。元学習の約5%でMHAから変換、MQA並みの速度でMHA近傍の品質。【信頼性: 中〜高（査読付き）】 ↩︎ ↩︎2 ↩︎3

  10. Fast Transformer Decoding: One Write-Head is All You Need - Noam Shazeer (2019). 全クエリヘッドで単一KVを共有するMQA。KVキャッシュをヘッド数分の1に削減。【信頼性: 中〜高（原典論文）】 ↩︎

  11. DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model - DeepSeek-AI (2024). KeyとValueを低ランク潜在ベクトルに圧縮するMLA。KVキャッシュ93.3%削減・最大生成スループット5.76倍。【信頼性: 中〜高（技術報告・実測）】 ↩︎ ↩︎2 ↩︎3

  12. Efficient Memory Management for Large Language Model Serving with PagedAttention - Woosuk Kwon et al. (2023, SOSP 2023). KVキャッシュをOS風のページで管理し断片化をほぼ排除、FasterTransformer/Orca比2〜4倍のスループット。vLLMの中核。【信頼性: 高（査読付き・トップ会議）】 ↩︎ ↩︎2 ↩︎3

  13. FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness - Tri Dao et al. (2022). IO-awareなタイル計算でN×N行列を書き出さず、メモリO(N²)→O(N)・高速化。後継のFlashAttention-2（2307.08691）、FlashAttention-3（2407.08608、Hopper向け1.5〜2倍・FP8対応）。【信頼性: 中〜高（広く採用・一部査読付き）】 ↩︎ ↩︎2 ↩︎3

  14. Fast Inference from Transformers via Speculative Decoding - Yaniv Leviathan et al. (2022, ICML 2023). 小さなdraftモデルが先読みし本体が並列検証。出力無劣化で2〜3倍。【信頼性: 中〜高（査読付き）】 ↩︎ ↩︎2

  15. Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads - Tianle Cai et al. (2024). 本体に複数の予測ヘッドを足すself-speculative方式。追加ドラフトモデル不要で2.2〜3.6倍。【信頼性: 中（プレプリント・広く採用）】 ↩︎ ↩︎2

  16. EAGLE-3: Scaling up Inference Acceleration of LLMs via Training-Time Test - Yuhui Li et al. (2025, NeurIPS 2025). 中間特徴を使う軽量ヘッドによる投機的デコード。最大6.5倍、大バッチでの利得縮小も改善。【信頼性: 中〜高（査読付き会議採択）】 ↩︎ ↩︎2 ↩︎3

  17. Break the Sequential Dependency of LLM Inference Using Lookahead Decoding - Yichao Fu et al. (2024, ICML 2024). ドラフトモデル不要、Jacobi反復でn-gram候補を生成・検証。出力無劣化で最大1.8倍。【信頼性: 中〜高（査読付き）】 ↩︎

  18. How continuous batching enables 23x throughput in LLM inference - Anyscale. イテレーション単位でリクエストを投入する連続バッチング。素朴な静的バッチ比で単体8倍、PagedAttention併用で最大23倍。【信頼性: 中（ベンダー公式ブログ・実測）】 ↩︎ ↩︎2

  19. Automatic Prefix Caching (vLLM公式ドキュメント) - vLLM. 共通プレフィックスのKVキャッシュ再利用。prefillのみ短縮しdecodeは短縮しないと明記。【信頼性: 中〜高（公式ドキュメント）】 ↩︎ ↩︎2 ↩︎3

  20. DistilBERT, a distilled version of BERT - Victor Sanh et al. (2019). 知識蒸留でサイズ40%減・推論60%高速化・性能97%維持。【信頼性: 中〜高（広く検証された原典）】 ↩︎ ↩︎2

  21. Model Compression and Efficient Inference for Large Language Models: A Survey - Wenxiao Wang et al. (2024). 量子化・枝刈り・蒸留を横断するサーベイ。構造化/非構造化スパース性のトレードオフを整理。【信頼性: 中（サーベイ・プレプリント）】 ↩︎ ↩︎2

  22. Mixtral of Experts - Mistral AI (2024). 総46.7B中トークンあたり12.9Bを活性化するSparse MoE。70Bクラス並みの性能を約6倍速い推論で（「Llama 2 70B比6倍」はMistral AI公式発表による）。全expert常駐のためメモリ容量は減らない。【信頼性: 中〜高（技術報告・実測）】 ↩︎ ↩︎2

  23. BentoML LLM Inference Handbook: 並列化とサービング - BentoML. Tensor/Pipeline並列のトレードオフ、フレームワーク選択の指針。あわせてSGLang (arXiv:2312.07104)、llama.cpp部分オフロードの「帯域の崖」を参照。【信頼性: 中（実務向け技術解説）】 ↩︎ ↩︎2 ↩︎3 ↩︎4 ↩︎5

  24. Introduction to torch.compile and How It Works with vLLM - vLLM (2025). torch.compileとCUDA graphsによるカーネル融合・起動オーバーヘッド削減。出力無劣化でレイテンシ/スループット改善。【信頼性: 中〜高（公式ブログ）】 ↩︎

  25. Choosing the best LLM inference engine in 2026 - BIZON (2026). 用途別の選択指針（laptop→Ollama、workstation→llama.cpp、多人数→vLLM/SGLang、NVIDIA本番→TensorRT-LLM）。あわせてH100ベンチ比較（Spheron, 2026）、HF公式のTGI保守モード移行とvLLM/SGLang推奨を参照。倍率・序列はバージョン依存で変動。【信頼性: 中（ベンダー/比較ブログ・ベンチ）】 ↩︎ ↩︎2 ↩︎3

AI・テクノロジー
LLM 推論最適化 量子化 KVキャッシュ 投機的デコード vLLM ローカルLLM
This post is licensed under CC BY 4.0 by the author.