テスト時計算予算配分（Compute Budget Allocation）（テストジケイサンヨサンハイブン）
LLMの推論時に利用可能な計算リソース（トークン数・探索回数・時間）を問題の難易度や種類に応じて動的に配分する最適化手法。固定配分と比較して最大14倍の効率改善が報告されている。
テスト時計算予算配分とは
テスト時計算予算配分（Compute Budget Allocation）とは、LLMが推論時に使用する計算リソースを、入力された問題の難易度や性質に応じて動的に調整する技術である。全ての質問に同量の計算を割り当てるのではなく、簡単な質問には少ない計算で迅速に回答し、困難な問題にのみ大量の計算資源を集中投入する。2024年のGoogle DeepMindの研究で体系化された。
固定配分 vs 動的配分
| 配分方式 | 説明 | メリット | デメリット |
|---|---|---|---|
| 固定配分 | 全質問に同一の推論ステップ数 | 実装が単純・レイテンシ予測可能 | 簡単な問題で無駄・難問で不足 |
| 問題適応型 | 難易度推定に基づく段階的配分 | 効率が高い・コスト最適化 | 難易度推定の精度に依存 |
| 報酬ガイド型 | PRMスコアに基づく動的打ち切り | 各ステップで最適判断 | PRM学習コストが追加で必要 |
| ユーザー制御型 | APIパラメータで計算量を指定 | 柔軟・用途別最適化 | ユーザー側の知識が必要 |
計算予算の構成要素
推論時に配分される計算リソースは、以下の要素に分解される。
- 思考トークン数: Chain-of-Thought推論で生成される内部思考の長さ。OpenAI o1では最大32,768トークン、o3では最大100,000トークンが内部思考に割り当てられる
- サンプリング回数: ベストオブNサンプリングにおける候補生成数。N=1（単一回答）からN=256（大規模探索）まで
- 探索深度: ツリー探索における最大深度。MCTSでは通常8〜64ステップ
- 検証回数: 自己検証ループの反復回数。1回のチェックから5回以上の反復検証まで
- 並列度: 同時に探索するパスの数。ビーム幅に相当し、通常4〜32
難易度推定手法
計算予算を適切に配分するために、問題の難易度をリアルタイムに推定する技術が不可欠である。
- プロンプト長ヒューリスティック: 入力トークン数と問題難易度の相関を利用。短い質問は簡単、長い問題文は困難という統計的傾向
- 初期トークン信頼度: モデルが最初の数トークンを生成した時点でのロジット分布のエントロピー。エントロピーが高いほど不確実性が高く、追加計算が必要
- 分類器ベース: 軽量な分類モデル（BERT-baseクラス）で問題の難易度を事前に3〜5段階に分類。オーバーヘッドは数ミリ秒
- 段階的エスカレーション: まず最小計算で回答を生成し、検証器の信頼度が閾値未満なら計算予算を増加させるカスケード方式
- 強化学習ベース: 計算予算の配分自体を強化学習で最適化。報酬は回答正確性とコストの加重和
実装パターンと効果
Google DeepMindの研究（Snell et al., 2024）が示した主要な知見を整理する。
- 最適配分 vs 固定配分: 同一の総計算予算で、問題適応型配分は固定配分の14倍以上の性能を達成。特に中難度の問題群で差が顕著
- 計算量の対数的改善: 推論計算量を2倍にすると性能は約5〜10%改善するが、10倍にしても30〜40%程度の改善に留まる（収穫逓減）
- 小モデル+大計算の有効性: Llama 3.1 8Bに100倍の推論計算を投入すると、Llama 3.1 70Bの単一パス推論に匹敵する性能を示す場合がある（数学タスク限定）
- 損益分岐点: 推論計算の追加コストが学習コストの1/1000を超えると、より大きなモデルを学習した方が費用対効果が高くなる傾向
APIでの計算予算制御
主要なAPIプロバイダーが提供する計算予算制御パラメータを示す。
| プロバイダー | パラメータ | 設定範囲 | 説明 |
|---|---|---|---|
| OpenAI | reasoning_effort | low/medium/high | o1/o3系の推論深度制御 |
| Anthropic | thinking.budget_tokens | 1024〜128000 | Extended Thinking の思考トークン上限 |
| DeepSeek | max_tokens（思考含む） | 1〜65536 | R1の思考+回答の合計トークン上限 |
| thinking_budget | 0〜24576 | Gemini 2.0 Flash Thinkingの思考予算 |
2025〜2026年の最新動向
- 適応的推論（2025年前半）: OpenAI o3-miniが3段階のreasoning_effort（low/medium/high）を提供し、APIユーザーが用途に応じて計算量を制御可能に
- 自律的計算制御（2025年後半）: モデル自身が問題を見て必要な計算量を自動判断する「メタ推論」機能が研究段階から実用段階へ
- コスト最適化サービス（2026年）: 推論リクエストのバッチ処理で、問題の難易度を事前分類し、適切な計算予算を自動割り当てるミドルウェアが登場
- ハードウェア連動制御: NVIDIA TensorRT-LLMがリクエストごとのGPU計算予算をAPI経由で動的に変更する機能をベータ提供
よくある質問（FAQ）
Q1: 計算予算を増やせば必ず性能は向上するのか？ A: 一定の範囲までは向上するが、収穫逓減が発生する。目安として、基準計算量の10〜100倍の範囲が費用対効果の高いゾーンである。それ以上増やしても改善は微小で、コストばかりが増大する。
Q2: 計算予算配分はどのように課金に影響するのか？ A: 多くのAPIプロバイダーは思考トークンも従量課金対象としている。OpenAI o1の場合、内部思考トークンは出力トークンの75%の料金（$45/1M思考トークン）が課金される。計算予算を適切に配分することで、月間APIコストを30〜50%削減できるケースが報告されている。
Q3: 自前のモデルで計算予算配分を実装するにはどうすればよいか？ A: 最も簡単なアプローチは、ベストオブNサンプリングとProcess Reward Modelの組み合わせである。vLLMでN個の候補を並列生成し、PRMでスコアリングして最良を選択する。Nを問題の難易度に応じて1〜64の範囲で調整する。オープンソースのPRMとしてはMath-Shepherd（Mistral AI）やSkywork-PRM（Kunlun）が利用可能。
まとめ
- 計算予算配分は推論時のリソースを問題難易度に応じて動的に調整する技術
- 固定配分と比較して最大14倍の効率改善が可能
- 思考トークン数・サンプリング回数・探索深度が主な配分対象
- APIではreasoning_effortやbudget_tokensパラメータで制御可能
- 収穫逓減があるため、10〜100倍の範囲が費用対効果の最適ゾーン