Krea 2를 수천 GPU에서 학습·서비스하는 인프라 설계

URL: https://www.youtube.com/watch?v=byn9PURoBNY 날짜: 2026-08-19 채널: aiDotEngineer 발표자: Gabriel Jorge Menezes, Krea.ai 영상 길이: 16분 55초 (1,015초) 영상 ID: byn9PURoBNY

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==수천 개 GPU에서 처음부터 학습한 Krea 2를 안정적으로 학습하고, 같은 GPU 자원을 연구·프로덕션 사이에서 자동으로 이동시키며, 외부 GPU 공급자까지 하나의 Kubernetes 운영 모델로 묶는 방법은 무엇인가?==

• 대규모 학습의 병목은 모델 코드만이 아니라 GPU 온도, 노드 간 통신, 파일시스템, 장애 복구, 스케줄링에 있다.
• GPU utilization 같은 단순 지표만 믿지 않고 Tensor Core, InfiniBand, NVLink, 대기 시간, 오류 종류까지 관찰해야 원인을 찾을 수 있다.
• 연구자가 GPU를 직접 고르지 않도록 queue와 gang scheduling을 두고, 학습이 프로덕션을 밀어내더라도 트래픽을 다른 클러스터나 GPU rental provider로 자동 전환해야 한다.
• Virtual Kubelet, Kubernetes HPA, taint/toleration, descheduler를 조합하면 실패를 직접 복구하려는 복잡한 오케스트레이터 없이도 self-healing과 높은 GPU 활용률을 얻을 수 있다.

Gabriel Jorge Menezes는 Krea 2(K2)를 만든 동기부터 from-scratch training, 수천 GPU 클러스터의 실패 패턴과 관측성, 체크포인트 전략, Kueue 기반 학습 스케줄링, 그리고 프로덕션 inference와 training을 같은 자원 풀에서 운영하는 방법까지 시간순으로 설명한다. 핵심 철학은 연구자가 인프라의 세부사항을 몰라도 학습을 제출할 수 있게 하고, 시스템이 자원 확보·장애·트래픽 이동·노드 회수를 스스로 처리하게 만드는 데 있다.

1. Krea 2가 풀려는 문제와 제품의 형태

Krea 2의 목적은 기존 AI 이미지의 반복적인 스타일을 넘어 창작자가 분포 밖(out-of-distribution)의 이미지를 탐색하도록 돕는 데 있다.

1.1. “영혼 없고 양념 없는” AI 이미지에서 창작 도구로

1. 학습을 시작한 이유

   1. 반복되는 결과에 대한 피로: Krea 팀은 기존 AI 이미지가 꽤 영혼 없고(soulless) 양념이 없다고 느꼈다. 같은 듯한 미학적 결과만 내는 모델보다 더 흥미로운 매체를 만들고자 했다.
   2. 창작자의 탐색 공간 확대: 모델은 창작자가 분포 밖의 매우 흥미로운 이미지를 탐색하고, 구도를 실험하며, 실제 창작 도구로 사용할 수 있게 하는 것을 목표로 삼았다.

2. Krea 2의 모델 정체성

   1. 처음부터 학습: Krea 2는 이미 학습된 base checkpoint를 가져오지 않고, 아무 기반 체크포인트도 없이 Krea 내부에서 pre-trained from scratch로 만든 모델이다.
   2. 단순하지만 효과적인 구조: 연구팀은 LLM 연구와 diffusion transformer(DiT) 사이의 간극을 줄이려 했다. LLM에서 나온 연구 성과를 DiT에 다수 이식했고, 아키텍처는 “매우 단순하고, 아주 멍청해 보이지만 매우 효과적인(very dumb, but very effective)” 방향으로 유지했다.

1.2. 공개 모델과 실제 사용 방식

