LLM推論における非決定性を克服する方法

 (thinkingmachines.ai)
2 ポイント 投稿者 GN⁺ 2025-09-12 | 1件のコメント | WhatsAppで共有
  • LLM（大規模言語モデル） の推論では、同一の入力と条件でも結果が異なる 非決定性（nondeterminism） の問題が発生する
  • 従来は 並行性（concurrency） と 浮動小数点（floating-point）演算の非結合性（non-associativity） が非決定性の主因と見なされてきた
  • 実際の決定的な原因は、バッチサイズ（batch size）の変化 に伴うカーネル（演算コード）内部の計算順序の変化にある
  • カーネル内のすべての演算が バッチ不変性（batch invariance） を持つように実装すれば、完全な 再現性（reproducibility） を保証できる
  • データ並列演算、split reduction、固定サイズの split 戦略 などにより、主要演算（RMSNorm、matmul、attention）についてバッチ不変カーネルを作成できる

序論と問題の概要

  • 科学的進歩の中核要素である再現性（reproducibility） は、LLM（大規模言語モデル）の推論では十分に守られていない
  • 同じ質問を ChatGPT に何度もしても、異なる回答 が生成されることがよくある
  • これは LLM が結果を サンプリング（sampling） する過程で、確率分布に基づく 確率的選択 を行うためである
  • しかし、temperature を 0 に設定 しても、実際には LLM API が必ずしも 決定的ではない（つまり、同じ入力に対して結果が常に同じとは限らない）
  • オープンソースの推論ライブラリ（vLLM、SGLang など）や自前ハードウェアで実行しても、非決定性 の問題は存在する

従来の仮説と限界

  • 広く知られている仮説: 並行性 + 浮動小数点の非結合性 によって非決定性が発生する
    • GPU における浮動小数点演算は、演算順序やスレッド終了順によって結果がわずかに変わる
  • しかし実際には、同じデータで同じ方法の行列積を繰り返しても、常に同一の（bw=bitwise equal）結果 が得られる
  • 真の原因を把握するには、より深い分析が必要

LLM推論の非決定性の原因に関する詳細分析

浮動小数点の非結合性の本質

  • 浮動小数点演算は (a+b)+c ≠ a+(b+c) の関係を持つ
  • 大きさ（exponent）の異なる値同士を演算すると精度損失や情報損失が生じ、演算順序によって結果が変わる
  • 演算順序が変わりうるため、複数回の総和をランダムに実行すると 多様な結果（実験的にも確認） が導かれる

カーネルの演算順序変化と並行性

  • 一般に非決定性の主因として、atomic add などにおける並行性の問題が指摘される
  • しかし、LLM 推論で使われる大半のカーネル（特に forward pass）は、atomic add なしでも動作 する
  • 適切な並列戦略や split（reduction）などにより、同一の演算順序を確保 できる

実質的な核心原因: 「バッチ不変性（batch invariance）」の欠如

  • 個々のカーネルは、入力が同じであれば常に同じ結果を返す（run-to-run deterministic）
  • しかし、複数ユーザーの同時リクエストによってバッチサイズが非決定的に変化するため、各リクエストに対しては実質的に結果が一定しない
  • バッチサイズ に応じて内部で演算を分割したり結合したりする順序が変わり、非決定性が発生する
  • つまり、サーバー負荷と並列度（バッチサイズ）が非決定的だったこと が核心原因である

バッチ不変カーネル設計と主要演算の事例

RMSNorm

  • データ並列化（data-parallel） 戦略を適用: 各バッチ要素を独立に1つのコアが処理
  • バッチサイズが大きければ十分な並列性を維持でき、並列戦略が一定になるため バッチ不変性 が確保される
  • バッチサイズが非常に小さい場合は split reduction などの代替戦略を使うが、この場合は一部のバッチ不変性が犠牲になる

行列積（matmul）

  • タイル（tile）単位で並列化することでデータ並列戦略を活用
  • Tensor Core の利用最適化には 2D タイル分割が必要であり、バッチが非常に小さい場合には split-K のような特別な戦略が必要
  • split-K 戦略を使うとバッチ不変性が崩れる可能性がある
  • 一部の性能を犠牲にしても、同一のカーネル構成を強制することで一貫した（reproducible な）演算順序を確保できる

Attention

  • FlashAttention2 などでは、クエリ方向の並列化、Key/Value の同時 reduction 戦略によりバッチ不変性を確保する
  • バッチサイズやシーケンス分割（chunked prefill、prefix caching など）によって reduction 順序が変わると不変性が崩れる
  • split-KV（FlashDecoding）などの split-reduction 戦略では、split サイズを固定（fixed split-size） して演算順序を同一に保つ
  • 内部動作上、key/value キャッシュと新規トークンを別々に処理せず、すべての演算でキー/値レイアウトを一貫して維持する必要がある

実装

  • vLLM と torch.Library を活用して、batch-invariant カーネル を適用した決定的推論デモを提供
  • 関連演算の置き換えカーネルは GitHub リポジトリ（thinking-machines-lab/batch-invariant-ops）で閲覧できる

