128K contextを使えるLLMでも、長いpromptを入れた瞬間に軽快さが消えることがあります。
NVIDIAが2026年8月1日早朝に公開した公式技術記事では、DeepSeek-R1のprefill時間に占めるAttentionの比率が、4K contextの18%から128Kでは85%まで上昇しました。長文になるほど、Attentionは脇役ではなく主犯になります。GPUに怒られてから設計を見直すのでは、少し遅いわけです。
重要なのは、Attentionを一つの処理として最適化しないことです。promptを一括処理するprefillと、1 tokenずつ生成するdecodeでは、詰まる場所が違います。
古い問題。prefillとdecodeを同じ速さの話にしていた
prefillは入力tokenをまとめて処理します。計算量が大きく、GPUの行列演算能力がbottleneckになりやすい処理です。
decodeは次の1 tokenを作るたびにKV cacheを読みます。行列は小さい一方、長いcontextのkeyとvalueをHBMから運ぶため、memory bandwidthがbottleneckになります。
同じAttentionでも、prefillはcompute-bound、decodeはmemory-boundです。だからkernelやGPUを一つの処方箋として扱うだけでは足りません。
中心原理。Q headを増やすよりKV headを共有する
NVIDIA記事の一つ目の軸はgroup size、記号ではGです。これは1本のKV headを何本のquery headで共有するかを表します。
query headが64本あるmodelでGが8ならKV headは8本です。Gを16にするとKV headは4本になります。
decodeでは、KV headが少ないほど1 token生成時に読み込むKV cacheが減ります。記事の式ではdecodeのarithmetic intensityはおおよそ2掛けるGです。Gを1から8へ上げると、memory trafficを減らしながら計算密度を8倍へ上げられます。
測定でも、decode runtimeはGを倍にするごとに概ね半分になりました。一方、prefillはGを1から64まで変えてもruntime差が1%未満です。
第一原則は明快です。decodeを重視するならGを大きくする。ただし、これは推論速度の話です。KV headを減らしてもmodel品質が変わらないとは、この記事は証明していません。
head dimensionは大きければよいわけではない
二つ目の軸はhead dimensionです。
NVIDIAは128または256を効率的な選択肢として挙げています。64ではGPUの128-wide tileを使い切れず、実質的に128幅の費用を払います。逆に512以上はTensor Memoryの容量上限へ近づきます。
さらにGPUは128-byte単位のmemory accessを得意とします。head dimensionをhardwareのtileとmemory alignmentへ合わせると、計算量を変えなくても無駄な空きを減らせます。
これはserving softwareだけで後から直せる話ではありません。model architectureを決めた時点で、推論時の形がかなり決まります。
長文ではprefillが二乗、decodeが線形に重くなる
sequence lengthを2倍にすると、prefillは全token同士を比較するため、dense attentionの仕事量はおおむね4倍になります。
decodeは1 stepごとにKV cache全体を読むので、contextが2倍なら各stepのruntimeはおおむね2倍です。
この非対称性から三つ目の原則が出ます。実効的なKV stateを減らすことです。
- KV cacheを圧縮する
- sliding-window attentionを使う
- sparse attentionを使う
- global attentionを一部layerだけへ残すhybrid architectureを使う
ただし、今回のNVIDIA記事が測ったのはdense attentionです。sparse attentionは次回記事の予告であり、精度と速度のtradeoffは今回の数値からは判断できません。
GPUを増やすとKV cacheが増える逆転現象
四つ目はmulti-GPU配置です。
Tensor Parallelismはattention headをGPUへ分けます。ところが、TP数がKV head数を超えると、1本のKV headを複数rankへ複製しなければなりません。GPUを増やしたのにKV stateとbandwidth負荷が増えるという、少し悲しい逆転が起きます。
原則は TP ≤ KH です。各GPUが少なくとも完全なKV headを1本持てる範囲にします。
KV headが1本や2本しかないmodelでは、Attention Data Parallelismでrequestを分けるか、KV Parallelismで長いKV cacheを分割します。MoEのFFNはExpert Parallelismで別にscaleさせます。TensorRT-LLMではWide EPやHelix Parallelismとして実装経路が用意されています。
小さな設計チェック。64 query headのmodelを置く
model選定時に次の表を作るだけでも、危険な構成を早く見つけられます。
- query head数QHを確認する
- group size Gを確認する
KH = QH / GでKV head数を出す- 想定TPがKH以下か確認する
- head dimensionが128または256に近いか確認する
- 32K、64K、128Kでprefillとdecodeを別々に測る
QHが64、Gが8ならKHは8です。TP 8までは各GPUへKV headを分けられます。TP 16にすると複製が必要です。
Gを16へ増やすとdecodeは有利になりやすい一方、KHは4へ減るのでtensor parallelの上限も4へ下がります。一つのparameterを改善すると、別のscale方法が必要になります。これがco-designの意味です。
実務で測るべき4つの数字
AICompanyの解釈として、長文agent基盤では一つのtokens per secondだけを見ないほうがよいです。
- time to first token。prefillの重さを見る
- inter-token latency。decodeの軽快さを見る
- request当たりKV cache容量。concurrencyの上限を見る
- GPU数を増やしたときの実効throughput。KV複製の有無を見る
agentは長いrepository、tool log、memoryをpromptへ積み上げます。平均contextだけでなくp95とp99のcontext lengthで測らないと、本番の遅いrequestを見落とします。
限界。速いkernelと速いserviceは同じではない
第一に、公開図はnormalized kernel runtimeが中心です。end-to-endのtokens per second、first-token latency、電力、総費用を直接比較した表ではありません。
第二に、記事本文では使用GPU型番、clock、TensorRT-LLM versionなど完全な再現条件が一か所にまとまっていません。数値を別環境へそのまま移せません。
第三に、測定はAttention演算とKV cacheの両方でFP8を使います。別precisionではmemory trafficとcomputeの境界が変わります。
第四に、G、head dimension、sparse patternの変更はmodel品質へ影響し得ます。今回の記事は推論性能の分析であり、accuracyやreasoning能力を同時評価していません。
最後に、これはNVIDIA GPU向けの指針です。原理は広く使えますが、tile幅、memory transfer、parallelismの最適値はhardwareごとに検証が必要です。
結論。長文LLMはmodelとservingを一緒に選ぶ
長文推論が遅いとき、serving engineだけを疑うのは半分正解です。
prefillは計算、decodeはmemory。group sizeはdecode、head dimensionはtile、KV stateはcontext、KV head数はGPU配置を決めます。
NVIDIAの4原則が示すのは、LLMの速さはparameter数だけでは読めないということです。QH、KH、G、head dimension、想定context、GPU数を一枚の設計表へ並べる。それだけで、後からGPUを足してKV cacheまで増やす事故をかなり避けられます。
長文agentを本番へ出すなら、model benchmarkとserving benchmarkを別々に眺める段階は終わりです。model architectureとhardware配置を同じ設計問題として扱う必要があります。
参照
【送料無料】マクロキーパッド、ストリームコントローラーデッキゲームストリーミングショートカットキーボード、18個のプログラム可能