1. 출력의 폭

   1. 스타일 다양성: Krea 2는 pixel art, photorealistic 이미지, 일부러 엉뚱하고 silly한 결과처럼 서로 다른 스타일을 다룬다.
   2. 매체 탐색: 목적은 특정 스타일 하나를 최고 품질로 복제하는 것이 아니라 이미지라는 매체 자체를 탐색하는 것이다.

2. 두 가지 체크포인트

   1. Raw checkpoint: 최근 pre-training한 원본 체크포인트를 공개해 사용자가 post-training을 수행하거나 원하는 방식으로 변형할 수 있게 했다.
   2. Turbo checkpoint: post-trained 버전인 Turbo는 매우 빠르며, 이미지를 1초보다 짧은 시간에 얻을 수 있다.
   3. 공개·프로덕션 경로: 체크포인트는 Hugging Face와 GitHub에서 사용할 수 있고, Krea.ai에서도 프로덕션으로 제공된다.

2. 수천 GPU에서 from-scratch training 하기

대규모 학습은 “GPU를 많이 연결하고 돌리면 끝”이 아니다. 작은 실험에서 보이지 않던 장애가 GPU 수와 실행 시간에 비례해 표면화되므로 가설 검증, 확장, 장애 관측을 함께 설계해야 한다.

2.1. 작은 ablation에서 대규모 클러스터로

1. 기본 클러스터

   1. 수천 개 GPU: Krea는 하나의 큰 클러스터에 많은 GPU를 두고, 모든 GPU를 InfiniBand로 연결했다.
   2. 단순한 기대와 실제: 이상적으로는 연결된 GPU를 모두 일하게 하면 학습이 되지만, 실제 운영은 그렇게 단순하지 않았다.

2. 확장 전 검증

   1. Small ablation: 처음부터 전체 클러스터를 사용하지 않고 적은 수의 GPU에서 작은 ablation을 여러 번 수행했다.
   2. 가설의 빠른 판별: 작은 GPU 수로 잠시 학습하며 가설이 맞는지 확인하고, “작동한다/작동하지 않는다”를 판별한 뒤 규모를 키웠다.
   3. 연구와 시스템의 동시 진화: 학습 코드를 키우는 동안 LLM 연구를 DiT로 옮기고, 단순한 구조가 대규모 환경에서도 효과적인지 확인했다.

2.2. GPU 수가 늘수록 조용한 장애가 늘어나는 이유

1. 실패 표면적의 증가

   1. 128→256→512 GPU: 작은 실험은 며칠씩 실행되어도 비교적 잘 끝났지만, GPU를 128개, 256개, 512개로 늘릴수록 충돌이 자주 발생했다.
   2. 자연스러운 확률 증가: 머신과 연결 수가 많아지면 고장 날 표면적(surface area)이 커진다. 문제는 눈에 띄는 crash만이 아니라 metrics가 정상인 상태에서 일어나는 silent failure다.

2. 실제 장애 패턴

   1. 노드 간 통신 장애: 자동자막의 “nickel timeouts”는 문맥상 NCCL timeouts로 해석된다. 통신 타임아웃이나 노드 문제로 학습이 멈추거나 죽어도 다른 지표는 괜찮아 보일 수 있다.
   2. 반복적으로 짧은 실행: 같은 머신·같은 코드·같은 데이터에서 한 시간 실행 후 crash하고, 다시 한 시간 실행 후 crash하는 현상이 나타났다. 그러다 같은 조건에서 12시간, 16시간, 24시간 연속 실행되기도 했다.
   3. 실패 횟수의 예측 가능성: Meta의 한 논문이 대규모 학습에서 예상되는 실패 횟수의 대략적인 추정치를 제시한다. Krea도 비슷한 패턴을 보았지만 숫자가 같지는 않았고, Krea의 실행은 논문 속 실행보다 훨씬 짧게 끊겼다.

