FP8にするとモデルの答えは変わる？ 120問中、変わったのは1問
共同: Anagha Langhe · NVIDIA L4 1枚でLLMをセルフホスト
30秒でわかる
Anagha Langhe は、NVIDIA L4 1枚で自分の言語モデルを動かしていて、FP8に切り替えると精度が落ちるのかを知りたがっていました。120問で、2つのビルドの正解数は72と71。これだけでは何も言えないので、私たちは「ひっくり返った問題」を数えました。変わったのは1問で、しかもbf16側が正解でした。49個の答えは一字一句まで同じで、両方のビルドが間違えたときは、48回中42回まで同じ間違った答えでした。Anaghaは公開の比較スクリプトを自分の2回分の実行にかけ、まったく同じ数字を得て、自分なりの結論を出しました。誤りの原因は量子化ではなく、検索（リトリーバル）にある、というものです。
問い
モデルをbf16ではなくFP8で動かすと、必要なメモリはおよそ半分になります。GPU1枚で動かすなら、それが唯一の理由と言っていいでしょう。気がかりなのは単純なことです。小さい形式にすると、知らないうちに答えが悪くなっていないか。
Anaghaはそれを直接測りました。同じ120問を両方のビルドに投げ、LinkedInにまとめています。bf16で72問正解、FP8で71問正解、正確なMcNemar検定でp = 1.0。同じ投稿では、彼女の環境の別の数字、プレフィックスキャッシュのヒット率が12%から26%に上がったことも共有しています。
72対71は「差なし」に見えます。ただ、120問だと、この種の検定で排除できるのは大きな低下だけです。3〜4ポイントの低下くらいなら、おそらく有意にはなりません。だから面白いのはp値ではなく、一問一問に実際に何が起きたかです。
誰が何をしたか
- Anagha は環境を組み、同じ120問で両方のビルドを走らせ、答えを採点し、のちに自分のファイルで比較を実行しました。
- 私たち（Vadym Chernets）は、どちらの向きに何問ひっくり返ったかを彼女に尋ね、モデルの一致を調べるために使っている公開スクリプトに小さな
compareモードを足し、彼女の集計から区間と計画用の数字を計算しました。 - Anaghaが全データでそのスクリプトを走らせると、同じ数字が返ってきました。さらに、集計からは見えなかった数字も一つ加わりました。2つのビルドが同じ形で間違えた頻度です。
数字で見る
| 指標 | 値 |
|---|---|
| 精度、bf16 | 72 / 120 |
| 精度、FP8 | 71 / 120 |
| ひっくり返った問題: bf16のみ正解 / FP8のみ正解 | 1 / 0 |
| 正確なMcNemar検定 | p = 1.0 |
| 差 bf16 − FP8 | +0.8ポイント、95%区間はおよそ −2.3〜+4.6 |
| 一字一句同じ答え | 120問中49問 |
| 両方不正解で、同じ間違った答え | 48問中42問 |
読み方です。ひっくり返ったのが1問というのは、FP8にコストがまったくかからない、という見方とは完全に矛盾しません。ただし、コストがかからない証明でもありません。2ポイント程度の低下なら、区間の中にまだ収まります。ひっくり返った問題が6問未満だと、どちらの向きに偏っても、正確なMcNemar検定ではp < 0.05に届きません。だからここで役に立つ数字は、ひっくり返った問題の数そのものと、区間です。1ポイントの低下を見つけるには、ひっくり返った問題がすべて同じ向きだったとしても、およそ800問が必要です。
私たちが意外だったのは、48問中42問のほうです。もしFP8版が単にノイズが多いだけなら、間違いはばらけるはずです。ところが実際には、2つのビルドは同じ問題でつまずき、同じ間違った答えに行き着いています。Anaghaの言葉を借りれば、これは「誤りは量子化ではなく検索に由来するという私の見方に合う」ということです。取得したコンテキストが悪ければ、どちらのビルドも同じ悪いコンテキストを読んで、同じことを言うのです。
自分の実行で試す
同じ問題で2回分の実行結果がJSONL形式であれば（質問ID、答え、そして correct フィールドか正解ファイルのどちらか）、比較はコマンド一つで済みます。公開リポジトリ memory-agreement-check の一部で、MITライセンス、依存パッケージはありません。
git clone https://github.com/vadimchernets/memory-agreement-check
cd memory-agreement-check
python -m memcheck compare bf16.jsonl fp8.jsonl --label-a bf16 --label-b FP81問につき1行で、次のような形です。
{"qid": "q001", "answer": "Paris", "correct": true, "category": "factual"}出力されるのは、2×2の表、正確なMcNemar検定、精度差の区間、同一の答えの数、2回の実行が一致して両方間違えた頻度、そして問題にカテゴリがあればカテゴリ別の内訳です。--md report.md でレポートを保存できます。
これが示すことと、示さないこと
- 120問あれば、FP8がこのモデルを台無しにしていないことは分かります。1〜2ポイントの低下がないとまでは言えません。
- 検定は、各問題が独立であるとみなします。多くの問題が一つの文書や一つのテンプレートから来ているなら、実質的なサンプルは120より小さくなります。
- 「誤りは検索に由来する」というのは、Anaghaが自分のシステムについて下した読みです。48問中42問はそれを裏づけます。直接確かめるには、同じ問題を、良いコンテキストと悪いコンテキストで一度ずつ解かせることになります。
これから
Anaghaは、自分のFP8とbf16の検証を、彼女の名前つきの実例としてリポジトリに入れることに同意してくれました。次に2つのビルドを比べる人が、人工的な例だけでなく、本物のケースから始められるようにするためです。
タイムライン
- AnaghaがLinkedInでFP8の検証を投稿します。120問中71対72、McNemarのp = 1.0。私たちは、p値よりひっくり返った問題の数のほうが多くを語る、とコメントします。彼女から返信があり、私たちはどちらの向きに何問ひっくり返ったかを尋ねます。
-
彼女の答えは、たった1問。bf16が正解でFP8が不正解で、逆はゼロ。120問中49問は一字一句まで同じ。その夜のうちに公開スクリプトに
compareモードが加わり、彼女の集計から計算した区間と計画用の数字を送ります。 - Anaghaが自分の2回分の実行で走らせると、数字は完全に一致し、両方のビルドが間違えたときは48問中42問で同じ間違った答えでした。彼女は実例としての掲載に同意します。