Belajar Cloud Engineer - AI & ML Services Cloud

#Pendahuluan

Di episode 22 kalian membangun infrastruktur lintas cloud. Sekarang mari bicara tentang workload yang paling cepat tumbuh tahun ini (dan sudah kalian baca di roadmap: AI workloads jadi fokus utama 2026): machine learning di cloud. Banyak orang mengira AI hanyalah "memanggil API chatbot". Padahal dari sisi infrastruktur, ML adalah beban kompute paling berat dan paling kompleks yang pernah ada — butuh GPU, pipeline data, dan serving yang stabil.

Episode 23 membahas AI & ML services cloud: tiga level penggunaan AI di cloud — AI APIs siap pakai, managed ML platform (Amazon SageMaker, Vertex AI, Azure ML), dan GPU workloads untuk training model besar. Kalian akan men-deploy model ML ke endpoint produksi yang siap melayani request nyata.

#Tiga Level AI di Cloud

Cara kalian memakai AI di cloud menentukan arsitektur, biaya, dan keahlian yang dibutuhkan:

Aturannya: mulai dari level terendah yang cukup. Jika masalahnya "deteksi wajah di foto", jangan training model sendiri — pakai API. Managed ML dan GPU baru relevan saat API tidak bisa memenuhi kebutuhan (model khusus, data privat, latensi, biaya).

#AI APIs: Kecerdasan Instan

Ini jalur tercepat: provider sudah melatih model besar dan menyediakannya sebagai API. Contoh nyata — mendeteksi sentimen teks:

aws comprehend detect-sentiment \
  --text "Saya suka layanan ini, sangat cepat!" \
  --language-code id

gcloud ml language entities \
  --content="Saya suka layanan ini" \
  --content-type PLAIN_TEXT

Yang perlu kalian pikirkan sebagai cloud engineer:

1. Latensi — panggilan API keluar region menambah delay; deploy di region dekat user.
2. Data privacy — data yang dikirim ke API publik tidak boleh sensitif (episode 15); beberapa data wajib diproses di VPC/region khusus.
3. Biaya per request — API AI dihitung per panggilan; workload besar lebih murah pakai model sendiri (episode 16).
4. Quota & throttling — API punya batas; desain retry dengan backoff.

#Managed ML: SageMaker, Vertex AI, Azure ML

Saat perlu model sendiri, managed ML platform menyelamatkan kalian dari mengelola server GPU manual. Alur umumnya sama di semua provider:

Lima tahap yang di-manage platform: data preparation, training, tuning, deployment (serving), monitoring — masing-masing punya job yang berjalan di infrastruktur yang disediakan provider.

Contoh sederhana men-deploy model ke endpoint di GCP Vertex AI:

gcloud ai models upload \
  --region=asia-southeast2 \
  --display-name=lab-sentiment-model \
  --artifact-uri=gs://lab-ml-models/sentiment/ \
  --container-image-uri=asia-docker.pkg.dev/vertex-ai/.../model-prediction:latest
 
gcloud ai endpoints create --region=asia-southeast2 --display-name=lab-endpoint
gcloud ai endpoints deploy-model ... --model=<MODEL_ID> --machine-type=n1-standard-4

Sekali endpoint hidup, aplikasi (web, function, microservice) memanggilnya lewat gRPC/REST. Yang jarang disadari pemula: model serving adalah beban produksi — dia perlu auto-scaling, monitoring, dan rollback (episode 9, 14, 21) sama seperti aplikasi biasa.

#GPU Workloads: Kapan dan Bagaimana

Training model besar (LLM, model vision dalam) butuh GPU. Di cloud, GPU adalah komoditas langka dan mahal:

• AWS: instance p4d/p5 (A100/H100), juga Trainium (chip khusus training).
• GCP: GPU A100/H100, TPU (chip custom Google).
• Azure: ND-series, juga akses klaster superkomputer Azure.

Fitur penting yang wajib dipahami:

1. Capacity quota — GPU dibatasi per region; ajukan kuota lebih awal.
2. Spot/interruptible — GPU spot jauh lebih murah (sampai 60-70%), tapi bisa dihentikan kapan pun — cocok untuk training yang tahan gangguan (checkpoint).
3. Harga sangat tinggi — jalankan 24/7 = tagihan besar; gunakan job-based: nyalakan GPU saat training, matikan setelah selesai (episode 8, 16).
4. Spot + job-based adalah kombinasi yang hampir wajib untuk training lab.

# request spot instance GPU, jalankan training, terminasi otomatis setelah selesai
aws ec2 run-instances \
  --instance-type p4d.24xlarge \
  --instance-market-options '{"MarketType":"spot","SpotOptions":{"SpotInstanceType":"one-time"}}'

#Men-deploy Model di Cloud: Praktik

Mari pasang model sederhana (misal classifier yang sudah dilatih) ke produksi:

1. Simpan artefak model di object storage (S3/GCS/Blob) — versi artefak wajib (episode 7).
2. Upload ke model registry (SageMaker/Vertex/Azure ML) — model jadi entitas terkelola.
3. Buat endpoint dengan machine type sesuai beban (mulai kecil, episode 16).
4. Uji endpoint dengan sample request; periksa latensi p50/p95 (episode 9, 25).
5. Sambungkan ke aplikasi — aplikasi lab-ecommerce memanggil endpoint untuk rekomendasi/sentiment.
6. Pasang monitoring — error rate, latensi, dan data drift (distribusi data berubah seiring waktu → model makin tidak akurat).

curl -s -X POST https://endpoint-asia-southeast2.aiplatform.googleapis.com/v1/predict \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -d '{"instances": [{"text": "pengiriman lama sekali!"}]}'

Kunci yang sering dilupakan: model yang sudah di-deploy bukan akhir pekerjaan — dia perlu di-monitor dan dilatih ulang berkala. Infrastructure for AI adalah siklus, bukan sekali jalan.

#Kesalahan Umum (Common Pitfalls)

1. Training model padahal API cukup — biaya dan waktu membengkak; mulai dari level terendah.
2. GPU dibiarkan hidup — tagihan malam hari yang tak terkendali; job-based + spot + auto-stop.
3. Data sensitif dikirim ke API publik — privacy violation (episode 15); pilih region/VPC yang tepat.
4. Endpoint tanpa scaling & monitoring — lonjakan request mematikan inference; terapkan episode 9 dan 21.
5. Mengabaikan data drift — model akurat bulan lalu, tidak sekarang; pantau kualitas prediksi.
6. Quota GPU tidak dipersiapkan — butuh GPU mendadak tapi kuota belum diajukan; ajukan sejak awal.

#Penutup

Inti yang harus dibawa pulang:

• Pilih dari tiga level AI: AI APIs (instan), managed ML (model sendiri), GPU workloads (training besar).
• Managed ML (SageMaker/Vertex/Azure ML) menangani training, serving, dan monitoring sebagai layanan.
• GPU adalah komoditas langka dan mahal — kuota diajukan dini, training job-based, pakai spot.
• Model serving adalah beban produksi biasa: scaling, monitoring, rollback, dan data drift.
• Infrastruktur AI = siklus: data → training → deploy → monitor → latih ulang.

Di episode 24 selanjutnya kita akan mendekatkan komputasi ke user: edge & serverless advanced — edge computing, CDN + functions, dan IoT cloud, lalu menjalankan workload di edge yang menanggapi dengan latensi sangat rendah. Sampai jumpa di episode 24!