3. 짧은 실행이 만드는 비용

   1. 8시간 미만의 pre-training run: 대규모 pre-training이 8시간도 지속되지 않으면 GPU를 계속 공급할 수 없고, crash 동안 진척이 없으며 모델 출시가 늦어진다.
   2. 초기 대응의 변화: 처음에는 문제가 생길 때마다 노드를 교체하거나 다른 노드로 옮기는 등 편집증적으로 대응했다. 이후 같은 환경에서 계속 재시작해 우연히 긴 실행이 이어질 수 있다는 점을 받아들이고, 관측성과 체크포인트로 손실을 제한했다.

3. 관측성: GPU가 실제로 유용한 일을 하는지 측정하기

대규모 pre-training에서 metrics는 인프라가 연구자를 지원하는 유일한 시야다. 관측성에 투자하지 않으면 시스템을 보지 못한 채 운영하게 되고, 장애 원인을 찾는 사람이 먼저 지친다.

3.1. GPU 온도와 utilization의 함정

1. 온도 기준

   1. 78°C 임계값: 단일 GPU라도 다른 GPU보다 조금 뜨거우면 throttling으로 느려지고 학습이 불안정해질 수 있다.
   2. 즉시 제거: GPU 온도가 78°C를 넘으면 고치려고 시간을 쓰지 말고 클러스터에서 제거한다. 공급자에게 “이 GPU가 뜨거우니 교체해 달라”고 요청하는 편이 시간을 절약한다.

2. GPU utilization은 거짓말한다

   1. 일하고 있다는 표시일 뿐: 일반적인 GPU utilization은 GPU가 어떤 작업을 수행하고 있는 시간만 보여준다. 그 일이 효율적인지, 실제 학습에 기여하는지는 알려주지 않는다.
   2. 100%의 오해: Krea의 pre-training 대시보드에서 GPU utilization은 100%로 표시됐지만, GPU를 완전히 활용하고 있다는 뜻은 아니었다.
   3. Tensor Core utilization: Krea는 실제 연산 자원 사용 정도를 보는 proxy로 Tensor Core utilization을 사용했다. Tensor Core가 얼마나 사용되고 얼마나 효과적으로 일하는지가 더 유용한 신호였다.

3. 해상도 변화와 연산 효율

   1. 학습 단계별 scaling: pre-training에서 mid-training, post-training으로 넘어갈수록 이미지 해상도를 높였다.
   2. 관찰된 범위: 해상도는 128, 256, 512, 1,024 pixels 수준으로 확장됐고, 이미지에 수행하는 작업이 늘면서 Tensor Core utilization도 함께 올라갔다.

3.2. InfiniBand와 NVLink를 직접 수집해야 하는 이유

1. 기본 metrics의 빈틈

   1. DCGM만으로 부족: NVIDIA의 DCGM 계열 metrics에는 InfiniBand 지표가 기본으로 노출되지 않는다. NVLink 관련 정보가 일부 있어도 InfiniBand는 빠진다.
   2. 필수성: 여러 머신의 GPU가 대규모로 통신하는데 InfiniBand metrics가 없다면 잘못된 운영을 하고 있는 셈이다.

2. Krea가 모은 통신 지표

   1. fabric 대기 시간: 메시지가 fabric으로 전송된 뒤 얼마나 대기하는지 측정했다.
   2. 오류 정보: 오류의 총량뿐 아니라 오류 유형별 수치를 수집했다.
   3. 패킷·throughput: 패킷 수와 throughput을 함께 봤다. 단순 throughput만 있는 공개 화면보다 실제 reference dashboard에는 통신 대기·오류·패킷 등 InfiniBand가 내보내는 여러 정보가 들어갔다.
   4. custom collector: 필요한 지표가 기본 exporter에 없어서 직접 수집기를 만들었다. 구현은 어렵지 않고, 각 팀이 충분히 구축할 수 있는 수준이라고 강조했다.

