ローカルLLMがより低能に感じられる理由:量子化と推論バックエンドの影響
ローカルLLMのパフォーマンスが公式のベンチマークと乖離する理由は、ベースモデルの知能によるものではなく、実装固有のハザードによる累積的な影響であることが多い。アテンション・バックエンドの選択、KVキャッシュの量子化、および重みの量子化手法などの要因が、「トークン・フリップ(token flips)」を引き起こす可能性がある。これは、モデルがリファレンス実装とは異なる次のトークンを選択してしまう現象であり、ツール呼び出しのような複雑なタスクにおいて壊滅的な失敗を招く原因となる。
推論バックエンドの乖離
異なるアテンション・バックエンドは、同じモデルの重みに対して異なるロジットを生成し、プリフィル(prefill)段階で異なるトークン選択を導く可能性がある。RTX PRO 6000 Blackwell GPU上でQwen3.6-27Bを使用した実験では、3つのvLLMアテンション・バックエンド(FlashAttention 2、Flash Inference、Triton Attention)を、100kトークンの実世界のワークストリームを用いて比較した。
主な調査結果は以下の通り:
- Bit-for-bit identity: 同じバックエンドを複数回実行すると同一のロジットが生成される。つまり、乖離はランダムなノイズではなく、カーネル内の特定の行列乗算および加算操作によって引き起こされる。
- Context-dependent divergence: バックエンド間の不一致(トークン・フリップ)はクラスター状に発生し、コンテキスト長に対して線形に増加するのではなく、プロンプトの内容に基づいて変化する。
- Precision trade-offs: 乖離は、異なるCUDAカーネルがGPUファミリーやSM計算能力(compute capabilities)によって数学的実装を異にしているために発生する。
KVキャッシュの量子化の影響
KV(Key-Value)キャッシュを量子化すると、コンテキスト長が増加するにつれてモデルの知能が著しく低下する。これは、特に長いシーケンスにわたって論理を維持するモデルの能力に影響を与える。
Qwen3.6-27Bを用いたテストでは、BF16(Brain Floating Point 16)のKVキャッシュは安定していたが、量子化によって重大な失敗が引き起こされた:
- INT8 KV Cache: 一部のツール呼び出しエラーからは回復できたが、顕著な乖離が見られた。
- INT4 KV Cache: ツール呼び出しを正しく実行することに完全に失敗し、KVキャッシュの量子化が約40kトークンの後にモデルの「IQを急激に低下させる」ことを示した。
重みの量子化と忠実度
すべての量子化手法が等価であるわけではない。重みとアクティベーションの圧縮方法の選択は、複雑な構文の遵守やツール呼び出しの終了(close tool calls)の能力に直接影響を与える。
Qwen3.6-27Bの5つのバリエーションによる比較テスト(bakeoff)では、結果は以下の通りであった:
| 量子化手法 | パフォーマンスの観察結果 |
|---|---|
| BF16 Reference | ベースラインの忠実度。 |
| INT8 (W8A16) | 高い忠実度。ファーストパーティのFP8およびNVIDIAのFP4リリースを上回った。 |
| FP8 (W8A8) | 中程度の忠実度。正しいツール呼び出しを完了できる。 |
| AWQ (W4A16) | 低い忠実度。ツール呼び出しの終了に失敗し、Cisco CLI構文を台無しにした。 |
| NVFP4 | 最も低い忠実度。88kコンテキストで約50%のトークン・フリップに達し、ツール呼び出しに失敗した。 |
決定的な違いとして、INT8 (W8A16) バリエーションは、BF16のアクティベーションを利用し、Gated DeltaNet (GDN) プロジェクションを量子化せずに残したため、優れた忠実度を示した。
量子化以外の実装上のハザード
コミュニティの知見によれば、ローカルモデルの知覚的な「低能化」は、モデルの重みよりも設定ミスに起因することが多い:
- Chat Templates: 誤ったチャット・テンプレートを使用すること(例:モデルが特定の形式を要求している場合にChatMLにフォールバックしてしまうこと)は、パフォーマンスを大幅に低下させる可能性がある。
- Sampling Settings: ベンダーが推奨するtemperatureやtop-pの設定を無視することは、ループや支離滅裂な出力を引き起こす可能性がある。
| Grammar Constraints:
llama.cppのような一部のランナーは、トークン生成における文法制約(grammar constraints)を強制することで、量子化に起因するツール呼び出しの失敗を軽減できる。
"Most of the time when a local model feels dumb its not the quant, its the chat template. a lot of gguf mints just drop the template from the metadata and the runtime silently falls back to chatml."
ローカル推論のベストプラクティスまとめ
ローカルLLMの知能を最大化するためには、ユーザーは以下の設定を優先すべきである:
- KVキャッシュの量子化を避ける: 長いコンテキスト・ウィンドウにおいて論理崩壊を防ぐため、KVキャッシュはBF16に保つこと。
- 高ビット重みの優先: VRAMが許す限り、Q8またはBF16の重みを使用すること。エージェント的タスク(agentic tasks)において、積極的な4-bit量子化(NVFP4やAWQなど)は避けること。
- チャット・テンプレートの検証: ランタイムがモデルのHugging Face cardに指定された正確な正確なテンプレートを使用していることを確認すること。
- サンプリング設定の適合: 出力ループを防ぐための一般的な失敗モードを避けるため、推奨されるtemperatureおよびtop-pの値を使用すること。
Sources
関連
- Dispatch
- Dispatch
- Dispatch
- Dispatch
- Dispatch