Belajar Platform Engineer - Platform Engineering AI

#Pendahuluan

Dari episode 14 hingga 20 platform sudah melayani aplikasi konvensional: workload stateless, data, dan jaringan yang aman. Tapi 2026 membawa pertanyaan baru: bagaimana platform melayani AI? Episode ini membahas platform engineering AI — infrastruktur untuk AI workloads: GPU scheduling, LLM serving, dan MLOps — plus bagaimana AI menjadi fitur platform itu sendiri, dari auto-remediation sampai golden path yang dibantu AI.

Mengapa ini penting? AI workloads mengubah asumsi dasar platform: resource tidak lagi "CPU + memory" saja, tapi GPU; traffic tidak lagi "request kecil merata", tapi inference dengan pola burst dan request panjang; dan lifecycle tidak lagi "build → deploy", tapi train → evaluate → serve → iterate. Platform yang mengabaikan ini akan ditinggalkan, sementara tim AI membangun sendiri infra yang tidak terkelola.

#GPU Scheduling di Kubernetes

GPU adalah resource yang tidak bisa dibagi sembarangan — ia dijadwalkan sebagai unit utuh. Langkah dasar:

Node pool GPU — node khusus dengan GPU, terpisah dari workload biasa agar harga dan quota jelas.
Device plugin / NFD — Kubernetes mendeteksi GPU sebagai resource terukur (contoh nvidia.com/gpu).
Quota GPU per tim — sama seperti quota CPU/memory di episode 4, tapi lebih ketat karena mahal.
GPU sharing/MIG — membagi satu GPU untuk beberapa workload kecil; mahal dan hemat, tapi perkenalkan dengan hati-hati (isolasi lemah).

gpu/llm-serving-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-serving
  namespace: ai-services
spec:
  replicas: 2
  template:
    spec:
      nodeSelector:
        node-group: gpu
      containers:
        - name: vllm
          image: registry.example.com/vllm:latest
          resources:
            limits:
              nvidia.com/gpu: "1"
            requests:
              cpu: "4"
              memory: 32Gi

Policy platform harus memastikan: GPU hanya di node GPU (nodeSelector dipaksakan), tidak ada request GPU dari workload non-AI, dan GPU selalu punya limit (bukan hanya request).

#LLM Serving: Inference sebagai Service

Menjalankan model besar (LLM) butuh runtime khusus — vLLM, TGI, atau TensorRT-LLM — yang mengoptimalkan memori GPU (KV cache) dan throughput. Serving inference punya pola unik:

Autoscaling berbasis GPU utilization & queue length, bukan sekadar CPU.
Request panjang (streaming) yang berbeda dari request HTTP biasa; health check harus toleran.
Model versioning — satu endpoint melayani beberapa model dengan routing (via model router).

Struktur stack LLM serving

LLM Gateway (routing + policy)
  └─ vLLM instances (model ter-cache di GPU)
       └─ Model Registry (artefak model + metadata)

Platform menyediakan ini sebagai layer self-service (episode 12): developer cukup menyatakan "saya ingin serve model X versi Y", platform mengatur GPU, autoscaling, dan observability.

#MLOps sebagai Golden Path

Di atas serving ada siklus hidup model: MLOps. Platform engineering menyeragamkannya seperti IaC — supaya tidak ada tim yang membangun pipeline training sendiri-sendiri:

Tahap	Layanan platform	Contoh tooling
Experiment	Tracking experiment terpusat	MLflow, Weights & Biases
Training	Job training di cluster (CPU/GPU)	Kubeflow, Kueue
Model registry	Artefak model + metadata + approval	Model registry (MLflow)
Serving	LLM serving + autoscaling	vLLM, TGI
Monitoring	Drift, latency, cost per inference	Prometheus + custom metrics

Pola yang paling penting: model adalah artefak yang diregulasi seperti image — lewat registry, approval, dan deployment gate. Model yang tidak melalui jalur ini sama berbahayanya dengan image yang tidak ter-sign.

#AI sebagai Fitur Platform

Dua arah: platform untuk AI (di atas) dan AI untuk platform. Yang kedua adalah diferensiator 2026:

Auto-remediation — AI menganalisis alert dan runbook, lalu mengusulkan/menjalankan perbaikan yang sudah disetujui. Mulai dari yang aman: restart task, scale out, rollback ke versi stabil.
AI-assist di golden path — developer bertanya dalam bahasa alami ("deploy service ini ke staging dengan canary") dan platform menerjemahkannya ke action yang ter-governed.
Copilot untuk platform engineer — analisis log, investigasi incident, dan penulisan IaC yang di-review manusia.

100%

Aturan emasnya: AI boleh mengusulkan, manusia atau policy yang menyetujui dampak besar. AI mempercepat, policy memastikan tidak ada yang melanggar batas.

#Common Pitfalls

GPU dibiarkan menganggur — dipesan besar tapi dipakai kecil; ukur GPU utilization dan buat quota ketat.
LLM serving tanpa autoscaling berbasis GPU — antrian menumpuk saat traffic naik; pakai metrics inference (queue length, GPU utilization).
MLOps hanya untuk data scientist — tanpa golden path, tiap tim membangun pipeline sendiri yang tidak terkelola.
AI untuk platform tanpa guardrail — auto-remediation yang langsung eksekusi tanpa approval bisa menyebabkan bencana; mulai dari tindakan berisiko rendah.
Menganggap semua workload butuh GPU — banyak workload AI kecil lebih hemat di CPU; jadikan GPU sebagai resource istimewa yang diminta eksplisit.

Note

Platform engineering AI bukan berarti kalian harus menjadi data scientist. Tugas kalian adalah menyediakan jalur yang benar — GPU yang terkelola, serving yang terautomasi, model yang diregulasi — supaya tim AI bisa fokus pada model, dan platform tetap memegang kendali resource dan policy.

#Penutup

Inti yang harus dibawa pulang:

GPU adalah resource istimewa: node pool terpisah, quota ketat, autoscaling berbasis GPU.
LLM serving memakai runtime khusus (vLLM/TGI) dan punya pola scaling yang berbeda.
MLOps dijadikan golden path: tracking, training, registry, serving, dan monitoring yang seragam.
Model diregulasi seperti image: lewat registry, approval, dan deployment gate.
AI menjadi fitur platform (auto-remediation, AI-assist) — boleh usul, manusia/policy yang setujui.

Di episode 22 selanjutnya kita mengelola platform dari sisi produk: platform-as-a-product advanced — roadmap, user research developer, dan KPI platform berbasis DORA yang mengubah tim platform dari cost center menjadi tim produk sungguhan!