科学と神々株式会社アドベントカレンダー 2025
LLM量子化 Day 18: Lossy変換の警告
「劣化」という現実
Day 17でフォーマット変換の仕組みを学びました。今日は、変換に伴う品質劣化について、より深く掘り下げます。
重要な事実を最初に述べます：すべての量子化形式間変換は品質劣化を伴います。例外はありません。
なぜ品質が劣化するのか
量子化とは、情報を「捨てる」プロセスです。FP16の32,768段階から、INT4の16段階に減らすとき、情報の大部分が失われます。
変換時の誤差蓄積
元モデル（FP16）
│ 値: 0.4728
▼
GGUF Q4_K_M
│ 値: 0.50（誤差 ε1 = +0.0272）
▼ 逆量子化
近似FP16
│ 値: 0.50（ε1は回復不可能）
▼
AWQ 4bit
│ 値: 0.48（誤差 ε2 = -0.02）
▼
最終値: 0.48
累積誤差: |0.48 - 0.4728| = 0.0072
直接量子化なら: |0.47 - 0.4728| = 0.0028
変換を経由すると、誤差が蓄積します。直接量子化より悪い結果になるのは、この累積が原因です。
誤差の性質を理解する
量子化誤差には、いくつかの種類があります：
1. 丸め誤差
最も基本的な誤差。値を離散的なグリッドに丸めることで生じます。
連続値: 0.123, 0.127, 0.131
↓ 4ビット量子化
離散値: 0.125, 0.125, 0.125（すべて同じ値に！）
2. クリッピング誤差
値が量子化範囲を超えた場合に生じます。
範囲: [-1.0, 1.0]
値: 1.5
↓ クリッピング
量子化値: 1.0（0.5の誤差）
3. グループ間の不整合
グループ量子化では、グループごとに異なるスケールを使用します。変換時に、このグループ境界が一致しないと、追加の誤差が生じます。
GGUF: グループサイズ32
AWQ: グループサイズ128
変換時に境界が不一致
→ スケールの再計算が必要
→ 追加の量子化誤差
品質劣化の定量的な影響
典型的なケースでの品質劣化を見てみましょう：
Perplexity（困惑度）での比較
Llama 2 7Bの例:
直接量子化:
├── FP16 → GGUF Q4_K_M: Perplexity 5.68（+0.10）
├── FP16 → AWQ 4bit: Perplexity 5.63（+0.05）
└── FP16 → GPTQ 4bit: Perplexity 5.71（+0.13）
変換経由:
├── GGUF → AWQ: Perplexity 5.82（+0.24）
├── AWQ → GGUF: Perplexity 5.89（+0.31）
└── GPTQ → AWQ: Perplexity 5.75（+0.17）
変換を経由すると、Perplexityが0.1〜0.3ポイント悪化します。これは、モデルの出力品質に影響を与える程度の劣化です。
品質維持率での表現
直接量子化（FP16基準）:
├── GGUF Q4_K_M: 約97%の品質維持
├── AWQ 4bit: 約98%の品質維持
└── GPTQ 4bit: 約96%の品質維持
変換経由:
├── GGUF → AWQ: 約94%の品質維持
├── AWQ → GGUF: 約93%の品質維持
└── 複数回変換: 約90%以下の品質維持
警告システムの設計
llm-quantizeは、すべての変換に対して警告を出力します：
$ llm-quantize convert ./model-Q4_K_M.gguf awq -o ./output
⚠️ Warning: Converting from gguf to awq may result in quality degradation.
Consider re-quantizing from the original model for best results.
Converting: model-Q4_K_M.gguf → AWQ
[████████████████████████████████] 100%
Output: ./output/model-Q4_K_M-awq
Size: 4.2 GB
Status: ⚠️ Lossy conversion completed
この警告は、ユーザーが意識的な判断を下せるようにするためのものです。
変換パスごとの影響度
すべての変換が同じ程度の劣化を引き起こすわけではありません：
| 変換パス | 影響度 | 理由 |
|---|---|---|
| GGUF → AWQ | 大 | k-quant最適化の損失、再キャリブレーション |
| GGUF → GPTQ | 大 | ヘシアン情報なし、再キャリブレーション |
| AWQ → GGUF | 中 | k-quant最適化の恩恵なし |
| AWQ → GPTQ | 小 | 類似アルゴリズム、GPU向け同士 |
| GPTQ → AWQ | 小 | 類似アルゴリズム、GPU向け同士 |
| GPTQ → GGUF | 中 | k-quant最適化の恩恵なし |
GPU形式同士（AWQ↔GPTQ） の変換は、影響が比較的小さいです。両者は似たアプローチを取っているためです。
GGUF と GPU形式間 の変換は、影響が大きいです。k-quantの混合精度最適化が、他形式では活かせないためです。
品質劣化を最小化する戦略
戦略1: 元モデルから直接量子化
# 最も品質が高い方法
llm-quantize quantize meta-llama/Llama-2-7b-hf awq -q 4bit
元のFP16/BF16モデルが利用可能なら、必ずこの方法を選んでください。
戦略2: 複数形式を並行生成
# 複数の形式が必要な場合
llm-quantize quantize model gguf -q Q4_K_M -o ./gguf
llm-quantize quantize model awq -q 4bit -o ./awq
llm-quantize quantize model gptq -q 4bit -o ./gptq
変換を経由せず、それぞれ直接生成することで、各形式で最高品質を維持できます。
戦略3: 変換が必要な場合の最適パス
AWQが欲しいが、GPTQしかない場合:
├── 元モデルが入手可能 → 直接AWQ量子化
└── 元モデルが入手不可 → GPTQ → AWQ変換（影響小）
GGUFが欲しいが、AWQしかない場合:
├── 元モデルが入手可能 → 直接GGUF量子化
└── 元モデルが入手不可 → AWQ → GGUF変換（影響中）
戦略4: 用途に応じた許容度の判断
用途別の許容度:
├── 本番サービス: 品質劣化は許容しない → 直接量子化のみ
├── 開発・テスト: 多少の劣化は許容 → 変換も選択肢
├── 実験・比較: 劣化を前提に評価 → 変換を積極活用
└── デモ・プロトタイプ: 速度優先 → 変換で十分
変換後の検証
変換後は、必ず品質を確認してください：
簡易検証
# 推論が動作することを確認
llama-cli -m ./model.gguf -p "Hello, world!" -n 50
品質検証
# Perplexityの計算（概念的なコード）
def evaluate_perplexity(model_path, test_data):
# モデルを読み込み
# テストデータで推論
# 困惑度を計算
return perplexity
original_ppl = evaluate_perplexity("./original-awq", test_data)
converted_ppl = evaluate_perplexity("./converted-gguf", test_data)
degradation = (converted_ppl - original_ppl) / original_ppl * 100
print(f"品質劣化: {degradation:.1f}%")
ベストプラクティスのまとめ
判断フローチャート:
1. 元モデルは入手可能か？
├── Yes → 直接量子化（最高品質）
└── No → 2へ
2. 品質劣化は許容できるか？
├── Yes → 変換を実行
│ ├── GPU形式同士 → 影響小
│ └── GGUF↔GPU形式 → 影響大
└── No → 元モデルの入手を検討
3. 変換後の検証を実施
├── 推論が動作するか
├── 品質は許容範囲か
└── 問題があれば別の方法を検討
次回予告
Day 19からは「実践編」として、チェックポイント機能、CLI設計、進捗表示、エラーハンドリング、テスト戦略など、実際の開発で重要なトピックを解説していきます。
「できるからやる」ではなく、「やるべきかどうか」を考える——これがエンジニアリングの本質です。変換機能は便利ですが、その限界を理解した上で使うことが大切です。