2024년 8월 30일(금) 주간 개발트렌드

![image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/2a3741f8-626e-4237-b985-d52de10bb444_thumbnail_1.png)

## Cloud / AI Infra — Cloud Run에 GPU 지원 Preview

Google이 **8월 21일 Cloud Run에서 NVIDIA L4 GPU 지원 Preview**를 발표했습니다.

기존 Cloud Run은 CPU 기반의 Serverless Container 실행 환경이 중심이었지만, GPU 지원이 추가되면서 **AI Inference Workload까지 Serverless 방식으로 실행할 수 있는 길**이 열리기 시작했습니다.

특히 직접 GPU Server를 구축하고 운영하지 않아도 Container 형태로 모델을 배포할 수 있다는 점이 중요했습니다.

---

### 기존 GPU Inference 구조

자체 AI 모델을 서비스하려면 일반적으로 GPU Infrastructure를 직접 구성해야 했습니다.

```text
GPU VM
  ↓
Container
  ↓
Model Server
  ↓
Scaling
  ↓
Load Balancer
  ↓
GPU Resource 관리
```

예를 들어 Cloud VM이나 Kubernetes Cluster에 GPU Node를 구성하고 모델 서버를 실행하는 방식입니다.

이 경우 개발자는 단순히 모델만 배포하는 것이 아니라 다음 요소까지 관리해야 했습니다.

- GPU Instance
- Container Runtime
- Model Server
- Load Balancer
- Autoscaling
- GPU Driver
- CUDA Environment
- Monitoring
- Instance Lifecycle

AI Inference를 운영하기 위해 상당한 Infrastructure 관리가 필요했던 것입니다.

---

### Cloud Run + GPU

Cloud Run에 GPU가 추가되면서 구조가 훨씬 단순해질 수 있게 됐습니다.

```text
Container
   ↓
Cloud Run
   ↓
NVIDIA L4 GPU
```

개발자는 AI 모델과 Inference Server를 Container Image에 넣고 Cloud Run에 배포하는 형태로 서비스를 구성할 수 있습니다.

즉 GPU Infrastructure 자체를 직접 운영하기보다 **Container 단위의 Serverless 실행 환경을 사용하는 방식**이 가능해진 것입니다.

---

### Serverless GPU

Serverless의 핵심은 개발자가 Server 자체를 직접 관리하지 않는다는 점입니다.

기존 방식에서는

```text
Developer
   ↓
VM
   ↓
GPU
   ↓
Container
   ↓
Model
```

Infrastructure 관리가 필요했습니다.

Cloud Run에서는 이를

```text
Developer
   ↓
Container
   ↓
Cloud Run
   ↓
GPU
```

형태로 추상화할 수 있습니다.

개발자가 집중해야 할 영역이 Infrastructure에서 **Application과 Model Serving** 쪽으로 이동하게 됩니다.

---

### 왜 중요한가

GPU 기반 AI Inference는 오랫동안 일반적인 Serverless 환경과 잘 맞지 않는 영역이었습니다.

GPU는 비싼 Resource이고 초기화 시간이 길며 모델 자체도 큰 Memory를 요구하기 때문입니다.

그래서 AI Infrastructure는 주로 다음과 같은 환경에서 운영됐습니다.

```text
AI Inference

├─ GPU VM
├─ Kubernetes GPU Node
└─ Managed AI Platform
```

Cloud Run의 GPU 지원은 여기에 새로운 선택지를 추가했습니다.

```text
AI Inference

├─ GPU VM
├─ Kubernetes
├─ Managed AI Platform
└─ Serverless GPU
```

즉 생성형 AI Workload가 **전용 GPU Infrastructure 영역에서 일반 Serverless Application Platform으로 내려오기 시작한 것**입니다.

---

### Kubernetes와의 차이

대규모 AI 서비스를 운영할 때 Kubernetes는 여전히 강력한 선택지입니다.

```text
Kubernetes

GPU Node
   ↓
Pod
   ↓
Model Server
   ↓
Service
   ↓
Ingress
```

GPU Scheduling, 여러 Model 배포, 복잡한 Networking이나 Resource 관리가 필요한 환경에서는 Kubernetes가 적합할 수 있습니다.

하지만 작은 서비스에서는 Kubernetes 자체가 부담이 될 수 있습니다.

```text
작은 AI 서비스

Model 하나
+
API 몇 개
+
불규칙한 Traffic
```

이런 환경에서는 Cluster를 운영하는 것보다 Cloud Run 같은 Serverless Platform에 Container를 배포하는 방식이 훨씬 단순할 수 있습니다.

---

### 불규칙한 Traffic

Serverless GPU가 특히 의미 있는 영역은 **Traffic이 일정하지 않은 AI 서비스**입니다.

기존 GPU Server는 요청이 없어도 Instance를 계속 실행해야 하는 경우가 많았습니다.

```text
GPU Server

Traffic 있음  → GPU 실행
Traffic 없음  → GPU 실행
Traffic 없음  → GPU 실행
Traffic 있음  → GPU 실행
```

