「推論は学習より12倍重要」― YC Paper ClubでDeepSeekの公開数値から試算、学習は約280万H800時間、推論は年換算で約6倍の計算量
Y Combinator(YC)の勉強会「Paper Club」で、推論(inference)をテーマにした回が開かれ、YCのパートナーによる概観と、4人の実務家の講演がありました。登壇者は、Together AIの研究責任者ダン・フー氏、Ollama創業者のジェフ・モーガン氏、Luminal創業者のジョー・フィオッティ氏、SGLangの中核開発者でRadixArkのリャンシェン・イン氏です。
本記事では、約1時間半の内容を、投資家・ビジネスパーソン向けに整理します。発言は要旨で、逐語ではありません。字幕の自動書き起こしに誤りとみられる箇所があり、モデル名や数字は文脈から補っています(末尾に補足します)。
1. なぜ推論か:学習より12倍重要という試算
1-1. DeepSeekの公開数値から
冒頭の概観で、YCの登壇者は、学習と推論の計算量の比較を、唯一データを公開しているDeepSeekで試算しました。
DeepSeek V3の学習:約280万H800時間
推論:1日あたり約4万3,000H800時間(古いデータで、実際はもっと多い見込み)
年換算で、推論は学習の約6倍。重みファイル(モデル)の実用期間を2年とすれば、約12倍
そのため、論文で学習計算量を揃えて比較する(Chinchilla型の)軸だけでなく、推論計算量を揃えた比較が必要だという主張です。同氏は、DeepSeekの利益率が、約80%と試算される点にも触れ、推論面の革新の成果だと述べました。
1-2. 推論が難しい理由と指標
推論は、プロンプトを処理する「プリフィル」と、トークンを1つずつ生成する「デコード」に分かれます。
モデルFLOP利用率(MFU):学習やプリフィルで約50%、デコードでは約5%。メーカーが示す理論性能の半分でも良好
主な指標:最初のトークンまでの時間(TTFT)、出力トークンあたりの時間、GPU時間あたりのスループット、サービス水準を満たしたスループット(グッドプット)
DeepSeekの公開値:1GPUあたり、キャッシュヒットを除くプリフィルは毎秒6万トークン、キャッシュヒットありでは毎秒150万トークン。入力キャッシュヒット率は96%、KVキャッシュの保持期間は72時間。TTFTは約400ミリ秒(P99で約1秒)。デコードは毎秒1万4,000トークンで、ここが律速
1-3. 最適化の3つの層
登壇者は、推論の最適化を3つに分けました。
モデル側:専門家混合(MoE)、全層で注意機構を使わない設計、潜在注意(MLA)、量子化、蒸留
カーネルとランタイム側:RadixAttention、FlashAttention、PagedAttention(OSやデータベースの手法の応用)
ハーネス側:ルーティング、投機的デコード、再帰的言語モデル、コンパクション
2. Together AI:推論リクエストの一生
2-1. オープンモデルの規模
フー氏によれば、オープンソースのAIは過去最大の規模にあります。
Together AIは、数か月前の時点で月400兆トークンを処理。Googleが公表したGeminiのトラフィックの約8分の1
OpenRouterでは、今年に入り、トークンの過半数がオープンモデル経由
オープンモデルは、同等かそれ以上の品質で、最大10倍安い
同社は、「AIネイティブなクラウド」として、事前学習、ファインチューニング、推論、エージェント用のサンドボックスを提供し、約80人の研究者が推論に注力しています。
2-2. リクエストの経路
ルーティング:単純な負荷分散に加え、同じ要求を同じGPUに送ってKVキャッシュを再利用できるようにする工夫が必要
トークン化:ツール呼び出しの正確さを保つ
スケジューリング:スループット重視か、即応性重視かで設計が変わる
プリフィル(計算律速)とデコード(メモリ律速):性質が違うため、別のGPUに分ける「分離(disaggregation)」も使う
2-3. 詳しく語られた3つの手法
カーネル:
社内の「Together Compiler」(名称は仮)で、エージェントに実トラフィックでカーネルを自動最適化させる。推論向けの再帰的自己改善の萌芽だと位置づけた並列化:
Kimi K3は、3兆パラメータで、FP4でも1.5テラバイトになり、1つのGPUに収まらない。Nvidiaの72GPUラックのような大きなスケールアップ領域で、専門家を別々のGPUに置けば、行列計算が大きくなり、効率が上がる。一方、72GPUのうち1つが故障すると、ラック全体が止まる恐れがあり、信頼性の確保に注力している量子化:
BF16を8ビットや4ビットに縮める。品質が最大の関門で、同社は、公開前に社内で使い込む「品質のレッドチーム」を運用し、Flappy Birdを書かせる自動ループまで回している。MiniMaxのM3は、同社のレシピで、NVFP4でも元のFP8と同等の性能を達成した。学習なしの手法(キャリブレーションや、同社が公開したscale search論文など)を使っているという
2-4. アーキテクチャの見通し
SSMや線形注意(Kimi K3のKDAなど)、疎な注意、拡散言語モデル(投機的デコードの下書き役)、ループ型モデルが、すでに主要なモデルで使われているとのことです。同氏は、良いアイデアが出れば、GPT-6やGPT-7に入るほど、反映が速いと語りました。
3. Ollama:オープンモデルのトークンは同じではない
3-1. 提供元ごとの品質差
モーガン氏は、同じオープンモデルでも、提供元によって品質が大きく異なると述べました。
最悪と最良の提供元の差が、クローズドモデルとオープンモデルの差より大きい
2024年の論文では、31のLlamaエンドポイントを調べ、同じ重みのはずなのに、GPT-3.5に近い性能のものが混在していた
原因は、過度な量子化、重みのバージョン違い、ツール呼び出しの失敗、サンプリング、推論エンジンの違い、誤った名前で提供される、など
エージェント作業で悪化する:15ステップの作業で、1回あたり10%の逸脱があれば、全体の約79%が誤りになる(同氏の例を、私が確認した計算)
3-2. 品質の見張り方
評価(ベンチマーク)の実行:確実だが高価で、継続的にできない
提供元自身の検証ツール:MoonshotのKimi K2のツール検証、MiniMaxの同種の取り組み
出力分布の比較:基準の重みとAPIの出力分布を比べる。1回約1ドルと安い
ログ確率(logprobs)の変化:1トークンの要求で、過去からのずれを測る。安いが、対応するAPIが少なく、最初から誤っている場合は検出できない
リクエストの形状の監視:ツール呼び出しの失敗、出力長の分布、無限ループなどを、データを保持せずに見る
将来の方向としては、モデルを作る研究所が推論の実装(DeepSeekが公開したDeepInfer)や、量子化済みの重みを自ら公開すること、ハーネス側でツール呼び出しを統一すること、Nvidia GPUの信頼実行環境を使った証明などを挙げました。質疑では、評価に「過学習」した量子化への対策として、顧客ごとの非公開テストが有効だと答えました。
4. Luminal:探索でコンパイルする
フィオッティ氏は、コンパイラが、GPUの計算量をトークンに変える「変換関数」を決め、収益性を左右すると述べました。
発想:PyTorchの約2,000の演算を、足し算、掛け算、総和など約14〜15の基本演算に分解する(「PyTorch完全」で、チューリング完全ではない)
手法:等式飽和(equality saturation)。書き換え規則を、元の式を壊さずに、あらゆる順序で適用して、等価なプログラムの空間を作り、その中から候補を実機で測って選ぶ。コスト関数は持たない
効果:巨大なコンパイラチームやカーネルライブラリを不要にし、NvidiaとAMDのGPU、TPU、Trainiumなどに対応。数十人ではなく、8人で、毎月約80兆トークンを処理しているという
質疑:探索するのは空間のごく一部(1%の1%)で、局所最適が大域最適の約99%に届けば良い。1回の実行は10ミリ秒未満で、コンパイル時間は、利用者が予算を決める。数値精度は明示的に扱う。同氏は、同社は収益化でき、コンパイラ企業としては珍しいと述べた
5. SGLang:エージェント時代のメモリ
イン氏は、SGLangの歩みを、エージェントのワークロードに沿って説明しました。
RadixAttention(2023年末):
共有されたプレフィックスをツリーで管理し、再利用する。メモリが足りない時は、使われていない葉から捨てるオーバーラップスケジューリング:
CPUの準備とGPUの実行を重ね、GPUの空きを減らす。DeepSeekのDeepInferも同様の方式。Hopperでは約1.1倍、Blackwellでは条件により最大約2倍の差HiCache:
GPU、ホストメモリ、外部ストレージをL1〜L3として使い、TTFTを56%下げたハイブリッド構造への対応:
スライディングウィンドウやMamba/KDAなどが混ざると、キャッシュ共有が難しい。統一したRadixツリーと、統一メモリプール、断片化を解消するコンパクションを導入した。キャッシュヒット率が95%から99%に上がれば、計算量は約5分の1になる学習側:
RLのロールアウト用に、推論を訓練ループに組み込む「Miles」を提供している
