Part 4: Katib — 하이퍼파라미터 튜닝과 AutoML 퀴즈
이 퀴즈는 Katib의 Experiment/Trial/Suggestion 아키텍처, Katib이 지원하는 탐색 알고리즘, 조기 종료, 메트릭 수집, 그리고 EKS에서 Katib을 운영할 때의 리소스 압박 고려사항에 대한 이해도를 테스트합니다.
객관식 문제
- Katib 아키텍처에서 Experiment, Trial, Suggestion의 관계는 무엇인가요?
- A) 셋 다 같은 CRD를 가리키는 서로 다른 이름일 뿐이다
- B) Suggestion이 여러 Experiment를 소유하고, 각 Experiment는 하나의 Trial을 소유한다
- C) Experiment가 특정 하이퍼파라미터 조합으로 실행되는 여러 Trial을 소유하고, Suggestion 서비스가 그 조합들을 제안한다
- D) Trial이 여러 Experiment를 소유하고, 단일 전역 Suggestion이 이를 조율한다
정답 보기
정답: C) Experiment가 특정 하이퍼파라미터 조합으로 실행되는 여러 Trial을 소유하고, Suggestion 서비스가 그 조합들을 제안한다
설명: Experiment 객체는 튜닝 실행을 기술하며 maxTrialCount는 완료 수에 대한 종료 기준입니다. 성공한 학습 수나 불변 비용 한도가 아닙니다. 각 Trial은 특정 하이퍼파라미터 조합 하나로 실행되는 단일 학습 실행입니다. Suggestion 서비스는 탐색 알고리즘을 구현하며, 과거 관측값을 활용하는 방식은 알고리즘마다 다릅니다.
- 하이퍼파라미터가 목표 메트릭에 어떻게 매핑되는지에 대한 확률 모델을 만들고, 그 모델을 이용해 다음으로 시도할 가장 유망한 지점(들)을 고르는 탐색 알고리즘은 무엇인가요?
- A) 그리드 탐색
- B) 랜덤 탐색
- C) 베이지안 최적화
- D) Hyperband
정답 보기
정답: C) 베이지안 최적화
설명: 베이지안 최적화는 하이퍼파라미터와 목표 값의 관계에 대한 확률 모델을 만들고, 이를 이용해 지금까지 관찰된 최고 결과를 개선할 가능성이 가장 높은 다음 후보(들)를 선택합니다. 랜덤 탐색은 과거 Trial에 대한 기억 없이 독립적으로 샘플링하고, 그리드 탐색은 이산 조합을 모두 나열하며, Hyperband는 작은 예산을 넓게 배분한 뒤 초반 생존자에게 재배분합니다.
- Hyperband는 모든 설정에 동일하고 완전한 학습 예산을 주는 방식과 비교해 어떤 트레이드오프를 취하나요?
- A) 비교하기 전에 모든 설정을 완전히 학습시킨다
- B) 많은 설정에 작은 예산을 주고, 성적이 가장 나쁜 것들을 초반에 걸러낸 뒤, 남은 예산을 생존자들에게 재배분한다
- C) 항상 단 하나의 설정만 시도한다
- D) 중간 성과를 전혀 고려하지 않고 설정을 무작위로 고른다
정답 보기
정답: B) 많은 설정에 작은 예산을 주고, 성적이 가장 나쁜 것들을 초반에 걸러낸 뒤, 남은 예산을 생존자들에게 재배분한다
설명: Hyperband는 설정별로 낱낱이 정보를 얻는 대신 조기 가지치기를 택합니다. 처음에는 많은 설정을 저렴하게 실행하고, 가장 성적이 나빠 보이는 것들을 적극적으로 걸러낸 뒤, 확보된 리소스 예산을 여전히 유망한 설정들에게 넘겨줍니다.
- Experiment 스펙에서
objective필드는 무엇을 정의하나요?- A) 각 Trial을 실행하는 데 사용되는 컨테이너 이미지
- B) 최적화할 메트릭과 이를 최대화할지 최소화할지 여부
- C) 동시에 실행될 수 있는 Trial의 수
- D) 탐색 알고리즘 내부의 하이퍼파라미터
정답 보기
정답: B) 최적화할 메트릭과 이를 최대화할지 최소화할지 여부
설명:objective는 메트릭(예: accuracy 또는 loss)과 목표(최대화 또는 최소화)를 지정하며, 도달 시 Experiment를 조기 종료할 수 있는 목표값을 선택적으로 포함할 수 있습니다. 탐색 공간은 별도로 parameters에서 정의되고, 각 Trial의 잡을 어떻게 실행할지는 trialTemplate에서 정의됩니다.
- 이 장에서 검증한 Katib 0.19.0의 medianstop 임계값 구현은 무엇인가요?
- A) 중간값에 해당하는 Trial이 끝나면 Experiment 전체를 종료한다
- B) 성공 Trial별 첫 start_step 관측값 평균을 저장하고, 그 평균값들의 산술평균으로 임계값을 만든다
- C) 제안된 전체 Trial 중 정확히 절반만 실행하도록 허용한다
- D) 최종 답으로 중앙값에 해당하는 하이퍼파라미터 값을 선택한다
정답 보기
정답: B) 성공 Trial별 첫 start_step 관측값 평균을 저장하고, 그 평균값들의 산술평균으로 임계값을 만든다
설명: 공식 가이드는 중앙값 규칙을 설명하지만 0.19.0 구현은 산술평균을 계산합니다. 로컬에서 성공 Trial 평균값 [1, 2, 100]을 넣으면 약 34.333이 나오며 통계적 중앙값 2와 다릅니다. 기본 min_trials_required=3, start_step=4이고 StdOut/File과 타임스탬프 조건도 확인해야 합니다.
- Katib은 보통 실행 중인 Trial의 학습 컨테이너로부터 목표 메트릭 값을 어떻게 얻어내나요?
- A) 학습 컨테이너가 코드 내부에서 Katib API를 직접 호출해야 한다
- B) 설정된 pull collector로 수집하거나 Push 모드의 report_metrics()로 DB manager에 보고한다
- C) Katib이 컨테이너를 일시 정지시키고 메모리를 직접 조사한다
- D) Kubernetes 스케줄러가 리소스 사용량으로부터 메트릭을 자동으로 추출한다
정답 보기
정답: B) 설정된 pull collector로 수집하거나 Push 모드의 report_metrics()로 DB manager에 보고한다
설명: StdOut/File/TensorFlowEvent와 Custom collector가 있으며 Push 방식도 있습니다. 임의 HTTP scrape는 기본 내장 방식이 아닙니다. Pull 주입에는 namespace label, webhook, 대상 Pod·컨테이너 설정이 필요하고 Job 성공만으로 메트릭 수집 성공이 보장되지 않습니다.
parallelTrialCount를 높게 설정하면 같은maxTrialCount를 낮은 동시성으로 실행할 때보다 EKS 클러스터에 왜 더 급격한 리소스 압박을 주나요?- A)
parallelTrialCount는 생성되는 Pod 수에 영향을 주지 않는다 - B) 동시성이 높으면 많은 Trial(그리고 그에 따른 GPU 등 리소스 요청)이 시간에 걸쳐 분산되지 않고 한꺼번에 클러스터를 때려서, 짧고 급격한 수요 스파이크를 만든다
- C) EKS는 기본적으로
parallelTrialCount를 1로 제한한다 - D) 병렬 Trial들은 항상 같은 노드에서 실행되므로 추가 수요가 발생하지 않는다
- A)
정답 보기
정답: B) 동시성이 높으면 많은 Trial(그리고 그에 따른 GPU 등 리소스 요청)이 시간에 걸쳐 분산되지 않고 한꺼번에 클러스터를 때려서, 짧고 급격한 수요 스파이크를 만든다
설명: 동시에 실행되는 Trial 하나하나가 완전한 학습 잡입니다. 수요는 동시 Trial 수 × Trial당 Pod 수 × Pod당 자원과 collector 등의 오버헤드로 계산해야 하며, 이는 전체 maxTrialCount가 소박해 보이는 Experiment라도 수요를 급격히 치솟게 할 수 있습니다.
- EKS에서
parallelTrialCount가 높게 설정된 Experiment가 시작된 직후, 새로 생성된 Trial Pod들이 한동안 Pending 상태로 머무른다면 어떤 설명이 그럴듯한가요?- A) Suggestion 서비스가 크래시했다
- B) 용량 공급을 기다리는 경우일 수 있지만 Pod 이벤트, NodePool 조건, quota·EC2 용량·부팅 상태로 원인을 확인해야 한다
- C) Katib은 새 Trial마다 항상 고정된 워밍업 기간 동안 일시 정지시킨다
- D) 메트릭 수집 사이드카가 Pod 시작을 막고 있다
정답 보기
정답: B) 용량 공급을 기다리는 경우일 수 있지만 Pod 이벤트, NodePool 조건, quota·EC2 용량·부팅 상태로 원인을 확인해야 한다
설명: Pending만으로 Karpenter가 정상적으로 노드를 만들고 있다고 단정할 수 없습니다. 자원 부족 외에도 affinity, taint, 볼륨, quota, 공급 제한과 부팅 실패가 원인일 수 있습니다. 관측 근거로 구분하세요.
단답형 문제
- Katib이 지원하는 탐색 알고리즘 중 두 가지를 고르고, 각각 어떤 문제에 가장 적합한지 한 문장씩 설명하세요.
정답 보기
정답: 다음 중 두 가지를 선택: 랜덤 탐색(탐색 공간이 크거나 잘 파악되지 않았을 때의 저렴한 베이스라인), 그리드 탐색(차원이 낮고 작은 이산 탐색 공간의 전체 커버리지), 베이지안 최적화(목표 값에 대한 확률 모델을 이용해 각 Trial이 비쌀 때 필요한 전체 Trial 수를 줄임), Hyperband(저렴하고 유용한 초기 신호를 이용해 성적이 나쁜 설정을 조기에 가지치기), CMA-ES(공분산 적응 진화 전략), PBT(체크포인트 공유 등을 요구하는 별도 population-based training).
설명: 각 알고리즘은 탐색 비용과 탐색 효율성 사이의 트레이드오프를 서로 다르게 취하며, 어떤 것이 적합한지는 Trial 하나의 비용과 탐색 공간의 구조에 따라 달라집니다.
- 둘 다 컴퓨트 낭비를 막는 것을 목표로 한다는 점에서, Hyperband가 하는 일과 조기 종료(예: median-stopping rule)가 하는 일의 차이는 무엇인가요?
정답 보기
정답: Hyperband는 각 설정에 얼마의 리소스 예산을 줄지 처음부터 결정하는 탐색 전략이고, 조기 종료는 이미 진행 중인 Trial에 대해 그 시점까지 다른 Trial들과 비교한 성과를 기준으로 적용되는 실행 중 판단입니다.
설명: 두 메커니즘은 서로 다른 층위에서 작동합니다. Hyperband의 가지치기는 탐색 알고리즘의 전체적인 예산 배분 전략의 일부이고, 조기 종료는 설정된 collector·로그 형식과 호환되는 실행 중 Trial에 적용됩니다. 모든 조합에 자동 지원되는 것은 아닙니다.
실습/응용 문제
- 각 Trial이 GPU 1개를 요청하는 Experiment를 설정하고 있고, 클러스터에는 새 용량을 프로비저닝하는 데 보통 몇 분이 걸리는 GPU 인스턴스용 Karpenter NodePool이 있습니다.
maxTrialCount: 60으로 설정했고parallelTrialCount를 얼마로 할지 결정해야 합니다. 이 환경에서 이를 높게(예: 20) 설정하는 것과 낮게(예: 4) 설정하는 것 사이의 트레이드오프를 몇 문장으로 설명하세요.
정답 보기
정답: parallelTrialCount를 높게(예: 20) 설정하면 용량이 충분하면 더 적은 라운드로 처리할 수 있지만, 동시에 20개의 GPU 요청이 급격히 발생해 Karpenter가 GPU 노드를 프로비저닝하는 속도를 앞지를 수 있습니다 — 초기 Trial들이 학습이 아니라 대기 상태로 머무르고, 같은 GPU NodePool을 다른 워크로드와 공유한다면 클러스터 용량에 스파이크를 일으킬 수도 있습니다. 낮게(예: 4) 설정하면 같은 60개의 Trial을 더 많은 라운드에 걸쳐 분산시켜, Karpenter가 점진적으로 프로비저닝할 시간을 벌어주고 용량 스파이크 위험을 줄이지만, maxTrialCount에 도달하기까지 전체 소요 시간이 늘 수 있습니다. 실제 시간과 비용은 자원 가용성, 작업 길이, 실패·종료·노드 회수에 따라 달라집니다.
설명:parallelTrialCount와 maxTrialCount는 독립적인 설정이 아니라 클러스터의 오토스케일링 동작을 고려해 함께 튜닝해야 합니다 — 특히 Trial들이 GPU처럼 희소하거나 프로비저닝이 느린 리소스를 요청할 때는 더욱 그렇습니다.