3. 장애를 노드 단위로 좁히기

   1. 대부분은 cross-node: Krea의 실패 중 가장 큰 비중은 노드 간 통신과 관련됐다. 그래서 InfiniBand가 특히 중요했다.
   2. NVLink의 역할: NVLink는 한 노드 안의 GPU 통신을 보여준다. 단일 노드의 GPU들이 겉으로는 정상이어도 이상한 오류가 날 때 NVLink error를 확인하면 문제 머신을 찾아낼 수 있다.
   3. 대응: NVLink 오류가 반복되는 머신은 교체한다. 이 지표들이 없었다면 Krea는 학습을 계속할 수 없었을 정도로 중요했다.

4. 체크포인트와 학습 작업 스케줄링

장애를 완전히 없애기 어렵다면 장애가 발생해도 빠르게 이전 상태로 돌아가고, 연구자는 GPU 배치보다 실험에 집중하도록 만들어야 한다.

4.1. 파일시스템을 이용한 빠른 복구

1. 체크포인트를 아끼지 않기

   1. 실용적인 해킹: 학습이 계속 crash하던 상황에서 가장 실용적인 해결책은 “파일시스템을 사용하고 또 사용해 체크포인트하라”는 것이었다.
   2. 초기 저장소의 실패: 초기에 사용한 Ceph는 자동자막에서 “SEF”로 인식됐으며 잘 작동하지 않았다. 시스템이 깨지면서 데이터에 대한 신뢰를 잃었다.
   3. 유료 저장소의 가치: 예산이 있다면 데이터를 신뢰할 수 있는 paid filesystem을 쓰라고 권한다. 저장 숫자와 실제 결과를 믿을 수 있어야 대규모 학습을 운영할 수 있다.

2. Krea worker cluster의 처리량

   1. 읽기: 초당 약 1.8TB를 읽을 수 있다.
   2. 쓰기: 초당 거의 1TB를 쓸 수 있다.
   3. 훈련을 막지 않는 저장: 이 처리량 덕분에 파일시스템이 학습을 압박하지 않았다. 20~30분마다 체크포인트하고, 약 1TB의 데이터를 30초 이내에 기록할 수 있었다.
   4. 장애 비용 회수: 체크포인트가 학습 손실을 회수하는 가장 중요한 방법이었다. 체크포인트를 잊지 말고, 실행이 짧게 끊겨도 마지막 상태에서 다시 시작해야 한다.

4.2. 연구자가 GPU를 고르지 않는 queue

1. 제출 모델

   1. GPU 추상화: 연구자는 GPU를 생각하지 않고 작업을 제출한다. 작업은 queue에 들어가고, GPU가 있으면 실행되며 없으면 기다린다.
   2. gang scheduling: Krea가 사용한 오픈소스 프로젝트는 Kueue로 보이며, 자동자막에는 “Q/queue”로 인식됐다. 학습 작업 전체가 필요한 GPU를 한꺼번에 받아야 하므로 gang scheduling이 중요하다.

2. 두 단계 우선순위

   1. workload priority: 어떤 학습이 다른 학습보다 중요한지 지정해 queue 앞쪽으로 보낼 수 있다.
   2. Kubernetes priority: workload priority 아래에는 일반적인 Kubernetes priority가 있다.
   3. training 우선: training pod는 높은 priority로 제출된다. 제출되면 스케줄될 때까지 기다리고, 해당 머신에서 inference가 실행 중이면 inference가 밀려난다.

3. Queue 운영상의 마찰

   1. 리소스 선언: queue에는 CPU, NVIDIA GPU, memory 등 리소스 양을 지정해야 한다.
   2. 수동 관리: 이 숫자는 수동으로 지정된다. Krea 클러스터는 노드가 maintenance로 들어가거나 빠지고, 일부 노드를 잃는 등 유동적이어서 실제 자원 수와 설정이 어긋날 수 있다.
   3. gang scheduling의 취약점: 숫자가 어긋나면 gang scheduling이 깨질 수 있다. Kueue는 좋은 프로젝트지만 이 부분은 사용하는 팀이 마주칠 성가신 운영 문제다.
   4. Kubernetes 버전 언급: 발표 자동자막은 “Kubernetes 1.15”로 받아 적었고, 해당 버전에서 유사한 gang scheduling을 기본 제공한다고 언급했다. 버전 숫자는 자동자막 오인식 가능성이 있으나, 핵심은 Kueue와 유사한 기능이 Kubernetes 기본 기능으로 들어왔다는 점이다.

