ポちのDeepResearch

DeepResearchの結果を個人的にまとめたサイト

LLM推論における非決定性の多角的検証：バッチ不変性、数値精度、およびシステムレベル効果の統合的分析

タグ: LLM推論

作成日: 2025年09月15日

動画解説

音声解説

閲覧データ（過去90日間）

ページビュー数: 5回
ユニークユーザー数: 4人
平均セッション時間: 282.05秒

プロンプト

「Defeating Nondeterminism in LLM Inference」で語られている内容を多角的に検証して信憑性を確かめて欲しい。

📋 目次

LLM推論における非決定性の多角的検証：バッチ不変性、数値精度、およびシステムレベル効果の統合的分析

エグゼクティブサマリー

本レポートは、Thinking Machines社がブログ記事「Defeating Nondeterminism in LLM Inference」で提示した主張について、多角的な検証と信頼性評価を行うものである。同記事は、大規模言語モデル（LLM）の推論における非決定性の主要因が、一般に信じられている「並行処理と浮動小数点演算の非結合性」ではなく、GPUカーネルにおける「バッチ不変性（batch invariance）の欠如」というシステムレベルの問題であると結論付けている。

本分析の結果、Thinking Machines社の中心的な論文、すなわち本番環境のLLM推論における非決定性の主要な、そして見過ごされがちな駆動要因がバッチ不変性の欠如であるという主張は、この分野における重要な貢献として肯定される。この論文は、これまで曖昧であった問題に対して、明確なメカニズムと実証的な証拠を提示している。

しかし、この主張をより広い文脈に位置づけることが不可欠である。学術研究では、BF16（BFloat16）のような低精度浮動小数点フォーマット固有の脆弱性が、バッチサイズの変動によって引き起こされる不整合を強力に増幅させる相補的な要因であることが示されている。つまり、バッチ不変性の欠如が演算順序を変動させる「メカニズム」である一方、低精度演算がその変動の影響を致命的なものにする「脆弱性」として機能する。

したがって、LLM推論における真の決定性を達成するには、どちらか一方だけでは不十分であり、包括的なアプローチが求められると結論付ける。これには、アルゴリズムレベルでの演算順序の固定（バッチ不変カーネルの実装）と、データレベルでの数値的安定性の確保（より高い精度の利用）の両方が含まれる。本レポートは、これらの要因を統合的に分析し、研究者および本番システムのエンジニアリングリーダーに対して、決定性を達成するための実践的な意思決定フレームワークを提供する。

1. 並列コンピューティングにおける非決定性の基礎的展望

LLM推論における非決定性の複雑な問題を解き明かす前に、その根底にある並列コンピューティングの基本原則を確立することが不可欠である。これらの原則は、後続の議論の土台を形成し、なぜ一見些細に見える違いが最終的に大きな結果の相違につながるのかを理解するための鍵となる。

1.1. 原罪：浮動小数点数の非結合性

コンピュータサイエンスにおける数値計算の根幹には、「浮動小数点数の非結合性」という避けられない特性が存在する。これは、数学的には真である結合法則 (a + b) + c = a + (b + c) が、コンピュータ上の浮動小数点演算では必ずしも保証されないという現象である 1。

この現象の根本原因は、浮動小数点数が実数を有限のビット数で近似的に表現する仕組みにある。特に、指数部が異なる二つの数値を加算する際には、一方の仮数部をシフトして指数を揃える必要があり、この過程で下位のビットが失われる「丸め誤差」が発生する。この丸め誤差の発生の仕方は、加算される数値の組み合わせと順序に依存する。したがって、同じ一連の数値を異なる順序で加算すると、各ステップで発生する丸め誤差が異なり、最終的な合計値がビットレベルで異なる結果となりうる 3。

これはバグではなく、広いダイナミックレンジの数値を効率的に表現するための根本的なトレードオフである。しかし、この特性こそが、並列コンピューティングにおいて演算の「順序」がなぜこれほどまでに重要となるかの核心的な理由である。

1.2. 従来の主犯：並行性、競合状態、およびアトミック操作

GPUにおける非決定性を説明する際の伝統的なモデルは、数千ものスレッドが並列に実行され、それらの完了順序が予測不可能であるという点に基づいている 1。ベクトル要素の総和を計算するようなリダクション操作において、複数のスレッドが単一のメモリ位置にある合計値に自身の計算結果を同時に加算しようとすると、「競合状態（race condition）」が発生する。

この問題を解決し、更新が失われないように（正当性を保証する）ために、ハードウェアレベルで提供されるのが atomicAdd のようなアトミック操作である 1。

atomicAdd は、メモリへの読み取り、変更、書き込みの操作が他のスレッドによって中断されないことを保証する。しかし、NVIDIAのCUDAドキュメントが示すように、atomicAdd は正当性を保証する一方で、どのスレッドの加算がどの順序で行われるかについては一切保証しない 7。完了したスレッドから順に、非決定的な順序で加算が実行される。

この「並行性＋浮動小数点」仮説は、長年にわたり深層学習における非決定性の標準的な説明であった。これは直感的であり、多くの並列コンピューティングの文脈で正しい。つまり、アトミック操作による非決定的な加算順序と、浮動小数点数の非結合性が組み合わさることで、同じ入力に対しても実行ごとに異なる結果が生じると考えられてきた。

