Belajar Cloud Architect - AI & ML Architecture
AI/ML mengubah cara kita merancang arsitektur: GPU mengubah biaya compute, model butuh data terkelola, dan LLM memperkenalkan pola baru. Episode ini membahas arsitektur workload AI/GPU, managed ML pipelines, RAG untuk LLM, dan desain data yang menopang semuanya
#Pendahuluan
AI bukan lagi proyek riset — ia workload produksi yang harus dirancang seperti workload lain: dengan trade-off, biaya, dan operasional yang dihitung (episode 3, 8, 9). Perbedaannya: AI memperkenalkan tantangan baru yang belum pernah ada di episode 4-5 — GPU mahal, model berubah cepat, dan data menjadi bahan bakar utama.
Episode ini membangun arsitektur AI/ML yang realistis: kapan memakai GPU, bagaimana managed ML pipeline bekerja, pola RAG untuk LLM, dan mengapa kualitas data lebih menentukan hasil daripada model.
#Arsitektur Workload AI/GPU
#Compute untuk AI
Melatih model (training) dan menjalankan model (inference) butuh GPU — resource termahal di cloud. Dua pertanyaan arsitektur utama:
- Melatih sendiri atau pakai managed?
- Menjalankan model di GPU sendiri atau pakai API model (managed)?
| Pilihan | Karakter | Dipakai Ketika |
|---|---|---|
| GPU self-managed (VM) | Kontrol penuh, biaya tetap tinggi | Training besar, kontrol maksimal |
| GPU managed (SageMaker, Vertex AI) | Managed, biaya per pemakaian | Training/menjalankan tanpa kelola GPU |
| API model (OpenAI, Bedrock) | Tanpa GPU sama sekali | Inference siap pakai, tanpa infrastruktur |
Aturan praktis 2026: inference sebagian besar lewat API model; GPU hanya untuk training kustom atau inference yang butuh kontrol/latency ketat. Menjalankan GPU sendiri untuk hal yang bisa dipakai API-nya adalah pemborosan besar.
aws ec2 describe-instance-types \
--filters "Name=instance-type,Values=p4d*" \
--query 'InstanceTypes[].{Type:InstanceType,Gpu:ProcessorInfo}'Perhatikan biaya: satu instance GPU bisa lebih mahal dari selusin instance CPU. Arsitektur AI wajib menghitung cost per inference sejak awal (episode 9).
#Managed ML Pipelines
#Pipeline ML Standar
Proses ML bukan hanya "training model" — ia pipeline yang harus diotomasi:
Managed ML pipeline (SageMaker Pipelines, Vertex AI Pipelines) mengotomasi seluruhnya — data versioning, training, evaluasi, registry, deployment. Bagi arsitek, ini menghilangkan beban mengelola infrastruktur ML dan memberi reproducibility (versi data + kode + konfigurasi terdokumentasi).
#Bagian yang Sering Terlupakan: Data
Model sebaik kualitas datanya. Arsitektur ML wajib menjawab:
- Darimana data training berasal? — data lake dari episode 5.
- Bagaimana versioning data? — perubahan data harus bisa dilacak ke model mana yang memakainya.
- Bagaimana data bersih & konsisten? — tanpa data berkualitas, model apapun gagal.
- Bagaimana drift terdeteksi? — distribusi data berubah seiring waktu → model menurun.
Tip
Ingat pelajaran episode 5: arsitektur data (data lake + warehouse) adalah fondasi arsitektur ML. Jangan membangun model di atas data yang tidak terkelola — 80% effort proyek ML produksi ada di data, bukan di model.
#RAG dan LLM Architecture
#Apa itu RAG
RAG (Retrieval-Augmented Generation) menjawab kelemahan LLM: model tidak tahu data internal kalian dan bisa "berhalusinasi". RAG menggabungkan retrieval (mencari dokumen yang relevan dari knowledge base) dengan generation (LLM menyusun jawaban dari dokumen itu).
#Pola RAG
Alur lengkapnya: dokumen di-embedding menjadi vektor → disimpan di vector database → saat user bertanya, pertanyaan di-embedding dan dicari dokumen paling mirip (top-k) → LLM menyusun jawaban dengan konteks itu.
#Keputusan Arsitektur RAG
| Komponen | Pilihan | Pertimbangan |
|---|---|---|
| Vector DB | OpenSearch, Pinecone, pgvector | Skala, ekosistem yang sudah ada |
| Embedding | Managed API atau self-host | Biaya vs kontrol |
| LLM | API model vs self-host | Latency, biaya, kepatuhan data |
| Chunking & pipeline dokumen | Custom vs managed | Kualitas retrieval sangat bergantung ini |
Kesalahan umum: fokus pada memilih LLM, lupa bahwa kualitas retrieval menentukan kualitas jawaban. Chunking dokumen, pemilihan metadata, dan pipeline ingestion lebih berdampak pada hasil daripada model yang dipakai.
#Data untuk AI
#Karakter Data yang Bagus
- Bersih — tanpa duplikasi, tanpa PII yang bocor tanpa izin.
- Berversi — tiap training set bisa dilacak ke sumbernya.
- Terkelola aksesnya — data training tidak boleh lebih terbuka dari data produksi (episode 18).
- Terukur kualitasnya — metrik kualitas data adalah SLI data (episode 10).
#Data Pipeline untuk AI
Gunakan fondasi episode 5: data lake menyimpan data mentah, pipeline cleansing menghasilkan dataset siap-training, feature store menyediakan fitur konsisten untuk training & inference. Arsitektur ini memastikan data training dan inference berasal dari sumber yang sama — kunci reproducibility.
#Praktik: Mendesain AI Platform
Kerangka desain platform AI produksi:
- Compute: API model untuk inference umum; GPU hanya untuk kebutuhan nyata.
- Pipeline: managed ML pipeline untuk training + evaluasi + registry.
- Data: gali dari data lake; versioning data; deteksi drift.
- LLM: pola RAG dengan vector DB; fokus pada kualitas retrieval.
- Cost: hitung cost per inference; awasi biaya GPU (episode 9).
- Compliance: data yang masuk ke model melewati aturan residency & PII (episode 15, 20).
#Penutup
Inti yang harus dibawa pulang:
- Inference umum via API model; GPU hanya saat kontrol/latency menuntut.
- Managed ML pipelines mengotomasi training→registry→deploy dengan reproducibility.
- Kualitas data lebih menentukan hasil daripada pilihan model.
- RAG = retrieval + generation; fokus pada kualitas retrieval & chunking.
- Cost per inference dan kepatuhan data adalah bagian desain, bukan pasca-produksi.
Di episode 18 selanjutnya kita akan membahas identity & access architecture — desain IAM, federasi SSO, service identity, dan hierarki policy. Sampai jumpa di episode 18!