実験と性能

非決定性の測定実験

  • Qwen/Qwen3-235B-A22B-Instruct-2507 モデルで temperature 0 条件のもと、同一プロンプト（“Tell me about Richard Feynman”）を1000回生成
  • 80種類の異なる完了 が生成された（同一プロンプトでも非決定性が存在）
  • 最初の102トークンまでは同一で、103番目のトークンで最初の分岐が発生（“Queens, New York” vs “New York City”）
  • バッチ不変カーネルを使用すると1000回すべて同一結果 となり、完全な再現性を確保

性能評価

  • GPU 1台で Qwen-3-8B を実行し、それぞれ長さ90〜110のシーケンス1000件をリクエスト
    • vLLM デフォルト: 26秒
    • 非最適化 deterministic vLLM: 55秒
    • 改善版 attention カーネル適用: 42秒
  • 最適化は十分ではないものの、実用可能な性能水準を維持

On-policy RL における価値

  • 従来は training と inference の間の微細な数値差により、on-policy RL を正確に実装できなかった
  • 決定的推論が可能になれば、サンプリングとトレーニングをともに bitwise identical にでき、真の on-policy RL を実装できる
  • KL-divergence、reward など主要な metric で 完全に一致する結果 を確認

結論

  • LLM 推論システムでは非決定性や数値誤差が軽視されがちだが、この問題の 根本原因（バッチ不変性の欠如） を把握して改善すれば、完全な 再現性と決定性 を得られる
  • 本研究は LLM 推論の非決定性問題に対する解決策を示し、開発者が自社システム内で完全な再現性を確保できるよう支援する

引用情報

  • 本研究を引用する際は、以下の情報を使用
He, Horace and Thinking Machines Lab, "Defeating Nondeterminism in LLM Inference", 
Thinking Machines Lab: Connectionism, Sep 2025.

または