1.3. 批判的再評価：LLM推論における「並行性＋アトミック」仮説

ここで、Thinking Machinesの記事は、この伝統的な仮説に対して重要な再評価を促す。その中心的な主張は、典型的なLLMの順方向パス（フォワードパス）では、実際には atomicAdd のような非決定的なアトミック操作はほとんど、あるいは全く使用されないというものである 1。

この主張の根拠は二つある。第一に、LLMの推論では通常、「バッチ次元」に沿って十分な並列性が確保できる。例えば、512個のリクエストを同時に処理する場合、GPUの各コアはそれぞれ独立したリクエストのリダクション操作を担当できる。これにより、複数のコアが一つのリクエストの合計値に殺到する必要がなくなり、アトミック操作が不要となる 1。

第二に、最新のニューラルネットワークライブラリは、性能を犠牲にすることなく決定性を達成するための様々な戦略を長年にわたって採用してきた。例えば、「分割（ツリー）リダクション」では、大きなリダクションを複数の小さなチャンクに分割して並列に処理し、最後にそれらの部分和を逐次的に（あるいはセマフォを用いて決定的な順序で）合算する。これにより、アトミック操作に伴う非決定性を回避できる 1。

この主張は極めて重要である。開発者フォーラムでの議論でも、GPUが「本質的に非決定的」であるか、それとも性能向上のために開発者が非決定的な手法を「選択」しているのかがしばしば議論されるが、後者の見解が優勢である 5。これは、決定的な代替手段が存在し、しばしば利用されているという記事の前提を裏付けている。

この再評価は、問題の所在を根本的に転換させる。これまで、非決定性の原因はGPUハードウェアの低レベルな動作原理（スレッドの完了順序やアトミック操作）にあると考えられてきた。しかし、LLMのフォワードパスという特定の応用分野において、これらのプリミティブが実際には使用されていないのであれば、「並行性＋アトミック」仮説は、原理的には正しくとも、この文脈においては的を射ていない（red herring）可能性が高い。

その結果、調査の焦点は、atomicAdd のようなハードウェアプリミティブから、推論サーバーとそのカーネルのシステムレベルのソフトウェアアーキテクチャへと移行しなければならない。問題は、マイクロ秒単位のハードウェアの競合ではなく、より高い抽象度、すなわちソフトウェアの論理の中に潜んでいることになる。この視点の転換こそが、Thinking Machinesが提示する「バッチ不変性」という新たな診断の出発点となる。

2. バッチ不変性という論文：システムレベルの診断

Thinking Machinesの記事が提示する中心的な論文は、LLM推論における非決定性の真の原因が、個々のカーネルの内部的な動作ではなく、システム全体のアーキテクチャに起因するというものである。このセクションでは、この「バッチ不変性」という概念を詳細に分析し、それがどのようにしてユーザー視点での非決定性を生み出すのかを明らかにする。

2.1. 用語の定義：実行間決定性 vs. バッチ不変性

議論の核心に迫る前に、記事で用いられる重要な用語を明確に区別する必要がある。

  • 実行間決定性（Run-to-Run Determinism）: これは、特定のカーネルやスクリプトが、同一の入力に対して複数回実行された場合に、常にビットレベルで同一の出力を生成する性質を指す 1。記事は、LLMで使用される行列乗算のような個々のカーネルの多くは、この意味で「決定的」であると主張している 9。
  • バッチ不変性（Batch Invariance）: これはより高次のシステム特性であり、バッチ処理されるリクエスト群の中で、ある単一のリクエストに対する出力が、そのリクエストと一緒に処理される他のリクエストの数や内容（すなわちバッチサイズや構成）に影響されず、常に同一でなければならないという性質を指す 1。

この二つの概念の区別が、論文全体の鍵となる。システムは、完全に決定的なコンポーネント（実行間決定性を持つカーネル）で構成されていながら、入力の構成が変化することで、エンドユーザーの視点からは非決定的な振る舞いを示す可能性がある。

2.2. 触媒：本番推論サーバーにおける動的バッチ処理

このシステムレベルの非決定性を引き起こす触媒となるのが、vLLMのような本番LLM推論サーバーで標準的に採用されている「動的バッチ処理」である 8。GPUの計算資源を最大限に活用し、スループットを向上させるため、サーバーは到着したユーザーリクエストをリアルタイムでグループ化し、「バッチ」としてまとめて処理する 9。

個々のユーザーの視点から見ると、自分のリクエストがサーバーに到着した瞬間のシステム全体の負荷は予測不可能である。したがって、自分のリクエストが、他の3つのリクエストと一緒にサイズ4のバッチで処理されるか、あるいは他の255のリクエストと一緒にサイズ256のバッチで処理されるかは、事実上ランダムな事象となる 9。この本番環境における避けられない最適化手法が、非決定性の温床となる。

2.3. 中心論文：バッチ不変でないカーネルがユーザー視点の非決定性を生む仕組み

ここから、Thinking Machinesの中心的な主張が明確になる。それは、以下の等式で要約できる。

決定的カーネル + 非決定的バッチサイズ = 非決定的システム出力 8

