26O05c3

QK·5일 전

수정했습니다. 이번 버전은 6k/summary 개선 + Stage1/2/3a/6 공통 환경변수화를 같이 적용했습니다.

b300_validation_common_env_v4.tar.gz전체 패키지 다운로드

핵심은 validation_env.shvalidation_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.mdREADME_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가 모두 나쁘다면 그 결과도 그대로 드러납니다.

Gate 범위

기본 gate_criteria.yaml은 이제 초기 B300 acceptance 전용 v2 profile입니다.

CORE / hard acceptance
 ├─ Stage1   HW integrity
 ├─ Stage2   Network + Local NVMe
 ├─ Stage3a  vLLM short/long basic
 ├─ Stage6a  K8s NCCL measured
 ├─ Stage6b  K8s network measured
 ├─ Stage6c  GPU topology
 └─ Stage6k  K8s vLLM short/long measured

Conditional / characterization
 ├─ Stage2c
 ├─ Stage3a6
 ├─ Stage3a8
 └─ Stage3a10
      ├─ none
      ├─ local_nvme
      └─ remote_obj

Stage3a5와 Stage4는 기본 acceptance gate에서 제거했습니다. 기존 설정은 누락 데이터 기본값이 fail이었고 gate_criteria Stage3a5도 hard gate에 포함되어 있었기 때문에 gate_criteria 현재 범위와 충돌했는데, 이 부분이 해결됐습니다.

KV tier

Stage3a10에서는 이제 다음 metric을 자동 추출합니다.

kvtier_none_max_concurrency
kvtier_none_peak_rps

kvtier_local_nvme_max_concurrency
kvtier_local_nvme_peak_rps
kvtier_local_nvme_capacity_vs_none_pct
kvtier_local_nvme_peak_rps_vs_none_pct

kvtier_remote_obj_max_concurrency
kvtier_remote_obj_peak_rps
kvtier_remote_obj_capacity_vs_none_pct
kvtier_remote_obj_peak_rps_vs_none_pct

중요하게도 remote OBJ가 local NVMe보다 반드시 빨라야 PASS라는 식으로 만들지 않았습니다. capacity 증가와 throughput cost를 각각 보여주고 soft warning으로 판단합니다.

Stage6

Stage6도 summary Markdown을 재파싱하지 않고 raw 결과를 직접 읽습니다.

6a는 measured NCCL 존재 여부가 hard gate이고 Stage1 대비 bandwidth delta는 soft warning입니다. 6b는 Pod-to-Pod 결과 존재가 hard gate이고 Stage2 대비 성능 차이는 soft warning입니다.

6c는 특히 수정했습니다. 기존처럼 전체 nvidia-smi topo -m 파일에서 PHB|SYS를 grep하면 Legend의 설명까지 잡힐 수 있기 때문에, 이제 GPU-to-GPU matrix cell에 있는 PHB/SYS만 계산합니다.

6k는 다음을 hard gate로 봅니다.

performance_ready_at.txt 존재
short c64 benchmark 완료
long c8 benchmark 완료

Stage3a bare-metal 대비 short/long TTFT와 output TPS 차이는 soft warning입니다.

Hard FAIL과 WARN도 분리

성능 차이가 threshold를 벗어나도 이제 화면에 FAIL이라고 표시하지 않습니다.

hard_fail 기준 위반 → FAIL → exit 1
soft_warn 기준 위반 → WARN → exit 0
optional 미실행       → SKIP → exit 영향 없음

따라서 계약상의 절대 성능 기준이 아직 확정되지 않은 현재 acceptance에 더 적합합니다.

실행은:

source ./validation_env.sh

python3 regression_gate.py \
  --base-dir "$VALIDATION_ROOT" \
  --out "$VALIDATION_ROOT/acceptance_gate.md" \
  --json-out "$VALIDATION_ROOT/acceptance_gate.json"

장기 regression baseline도 그대로 지원합니다.

python3 regression_gate.py \
  --base-dir "$VALIDATION_ROOT" \
  --save-baseline baseline.json

이후:

python3 regression_gate.py \
  --base-dir "$VALIDATION_ROOT" \
  --baseline baseline.json

으로 비교할 수 있습니다.

전체 shell script에 bash -n, Python 전체에 py_compile, YAML parsing까지 다시 확인했습니다. regression_gate_metrics.py의 원래 역할처럼 사람이 읽는 summary와 별도로 숫자를 gate용으로 추출하는 구조도 유지했습니다. regression_gate_metrics

완료했습니다. 첨부한 Stage3b~5 스크립트 전체를 기존 v7 공통 환경에 맞추고, 개선사항까지 반영해 v8로 묶었습니다.

b300_validation_common_env_v8.tar.gz전체 B300 Validation v8 패키지

:chatgpt-content-reference{index="11"}Deferred/Extended 단계 가이드
:chatgpt-content-reference{index="12"}변경 내역

주요 수정은 다음과 같습니다.