5. 한 클러스터의 training·production 자원을 자동 분리하기

Krea는 하나의 큰 클러스터에서 production과 training을 함께 실행한다. 우선순위를 무작정 고정하지 않고, training이 GPU를 쓸 때 production 트래픽을 다른 곳으로 이동시키는 구조가 핵심이다.

5.1. 연구를 막지 않고 서비스도 유지하기

1. 자원 가치의 비대칭

   1. Production의 요구: 웹사이트는 계속 작동해야 하고 사용자는 서비스를 이용할 수 있어야 하므로 production이 사라지면 안 된다.
   2. Training의 가치: 그러나 GPU가 training으로 만들어내는 연구 가치가 단순 production 실행에서 얻는 가치보다 높다고 판단했다.
   3. 운영 원칙: 연구자가 “프로덕션이 GPU를 쓰고 있으니 학습을 늦춰야 한다”고 생각하게 만들지 않는다. 학습이 자원을 사용할 수 있게 하되, 서비스는 다른 자원에서 유지한다.

2. 트래픽 flip 패턴

   1. 기본 상태: 한 클러스터의 짙은 녹색 영역은 그 클러스터에서 실행 중인 inference를 나타낸다.
   2. 학습 제출: 누군가 training을 시작하면 inference 트래픽을 다른 클러스터로 flip한다.
   3. 학습 종료: training이 끝나거나 상황이 바뀌면 트래픽을 원래 클러스터로 다시 flip한다.
   4. 효과: 이 전환은 seamless하게 이뤄져 누구도 GPU나 클러스터를 수동으로 고르지 않는다. 사용자는 production에서 아무것도 느끼지 않고, 연구자는 원하는 GPU를 활용한다.

3. 외부 공급자까지 같은 모델로 다루기

   1. 대상 범위: 트래픽은 자체 클러스터뿐 아니라 external provider, GPU rental 등으로도 이동할 수 있다.
   2. 비용 절감: 학습이 없을 때 비싼 외부 자원을 계속 유지하지 않고, 필요한 시점에만 공급자 쪽으로 보낸다.
   3. 자동 운영: 전체 시스템이 스스로 자원과 트래픽을 처리하므로 연구자는 GPU 숫자를 생각하지 않는다.

6. Virtual Kubelet로 외부 GPU를 Kubernetes 노드처럼 연결하기

Krea는 오픈소스 Virtual Kubelet을 바탕으로 Kubernetes가 외부 GPU 자원을 가짜 노드처럼 보게 만들었다. 이 추상화 덕분에 표준 Kubernetes 스케줄러와 외부 공급자별 구현을 분리할 수 있다.

6.1. 가짜 노드와 provider abstraction

1. Virtual Kubelet

   1. 오픈소스 기반: Virtual Kubelet은 활용하기 좋은 오픈소스 프로젝트이며, 그 위에 시스템을 구축할 수 있다.
   2. 가짜 머신: Kubernetes의 node 목록에 제어 가능한 fake machine을 만든다. 일반 Kubernetes scheduling은 실제 노드와 마찬가지로 pod를 이 가짜 노드에 배치한다.

2. GPU가 모두 사용 중일 때의 흐름

   1. 대기 pod 배치: 클러스터의 GPU가 모두 사용 중이면 새로운 pod가 Virtual Kubelet node로 간다.
   2. provider 선택: Krea가 pod를 되돌려 받아 어떤 provider에 보낼지 결정한다. 좋은 가격을 주는 GPU 공급자와 계약했다면 해당 provider adapter를 연결할 수 있다.
   3. 누수 없는 인터페이스: Krea는 provider 구현 세부사항이 상위 시스템으로 새지 않도록 인터페이스를 만들었다. 새 공급자를 붙일 때 provider만 구현하면 된다.
   4. 배치 알고리즘과 reconciliation: 알고리즘이 어느 provider를 사용할지 결정하고, pod 표현을 provider의 리소스 표현으로 변환해 배포한다. 이후 양쪽 상태를 reconciliation한다.