記事が指摘するのは、多くの高性能GPUカーネルが、GPUを常にビジー状態に保つために、入力されるバッチサイズに応じて内部の計算戦略を動的に変更する点である。例えば、小さなバッチを処理する場合と大きなバッチを処理する場合で、異なるアルゴリズムや異なる命令セットを選択することがある。この戦略の変更は、浮動小数点演算の実行順序を変える。そして、前述の通り、浮動小数点数の非結合性により、演算順序が変われば最終的な結果もビットレベルで変化する 1。

この主張は、複数の情報源によって裏付けられている。ある技術ブログでは、同じトークンに対する対数確率（logprob）がバッチサイズによって実際に異なる値になることが実験的に示されている 11。コミュニティの議論でも、これが既知の問題であることが確認されている 12。Thinking Machines自身の実験、すなわちデフォルト設定のvLLMで同じプロンプトを1000回実行したところ80種類のユニークな応答が生成されたという結果は、この現象の強力な実証的証拠となる 14。

この分析は、非決定性の原因に関する我々の理解を根本的に変えるものである。従来考えられていたように、ランダム性の源泉はGPU内部のマイクロ秒レベルのスレッド実行タイミングの揺らぎにあるのではない。そうではなく、ランダム性の源泉は、ユーザーリクエストの予測不可能な到着パターンという「外部環境」に移行している。システムは、このランダムな入力（＝動的に変動するバッチ）に対しては決定的に応答する。しかし、その応答の仕方がバッチサイズに依存するため、個々のユーザーにとっては非決定的な結果として現れる。

この視点の転換は、問題解決のアプローチにも大きな影響を与える。解決策は、低レベルのハードウェア制御（例えば、アトミック操作の挙動を制御するフラグ）にあるのではなく、高レベルのソフトウェアおよびアルゴリズム設計にある。すなわち、推論サーバーで実行される関数 f を「バッチ不変」にすること、つまり、あるリクエスト r1 に対応する出力部分が、バッチ内の他の要素に依らず常に同じになるように設計し直す必要がある。

以下の表は、LLM推論における非決定性の様々な原因を体系的に整理したものである。これにより、バッチ不変性の欠如が全体像の中でどのような位置を占めるかが明確になる。

表1: LLM推論における非決定性の原因の分類

原因カテゴリ 具体的な原因 因果メカニズム 主要な緩和戦略 パフォーマンスへの影響
アルゴリズム バッチ不変でないカーネル バッチサイズに応じてリダクション順序が変化し、浮動小数点の丸め誤差が変動する バッチ不変カーネルの実装 高
  アトミック操作の競合状態 スレッドの完了順序が非決定的であり、アトミック加算の順序が変動する 決定論的リダクションアルゴリズム（例：ツリーリダクション）の採用 低
データ型 低精度浮動小数点演算（例：BF16） 仮数部のビット数が少なく、丸め誤差が大きいため、演算順序の変動による影響が増幅される 計算にFP32を使用する（例：LayerCast） 中
アーキテクチャ Mixture-of-Experts (MoE) のルーティング バッチ内の他のトークンとの競合により、同じ入力シーケンスでも異なるエキスパートにルーティングされることがある バッチレベルでの決定性を確保する（シーケンスレベルでは困難） -
確率的 サンプリング（温度 > 0） トークンの選択が確率分布に基づいて行われる 温度を0に設定する（Greedy Sampling） なし

この表が示すように、バッチ不変性の問題は、性能への影響が大きい一方で、明確な緩和戦略が存在するアルゴリズムレベルの主要な原因である。

3. 技術的詳細：Transformerにおけるバッチ不変でない操作の分解

Thinking Machinesの記事は、単に「バッチ不変性の欠如」を指摘するだけでなく、Transformerアーキテクチャ内のどの具体的な操作がこの問題の影響を最も受けやすいかを特定している。本セクションでは、RMSNorm、行列乗算、アテンションの3つの主要な操作について、バッチサイズがどのようにして計算結果を変化させるのか、その技術的なメカニズムを詳細に分析する。

3.1. RMSNorm：分割リダクションの影響

RMSNorm（Root Mean Square Layer Normalization）は、各行（各トークンの埋め込みベクトル）の二乗平均平方根を計算する操作であり、本質的にリダクション（総和計算）を含む。

  • メカニズム: 大規模なバッチが与えられた場合、標準的な並列化戦略は「データ並列」である。つまり、GPUの各コアがバッチ内の一つの行（要素）全体を担当し、その行に関するリダクションをコア内で完結させる。このアプローチは、各行の計算が他の行から完全に独立しているため、本質的にバッチ不変である 1。

    問題が発生するのは、バッチサイズが小さく、GPUの全コアを飽和させるのに十分な行数が存在しない場合である。この状況でGPUの利用率を最大化するため、「最適化された」カーネルは「分割リダクション」と呼ばれる戦略に切り替えることがある。これは、単一の行の計算を複数のコアに分割し、共同でリダクションを行わせる手法である。この戦略変更は、リダクションにおける浮動小数点数の加算順序を根本的に変えてしまうため、バッチ不変性を破壊する 1。

  • 提案された解決策: 記事では、この問題に対して実用的な解決策を提示している。一つは、小規模バッチのケースを無視すること（RMSNormカーネルの実行時間は短いため、多少の非効率性は許容できる可能性がある）。より堅牢な解決策は、バッチサイズに関わらず、常に単一の、一貫したリダクション戦略（例えば、常にデータ並列アプローチ）を使用することである。これにより、小規模バッチではGPUの一部が遊休状態になるかもしれないが、計算の再現性が保証される 1。

