양자화 내보내기 (Quantized Export)
checkpoint-promotion이 PROMOTE 판정을 내린 후의 마지막 단계입니다.
4단계 게이트를 통과한 체크포인트는 대상 런타임에 맞는 올바른 형식으로 내보내기 전까지는 배포되지 않습니다.
REJECT 판정을 받은 경우 이 스킬에 도달하지 않으며, 내보내기는 승격된 체크포인트에서만 시작됩니다.
입력: 승격된 체크포인트(또는 LoRA 어댑터)와 대상 배포 환경(GPU 클래스, 서빙 스택, 장문 맥락/코드/수학 워크로드 적용 여부) 출력 형식: 선택한 형식의 내보내기 아티팩트와 사전/사후 내보내기 시 3~5개의 골든 출력을 비교한 스모크 테스트 차이 보고서
형식 맵
하드웨어와 배포 형태에 따라 형식을 선택하세요. 습관적으로 고르지 마십시오. 잘못된 선택은 처리량 헤드룸을 낭비하거나 특정 워크로드에서 조용히 실패할 수 있습니다(워크로드 재정의 참조).
- 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% 느립니다. 하드웨어에 네이티브
cvt.e2m1x2경로가 없기 때문이며, 커널이sm_121a로 컴파일되지 않은 한 그렇습니다. GB10 대상에서 NVFP4를 선택하는 것은 업그레이드가 아닌 성능 저하입니다. 대신 FP8을 선택하십시오. - 병합 vs LoRA 전용은 양자화 형식과 별개의 축입니다. 병합 내보내기는 어댑터를 기본 가중치에 통합합니다. 아티팩트가 더 크지만 서빙 시 기본 모델 의존성이 없습니다. LoRA 전용은 어댑터를 분리하여 유지합니다. 아티팩트는 훨씬 작지만 서빙 스택이 정확히 동일한 기본 모델을 함께 로드해야 합니다. 일치하지 않거나 잘못된 리비전의 기본 모델은 조용히 출력을 변경합니다. 아티팩트 이식성이 저장 공간보다 중요할 때는 병합을 선택하고, 디스크 공간이나 멀티 어댑터 서빙이 더 중요할 때는 LoRA 전용을 선택하십시오.
실제 선택 예시
일반적인 시나리오에 대한 조회 테이블로 읽는 핵심 형식 선택 트레이드오프:
| 대상 | 워크로드 | 형식 |
|---|---|---|
| 데이터센터 GPU | 일반 채팅 | FP8 |
| 데이터센터 GPU | 장문 맥락/코드/수학 | FP8 또는 W8A8 — INT4 절대 금지 |
| 구형 GPU 세대 | 일반 | AWQ INT4 |
| 엣지 장치/노트북 | llama.cpp 서빙 | GGUF Q4_K_M + imatrix |
| GB10 | 모든 워크로드 | FP8(vLLM nightly) 또는 GGUF(llama.cpp 로컬) — 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에서 문제가 발생합니다. 양자화 오류는 긴 시퀀스와 정밀한 토큰 수준 추론에서 누적되어 짧고 일반적인 프롬프트에서는 나타나지 않습니다. 이러한 세 가지 워크로드 클래스 중 하나라도 해당하는 경우 FP8 또는 W8A8을 유지하십시오. 대상 하드웨어가 비용 측면에서 INT4를 정당화하더라도 마찬가지입니다.
- MMLU 또는 유사한 광범위한 지식 벤치마크로 이 재정의를 검증하지 마십시오. 이런 벤치마크는 실패 모드를 강조하지 않습니다. 실제 작업 평가로 측정하십시오. 내보내기 아티팩트를 통해 실행되는
eval-harness-first의 골든 및 채점기를 사용하십시오. INT4가 장문 맥락, 코드, 수학에서 저하되는 현상은 작업별 실패(컨텍스트 누락, 구문 오류, 산술 오류)로 나타나며, 지식 벤치마크가 변하기 훨씬 전에 발생합니다. - 이러한 세 가지 워크로드 클래스 중 하나에서 INT4 내보내기 후 작업 평가가 저하되는 경우, 해결 방법은 형식을 전환하는 것이지 양자화 레시피를 다시 조정하는 것이 아닙니다. 동일한 비트 폭의 AWQ 및 GPTQ 변형은 이러한 워크로드에서 동일한 누적 오류 실패 모드를 공유합니다.
스모크 테스트
내보내기 버그는 파일 수준에서 조용합니다. 잘못된 내보내기도 로드 가능한 아티팩트를 생성하므로 파일 존재 확인은 아무것도 증명하지 못합니다. 모든 내보내기에 대해 스모크 테스트는 필수이며, "당연히 작동해야 하는" 형식에 대한 예외도 없습니다.
- 실제 대상 런타임에서 내보내기 아티팩트를 로드합니다. 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
# 사전/사후 불일치 시 0이 아닌 종료 코드
실패 시그니처
내보내기 버그가 실제로 어떻게 보이는지, 단순한 통과/실패 플래그가 아닙니다:
- 템플릿 불일치는 왜곡되거나 이어지는 출력으로 나타납니다. 내보내기에 포함된 채팅 템플릿이 체크포인트가 훈련 및 평가된 템플릿과 일치하지 않아 턴 경계나 특수 토큰이 잘못된 위치에 배치됩니다.
lm_head에 잘못된 양자화 적용은 유창해 보이지만 템플릿에서 벗어나거나 의미적으로 무의미한 출력으로 나타납니다. 네트워크의 나머지 부분이 깨끗하게 양자화되었더라도 출력 헤드가 필요한 정밀도를 잃었습니다.
이 단계를 건너뛴 내보내기를 절대 배포하지 마십시오. 체크포인트의 PROMOTE 판정은 내보내기 전 체크포인트가 좋다는 의미일 뿐, 내보내기 파이프라인에 대해서는 아무것도 말하지 않습니다. 첫 번째 내보내기뿐만 아니라 모든 양자화 방법 또는 런타임 버전 업데이트 후에 다시 실행하십시오. 모든 형식에 대한 실행 가능한 명령 시퀀스와 스모크 테스트 스크립트 골격은 references/export-commands.md를 참조하십시오.
관련 스킬
checkpoint-promotion— 이 스킬의 유일한 유효한 업스트림 소스입니다.PROMOTE판정이 없는 체크포인트는 내보내기에 도달하지 않습니다.eval-harness-first— 이 스킬의 스모크 테스트가 3~5개의 프롬프트를 가져오는eval/goldens.jsonl을 소유하며, 워크로드 재정의 섹션에서 장문 맥락/코드/수학 검증에 필요한 작업 평가를 제공합니다.finetuning-method-selection—references/model-catalog.md에는 형식 맵에서 형식을 선택하기 전에 하드웨어 클래스 가정(기본 모델이 대상으로 하는 GPU 세대)을 확인할 수 있는 장소입니다.
Spark 사용자 참고: GB10에서 GGUF via llama.cpp는 로컬 서빙에 잘 작동하며, vLLM nightly 빌드를 통한 FP8 서빙은 또 다른 검증된 경로입니다. NVFP4는 GB10에서 피해야 할 유일한 형식입니다(위 형식 맵 예외 참조). dgx-spark-ops 플러그인이 설치되면 Spark 특정 서빙 및 열 관련 질문은 이곳에서 다시 유도하지 않고 해당 스킬에 위임하십시오.