Google TPU Trillium: 8세대 AI 가속기 훈련 및 추론 아키텍처

서론: Agent 시대의 지연 시간(Latency) 문제와 하드웨어의 한계

최근 몇 달간 운영 중인 RAG(검색 증강 생성) 기반의 AI 서비스에서 사용자들은 “왜 답변이 생성될 때마다 끊기지?“라고 불평하기 시작했습니다. 기존 GPU 클러스터에서는 배치(Batch) 처리를 통해吞吐量(Throughput)는 확보했지만, 개별 토큰 생성 속도(TTF - Time To First Token)가 느려지는 병목 현상이 발생했습니다.

더욱이 단순한 질의응답을 넘어, 도구를 사용하고 스스로 계획을 수립하는 ‘에이전트(Agent)’ 형태의 AI 워크로드가 등장하면서, 추론(Inference) 단계에서도 훈련(Training)에 준하는 엄청난 연산량과 메모리 대역폭이 요구되기 시작했습니다. 이제 단순히 더 많은 GPU를 추가하는 것만으로는 이러한 대기 시간 문제와 비용 효율성 문제를 동시에 해결할 수 없게 되었습니다.

Google이 발표한 8세대 TPU 아키텍처인 Trillium은 이러한 문제를 해결하기 위해 설계되었습니다. 특히 에이전트 AI 시대에 특화된 **TPU 8t(훈련)**와 **TPU 8i(추론)**는 하드웨어적인 분리를 통해 각 워크로드에 최적화된 성능을 제공합니다. 이 글에서는 SRE/DevOps 관점에서 Trillium 아키텍처의 기술적 변화를 분석하고, Google Cloud 환경에서 이를 실제 인프라에 통합하는 방법을 다룹니다.

본론: Trillium 아키텍처의 기술적 심층 분석

1. Trillium의 핵심: HBM3e와 고속 인터커넥트

기존 TPU v5p와 비교했을 때, Trillium(8세대)의 가장 큰 변화는 메모리 대역폭칩 간 통신 속도입니다. 대규모 언어 모델(LLM)은 연산 능력(FLOPs)보다 데이터를 메모리에서 얼마나 빨리 가져오느냐(Memory Bound)가 성능을 좌우하는 경우가 많습니다.

Trillium은 **HBM3e(High Bandwidth Memory 3e)**를 채택하여 대역폭을 획기적으로 늘렸습니다. 이는 모델 가중치(Weights)를 빠르게 로드하여 추론 지연 시간을 줄이는 데 결정적인 역할을 합니다. 또한, TPU 간 데이터 복제 및 병렬 처리를 위한 ICI(Interconnect ICI) 대역폭 역시 두 배 이상 증가하여, 수천 개의 칩이 하나의 거대한 가상 머신처럼 작동할 수 있게 합니다.

2. TPU 8t vs TPU 8i: 워크로드에 따른 최적화

Google은 이번 세대부터 훈련 전용 칩과 추론 전용 칩의 명확한 구분을 제시합니다. 이는 인프라 비용 효율화를 위해 매우 중요한 접근입니다.

| 비교 항목 | TPU 8t (Training) | TPU 8i (Inference) | | :— | :— | :— | | 주 목적 | 대규모 모델 사전 훈련 & 파인 튜닝 | 고밀도 추론 & low-latency 서빙 | | 메모리 (HBM) | 초고용량 (파라미터 저장 최적화) | 고대역폭 (데이터 로딩 속도 최적화) | | 합성곱 성능 | 훈련 속도 위주의 MXU 구성 | 추론 처리량 위주의 구성 | | 주요 사용 사례 | Gemini 2.0 훈련, 기초 모델 베이스 | Chatbot, Code Assistant, Agents | | SRE 관점 | 장기간 안정적인 전력/열 관리 필요 | 높은 요청 밀도(RPS) 처리 능력 중요 |

3. TPU Pod 슬라이스 아키텍처 (Mermaid)