3.2. 行列乗算（Matmul）：一貫性のないタイリングと命令選択

行列乗算は、Transformerの計算負荷の大部分を占める操作であり、これもまた本質的には要素ごとの積の後にリダクションを行う処理である。

  • メカニズム: cuBLASのような高性能ライブラリは、与えられた行列の次元（M, N, K）に応じて、最適な計算戦略を動的に選択する。バッチに関連する次元（MやN）が小さい場合、カーネルはリダクション次元であるKに沿って計算を分割する「Split-K」と呼ばれる戦略を採用することがある。これにより、複数のコアがK次元方向の部分和を並行して計算し、後でそれらを合算する。このSplit-Kの分割方法や合算順序がバッチサイズに依存するため、バッチ不変性が損なわれる 1。

    さらに、最新のGPUアーキテクチャ（例：NVIDIA Hopper）は、異なる形状やサイズのタイルを処理するために最適化された複数のテンソルコア命令を提供する。バッチサイズが変わると、ライブラリが異なるテンソルコア命令を選択する可能性があり、これらの命令は内部的に異なるリダクション順序を持つことがある。これもまた、非決定性の源泉となる 1。

  • 提案された解決策: ここでも解決策は「一貫性の強制」である。すなわち、あらゆる形状の行列乗算に対して、単一の安定したカーネル構成をコンパイルし、それを使用する。これにより、特定の形状に対するピーク性能は若干犠牲になる（cuBLASと比較して約20%の性能低下が引用されている）が、バッチサイズが変わっても常に同じ計算パスを辿ることが保証され、バッチ不変性が達成される 1。

3.3. アテンション：最も複雑な課題

アテンションメカニズムは、その複雑さからバッチ不変性を達成する上で最も困難な課題を提示する。

  • メカニズム: アテンションは、シーケンス次元と特徴次元の両方に沿ったリダクションを含むため、問題がより複雑になる。さらに、この問題は、長いプロンプトを効率的に処理するための「チャンク化されたプレフィル」や、生成されたトークンのキーとバリューを再利用する「KVキャッシング」といった、推論時の最適化によって悪化する。これらの最適化は、一度に処理されるトークンの数やメモリ上の配置を動的に変化させるため、リダクションの順序に一貫性を持たせることが困難になる 1。

    特に、最初のプロンプトを処理する「プレフィル」フェーズと、トークンを一つずつ生成する「デコード」フェーズでは、クエリの長さが大きく異なる。デコードフェーズではクエリ長が1であるため、FlashDecoding（Split-KV）のような特殊な分割リダクションカーネルがしばしば必要とされ、これがプレフィルフェーズの計算方法との間に不整合を生み、バッチ不変性を破壊する大きな要因となる 1。

  • 提案された解決策: 記事が提案する巧妙な解決策は、「分割数を固定する」のではなく、「各分割のサイズを固定する」という「固定分割サイズ」戦略である。シーケンス長に応じて分割の「数」が変動するが、各分割チャンク内での計算（リダクション）は常に同じ方法で行われる。これにより、処理するトークンの数に関わらず、常に同一のリダクション順序が保証され、バッチ不変性が達成される 1。

3.4. vLLMとtorch.Libraryによる実装

これらの理論的な解決策の信頼性を高めるために、Thinking MachinesはvLLMのFlexAttentionバックエンドとPyTorchのtorch.Library機能を利用した概念実証（Proof-of-Concept）実装を提供している。torch.Libraryを用いることで、既存のPyTorchの演算子を非侵襲的な方法で、自作のバッチ不変カーネルに置き換えることが可能になる。このオープンソース化された実装は、提案された解決策が単なる理論に留まらず、現実の推論エンジン上で実現可能であることを示しており、記事の主張に大きな説得力を与えている 1。

4. 重要な補完的視点：数値精度の影響

Thinking Machinesの記事が「バッチ不変性の欠如」というアルゴリズムレベルの問題を鮮やかに解明した一方で、学術研究からは、この問題を大きく増幅させるもう一つの重要な要因、すなわち「数値精度」の役割が指摘されている。このセクションでは、これらの研究成果を紹介し、バッチ不変性の論文と統合することで、非決定性の全体像をより深く理解する。

4.1. 低精度フォーマットの脆弱性：BF16 vs. FP16 vs. FP32

LLMの学習と推論では、メモリ使用量と計算速度を最適化するために、標準的な32ビット浮動小数点数（FP32）よりも低い精度のフォーマットが広く採用されている。中でもBF16（BFloat16）は、FP32と同様のダイナミックレンジ（指数部が8ビット）を保ちつつ、精度（仮数部が7ビット）を大幅に削減したフォーマットであり、多くの最新GPUでサポートされている。