Stage3b Triton/TRT-LLM
- validation_env.sh 연동
- Triton/SDK image, model repository, ports를 공통 변수화
- genai-perf 실패를 || true로 숨기던 동작 제거. 기존에는 실제 benchmark 실패도 계속 진행될 수 있었습니다. stage3b_genai_perf_runner
- 24.08 이미지는 승인된 B300 조합으로 간주하지 않고 버전 검증 대상으로 유지했습니다. 원본 자체가 NGC TRT-LLM 컨테이너 내부 빌드를 전제로 합니다. stage3b_triton_trtllm_benchmark
Stage3c SGLang
- SGLANG_VENV, 공통 모델/로그/포트 사용
- benchmark 실패를 정상 완료처럼 처리하지 않도록 변경
- GPT-OSS/FP4는 optional 유지
- --quantization fp4 등은 SGLang 설치 버전 의존 항목으로 명시했습니다.
Stage3d AIPerf
- AIPERF_VENV 적용 및 binary fail-fast
- primary AIPerf benchmark 실패를 숨기지 않도록 변경
- 원래도 Triton native 옵션은 AIPerf 버전에 따라 미지원일 수 있다고 되어 있으므로 stage3d_aiperf_unified_benchmark 이 부분은 genai-perf fallback 대상으로 유지했습니다.
Stage4 Training
- TRAIN_VENV, MODEL_70B, TRAIN_DATA_DIR, TRAIN_OUTPUT_ROOT, MINIO_* 공통화
- MinIO endpoint/access/secret 하드코딩 기본값 제거. 원본에는 기본 credentials가 있었습니다. stage4_run_train_benchmark
- MinIO가 설정되지 않으면 remote_s3만 SKIP
- DeepSpeed 결과와 실제 LoRA final artifact 저장
- FSDP2에 DistributedSampler 추가
- FSDP2에도 gradient accumulation=2를 적용해 DeepSpeed와 effective global batch를 맞춤
- 결과 파일을 각 Stage4 LOG_DIR 안에 직접 생성하도록 정리

특히 FSDP2와 DeepSpeed의 기존 비교 조건이 동일하지 않았던 점을 수정했습니다. DeepSpeed는 gradient accumulation=2를 사용하고 있었지만 stage4_train_benchmark_deepspeed FSDP2는 단순 per-device batch × world-size만 사용하고 있었습니다. stage4_train_benchmark_fsdp2

Stage5a
- 공통 MinIO/model/NVMe 경로 적용
- 설치된 mc 버전에 따라 문제가 될 수 있는 mc mirror --threads 16 가정 제거. 원본은 이를 고정하고 있었습니다. stage5a_model_cold_load
Stage5b
- model name 공통화
- JSON summary 출력 추가
- TLS 검증을 기본 활성화
- 인증서 검증 해제는 명시적인 --insecure에서만 가능
Stage5c
- 가장 중요한 오류 중 하나를 수정했습니다.
- checkpoint가 없을 때 가짜 500MB safetensors를 만드는 동작 제거. 원본은 실제 checkpoint가 없어도 이를 생성했습니다. stage5c_checkpoint_lifecycle
- 이제 실제 checkpoint가 없으면 FAIL
- MinIO 업로드 후 remote object listing 확인
- /v1/models HTTP 200은 reload 성공을 뜻하지 않는다고 명시
- 기본 checkpoint는 Stage4가 만든 ${TRAIN_OUTPUT_ROOT}/lora/final
Stage5d
- vLLM 0.29 환경과 같은 VLLM_BIN serve 사용
- vLLM/training 각각 지정된 venv binary 사용
- 4-GPU training에 --num_gpus 4 전달
- 따라서 기존에 4 GPU를 사용하면서 MFU 계산은 8 GPU 기준으로 할 수 있던 문제를 해결했습니다. 원본의 co-tenancy 구조 자체는 GPU 0–3/4–7 분할입니다. stage5d_co_tenancy_test
Stage5e
- latest 이미지 제거
- image를 validation_env.sh에서 pin
- Docker 전용 runtime: nvidia 대신 Podman/CDI 방향으로 변경
- bare-metal monitoring 검증과 Stage6 K8s observability를 분리했습니다. 원본은 docker compose, latest 이미지와 NVIDIA runtime을 전제로 했습니다. stage5e_monitoring_setup

validation_env.sh에는 이제 추가로 TRAIN_VENV, SGLANG_VENV, AIPERF_VENV, Triton image/repository/ports, MinIO bucket/prefix, training paths, Prometheus/Grafana/DCGM exporter image 변수가 들어갑니다.

00_compatibility_check.sh에도 Deferred 단계용 podman, aws, mc, sar, 각 venv 및 training Python module 검사를 추가했습니다.

다만 추후 실제 Stage3b~5를 실행하기 직전 한 번 더 버전 호환성 audit을 하는 것이 필요합니다. 특히 TensorRT-LLM/Triton image, trtllm-build 옵션, SGLang FP4, AIPerf CLI, PyTorch FSDP2 API는 vLLM 0.29처럼 현재 버전을 이미 고정해서 확인한 영역과 달리 설치 버전에 민감합니다. Stage4의 70B ZeRO-3 초기 모델 loading memory behavior도 실제 설치한 Transformers/DeepSpeed 조합에서 먼저 작은 smoke run으로 확인하는 것을 권장하도록 문서에 남겼습니다.

마지막으로 전체 .sh에 bash -n, 전체 .py에 py_compile, YAML parsing을 다시 수행해 모두 통과했습니다.

engineer

이전 포스트

26O05c2

다음 포스트