Ketika job pelatihan ML batch tiba-tiba mengonsumsi CPU dan GPU melebihi ekspektasi, biaya operasional bertumbuh tanpa kontrol. Artikel ini menjawab langsung bagaimana menelusuri gejala awal, menemukan penyebab utama, dan menerapkan perbaikan yang konkret untuk menjaga biaya terkendali.

Gejala Awal Cost Spike pada Job ML

Dalam kasus nyata yang mirip dengan bocoran keuangan OpenAI, biaya menanjak setelah job ML tertentu mengalami

  • Spike CPU/GPU pada node worker tanpa peningkatan job yang proporsional, akibat antrian job lain tidak bergerak.
  • Antrean job menumpuk karena satu job menahan resource yang tidak pernah selesai, sementara scheduler terus menambahkan job baru.
  • Retry loop tak terbatas yang terus menjalankan ulang job gagal, sehingga jumlah instance aktif mencapai puluhan atau ratusan.

Deteksi dini menggunakan resource monitoring (misalnya top, kubectl top pods, atau dashboard Grafana) membantu memfilter job yang bertingkah abnormal.

Diagnosis Root Cause

Setelah gejala teridentifikasi, langkah diagnosa lebih mendalam bisa menjawab "mengapa" biaya melesat.

Misinterpretasi Parameter Dataset

Job ML batch sering dikonfigurasi dengan parameter dataset (misalnya batch size, jumlah shard, filter temporer) yang dapat menyebabkan job memproses volume data jauh lebih besar dari yang dimaksudkan. Kesalahan paling umum adalah menyuplai path dataset tanpa pembatasan atau salah membaca schema, sehingga job berjalan pada seluruh dataset produksi alih-alih subset.

Periksa parameter input di file config (YAML/JSON) atau environment variable. Bandingkan jumlah record yang diproses dengan ekspektasi untuk memastikan tidak terjadi data explosion.

Backoff Retry Tidak Terbatas

Beberapa workflow engine otomatis meretry job dengan interval tetap hingga berhasil. Namun jika job gagal karena konfigurasi (contoh: quota API) dan retry tanpa penundaan atau batas, sistem malah memperbanyak concurrent job.

Solusi diagnostik: cek log scheduler/retry controller dan pastikan terdapat retry limit dan exponential backoff. Parameter seperti maxRetries dan backoffPolicy harus diset eksplisit, jangan bergantung default.

Konfigurasi Quota Hilang atau Terhapus

Ketidakhadiran quota resource (CPU, GPU, node group) pada scheduler/kubernetes menyebabkan job saling berebut resource. Dalam kasus tertentu, quota yang awalnya mencegah job bertumpuk terhapus karena redeploy atau human error.

Audit ruang lingkup resource quota di namespace terkait. Pastikan ada LimitRange dan ResourceQuota yang menahan alokasi maksimum per job.

Langkah Perbaikan Praktis

Setelah akar masalah teridentifikasi, lakukan langkah-langkah berikut secara sistematis.

Perbaiki Konfigurasi Scheduler

Contoh sederhana pada Kubernetes CronJob/Argo Workflows: tetapkan concurrencyPolicy menjadi Forbid atau Replace, dan tambahkan limit server-side.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: ml-training-batch
spec:
  schedule: "0 2 * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: trainer
            image: registry.example/ml:latest
            resources:
              limits:
                cpu: "4"
                memory: "16Gi"
              requests:
                cpu: "2"
                memory: "8Gi"
          restartPolicy: OnFailure
          backoffLimit: 3

Pengaturan backoffLimit membatasi percobaan ulang, sementara concurrencyPolicy mencegah job baru dimulai sebelum job saat ini selesai.

Tambahkan Alert Batas Resource

Implementasikan alert berbasis metric (CPU, GPU, antrean job) sehingga tim tahu sebelum biaya meledak. Tools seperti Prometheus + Alertmanager bisa dipakai untuk mengirim notifikasi saat:

  • CPU usage > 90% lebih dari 5 menit.
  • Jumlah job gagal > threshold per jam.
  • Retry rate meningkat secara tiba-tiba.

Alert memungkinkan tindakan cepat untuk scale down atau menonaktifkan job.

Perkuat Observability

Tambahkan tracer atau log yang melacak parameter input, jumlah shard, dan durasi setiap bagan dari job.

Gunakan context propagation agar setiap job dapat dilacak ke permintaan asli, dan hubungkan log dengan metrik resource.

Uji Ulang Setelah Perubahan

Jangan langsung deploy ke produksi. Lakukan tes end-to-end pada staging dengan simulasi dataset terbatas dan verifikasi batas resource. Pantau apakah job merespek quota dan backoff.

Verifikasi Perbaikan dan Rekomendasi Preventif

Verifikasi dilakukan dengan membandingkan metrik sebelum dan sesudah perbaikan: CPU per job, jumlah retry, durasi finishing. Gunakan dashboard untuk membuktikan bahwa job tidak lagi memperbanyak concurrency.

Rekomendasi preventif:

  • Dokumentasikan parameter dataset dan batasannya.
  • Tetapkan runbooks untuk mengatasi job retry loop.
  • Lakukan peninjauan konfigurasi scheduler setiap kali ada perubahan workflow.
  • Pastikan alert di-forward ke on-call yang dapat langsung memutus eksekusi job jika diperlukan.

Dengan proses ini, biaya operasional bisa tetap stabil bahkan saat skala job ML bertambah.