しかし、arXivに投稿されたある論文は、このBF16の利用が再現性の脆弱性に直結することを体系的な実験によって明らかにしている 3。この研究によれば、BF16を用いた推論は、評価バッチサイズ、使用するGPUの数や種類といったシステム構成の変更に対して極めて敏感である。Greedy Decoding（温度0）という決定論的な設定でさえ、BF16を使用したモデルは、構成の違いによって正解率に最大9%のばらつきを示し、応答長も大きく変動した 4。

対照的に、同じ16ビットフォーマットでも仮数部が10ビットと多いFP16はより安定しており、仮数部が23ビットであるFP32に至っては、システム構成を変更しても分散がほぼゼロとなり、浮動小数点の丸め誤差に対して非常に堅牢であることが示された 3。これは、BF16の極端に短い仮数部が、演算順序の変更によって生じる丸め誤差の差異を相対的に大きくし、後続の計算でその誤差が雪だるま式に増幅されやすいためである。

4.2. 論文の統合：精度誘発不安定性の増幅器としてのバッチ不変性の欠如

Thinking Machinesの論文と、この数値精度に関する学術研究は、決して対立するものではない。むしろ、それらは同じ問題の異なる側面を照らし出す、相互補完的な関係にある。

  • メカニズムとしてのバッチ不変性の欠如: Thinking Machinesが明らかにしたように、「バッチ不変性の欠如」は、浮動小数点演算の順序をシャッフルする具体的な「メカニズム」である。バッチサイズが変わることで、カーネルは異なる計算戦略を選択し、結果として加算の順序が変動する。
  • 脆弱性としての低精度: 一方で、BF16のような「低数値精度」は、システムがその演算順序の変更に対してどれだけ敏感であるかを決定する「脆弱性」である。FP32のような高精度フォーマットを使用している場合、演算順序が変わっても生じる結果の差異は非常に小さく、多くの場合、後続の計算に影響を与えずに収束する。しかし、BF16を使用している場合、そのわずかな順序の変更が、無視できない大きさの誤差を生み出し、それが非線形な活性化関数などを通じて増幅され、最終的には全く異なるトークンが選択されるという分岐を引き起こす。

したがって、本番システムで観測される非決定性は、これら二つの要因の相乗効果として理解するのが最も正確である。バッチ不変でないアルゴリズムと、低精度演算の脆弱性が組み合わさることで、初めて深刻な問題として顕在化する。Thinking Machinesの記事はソフトウェアレベルの原因（バッチ不変でないカーネル）を正確に特定したが、ハードウェア／データフォーマットレベルの脆弱性（BF16）の役割を相対的に軽視している。逆に、学術論文は脆弱性を正確に特定したが、その脆弱性を突く主要なメカニズムとしてバッチ不変でないカーネルの挙動を組み込むことで、より説得力を増すだろう。

4.3. 代替的解決策：高精度計算

この数値精度の脆弱性という観点から、学術研究はThinking Machinesとは異なるアプローチの解決策を提案している。それが「LayerCast」と呼ばれる推論パイプラインである 3。

LayerCastのアイデアは、メモリ効率と数値的安定性の両立を目指すものである。モデルの重みはBF16のような16ビットフォーマットでメモリ上に保持する。これにより、大規模モデルでもGPUメモリの消費を抑えることができる。しかし、行列乗算やアテンションといった実際の計算は、すべてFP32にアップキャストして実行する。これにより、演算中の丸め誤差を最小限に抑え、演算順序の変動に対する堅牢性を確保する。

これは、カーネルのアルゴリズム自体を修正して精度誤差に強くする（Thinking Machinesのアプローチ）のではなく、データフォーマット自体をアルゴリズムの変動に強いものにする（LayerCastのアプローチ）という、興味深い対比を示している。どちらのアプローチが優れているかは一概には言えず、性能への影響や実装の容易さなどを考慮して、状況に応じて選択されるべきであろう。

5. 決定性の実用性：パフォーマンスと費用対効果の分析

LLM推論における決定性の実現は、無償ではない。再現性と引き換えに、計算速度やスループットといった重要なパフォーマンス指標が犠牲になる可能性がある。本番システムのアーキテクチャを担うエンジニアリングリーダーにとって、このトレードオフを正確に理解し、費用対効果を評価することは極めて重要である。

5.1. バッチ不変カーネルのオーバーヘッドの定量化

Thinking Machinesの記事および関連する議論は、バッチ不変カーネルを導入することによる性能への影響について具体的な数値を提供している。

  • 最適化されていない決定論的なvLLM実装は、デフォルトの非決定論的な実装と比較して最大で2倍遅くなる可能性がある 10。
  • アテンションカーネルを注意深く最適化することで、この速度低下は1.6倍程度に緩和される 10。
  • 他の報告では、性能が約半分に低下する 12、あるいは行列乗算においてcuBLASと比較して約20%の性能低下が見られる 8 といった見積もりも存在する。

これらの数値を総合すると、バッチ不変性を実現するための性能コストは、20%から60%程度のスループット低下と見積もるのが妥当であろう。これは、本番環境におけるスループット、レイテンシ、そして運用コストに直接影響を与える、非常に大きな代償である。

5.2. 高精度（FP32）推論のパフォーマンスコスト