6.2. HPA와 실패 위임

1. Horizontal Pod Autoscaler 활용

   1. replica 자동 조절: Kubernetes의 HPA는 pod replica 수를 조절한다. 외부 provider를 붙여도 이 Kubernetes 기본 메커니즘을 계속 활용할 수 있다.
   2. 운영 복잡도 절감: provider마다 별도의 대규모 autoscaling 로직을 만들지 않고, pod 상태와 replica를 Kubernetes가 관리하게 한다.

2. 장애를 직접 구하려 하지 않기

   1. 실패 표기: 자기 쪽이나 provider 쪽에서 문제가 발생하면 pod를 failed로 표시한다.
   2. Kubernetes의 복구: Kubernetes가 실패를 감지하고 새 pod를 만들게 한다.
   3. “세상을 구하지 않기”: 실패한 pod를 억지로 살려내는 복잡한 복구 로직을 추가하지 않는다. “무언가 실패했다”고 표시하고 Kubernetes가 새 인스턴스를 만들게 두는 편이 훨씬 깔끔하다.
   4. 양쪽에 동일 적용: Krea 시스템 측 장애든 provider 측 장애든 같은 규칙으로 failed 처리하면 작업은 계속된다.

7. Taint, toleration, descheduler로 유휴 GPU와 프로덕션을 조절하기

외부 GPU를 빌리는 동안 자체 GPU를 놀리면 돈을 낭비하고, 학습이 끝난 뒤 외부 pod를 즉시 쫓아내면 production이 죽는다. Taint/toleration과 descheduler를 조합해 양쪽 문제를 동시에 해결한다.

7.1. GPU가 비어 있을 때 pod를 외부로 보내기

1. Taint 기반 신호

   1. 허용·차단 규칙: Kubernetes taint는 특정 노드에서 실행을 허용하거나 막고, pod의 toleration은 해당 taint를 견딜 수 있는지를 표현한다.
   2. Prometheus 입력: Krea는 Prometheus metrics를 이용해 GPU 상태를 확인한다. 구현은 단순하지만 매우 잘 작동했다.

2. 유휴 GPU 방지

   1. GPU 사용 가능 상태: 자체 클러스터에 GPU가 남아 있을 때 시스템은 노드 상태에 맞게 taint를 조정해 pod가 자체 GPU를 사용하도록 만든다.
   2. GPU가 모두 점유된 상태: training이 클러스터의 GPU를 전부 가져가면 시스템이 이를 감지하고 taint를 제거한다. 그러면 대기 중인 새 pod가 실제 GPU 노드에 스케줄된다.
   3. 외부 비용 억제: 자체 GPU가 있는데 외부 GPU를 계속 쓰지 않도록 하여 비용을 낭비하지 않는다.

7.2. 학습 종료 후 외부 pod를 천천히 되돌리기

1. descheduler의 역할

   1. 상태 변화 감지: training이 끝나 자체 GPU가 다시 비면 시스템이 taint를 추가한다.
   2. pod 이동: taint를 tolerate하지 않는 외부 쪽 pod를 descheduler가 찾아 자체 클러스터 쪽으로 천천히 migrate한다.

2. NoExecute를 쓰지 않은 이유

   1. 즉시 퇴출의 위험: Kubernetes의 NoExecute taint를 사용하면 taint를 넣는 순간 모든 대상 pod가 한꺼번에 쫓겨난다.
   2. Production 장애: 그런 방식은 production을 동시에 끊어 사이트가 내려갈 수 있다.
   3. 점진적 회수: descheduler 방식은 pod를 조금씩 옮기므로 production이 중단되지 않고, 자체 GPU가 다시 사용되며 외부 GPU 비용도 줄어든다.

