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 CRD는 하나의 튜닝 실행을 기술하며, 전체 수명 동안 최대 maxTrialCount개의 Trial을 소유합니다. 각 Trial은 특정 하이퍼파라미터 조합 하나로 실행되는 단일 학습 실행입니다. Suggestion 서비스는 탐색 알고리즘을 구현하며, 이전 결과를 바탕으로 각 Trial이 시도해야 할 조합을 제안합니다.
- 하이퍼파라미터가 목표 메트릭에 어떻게 매핑되는지에 대한 확률 모델을 만들고, 그 모델을 이용해 다음으로 시도할 가장 유망한 지점(들)을 고르는 탐색 알고리즘은 무엇인가요?
- 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에서 정의됩니다.
- median-stopping rule은 개념적으로 어떤 동작을 하나요?
- A) 중간값에 해당하는 Trial이 끝나면 Experiment 전체를 종료한다
- B) 학습의 특정 시점에서 한 Trial의 중간 목표 값을 같은 시점의 다른 Trial들의 중앙값과 비교하고, 의미 있게 뒤처지면 그 Trial을 조기에 중단시킨다
- C) 제안된 전체 Trial 중 정확히 절반만 실행하도록 허용한다
- D) 최종 답으로 중앙값에 해당하는 하이퍼파라미터 값을 선택한다
정답 보기
정답: B) 학습의 특정 시점에서 한 Trial의 중간 목표 값을 같은 시점의 다른 Trial들의 중앙값과 비교하고, 의미 있게 뒤처지면 그 Trial을 조기에 중단시킨다
설명: median-stopping은 조기 종료의 한 형태입니다. 명백히 성적이 나쁜 Trial을 끝까지 실행시키는 대신, 같은 학습 시점의 다른 Trial들의 중앙값과 중간 값을 비교해 크게 뒤처지면 조기에 종료합니다 — 경쟁력이 없을 결과를 위해 소모될 컴퓨트를 아끼는 효과를 냅니다.
- Katib은 보통 실행 중인 Trial의 학습 컨테이너로부터 목표 메트릭 값을 어떻게 얻어내나요?
- A) 학습 컨테이너가 코드 내부에서 Katib API를 직접 호출해야 한다
- B) 메트릭 수집 사이드카가 로그/stdout을 tail하거나 메트릭 엔드포인트를 스크래핑해서 파싱된 값을 Katib에 보고한다
- C) Katib이 컨테이너를 일시 정지시키고 메모리를 직접 조사한다
- D) Kubernetes 스케줄러가 리소스 사용량으로부터 메트릭을 자동으로 추출한다
정답 보기
정답: B) 메트릭 수집 사이드카가 로그/stdout을 tail하거나 메트릭 엔드포인트를 스크래핑해서 파싱된 값을 Katib에 보고한다
설명: 메트릭 수집(metrics-collector) 사이드카는 학습 컨테이너와 함께 Trial Pod에 주입됩니다. 이 사이드카는 학습 컨테이너의 출력을 관찰합니다 — 보통 stdout/로그 파일을 파싱하거나 노출된 메트릭 엔드포인트를 스크래핑하는 방식으로 — 그리고 목표 메트릭을 Katib에 보고하여, 학습 코드 자체는 Katib을 거의 인식하지 않아도 되게 만듭니다.
parallelTrialCount를 높게 설정하면 같은maxTrialCount를 낮은 동시성으로 실행할 때보다 EKS 클러스터에 왜 더 급격한 리소스 압박을 주나요?- A)
parallelTrialCount는 생성되는 Pod 수에 영향을 주지 않는다 - B) 동시성이 높으면 많은 Trial(그리고 그에 따른 GPU 등 리소스 요청)이 시간에 걸쳐 분산되지 않고 한꺼번에 클러스터를 때려서, 짧고 급격한 수요 스파이크를 만든다
- C) EKS는 기본적으로
parallelTrialCount를 1로 제한한다 - D) 병렬 Trial들은 항상 같은 노드에서 실행되므로 추가 수요가 발생하지 않는다
- A)
정답 보기
정답: B) 동시성이 높으면 많은 Trial(그리고 그에 따른 GPU 등 리소스 요청)이 시간에 걸쳐 분산되지 않고 한꺼번에 클러스터를 때려서, 짧고 급격한 수요 스파이크를 만든다
설명: 동시에 실행되는 Trial 하나하나가 완전한 학습 잡입니다. parallelTrialCount가 8이라는 것은 8개의 리소스 요청(예: GPU 요청)이 시간에 걸쳐 분산되는 게 아니라 한꺼번에 발생한다는 뜻이며, 이는 전체 maxTrialCount가 소박해 보이는 Experiment라도 수요를 급격히 치솟게 할 수 있습니다.
- EKS에서
parallelTrialCount가 높게 설정된 Experiment가 시작된 직후, 새로 생성된 Trial Pod들이 한동안 Pending 상태로 머무른다면 어떤 설명이 그럴듯한가요?- A) Suggestion 서비스가 크래시했다
- B) Karpenter가 급증한 Pending Pod에 반응해 새 GPU 노드를 프로비저닝하는 중이며, GPU 인스턴스 타입은 프로비저닝 소요 시간이 더 긴 경우가 많다
- C) Katib은 새 Trial마다 항상 고정된 워밍업 기간 동안 일시 정지시킨다
- D) 메트릭 수집 사이드카가 Pod 시작을 막고 있다
정답 보기
정답: B) Karpenter가 급증한 Pending Pod에 반응해 새 GPU 노드를 프로비저닝하는 중이며, GPU 인스턴스 타입은 프로비저닝 소요 시간이 더 긴 경우가 많다
설명:parallelTrialCount가 높아 Pending Trial Pod가 급증하면 보통 Karpenter가 새 노드를 프로비저닝하도록 트리거됩니다. GPU 인스턴스 타입은 범용 인스턴스보다 프로비저닝에 더 오래 걸릴 수 있어, Trial들이 노드 용량을 기다리며 머무를 수 있습니다 — 탐색 알고리즘 자체가 느리다고 단정하기 전에 Trial Pod의 이벤트를 확인해 볼 가치가 있습니다.
단답형 문제
- Katib이 지원하는 탐색 알고리즘 중 두 가지를 고르고, 각각 어떤 문제에 가장 적합한지 한 문장씩 설명하세요.
정답 보기
정답: 다음 중 두 가지를 선택: 랜덤 탐색(탐색 공간이 크거나 잘 파악되지 않았을 때의 저렴한 베이스라인), 그리드 탐색(차원이 낮고 작은 이산 탐색 공간의 전체 커버리지), 베이지안 최적화(목표 값에 대한 확률 모델을 이용해 각 Trial이 비쌀 때 필요한 전체 Trial 수를 줄임), Hyperband(저렴하고 유용한 초기 신호를 이용해 성적이 나쁜 설정을 조기에 가지치기), CMA-ES/population-based 방식(연속적이거나 차원이 높은 공간에서 후보 집단을 진화시키는 데 적합).
설명: 각 알고리즘은 탐색 비용과 탐색 효율성 사이의 트레이드오프를 서로 다르게 취하며, 어떤 것이 적합한지는 Trial 하나의 비용과 탐색 공간의 구조에 따라 달라집니다.
- 둘 다 컴퓨트 낭비를 막는 것을 목표로 한다는 점에서, Hyperband가 하는 일과 조기 종료(예: median-stopping rule)가 하는 일의 차이는 무엇인가요?
정답 보기
정답: Hyperband는 각 설정에 얼마의 리소스 예산을 줄지 처음부터 결정하는 탐색 전략이고, 조기 종료는 이미 진행 중인 Trial에 대해 그 시점까지 다른 Trial들과 비교한 성과를 기준으로 적용되는 실행 중 판단입니다.
설명: 두 메커니즘은 서로 다른 층위에서 작동합니다. Hyperband의 가지치기는 탐색 알고리즘의 전체적인 예산 배분 전략의 일부이고, 조기 종료는 어떤 탐색 알고리즘이 그 Trial을 제안했는지와 무관하게 실행 중인 개별 Trial에 대해 내려지는 판단입니다.
실습/응용 문제
- 각 Trial이 GPU 1개를 요청하는 Experiment를 설정하고 있고, 클러스터에는 새 용량을 프로비저닝하는 데 보통 몇 분이 걸리는 GPU 인스턴스용 Karpenter NodePool이 있습니다.
maxTrialCount: 60으로 설정했고parallelTrialCount를 얼마로 할지 결정해야 합니다. 이 환경에서 이를 높게(예: 20) 설정하는 것과 낮게(예: 4) 설정하는 것 사이의 트레이드오프를 몇 문장으로 설명하세요.
정답 보기
정답: parallelTrialCount를 높게(예: 20) 설정하면 60개의 Trial을 더 적은 라운드에 걸쳐 끝낼 수 있지만, 동시에 20개의 GPU 요청이 급격히 발생해 Karpenter가 GPU 노드를 프로비저닝하는 속도를 앞지를 수 있습니다 — 초기 Trial들이 학습이 아니라 대기 상태로 머무르고, 같은 GPU NodePool을 다른 워크로드와 공유한다면 클러스터 용량에 스파이크를 일으킬 수도 있습니다. 낮게(예: 4) 설정하면 같은 60개의 Trial을 더 많은 라운드에 걸쳐 분산시켜, Karpenter가 점진적으로 프로비저닝할 시간을 벌어주고 용량 스파이크 위험을 줄이지만, maxTrialCount에 도달하기까지 Experiment 전체 소요 시간은 늘어납니다.
설명:parallelTrialCount와 maxTrialCount는 독립적인 설정이 아니라 클러스터의 오토스케일링 동작을 고려해 함께 튜닝해야 합니다 — 특히 Trial들이 GPU처럼 희소하거나 프로비저닝이 느린 리소스를 요청할 때는 더욱 그렇습니다.