LayerCastのような高精度計算アプローチもまた、性能上のトレードオフを伴う。BF16からFP32へ計算を移行すると、各数値のデータサイズが2倍になるため、GPUのメモリバンド幅への要求が単純に2倍になる。さらに、最新のGPUに搭載されているテンソルコアは、BF16やFP16といった低精度フォーマットでのスループットが最大になるように設計されており、FP32での計算ではその恩恵を最大限に受けることができない。

LayerCastの論文は、重みを16ビットで保持することでこの影響を緩和しようと試みているが、計算がメモリバンド幅律速か計算律速かによって、その性能ペナルティはバッチ不変カーネルアプローチよりも大きくなる可能性も小さくなる可能性もある 3。

5.3. フレームワークレベルの制御とそのコスト

PyTorchやTensorFlowのような深層学習フレームワークは、決定性を確保するための高レベルなフラグを提供している。例えば、torch.use_deterministic_algorithms(True) 16 や

TF_DETERMINISTIC_OPS=1 18 などがそれにあたる。

しかし、これらの公式ドキュメントは、決定論的な設定がしばしばより低速なアルゴリズムを使用するため、パフォーマンスに悪影響を与える可能性があると明確に警告している 17。例えば、PyTorchで

torch.backends.cudnn.benchmark = False を設定すると、cuDNNが実行時に最も高速な畳み込みアルゴリズムを動的に探索する機能が無効になり、再現性は向上するが性能は低下する可能性がある 17。

これらのフレームワークレベルのフラグは、いわば「鈍器」のようなものであり、システム全体の動作を決定論的にしようとする。これに対し、Thinking Machinesのアプローチはより「外科的」であり、バッチ不変性の欠如という特定の非決定性の原因のみを修正し、他の最適化は可能な限り維持しようとする点で異なっている。

5.4. トレードオフの評価：真の決定性はいつコストに見合うのか？

決定性を追求することの価値は、その応用分野に大きく依存する。

  • 絶対的な要件となる分野: 科学研究やベンチマーキングの世界では、再現性は「科学的進歩の礎」であり、必須の要件である 1。同様に、金融や医療といった規制の厳しい業界で用いられるエンタープライズアプリケーションでは、検証可能で常に同一の出力が生成されることが、単なる特徴ではなく法的・倫理的な要件となる 9。
  • 許容、あるいは望ましい分野: 一方で、創造性が求められる消費者向けのチャットボットのようなアプリケーションでは、ある程度のばらつきは許容されるか、むしろ望ましいとさえ考えられることがある 20。
  • 中間の分野: そして、複数のツールコールを連続して行うエージェント的ワークフローや、真のオンポリシー強化学習のような新しい応用分野が存在する。これらの分野では、ビットレベルでの完全な再現性は必ずしも必要ではないかもしれないが、「予測不可能なドリフト」が減少することは、システムの安定性と信頼性を高める上で非常に有益である 21。

この分析から導き出される結論は、決定性の必要性は普遍的ではなく、アプリケーションごとに判断されるべきだということである。その実現には高いパフォーマンスコストが伴うため、デフォルトで有効にすべきものではなく、明確な意思決定に基づく選択であるべきだ。

これにより、議論の焦点は「いかにして決定性を達成するか」から、「いつその対価を支払うべきか」へと移行する。推論サービスプロバイダーは、将来的に「決定論的モード」を、追加料金で提供されるプレミアム機能として位置づけるかもしれない。そして、各開発チームは、自らのユースケースにおいて決定性がもたらす価値と、それが要求する性能コストを天秤にかけるための、明確な費用対効果分析フレームワークを構築する必要に迫られるだろう。

6. 信頼性評価と最終的な統合

本レポートの分析を通じて、Thinking Machinesの記事「Defeating Nondeterminism in LLM Inference」が提示した主張の信頼性を評価し、LLM推論における非決定性の全体像を統合的に結論付ける。

6.1. Thinking Machinesの論文の妥当性：健全かつ重要な貢献

本検証の結果、Thinking Machinesが提唱する中心的な論文、すなわち「最新のLLM推論サーバーにおいてユーザーが知覚する非決定性の主要な駆動要因は、GPUカーネルにおけるバッチ不変性の欠如である」という主張は、極めて信頼性が高く、証拠によって十分に裏付けられていると評価する。

この記事は、これまで漠然と「GPUの並列処理に起因するもの」とされてきた問題に対し、明確なメカニズム（バッチサイズに応じたカーネル戦略の動的変更）を提示した。さらに、その主張を実証的な実験結果（1000回の実行で80種類の出力）と、動作する実装（オープンソースのバッチ不変カーネル）によって裏付けている。これは、これまで学術界や産業界で十分に議論されてこなかったシステムレベルの問題を的確に特定した、重要かつ価値のある貢献である。

6.2. 限界と省略：数値精度分析の統合の必要性

一方で、この記事の主な限界は、数値精度の役割に対する焦点が相対的に不足している点にある。記事は浮動小数点数の非結合性を「原罪」として認識しているものの、BF16とFP32というデータフォーマットの選択が、システムのバッチ不変性に対する感度をいかに劇的に変化させるかについては深く掘り下げていない。

