推論ソフトウェアスタックのわずかな違いが、出力トークンを変えてしまう
梦晨（凹非寺発）
終わった！ 苦労してローカルにデプロイした大規模モデルが、なぜ公式版よりずっと頭が悪い？？
同じGPU、まったく同じ重みを使っていても、推論ソフトウェアスタックのわずかな違いによって、モデルが重要な箇所でまったく異なるトークンを出力し、場合によってはツール呼び出しが完全に失敗することさえあります。
この落とし穴は簡単に発生する一方で、原因の特定は非常に困難です。まるで三体人が「智子封鎖」を仕掛けているのではないかと疑いたくなるほどです。
Level1Techsフォーラムのユーザー thr3e 氏は、一連の実験を実施しました。RTX PRO 6000 Blackwell上で Qwen3.6-27B を使用し、10万トークン以上にわたる全量 logit キャプチャテストを行ったものです。
Logits とは、すべての候補トークンに対して計算された生のスコアの集合であり、サンプラー（sampler）を経て次のトークンが出力されます。
重要なのは、logits が純粋な数学的産物だという点です。行列乗算、アテンション計算、活性化関数などを何層にもわたって適用した結果として得られる浮動小数点数です。同じ重みと同じ入力を使う2つのシステムがあれば、理論上は完全に同一の logits が計算されるはずです。
しかし現実には、浮動小数点演算の精度、加算の順序、ハードウェア命令セットの違いによって、最終的な数値にはわずかなずれが生じます。
そのずれが、確率最大のトークンを変えるほど大きくなったとき、モデルの挙動に違いが現れます。
ローカル環境の性能がひどくても、落ち込む必要はありません。他の人の環境も、それぞれ別の形でひどいのです。
重みは同じでも、アテンションバックエンドを変えると馬鹿になる
推論処理における重要な要素の一つが、「アテンションバックエンド」です。
vLLM では Qwen3.6-27B 向けに、フルアテンション用のバックエンドとして FlashAttention 2、Flash Inference、Triton Attention の3種類を選択できます。
この設定だけを切り替え、それ以外のハードウェア、ソフトウェア、重み、KVキャッシュの精度はすべて同一に保ちました。
実験には、約10万トークンの実際の業務シナリオデータを使用しました。複数回のツール呼び出しを含む Agent ワークフローから取得したものです。
thr3e 氏は、このデータが公開ベンチマークや学習データセットに属するものではなく、誰もこのデータに対してベンチマーク最適化や量子化キャリブレーションを行えない点を特に強調しています。
テストでは、32トークンごとに1回、語彙全体の logit をサンプリングし、事後的に FP64 精度で KL ダイバージェンスと Top-1 一致率を計算しました。
実験では「Top-1反転」現象が確認されました。つまり、バックエンドを切り替えると、モデルがベースラインとは異なる貪欲デコードのトークンを選択するのです。
具体的なエラー例では、モデルがツール呼び出しを実行し、Ciscoルーター上のインターフェース GigabitEthernet0/0/1.201 を対象にしていました。
しかし FlashAttention 2 でエラーが発生し、インターフェースが GigabitEthernet0/1/4 に変わってしまいました。その後、モデルは続く2回のツール呼び出しでも誤ったコマンドを実行しました。
数学的な比較可能性を保つため、すべてのバックエンドで同じトークン履歴を強制的に共有しました。反転として記録したのは「本来であれば誤ったトークンを選択する」ケースだけであり、エラーが後続の処理に伝播しないようにしています。
最初の数千トークンでは、3つのバックエンドの出力は完全に一致していました。しかしコンテキストが長くなるにつれて、分岐が現れ始めました。また、その分布は一様ではありませんでした。
thr3e 氏は、同じバックエンドを複数回実行した場合の再現性も比較しました。vLLM の設定項目を1つ切り替えただけで、同じGPU、同じOSとドライバー、同じ重み、同じ prompt を使った場合、各隠れ状態の logit は複数回の実行ですべてビット単位まで一致しました。
これは、観測された分岐が、異なる CUDA カーネル関数が prefill 段階で行列乗算と累積を実行する際に生じる数値の違いに完全に起因することを意味します。
KVキャッシュの量子化で知能が崖から落ちる
次の実験では、重みを BF16 のまま変更せず、アテンションバックエンドを Triton に固定したうえで、KVキャッシュの量子化精度だけを変更し、BF16、INT8、INT4 の3種類をテストしました。
その結果、INT4 KVキャッシュでは長いコンテキストにおける Top-1 反転率が急激に上昇し、最終的にツール呼び出しから復帰できなくなりました。INT8 KVキャッシュでも反転は発生しましたが、モデルは最終的に正しい軌道へ戻ることができました。全行程で安定していたのは BF16 KVキャッシュだけでした。
thr3e 氏は、反転後の生成をベースラインへ戻すのではなく、そのまま自由に実行させ、実際にどのような結果になるかを観察しました。
BF16 はすべての呼び出しを正常に完了しました。INT8 はエラー後に「どうにか苦しみながら復帰」しました。一方、INT4 は完全に逸脱し、ツール呼び出しに失敗したうえ、自力で修正することもできませんでした。
この問題は、VRAMを節約するために KVキャッシュを INT4 まで圧縮しているローカルユーザーに、特に影響しやすいものです。
短いコンテキストでは違いに気づかないかもしれません。しかし、会話や Agent ワークフローが数万トークンまで長くなると、数値のずれが蓄積し、モデルが致命的な判断ミスをするほどになります。
重み量子化を比較：NVIDIA公式FP4が最下位
最後の実験では、KVキャッシュを BF16 に統一し、5種類の重み量子化方式を比較しました。
比較対象は、Qwen公式の BF16 ベースライン、Qwen公式の FP8（W8A8）、TheHouseOfTheDude が公開した INT8（W8A16、キャリブレーションデータセットなしの一括量子化）、NVIDIA公式の NVFP4、そして cyankiwi が公開した AWQ INT4（W4A16、STEM および Agentic データセットでキャリブレーション）の5種類です。
5つの方式では、それぞれ異なる CUDA カーネル関数を使って行列演算を実行します。BF16 は標準の torch 線形層、FP8 は CUTLASS の FP8 ブロック・スケーリングカーネル、INT8 と AWQ はいずれも Marlin カーネルを使用します。
NVFP4 はハイブリッドな経路を採用しています。208個の対象では FlashInfer の FP8 スケーリングカーネルを、193個の MLP 投影では Marlin の NvFp4 カーネルを使用します。
今回のテストで使用した vLLM nightly 版では、GPUパスがネイティブな FP4 演算をサポートしていないと判定されました。そのため NVFP4 で実際に行われたのは、Marlin カーネルによる重みのみの FP4 展開であり、真の FP4 演算ではありません。
結果で最も際立っていたのは、TheHouseOfTheDude の INT8（W8A16）でした。これはキャリブレーションデータセットを一切使用せず、チャネル単位の対称量子化のみを行ったコミュニティ版です。それにもかかわらず、Top-1 一致率は Qwen公式の FP8 や NVIDIA公式の NVFP4 を明らかに上回りました。
分析によると、これは W8A16 が BF16 のアクティベーション精度を維持していることに加え、この量子化方式では Gated DeltaNet の投影層と lm_head 層を除外しているためです。
NVIDIA の NVFP4 は、今回のテストで総合的に最も低い性能となりました。コンテキスト長が約8万8000トークンに達すると、Top-1 反転率は50%近くまで上昇しました。これは、モデルが約半分の位置で異なるトークンを選択することを意味します。
実際のツール呼び出しテストでは、NVFP4 と AWQ W4A16 はいずれもツール呼び出しを正しく終了できず、Cisco のコマンドライン構文も間違えました。正しい show arp ではなく、show run を実行したのです。一方、FP8 と INT8 はどちらも正常に完了しました。
thr3e 氏は、テンソル並列によって生じる奇妙な現象も紹介しています。同じ BF16 の重みを使った場合、TP1 の1枚構成ではツール呼び出しを正しく完了できたのに、TP2 の2枚構成へ切り替えると失敗し、さらに TP4 の4枚構成へ切り替えると再び成功しました。
さらにデバッグを進め、NCCL の通信グラフをキャプチャした結果、これは通常、NCCL のGPU間リダクション処理における数値の違いが原因であることが分かりました。
734個の依存パッケージ、その一つ一つに落とし穴がある
thr3e 氏によると、何気なくダウンロードした vLLM nightly のコンテナイメージには734個のソフトウェアパッケージが含まれており、そのうち252個は Python の uv/pip パッケージでした。
この734個のコードライブラリには、それぞれ異なるバグや、記録されていない挙動上の特徴が存在します。特定のハードウェアとモデル構成がこの「コードの山」の中でたどる経路は、すべて唯一無二です。
だからこそ、Hugging Face のモデルカードに記載された極めて低い KL ダイバージェンスの値を、簡単に信じてはいけません。
参照チェックポイント、完全なランタイム環境、評価テキスト、キャリブレーションデータ、コンテキスト長、サンプリング位置、KL の方向、語彙の切り詰め方法、集約方法を作者が完全に開示していない限り、その数字を解釈することはできません。
現在、thr3e 氏は、異なる重み、異なるモデル（Qwen3.6 と Qwen3.8 のモデル間比較を含む）、異なる KVキャッシュ量子化方式、異なるテンソル並列度、異なる NCCL 設定、異なるアテンションバックエンド、さらに異なるGPU（RTX PRO 6000 と RTX 5090。いずれも SM120 アーキテクチャ）について、全量 logit のキャプチャと分岐の追跡を完了しています。
現在は、テストツールとデータセットを配布可能な形式にまとめ、他のユーザーが自分の環境で実行し、結果を報告できるよう準備を進めています。
あるモデルが「圧倒的、衝撃的、無敵」だと聞いてローカルにダウンロードしたのに、実際にはひどく頭が悪いと感じたなら、原因は推論スタックにあるのかもしれません。アテンションカーネル関数、KVキャッシュの精度、重み量子化方式、マルチGPU通信プロトコルに至るまで、各層がオリジナルのベンチマークとは異なる数学的結果を生み出している可能性があります。
そして、こうした違いは長いコンテキストの中で雪だるま式に蓄積し、ついにはモデルが重要な場面で完全に誤った判断を下すことになります。
参考リンク：
[1] https://forum.level1techs.com/t/why-your-local-llm-feels-dumber-than-it-is/253917/4