26O13b
업로드하신 Stage7 파일 16개를 확인했습니다. Stage3a 최신 변경사항을 반영할 필요가 있고, 기존 Stage7 자체에도 실행을 방해할 수 있는 문제가 있습니다.
특히 다음 사항이 중요합니다.
stage7d는--external-server를 전달하지만, 기존stage7_llm_qualification.py는 이 옵션을 받지 않습니다. Kubernetes 재검증이 실행되지 않는 문제입니다.- Stage7은
vllm_metrics_compat.py를 호출하지만, 업로드된 파일에는 해당 스크립트가 없습니다. - 모델별 Saturation은 측정하지만 Stage3a3에서 확인한 Short/Long Prefill 간섭과 AB/BA 순서 효과는 검증하지 않습니다.
- Stage7의 표준 vLLM 버전이 아직
0.30.0으로 설정되어 있습니다. - 운영 설정 생성 시 Prefix Cache의 명시적 ON/OFF와 실제 검증 근거를 더 엄격하게 연결할 필요가 있습니다.
따라서 기존 Stage7a~7d 구조와 모델 목록은 유지하면서, 공통 측정 엔진, Kubernetes 재검증, 메트릭 호환성, 운영 승인 조건을 중심으로 보완하겠습니다.
Stage7 v2 수정 패키지 완성
Stage7 v2 전체 다운로드 (.tar.gz)
기존 16개 파일 + 메트릭 호환성 스크립트 + 변경 안내서, 총 18개 파일
반영한 변경사항
| 구분 | 변경 내용 |
|---|---|
| Stage7a 야간 배치 | 기존 모델별 Saturation·TP 최적화 유지 |
| Stage7b 온라인 | Short/Long 간섭 및 AB/BA 4회 교차 측정 추가 |
| Stage7c 문서 | 기존 PaddleOCR/Docling 어댑터 구조 유지 |
| Stage7d Kubernetes | --external-server 지원 및 서버 종료 방지 |
| 메트릭 | vLLM 0.31.0 Prefix Cache counter 호환 파서 추가 |
| 운영 설정 생성 | 온라인 TTFT SLO, 간섭 검증 및 Prefix 설정 확인 강화 |
| 모델 Manifest | 표준 vLLM 버전 0.31.0으로 변경 |
중요한 검증 조건
온라인 모델은 AB/BA 유효 4회 이상을 확인하도록 보완했습니다. 다만 현재 간섭 분석은 Short/Long TTFT 변화와 메트릭을 수집하는 수준입니다. Scheduler 정책과 KV 메모리 압박의 인과관계를 확정하는 통제 실험은 별도로 필요합니다.
또한 운영 승인에 필요한 Stage7 Evidence는 실제 측정 결과를 바탕으로 작성해야 합니다. 벤치마크 결과가 있다는 이유만으로 자동 운영 승인하지 않도록 했습니다.
검증 결과: Python 구문 검사, Bash 구문 검사, YAML 파싱을 통과했습니다. 실제 B300, vLLM 0.31.0 및 Kubernetes 환경에서의 통합 실행은 아직 수행하지 않았습니다.
기존 validation_env.sh는 업로드 파일에 없으므로 패키지에 포함하지 않았습니다.
==
Stage7 v2 패키지의 실제 스크립트를 기준으로 정리하겠습니다.
현재 환경인 B300 8GPU 단일 노드, vLLM 0.31.0, Kubernetes GPU 클러스터, AIStor + Local NVMe를 기준으로 하면, 가장 효율적인 순서는 다음과 같습니다.
Stage7a/7b Bare-metal 모델별 검증 → Stage7c 문서 모델 검증 → Stage7 결과 분석 → Stage7d Kubernetes 재검증 → Production Evidence 작성 → 운영 설정 생성
중요한 점은 Stage7이 모델을 한꺼번에 배포하는 스크립트가 아니라, 모델별 GPU 구성과 성능을 측정하고 운영 가능 여부를 판단하는 검증 도구라는 것입니다.
1. 어떤 스크립트를 실행해야 하나?
스크립트 역할 대상
stage7a_night_batch_qualification.sh TP 후보, 동시성, 처리량, Saturation 측정 GLM-5.3, Qwen3.6, gpt-oss-20b
stage7b_online_slo_qualification.sh TTFT/ITL SLO, 동시성, Short/Long 간섭 DeepSeek-V4.1-Flash, GLM-5.3-Flash
stage7c_document_pipeline.py OCR·문서 처리 성공률, 처리 속도, 품질 지표 수집 PaddleOCR-VL, Docling
stage7d_k8s_model_revalidation.sh Kubernetes 환경에서 동일한 LLM 워크로드 재검증 위 5개 LLM
stage7_summary_report.py 모델별 검증 결과 취합 전체
stage7_generate_production_config.py 검증 결과를 운영 프로파일과 Helm values로 변환 LLM
stage7_generate_serving_platform_configs.py InferencePool, HTTPRoute, LiteLLM 용량 설정 생성 LLM
나머지 stage7_llm_qualification.py는 Stage7a/b/d가 공통으로 호출하는 실행 엔진이고, stage7_model_qualification.yaml은 모델별 테스트 정의 파일입니다.
2. 실행 전 준비: 환경 설정
2-1. Stage7 패키지 설치
mkdir -p ~/b300-validation
cd ~/b300-validation
tar xzf stage7_v2_stage3a_aligned.tar.gz
cd stage7_v2_stage3a_aligned
chmod +x stage7*.sh
이 패키지에는 validation_env.sh가 포함되어 있지 않으므로, 기존 Stage1~6에서 사용한 환경 설정 파일을 재사용해야 합니다.
2-2. 환경변수 설정
다음은 validation_env.sh에 추가할 수 있는 예시입니다. 실제 모델 경로는 다운로드한 체크포인트 위치에 맞게 수정하세요.
공통 실행 환경
export PYTHON_BIN=/opt/venvs/vllm/bin/python
export VLLM_BIN=/opt/venvs/vllm/bin/vllm
export STAGE7_ROOT=/var/log/b300_validation/stage7
export STAGE7_MANIFEST=HOME/b300-validation/stage7_v2_stage3a_aligned/stage7_production_profile_policy.yaml
export STAGE7_HOST=127.0.0.1
export STAGE7_PORT=8100
export STAGE7_SERVER_READY_TIMEOUT_SEC=3600
Local NVMe 모델 캐시 경로 예시
export MODEL_GLM53=/mnt/local-nvme-cache/models/GLM-5.3
export MODEL_QWEN36_35B_A3B=/mnt/local-nvme-cache/models/Qwen3.6-35B-A3B
export MODEL_GPTOSS_20B=/mnt/local-nvme-cache/models/gpt-oss-20b
export MODEL_DEEPSEEK_V41_FLASH=/mnt/local-nvme-cache/models/DeepSeek-V4.1-Flash
export MODEL_GLM53_FLASH=/mnt/local-nvme-cache/models/GLM-5.3-Flash
문서 모델 경로
export MODEL_PADDLEOCR_VL16=/mnt/local-nvme-cache/models/PaddleOCR-VL-1.6
export MODEL_DOCLING_LAYOUT_HERON=/mnt/local-nvme-cache/models/docling-layout-heron
export MODEL_DOCLING_MODELS=/mnt/local-nvme-cache/models/docling-models
STAGE7_MANIFEST와 STAGE7_PRODUCTION_POLICY는 반드시 실제 파일 위치를 가리켜야 합니다.
2-3. 기본 확인
source ./validation_env.sh
"$PYTHON_BIN" -c \
'import vllm; print(vllm.version)'
nvidia-smi
"$VLLM_BIN" bench serve --help
특히 모델 로딩과 벤치마크 옵션은 실제 설치된 vLLM 0.31.0에서 확인해야 합니다. Manifest에 적힌 READY나 CONDITIONAL은 실제 체크포인트 호환성이 검증됐다는 뜻이 아닙니다.
3. 모델별 실행 순서
권장 순서는 비교적 작은 TP 후보를 사용하는 모델부터 시작하고, 이후 8GPU 전체를 사용하는 모델을 검증하는 것입니다.
1단계 — gpt-oss-20b
Stage7a · TP 1, 2
./stage7a_night_batch_qualification.sh gpt_oss_20b
2단계 — Qwen3.6-35B-A3B
Stage7a · TP 1, 2
./stage7a_night_batch_qualification.sh qwen3_6_35b_a3b
3단계 — GLM-5.3
Stage7a · TP 8
./stage7a_night_batch_qualification.sh glm_5_3
4단계 — DeepSeek-V4.1-Flash
Stage7b · TP 2, 4, 8 · 온라인 SLO
./stage7b_online_slo_qualification.sh deepseek_v4_1_flash
5단계 — GLM-5.3-Flash
Stage7b · TP 2, 4, 8 · 온라인 SLO
./stage7b_online_slo_qualification.sh glm_5_3_flash
이 순서는 실행 편의성을 위한 권장 순서이며, 각 모델의 실제 메모리 적합성이나 호환성을 보증하지는 않습니다.
Stage7b는 기본적으로 Short/Long 간섭을 4회 교차 측정합니다. 각 모델의 tp*/interference_summary.json에서 유효 Round와 TTFT 악화율을 확인하세요.
4. Docling 실행 방법
Docling은 LLM과 달리 stage7c_document_pipeline.py를 사용합니다.
현재 Manifest에 정의된 문서 모델 키는 다음과 같습니다.
모델 '--model-key
PaddleOCR-VL-1.6 paddleocr_vl_1_6
Docling Layout Heron docling_layout_heron
Docling Models docling_models
DocumentFigureClassifier document_figure_classifier
4-1. Golden 문서 준비
stage7_golden_manifest_example.jsonl을 복사해 실제 검증 문서 경로로 수정합니다.
cp stage7_golden_manifest_example.jsonl \
stage7_golden_manifest.jsonl
예를 들어 다음과 같은 문서 구성을 권장합니다.
- 일반 PDF: 텍스트 추출 정확도
- 스캔 PDF: OCR 품질
- 표가 많은 문서: Table Extraction
- 그림이 많은 문서: Figure Detection
- 복잡한 레이아웃: Layout Parsing
4-2. Docling Adapter 구현
현재 stage7_document_adapter_example.py는 실제 Docling 실행 코드가 아닌 골격입니다. run_pipeline()에 NotImplementedError가 있으므로 그대로 실행하면 실패합니다.
실제 Docling 런타임을 호출하고 아래와 같은 결과를 반환하도록 구현해야 합니다.
{ "metrics": { "text_score": 0.98, "layout_score": 0.95, "table_score": 0.93, "figure_score": 0.91 }, "result": { "output_path": "/path/to/result.json" }}
위 점수는 출력 형식을 보여주기 위한 예시 값입니다. 실제 구현에서는 Golden 정답과 비교하여 산출해야 합니다.
4-3. 실행
Adapter 구현이 끝났다면:
python3 stage7c_document_pipeline.py \
--manifest "$STAGE7_MANIFEST" \
--model-key docling_layout_heron \
--golden-manifest stage7_golden_manifest.jsonl \
--adapter-cmd \
'python3 stage7_document_adapter_example.py --input {input} --output {output} --model-key {model_key}'
docling_models와 document_figure_classifier도 같은 방식으로 실행할 수 있지만, 각각의 실제 파이프라인을 처리하도록 Adapter를 구성해야 합니다.
주의: Stage7c는 Adapter가 반환한 품질 점수를 기록할 뿐, Golden 정답과 자동 비교하여 정확도를 계산하지 않습니다. 또한 성공률 100%만으로 문서 추출 품질이 합격했다고 판단해서는 안 됩니다.
5. Stage7 결과 확인
모델별 실행이 끝나면 다음을 실행합니다.
python3 stage7_summary_report.py \
--root "STAGE7_ROOT/stage7_summary.md" \
--json-out "$STAGE7_ROOT/stage7_summary.json"
모델별로 다음 파일을 확인하세요.
결과 파일 확인 내용
preflight.json 모델 호환성, vLLM 버전
qualification_metrics.json TP·동시성별 TTFT, ITL, TPS
tp/saturation_summary.json Saturation 및 SLO 만족 여부
tp/interference_summary.json 온라인 모델의 Short/Long 간섭
tp/metrics_compat.json vLLM 메트릭 호환성
model_selection_summary.json 최종 TP 후보 선정 결과
document_qualification.json Docling 성공률, 처리 속도, 품질 점수
예를 들어 gpt-oss-20b의 최신 결과를 보려면:
ls -dt "$STAGE7_ROOT/night_batch/gpt_oss_20b/" | head -1
여기서 중요한 것은 가장 높은 TPS를 기록한 구성이 반드시 운영 최적 구성은 아니라는 점입니다. 온라인 모델은 TTFT/ITL SLO를, 야간 배치 모델은 처리량과 GPU 효율을 우선하여 선정해야 합니다.
6. Stage7d — Kubernetes 재검증
Bare-metal 결과에서 선정된 TP와 Serving 설정을 Kubernetes에 배포한 후 Stage7d를 실행합니다.
예를 들어 gpt-oss-20b가 TP=2로 선정되었다면:
터미널 1에서 Kubernetes Service를 포트 포워딩합니다.
kubectl -n ai-serving port-forward \
svc/gpt-oss-20b 8100:8000
터미널 2에서:
source ./validation_env.sh
./stage7d_k8s_model_revalidation.sh \
night_batch gpt_oss_20b \
--external-tp 2
온라인 모델도 같은 방식입니다.
./stage7d_k8s_model_revalidation.sh \
online deepseek_v4_1_flash \
--external-tp 4
--external-tp에는 실제 Kubernetes Deployment의 TP 값을 입력해야 합니다. stage7d는 이미 실행 중인 vLLM 서버에 요청하며 서버를 직접 종료하지 않습니다.
단, Stage7d는 Kubernetes Deployment를 생성하지 않습니다. GPU Operator, 스케줄링, Service, 모델 캐시 등은 Stage6에서 검증한 구성을 사용해야 합니다.
7. 운영 설정 생성
Stage7a/b 결과, 품질 검증, 장시간 안정성 검증, Kubernetes 재검증을 모두 확보한 후 Production Evidence를 작성합니다.
cp stage7_production_evidence_example.yaml \
deepseek_v4_1_flash_evidence.yaml
이 파일에서 다음 항목을 실제 결과로 채워야 합니다.
- quality.status: Golden Set 품질 검증
- stability.soak_status: 장시간 안정성
- k8s.status: Kubernetes 재검증
- serving: precision, KV dtype, max model length, batch tokens, Prefix Cache 설정
- container: 이미지 repository, tag, digest
운영 프로파일 생성 예시:
RUN_DIR=STAGE7_ROOT/online/deepseek_v4_1_flash/"* | head -1)
./stage7_generate_full_production_bundle.sh \
deepseek_v4_1_flash \
"RUN_DIR" \ deepseek_v4_1_flash_evidence.yaml \ "STAGE7_ROOT/production-configs/deepseek_v4_1_flash"
생성되는 파일은 model-production-profile.yaml, helm-values.yaml, inferencepool.yaml, httproute.yaml, litellm-model-team-capacity.yaml 등입니다.
운영 승인 조건이 미충족이면 REVIEW_REQUIRED로 처리하거나 배포가 비활성화됩니다. 생성된 YAML을 그대로 운영 클러스터에 적용하기 전에 실제 Gateway API와 InferencePool CRD 버전도 확인해야 합니다.
8. 실행 전에 수정할 파일 정리
파일 수정 필요성 수정할 내용
validation_env.sh 필수 Python/vLLM 경로, 모델 경로, 결과 경로
stage7_model_qualification.yaml 검토 필수 TP 후보, 컨텍스트 길이, 동시성, 호환성, Serving 옵션
stage7_production_profile_policy.yaml 필수 TTFT/ITL SLO, 최소 처리량, 예상 피크, Headroom
stage7_golden_manifest_example.jsonl 문서 검증 시 필수 실제 Golden 문서 경로
stage7_document_adapter_example.py Docling 검증 시 필수 실제 Docling/PaddleOCR 호출 구현
stage7_production_evidence_example.yaml 운영 설정 생성 시 필수 품질, Soak, K8s, Serving 검증 결과
stage7_llm_qualification.py 일반적으로 불필요 공통 측정 엔진이므로 우선 그대로 사용
Stage7a/b/d Shell 일반적으로 불필요 모델 키와 실행 옵션으로 제어
특히 현재 stage7_production_profile_policy.yaml의 TTFT/ITL 임계값과 최소 처리량은 null로 남아 있습니다. 이 값을 실제 서비스 요구사항에 맞게 확정하지 않으면 의미 있는 SLO 합격 판정을 내릴 수 없습니다.
또한 현재 스크립트에서 확인되는 제약이 있습니다. Prefix Cache 메트릭 호환성은 처리하지만 Prefix Cache OFF/ON 완전 A/B 테스트는 자동 실행하지 않습니다. Stage3a8에서 별도로 수행한 결과를 Evidence에 연결하는 편이 좋습니다. Stage7의 Golden Set 기반 LLM 품질 자동 평가도 별도 구현이 필요합니다.
최종 권장 실행 흐름
환경 설정 및 모델 호환성 확인
validation_env.sh + Manifest + Policy
Stage7a
GLM-5.3, Qwen3.6, gpt-oss
Stage7b
DeepSeek Flash, GLM Flash
Stage7c — Docling / PaddleOCR
문서 Golden Set 및 Adapter 검증 (별도 트랙)
Stage7 Summary + 품질·안정성 검증
TP, 동시성, TPS, SLO 및 품질 근거 확보
Stage7d — Kubernetes LLM 재검증
Stage6 환경에 동일 모델/설정 배포 후 측정
Production Evidence → 운영 설정 생성
Helm / InferencePool / HTTPRoute / LiteLLM
현재 단계에서 가장 먼저 할 일은 validation_env.sh의 모델 경로를 확정하고, stage7_model_qualification.yaml의 TP 후보와 stage7_production_profile_policy.yaml의 SLO를 점검하는 것입니다. 그다음 gpt-oss-20b부터 순차적으로 실행하는 것을 권장합니다.
Stage7 v2 스크립트 패키지
===
Docling 검증에 필요한 부분을 구현해 Stage7 v3 패키지로 만들었습니다. 기존 Stage7a/b/d와 LLM 검증 기능은 유지하고, Stage7c의 Docling 실행 부분을 확장했습니다.
Stage7 v3 + Docling 검증 패키지 다운로드 (.tar.gz)
이번에 구현한 기능
| 항목 | 구현 내용 |
|---|---|
| 실제 Docling 실행 | DocumentConverter 기반 PDF 변환 |
| OCR 설정 | auto, on, off 선택 |
| 결과 저장 | Markdown, 가능한 경우 Docling JSON |
| 처리 성능 | 문서별 처리 시간, 페이지당 시간, pages/min |
| 텍스트 품질 | Golden 정답과 정규화된 문자 유사도 비교 |
| 품질 판정 | PASS / FAIL / REVIEW_REQUIRED |
| 사전 점검 | Docling, PyTorch, CUDA, GPU 인식 여부 |
| 결과 취합 | 기존 Stage7 Summary와 연동 |
| 실행 편의성 | Docling 전용 Shell 실행 스크립트 |
| 안전한 실행 | 문서 경로를 Shell 명령으로 직접 실행하지 않도록 개선 |
특히 품질 점수를 임의로 생성하지 않도록 구성했습니다. 실제 Golden 정답이 없으면 텍스트 품질은 REVIEW_REQUIRED로 남으며, Layout·Table·Figure 정확도는 별도 평가가 필요합니다.
추가된 주요 파일
| 파일 | 용도 |
|---|---|
stage7_docling_adapter.py | 실제 Docling 변환 실행 |
stage7c_document_pipeline.py | 성능 측정 및 Golden 품질 평가 (수정) |
stage7c_docling_run.sh | Docling 검증 통합 실행 |
stage7c_docling_preflight.py | 실행 환경 사전 점검 |
stage7c_docling_golden_template.jsonl | Golden 문서 목록 템플릿 |
requirements-stage7c-docling.txt | Python 의존성 |
README_STAGE7C_DOCLING.md | 설치·실행·판정 방법 |
실행 방법
1. 패키지 압축 해제 및 의존성 설치
tar xzf stage7_v3_docling_ready.tar.gz
cd stage7_v3_docling_ready
python3 -m venv .venv-docling
source .venv-docling/bin/activate
pip install -r requirements-stage7c-docling.txt
python stage7c_docling_preflight.pyB300 환경의 기존 PyTorch/CUDA 구성을 유지해야 한다면, 별도 가상환경에서 Docling 의존성을 검증한 뒤 설치 버전을 고정하는 것이 좋습니다.
2. Golden 문서 준비
cp stage7c_docling_golden_template.jsonl \
stage7c_docling_golden.jsonl이 파일에서 PDF 경로와 정답 Markdown 경로를 실제 경로로 변경합니다.
3. Docling 검증 실행
export STAGE7_ROOT=/var/log/b300_validation/stage7
./stage7c_docling_run.sh \
docling_models \
stage7c_docling_golden.jsonl \
--min-text-similarity 0.900.90은 예시 임계값입니다. 실제 운영 기준은 문서 종류별 요구 품질에 맞게 결정해야 합니다.
4. 결과 확인
python stage7_summary_report.py \
--root "$STAGE7_ROOT" \
--out "$STAGE7_ROOT/stage7_summary.md"문서별 결과는 다음 디렉터리에 저장됩니다.
$STAGE7_ROOT/document/docling_models/<timestamp>/
├── document_qualification.json
├── document_qualification.csv
├── 0000_<document-id>.json
└── 0000_<document-id>/
├── document.md
└── document.json아직 실제 환경에서 확인해야 하는 부분
Docling 전체 파이프라인 검증과 특정 내부 모델 검증은 구분해야 합니다.
docling_models는 실제 Docling 변환을 실행하도록 구현했습니다. 반면 docling_layout_heron과 document_figure_classifier는 특정 체크포인트가 실제 로딩되었다는 증거가 필요하므로, 범용 Docling 실행 결과를 해당 모델의 합격 결과로 처리하지 않습니다.
또한 이번 패키지는 다음 사항을 아직 보장하지 않습니다.
- B300에서 실제 Docling 변환 성공 여부
- 특정 Docling 버전의 CUDA 가속 및 GPU 사용률
- Layout·Table·Figure의 정답 기반 정확도
- Kubernetes 환경에서의 Docling 성능 재현성
검증 상태: Python 컴파일, Bash 구문 검사, YAML 파싱, 모의 Adapter를 이용한 Stage7c 실행 및 Golden 점수 계산을 확인했습니다. 실제 Docling 런타임 통합 테스트는 수행하지 않았습니다.
현재 단계에서는 docling_models의 실제 변환과 Golden 품질 평가부터 수행하고, 이후 Layout Heron 및 Figure Classifier를 각각 독립적으로 검증하는 순서를 권장합니다.
===
현재 Stage7 v3 Docling Ready 패키지를 기준으로, 실행 전에 설정해야 하는 파일과 변수, 권장 초기값을 정리했습니다.
핵심은 설정을 세 단계로 구분하는 것입니다.
- 공통 환경: 모델 경로, Python/vLLM 실행 경로, 결과 저장 위치
- 검증 조건: 모델별 TP·동시성·입출력 길이, SLO, Docling Golden Set
- 운영 전환: 품질·안정성·Kubernetes 검증 증거, Serving 설정, 배포 설정
아래 권장값은 B300 8GPU 단일 노드에서 검증을 시작하기 위한 초기값입니다. 실제 운영 최적값이나 합격 기준이 이미 검증됐다는 의미는 아닙니다.
1. 설정 파일 전체 목록
| 파일 | 설정 시점 | 중요도 |
|---|---|---|
validation_env.sh | 모든 Stage7 실행 전 | 필수 |
stage7_model_qualification.yaml | LLM/Docling 검증 전 | 필수 검토 |
stage7_production_profile_policy.yaml | 성능 검증 및 운영 설정 생성 전 | 필수 |
stage7c_docling_golden.jsonl | Docling 검증 전 | 필수 |
stage7_production_evidence_example.yaml 복사본 | 운영 설정 생성 전 | 필수 |
stage7_qualification_card_template.yaml 복사본 | 모델별 검증 기록 시 | 권장 |
requirements-stage7c-docling.txt | Docling 환경 설치 시 | 필수 확인 |
stage7_docling_adapter.py | Docling 내부 구성 변경 시 | 조건부 |
stage7_generate_serving_platform_configs.py | 플랫폼 CRD/출력 형식 변경 시 | 조건부 |
stage7_llm_qualification.py, Stage7a/b/d Shell 스크립트는 일반적으로 직접 수정하지 않고 환경변수와 YAML로 제어합니다.
2. validation_env.sh — 공통 환경변수
Stage7 v3에는 이 파일이 포함되어 있지 않으므로 기존 Stage1~6의 파일을 재사용하거나 별도로 만들어야 합니다.
| 변수명 | 의미 | 권장 초기값 |
|---|---|---|
PYTHON_BIN | Python 실행 파일 | vLLM 0.31.0이 설치된 Python 절대 경로 |
VLLM_BIN | vLLM CLI | 해당 가상환경의 vllm 절대 경로 |
STAGE7_ROOT | 결과 저장 디렉터리 | /var/log/b300_validation/stage7 |
STAGE7_MANIFEST | 모델 정의 YAML 경로 | Stage7 디렉터리 내 Manifest |
STAGE7_PRODUCTION_POLICY | 운영 정책 YAML 경로 | Stage7 디렉터리 내 Policy |
STAGE7_HOST | 벤치마크 대상 주소 | 127.0.0.1 |
STAGE7_PORT | 벤치마크 대상 포트 | 8100 |
STAGE7_SERVER_READY_TIMEOUT_SEC | 모델 로딩 후 준비 대기 최대 시간(초) | 3600 |
STAGE7_ENGINE_WARMUP_REQUESTS | 엔진 초기 Warm-up 요청 수 | 20 |
STAGE7_INTERFERENCE_ROUNDS | 온라인 Short/Long 교차 측정 Round 수 | 4 이상 |
STAGE7_EXTERNAL_TP | K8s 외부 vLLM 서버의 실제 TP | Deployment의 실제 TP |
STAGE7_DOC_ADAPTER_CMD | 문서 모델용 별도 Adapter 명령 | 기본 Docling 전체 파이프라인은 미설정 |
STAGE7_PRODUCTION_EVIDENCE_ROOT | 모델별 운영 Evidence 디렉터리 | $STAGE7_ROOT/production-evidence |
모델 경로 변수는 Manifest의 model_path_env와 정확히 일치해야 합니다.
| 모델 | 환경변수 |
|---|---|
| GLM-5.3 | MODEL_GLM53 |
| Qwen3.6-35B-A3B | MODEL_QWEN36_35B_A3B |
| gpt-oss-20b | MODEL_GPTOSS_20B |
| DeepSeek-V4.1-Flash | MODEL_DEEPSEEK_V41_FLASH |
| GLM-5.3-Flash | MODEL_GLM53_FLASH |
| PaddleOCR-VL-1.6 | MODEL_PADDLEOCR_VL16 |
| Docling Layout Heron | MODEL_DOCLING_LAYOUT_HERON |
| Docling Models | MODEL_DOCLING_MODELS |
| DocumentFigureClassifier | MODEL_DOCUMENT_FIGURE_CLASSIFIER |
아래는 추가 설정 예시입니다. 기존 validation_env.sh가 있다면 파일을 통째로 덮어쓰지 말고 필요한 변수를 병합하세요.
# Stage7 전용 환경변수 예시
export STAGE7_DIR="$HOME/b300-validation/stage7_v3_docling_ready"
export PYTHON_BIN="/opt/venvs/vllm/bin/python"
export VLLM_BIN="/opt/venvs/vllm/bin/vllm"
export STAGE7_ROOT="/var/log/b300_validation/stage7"
export STAGE7_MANIFEST="$STAGE7_DIR/stage7_model_qualification.yaml"
export STAGE7_PRODUCTION_POLICY="$STAGE7_DIR/stage7_production_profile_policy.yaml"
export STAGE7_HOST="127.0.0.1"
export STAGE7_PORT="8100"
export STAGE7_SERVER_READY_TIMEOUT_SEC="3600"
export STAGE7_ENGINE_WARMUP_REQUESTS="20"
export STAGE7_INTERFERENCE_ROUNDS="4"
export MODEL_GLM53="/mnt/local-nvme/models/GLM-5.3"
export MODEL_QWEN36_35B_A3B="/mnt/local-nvme/models/Qwen3.6-35B-A3B"
export MODEL_GPTOSS_20B="/mnt/local-nvme/models/gpt-oss-20b"
export MODEL_DEEPSEEK_V41_FLASH="/mnt/local-nvme/models/DeepSeek-V4.1-Flash"
export MODEL_GLM53_FLASH="/mnt/local-nvme/models/GLM-5.3-Flash"
export STAGE7_PRODUCTION_EVIDENCE_ROOT="$STAGE7_ROOT/production-evidence"/mnt/local-nvme/models는 예시 경로입니다. 실제 AIStor에서 동기화한 로컬 체크포인트 위치로 변경해야 합니다.
주의할 점은 Stage7d에서 외부 서버를 사용할 때도 vLLM CLI가 필요하다는 것입니다. 로컬 CLI가 벤치마크 클라이언트 역할을 하기 때문입니다.
3. stage7_model_qualification.yaml — 모델별 검증 설정
이 파일은 모델을 어떤 GPU 구성과 워크로드로 테스트할지 정의합니다.
공통 변수
| 변수명 | 의미 | 권장 설정 |
|---|---|---|
qualification_policy.vllm_standard_version | 표준 vLLM 버전 | 0.31.0 유지 |
models.<key>.model_path_env | 체크포인트 경로를 읽을 환경변수 이름 | 기존 이름 유지 |
models.<key>.served_name | vLLM API 모델 이름 | 배포 시 이름과 일치 |
models.<key>.compatibility | 사전 호환성 분류 | 실제 로딩 확인 전 확정 금지 |
models.<key>.min_vllm_version | 최소 요구 버전 | 모델별 검증된 버전 |
models.<key>.tp | 기본 Tensor Parallel 수 | 초기 후보 중 하나 |
models.<key>.tp_candidates | 순차 테스트할 TP 후보 | 모델별 아래 표 |
models.<key>.extra_serve_args | vllm serve에 추가할 옵션 | 현재 버전에서 지원 확인 |
models.<key>.profiles | 테스트 워크로드 목록 | Short/Medium/Long 등 |
profiles[].input_len | 입력 토큰 수 | 실제 사용 패턴 기준 |
profiles[].output_len | 출력 토큰 수 | 실제 사용 패턴 기준 |
profiles[].concurrencies | 테스트 동시 요청 수 목록 | 작은 값부터 증가 |
모델별 TP 권장 초기값
| 모델 | 현재 Manifest | 권장 |
|---|---|---|
| GLM-5.3 | [8] | [8] 유지, 메모리 적합성 확인 |
| Qwen3.6-35B-A3B | [1, 2] | [1, 2] |
| gpt-oss-20b | [1, 2] | [1, 2] |
| DeepSeek-V4.1-Flash | [2, 4, 8] | [2, 4, 8], 적합성 확인 후 |
| GLM-5.3-Flash | [2, 4, 8] | [2, 4, 8], 적합성 확인 후 |
이 값들은 업로드된 Manifest의 탐색 후보이지, 실제 체크포인트 크기와 HBM 요구량을 확인한 최적값이 아닙니다. 특히 Flash 모델의 CONDITIONAL 상태는 검증이 더 필요하다는 의미입니다.
프로파일 권장
| 프로파일 | 입력 / 출력 토큰 | 초기 동시성 |
|---|---|---|
| 야간 Small | 4,096 / 1,024 | [4, 8, 16] |
| 야간 Medium | 16,384 / 2,048 | [4, 8, 16] |
| 야간 Long | 65,536 / 4,096 | [1, 2, 4] |
| 온라인 Short | 2,048 / 256 | [1, 8, 16, 32] |
| 온라인 Medium | 8,192 / 512 | [1, 8, 16, 32] |
| 온라인 Long | 32,768 / 512 | [1, 4, 8, 16] |
위 값은 통일된 비교를 위한 제안입니다. 기존 Manifest의 동시성 목록과 일부 다르며, 자동 적용된 설정은 아닙니다.
중요: 긴 컨텍스트에서 OOM이 발생하면 동시성을 낮추거나 프로파일 길이를 줄여야 합니다. 단, 그 경우 원래 테스트와 다른 조건이므로 결과를 별도로 기록하세요.
4. stage7_production_profile_policy.yaml — SLO 및 GPU 선정 정책
이 파일은 Stage7에서 가장 중요한 설정 중 하나입니다.
온라인 모델
| 변수명 | 의미 | 권장 초기값 |
|---|---|---|
workload_classes.online.target_profile | GPU 선정에 사용할 대표 워크로드 | medium |
slo.p99_ttft_ms | TTFT p99 상한(ms) | 실제 서비스 요구사항 입력 |
slo.p99_itl_ms | ITL p99 상한(ms) | 실제 서비스 요구사항 입력 |
slo.max_error_rate | 허용 오류 비율 | 0.01 (1%) |
expected_peak_concurrency | 예상 피크 동시 요청 수 | 실제 예상값 |
expected_peak_rps | 예상 피크 초당 요청 수 | 실제 예상값 |
headroom.concurrency_pct | 동시성 여유율 | 30 (%) |
headroom.rps_pct | 처리량 여유율 | 25 (%) |
예를 들어 서비스 목표를 임시로 정하고 성능을 탐색한다면:
online:
target_profile: medium
slo:
p99_ttft_ms: 3000
p99_itl_ms: 150
max_error_rate: 0.01
expected_peak_concurrency: 16
expected_peak_rps: 2
headroom:
concurrency_pct: 30
rps_pct: 25이는 가상의 서비스 SLO 예시입니다. 실제 요구사항이 정해지지 않았다면 해당 숫자를 운영 승인 기준으로 사용하지 마세요.
위 예시의 동시성 필요량은 ceil(16 × 1.3) = 21이며, RPS 필요량은 2 × 1.25 = 2.5입니다.
야간 배치 모델
| 변수명 | 의미 | 권장 초기값 |
|---|---|---|
target_profile | GPU 선정 기준 프로파일 | medium |
slo.minimum_request_throughput_rps | 최소 요청 처리량 | 배치 완료시간에서 역산 |
slo.minimum_output_throughput_tps | 최소 출력 TPS | 실제 처리량 목표 |
slo.max_error_rate | 허용 오류율 | 0.01 |
expected_peak_concurrency | 필요한 동시 작업 수 | 배치 규모 기준 |
expected_peak_rps | 필요한 요청 처리량 | 배치 규모 기준 |
headroom.concurrency_pct | 동시성 여유 | 30 |
headroom.rps_pct | RPS 여유 | 25 |
예를 들어 야간 8시간 동안 100,000개 요청을 처리해야 한다면 최소 평균 처리량은 약 3.47 RPS입니다. 여유율 25%를 적용한 탐색 목표는 약 4.34 RPS입니다. 다만 실제로는 입력·출력 길이 분포와 재시도 비용도 반영해야 합니다.
Saturation 중단 조건
| 변수명 | 의미 | 현재값 / 권장 |
|---|---|---|
selection.adaptive_stop.consecutive_slo_failures | 연속 SLO 실패 시 탐색 중단 | 2 유지 |
selection.adaptive_stop.throughput_plateau_pct | 처리량 증가가 이 값보다 작으면 Plateau 후보 | 5 (%) |
selection.adaptive_stop.min_concurrency_before_plateau_stop | Plateau 중단을 적용할 최소 동시성 | 16 |
주의할 점은 slo 값이 null이면 해당 성능 지표의 합격 조건이 사실상 생략된다는 것입니다. 따라서 현재 파일 그대로 실행하면 실제 서비스 SLO에 대한 합격을 보장하지 않습니다.
또한 expected_peak_concurrency: 0은 의미 있는 피크 수요가 입력되지 않은 상태입니다. 운영용 GPU 수 선정 전에 실제 값을 채우는 것이 좋습니다.
5. Docling 전용 설정
5-1. stage7c_docling_golden.jsonl
템플릿 stage7c_docling_golden_template.jsonl을 복사해서 사용합니다.
| 필드 | 의미 | 권장 |
|---|---|---|
id | 문서 고유 ID | 중복 없이 지정 |
path | 실제 PDF 절대 경로 | 필수 |
pages | 문서 페이지 수 | 실제 PDF 페이지 수 |
category | 문서 유형 | text_pdf, scanned_pdf, table_pdf 등 |
expected_text_path | 검수된 정답 Markdown/텍스트 | 품질 평가 시 필수 |
예시:
{"id":"doc001","path":"/data/golden/text.pdf","pages":3,"category":"text_pdf","expected_text_path":"/data/golden/expected/text.md"}
{"id":"doc002","path":"/data/golden/scan.pdf","pages":5,"category":"scanned_pdf","expected_text_path":"/data/golden/expected/scan.md"}권장하는 Golden Set 구성은 실제 업무 문서 비율을 반영하는 것입니다. 초기에는 각 유형별 10~20개 문서로 시작해 평가 로직을 점검하고, 운영 판정 전에는 대표성과 표본 수를 확대하는 방식을 추천합니다.
5-2. Docling 실행 옵션
| 변수 / 옵션 | 의미 | 권장 |
|---|---|---|
--model-key | 검증 대상 모델 키 | 전체 파이프라인은 docling_models |
--golden-manifest | Golden JSONL 경로 | 실제 파일 |
--timeout-sec | 문서당 제한시간 | 기본 900초 |
--min-text-similarity | 텍스트 유사도 합격 하한 | 초기 탐색용 0.90 |
--adapter-cmd | Adapter 실행 명령 | 기본 Docling 어댑터 |
Adapter --ocr | OCR 실행 설정 | auto로 시작, 이후 ON/OFF 비교 |
Adapter --artifacts-dir | Markdown/JSON 저장 위치 | 기본 자동 생성 경로 |
예시:
./stage7c_docling_run.sh \
docling_models \
stage7c_docling_golden.jsonl \
--min-text-similarity 0.90 \
--timeout-sec 900--ocr은 stage7c_docling_run.sh가 직접 받는 옵션이 아니라 Adapter 옵션입니다. OCR 모드를 바꾸려면 STAGE7_DOC_ADAPTER_CMD에 별도로 지정해야 합니다.
예를 들어 OCR을 강제로 켜려면:
export STAGE7_DOC_ADAPTER_CMD="python3 $PWD/stage7_docling_adapter.py --ocr on --input {input} --output {output} --model-key {model_key}"이후 Stage7c 실행 스크립트를 실행합니다.
권장: 텍스트 PDF는 OCR OFF, 스캔 PDF는 OCR ON을 별도 테스트하여 품질·속도를 비교하세요. 현재 스크립트가 문서 유형에 따라 OCR 모드를 자동으로 바꾸지는 않습니다.
6. stage7_production_evidence_example.yaml — 운영 승인 근거
모델별 복사본을 만들어 실제 검증 결과를 기록합니다.
| 변수명 | 의미 | 입력 권장 |
|---|---|---|
model_key | 모델 식별자 | Manifest와 동일 |
quality.status | Golden 품질 검증 상태 | 실제 검증 후 PASS |
quality.golden_set_version | Golden Set 버전 | 예: golden-v1 |
stability.soak_status | 장시간 안정성 검증 | 실제 검증 후 PASS |
stability.soak_hours | 검증 시간 | 실제 수행 시간 |
k8s.status | K8s 재검증 상태 | 실제 검증 후 PASS |
k8s.result_dir | Stage7d 결과 경로 | 실제 경로 |
serving.precision | 추론 정밀도 | 검증된 BF16/FP8 등 |
serving.kv_cache_dtype | KV Cache 정밀도 | 검증된 값 |
serving.max_model_len | 최대 Context Length | 테스트된 값 |
serving.max_num_seqs | 최대 동시 Sequence | Saturation 결과 기반 |
serving.max_num_batched_tokens | 배치당 최대 토큰 | 테스트된 값 |
serving.enable_prefix_caching | Prefix Cache ON/OFF | Stage3a8 결과 기반 |
serving.gpu_memory_utilization | GPU 메모리 사용 목표 비율 | 초기 탐색 0.90 |
serving.extra_serve_args | 추가 vLLM 옵션 | 검증된 옵션만 |
container.repository | 이미지 저장소 | 실제 Registry |
container.tag | 이미지 태그 | 고정 버전 |
container.digest | 이미지 Digest | 가능하면 SHA256 고정 |
litellm.logical_model_name | LiteLLM 노출 이름 | 클라이언트용 논리 이름 |
litellm.team | 용량 할당 대상 팀 | 실제 팀 |
litellm.capacity_allocation_pct | 팀 용량 할당 비율 | 초기 100, 공유 시 조정 |
추가로 Stage3a 정합성 관련 항목이 있습니다.
| 변수명 | 의미 |
|---|---|
stage3a_alignment.mixed_workload.status | Mixed Workload 검증 상태 |
stage3a_alignment.mixed_workload.crossover_valid_rounds | 유효 교차 측정 Round 수 |
stage3a_alignment.mixed_workload.p99_ttft_degradation_pct | Short TTFT 악화율 |
stage3a_alignment.prefix_cache.status | Prefix Cache 검증 상태 |
stage3a_alignment.prefix_cache.warm_hit_rate | Warm 상태 Cache Hit Rate |
stage3a_alignment.prefix_cache.metric_source | 메트릭 출처 |
stage3a_alignment.scheduler_kv.status | Scheduler/KV 분석 상태 |
stage3a_alignment.precision_quality.status | 정밀도별 품질 검증 상태 |
stage3a_alignment.precision_quality.bf16_fp8_quality_delta_pp | BF16 대비 FP8 품질 차이(%p) |
여기서 주의할 부분은 Evidence에 PASS를 적는 것과 실제 검증 결과를 자동으로 확인하는 것은 다르다는 점입니다. 운영 설정 생성기는 Evidence의 상태값을 읽으므로, 결과 파일과 수동으로 대조한 후 입력해야 합니다.
7. stage7_qualification_card_template.yaml — 모델별 검증 기록
이 파일은 모델별 승인·검토 기록을 남기기 위한 템플릿입니다.
주요 항목은 다음과 같습니다.
| 영역 | 주요 변수 | 의미 |
|---|---|---|
| 모델 | model_key, checkpoint_revision | 검증한 정확한 모델 |
| 소프트웨어 | software.runtime_version, cuda, driver | 재현 가능한 실행 환경 |
| 배포 | deployment.tp, ep, precision, kv_cache_dtype | GPU 구성 |
| 기능 | functional.load, generation_or_pipeline | 로딩·실행 검증 |
| 품질 | quality.golden_set_version, result | 품질 검증 |
| 성능 | performance.max_sustainable_concurrency, ttft_p99_ms, itl_p99_ms, output_tps | 성능 결과 |
| 캐시 | capacity.local_nvme, remote_object, memkv_tcp, memkv_rdma | 캐시·스토리지 검증 |
| 안정성 | stability.smoke_4h, soak_8h | 안정성 |
| K8s | k8s.startup, readiness, performance_revalidation | K8s 검증 |
| 승인 | approval.status, conditions | 최종 판단 |
이 템플릿은 사람이 검증 이력을 정리하기 위한 자료이며, 현재 Production Config 생성기가 이 파일을 직접 읽는 구조는 아닙니다.
8. 운영 플랫폼 설정
stage7_production_profile_policy.yaml의 platform_outputs 영역에서 설정합니다.
| 변수명 | 의미 | 현재값 / 권장 |
|---|---|---|
namespace | 모델 배포 Namespace | ai-serving |
gateway_name | Gateway API Gateway 이름 | inference-gateway |
gateway_namespace | Gateway Namespace | ai-serving-system |
gateway_section_name | Listener 이름 | https |
inference_api_group | InferencePool API 그룹 | inference.networking.x-k8s.io |
inference_api_version | InferencePool API 버전 | v1, 실제 CRD 확인 |
epp_service_port | Endpoint Picker 서비스 포트 | 9002 |
http_route.api_path_prefix | HTTPRoute PathPrefix | /v1 |
http_route.hostname | HTTPRoute 호스트명 | 실제 도메인 |
litellm.default_team | 기본 팀 | shared |
litellm.capacity_allocation_pct | 기본 할당 비율 | 100 |
이 값은 현재 스크립트의 기본 출력 형태입니다. 특히 InferencePool API 그룹과 버전은 설치된 Gateway API Inference Extension의 CRD와 일치해야 합니다.
9. 실제 설정 순서
1. 환경 준비
validation_env.sh에 모델 경로, Python, vLLM, 결과 경로 설정
2. 모델별 측정 조건
stage7_model_qualification.yaml에서 TP 후보와 프로파일 검토
3. 서비스 성능 기준
stage7_production_profile_policy.yaml에서 SLO·피크 수요·Headroom 설정
4. Docling Golden Set
JSONL 경로와 검수된 정답 텍스트 지정
5. Stage7a/b/c 실행
모델별 측정 및 품질 검증
6. Stage7d 실행
LLM을 Kubernetes에 배포한 뒤 성능 재검증
7. Evidence 및 운영 설정
모델별 Evidence 작성 후 Helm/Gateway/LiteLLM 설정 생성
추가로 확인한 스크립트상 주의사항
- Stage7b의 간섭 테스트는 4회 교차 측정이 기본이지만, 현재 공통 엔진의
model_selection_summary.json은 간섭 결과를 GPU 선정 조건에 직접 반영하지 않습니다. 별도 결과 확인이 필요합니다. - Stage7d 결과는 Stage7a/b와 같은 모델 디렉터리에 저장됩니다. 따라서
latest_run기반 운영 설정 생성 전에 Bare-metal 결과와 K8s 결과 중 어느 Run을 사용할지 명시적으로 결정해야 합니다. 가능하면--run-dir을 지정하세요. - Stage7의 문서용 Policy에 있는
minimum_pages_per_min은 Docling Stage7c의 자동 합격 기준으로 연결되어 있지 않습니다. 현재 Docling은 별도--min-text-similarity를 사용합니다. stage7_generate_all_production_configs.sh는 LLM 5개만 대상으로 하며, Docling 운영 배포 설정은 생성하지 않습니다.- 모델별
extra_serve_args의 parser 옵션과 KV Cache 설정은 vLLM 0.31.0 및 해당 체크포인트에서 실제 지원되는지 사전 확인해야 합니다.
최종적으로 먼저 확정할 값은 TP 후보, 입출력 토큰 길이, 동시성, SLO, Golden Set 다섯 가지입니다. 이 값이 정해져야 Stage7의 측정 결과를 근거로 주간 온라인 프로파일과 야간 배치 프로파일을 신뢰성 있게 선정할 수 있습니다.
===
다음 개선으로는 Stage7a/b/d 실행 결과에 모델 Revision, vLLM 버전, Precision, KV dtype, Prefix Cache, GPU 구성 등의 실행 환경 정보를 자동 저장하고, Stage3a·Stage6k 결과 정규화 및 Production Evidence 연동까지 자동화하는 것을 권장
===
요청하신 개선사항을 반영해 Stage7 v5 — Baseline & Evidence Automation 패키지를 만들었습니다.
Stage7 v5 전체 패키지 다운로드 (.tar.gz)
기존 Stage7a/b/c/d와 Docling 검증 기능을 유지하면서 다음 기능을 추가했습니다.
| 개선 항목 | 구현 내용 |
|---|---|
| 실행 환경 자동 기록 | 모델 Revision, vLLM 버전, Precision, KV dtype, Prefix Cache, TP, GPU 정보 |
| Stage3a 결과 정규화 | 기존 벤치마크 JSON을 Stage7 비교 형식으로 변환 |
| Stage6k 결과 정규화 | Short/Long 벤치마크 JSON 및 메타데이터 변환 |
| 환경 일치성 비교 | Bare-metal과 K8s의 모델·Serving 설정 비교 |
| Production Evidence 연동 | 비교 결과를 모델별 Evidence YAML 후보에 자동 반영 |
| 안전한 승인 처리 | 근거가 부족하면 REVIEW_REQUIRED, 품질·안정성 PASS 자동 생성 금지 |
특히 자동 수집된 사실과 운영자가 선언한 설정을 구분하도록 했습니다. Kubernetes 외부 vLLM 서버는 API만으로 실제 TP, Precision, KV dtype, 모델 Revision을 모두 확인할 수 없으므로, 확인되지 않은 값을 임의로 채우지 않습니다.
1. 새로 추가된 파일
| 파일 | 역할 |
|---|---|
stage7_run_fingerprint.py | Stage7a/b/d 실행 환경 기록 |
stage7_baseline_normalize.py | Stage3a·Stage6k 결과 정규화 |
stage7_baseline_compare.py | 기존 성능 비교 + 실행 환경 일치성 검사 |
stage7_evidence_sync.py | 비교 결과를 Production Evidence 후보에 반영 |
README_STAGE7_V5_AUTOMATION.md | 설정·실행 가이드 |
Stage7a/b/d가 사용하는 stage7_llm_qualification.py도 수정했습니다. vLLM 서버 준비가 완료되면 TP별 디렉터리에 execution_fingerprint.json을 저장합니다.
2. 권장 실행 순서
① Stage3a — 모델별 Baseline
기존 성능 측정 결과 확보
② Stage7a/b — Bare-metal 검증
성능 + 실행 환경 Fingerprint 저장
③ Stage6/6k — Kubernetes 검증
K8s 플랫폼 및 필요 시 상세 성능 검증
④ Stage7d — Kubernetes 재검증
성능 + 배포 환경 Fingerprint 저장
⑤ Baseline Normalize + Compare
동일 조건 성능 회귀 및 설정 차이 검사
⑥ Production Evidence 후보 생성
검증 결과 반영 → 최종 승인 전 수동 확인
3. Stage7a/b/d 실행 환경 기록
기존 명령을 그대로 실행하면 됩니다.
./stage7a_night_batch_qualification.sh gpt_oss_20b
./stage7b_online_slo_qualification.sh deepseek_v4_1_flashStage7d에서는 실제 배포 환경에서 확인한 값을 추가로 제공할 수 있습니다.
export STAGE7_DEPLOYED_MODEL_REVISION="<실제 체크포인트 revision>"
export STAGE7_DEPLOYED_VLLM_VERSION="0.31.0"
export STAGE7_DEPLOYED_DTYPE="bfloat16"
export STAGE7_DEPLOYED_KV_DTYPE="auto"
export STAGE7_DEPLOYED_PREFIX_CACHE="true"
export STAGE7_K8S_NAMESPACE="ai-serving"
export STAGE7_K8S_DEPLOYMENT="gpt-oss-20b"
export STAGE7_EXTERNAL_TP=2
./stage7d_k8s_model_revalidation.sh \
night_batch gpt_oss_20b위 값들은 실제 Kubernetes Deployment와 vLLM 실행 설정을 확인한 뒤 입력해야 합니다. 특히 STAGE7_DEPLOYED_* 변수는 운영자 선언값으로 기록되며, 자동으로 검증 완료 처리되지 않습니다.
4. Stage3a·Stage6k 정규화
Stage3a 결과:
python3 stage7_baseline_normalize.py \
--stage stage3a \
--source-dir /logs/stage3a_run \
--model-key gpt_oss_20b \
--tp 2 \
--profile small \
--input-len 4096 \
--output-len 1024 \
--out /logs/stage3a_normalized.jsonStage6k 결과:
python3 stage7_baseline_normalize.py \
--stage stage6k \
--source-dir /logs/stage6k_run \
--metadata /logs/stage6k_run/comparison_metadata.json \
--model-key gpt_oss_20b \
--tp 2 \
--out /logs/stage6k_normalized.json변환 후에는 workload_equivalence_verified가 기본적으로 false입니다.
이는 의도된 동작입니다. 모델 Revision, 입력 분포, 요청 속도, Tokenizer, TP, Serving 옵션 등이 동일한지 확인한 후에만 true로 변경해야 합니다. 또한 원본에 없는 워크로드 메타데이터는 자동 추정하지 않습니다.
5. 자동 비교 및 Evidence 생성
python3 stage7_baseline_compare.py \
--model-key gpt_oss_20b \
--bare-run /logs/stage7_bare \
--k8s-run /logs/stage7_k8s \
--stage3a-metrics /logs/stage3a_normalized.json \
--stage6k-normalized /logs/stage6k_normalized.json \
--out /logs/comparison.json그다음:
python3 stage7_evidence_sync.py \
--template stage7_production_evidence_example.yaml \
--comparison /logs/comparison.json \
--k8s-run /logs/stage7_k8s \
--out /logs/production-evidence-candidate.yaml생성된 YAML에는 비교 결과 상태와 보고서 경로, 확인 가능한 Serving 설정이 포함됩니다.
단, Evidence 생성과 운영 승인 게이트 연결은 구분해야 합니다. 이번 버전은 비교 결과를 Evidence의 baseline_comparison 영역에 기록하지만, 기존 Production Config 생성기의 승인 로직을 변경해 Baseline 비교 PASS를 필수 조건으로 만들지는 않았습니다.
6. 검증 결과 및 남은 제한사항
다음 정적·모의 검사를 수행했습니다.
- Python 구문 검사 및 Bash 구문 검사
- Stage6k 모의 JSON 정규화
- Stage7 Bare-metal/K8s 모의 성능 비교
- Fingerprint 누락 시
REVIEW_REQUIRED처리 - 비교 결과에서 Production Evidence YAML 후보 생성
- 다운로드 패키지 파일 확인
실제 B300 GPU 및 Kubernetes 통합 테스트는 수행하지 않았습니다.
또한 현재 정규화기는 Stage3a/Stage6k의 대표적인 벤치마크 JSON을 처리하지만, 모든 Stage3a 스크립트의 원본 출력 형식을 자동 인식하는 범용 변환기는 아닙니다. 특히 Stage3a3 간섭 통계와 Stage3a8 Prefix Cache A/B는 기존 비교기의 전용 입력 옵션을 계속 사용해야 합니다.
결과적으로 v5에서는 실행 환경 기록 → Baseline 정규화 → 성능·설정 비교 → Evidence 후보 생성까지 연결했습니다. 다만 Kubernetes 실제 설정의 독립 검증, 워크로드 동등성 확인, 최종 운영 승인은 여전히 명시적인 검토가 필요하도록 유지했습니다.
