26O05c3

About this offer

수정했습니다. 이번 버전은 6k/summary 개선 + Stage1/2/3a/6 공통 환경변수화 를 같이 적용했습니다. b300_validation_common_env_v4.tar.gz 전체 패키지 다운로드 핵심은 validation_env.sh validation_env.sh 입니다. 이제 기본 경로는 여기서 한 번만 설정하면 됩니다. VALIDATION_ROOT=/var/log/b300_validation LOCAL_CACHE_DIR=/mnt/local-nvme-cache LOCAL_MODEL_ROOT=${LOCAL_CACHE_DIR}/models HF_HOME=${LOCAL_CACHE_DIR}/huggingface VLLM_VENV=${HOME}/vllm-bench-env PYTHON_BIN=${VLLM_VENV}/bin/python3 VLLM_BIN=${VLLM_VENV}/bin/vllm MODEL_70B=${LOCAL_MODEL_ROOT}/Meta-Llama-3.1-70B-Instruct MODEL_8B=${LOCAL_MODEL_ROOT}/Meta-Llama-3.1-8B-Instruct MODEL_DEEPSEEK=${LOCAL_MODEL_ROOT}/DeepSeek-R1 MODEL_NAME=llama-3.1-70b NAMESPACE=gpu-validation 따라서 서버마다 경로가 다르면 개별 Stage 스크립트를 수정하지 않고 validation_env.sh 만 변경하면 됩니다. 실행 전에 export MODEL_70B=... 처럼 지정하면 그 값이 공통 파일의 기본값보다 우선합니다. 6k도 수정했습니다 :chatgpt-content-reference{index="2"} 수정된 stage6k 이제 임의 STAGE3_BENCH_CMD 방식 대신 Stage3a와 같은 vllm bench serve --save-result 구조로 고정했습니다. K8s Ready ↓ API Ready ↓ Engine warm-up ↓ Short c64 workload warm-up ↓ dense70b_bf16_short_c64.json ↓ Long c8 workload warm-up ↓ dense70b_bf16_long_c8.json 즉 Stage3a와 Stage6k가 같은 이름과 같은 JSON 포맷을 사용합니다. Summary도 수정했습니다 :chatgpt-content-reference{index="3"} 수정된 stage6_summary_report.py 이제 STAGE3_BASELINE_DIR 를 지정하면 자동으로 다음 비교가 가능합니다. Metric Stage3 bare-metal Stage6 K8s Delta ---------------------------------------------------------------- Short c64 TTFT Short c64 ITL Short c64 Output TPS Long c8 TTFT Long c8 ITL Long c8 Output TPS NCCL bandwidth Network throughput 예를 들어: export STAGE3_BASELINE_DIR=/var/log/b300_validation/stage3a_vllm_20261003_120000 ./stage6k_k8s_vllm_performance_revalidation.sh python3 stage6_summary_report.py \ --base-dir "${VALIDATION_ROOT}" \ --print 6k가 comparison_metadata.json 에 Stage3 baseline 위치까지 기록하므로 이후 summary를 다시 실행해도 비교할 수 있습니다. 공통 환경 적용 범위 이번 패키지에서는 현재 인수검증에 관계있는 Stage1, Stage2, Stage3a 계열, Stage6 전체 shell script 에 공통 환경 로딩을 적용했습니다. 기존처럼 각 스크립트에 있던: LOG_DIR="/var/log/b300_validation/..." source ~/vllm-bench-env/bin/activate LOCAL_MODEL_ROOT="/mnt/local-nvme-cache/models" HF_HOME="/mnt/local-nvme-cache/huggingface" 같은 경로 의존성을 없애고 공통 설정을 참조합니다. 특히 로그는 전부: ${VALIDATION_ROOT}/stage1_... ${VALIDATION_ROOT}/stage2_... ${VALIDATION_ROOT}/stage3a_... ${VALIDATION_ROOT}/stage6a_... ... ${VALIDATION_ROOT}/stage6k_... 형태가 됩니다. 공통 환경 사용법은 README_COMMON_ENV.md README_COMMON_ENV.md 에 같이 넣었습니다. 모든 수정 .sh 에 대해 bash -n , summary에 대해 Python compile 및 빈 결과 디렉터리 smoke test까지 통과했습니다. 한 가지 추가로 권하는 구조는 validation_env.sh 자체를 소스 트리 밖 /etc/b300-validation/validation_env.sh 같은 곳에 두고 VALIDATION_ENV_FILE 로 지정하는 것 입니다. 그러면 앞으로 스크립트 패키지를 새 버전으로 통째로 교체해도 서버별 모델/venv/log 경로 설정을 덮어쓰지 않게 됩니다. 네. vLLM 0.29.0 기준으로 현재 Stage3a/6k의 핵심 benchmark CLI는 호환됩니다. 공식 v0.29.0 문서에서 vllm bench serve 와 우리가 쓰는 주요 옵션들을 직접 대조했습니다. vLLM 확인 결과는 다음과 같습니다. 사용 항목 vLLM 0.29.0 판단 vllm bench serve 지원 OK --backend openai-chat 지원 OK --endpoint /v1/chat/completions 지원 OK --host , --port 지원 OK --model , --tokenizer 지원 OK --dataset-name random 지원 OK --random-input-len 지원 OK --random-output-len 지원 OK --random-range-ratio 지원 OK --random-prefix-len 지원 OK --num-prompts 지원 OK --max-concurrency 지원 OK --request-rate 지원 OK --num-warmups 지원, default 0 OK --save-result 지원 OK --result-dir 지원 OK --result-filename 지원 OK --enable-prefix-caching 지원 OK --no-enable-prefix-caching 지원 OK 특히 우리가 별도 warm-up을 구현하면서 built-in --num-warmups 를 0으로 두는 구조도 0.29.0 CLI와 맞습니다. vLLM Prefix caching 옵션 역시 v0.29.0 engine args에 존재합니다. vLLM 다만 vLLM보다 오히려 주변 도구들의 버전 고정이 더 중요 합니다. NCCL tests는 -b/-e/-f/-g 가 현재 NVIDIA nccl-tests에 존재하고, 더 좋은 점은 nccl-tests 자체에 -w/--warmup_iters 와 -n/--iters 가 있다는 것입니다. GitHub 따라서 우리가 Stage6a에서 별도 warm-up run을 하나 버리는 방식보다, Stage1과 Stage6a 모두 동일한 nccl-tests 버전을 고정한 뒤 -w N -n N 을 명시적으로 동일하게 주는 방식이 더 정확 합니다. 이 부분은 Stage1/6a를 한 번 더 수정하는 게 좋겠습니다. Stage6b의 iperf3 -P ... -J 도 일반적인 현재 iperf3와 호환됩니다. 그리고 warm-up 관점에서는 iperf3 자체에 -O/--omit 가 있어 TCP slow-start 구간을 측정에서 제외할 수 있습니다. ESnet Software 따라서 Stage6b도 예를 들어 -O 3 -t 15 + 3회 반복 median 으로 바꾸는 편이 현재 단일 10/15초 실행보다 더 재현성이 좋습니다. Cilium 쪽도 확인이 필요합니다. 특히 6g에서 사용하는 cilium clustermesh connect/disconnect --destination-context 는 현재 CLI에 존재하지만, Cilium CLI 버전에 따라 동작을 확인해야 합니다. 현재 공식 문서에서도 connect --destination-context 가 지원됩니다. Cilium 문서 그리고 하나 더 중요한 게 vLLM /metrics 이름 입니다. Stage3a가 /metrics 에서 vllm:time_to_first_token_seconds 와 vllm:inter_token_latency_seconds 를 직접 파싱하는 부분은 CLI 호환성과 별개입니다. vLLM 버전에 따라 Prometheus metric 이름/label 구조가 바뀔 수 있으므로 이 부분은 실제 0.29.0 서버에서: curl -s http://127.0.0.1:8000/metrics \ | grep -E 'time_to_first_token|inter_token|request|cache' 로 사전검증하는 게 좋습니다. 다행히 benchmark JSON 자체의 TTFT/ITL/TPS가 주 측정값이고 /metrics 는 교차검증 용도라서, metric 이름이 달라도 benchmark 전체가 깨지도록 만들 필요는 없습니다. 그래서 지금 패키지에 00_compatibility_check.sh 같은 preflight를 하나 추가하는 것을 권합니다. 실제 서버에서 테스트 시작 전에 vllm --version == 0.29.0 , 필요한 vllm bench serve --help 옵션 존재 여부, all_reduce_perf 의 -w/-n 지원, iperf3 -O/-J/-P , kubectl , cilium , hubble , mc , Python/venv, 모델/tokenizer 경로, vLLM metrics 이름까지 자동 검사해서 PASS/WARN/FAIL 리포트를 만들게 하면 이후 스크립트 실행 중 CLI 버전 때문에 깨지는 일을 상당히 줄일 수 있습니다. 그리고 그 작업과 함께 Stage1/Stage6a NCCL을 -w/-n 명시 방식으로 통일하고 Stage6b를 iperf3 -O + 반복 median 방식으로 수정 하는 게 지금 가장 가치 있는 다음 수정입니다. 만들었습니다. 00_compatibility_check.sh 는 실제 설치된 바이너리의 --help 와 버전을 검사하도록 구성했습니다. :chatgpt-content-reference{index="4"} 00_compatibility_check.sh b300_validation_common_env_v5.tar.gz 공통 환경 포함 최신 전체 패키지 주요 검사항목은 다음과 같습니다. vLLM 설치 버전 확인 기대 버전 기본값 0.29.0 vllm bench serve 존재 openai-chat random dataset 관련 옵션 concurrency/request-rate --num-warmups --save-result , --result-dir , --result-filename prefix 관련 옵션 Python/venv VLLM_VENV PYTHON_BIN Python version vLLM import 공통 경로 VALIDATION_ROOT LOCAL_MODEL_ROOT HF_HOME MODEL_70B GPU nvidia-smi GPU 8장 인식 여부 topology 명령 NCCL tests all_reduce_perf -b/-e/-f/-g -w/--warmup_iters -n/--iters Network iperf3 -J -P -O/--omit K8s kubectl cilium hubble mc 선택 도구는 없는 경우 WARN Air-gap HF_HUB_OFFLINE TRANSFORMERS_OFFLINE HF_DATASETS_OFFLINE vLLM 0.29.0에서 bench serve , --num-warmups , --save-result , --result-dir , --result-filename , random dataset 및 concurrency 관련 옵션이 공식적으로 제공되는 것도 확인했습니다. vLLM NCCL tests의 -w 와 -n 도 공식 프로젝트에서 각각 untimed warm-up과 measured iterations 용도로 제공됩니다. GitHub iperf3 -O 역시 slow-start 구간을 측정에서 제외하는 공식 옵션입니다. ESnet Software 실행은 간단합니다. ./00_compatibility_check.sh 또는 공통 환경 파일을 외부에 뒀다면: export VALIDATION_ENV_FILE=/etc/b300-validation/validation_env.sh ./00_compatibility_check.sh 결과는 ${VALIDATION_ROOT}/compatibility_<timestamp>/ 아래에 compatibility_report.md 와 상세 command 출력으로 남게 했습니다. 판정은 FAIL이 하나라도 있으면 exit 1 , WARN만 있으면 exit 0입니다. 따라서 실제 acceptance 시작 전에 다음처럼 gate로 쓰는 것을 권장합니다. ./00_compatibility_check.sh || exit 1 ./stage1_hw_validation.sh ./stage2_net_storage_validation.sh # ... 특히 이 preflight를 넣었으므로 다음에 Stage1/6a의 NCCL을 -w/-n 으로 통일하거나 Stage6b를 iperf3 -O 방식으로 변경하더라도, 실제 설치 버전이 해당 옵션을 지원하는지 실행 전에 자동 확인 할 수 있습니다. 맞습니다. 이전 답변에서 실제 파일이 생성되지 않은 상태로 링크를 드렸습니다. 이번에는 실제 생성 여부와 bash -n 구문 검사까지 확인했습니다. :chatgpt-content-reference{index="0"} 00_compatibility_check.sh :chatgpt-content-reference{index="1"} validation_env.sh b300_compatibility_check_v1.tar.gz 두 파일 묶음 tar.gz 실행은 두 파일을 같은 디렉터리에 둔 뒤: chmod +x 00_compatibility_check.sh ./00_compatibility_check.sh 하면 됩니다. validation_env.sh 가 같은 디렉터리에 있으면 자동으로 읽습니다. 별도 위치라면: VALIDATION_ENV_FILE=/etc/b300-validation/validation_env.sh \ ./00_compatibility_check.sh 로 실행할 수 있습니다. 이번 파일은 인터넷 연결 없이 현재 서버에 실제 설치된 vLLM 0.29.0의 --help , nccl-tests, iperf3, GPU, Python/venv, 모델 경로, kubectl/Cilium/Hubble 등을 직접 검사 하도록 되어 있습니다. 가능해서 추가 수정했습니다. 이번에는 빠졌던 Stage2c 2개 + Stage3a5 2개 + Stage3a10 2개 를 공통 패키지에 다시 포함했고, 기존 수정본과 동일한 validation_env.sh 구조에 맞췄습니다. b300_validation_common_env_v6.tar.gz 전체 v6 패키지 주요 변경점 Stage2c 는 VALIDATION_ROOT , PYTHON_BIN , MemKV 관련 공통 변수를 사용합니다. 기존처럼 실행 중 인터넷으로 pip install 하지 않고, 의존성이 없으면 fail-fast하도록 변경했습니다. Wire benchmark에는 측정에서 제외되는 object-store warm-up도 추가했습니다. Stage3a5 도 VLLM_VENV , HF_HOME , MODEL_70B , VALIDATION_ROOT 를 공통 환경에서 가져옵니다. prefetch_eval_datasets.py 는 staging PC용이라는 성격은 그대로 유지하면서 HF_HOME 을 기본값으로 받을 수 있게 했습니다. Stage3a10은 꽤 크게 수정했습니다. vLLM 0.29 계열 KV offloading 구조에 맞춰 다음 세 조건으로 명확히 분리했습니다. none └─ GPU KV only / secondary tier 없음 local_nvme └─ GPU ↕ CPU primary tier ↕ Local NVMe filesystem tier remote_obj └─ GPU ↕ CPU primary tier ↕ Remote MinIO/MemKV S3-compatible object tier vLLM offloading에서 secondary tier는 CPU primary tier를 통해 GPU와 데이터를 주고받는 구조입니다. vLLM 또한 v0.29.0의 OBJ 설정에는 bucket, endpoint, credentials 등을 담는 object-store configuration이 제공됩니다. vLLM 기존 3a10에서 빠져 있던 다음 설정도 보완했습니다. { "kv_connector": "OffloadingConnector", "kv_role": "kv_both", "kv_connector_extra_config": { "spec_name": "TieringOffloadingSpec" } } 그리고 단순 TTFT 비교가 아니라 concurrency sweep으로: RAG_CONCURRENCIES=8,16,32,64 tier max usable C peak RPS TTFT P50 TTFT P99 error none local_nvme remote_obj 를 측정합니다. 그래서 원하는 성능 이점과 capacity 이점을 분리해서 확인 할 수 있습니다. 예를 들어 remote tier가 NVMe보다 TTFT는 조금 느리지만: none max C=16 local_nvme max C=32 remote_obj max C=64 처럼 높은 부하까지 안정적으로 처리한다면, latency 개선이 아니라 KV capacity 확장 측면의 이점 으로 볼 수 있게 했습니다. 반대로 remote OBJ가 NVMe보다 처리량·latency·수용 concurrency가 모두 나쁘다면 그 결과도 그대로 드러납니다. 관련 파일은: :chatgpt-content-reference{index="7"} stage3a10 비교 스크립트 :chatgpt-content-reference{index="8"} stage3a10 부하 클라이언트 :chatgpt-content-reference{index="9"} Stage2c wire benchmark :chatgpt-content-reference{index="10"} Stage2c client :chatgpt-content-reference{index="11"} Stage3a5 quality :chatgpt-content-reference{index="12"} Stage3a5 prefetch 그리고 00_compatibility_check.sh 00_compatibility_check.sh 에도 aiohttp , numpy , minio , lm_eval 및 vLLM OBJ tier module 확인을 추가했습니다. stage3a_summary_report.py stage3a_summary_report.py 도 패키지에서 누락되어 있던 것을 복구했고, Stage3a10의 capacity_summary.json 을 읽을 수 있도록 추가했습니다. 추가로 올려주신 regression gate도 같이 패키지에 넣었습니다. 현재 gate 설정은 데이터 누락 기본값이 fail 이고, gate_criteria Stage3a5가 여전히 hard-fail 기준에 포함되어 있습니다. gate_criteria 따라서 현재 acceptance 범위와 최종 gate 기준을 다시 맞추는 작업 은 별도로 하는 것이 좋습니다. regression_gate_metrics.py 도 현재 Stage3a6에서 이미 none/fs/memkv saturation 값을 추출하는 구조라, regression_gate_metrics 다음에는 이것