GPU는 일반 CPU Instance보다 비용이 높기 때문에 Idle 시간이 길어지면 비용 낭비가 커질 수 있습니다.

Serverless 방식에서는 Workload에 따라 Resource를 조정할 수 있기 때문에 이런 문제를 줄일 가능성이 생깁니다.

```text
Traffic 증가
    ↓
Scale Up

Traffic 감소
    ↓
Scale Down
```

AI 서비스에서도 **Elastic Scaling**을 활용할 수 있는 영역이 넓어지는 것입니다.

---

### 어떤 Workload에 적합한가

Cloud Run GPU 같은 Serverless GPU는 특히 다음과 같은 서비스에서 활용 가능성이 높습니다.

- 작은 Open Model Inference
- 이미지 생성
- 이미지 분석
- Embedding 생성
- Speech Processing
- AI API
- Prototype
- Internal AI Tool
- Traffic이 불규칙한 AI 서비스

예를 들어 작은 Open Model을 API로 제공한다면 다음과 같은 구조를 만들 수 있습니다.

```text
Client
  ↓
API
  ↓
Cloud Run
  ↓
GPU
  ↓
Open Model
  ↓
Inference Result
```

별도의 GPU Cluster를 만들지 않고 AI API를 구성할 수 있는 것입니다.

---

### Backend 관점에서의 변화

기존에는 AI 기능을 직접 Hosting하려면 Infrastructure 지식이 상당히 중요했습니다.

```text
Backend
+
GPU Infrastructure
+
Model Serving
+
Scaling
```

하지만 Serverless GPU가 발전하면 Backend 개발자가 Container를 중심으로 AI Model Serving을 다룰 수 있는 영역이 넓어집니다.

```text
Backend Developer

Application
     ↓
Container
     ↓
Serverless GPU
     ↓
Model
```

따라서 AI Backend에서도 다음과 같은 기술 조합이 현실적으로 사용될 수 있습니다.

- Docker
- FastAPI / Node.js
- Model Server
- Cloud Run
- GPU
- Autoscaling

기존 Backend 개발 방식과 AI Infrastructure 사이의 거리가 줄어드는 것입니다.

---

### 비용 측면

Serverless GPU가 있다고 해서 항상 GPU 비용이 저렴해지는 것은 아닙니다.

Traffic이 지속적으로 높다면 Dedicated GPU Instance나 Kubernetes 기반 GPU Pool이 더 효율적일 수도 있습니다.

```text
Traffic Pattern

지속적인 높은 Traffic
        ↓
Dedicated GPU

불규칙한 Traffic
        ↓
Serverless GPU
```

따라서 Architecture를 결정할 때는 다음 요소를 함께 고려해야 합니다.

- Request Traffic
- Model Size
- Cold Start
- GPU Utilization
- Latency Requirement
- Scaling Pattern
- GPU Cost
- Operational Cost

Serverless GPU의 장점은 GPU 자체가 싸다는 것이 아니라 **GPU Infrastructure를 필요한 만큼 유연하게 사용할 수 있다는 점**에 가깝습니다.

---

### AI Infrastructure의 변화

AI Infrastructure도 기존 Web Backend와 비슷한 방향으로 발전하고 있습니다.

과거 Web Application은

```text
Physical Server
      ↓
VM
      ↓
Container
      ↓
Kubernetes
      ↓
Serverless
```

방향으로 Infrastructure 추상화가 진행됐습니다.

AI Workload에서도 비슷한 변화가 나타나고 있습니다.

```text
Dedicated GPU Server
        ↓
GPU VM
        ↓
GPU Kubernetes
        ↓
Serverless GPU
```

GPU Resource를 직접 관리하는 영역이 점점 Cloud Platform 내부로 추상화되고 있는 것입니다.

---

### 실무 영향

Cloud Run GPU 지원은 작은 AI 서비스를 구축하는 개발자에게 특히 의미가 있습니다.

기존에는 자체 모델을 서비스하기 위해

```text
GPU Infrastructure 구축
        ↓
Model Serving
        ↓
Scaling
        ↓
Application 개발
```

순서로 상당한 Infrastructure 작업이 필요했다면,

Serverless GPU에서는

```text
Model
  ↓
Container
  ↓
Cloud Run
  ↓
GPU
```

형태로 훨씬 단순한 Architecture를 구성할 수 있습니다.

특히 Traffic이 불규칙한 서비스에서는 항상 GPU Server를 실행해 두는 구조를 피할 수 있는 가능성도 생겼습니다.

결국 Cloud Run의 GPU 지원은,

> **AI Inference 역시 전용 GPU Server나 Kubernetes만의 영역이 아니라 일반 Serverless Application처럼 배포할 수 있는 방향으로 움직이기 시작했다는 신호**

라고 볼 수 있습니다.

2024년 8월 23일(금) 주간 개발트렌드

독자의 메모