Quantized Export (量子化エクスポート)
checkpoint-promotion の後、PROMOTE 判定が渡される最終地点です。4段階のゲートを通過したチェックポイントでも、ターゲットランタイムに適した形式でエクスポートされ、エクスポート後も動作することを確認するまではデプロイされません。REJECT 判定はこのスキルに到達しません。エクスポートはプロモートされたチェックポイントからのみ開始されます。
入力: プロモートされたチェックポイント（またはLoRAアダプタ）と、ターゲットデプロイ面（GPUクラス、サービングスタック、長文脈/コード/数学ワークロードが対象かどうか）。 出力形式: 選択された形式のエクスポート成果物と、エクスポート前後の3～5個のゴールデン出力を比較するスモークテスト差分レポート。
形式マップ (Format Map)
形式は、習慣ではなくハードウェアとデプロイ形状に基づいて選択します。誤った選択は、スループットの余力を無駄にするか、特定のワークロードで静かに壊れます（「ワークロードオーバーライド」を参照）。
- FP8 は Hopper クラス以上のGPUのデフォルトです。 ほぼbf16の品質をメモリ約半分で維持し、ターゲットGPUがサポートしておりエッジデバイスの制約がない場合の安全な第一選択肢です。
- AWQ INT4 は FP8 ハードウェアサポートより前の古いGPUを対象とします。新しいデプロイでは GPTQ は置き換えられています。 新しいエクスポートではGPTQに頼らないでください。AWQは同じビット幅で精度保持が優れており、現在のツールサポートも広いです。
- imatrix から構築された GGUF Q4_K_M 量子化は、エッジ/llama.cpp形式です。 ローカルまたはCPUに近いデプロイに使用し、GPUサービングのスループット向けではありません。フットプリントを最適化し、データセンタGPUのトークン/秒を重視しません。
- NVFP4 は Blackwell スケールのデプロイ専用であり、GB10 では明示的に使用しないでください。 GB10 (SM121) での NVFP4 は FP8 より約32%遅くなります。これは、ハードウェアがカーネルを
sm_121aでコンパイルしない限り、ネイティブのcvt.e2m1x2パスを持たないためです。GB10 ターゲットで NVFP4 を選択することは後退であり、アップグレードではありません。代わりに FP8 を選択してください。 - マージ版 vs LoRA専用版 は量子化形式とは別の軸です。 マージエクスポートはアダプタをベースウェイトに統合します。成果物は大きくなりますが、サービング時にベースモデル依存がありません。LoRA専用版はアダプタを分離したままにします。成果物ははるかに小さいですが、サービングスタックはまったく同じベースモデルを一緒にロードする必要があります。一致しないリビジョンのベースは静かに出力を変更します。成果物のポータビリティがストレージより重要な場合はマージ版を選択し、ディスクフットプリントやマルチアダプタサービングが重要な場合はLoRA専用版を選択します。
実例選択
形式選択の核心的なトレードオフを、一般的なシナリオのルックアップテーブルとして示します。
| ターゲット | ワークロード | 形式 |
|---|---|---|
| データセンタGPU | 汎用チャット | FP8 |
| データセンタGPU | 長文脈/コード/数学 | FP8 または W8A8 — INT4は不可 |
| 古いGPU世代 | 汎用 | AWQ INT4 |
| エッジデバイス/ラップトップ | llama.cpp サービング | GGUF Q4_K_M + imatrix |
| GB10 | 任意のワークロード | vLLM nightly 経由の FP8、または llama.cpp 経由の GGUF ローカル — NVFP4 はスキップ |
# 素早い判断スニペット — 完全なマップは上の表を参照
hopper_or_newer: fp8
older_gpu: awq-int4
edge_llama_cpp: gguf-q4_k_m+imatrix
gb10_any_workload: fp8-vllm-nightly # GB10 では nvfp4 は不可
ワークロードオーバーライド (Workload Overrides)
上記の形式マップはデフォルトであり、すべてのワークロードで有効なルールではありません。長文脈、コード、数学ワークロードは INT4 で動作しません。 量子化誤差は長いシーケンスや正確なトークンレベルの推論で複合的に悪化し、短く一般的なプロンプトでは現れません。これら3つのワークロードクラスについては、FP8 または W8A8 を維持してください。 たとえターゲットハードウェアがコストの理由で INT4 を正当化する場合でも同様です。
- このオーバーライドを MMLU や類似の広範知識ベンチマークで検証しないでください。これらのベンチマークは障害モードをストレス処理しません。実際のタスク評価で測定してください。
eval-harness-firstのゴールデンとグレーダーを、エクスポートされた成果物で実行します。INT4 の長文脈、コード、数学での劣化は、知識ベンチマークに影響を与えるずっと前に、タスク固有の障害（文脈の消失、構文の破損、算術エラー）として現れます。 - これら3つのワークロードクラスのいずれかで INT4 エクスポート後にタスク評価が低下した場合、修正は形式の切り替えであり、量子化レシピの再調整ではありません。同じビット幅の AWQ と GPTQ のバリアントは、これらのワークロードで同じ複合誤差の障害モードを共有します。
スモークテスト (Smoke Test)
エクスポートのバグはファイルレベルでは静かです。不正な形式のエクスポートでもロード可能な成果物が生成されるため、ファイルの存在チェックは無意味です。スモークテストはすべてのエクスポートで必須であり、「動作するはず」の形式でも例外はありません。
- エクスポートされた成果物を実際のターゲットランタイムでロードします。 FP8/AWQ の場合は vLLM、GGUF の場合は llama.cpp を使用し、本番で使用するものとは異なるフレームワークでの簡易検証は行わないでください。
- 3～5個のゴールデンプロンプトを実行します。 これらは
eval-harness-firstが管理する同じeval/goldens.jsonlから取得し、新たにアドホックなセットを作成しないでください。 - 各出力をエクスポート前の生成結果と比較します。 同じプロンプト、同じ決定論的サンプリング設定（温度0のグリーディデコーディング、固定シード）を使用し、エクスポート前後の実行間で永続化および再利用します。単なる名目上同じ設定ではありません。ロスレスエクスポートの場合、バイト一致がゲートです。差分はすべてバグです。 ロッシー（量子化）エクスポートの場合、バイト一致は失敗することが予想されます。ゲートは代わりにタスクグレーダー判定の一致です。詳細は
references/export-commands.mdの「スモークテストスクリプトスケルトン」を参照してください。
これを手動チェックではなくゲートとして実行します。
python smoke_test.py "$EXPORT_PATH" \
eval/goldens.jsonl pre-export-outputs.jsonl
# エクスポート前後の不一致で非ゼロ終了
障害シグネチャ (Failure Signatures)
エクスポートバグが実際にどのように見えるか。単なる合格/不合格のフラグではありません。
- テンプレートの不一致 は、文字化けした出力や継ぎ足しのような出力として現れます。エクスポートに組み込まれたチャットテンプレートが、チェックポイントがトレーニングおよび評価されたものと一致しないため、ターン境界や特殊トークンが間違った場所に配置されます。
lm_headに誤った量子化が適用された場合 は、テンプレートから外れた、または意味的に無意味でありながら流暢に見える出力として現れます。出力ヘッドが必要な精度を失っている一方で、ネットワークの残りの部分はきれいに量子化されています。
このステップをスキップしたエクスポートを絶対に出荷しないでください。チェックポイントの PROMOTE 判定は、エクスポートされていないチェックポイントが良好であることを示します。エクスポートパイプラインについては何も示しません。最初のエクスポート後だけでなく、量子化方法やランタイムのバージョンが上がった場合にも再実行してください。すべての形式の実行可能なコマンドシーケンスとスモークテストスクリプトのスケルトンについては、references/export-commands.md を参照してください。
関連スキル (Related Skills)
checkpoint-promotion— このスキルの唯一の有効な上流ソース。PROMOTE判定のないチェックポイントはエクスポートに到達しません。eval-harness-first— このスキルのスモークテストが3～5個のプロンプトを取得するeval/goldens.jsonlと、ワークロードオーバーライドセクションが長文脈/コード/数学検証に必要とするタスク評価を所有します。finetuning-method-selection— そのreferences/model-catalog.mdは、上記の形式マップから形式を選択する前に、ハードウェアクラスの前提（ベースモデルがターゲットとするGPU世代）をチェックする場所です。
Spark ユーザーへ: GB10 では、llama.cpp 経由の GGUF はローカルサービングに適しており、vLLM nightly ビルド経由の FP8 サービングも実績のあるパスです。NVFP4 はそこで避けるべき唯一の形式です（上記の形式マップの例外を参照）。dgx-spark-ops プラグインがインストールされたら、Spark固有のサービングや熱に関する質問は、ここで再導出するのではなく、そのスキルに委ねてください。