AI推論最適化の論点
まず分類する
AI推論最適化は、次の層に分けて考えます。
| 層 | 例 | ルール違反リスク |
|---|---|---|
| ベンチ条件 | concurrency、request count、ISL/OSL | 低。ただし指定条件は守る |
| serving設定 | max running requests、CUDA graph batch、memory fraction | 低から中 |
| 並列化 | TP、PP、DP、EP、DP attention | 中。モデル・実装依存 |
| cache | KV cache、prefix cache、RadixAttention | 中 |
| disaggregation | prefill/decode分離、worker比率、KV transfer | 中から高 |
| 推測系 | speculative decoding、MTP、draft model | 高。モデル品質・重み・評価条件に依存 |
| 量子化 | FP8、INT8、INT4、KV quantization | 高。2025年はモデル性能低下変更が禁止された |
| 実験的機能 | torch.compileなど | 高。2025年は実験的機能が禁止されたという参加記情報あり |
Qwen3-235B-A22Bで重要そうなこと
Qwen3-235B-A22BはMoEモデルです。総235Bの重みを扱いつつ、1 tokenあたりは一部expertを使います。
重要な論点は次の通りです。
- 重みロード時間とストレージ配置。
- GPUメモリ上に重みとKV cacheをどう載せるか。
- Expert Parallelismでexpert計算をどう分散するか。
- TP/PP/EPの組み合わせ。
- 長いcontextを扱う場合のprefillコスト。
- thinking mode / non-thinking modeと出力長の扱い。
SGLangで出てくる設定
参加記では、--max-running-requestsや--cuda-graph-max-bsをバッチサイズ相当の調整として扱ったと書かれています。SGLangのserver argumentsにもこれらの引数が存在します。
ただし、最適値はモデル、GPU、VRAM、context長、concurrency、CUDA graphの有無で変わります。固定値を丸写ししないで、sweepする必要があります。
SGLang concurrency調査の進め方
2026-06-26のAIチーム共有スライドでは、Qwen3-30Bでconcurrencyを1、2、4、8に変え、output TPS、QPS、TTFT p50、E2E latency p99、GPU使用率、GPUメモリ使用量を比較しました。
次の順番で進める方針です。
concurrencyの飽和点を探す。次は12、16、24、32などを試す。- 短文、長文、長出力でボトルネックを分ける。
- SGLangのscheduler系パラメータを触る。
- 最後にモデル、Tensor Parallel、別ランタイムを比較する。
理論上の8倍に届かない要因として、次が挙がっています。
- schedulerの管理コスト。
- KV cacheアクセスとメモリ帯域。
- decodeの逐次性。
- prefillとdecodeの干渉。
- リクエスト長のばらつき。
- GPU kernelの効率限界。
SGLang公式のBenchmark and Profilingでは、bench_servingは実運用に近いonline serving測定に使え、TTFT、TPOT、ITL、throughputを測れると説明されています。チームの測定でも、concurrencyだけでなくrequest countとwarmupを揃えます。
次に見るSGLang設定候補:
| 設定 | 見る理由 | 注意点 |
|---|---|---|
--max-running-requests | 同時に走るrequest上限を変える | 高すぎるとKV cacheやVRAMが詰まる |
--chunked-prefill-size | 長いpromptのprefillを小分けにする | 小さくするとメモリは節約できるがprefillが遅くなる可能性 |
--max-prefill-tokens | prefill batchのtoken上限を決める | 長文入力の挙動に影響する |
--schedule-policy | requestの選び方を変える | cache hitやtail latencyに影響する可能性 |
--cuda-graph-max-bs / --cuda-graph-max-bs-decode / --cuda-graph-max-bs-prefill | CUDA graphを使うbatchサイズ範囲を広げる | SGLangのバージョンで引数名が変わる可能性がある。CUDA graphはメモリを使うためVRAM残量とセットで見る |
--mem-fraction-static | 重みとKV cache poolに割り当てるGPUメモリ比率を変える | 高すぎるとactivationやCUDA graph用の余裕がなくなり、低すぎると最大concurrencyが下がる |
--num-continuous-decode-steps | scheduler overheadを減らす可能性がある | throughput向上とTTFT悪化のtrade-offがある |
speculative decoding / MTP
SGLangのSpeculative Decoding docsでは、EAGLE、Multi Token Prediction、draft model、NGRAMなど複数の推測デコード手法が説明されています。
メモ上の議論では、ランダム重みでベンチマークすると、MTPやspeculative decodingの有効性が実運用の分布を反映しないのではないかという懸念があります。これは妥当な論点です。推測デコードは「予測したtokenがどれだけ採用されるか」に依存するため、実重み・実データ分布でないと評価が歪み得ます。
DP Attention
2025年参加記では、DeepSeekモデル向けのDP Attentionを試したものの、KV cache削減は確認できてもスループットは大きく下がったと書かれています。
この教訓は、公式ブログや論文上の高速化率をそのまま信じないことです。最適化は次の条件が揃ったときだけ意味があります。
- 同じモデルか。
- 同じGPU世代か。
- 同じbatch/concurrencyか。
- 同じ入力長・出力長か。
- 同じnetworkか。
- 同じ評価指標か。
実験の優先順位
最終ルール前にやるなら、リスクが低い順に進めます。
- ベンチマークの測り方を固定する。
- concurrency sweepを作る。
- TP/PP/DP/EPの意味をチームで説明できるようにする。
- SGLangの主要server argumentsを読む。
- PD disaggregationの構成図を描けるようにする。
- ルール確定後に、禁止されていない範囲で最適化候補を絞る。