学術研究が示したように 3、数値精度は単なる背景条件ではなく、非決定性の方程式における決定的な変数である。BF16の脆弱性は、バッチ不変性の欠如によって引き起こされる小さな誤差を、最終的な出力の分岐につながる大きな違いへと増幅させる。したがって、非決定性の問題を完全に診断するためには、バッチ不変性の論文と数値精度の分析を統合し、両者が相乗的に作用する様を理解する必要がある。

6.3. 「非決定性の克服」に関する最終評価

結論として、Thinking Machinesの記事は、非決定性の特定の、しかし非常に重要な原因を「克服」する方法を成功裏に示しており、その主張は大部分において正当化される。彼らが開発したバッチ不変カーネルは、この問題に対する強力な解決策である。

しかし、LLM推論における「包括的な」決定性を達成するには、より広い視野が必要となる。それには、本レポートで統合的に分析したように、数値精度の管理（例：FP32計算の採用）、MoEモデルにおけるルーティングのような他の非決定性要因の制御 22、そしてフレームワークレベルでの適切な決定性フラグの設定などが含まれる。Thinking Machinesは強力な新しい武器を提供したが、それは非決定性との戦いにおける、より大きな兵器庫の一部と位置づけるのが最も正確な評価であろう。

7. 再現可能なLLM推論を達成するための実践的推奨事項

本レポートの分析結果を、AI研究者および本番システムのエンジニアリングリーダーが直面する現実的な課題に対応するための、実践的な推奨事項へと落とし込む。

7.1. 研究者およびベンチマーキングチーム向け

  • Greedy Decoding評価におけるFP32計算の優先: 異なるハードウェアやシステム構成間での結果の比較可能性を保証するため、Greedy Decoding（温度0）を用いるすべての評価において、可能な限りFP32での計算を優先すべきである 3。これは、特にモデルの能力を厳密に比較する際に、数値精度に起因するばらつきを排除するために不可欠である。
  • 低精度使用時の厳格な報告: 計算資源の制約によりBF16のような低精度フォーマットを使用せざるを得ない場合は、単一の実行結果のみを報告するのではなく、複数回実行した結果の平均値と誤差範囲（標準偏差など）を報告することが強く推奨される。さらに、使用したハードウェア（GPUの種類）、ソフトウェアスタック（フレームワークのバージョン）、および推論構成（バッチサイズ、テンソル並列サイズなど）を完全に文書化し、第三者による再現を可能な限り容易にすべきである 3。
  • 単一実行ベンチマークスコアの脆弱性の認識: BF16を用いた単一実行によるベンチマークスコアは、システム構成に大きく依存するため「脆弱」であり、誤解を招く可能性があることを常に認識する必要がある。

7.2. 本番環境のエンジニア向け：意思決定フレームワーク

本番環境では、決定性とパフォーマンスのトレードオフを慎重に管理する必要がある。以下のステップからなる意思決定フレームワークを提案する。

  • ステップ1：必要性の評価:
    まず、対象のアプリケーションがどのレベルの再現性を要求するかを明確に定義する。
    • ビットレベルの再現性: 金融取引の監査、医療診断の記録など、法規制やコンプライアンス上、常にビットレベルで同一の出力が必要か？
    • 意味論的な一貫性: マルチステップのエージェントやツール利用において、出力の細部が異なっても全体としての一貫した振る舞いが維持されれば十分か？
    • 変動の許容: クリエイティブなテキスト生成や一般的な対話など、出力のばらつきが問題にならない、あるいはむしろ望ましいか？
  • ステップ2：戦略の選択:
    評価された必要性と、許容できるパフォーマンスト（コスト）予算に基づき、適切な戦略を選択する。
    • 最優先（高コスト）: ビットレベルの再現性が必須の場合、Thinking Machinesが提供するようなバッチ不変カーネルを実装し、さらに可能であればFP32計算を併用する。
    • 中優先（中コスト）: 意味論的な一貫性が重要な場合、LayerCastアプローチ（FP32計算）またはBF16とバッチ不変カーネルの組み合わせを検討する。
    • 低優先（低コスト）: 変動が許容される場合、パフォーマンスを最大化するために、標準的な高性能BF16推論を引き続き使用する。
  • ステップ3：実装と監視:
    選択した戦略に基づき、利用可能なツール（例：Thinking Machinesのライブラリ、フレームワークのフラグ）を用いて実装を行う。導入後は、パフォーマンス（スループット、レイテンシ）と決定性のレベルを継続的に監視し、ビジネス要件とコストのバランスを最適化する。

7.3. 決定論的AIシステムの未来

LLMにおける決定性の追求は、今後さらに重要性を増すと考えられる。将来的には、以下のような展開が予測される。

  • ハードウェアとソフトウェアの協調設計: バッチ不変な操作をより高性能に実行するための、ハードウェアレベルのサポートや、コンパイラの最適化が進む可能性がある。
  • 階層化された推論サービス: クラウドプロバイダーが、異なるレベルの決定性保証を持つ推論サービスを、異なる価格帯で提供するようになるかもしれない（例：「標準推論」vs.「高信頼性・決定論的推論」）。
  • 新たな応用分野の牽引: Thinking Machinesの記事でも言及されているように、LLMからのフィードバックを用いた決定論的なオンポリシー強化学習（True On-Policy RL）のような、これまで不可能だった新しいAIパラダイムの開発が、これらの決定性技術の採用を強力に牽引する可能性がある 1。

