반응형
🎯 한 줄 결론 먼저
라벨은 “계층별로 의미가 하나씩만” 갖게 표준화하고
MIG 쓰면 Chief / Worker 노드풀은 분리하는 게 정석이다.
1️⃣ GPU 노드 라벨 “표준 계층” (이게 핵심)
라벨은 의미 중복 없이 계층화해야 한다.
✅ Level 1 — 하드웨어 식별 (변하지 않음)
gpu.vendor: nvidia
gpu.model: A100
gpu.mem: 80gb
gpu.model: A100
gpu.mem: 80gb
- 물리 스펙
- 절대 바뀌지 않음
- 모니터링 / 비용 / 통계용
✅ Level 2 — GPU 기능 상태
gpu.mig: enabled # or disabled
- MIG ON / OFF
- 스케줄 정책 분기점
✅ Level 3 — MIG 구성 정책 (중요)
gpu.mig.profile: 1g.10gb
# 또는 3g.40gb
# 또는 3g.40gb
- 노드풀의 “의도”
- 실제 생성된 MIG와 1:1
- Autoscaler 핵심 기준
✅ Level 4 — 노드풀 역할 (운영 로직)
gpu.role: chief # or worker
gpu.pool: train # train / infer / dev
gpu.pool: train # train / infer / dev
- TFJob / 서비스 스케줄 제어
- Chief 보호 핵심
🔥 최종 “운영 표준 라벨 세트”
nodeLabels:
gpu.vendor: nvidia
gpu.model: A100
gpu.mem: 80gb
gpu.mig: enabled
gpu.mig.profile: 1g.10gb
gpu.role: worker
gpu.pool: train
👉 이걸 노드풀 단위로 고정
2️⃣ Chief / Worker 노드풀, 분리하는 게 정답이야?
✔ 결론: 권장 (사실상 정석)
🔹 이유 1 — 안정성
| 항목 | 분리 | 혼합 |
| Chief 보호 | ✅ | ❌ |
| drain 영향 | 최소 | 큼 |
| 장애 전파 | 없음 | 있음 |
🔹 이유 2 — Autoscaler 정확도
- Worker 증가 → Worker 노드풀만 확장
- Chief는 고정
👉 비용 + 예측성 완벽
🔹 이유 3 — MIG 단편화 방지
- Chief: 3g.40gb 고정
- Worker: 1g.10gb 균일
👉 남는 g 없음
🔹 이유 4 — 운영 난이도
- 라벨 기준 명확
- 장애 분석 쉬움
- 표준 문서화 가능
3️⃣ 표준 노드풀 설계 예시 (실전)
🟢 Chief 노드풀
nodeLabels:
gpu.vendor: nvidia
gpu.model: A100
gpu.mem: 80gb
gpu.mig: enabled
gpu.mig.profile: 3g.40gb
gpu.role: chief
gpu.pool: train
gpu.vendor: nvidia
gpu.model: A100
gpu.mem: 80gb
gpu.mig: enabled
gpu.mig.profile: 3g.40gb
gpu.role: chief
gpu.pool: train
- 소수
- autoscaling ❌
🟢 Worker 노드풀
nodeLabels:
gpu.vendor: nvidia
gpu.model: A100
gpu.mem: 80gb
gpu.mig: enabled
gpu.mig.profile: 1g.10gb
gpu.role: worker
gpu.pool: train
gpu.vendor: nvidia
gpu.model: A100
gpu.mem: 80gb
gpu.mig: enabled
gpu.mig.profile: 1g.10gb
gpu.role: worker
gpu.pool: train
- 다수
- autoscaling ✅
4️⃣ TFJob에서 쓰는 표준 Affinity 패턴
Chief
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: gpu.role
operator: In
values: [chief]
- key: gpu.mig.profile
operator: In
values: [3g.40gb]
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: gpu.role
operator: In
values: [chief]
- key: gpu.mig.profile
operator: In
values: [3g.40gb]
Worker
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: gpu.role
operator: In
values: [worker]
- key: gpu.mig.profile
operator: In
values: [1g.10gb]
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: gpu.role
operator: In
values: [worker]
- key: gpu.mig.profile
operator: In
values: [1g.10gb]
5️⃣ “한 노드풀로 다 하면 안 돼?”
기술적으로는 가능
운영적으로는 ❌
“가능”과 “안전”은 다르다
6️⃣ 한 장 요약 (이거 기준으로 문서 만들어도 됨)
[하드웨어] gpu.vendor / model / mem
[기능] gpu.mig
[정책] gpu.mig.profile
[역할] gpu.role / gpu.pool
[기능] gpu.mig
[정책] gpu.mig.profile
[역할] gpu.role / gpu.pool
🧠 최종 결론
GPU 노드 라벨은 “하드웨어 → 기능 → 정책 → 역할”
이 4단 계층으로 표준화하고,
MIG를 쓰는 순간 Chief / Worker 노드풀 분리는 사실상 정석이다.
반응형
'[GPUaaS] > TensorFlow' 카테고리의 다른 글
| [중요3] 운영 표준 - [최종] KServer & NAS & S3 & TFJob.yaml (라벨/MIG/RWO/RWM 적용) (0) | 2026.01.30 |
|---|---|
| [중요2] 운영 표준 - [최종] Train.py & TFJob.yaml (라벨/MIG/RWO 적용) (0) | 2026.01.30 |
| [중요2] 운영 표준 - TFJob.yaml (라벨/MIG/RWO/S3 적용) (0) | 2026.01.28 |
| [중요2] 운영 표준 - ☸️ Kubernetes + TensorFlow 구동 원리 (0) | 2026.01.28 |
| [GPU 타입] 운영 무중단 - 라벨 NodePool 등록 (1) | 2026.01.27 |
| [GPU 타입] 신규 라벨 NodePool 등록 (라벨 + Taint + Affinity 세트) (0) | 2026.01.26 |
| [GPU] Node Affinity + GPU 타입 분리 (A100 / H100) (0) | 2026.01.26 |
| [GPU] requests = limits가 좋은 이유 (0) | 2026.01.26 |
댓글