- temperature=0 でも GPT-4 と GPT-3.5-turbo が同じ入力に対して毎回異なる出力を返す現象は、従来の dense デコーダモデルでは起きない異例の挙動
- これまで非決定性の原因は CUDA の浮動小数点演算の不安定性 で説明されてきたが、それだけでは説明が不十分
- Sparse MoE アーキテクチャ の batched inference 構造では、同じバッチ内の異なるシーケンスのトークンが expert バッファの枠を奪い合うことで非決定性が発生
- 30回の反復呼び出し実験で GPT-4 は他モデルと比べて圧倒的に多くの固有出力を生成し、仮説を経験的に裏づけ
- モデルはシーケンス単位ではなく バッチ単位でのみ決定的 である点が、GPT-4 API の信頼性問題の核心
問題提起 — temperature=0なのになぜ出力が毎回違うのか
- GPT-4/GPT-3.5-turbo が temperature=0.0 でも非決定的であることは、すでに広く知られている事実
- dense decoder-only モデルで temp=0 は greedy sampling を意味し、これは完全な決定性につながるはず
- 次のトークンの logits は入力シーケンスとモデル重みだけの純粋関数だからである
- OpenAI World Tour の開発者ラウンドテーブルでの技術陣の回答
- 「正直、私たちも混乱している。システムのバグか、最適化された浮動小数点計算の非決定性 かもしれない」という趣旨
- この挙動は 2年前 から言及されている問題でありながら解決されていない点に疑問がある
- reliability を重視する OpenAI が意図的に非決定性を維持する理由はないため、当初は解決不能なハードウェア上の限界が最ももっともらしい説明とみなされていた
新たな仮説 — Soft MoE 論文で見つけた手がかり
- Soft MoE 論文の 2.2 節で決定的な手がかりを発見
- 容量制約（capacity constraints）の下では、あらゆる Sparse MoE 方式が固定サイズのグループ単位でトークンをルーティングし、グループ内の均衡を強制または誘導する
- グループが異なるシーケンス/入力のトークンを含む場合、それらのトークンは expert バッファの空き枠をめぐって互いに競合する
- その結果、モデルは シーケンス単位では非決定的で、バッチ単位でのみ決定的 となり、一部の入力シーケンスが他の入力の最終予測に影響する
- GPT-4 が Mixture of Experts モデルであることはすでに公知の事実
- GPT-4 は 2022 年第2四半期以前に学習されており、Sparse MoE はそれ以前から存在していた
- 提示された中心仮説
- GPT-4 API は batched inference を行うバックエンドでホスティングされている
- 他の要因も一部影響している可能性はあるが、API の非決定性の 大半 は Sparse MoE アーキテクチャがシーケンスごとの決定性を強制できないことに起因する
検証 — ハードウェア問題ではないことの確認
- 仮説検証のため GPT-4 に直接テストスクリプトの作成を依頼
- chat モデル（gpt-4, gpt-3.5-turbo）と completion モデル（text-davinci-003/001, davinci-instruct-beta, davinci）を対象に、同一プロンプトを temperature=0 で繰り返し呼び出し、固有出力数を集計
- スクリプト作成中に発生した問題
- OpenAI API の応答が非常に遅く、3.5 turbo の呼び出しでもほぼ 10 秒の遅延が発生。タイムスタンプのログを追加して自前のエラーではないことを確認
- 一部の completion モデルが応答を早めに打ち切るため、EOS トークンに logit bias を適用して補正
- chat モデルの
<|im_end|> トークン（100265）には同等の bias を適用できず、API が最大値 100257 超過のキーエラーを返した
- ほとんどの completion は max token 長に達しており、chat モデルはすでにはるかに非決定的だったため、この制約は本質的な問題ではないと判断
経験的結果
- 3 回試行、N=30、max_tokens=128 条件での固有出力（平均/30）
- gpt-4: 12, 11, 12 — 平均 11.67
- gpt-3.5-turbo: 4, 4, 3 — 平均 3.67
- text-davinci-003: 3, 2, 4 — 平均 3.00
- text-davinci-001: 2, 2, 2 — 平均 2.00
- davinci-instruct-beta: 1, 1, 1 — 決定的、出力は反復ループに崩壊
- davinci: 1, 1, 1 — 決定的、出力は反復ループに崩壊
- logit_bias の問題を発見する前の max_tokens=256 条件での結果
- gpt-4: 30, gpt-3.5-turbo: 9, text-davinci-003: 5, text-davinci-001: 2
結果の解釈
- GPT-4 の固有出力数は異常に多く、長い出力では事実上つねに非決定的
- 反復ループに崩壊しなかった他モデルにも一定レベルの非決定性があり、これは GPU 演算の不安定性 が一部のランダム性の原因であるという公開された主張と整合する
- 残る疑問点
- text-davinci-001 から gpt-3.5-turbo に向かってランダム性が段階的に増える理由について明確な説明がない
- GPT-4 の強い非決定性が MoE ではなく単純にパラメータ数の多さによる可能性も排除できないが、より高速な Turbo が davinci よりも非決定的である点はこの説明と矛盾する
含意
私たちはあまりに遅れている
- 非決定性が Sparse MoE の batched inference に内在する特性なら、この分野の関係者には自明であってよい事実
- GPT-4 の利用者の大半が API 不安定性の原因を知らない現実は、仮説が誤っているか、MoE モデルを理解する人が少なすぎてこの説明が公に広まっていないことを示唆する
- Google Deepmind はこれを理解しており、論文では通りすがりの一文で済ませるほど些細なものとして扱っていた。dense モデルしか扱わない他組織よりも Deepmind を楽観視できる根拠になる
GPT-3.5-Turbo も MoE である可能性
- 3.5-turbo が GPT-4 と同じアーキテクチャ を共有し、パラメータ数だけが大幅に少ないという噂がある
- Turbo の性能に到達するには 700億パラメータ が必要な現状は、OpenAI が処理するトラフィックの規模と速度を考えると、単一の dense モデルだけでは説明しにくい
- Turbo は API で logprobs が非公開に制限されている唯一の別モデル
- 従来の説明は distillation の精度向上を防ぐためというものだったが、Orca などの事例を見ると説得力が弱まる
- OpenAI が ChatCompletions への logprobs 統合作業を進めていると公表している点は、「distillation 防止」よりも「本質的にランダム性が高すぎて安定したエンジニアリングが難しい」という解釈を支持する
結論
- OpenAI の GPT モデルが temperature=0 で非決定的であることは周知の事実
- 通常その原因は CUDA 最適化された浮動小数点演算の不正確さ だとされる
- ここで提示される別の仮説は、Sparse MoE モデルの batched inference が GPT-4 API の非決定性の根本原因である というもので、従来の説明よりもすっきりしている
- GPT-4（および一部の 3.5 モデル）の API 呼び出しが、他の OpenAI モデルよりもはるかに非決定的であることを経験的に示した
- 速度、非決定性、logprobs の除去を根拠に、GPT-3.5-turbo も MoE である可能性 が推測される
1件のコメント
Hacker News のコメント
浮動小数点誤差は通常は決定的なので、同じ計算を2回実行すればビット単位まで同じ結果になるはず
結果が分かれるのは、バッファを適切にゼロ初期化していない、競合状態がある、丸めモードのフラグを一貫して設定していないなど、別の状態やエントロピー源がある場合だけ
AI/MLエコシステムで急ごしらえされるコード品質を見ると、この3つすべて、あるいはそれ以上のことが起きていそう
この場合はGPUの並列性のために数値を足す順序が非決定的になり、その結果がわずかに変わることがある
よく知らないシステム上に書かれたコードについて、他人のコードをけなすのは避けたほうがよい
CPUでも並列処理のために同じことは起こり得るが、CPUの個々の命令の大半は決定的である一方、CUDAは非決定的な基本演算を提供している
これは決定的な対応物より速いため意図された設計であり、それを悪いコードが生んだバグのように表現している点が問題
例えば加算や乗算のような一部の浮動小数点演算は結合法則が成り立たないため、リダクション（reduction）を終える実行順序によって結果が変わる
並列状況では性能のためにリダクション順序を非決定的にする実装もあり、そのため最終結果も非決定的になる
GetTimeOfDay()の呼び出しだけでも可能だし、複数プロセッサ間のクロック周波数ドリフトでもそうなり得るhttps://forumgeom.fau.edu/FG2012volume12/FG201216.pdf
参照論文の抜粋を正しく理解できているのか分からない
より効率的な推論の一部が、まったく別の入力、例えば他のユーザーの入力から来たトークンを混ぜることに依存している、という意味なのか？ そして、たまたま同じ束に入った別の入力によって「エキスパート」の割り当て比率が変わり、最終的な補完結果も変わるという意味なのか？
もしそうなら、単に非決定性を導入するだけでなく、同じエキスパート割り当てを巡って競合する同時リクエスト数に応答品質が左右される可能性もある
例えばヒンディー語の翻訳/解釈が得意なシステム部分が、インドのピーク時間帯には同じ能力を巡って同時に競合する入力が多くなり、より悪い結果を出す可能性がある
時間がたつにつれて品質が落ちたと感じる、別の説明にもなり得る。以前は特定のテストが安定して成功していたが、関連エキスパートの混雑が少なく、今は同時利用が増えて同じテストがそのエキスパートの労力を十分に得られていない状況かもしれない
あるサブエキスパートが特定領域で最初は印象的にうまくいくと、その領域の利用がさらに集中し、新たな混雑のために模倣的な利用はもはや同じエキスパート割り当てを受けられず、初期の印象的な性能が低下する泥沼も起こり得る
効果が強く、OpenAIがそれを知りながら公開していなかったのなら、最初は混雑していないMixture-of-Expertsシステムの代表性のない優秀さでユーザーを引き寄せ、その後より混雑したシステムの低品質な結果を提供する、おとり商品のようにも見える
おそらくバッチを別の形でまとめているのだろう。10個のバッチを5個ずつ2グループに分けるとき、自分のプロンプトが1つ目のグループに入るか2つ目のグループに入るかで答えが変わり、バッチ内で同じ位置にあれば同じ答えが得られる、という具合
同じバッチ、つまりシーケンスと順序が同じならバッチ全体は決定的だが、バッチを混ぜるとその決定性を失う
今でも信頼性は、多くの業務の中核フローでLLMの広範な導入を妨げる主要な障壁の一つ
GPT-4が本質的に非決定的で不安定だという噂が本当なら、ほとんどの企業は特定ドメイン向けに、性能が近いオープンソースLLMをファインチューニングするほうがよい
ドメイン特化モデルは常に汎用モデルより高い性能を出すので、そのほうが性能面の利点も大きい
GPT-3.5がMoEモデルなら、オープンソース陣営にとってかなり希望のある兆候ではないか？
良いオープンソースMoEモデルが出てくれば、既存のデコーダーモデルの変形のような形かもしれないし、はるかに少ないリソースではるかに多くのことができるという意味になる
MoEモデルをゼロから学習する必要があるのかは分からない
FLOPs:メモリ比を下げる方法、例えばSoft MoEは、CPUや少なくともApple Siliconでの推論もより意味のあるものにできるかもしれない
バッチ内のシーケンス同士が互いのルーティングに影響し得るなら、奇妙で実装しにくいサイドチャネル攻撃の可能性が出てくる感じがする
本当に素晴らしい仕事。いくつかの理由から MoE には強く反対してきたが、Substack の記事や噂の繰り返しではない説得力のある証拠を見たのは初めて
GPT-4 が非決定的だとはまったく知らず、1日に2時間ほど使っている
ざっと見ただけではなぜ気づきにくかったのか理解できる。記憶の中では「感じ」が似ていて似た語彙を多く使うが、形式はまったく違い、重要な単語の一部が同じで、同義表現のように変わる形だ
リンク先の gist の例を見ると、非決定的な出力は本当に似ている: https://gist.github.com/152334H/047827ad3740627f4d37826c867a...
ランダム性は制限されているはずなので、この部分は少なくとも驚くことではない
OpenAI はいずれ、このランダム性を減らす方法を見つけると思う。ChatCompletions に logprobs を再び追加するという公約もあるので、なおさらそう思える
同じ入力で API を繰り返し呼び出してプログラムを開発するような使い方なら、非決定性を見落とすのは難しい
これだけ多く使っている人が、今週出た一連の機能まで含めてどんな洞察を得たのか興味がある
MoE は Mixture of Experts、つまり専門家混合を意味する
記事の中ほどでようやく、ほとんど偶然のように略語を展開しているが、想定読者は専門家混合のほうらしく、私はそこに含まれていなかった
GPT-3.0 の davinci-instruct-beta モデルは、すでに2021年初めから非決定的な logprobs を返していた
これは推測であり、CUDA 自体にも非決定性のバグはよくある
text-davinci-001とtext-davinci-002は FeedMe と SFT で学習され、text-davinci-003は RLHF だったモデル自体も高い温度では分散が大きくなる
davinciとcode-davinci-002はどうだろう？「これらのトークンは、しばしば専門家バッファの利用可能な枠をめぐって互いに競合する」なら、私が長いコードを要求するときに ChatGPT が関数の場所にしばしばプレースホルダーだけを書き入れる理由もこれなのか？
「これらのトークンは、しばしば専門家バッファの利用可能な枠をめぐって互いに競合する」とは、つまり負荷が高いときに結果が変わるという意味なのか？
ときどき出力品質が変わる感じも、高負荷で説明できるのか？
MoE は Mixture of Experts を意味する