DevOps 엔지니어가 이해해야 할 가장 중요한 부분은 리소스가 어떻게 물리적으로 연결되는지입니다. Google TPU는 슬라이스(Slice) 단위로 프로비저닝되며, 각 TPU는 고속 ICI 네트워크로 연결된 메시(Mesh) 토폴로지를 형성합니다.

아래 다이어그램은 사용자 요청이 Load Balancer를 거쳐 TPU 8i 슬라이스로 전달되고, HBM을 통해 처리되는 간단한 흐름을 보여줍니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
graph LR
    A[User Request] --> B[Cloud Load Balancer]
    B --> C[TPU VM Node 1]
    B --> D[TPU VM Node 2]
    C --> E[TPU Chip 8i]
    D --> F[TPU Chip 8i]
    E --> G[HBM3e Memory]
    F --> G
    E <--> F[High-Speed ICI]
    G --> H[Response Generation]
    H --> A

4. Google Cloud에서 Trillium 배포하기 (Terraform)

이제 실무적으로 Google Cloud TPU(Trillium) 환경을 프로비저닝해 보겠습니다. gcloud 명령어도 좋지만, 재현 가능한 인프라 관리를 위해 Terraform을 사용하는 것이 SRE 엔지니어의 관점에서 더 적절합니다.

아래 코드는 GKE(Google Kubernetes Engine)와 통합되지 않은 독립형 TPU Node를 생성하는 예시입니다. TPU VM은 GCE(Google Compute Engine)의 일종으로 작동합니다.

main.tf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = ">= 4.80.0"
    }
  }
}

provider "google" {
  project = "your-project-id"
  region  = "us-central1"
  zone    = "us-central1-b"
}

# TPU QueuedResource를 통한 Trillium 할당 요청
resource "google_tpu_queued_resource" "tpu_trillium_slice" {
  name         = "tpu-trillium-resource"
  parent       = "projects/your-project-id/locations/us-central1-b"
  tpu_node     = google_tpu_node.tpu_node.id
  guaranteed   = {
    priority = PRIORITY_HIGH
  }
}

# TPU Node 정의 (TPU v5p 혹은 Trillium 타입 선택)
# 주의: 실제 Trillium 타입은 region별 가용 여부를 확인해야 합니다.
resource "google_tpu_node" "tpu_node" {
  name           = "trillium-tpu-node"
  zone           = "us-central1-b"
  runtime_version = "v2-alpha-tpuv5" # 런타임 버전은 최신 안정화 버전 사용 권장
  accelerator_type = "TPU-V5-POD" # 예시 타입, 실제 Trillium SKU는 문서 확인 필요
  
  # 슬라이스 구성 (예: 4x4 토폴로지)
  tensorflow_config {
    endpoint      = "10.0.0.2:8470"
    gcp_network   = "projects/your-project-id/global/networks/default"
  }
  
  network_config {
    enable_external_ips = true
    network             = "projects/your-project-id/global/networks/default"
    subnetwork          = "projects/your-project-id/regions/us-central1/subnetworks/default"
  }
  
  data_disks {
    source_disk = "projects/your-project-id/zones/us-central1-b/disks/persistent-disk-1"
  }
  
  scheduling_config {
    preemptible = false # 프로덕션 환경에서는 false 권장
  }
}

실행 및 검증 단계:

  1. 초기화: terraform init 2. 계획 검토: terraform plan (TPU 리소스는 생성에 시간이 오래 걸리므로 plan 단계에서 설정을 면밀히 검토하세요.) 3. 배포: terraform apply 4. 상태 확인: TPU 노드가 생성되면 SSH 접속하여 top 명령어나 TPU-specific 툴을 통해 칩 상태를 모니터링해야 합니다.

5. 운영 관점의 모니터링과 트러블슈팅

TPU를 프로덕션


출처: https://blog.google/innovation-and-ai/infrastructure-and-cloud/google-cloud/eighth-generation-tpu-agentic-era/

Hugo로 만듦
JimmyStack 테마 사용 중