@article{he2025nondeterminism,
  author = {Horace He and Thinking Machines Lab},
  title = {Defeating Nondeterminism in LLM Inference},
  journal = {Thinking Machines Lab: Connectionism},
  year = {2025},
  note = {https://thinkingmachines.ai/blog/…},
  doi = {10.64434/tml.20250910}
}

関連記事

1件のコメント

 
GN⁺ 2025-09-12
Hacker News のコメント

  • 「理論上の」非決定性を完全に閉じた個別の入出力ペアで解決したとしても、実際には2つの非決定性の問題、つまり同じ入力でも前の文脈によって違う結果が出ることと、少し変形した入力が正しく変形された結果を返せないことが残る。こうした問題が解決されない限り、閉じたシステムでの非決定性は、実質的に参照テーブルで十分なケースを除けば、あまり役に立たない。テストしていない入力に対して「正確な」単体テストや評価セットで何かを証明するのは難しい

    • 「まったく同じ入力なのに前の文脈によって結果が変わる」という状況は実際には存在しない。前の文脈それ自体が入力だからだ。もしある入力プロンプトで常に同じ結果が出るなら、その文脈は無視されていると見なせる。つまり、セッション内の状態に関係なく、常に空の文脈から始めているのと同じだ。何人かが望んでいるのは、

      • 意味が同じさまざまなプロンプト文（例: "What is the capital of France" と "What is France's capital"）が同じ回答を返すべきだという要求
      • 前の文脈が質問と相互作用しないときは、結果に影響してほしくないという要求。たとえば、プロンプト "what is 2 + 2" には常に同じ答えが返り、文脈で 2 + 2 = 5 と指定しない限り変わってほしくない、ということだ。 こうした要求は、LLM というものに対する誤解を示している

    • 「前の文脈」が違う結果を生むことの何が問題なのか。もし文脈が結果に影響しないなら、文脈はただ捨てればよい。なぜわざわざそんな動作を望むのか。実際、ツールであれば、私の意図やモード切り替え（例: vim で insert モードに切り替えた後に動作が変わること）に応じて違う反応をすることを期待する。知能もそのように動いてほしい。文脈を無視するほうが、むしろ極端な確証バイアスに近く感じる

    • バグを再現するときには非常に有用

    • 「あまり役に立たない」と言ったところまでは同意していた。おそらく「問題を完全には解決してくれない」という意味で言ったのだと思う

  • 確率的システムで、なぜそんなに決定性を気にするのか気になる。ユーザーの立場では、"How do I X?" という入力に常にまったく同じ決定論的な答えを返したとしても、"how do i x?", "how do I x", "how do I X??" のような意味が同じ入力に対してまったく異なる結果が出るなら、あまり意味がない。LLM で本当に必要なのは、意味的に同じ入力なら常に意味的に同じ出力を保証する能力だ。これは、私たちが普通アルゴリズムで言う決定性とはまったく別の概念だ

    • すべての LLM ベースのアプリケーションが、ユーザーが即興でチャットするだけのインターフェースを持つわけではない。ツール呼び出しを評価目的で10回連続で行う場合や、DSPy Optimizer のようなツールリンクでプロンプトを継続的にテストする場合のように、トークンレベルの入力まで完全に自分で制御できるなら、予測不能性を減らすことが重要だ。こうした環境では、トークンレベルの揺らぎを取り除いて入力自体の曖昧さだけを残せれば、システムの振る舞いをはるかに信頼できるツリーやグラフ構造にマッピングできる

    • あなたの言うことは間違っていないが、だからといってこの程度の決定性が役に立たないわけではない。もしまったく同じ入力トークンを与えても毎回結果が違うなら、同僚と結果を再現しながら共有したり、LLM がごく稀で予測しづらい出力をする状況をテストしたり（例: red teaming）するのが難しくなる

    • LLM の出力にステガノグラフィで情報を埋め込むプロジェクトを進めている: innocuous モデルの上位10個程度のトークンだけを抽出して使っており、主に CPU ベースの 8B モデルでテストしているので、ハードウェアの影響でトークン順序が変わる心配はそれほど大きくないが、わずかな精度損失で選択肢が変わらないよう、eventually guard 条件も作っておくつもりだ

    • AI プラットフォームの顧客には非常に有用かもしれない。temperature 0 でプロンプトを何度も実行して結果が常に同じか確認すれば、AI プロバイダーが PRO モデルをこっそり安い別モデルにすり替えていないか検証できる

    • 「バグ」再現のためには必須だ。同じ入力文字列を与えたとき、同じ誤った出力や奇妙な出力を毎回再現できれば、デバッグはずっと簡単になる。結果が100回に1回だけ変わるようだと、はるかに難しくなる

  • （JAX/XLA で作業した経験あり）これはかなりよく知られている話だ。私自身も何度もこうした現象（バッチ単位の変動性）にぶつかっており、以下の issue で説明を読んだ: penzai issue #82, jax issue comment

    • この内容が最上位コメントになるべきだと思う

  • 非決定性の原因が実装の細部にあることもある。たとえば、GPT-2 のソースコードでは、GUI で temperature を 0 に設定しても、実際には 0 ではない "epsilon"（ごく小さな数）が入る。これは division by zero（ゼロ除算）エラーを防ぐためなので納得できる。非決定性は多くのアプリケーションでは「役に立たない」。LDA トピックモデルでも昔からある問題だ。特に法務、金融、規制分野では、決定論的でない手法を使うこと自体が違法である可能性すらある。あるいは、望ましくない追加義務（すべての画面記録を保管し、後から何が起きたかを一つひとつ復元できるようにしておくこと）を負うことになるかもしれない

  • 「他の人と一緒に Thinking Machines で働いた」という話が出てくる。昔、MIT AI Lab の前で赤い LED キューブが光っていたあのマシンを実際に見ていた頃を懐かしく思う。Richard Feynman は本当にすばらしい仕事をしていて、関連する記事もある Feynman and the Connection Machine。米国で “THINKING MACHINES” の商標は Hillis ではなく、彼が創業した会社に登録されており、1998–1999 年に抹消された。会社は 1994 年に倒産し、資産は Sun Microsystems（その後 Oracle）などに渡った。Amira Murati が設立した Thinking Machines Lab Inc. は 2025 年に新たに “THINKING MACHINES” の商標出願を進めている

    • あの会社名を見るたびに毎回この混同をしてしまう

  • 最近、高品質なブログスタイルの研究ディスカッションが増えていて本当にうれしい。Anthropic がこの文化を牽引していて、ますます広がっているようで期待が大きい。過去の RL 研究期には OpenAI もこういう感じだった

  • 自然言語そのものが曖昧さを持っている。曖昧でなければならない。ここで試みている「円を四角にして、なぜそうすべきかを説明しようとする」ようなアプローチは間違っていると思う。こうした議論は、結局のところ言語やランダム性の本質をもっとよく受け入れ、QKV projection matrix のようなミニ文法的な下位パターン以上のレベルで言語を解釈する議論へと発展していくだろう

    • その通り。ただ、決定性は曖昧さではない。決定性とは「まさにこの入力に対して、まさにこの出力を保証しなければならない」ということだ。同じモデルに同じ質問をすれば、必ず同じ答えが返るべきだと期待する。もちろん、文面を少し変えた質問なら、多少違う答えが返ることは十分理解できる

  • いまだにこの会社名が気に入らない。なぜこういう命名が繰り返されるのか不思議だ。伝説的な組織の性格が新興ベンチャーにも染み込むことを期待する文脈なのかもしれない。次のスタートアップの名前を PARC にしたからといって、ネットワーキングの革新が自動的に受け継がれるわけではないだろうと思う

    • 1994 年に消えた “Thinking Machines” という会社の話をしているのか？ 少し調べないと分からなかったし、思ったほど有名でもないので、そういう意図ではない気がする。単に格好よくて直感的な名前だと思う

    • 名前を付けるだけでマーケティングがタダで付いてくるのだから、商標制度が生まれた理由そのものだ

  • 本当に興味深い内容だ。知らない人のために言うと、この会社は元 OpenAI CTO の Mira Murati が始めたところだ