26O13a

QK·3일 전

Stage6 v4 패키지에 포함된 두 스크립트는 **기본 성능 재검증용(v1)**과 **Stage3a 최신 검증 항목을 확장한 버전(v2)**이라는 차이가 있습니다.

기능 비교

검증 항목_v1.sh기본 파일 (v2)
Kubernetes vLLM Pod 상태 확인OO
Engine Warm-upOO
Short/Long 기본 성능OO
Mixed WorkloadXO
AB/BA CrossoverXO
Prefill에 의한 TTFT 간섭XO
Saturation / 동시성 테스트XO
Prefix Cache 검증XO
KV Cache 사용률 분석XO
테스트 모드 선택고정STAGE6K_TESTS

각 스크립트의 역할

1. stage6k_k8s_vllm_performance_revalidation_v1.sh

Stage3a에서 확인한 기본 추론 성능이 Kubernetes 환경에서도 유지되는지 확인하는 용도입니다.

주로 기본 TTFT, ITL, TPS를 측정하는 비교적 단순한 검증입니다.

2. stage6k_k8s_vllm_performance_revalidation.sh

Stage3a3, Stage3a6, Stage3a8에서 보강한 테스트를 Kubernetes 환경에서 재검증하는 확장 버전입니다.

export STAGE6K_TESTS=basic,mixed,saturation,prefix,kv
./stage6k_k8s_vllm_performance_revalidation.sh

이렇게 실행하면 기본 성능뿐 아니라 Mixed Workload, Prefix Cache, KV Cache 관련 테스트도 함께 수행하도록 구성한 버전입니다.

권장

현재 B300 + vLLM 0.31.0 + Kubernetes 환경에서는 stage6k_k8s_vllm_performance_revalidation.sh를 주력으로 사용하고, _v1.sh는 과거 측정 결과와의 호환성 확인용으로 보관하는 것이 좋습니다.

단, v2의 Prefix Cache 검증은 현재 실행 중인 서버의 설정을 관측하는 방식입니다. Stage3a8처럼 enable_prefix_caching=True/False로 서버를 각각 재시작하는 완전한 A/B 테스트와는 다릅니다.

참고: 이 비교는 앞서 구성한 Stage6 v4의 기능 구분을 기준으로 한 것입니다. 이번 답변에서 두 파일의 실제 소스 코드를 다시 대조한 것은 아닙니다.

==

확인해 보니, 두 파일은 서로 다른 목적의 독립 테스트라기보다 Stage6k의 구버전(v1)과 확장 버전(v2) 관계입니다.

  • stage6k_k8s_vllm_performance_revalidation_v1.sh: Stage3a 성능 기준선을 Kubernetes 환경에서 재검증하는 기본 버전
  • stage6k_k8s_vllm_performance_revalidation.sh: Stage3a3·3a6·3a8에서 보강한 Mixed Workload, Saturation, Prefix Cache 검증까지 포함한 확장 버전

최신 Stage6 v4 패키지에는 두 파일이 모두 들어 있습니다.

기능 비교

구분_v1.sh기본 파일 (v2)
Kubernetes Deployment Ready 확인지원지원
vLLM Engine Warm-up지원지원
Short/Long 기본 성능지원지원
Mixed Workload없음AB/BA 교차 검증
Prefill 간섭 분석없음TTFT degradation 측정
Saturation없음동시성별 성능 측정
Prefix Cache없음Hit Rate 및 TTFT 측정
KV Cache없음별도 테스트 모드
테스트 선택고정STAGE6K_TESTS
결과 형식기본 JSON테스트별 JSON/CSV

어떤 것을 실행해야 하나?

현재 환경에서는 기본 파일(v2)을 사용하는 것이 맞습니다. Stage3a 최신 검증 방향을 반영했기 때문입니다.

전체 기본 테스트:

export STAGE6K_TESTS=basic,mixed,saturation,prefix
./stage6k_k8s_vllm_performance_revalidation.sh

KV 테스트까지 포함하려면:

export STAGE6K_TESTS=basic,mixed,saturation,prefix,kv
./stage6k_k8s_vllm_performance_revalidation.sh