再現性の確保は、AIを単なる興味深い技術から、社会の基盤となる信頼性の高いエンジニアリングシステムへと昇華させるための、避けては通れない道程である。

引用文献

  1. Defeating Nondeterminism in LLM Inference - Thinking Machines Lab, 9月 15, 2025にアクセス、 https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/
  2. Blog Pamela Toman, 9月 15, 2025にアクセス、 https://www.pamelatoman.net/blog/
  3. Give Me FP32 or Give Me Death? Challenges and Solutions for Reproducible Reasoning, 9月 15, 2025にアクセス、 https://arxiv.org/html/2506.09501v1
  4. (PDF) Give Me FP32 or Give Me Death? Challenges and Solutions for Reproducible Reasoning - ResearchGate, 9月 15, 2025にアクセス、 https://www.researchgate.net/publication/392597345_Give_Me_FP32_or_Give_Me_Death_Challenges_and_Solutions_for_Reproducible_Reasoning
  5. Non-determinism in GPT-4 is caused by Sparse MoE Hacker News, 9月 15, 2025にアクセス、 https://news.ycombinator.com/item?id=37006224
  6. Deterministic Atomic Buffering - IEEE/ACM International Symposium on Microarchitecture, 9月 15, 2025にアクセス、 https://microarch.org/micro53/papers/738300a981.pdf
  7. CUDA C++ Programming Guide - NVIDIA Documentation, 9月 15, 2025にアクセス、 https://docs.nvidia.com/cuda/pdf/CUDA_C_Programming_Guide.pdf
  8. Determinism, Speed-of-Light Kernels, and True On-Policy RL: How to Make LLM Systems Behave by Rajveer Rathod - Medium, 9月 15, 2025にアクセス、 https://medium.com/@rajveer.rathod1301/determinism-speed-of-light-kernels-and-true-on-policy-rl-how-to-make-llm-systems-behave-f7b371cbfc10
  9. The Real Reason for LLM Inference Nondeterminism - StartupHub.ai, 9月 15, 2025にアクセス、 https://www.startuphub.ai/ai-news/ai-research/2025/the-real-reason-for-llm-inference-nondeterminism/
  10. Why Your LLM Gives Different Answers, Even When It Shouldn’t (And How We’re Fixing It) by Cihat Emre Karataş Sep, 2025 Medium, 9月 15, 2025にアクセス、 https://medium.com/@emredeveloper/why-your-llm-gives-different-answers-even-when-it-shouldnt-and-how-we-re-fixing-it-1ef22f0b55c0
  11. Understanding Batch Size Impact on LLM Output: Causes & Solutions by Doil Kim, 9月 15, 2025にアクセス、 https://medium.com/@kimdoil1211/understanding-batch-size-impact-on-llm-output-causes-solutions-cd8b16d165a6
  12. Thinking Machines Lab dropped a new research: Defeating Nondeterminism in LLM Inference : r/LocalLLaMA - Reddit, 9月 15, 2025にアクセス、 https://www.reddit.com/r/LocalLLaMA/comments/1ne58kw/thinking_machines_lab_dropped_a_new_research/
  13. There’s been great interest in what Mira Murati’s Thinking Machines Lab is building - Techmeme, 9月 15, 2025にアクセス、 https://www.techmeme.com/250913/p15
  14. Mira Murati’s Thinking Machines Cracks the Code on LLM Nondeterminism, 9月 15, 2025にアクセス、 https://analyticsindiamag.com/ai-news-updates/mira-muratis-thinking-machines-cracks-the-code-on-llm-nondeterminism/
  15. Billion-Dollar Unicorn Releases Long Article Solving LLM Inference Non - Deterministic Problem in First Public Statement After 7 - Month Establishment - 36氪, 9月 15, 2025にアクセス、 https://eu.36kr.com/en/p/3461963944908162
  16. torch.use_deterministic_algorithms — PyTorch master documentation, 9月 15, 2025にアクセス、 https://alband.github.io/doc_view/generated/torch.use_deterministic_algorithms.html
  17. Reproducibility — PyTorch 2.8 documentation, 9月 15, 2025にアクセス、 https://docs.pytorch.org/docs/stable/notes/randomness.html
  18. Deterministic Tensorflow Part 1: Model Training - jackd, 9月 15, 2025にアクセス、 https://jackd.github.io/posts/deterministic-tf-part-1/
  19. tensorflow-determinism 0.3.0 - PyPI, 9月 15, 2025にアクセス、 https://pypi.org/project/tensorflow-determinism/0.3.0/
  20. Re: Defeating Nondeterminism in LLM Inference, The Future is Predictable HackerNoon, 9月 15, 2025にアクセス、 https://hackernoon.com/re-defeating-nondeterminism-in-llm-inference-the-future-is-predictable
  21. Defeating Nondeterminism in LLM Inference - Hacker News, 9月 15, 2025にアクセス、 https://news.ycombinator.com/item?id=45200925
  22. Achieving Consistency and Reproducibility in Large Language Models (LLMs) AI Mind, 9月 15, 2025にアクセス、 https://pub.aimind.so/creating-deterministic-consistent-and-reproducible-text-in-llms-e589ba230d44
タグ: LLM推論