3. 운영 결과

   1. Self-healing: 초기에는 버그가 있었지만 시스템을 조정하고 calibrate한 뒤 매우 안정적으로 동작했다.
   2. 연구자의 경험: 연구자는 GPU를 관리하지 않고 작업만 제출한다. GPU가 있으면 즉시 쓰고, 없으면 queue에 들어간다.
   3. 자원 활용: training은 클러스터 GPU를 충분히 사용하고 production은 다른 곳에서 실행된다. 연구와 서비스가 서로를 기다리거나 유휴 GPU를 남기지 않는다.

8. Diffusion Transformer inference의 장애 허용성

DiT 모델의 inference는 거대한 LLM inference처럼 여러 노드에 걸쳐야 할 만큼 크지 않다는 점이 운영 설계를 단순하게 만든다.

8.1. 나쁜 GPU도 inference에는 쓸 수 있다

1. LLM과의 차이

   1. 작은 inference 단위: diffusion transformer는 대형 LLM처럼 multi-node inference가 필수인 크기가 아니다.
   2. GPU 선택 폭: 어떤 GPU가 작동하기만 하면 inference를 실행할 수 있다.

2. 극단적인 사례

   1. 뜨거운 GPU: GPU가 뜨거워도 inference는 계속 실행될 수 있다.
   2. 버스에서 이탈하는 GPU: GPU가 bus에서 떨어지는 듯한 상태여도 inference가 계속될 수 있다.
   3. 폭발하는 GPU: 발표자는 과장된 표현으로 GPU가 “폭발하고 있어도” inference는 계속 실행된다고 말했다.
   4. 운영적 의미: training에서는 78°C 이상 GPU를 제거할 정도로 엄격하게 관리하지만, DiT inference는 훨씬 나쁜 GPU에서도 사용자에게 서비스를 제공할 수 있다. 결과적으로 GPU가 완벽하지 않아도 사용자는 만족하고, 시스템은 높은 가용성을 얻는다.

주요 발언 모음

“We were kind of bored of AI images. They’re quite soulless. They have no spice.”

“The whole idea was to give creatives tools to explore out-of-distribution, extremely interesting images.”

“The architecture was extremely simple. It is very, very dumb, but very effective.”

“Metrics are everything. Don’t go blind, because you’re going to go crazy.”

“If there is any GPU above 78 degrees, you remove it. Don’t try to be smart. Just remove the GPU.”

“GPU utilization is a lie. Use Tensor Core utilization as a proxy.”

“If you’re doing large-scale pre-training with a bunch of GPUs talking between machines and you have no InfiniBand metrics, you’re doing something wrong.”

“Just checkpoint. Use and abuse the filesystem that you have.”

“You don’t need to try to save the world. Let Kubernetes handle it for you.”

“If you have GPUs, we have GPUs. If not, we don’t have GPUs; go into the queue.”

“The GPU can be hot, falling out of the bus, it can be exploding. Inference is still going to run.”

핵심 데이터 & 수치

• 1,015초 / 16분 55초: 전체 발표 길이다.
• 수천 개 GPU: Krea 2 from-scratch training에 사용한 규모다.
• 128·256·512 GPU: 클러스터를 확장하며 실패 표면적이 커진 대표 단계다.
• 128·256·512·1,024 pixels: pre-training에서 mid-/post-training으로 가며 관찰한 이미지 해상도 범위다.
• 78°C: 초과 시 GPU를 제거하고 공급자에게 교체를 요청하는 온도 기준이다.
• 8시간 미만: 이보다 짧게 끊기는 pre-training run은 GPU를 계속 공급하기 어렵고 모델 출시를 늦춘다.
• 12·16·24시간: 같은 머신·코드·데이터가 반복 crash 뒤 다시 안정적으로 실행된 사례의 지속 시간이다.
• 1.8TB/s: worker cluster의 읽기 처리량이다.
• 약 1TB/s: worker cluster의 쓰기 처리량이다.
• 20~30분: 체크포인트 주기다.
• 30초 미만: 약 1TB 체크포인트 데이터를 쓰는 시간이다.
• 1초 미만: Krea 2 Turbo에서 이미지를 얻는 목표 수준이다.
• InfiniBand: cross-node communication 실패를 파악하기 위해 직접 metrics를 수집한 fabric이다.
• NVLink: single-node GPU 통신 오류와 문제 머신을 찾기 위해 수집한 지표다.

