Belajar Infrastructure Engineer - AI Infrastructure

#Pendahuluan

Setelah di episode 22 kita mengoptimalkan performa, kini kita masuk ke topik yang mengubah peta infrastruktur 2026: AI infrastructure. AI tidak lagi sekadar "menjalankan model di laptop" — ia menjadi beban kerja produksi yang menuntut perangkat keras khusus (GPU), jaringan berkecepatan tinggi, storage berkapasitas raksasa, dan platform yang terkelola.

Mengapa topik ini penting? Karena AI-ready infrastructure adalah skill premium 2026. Perusahaan berlomba menyediakan GPU untuk training dan inference — dan infra engineer yang bisa merancang, menyediakan, dan mengoperasikan cluster GPU adalah yang paling dicari pasar.

#Beban Kerja AI: Dua Dunia Berbeda

AI punya dua profil beban kerja yang sangat berbeda — jangan mencampurnya:

Konsekuensi arsitektur: training berjalan seperti job batch di cluster besar; inference berjalan seperti layanan online dengan auto-scaling (episode 21).

#Hardware: GPU dan Temannya

#GPU sebagai Compute Dominan

GPU berbeda dari CPU: ribuan core sederhana untuk komputasi paralel. Metrik penting:

GPU memory : kapasitas per kartu (menentukan ukuran model)
TFLOPS     : kecepatan komputasi (FP16/BF16 untuk AI)
HBM        : bandwidth memory (bottleneck paling umum)
NVLink/Infiniband : kecepatan interkoneksi antar GPU

#Satu GPU, Satu Node, atau Satu Cluster?

Model AI modern sering melebihi kapasitas satu GPU → butuh distributed training:

#Merancang GPU Cluster

#Jaringan: Interkoneksi Berkecepatan Tinggi

Distributed training bergantung pada kecepatan komunikasi antar GPU — jika terlalu lambat, GPU menghabiskan waktu menunggu. Standar industri: InfiniBand atau RoCE (RDMA over Ethernet). Jaringan biasa (1GbE/10GbE) tidak cukup untuk training skala besar.

#Storage: Data Pipeline

Dataset AI sangat besar (terabyte-petabyte). Pola yang benar:

Object storage (dataset mentah, arsip) 
   → high-throughput storage (dataset terproses)
      → scratch SSD lokal per node (epoch cache)

Dataset harus tersedia lebih cepat dari GPU bisa mengkonsumsinya — kalau tidak, GPU menganggur menunggu data. Ini bottleneck yang paling sering dilupakan.

#Scheduler: Menjalankan Job AI

Job training dijadwalkan dengan tool khusus: Kueue (Kubernetes), Volcano, Slurm (klasik HPC), atau RunAI. Konsep inti:

Konsep scheduling AI di K8s

GPU node pool (terlabel) → GPU requests (k8s.device.nvidia.com/gpu: 8)
Job meminta 8 GPU → scheduler menempatkan ke 1 node (atau multi-node)
Queue: job besar mengantre, job kecil lolos di sela-sela

Scheduling yang benar mencegah: GPU tidak terpakai (job menunggu tanpa perlu) dan GPU terfragmentasi (sisa-sisa yang tidak bisa dipakai siapa pun).

#Konsep GPU di Kubernetes

Deployment dengan GPU request

apiVersion: apps/v1
kind: Deployment
metadata:
  name: inference
spec:
  replicas: 2
  selector:
    matchLabels:
      app: inference
  template:
    metadata:
      labels:
        app: inference
    spec:
      containers:
        - name: model
          image: registry.lab.local/llm-api:v1.4.2
          resources:
            limits:
              nvidia.com/gpu: "1"

Catatan penting: nvidia.com/gpu tidak berfungsi tanpa device plugin (misal NVIDIA device plugin) dan GPU operator yang mengelola driver di node.

#Inference Infrastructure

Inference adalah layanan online — desainnya mengikuti pola HA & scaling (episode 21), ditambah spesifisitas AI:

#Komponen Inferensi Produksi

1. Model serving runtime: vLLM, TGI, Triton — mengoptimalkan inference (continuous batching, paged attention).
2. GPU pool: beberapa GPU dengan auto-scaling berdasarkan request.
3. Router/load balancer: membagi request ke worker GPU yang sibuk.
4. Cache: hasil inference yang sama bisa di-cache (prompt umum).
5. Vector database: retrieval untuk RAG — jembatan antara data perusahaan dan model.

#Konsep Scaling Inference

GPU idle → satukan beberapa model di satu GPU (multi-tenant serving)
GPU penuh → tambah GPU/replika (auto-scaling dari metrik GPU)
Antrean panjang → skala naik (queue length adalah sinyal terbaik)

Ukuran GPU untuk inference: pilih GPU berdasarkan ukuran model dan target latency — bukan selalu GPU terbesar. Model kecil di GPU kecil jauh lebih hemat biaya.

#Storage dan Data untuk AI

#Vector Database

RAG (Retrieval-Augmented Generation) membutuhkan penyimpanan vektor — representasi numerik dokumen:

Dokumen → chunking → embedding (vector) → vector DB
Query → embedding → pencarian similarity → konteks → model

Vector database populer: Qdrant, Weaviate, pgvector (di PostgreSQL), Milvus. Pilihan tergantung skala dan kebutuhan filter metadata.

#Data Pipeline AI

Peran infra engineer: menyediakan pipeline yang reproducible dan terpantau — data berubah, pipeline pecah, kualitas model turun tanpa disadari.

#Observability Khusus AI

Metrik standar (episode 9) belum cukup untuk AI:

GPU:
  - GPU utilization (%) — target tinggi saat training
  - GPU memory usage
  - GPU temperature (throttling kalau panas)
  - NVLink/IB utilization (bottleneck komunikasi)
Model/inference:
  - Time-to-first-token (TTFT)
  - Tokens per second (throughput)
  - Queue length inference
  - p95/p99 latency inference
  - Error rate (timeout, overload)

Alat pemantau GPU: DCGM exporter (NVIDIA) → Prometheus → Grafana. Tanpa ini, cluster GPU berjalan buta.

#Common Pitfalls AI Infrastructure

• GPU menganggur menunggu data: storage tidak mampu mengimbangi kecepatan GPU — bottleneck paling umum.
• Ngelola cluster GPU seperti CPU biasa: melupakan interkoneksi cepat (InfiniBand/RoCE) untuk distributed training.
• Tanpa scheduling yang benar: GPU terfragmentasi, pekerjaan menunggu tanpa kejelasan.
• Model serving tanpa cache: request berulang membebani GPU tanpa perlu.
• GPU terbesar untuk semua hal: boros biaya — pilih ukuran sesuai model dan latency.
• Tanpa observability GPU: thermal throttling, memory penuh, dan antrean tidak terlihat.

#Penutup

Pada episode 23 ini kalian telah membangun infrastruktur AI:

• Dua dunia: training (batch berat) vs inference (online latency-sensitive).
• Hardware: GPU, memory, interkoneksi (NVLink/InfiniBand) — dengan metrik yang benar.
• GPU cluster: node pool GPU, scheduler (Kueue/Volcano), dan storage pipeline yang tidak menjadi bottleneck.
• Inference infra: serving runtime, router, cache, dan auto-scaling berbasis queue.
• Observability khusus GPU (DCGM) dan jebakan thermal throttling.

Di episode 24 selanjutnya kita menjaga biaya tetap waras: cost optimization infra — FinOps, rightsizing, dan tagging. Sampai jumpa di episode 24!