この記事のポイント
- LLM の内部にある仕組みは、いきなり完成形として現れたわけではなく、その時々の「困りごと」を解くために一つずつ積み上げられてきた、という見方ができます。
- 本記事では Attention / Transformer、Mixture of Experts（MoE）、KV Cache、Speculative Decoding の 4 つを、数式をほぼ使わず、「なぜそれが必要だったのか」という発明の動機から例え話で整理します。
- どの工夫にも「何かを得るために何かを犠牲にした」というトレードオフがあります。ここを意識すると、モデル選定・コスト最適化・推論パラメータの調整の判断がブレにくくなる、と私は感じています。
- 2026 年の話題として、長コンテキスト時代の文脈で重要性が増している KV Cache 圧縮（TurboQuant など） にも触れます。
はじめに：発明の動機から理解する利点
LLM の API を呼び出すだけでも、ある程度のアプリは作れます。一方で、内部の仕組みを「結果」ではなく「どんな問題を解くために生まれたのか」という順番で掴んでおくと、こんな場面で判断がブレにくくなる、と私は感じています。
- モデル選定：同じ「30B クラス」でも、密モデル（Dense）と MoE では推論コストや必要メモリが大きく違います。なぜ違うのかを知っていると、スペック表の数字の意味が変わって見えてきます。
- コスト最適化：長文プロンプトのコストが「なぜ高いのか」を、KV Cache の観点で説明できると、設計の落とし所が見えてきます。
- 推論パラメータの調整：Speculative Decoding 系の機能を持つランタイム（vLLM、TGI、llama.cpp など）では、温度や貪欲デコーディングの選び方で速度が変わります。なぜ速くなるのかが分かると、設定の試行錯誤に当たりがつけやすくなります。
技術の解説は「どう動くか（How）」から入ることが多いのですが、本記事ではできるだけ「なぜそうしたかったのか（Why）」を先に置くようにしました。発明の動機が分かると、細部を忘れても全体像が頭に残りやすい、という個人的な実感がもとになっています。
もちろん、ここで紹介する見方が唯一の正解というわけではありません。論文の説明・実装側の解説・ベンダーのブログなど、流派によって表現はかなり違うので、複数の説明を読み比べてみるのがおすすめです。
想定読者と前提
- 対象読者：LLM の API は触ったことがあるものの、内部の仕組みは「なんとなくブラックボックス」と感じている方。
- 前提知識：特別な数学やフレームワークの知識は前提にしません。例え話を中心に進めます。
- 扱う範囲：Attention / Transformer・MoE・KV Cache・Speculative Decoding の 4 つと、2026 年の話題として KV Cache 圧縮を加えます。RoPE / SwiGLU は概要だけにとどめます。
数式の導出やコードの実装には踏み込みません。そこを深掘りしたい方は、末尾の参考リンク（論文・各ブログ）に進んでいただくのがよいと思います。
まず全体像：4 つの仕組みを「一言」と「たとえ」で
本編に入る前に、これから扱う 4 つが「ざっくり何なのか」を、一言とたとえだけで押さえておきます。細かい理由づけは各章で展開するので、ここでは「ふーん、そういう立ち位置か」くらいの感覚で十分です。
| 仕組み | 一言でいうと | 日常のたとえ |
|---|---|---|
| Attention（Self-Attention） | 文章中の単語同士が、互いの「関連の強さ」を計算し合う部品 | 会議で「今の話題に関係するのは誰の発言か」を見極める仕組み |
| Transformer | Attention を中核に、フィードフォワード層や位置情報の処理を組み上げたアーキテクチャ全体 | その見極めを使って、全員が一度に意見交換する会議の進め方そのもの |
| MoE（Mixture of Experts） | 専門家を大勢抱えつつ、1 回の処理では一部だけを起動する仕組み | 総合受付が、患者を適した専門外来だけに振り分ける病院 |
| KV Cache | 過去の計算結果を保存して使い回し、毎回の再計算をやめる仕組み | 議事録を整えて、毎回最初から議論を読み返さずに済ませる |
| Speculative Decoding | 小さなモデルが下書きし、大きなモデルがまとめて検証して速くする仕組み | アシスタントが下書きし、作家本人が一気に添削する |
| KV Cache 圧縮（TurboQuant など） | 使い回す議事録（KV Cache）そのものを圧縮して、メモリを大きく節約する仕組み | 議事録を要点だけに圧縮し、保管棚を空けて長い会議に備える |
上の表で Attention と Transformer を分けて並べましたが、この 2 つはイコールではなく、包含関係にあります。Attention（Self-Attention）は「単語同士の関連を計算する部品」、**Transformer は「その部品を中心に、フィードフォワード層や位置エンコーディングなどを組み上げたアーキテクチャ全体」**です。Attention は Transformer の一部（Attention ⊂ Transformer）で、心臓（Attention）とそれを積んだ車体全体（Transformer）のような関係になります。本記事では両者を土台としてセットで扱うため、次章でもまとめて解説します。
ここで覚えておきたいのは、これらがバラバラの発明ではないという点です。「ある工夫が新しい困りごとを生み、それを次の工夫が引き受ける」という連鎖でつながっています。たとえば Transformer が生んだ計算の重さを KV Cache が、KV Cache が生んだメモリ消費を圧縮技術が引き受ける、といった具合です。この流れを意識しながら読むと、各章が一本の線でつながって見えてきます。
ベース理解：Attention / Transformer はなぜ生まれたのか
MoE も KV Cache も Speculative Decoding も、すべて Transformer という土台の上に乗っています。なのでまず、その Transformer 自体が「何の問題を解くために生まれたのか」から始めます。ここが一番の根っこです。
Transformer 以前：RNN / LSTM が抱えていた 2 つの悩み
2017 年に Transformer を提案した論文のタイトルは「Attention Is All You Need（必要なのは Attention だけ）」でした。この「だけ」という言い方には、「それまで主役だった何かを外した」という含みがあります。外されたのが、当時の主流だった RNN（リカレントニューラルネットワーク）や LSTM です。
RNN / LSTM は、文章を「左から右へ、1 単語ずつ順番に読んでいく」モデルでした。これには直感的に分かりやすい一方で、大きく 2 つの悩みがありました。
悩み 1：逐次処理なので並列化できない
RNN は「3 単語目を処理するには、まず 1 単語目と 2 単語目の処理が終わっていないといけない」という構造になっています。前の単語の処理結果を受け取らないと次に進めないので、原理的に「順番待ち」が発生します。
GPU は本来、大量の計算を同時並行でこなすのが得意なハードウェアです。ところが RNN は順番待ちの連続なので、せっかくの並列計算の能力を活かしきれません。学習データが大きくなるほど、この「並列化できなさ」が学習速度の足かせになっていきました。
悩み 2：長い文章だと前半を忘れてしまう
RNN / LSTM は、文脈を「ひとつの記憶ベクトル」にぎゅっと畳み込みながら読み進めます。バケツリレーで情報を後ろへ受け渡していくようなイメージです。
このやり方だと、文章が長くなるにつれて、ずっと前に出てきた重要な単語の情報が、リレーの途中で薄まって消えていきます。「この代名詞は、20 文も前に出てきたあの人物を指している」といった長距離の関係（長距離依存）を、うまく保持しきれないことがありました。LSTM は「忘れにくくする工夫（ゲート機構）」を入れてこれを和らげましたが、根本的に解決したとは言いきれない状態でした。
Transformer の発想：全単語を「同時に」見渡す
Transformer がやったのは、「順番に読む」のをやめて、「文章中のすべての単語を一度に並べて、お互いの関係を同時に計算する」という方向転換でした。これにより、先ほどの 2 つの悩みに同時に答えています。
- 並列化できる：すべての単語を同時に見るので、順番待ちが消えます。GPU の並列計算の能力をフルに使えるようになり、大規模な学習が現実的になりました。
- 長距離依存に強い：20 単語先だろうが 200 単語先だろうが、「直接お互いを参照する」経路が用意されているので、リレーの途中で薄まる心配が減ります。
上の図の下半分のように、すべての単語がお互いに線で結ばれている、というのが Transformer のイメージです。この「全員がお互いを参照し合う」仕組みこそが Self-Attention です。
Self-Attention の中身：Q / K / V という三役
では、その「全員でお互いを参照し合う」処理は、具体的に何をしているのか。ここで出てくるのが Q（Query）/ K（Key）/ V（Value） という三役です。
kenmatsu4 さんのSelf-Attention の QKV を直感的に解説した記事では、この三役を「探す側 / 反応する側 / 渡される情報本体」として整理していて、私はこの分け方が一番しっくり来ました。
身近な例えにすると、こんなイメージです。
- Q（探す側）：会議で「来週の予定どうだっけ？」と問いかける質問者
- K（反応する側）：参加者それぞれが持つ「自分はこういう話題に反応します」というラベル
- V（渡される情報本体）：そのラベルを持つ人が実際に話す内容
質問（Q）と各人のラベル（K）の相性を見て、相性が良い人ほど大きな声で（重みを大きくして）情報（V）を渡す。これを全員ぶん集めて混ぜたものが、その単語の「文脈を踏まえた新しい意味」になります。RNN のバケツリレーと違い、誰もが誰とでも直接やり取りできる点が肝です。
Transformer が払った代償
ここで大事なのが、Transformer も「ただ良くなった」わけではなく、ある代償を払っているという点です。
「全単語が全単語を参照する」ということは、単語が N 個あれば N × N 通りの組み合わせを計算する、ということです。文章が 2 倍長くなると、計算量はおよそ 4 倍に膨らみます。これが「Attention は系列長の二乗に比例する」と言われる性質で、後の KV Cache や各種の Attention 高速化が解こうとしている問題の出発点でもあります。
つまり Transformer は、「逐次処理による並列化の難しさ・長距離依存の忘却」という悩みを、「系列長の二乗に比例する計算量」という新しい悩みと引き換えに解決した、と整理できます。ここから先の MoE / KV Cache / Speculative Decoding は、いずれも「この土台が抱える次の困りごとを、どう効率化するか」という工夫の話です。
Mixture of Experts（MoE）：賢くしたいけど計算が爆発する、を解く
なぜ生まれたのか：容量とコストのジレンマ
経験的に、モデルのパラメータ（中身の数字）を増やすほど、賢くなりやすい傾向があります。だったら「とにかくパラメータを増やせばいい」のですが、ここに大きなジレンマが立ちはだかります。
密モデル（Dense Model、ふつうの Transformer）では、1 トークンを処理するたびに、モデル内のすべてのパラメータを使って計算します。なのでパラメータを 10 倍にすると、賢さは上がるかもしれませんが、推論 1 回あたりの計算コストもほぼ 10 倍になります。これでは「賢くしたい」と「コストを抑えたい」が真っ向からぶつかってしまいます。
MoE は、このジレンマに対して「モデルの容量（総パラメータ数）と、1 回あたりの計算コストを切り離せないか」という問いを立てました。具体的には、「パラメータはたくさん持っておくが、1 トークンを処理するときには、その一部だけを起動する」という発想です。これは「条件付き計算（Conditional Computation）」と呼ばれます。必要なものだけスイッチを入れる、という考え方です。
例え：総合受付から専門外来へ振り分ける病院
ここでは病院の動きで例えてみます。
- 患者（トークン）が来院すると、まず 総合受付（ゲート / ルーター） が症状をヒアリングします。
- 受付は「内科」「整形外科」「皮膚科」など複数の専門外来（エキスパート） のうち、最も適した数科だけに患者を回します。
- 残りの診療科は、その患者については何もしません（給料は発生していても、その日その患者には稼働しない）。
ここで効いているのが、まさに「容量とコストの分離」です。病院は多くの専門外来（＝大きな容量）を抱えていますが、一人の患者が受けるのは 1〜2 科だけ（＝小さな計算コスト）です。「専門家をたくさん雇っておくが、一人の患者に全員が群がるわけではない」という運用が、MoE のやっていることに近いと私は捉えています。
仕組みのざっくり整理
| 要素 | 役割 | 例え |
|---|---|---|
| ルーター（ゲート） | どのエキスパートに渡すかを決める小さなネットワーク | 総合受付 |
| エキスパート | 専門化された FFN（フィードフォワード）の塊 | 各専門外来 |
| Top-k 選択 | 上位 k 個のエキスパートだけ起動（Mixtral は Top-2 など） | 1 人につき 1〜2 科だけ受診 |
代表的なモデルとして、Mistral の Mixtral 8x7B が分かりやすい例です。名前から「8 × 7B = 56B」と単純計算したくなりますが、Attention 層などはエキスパート間で共有されるため、総パラメータは実際には約 47B です（公式論文 arXiv:2401.04088）。一方で推論時に実際に動く活性パラメータは、Top-2 起動で約 13B 相当にとどまります。「47B 規模の容量を持ちつつ、計算は 13B 級で済ませる」というこの数字が、容量とコストを分離した結果そのものです。
何を犠牲に、何を得たのか
MoE は計算量を抑えますが、その代わりに別のコストを払っています。トレードオフを整理しておきます。
| 観点 | 内容 |
|---|---|
| 得たもの | 大きな容量（賢さの上限）を持ちつつ、推論あたりの計算量を抑えられる |
| 犠牲にしたもの（メモリ） | 「今回使われないエキスパート」も、いつ呼ばれるか分からないので VRAM には全員乗せておく必要があります。メモリ要件は活性パラメータ（約 13B）ではなく総パラメータ（約 47B）規模に近づきます |
| 犠牲にしたもの（学習の難しさ） | ルーターが特定のエキスパートにばかり患者を回すと、他が育ちにくくなります。負荷を分散させる工夫（ロードバランシング）が必要です |
| 向くシナリオ | スループット重視・複数 GPU が使える環境 |
| 向きにくいシナリオ | VRAM が厳しく、レイテンシ重視の単一 GPU 環境 |
「計算量は減ったが、メモリは減らない」という点が MoE の最大のトレードオフです。病院の例えで言えば「診療は速く回るが、専門外来の建物（VRAM）はぜんぶ建てておかないといけない」ということになります。なので「MoE のほうが常に得」というわけではない、という点はおさえておきたいところです。
なお、MoE はこの記事を書いている 2026 年時点でも、大規模モデルの主流であり続けています。一例として、2026 年 6 月に Moonshot AI が公開した大規模 MoE「Kimi K2.7-Code」は、総パラメータが約 1T 規模ながら、1 トークンあたりに動く活性パラメータは約 32B にとどまる構成で、オープンウェイトとして配布されています。容量とコストを分離するという MoE の発想が、最前線の大規模モデルでもそのまま効いていることが見て取れます。
KV Cache：同じ計算を何度もやり直す無駄を消す
なぜ必要なのか：自己回帰生成に潜む二度手間
LLM は「自己回帰（Autoregressive）」と呼ばれる方式で文章を生成します。これは「すでに書いた文章を見て次の 1 トークンを決め、それを末尾に足して、また次の 1 トークンを決める」という、1 トークンずつの逐次生成です。
ここに素朴な実装上の無駄が潜んでいます。先ほどの Self-Attention は「すべての単語が、これまでの全単語を参照する」処理でした。ということは、何も工夫しないと——
- 1 トークン目を出すとき：1 トークン分の K・V を計算
- 2 トークン目を出すとき：1〜2 トークン目の K・V をもう一度ぜんぶ計算
- 3 トークン目を出すとき：1〜3 トークン目の K・V をまたぜんぶ計算
というように、毎回これまでの全トークンの K・V を計算し直すことになります。先に触れた「系列長の二乗に比例する計算量」が、生成のたびに重くのしかかってくるわけです。
ところがよく考えると、過去のトークンの K と V は、後から新しいトークンが増えても変わりません。1 トークン目の「ラベル（K）」と「話す内容（V）」は、文章が伸びても同じです。だったら「一度計算した K・V を保存しておいて、次からは使い回せばいいのでは」というのが KV Cache の発想です。新しく増えた 1 トークンぶんだけ計算して、過去ぶんはキャッシュから引っ張る。これで「毎回全部計算し直す」二度手間が消えます。
例え：議事録を毎回最初から読み返さない
会議に途中参加した人を想像してみます。
- 議事録がない状態だと、発言するたびに「これまでの議論を最初から全部おさらい」しないと文脈に追いつけません。
- 一方で、議事録（K と V のキャッシュ）が整理されていれば、過去の発言は読み返さず、新しい発言だけに集中できます。
- 議事録が長くなるほど保管棚（メモリ）は埋まっていきますが、毎回頭から読み直すよりはるかに効率的です。
KV Cache でやっていることは、まさにこの「議事録の整備」に近いと、私は捉えています。
何を犠牲に、何を得たのか：今度はメモリを食う
KV Cache は「計算の二度手間」を消しましたが、その代わりに「議事録を保管する棚＝メモリ」を消費します。ここが新しいトレードオフです。
Hugging Face のブログにある計算例では、Llama-2 7B でシーケンス長 1 万トークン程度を扱うと、KV Cache だけで約 5GB を消費します。これはモデル重み（半精度）の 1/3 ほどに相当します。つまり長文を扱うほど、モデル本体よりも「議事録」の方がメモリを圧迫する、という逆転が起こり得ます。
| 観点 | 内容 |
|---|---|
| 得たもの | 過去トークンの再計算をやめ、生成 1 トークンあたりの計算を激減できる |
| 犠牲にしたもの | キャッシュを保持するためのメモリ。コンテキストが長くなるほど線形に増える |
「長いコンテキスト = 単にトークン課金が増える」だけでなく、推論サーバ側のメモリ予算をどう設計するか、という話に直結してくるのは、この KV Cache の性質が背景にあります。
関連用語：KV Cache を小さくする工夫たち
KV Cache が「メモリを食う」という新しい困りごとを生んだので、さらにそれを和らげる工夫が次々に出てきました。これらは「KV Cache の議事録を、いかにコンパクトに保つか」という共通のテーマで括れます。
| 用語 | ざっくりの意味 | 解こうとしている困りごと |
|---|---|---|
| MQA / GQA | Key と Value のヘッドを束ねてキャッシュ量を減らすアーキテクチャ工夫 | 議事録の冗長な複製を減らす |
| Flash Attention | プリフィル段階のメモリと速度を改善する Attention 実装 | 長文を最初に読み込む段階の重さ |
| KV Cache 量子化 | int8 / int4 などで保存し、メモリを 2〜5 倍ほど削減する手法 | 議事録の 1 文字あたりの容量を圧縮 |
Speculative Decoding：ハードウェアが暇している、を解く
なぜ生まれたのか：演算は余っているのにメモリ帯域で詰まる
LLM の生成が「1 トークンずつ」の逐次処理であることは KV Cache のところで触れました。ここで、もう一段踏み込んだ困りごとがあります。
1 トークンを生成するには、巨大なモデルの重み（数十 GB ぶんの数字）を、メモリから演算装置へ読み込んでくる必要があります。ところが、その重みを使って実際に行う計算は「たった 1 トークンぶん」です。たとえるなら、分厚い辞書を本棚から引っ張り出してきて、たった 1 単語だけ調べて棚に戻す、を延々と繰り返しているような状態です。
このとき GPU の演算能力（計算する力）は余っているのに、メモリ帯域（重みを運んでくる速さ）の方が先に限界に達します。これを「メモリ帯域律速（memory-bandwidth bound）」と言います。計算能力が暇しているのに、データの運搬待ちで遅くなっている——この状態が投機的デコーディングの解こうとした問題です。
ここで生まれた発想が、「どうせ重みを運んでくるなら、1 トークンと言わず、ついでに複数トークンをまとめて検証してしまえば、運搬コストを使い回せるのでは」というものです。Transformer は「複数トークンをまとめて 1 回で処理する」のが得意（並列処理が本来の強み）なので、この性質を生成側でも使い倒そう、というわけです。
例え：下書きをアシスタント、添削を本人
ある作家を想像してみます。
- アシスタント（小さなドラフトモデル）が、続きの文章を 5 トークン分くらい一気に下書き します。小さいので速く、運搬コストも軽い。
- 作家本人（大きな本番モデル）は、その下書きを 1 回の通読 で一気にチェックします。重い辞書を 1 回引いたついでに、5 単語まとめて答え合わせするイメージです。
- 序盤の数トークンが「自分が書いたものと一致している」なら、そのまま採用します。
- 途中で違う表現が出てきたら、そこから先は破棄して、本人が書き直します。
ポイントは、本番モデルが「1 回のフォワードパス（＝1 回の重み運搬）で複数トークンをまとめて検証できる」点を活かしているところです。下書きが当たれば、1 回の運搬で複数トークンぶん前進できるので、メモリ帯域の無駄が減ります。
そして大事なのが、生成結果そのものは、本番モデル単独で生成した場合と分布的に一致するよう設計されている点です。アシスタントの下書きは「当たれば採用、外れれば本人が直す」だけなので、最終的な文章の品質はアシスタントの賢さに引きずられません。速さだけをもらって、品質は本番モデルのまま、というのが狙いです。
どれくらい速くなるのか
Hugging Face の Assisted Generation 解説では、条件次第で次のような速度向上が示されています。
| 条件 | 速度向上の目安 |
|---|---|
| FP16 でモデルが GPU に収まる | 最大 2 倍程度 |
| INT8 量子化あり | 最大 3 倍程度 |
| メモリオフロードが必要な大規模モデル | 最大 10 倍程度 |
メモリオフロードが必要なほど大きいモデルで効果が大きいのは、それだけ「重みの運搬コスト」が支配的だからだと整理できます。ただし、これはあくまで「目安」です。タスクや温度設定、ドラフトモデルの選び方によって結果はかなり変わるため、自分のユースケースで一度ベンチマークを取ってから判断するのが安全です。
何を犠牲に、何を得たのか
| 観点 | 内容 |
|---|---|
| 得たもの | メモリ帯域律速の状況で、品質を保ったままレイテンシを削減できる |
| 犠牲にしたもの | ドラフトモデルを別途用意・運用する手間と、そのぶんの VRAM。下書きが外れ続けると検証が無駄打ちになり、かえって遅くなる場合もある |
効きやすい / 効きにくい場面
下書きが「当たりやすい」状況ほど効きます。逆に、本番モデルの出力が予測しづらい状況では、外れた下書きの破棄が増えて効きにくくなります。
| 効きやすい | 効きにくい |
|---|---|
| 翻訳・要約・コード補完など入力依存度が高いタスク | 高温度サンプリングで創造性を要求するタスク |
| 貪欲デコーディング、または低温度サンプリング | バッチサイズが大きく並列度が既に高いケース |
| ドラフトモデルが本番より 1 桁以上小さい | ドラフトとメインのトークナイザが異なる |
余談ですが、SARATHI のような「プリフィルとデコードを混ぜてバッチングする」工夫も、根っこの動機は同じで、「GPU を遊ばせないために、まとめてやれる仕事を増やす」発想だと私は理解しています。投機的デコーディングと SARATHI は手段こそ違いますが、「メモリ帯域律速でハードが暇している」という同じ困りごとに、別の角度から答えている、と捉えると見通しが良くなります。
RoPE / SwiGLU：本記事ではあえて深入りしない
ここまで紹介した 4 つに比べて、RoPE（Rotary Position Embedding）や SwiGLU は、もう少しモデル内部の細部に踏み込んだ話題になります。本記事では概要だけ触れます。
- RoPE：トークンの位置情報を、ベクトルの「回転」として埋め込む方式。Transformer は全単語を同時に見る代わりに「順番の情報」をそのままでは持たないので、位置情報を別途与える必要があります。RoPE はその与え方の工夫で、長文対応や位置補間（Position Interpolation）の議論でよく出てきます。
- SwiGLU：FFN（フィードフォワード）の活性化関数の一種。学習の安定性と表現力のバランスが取りやすい、と評価されています。
このあたりは「モデルアーキテクチャの差別化要素」として論文で語られることが多く、利用者目線では「最近のモデルはだいたいこの辺を採用している」と把握しておく程度でも、まずは十分かなと感じています。
2026 年の話題：長コンテキスト時代と KV Cache 圧縮（TurboQuant）
なぜ今、KV Cache 圧縮が重要なのか
近年のモデル競争は、扱えるコンテキスト長（一度に読み込める文章量）の長さが一つの軸になっています。数万〜数十万トークンを扱う、という話も珍しくなくなってきました。
ここで先ほどの KV Cache のトレードオフが効いてきます。KV Cache のメモリ消費は、コンテキストが長くなるほど線形に増えます。つまり「長いコンテキストを売りにする」ほど、「議事録の保管棚（メモリ）がパンクする」という問題が深刻になっていきます。長コンテキスト時代の足かせは、しばしば計算量よりもメモリの方にあります。だからこそ「議事録をいかに小さく畳むか」という KV Cache 圧縮が、競争の中心テーマの一つに浮上してきた、という流れです。
TurboQuant の要点
2026 年に話題になっているのが、Google Research が ICLR 2026 で発表した TurboQuant です（論文は arXiv:2504.19874）。InfoQ や研究ブログなどの紹介記事を読む限り、要点は次のようになります。
- KV Cache を 3〜3.5 bit 程度まで量子化しつつ、ベンチマーク上は元の精度をほぼ維持。なお、出典によって閾値の表記に幅があり、Google Research のブログは「3 bit」、InfoQ は「3.5 bit」と表現しています。完全に精度を保てる水準はおおむね 3.5 bit と捉えるのが安全です。
- 学習やファインチューニング不要で適用できる、データに依存しない手法。
- PolarQuant（ランダム回転を使った座標変換）と 1 bit の QJL 残差補正を組み合わせ、約 6 倍のメモリ削減と H100 上で 最大 8 倍の Attention 計算高速化を報告。
- 例として、ある 3B 級モデル（Qwen2.5-3B クラス）では、8K トークンの KV Cache が 289MB → 58MB 程度まで縮み、12GB 級 GPU で 40K トークン規模のコンテキストが現実的になる、という見積もりが紹介されています（モデル規模や量子化条件で値は変わります）。
「メモリを大きく削れば、同じ GPU でより長いコンテキストを扱える」という方向性は、まさに先ほどの「長コンテキスト時代の足かせはメモリ」という文脈にぴたりとはまります。
評価はこれから（2026 年 6 月時点）
ここはまだ評価が定まりきっていない領域です。公開直後から第三者検証が進み、論文のベンチマーク値をそのまま実運用の期待値にはできない、という指摘も出てきました。
たとえば vLLM チームの第三者ベンチマーク（vLLM Blog: TurboQuant）では、次のような結果が報告されています。
- どのバリアントでもスループットが BF16 を下回り、構成やモデルによっては 2〜3 割ほど遅くなる場合がある。
- 量子化を攻めたバリアントでは、難易度の高いベンチマーク（AIME25・LiveCodeBench-v6 など）で精度が大きく落ちることがある。
- 「3.5 bit で FP16 と同等」という結果も比較的やさしいベンチマークでの話で、難しいタスクでは必ずしも成立しない。
- 総合的には「KV Cache 量子化は、現状では FP8 が現実的なベスト」という評価。
つまり「6 倍削減・8 倍高速」は理想条件での数字で、実運用のスループットや難タスクの精度まで含めると話は単純ではない、ということになります。公式実装も 2026 年 6 月時点では未公開で、llama.cpp や vLLM への統合もコミュニティが PR を出している段階（本体へのマージは未達）です。極端にメモリが厳しい場面では選択肢になりますが、汎用的な推奨と捉えるのは早い、というのが現時点の温度感だと理解しています。
ただ、方向性としては「KV Cache をいかに小さく、いかに速く扱うか」が、コンテキスト長の競争と密接に絡んでいるのは、ここ数年共通している印象です。
まとめ：それぞれが「どんな困りごと」を「何と引き換えに」解いたか
4 つの仕組みを、「解いた困りごと」と「払った代償」の対で並べておきます。発明の動機とトレードオフをセットで覚えておくと、新しいモデルやランタイムの説明に出会ったときも、見当がつけやすくなる、と私は感じています。
| 仕組み | 解いた困りごと | 払った代償（トレードオフ） |
|---|---|---|
| Attention / Transformer | RNN の逐次処理（並列化できない）と長距離依存の忘却 | 系列長の二乗に比例する計算量という新たな重さ |
| MoE | 賢くするにはパラメータを増やしたいが、全部使うと計算が爆発する | 計算量は減るが、全エキスパートを載せるメモリは減らない |
| KV Cache | 自己回帰生成で過去全体を毎回再計算する二度手間 | キャッシュを保持するメモリを食う（長文ほど増える） |
| Speculative Decoding | メモリ帯域律速でハードが暇している（逐次生成が遅い） | ドラフトモデルの運用コスト、外れ続けると逆に遅くなる |
こうして並べてみると、ある工夫が解いた問題が、次の工夫が解くべき新しい問題を生んでいる、という連鎖が見えてきます。Transformer が計算量の問題を生み、KV Cache がメモリの問題を生み、そのメモリ問題を圧縮技術が引き継ぐ——LLM の内部は、こうした「困りごとのバトンリレー」の積み重ねとして眺めると、一本の筋が通って見えてくるように思います。
LLM の内部は、論文ベースで掘り下げると本当にキリがない領域です。一方で、API 利用者やアプリ開発者の立場では、ここで紹介した粒度の「なぜ」と「例え」を持っているだけでも、ベンダーの発表資料やランタイムのオプション説明がだいぶ読みやすくなる、と私は感じています。
本記事の説明は、あくまで 1 つの整理の仕方です。論文寄りの説明、実装寄りの説明、図解中心の説明など、流派はいろいろあるので、しっくり来るものを 2〜3 種類読み比べてみるのが、結局は近道かもしれません。
参考リンク
- Attention Is All You Need（arXiv:1706.03762）
- TransformerのSelf AttentionのQKVを直感的に解説する - Qiita（kenmatsu4 氏）
- Mixture of Experts Explained - Hugging Face Blog
- KV Cache Quantization in Transformers - Hugging Face Blog
- Assisted Generation: a new direction toward low-latency text generation - Hugging Face Blog
- SARATHI: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills（arXiv:2308.16369）
- TurboQuant（論文・arXiv:2504.19874）
- TurboQuant: Redefining AI efficiency with extreme compression - Google Research Blog
- A First Comprehensive Study of TurboQuant: Accuracy and Performance - vLLM Blog
- Kimi K2（GitHub・Moonshot AI）
- Google's TurboQuant Compression May Support Faster Inference - InfoQ