결론 및 시사점

1. 제품 목표와 인프라 목표를 연결하라: Krea 2는 AI 이미지의 반복성에 대한 문제의식에서 출발했고, out-of-distribution 창작을 위해 처음부터 학습했다. 창작 경험을 위해서는 연구자가 빠르게 실험해야 하므로 인프라가 연구자의 GPU 선택 부담을 제거해야 한다.
2. 관측성은 선택사항이 아니다: GPU utilization 100%라는 숫자만으로는 효율을 판단할 수 없다. Tensor Core utilization, GPU 온도, InfiniBand 대기·오류·패킷·throughput, NVLink errors를 함께 수집해야 한다.
3. 뜨거운 하드웨어를 고치려 하지 말라: 78°C를 넘는 GPU는 원인 분석을 길게 하기보다 제거하고 교체한다. 대규모 학습에서는 한 부품의 느린 throttling이 전체 작업을 불안정하게 만드는 비용이 더 크다.
4. 체크포인트를 장애 전략의 중심에 두라: 장애가 사라지지 않는 환경에서 짧은 주기의 빠른 체크포인트와 높은 파일시스템 처리량은 재시작 비용을 제한한다. 약 1TB를 30초 안에 쓰는 저장 계층은 20~30분 체크포인트를 학습 병목으로 만들지 않는다.
5. 학습에는 gang scheduling이 필요하다: 여러 GPU를 동시에 받아야 하는 training은 일부 GPU만 배정된 상태로 시작할 수 없다. workload priority와 Kubernetes priority를 함께 두면 연구자가 작업을 제출하고 queue가 자원을 묶어 배정한다.
6. 프로덕션과 연구를 물리적으로만 분리하지 말라: 하나의 GPU 클러스터를 training과 production이 공유하더라도, Virtual Kubelet과 트래픽 flip으로 inference를 다른 클러스터나 외부 provider로 이동할 수 있다. 핵심은 사용자 트래픽을 보호하면서 연구 GPU를 최대한 채우는 자동화다.
7. 공급자별 복잡도를 Kubernetes에 위임하라: Virtual Kubelet의 fake node와 provider adapter를 사용하면 공급자 변경이 상위 스케줄러로 새지 않는다. HPA와 reconciliation을 재사용하고, 실패한 pod는 failed로 표시해 Kubernetes가 새로 만들게 한다.
8. 자원 회수는 점진적으로 하라: taint/toleration으로 GPU 상태를 표현하고 descheduler로 pod를 천천히 옮기면, 유휴 GPU 비용을 줄이면서 NoExecute의 동시 퇴출로 인한 production 장애를 피할 수 있다.
9. 모델 종류에 맞게 장애 허용 수준을 설계하라: DiT inference가 multi-node LLM inference보다 작다면 일부 나쁜 GPU에서도 서비스를 계속할 수 있다. training과 inference에 동일한 하드웨어 기준을 강제하지 않는 것이 가용성과 비용 면에서 유리하다.
10. 최종 운영 원칙: 연구자는 “GPU가 있으면 실행되고 없으면 queue에서 기다린다”는 단순한 계약만 알면 된다. 나머지는 metrics, 체크포인트, 스케줄러, 트래픽 라우터, provider adapter, Kubernetes가 책임져야 한다.