量化匯出
在 checkpoint-promotion 發出 PROMOTE 判定後的最後一站：一個通過四階段閘門的 checkpoint 在以其目標執行環境的正確格式匯出並證明匯出後仍能正常工作之前，仍不會被部署。REJECT 判定永遠不會到達此技能——匯出僅從已晉升的 checkpoint 開始。
輸入： 一個已晉升的 checkpoint（或 LoRA 適配器）加上目標部署表面——GPU 級別、服務棧，以及長上下文/程式碼/數學工作負載是否在範圍內。 輸出格式： 一個所選格式的匯出工件，加上一份比較 3-5 個匯出前和匯出後黃金輸出的冒煙測試差異報告。
格式對應表
根據硬體和部署型態而非習慣選擇格式——錯誤的選擇要麼浪費吞吐容量，要麼在特定工作負載上無聲故障（參見工作負載覆蓋）。
- FP8 是 Hopper 級 GPU 及更新型號的預設選項。 它在約一半記憶體下保持接近 bf16 的品質。當目標 GPU 支援且無邊緣設備約束時，它是安全的首選。
- AWQ INT4 針對更早、不支援 FP8 硬體的 GPU。 對於新部署，GPTQ 已被取代——不要在全新匯出中使用它；AWQ 在相同位寬下具有更好的準確性保留和更廣泛的當前工具支援。
- GGUF 搭配 Q4_K_M 量化，從 imatrix 構建，是邊緣/llama.cpp 格式。 用於本地或與 CPU 相鄰的部署，而非 GPU 服務吞吐——它優化的是佔用空間，而非資料中心 GPU 上的 tokens/sec。
- NVFP4 僅用於 Blackwell 規模的部署——且明確不適用於 GB10。 在 SM121 (GB10) 上，NVFP4 運行速度比 FP8 慢約 ~32%，因為除非內核以
sm_121a編譯，否則硬體缺少原生cvt.e2m1x2路徑。在 GB10 目標上選擇 NVFP4 是一種回歸，而非升級——請改選 FP8。 - 合併與僅 LoRA 是與量化格式分開的軸。 合併匯出將適配器摺疊到基礎權重中：工件較大，服務時無需基礎模型依賴。僅 LoRA 保持適配器分離：工件小得多，但服務棧必須同時加載完全相同的基礎模型——不匹配或錯誤版本的基礎模型會無聲改變輸出。當工件可移植性比儲存更重要時，選擇合併；當磁碟佔用空間或多適配器服務更重要時，選擇僅 LoRA。
實例選擇
核心格式選擇權衡，以常見場景的查找表形式閱讀：
| 目標 | 工作負載 | 格式 |
|---|---|---|
| 資料中心 GPU | 通用聊天 | FP8 |
| 資料中心 GPU | 長上下文/程式碼/數學 | FP8 或 W8A8——切勿 INT4 |
| 舊 GPU 世代 | 通用 | AWQ INT4 |
| 邊緣設備 / 筆電 | llama.cpp 服務 | GGUF Q4_K_M + imatrix |
| GB10 | 任何工作負載 | 透過 vLLM 夜間版的 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
工作負載覆蓋
上面的格式對應表是預設值，並非能適用於每種工作負載的規則。長上下文、程式碼和數學工作負載會在 INT4 上故障——量化誤差在長序列和需要精確 token 級推理的場景中會累積，其方式在簡短、通用的提示中不會顯現。對於這三種工作負載類別中的任何一種，即使目標硬體出於成本考慮通常會證明使用 INT4 是合理的，也請堅持使用 FP8 或 W8A8。
- 不要使用 MMLU 或類似的廣泛知識基準來驗證此覆蓋——它們不會對故障模式施加壓力。使用實際任務評估進行衡量——來自
eval-harness-first的黃金樣本和評分員，透過匯出工件運行——因為 INT4 在長上下文、程式碼或數學上的退化表現為特定任務的失敗（遺漏上下文、語法錯誤、算術錯誤），早在它影響知識基準之前就會顯現。 - 如果對這三種工作負載類別之一執行 INT4 匯出後任務評估出現退化，解決方案是切換格式，而非重新調整量化配方——相同位寬的 AWQ 和 GPTQ 變體在這些工作負載上共享相同的複合錯誤故障模式。
冒煙測試
匯出錯誤在檔案層面是無聲的——一個格式錯誤的匯出仍然會產生一個可加載的工件，因此檔案存在性檢查證明不了什麼。對每一次匯出，冒煙測試都是強制性的，對任何「應該能正常工作」的格式也不例外：
- 在其實際目標執行環境中加載匯出的工件——對於 FP8/AWQ 使用 vLLM，對於 GGUF 使用 llama.cpp，而不是在與最終用於生產服務的框架不同的框架中進行快速健全性加載。
- 透過它運行 3-5 個黃金提示——從
eval-harness-first維護的同一份eval/goldens.jsonl中選取，而非一組全新的 ad hoc 提示。 - 將每個輸出與同一提示、相同確定性取樣設定下的匯出前生成進行比較——貪婪解碼（溫度 0）和固定種子，在匯出前和匯出後運行之間持久保存並重複使用，而不僅僅是名義上相同的配置。對於無損匯出，位元組匹配是閘門——任何差異都是錯誤。 對於有損（量化）匯出，位元組匹配預計會失敗；閘門改為任務評分員判定一致性——請參見
references/export-commands.md的冒煙測試腳本骨架。
將其作為閘門而非手動檢查來運行：
python smoke_test.py "$EXPORT_PATH" \
eval/goldens.jsonl pre-export-outputs.jsonl
# 在任何前後不匹配時以非零退出
故障特徵
匯出錯誤實際上看起來的樣子，而非一個乾淨的通過/失敗標誌：
- 模板不匹配表現為亂碼或連貫輸出——匯出中嵌入的對話模板與 checkpoint 被訓練和評估的模板不匹配，因此輪次邊界或特殊標記出現在錯誤位置。
lm_head上應用了錯誤的量化表現為脫離模板或語義上無意義但仍流暢的輸出——即使網路其餘部分量化乾淨，輸出頭也失去了它所需的精度。
切勿發佈跳過此步驟的匯出——checkpoint 的 PROMOTE 判定僅表示未匯出的 checkpoint 是好的；它對匯出管道一無所知。在每次量化方法或運行時版本更新後重新運行，而非僅在首次匯出後。每種格式的可運行命令序列加上冒煙測試腳本骨架：references/export-commands.md。
相關技能
checkpoint-promotion——此技能唯一有效的上游來源。沒有PROMOTE判定的 checkpoint 不會到達匯出。eval-harness-first——擁有此技能冒煙測試從中提取 3-5 個提示的eval/goldens.jsonl，以及「工作負載覆蓋」部分要求用於長上下文/程式碼/數學驗證的任務評估。finetuning-method-selection——其references/model-catalog.md是在從上方格式對應表選擇格式之前檢查硬體類別假設（基礎模型針對哪些 GPU 世代）的地方。
Spark 使用者： 在 GB10 上，透過 llama.cpp 的 GGUF 適合本地服務，透過 vLLM 夜間版構建的 FP8 服務是另一個經過驗證的路徑——NVFP4 是此處應避免的一種格式（請參見上方格式對應表中的例外）。安裝 dgx-spark-ops 插件後，請將與 Spark 相關的服務和散熱問題委託給其技能，而非在此重新推導。