# LLM高速化(勉強会) ## 概要 LLM 推論高速化をテーマにした勉強会資料(全 50 ページ)。自己回帰型モデルの言語生成の基礎から出発し、KVCache・FlashAttention・Continual Batching・PagedAttention・Speculative Decoding といったアルゴリズム的高速化、CUDA/Triton/CuTe による実装、GQA・MLA・Sliding Attention・Linear Attention といったアーキテクチャ的工夫、量子化、Nsight Compute/Systems によるプロファイリング、CUDAGraph、vLLM の内部構造とコントリビュート方法までを一気通貫で扱う。ブログ記事「LLM Serving を支える技術」に触発されて始めたイベントだと明記されている(p.3)。 ## 主要メッセージ - 素の PyTorch/Transformers 推論から vLLM 推論への移行で 15.88 倍(5.97→94.84 tokens/sec)の高速化を Colab ハンズオンで実演し、KVCache・PagedAttention・Continuous Batching・CUDAGraph 等の効果を体感させる構成になっている(p.9, p.49)。 - KVCache サイズは `2 × batch_size × num_layers × sequence_length × head_dim × num_heads` で見積もられ、例示条件(batch=16, layers=96, seq=32768, head_dim=128, heads=8, float16)では 192 GiB に達するとし、KVCache 削減が以降の技術(GQA・MLA・量子化・PagedAttention)を貫く動機として位置づけられている(p.10)。 - CUDAGraph 未適用の推論では GPU カーネル間に約 100 μs のギャップが生じ、CPU が GPU 実行速度に追いつけないことが最大のボトルネックになると述べる(p.39-40)。 ## 視覚的に重要な図表 **p.9 KVCache の計算過程** ![[_attachments/llm-kosokuka-benkyoukai/page-009.png]] Q・K・V の内積計算において、Prefill 段階で KVCache を構築し、Decode 段階では新規クエリ 1 本のみを計算してキャッシュ済みの K/V と掛け合わせることで計算量を削減する仕組みを示す。 **p.13 FlashAttention のメモリ階層とタイリング** ![[_attachments/llm-kosokuka-benkyoukai/page-013.png]] GPU の SRAM(19 TB/s)・HBM(1.5 TB/s)・DRAM(12.8 GB/s)の帯域差を踏まえ、Tiling による QK 計算と Online Softmax の併用で HBM アクセスを減らしながら計算を SRAM 上に留める設計を示す。 **p.16 Super Sequence + Continual Batching のマスク処理** ![[_attachments/llm-kosokuka-benkyoukai/page-016.png]] 複数リクエストのトークン列を 1 次元に連結する Ragged batching において、Attention マスクで異なるプロンプト間の相互作用を遮断する仕組みを示す。 **p.17 PagedAttention のブロック管理** ![[_attachments/llm-kosokuka-benkyoukai/page-017.png]] OS のページング機構に着想を得て、KVCache を固定サイズブロック単位で非連続に管理し、Batch 推論時の断片化・Padding を削減する構造を示す。 **p.22 Medusa Decoding と Eagle Decoding の比較** ![[_attachments/llm-kosokuka-benkyoukai/page-022.png]] Speculative Decoding のドラフト手法として、複数の予測ヘッドを並列に使う Medusa と、直前の予測を逐次入力して連鎖的にドラフトする Eagle の構造差を対比する。 **p.32 Multi-Head Latent Attention の low-rank 計算** ![[_attachments/llm-kosokuka-benkyoukai/page-032.png]] KV の hidden_dim を 512 に low-rank 化した場合、計算量が 3/8 に、KVCache 容量が 1/8 になるという具体的な見積もり計算を示す。 **p.44 vLLM のアーキテクチャ全体図** ![[_attachments/llm-kosokuka-benkyoukai/page-044.png]] リクエストを受け付ける Front End と、Scheduler・KVCacheScheduler・ModelExecutor から成る EngineCore の分担構造を示す。 **p.46 vLLM の Prefill-Decode Disaggregation** ![[_attachments/llm-kosokuka-benkyoukai/page-046.png]] Prefill 専用サーバーと Decode 専用サーバーを分離し、KV Cache Transfer で接続することで Time To First Token と Time Per Output Token を個別に最適化できる構成を示す。Prefill には Tensor Core の強い H200、Decode には A100 程度でも十分という具体例を挙げる(p.47)。 ## 技術トピックの要点 - **CUDA / Triton / CuTe(p.25-30)**: Python + Torch の for 文実装は 1 イテレータあたり 10〜100 μs を消費するため GPU 上での実装が必須とし、CUDA の最適化の 80% はメモリアクセスの効率化に帰着すると述べる。専門エンジニア雇用コストを避けるための DSL として Triton・CuTe-DSL を紹介し、近年の FlashAttention・vLLM の実装が基本的にこれらで書かれているとする。 - **アーキテクチャ面(p.31-35)**: GQA は複数の Grouped Query に対して 1 pair の KV を対応させ KVCache 量を削減する。MLA は KV の hidden_dim を縮小した潜在表現をキャッシュする。Sliding Attention は一部レイヤーで過去 window size 分のみを参照し KVCache の最大値を固定値にする(Gemma が採用)。Linear Attention は KV の代わりに前の hidden_state を使う方式で、Qwen3.5 以降の Qwen が採用するとし、採択トークン数に応じて途中までの状態を破棄する Speculative Decoding 的手法には弱いという弱点を指摘する(p.35)。 - **量子化(p.36-38)**: GPT-OSS の MoE 部分が FP4 で量子化されている例を挙げ、Block-wise Scaling と Mixed Precision Accumulation を精度維持の工夫として紹介する。低精度計算で高精度行列演算をエミュレートする Ozaki Scheme(cuBLAS に統合済み)を「HPC の人間にしか知られていない」手法として紹介する。 - **プロファイラ(p.39-41)**: Nsight Compute は CUDA カーネル単体の性能検証(メモリストール vs SM 飽和の切り分け)に、Nsight Systems はシステム全体のボトルネック特定に使うとし、NVTX でコード中の測定対象を可視化できると述べる。 - **vLLM の Contribute 方法(p.48)**: source からのビルド方法とアーキテクチャ説明が整備されており、簡単な実験は Plugins でも可能だとする。デバッグ時は `os.environ["VLLM_ENABLE_V1_MULTIPROCESSING"] = "0"` で Inprocess 実行にすることを推奨する。 ## 概念・実体への接続 - [[KVキャッシュ管理]] — KVCache のサイズ見積もり、PagedAttention によるブロック管理 - [[FlashAttention]] — メモリ階層とタイリングによる IO 削減 - [[Grouped-Query Attention]] / [[Multi-Head Latent Attention]] / [[線形注意]] / [[スライディングウィンドウアテンション]] — KVCache 削減を目的としたアーキテクチャ的工夫 - [[Prefill-Decode分離]] — vLLM における Prefill/Decode サーバー分離とハードウェア調整 - [[GPU最適化]] / [[カーネルフュージョン]] / [[混合精度訓練]] — CUDA/Triton/CuTe 実装、量子化、Mixed Precision Accumulation - [[vLLM]] — アーキテクチャ、Chunked Prefill、Preemption、Contribute 方法 ## 限界・不確実点 - スライド上に「LLM Serving を支える技術」というブログへのリンクがあるが(p.3)、URL 自体はスライド画像上でハイパーリンクとしてのみ存在しテキスト化できておらず、記事名の裏取りはスライド内表記のみに依拠する。 - 発表者名は SpeakerDeck 上で "SuperHotDog"(アカウント `superhotdogcat`)とのみ確認でき、所属組織の明示的な記載は SpeakerDeck プロフィールページ上に見つからなかった。スライド中(p.10 等)に GMO ペパボのロゴが表示されているが、これが発表者自身の所属を示すものか、スライドテンプレート由来のものかは確定できない。 - 公開日時の明確なメタデータ(SpeakerDeck ページ、PDF メタデータとも)が取得できず、`date_published` は年のみの推定値である。 - 音源・動画は提供されておらず、口頭説明や質疑応答は本ページに含まれない。 - p.24 で言及される「Gemma4 の MTP」の詳細な図・出典リンクはスライド上のハイパーリンクとしてのみ存在し、リンク先 URL はテキスト抽出できていない。