다만 확인된 구현상 주의점이 있습니다. v2의 STAGE3_BASELINE_DIR은 결과 메타데이터에 기록되지만, Stage3a 대비 성능 저하율을 자동으로 계산하는 기능은 확인되지 않습니다. 또한 Prefix Cache 테스트는 기존 서버 설정을 관측하며, OFF/ON 서버를 자동으로 재배포하지 않습니다.

따라서 운영 기준으로는 v2를 주력으로 사용하고 v1은 이전 결과와의 호환성 확인용으로 보관하는 구성을 권장합니다.

===

현재 Stage3a 수정사항을 기준으로 Stage6 스크립트를 검토하고, 필요한 부분을 반영해 Stage6 전용 패키지로 묶었습니다.

Stage6 v4 전체 스크립트 다운로드 (.tar.gz)

주요 수정 내용

Stage3a 변경사항Stage6 반영
Stage3a3 AB/BA CrossoverStage6k에서 5회 실행, 첫 1회 제외
Short/Long Prefill 간섭Mixed 워크로드 TTFT 비교 유지
Scheduler/KV 압박 분석Mixed 실행 중 /metrics 수집 추가
Stage3a8 Prefix CachevLLM 0.31.0 메트릭 이름 및 _total 지원
Prefix Cache Warm 검증Cold 이후 Warm 구간의 Hit Rate 계산
Stage3a6 Saturation동시성별 TTFT/ITL/TPS 및 KV 사용률 비교
Stage3a 결과 요약Stage6 Summary에서 테스트 모드별 결과 분석

특히 기존 Stage6k의 결과 디렉터리 이름과 Summary 파서가 일치하지 않는 문제도 수정했습니다.

유지한 구성

Stage6a~6j의 NCCL, 네트워크, GPU Topology, Spark, AIStor, 장애 복구, Cilium/ClusterMesh 검증은 기존 구조를 유지했습니다.

worker와 clustermesh 프로파일도 그대로 지원합니다.

실행 전 주의사항

Stage6k는 Kubernetes에 이미 배포된 vLLM을 검증합니다. 따라서 Prefix Cache OFF/ON의 완전한 A/B 비교는 각각 다른 설정으로 서버를 재시작해야 합니다. 현재 Stage6k의 Prefix 테스트는 실행 중인 서버 설정에 대한 관측 테스트입니다.

또한 기존 공통 파일인 validation_env.sh와 stage3a_warmup_lib.sh가 필요하며, 이번 Stage6 전용 패키지에는 포함하지 않았습니다.

검증 상태: 전체 Shell 구문 검사, Python 컴파일 검사, Summary 기본 실행 검사를 통과했습니다. 실제 B300/Kubernetes 환경의 통합 실행은 아직 검증하지 않았습니다.

===

Stage3a 최신 변경사항과 Stage6 v4를 기준으로 검토하면, Stage7도 보완할 부분이 있습니다.

항목Stage7 반영 권장사항
Mixed WorkloadShort/Long 요청 간 TTFT 간섭 측정
CrossoverAB/BA 교차 검증 4개 유효 Round 이상
Scheduler/KVPrefill 경합과 KV Cache 압박 구분
Prefix CachevLLM 0.31.0 메트릭 및 OFF/ON 비교
FP8 품질BF16 대비 모델별 품질 차이 검증
Saturation모델별 동시성·TPS·TTFT·ITL 최적값 산출
K8s 연계Stage6 환경에서 성능 재현성 확인

다만 현재 작업 공간을 확인한 결과, Stage7 원본 스크립트가 없습니다. Stage3a와 Stage6 파일은 확인되지만 Stage7 기존 파일을 찾을 수 없어, 원래 기능을 유지하면서 수정했다고 보장할 수 없습니다.

기존 Stage7 스크립트 묶음(.tar.gz 또는 .zip)을 올려주시겠어요?

올려주시면 기존 구조를 유지하면서 필요한 항목만 수정하고, Bash/Python 구문 검사까지 수행한 후 Stage7만 포함한 다운로드 패키지로 제공하겠습니다.

===

업로드하신 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는 업로드 파일에 없으므로 패키지에 포함하지 않았습니다.

profile
engineer

0개의 댓글