
2026/08/23 3:14
なぜあなたのローカル LLM は実際より知的に見えなくなるのか
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
本稿は、標準的なベンチマークが大型言語モデル(LLM)の性能を正確に測定できないことへの警告を示しています。推論中のロジット計算における実装固有のリスク、特に nightly バルドを利用するユーザー構成などが原因で重大な出力エラーが生じる可能性があるためです。ロジットの微小なシフトが結果の乖離を引き起こし、単純な精度指標を誤導的なものに変えてしまいます。さらに、数百のパッケージを含む NVIDIA nightly イメージなど、複雑な構成は推論パスに影響を与える隠れたバグをもたらします。KL ダイバージェンスなどの指標に基づき低誤差率を主張する一部の量化手法については、ロジット計算に用いられる CUDA カーネルやテスト手法に関する完全な透明性が欠ける限り、その主張は欺瞞的であり得ます。Qwen3.6-27B モデルに対して FlashAttention 2、Flash Inference、Triton Attention の 3 つの注意力バックエンドを実践的に比較した実験では、初期トークンの一致は見られましたが、量化テストの基準として Triton を用いた際には後に不一致が生じました。KV カッシュを quantize(int4/int8)としつつ重みを BF16 で維持する構成ではツール呼び出しエラーが発生し、int4 では乖離から回復できませんでした。5 つの構成に対する評価の結果、INT8 バージョンが他のどの構成よりも優れており、約 5% のトークンフリップしか起こさずに 88,000 トークンのコンテキストを処理し、コマンドを正しく実行することができました。一方、NVIDIA の NVFP4 および AWQ W4A16 バージョンは高いトークンフリップ率(NVFP4 では約 50%)を示し、特定の命令実行に失敗しました(例:Cisco コマンド)。したがって、正確なコマンド実行を必要とする生産環境負荷においては、曖昧な精度主張やドキュメント化されていないリスクに曝露されやすいデフォルト構成に頼るのではなく、実証された安定性を有する特定のハードウェア構成に依存することが不可欠です。
本文
LLM の「参照実装」とローカル環境の乖離:分散と精度劣化の実験報告
はじめに
私たちは日常において、様々なプラットフォーム(フォーラム、Reddit、Discord など)で他者の成果物を入手・試行します。しかし、**「動作するはずのモデルが自分の環境では動かない」**という経験は誰もが一度は抱えるものです。
本稿では、推論エンジン特有の実装依存性を可視化する一連の実験結果を報告します。「簡略化された数学」や「過度に長い論文」への言及を避け、実用的かつ読解しやすい形式で解説します。
核心メッセージ 「あなたのローカル環境での失敗は特別ではありません。なぜなら、ハードウェア、ソフトウェアスタック、および推論エンジンの設定が、参照実装(ベンチマーク声明を出す研究所)と根本的に異なるからなのです。」
1. なぜ「私の構成」が suck するのか?
LLM の実行環境には、**「状況次第で微妙な差異」や「特定のケースで劇的な差異」**が存在します。特にホームラボユーザーは、複数世代の GPU を混在運用することが多く、異なる命令セット(ISA)と数学演算手法を使用しているため、同じ重みでも出力が異なります。
評価アプローチ
単に「温度 0 で 3 つのテストプロンプト」を走らせるのは不十分です。以下の点が必要です:
- 多様なベンチマークの実行
(終端環境)terminal_bench
,h-le
,SWEthis
,HELLAthat
などMMLU
- 実際のワークロードの反映
- シンセティックなテスト(干し草の中の針を探す)ではなく、長文脈ツール呼び出しやドメイン固有の知識評価が必要です。
数学的な基準:Logits と KLD
モデルは各トークンに対してスコア(Logits)を出力します。これを確率に変換し、デトキナイザーを通じてテキストへ変換します。しかし、Logits の値がわずかでも変動すると、出力文脈が根本的に変化します(例:
THE→NE→XT... ではなく THE→NE→W→DAY...)。
KL ダイバージェンス (KLD) の注意点
- 定義: 出力された確率分布と基準分布との乖離度を測る指標。
- 限界: KLD が低い=「賢い」という意味ではありません。方向性も重要です。
- 警告: HF モデルカードに記載されている「不可能に低すぎる KLD」の数値には警戒してください。計算環境(チェックポイント、ランタイム、評価データ、コンテキスト長など)が明記されていなれば、その数値は無意味です。
2. エクスペリメント:推論エンジン上のソフトウェアスタック
巨大なソフトウェアスタック(vLLM など)は、ハードウェアフットプリントやテンソル形状に基づいて動的に構成されます。734 パッケージものコードが処理し、それぞれにバグや未文書化の癖が存在します。
テスト環境の設定 (Test 1)
- GPU: RTX PRO 6000 Blackwell
- モデル: Qwen3.6-27B (公式 BF16 チェックポイント)
- KV キャッシュ: BF16(量子化なし)
- ソフトウェア: Nightly vLLM (イージャーモード有効、CUDA グラフ/MTP 無効)
- アテンションバックエンドの比較
FlashAttention 2Flash Inference
(基準値)Triton Attention
重要: 実験対象は「プロンプト後」の部分のみ。プリフィル中の不一致は除外し、ツール呼び出しや実際のワークロードでの挙動を検証しました。
テスト 1 の結果:Top-1 フリップ
各アテンションバックエンドで Top-1 トークンの一致率を比較しました。
- 初期フェーズ: 数千トークンまで、どのバックエンドでも一致していました。
- 不一致の開始: プロンプトの後半からバックエンド間の差異が現れました。
- 原因: 行列乗算と加算演算における浮動小数点演算の累積誤差です(
の違い)。trt/fa2/fi
結論 この不一致は、モデルが「崩壊する」普遍的な長さを示すのではなく、実装ごとの数学的なノイズです。
3. 実験:KV キャッシュの量子化と分散 (Divergence)
テスト 2: KV キャッシュの量子化
BF16 重み・アクティベーションを維持し、KV キャッシュのみを量子化した場合の影響を確認しました。
- int8 KV キャッシュ: ツール呼び出しでエラーが発生した後、最終的に回復するケースがありました。
- int4 KV キャッシュ: 失敗。ツール呼び出しが正常に完了できませんでした。
テスト 3: 多様な量子化方式の比較
KV キャッシュを BF16 に戻し、重みとアクティベーションの量子化方式を変えて比較しました。
比較対象の構成
| 量子化方式 | リンク | 特徴 |
|---|---|---|
| BF16 (参照) | Qwen/Qwen3.6-27B | 重み・アクティベーション BF16、標準的な CUDA タイル |
| 公式 FP8 | Qwen/Qwen3.6-27B-FP8 | E4M3 重み、動的量子化、 |
| INT8 (W8A16) | TheHouseOfTheDude/... | 静的対称 INT8、 |
| NVIDIA NVFP4 | nvidia/Qwen3.6-27B-NVFP4 | 混合チェックポイント(FP8+W4A16)、 |
| AWQ (W4A16) | cyankiwi/... | 静的非対称 INT4、MSE オブザーバ、 |
実装上の差異 (CUDA カーネルの違い)
各量子化方式は、内部で異なる CUDA カーネル(GEMM/MMA)を呼び出します。
- Qwen3.6-27B:
(標準)torch.nn.functional.linear - FP8:
(SM120 向け、E8M0 スケールフォーマット注意)CutlassFp8BlockScaledMMKernel - INT8:
(圧縮テンソル使用)MarlinLinearKernel - NVFP4:
(FP4 アリートは非ネイティブのため、圧縮のみ)MarlinNvFp4LinearKernel - AWQ:
MarlinLinearKernel
テスト 3 の結果予測
- TheDude (W8A16): 他のすべてを圧倒しました。
- 公式 FP8 & NVFP4: 初期成績は良好でしたが、コンテキスト長が増加(88k トークン)につれてTop-1 フリップが大幅に増加しました(約 50%)。
- 失敗事例:
- NVFP4 & AWQ: ツール呼び出しのクローザが正しく行われず、Cisco コマンドライン構文を誤認識(
を実行しようとしていたがshow run
が期待されていたケースなど)。show arp - INT8 & FP8: 適切にツール呼び出しを完了しました。
- NVFP4 & AWQ: ツール呼び出しのクローザが正しく行われず、Cisco コマンドライン構文を誤認識(
まとめ:なぜ「同じモデル」でも結果が変わるのか?
今回の実験から、**「実装固有の危険性」**が推論精度に与える影響が明確になりました。
-
アテンションバックエンドの違い
- FlashAttention2, Flash Inference, Triton Attention など、演算順序や浮動小数点精度の扱い方によって、数千トークン以降で出力が分岐します。
-
量子化方式と CUDA カーネル
- 重みや KV キャッシュを圧縮すると、
,Marlin
,Cutlass
などの異なるカーネルが使われます。これらは理論的には同等でも、実装上の四捨五入やキャッシュ戦略の違いが、長文脈での「崩壊」を招きます。FlashInfer
- 重みや KV キャッシュを圧縮すると、
-
参照実装との乖離
- ベンチマーク結果が出ている環境(参照実装)とは、ハードウェアやソフトウェアスタックが異なる場合、単純に「ダウンロードして動かす」だけでは再現できません。特定の量子化方式やカーネル設定がそのユーザーの環境で機能するかどうかが鍵となります。
今後の展開
本シリーズではさらに多くの実験結果を報告していく予定です。詳細な設定や特定の実装についての質問は、DM または Discord までご連絡ください。