Belajar AI - MLOps & Deployment

#Pendahuluan

Setelah 17 episode membangun kemampuan teknis dan kepatuhan, episode ini masuk ke fase yang menentukan nasib produksi: MLOps dan deployment. Model yang hebat di notebook adalah biaya, bukan aset — ia baru menjadi aset ketika bisa diserve dengan andal, dimonitor, dan diperbarui tanpa downtime.

Mengapa episode ini penting? Karena pola kegagalan paling umum proyek AI bukan "modelnya tidak akurat", melainkan "model bekerja di notebook tapi tidak pernah sampai ke produksi" atau "model di produksi diam-diam menurun performanya". MLOps adalah disiplin yang menjembatani keduanya.

#Model Registry

Model registry adalah "sistem kontrol versi" untuk model — menyimpan model, versi, metadata (data training, metrik, siapa yang membuat), dan status siklus hidupnya. MLflow (episode 11) menyediakan ini, begitu juga W&B dan platform lain.

Alur standarnya: model lulus evaluasi → naik ke staging untuk pengujian → disetujui ke production → diarsipkan saat digantikan. Setiap model produksi harus bisa dijawab: berapa versinya, dilatih dengan data apa, skor berapa? — tautan langsung ke audit trail episode 17.

#CI/CD untuk Machine Learning

CI/CD klasik otomatis men-build dan men-deploy kode. Untuk ML, pipeline-nya diperluas:

Pola yang dianjurkan: semua perubahan (data, kode, model) melewati pipeline yang sama dan hanya lolos jika syarat terpenuhi — model tidak boleh naik produksi jika skor evaluasinya di bawah baseline, atau jika data training-nya tidak valid.

#Serving Model: vLLM, TorchServe, Triton

Model harus diserve sebagai API. Tiga opsi utama:

• vLLM: standar de facto untuk serving LLM — sangat cepat (paging attention, continuous batching), kompatibel OpenAI API, efisien memori.
• TorchServe: serving model PyTorch umum (CV, NLP, tabular) dengan API terkelola.
• Triton Inference Server (NVIDIA): platform serving multi-framework, optimal untuk produksi skala besar dan multi-GPU.

vllm serve Qwen/Qwen2.5-7B-Instruct \
  --port 8000 \
  --max-model-len 8192

Setelah berjalan, endpoint /v1/chat/completions — format OpenAI-compatible yang kita pakai di episode 14 — siap dipanggil aplikasi kalian.

#Container dan Kubernetes

Model diserve dalam container (Docker) agar konsisten di semua environment, lalu diorkestrasi dengan Kubernetes untuk skala dan self-healing:

FROM vllm/vllm-openai:latest
CMD ["--model", "Qwen/Qwen2.5-7B-Instruct", "--port", "8000"]

Kubernetes menangani hal yang bukan urusan model: auto-scaling saat beban naik, restart saat crash, dan distribusi GPU. Ini topik yang bisa kalian perdalam di series belajar-kubernetes — di sini yang penting adalah polanya: model = workload yang sama seperti service lain.

#Serverless

Untuk model kecil atau pemakaian tidak menentu, serverless (misal AWS Lambda, Cloud Run, atau provider serverless LLM) menawarkan skala nol-ke-besar tanpa mengelola server:

• Keunggulan: tidak ada idle cost, skala otomatis.
• Kekurangan: cold start (latensi tambahan), batas memori, biaya per-invocation untuk model besar sering lebih mahal.

Pilihan pragmatis: serverless untuk aplikasi yang jarang dipakai & model kecil; dedicated (vLLM/K8s) untuk beban stabil atau model besar.

#Monitoring: Drift dan Kualitas

Masalah terbesar ML di produksi: model yang akurat saat training menurun karena dunia berubah. Ini disebut drift, dan ada tiga jenis:

import numpy as np
 
def report_drift(train_mean: float, prod_mean: float,
                 train_std: float, threshold: float = 2.0) -> str:
    z = abs(prod_mean - train_mean) / train_std
    return "ALERT: drift" if z > threshold else "normal"
 
print(report_drift(train_mean=0.42, prod_mean=0.61,
                   train_std=0.08))

#Observability GenAI dengan OpenTelemetry

OpenTelemetry (OTel) — standar open-source untuk tracing, metrics, dan logs — kini memiliki dukungan untuk GenAI: semantic conventions khusus untuk LLM (span jenis gen_ai.operation, atribut gen_ai.model.name, dll). Ini memungkinkan kalian men-trace satu permintaan end-to-end: user → guardrail → retrieval → LLM → tool → respons.

from opentelemetry import trace
 
tracer = trace.get_tracer("genai-app")
with tracer.start_as_current_span("chat-completion") as span:
    span.set_attribute("gen_ai.model.name", "qwen3:8b")
    response = llm_call(messages)
    span.set_attribute("gen_ai.usage.completion_tokens", response.usage)

Metrik penting yang dipantau untuk aplikasi GenAI:

• Latency: waktu per request (p50/p95).
• Tokens per request (input & output) — berkorelasi langsung dengan biaya.
• Error & retry rate.
• Kualitas: skor evaluasi otomatis (groundedness, relevance — episode 8) pada sampel lalu lintas.
• Cost per user / per request.

#Common Pitfalls

• Deploy model tanpa registry: tidak tahu versi mana yang hidup di produksi.
• Promote model tanpa threshold: model boleh naik produksi berapa pun skornya.
• Memonitor hanya uptime: drift dan kualitas lebih menentukan nasib sistem AI.
• Tanpa rollback plan: perubahan model/prompt harus punya jalur mundur cepat.
• Melupakan cost per token: model besar di semua request = tagihan membengkak.

#Penutup

Inti yang harus dibawa pulang:

• Model registry mengelola versi & siklus hidup model; CI/CD ML memvalidasi data, training, dan evaluasi sebelum naik produksi.
• Serving: vLLM (LLM), TorchServe (PyTorch umum), Triton (skala besar); container + Kubernetes untuk orkestrasi, serverless untuk beban rendah.
• Monitoring wajib: data/concept drift dan kualitas GenAI — bukan hanya uptime.
• OpenTelemetry memperluas observability ke GenAI: trace LLM, ukur latency, token, error, dan biaya.

Di episode 19 selanjutnya kita akan mengoptimalkan sisi finansial: Scale & Cost Optimization — GPU inference, kuantisasi (GGUF, AWQ), caching, batching, model routing, dan strategi hybrid self-host vs API untuk menekan biaya tanpa mengorbankan kualitas. Sampai jumpa di episode 19!