AWS Batch Quota SageMaker Rilis: Trik Pinjam GPU Antartim

Kenapa Pengaturan Kuota GPU di SageMaker Sering Bikin Ribet?

Sebelum ada update ini, AWS Batch emang udah ngasih dukungan buat SageMaker Training jobs biar kita bisa ngantre, ngejadwalin, dan ngejalanin retry tugas ML tanpa repot bangun infrastruktur sendiri. Tapi pas organisasi makin gede dan tim yang gabung makin banyak, ngatur akses ke kapasitas GPU bersama ini ternyata ngelahirin masalah baru buat para admin.

Admin biasanya kudu repot nyiapin antrean terpisah buat tiap tim, ngutak-atik limit kapasitas bolak-balik, dan ngepas-ngepasin beban kerja biar dapat jatah di waktu yang pas. Komunikasi antartim jadi panjang cuma buat nanya, "Server GPU kamu lagi dipakai nggak? Boleh pinjam dulu nggak?" Kalau kapasitas lagi kepakai terus pemilik aslinya butuh mendadak, admin kudu nyari tahu job mana yang lagi minjam terus matiin manual. Ini jelas makan waktu banget dan rawan salah paham.

Lewat masukan dari para pengguna yang ngelola lingkungan training multi-tim, AWS ngerancang sistem yang bisa nentuin alokasi per tim atau proyek, ngebagi kapasitas nganggur secara otomatis, dan ngejalanin tugas prioritas paling tinggi lebih dulu. Nah, jawaban dari kebutuhan itu adalah quota management di AWS Batch.

Mengenal Konsep Quota Shares dan Cara Kerjanya

Inti dari fitur baru ini adalah membagi kapasitas komputasi yang terbatas jadi bagian-bagian virtual yang namanya quota shares. Quota share ini kayak antrean virtual yang nempel di dalam job queue utama AWS Batch.

Di tiap quota share, admin bisa nentuin batas kapasitas komputasi (misalnya jenis dan jumlah instance GPU tertentu) barengan sama strategi pembagian sumber daya (resource-sharing strategies) pas komputasi lagi nganggur. Waktu ngejadwalin tugas di dalam job queue, AWS Batch bakal ngecek dan mendahulukan quota share yang pemakaiannya masih di bawah batas kapasitas.

Kalau ada tugas baru masuk ke quota share yang kapasitasnya lagi dipinjam tim lain, AWS Batch bakal ngelakuin penarikan otomatis yang namanya cross-share preemption. Admin nggak perlu lagi pusing nyariin siapa yang minjam terus ngehentiin job itu secara manual. Sebaliknya, kalau ada tugas masuk ke quota share yang udah mentok kapasitasnya, sistem bakal ngecek apa ada kapasitas nganggur dari tim lain yang bisa dipinjam. Kalau ada, tugas itu bisa langsung jalan pakai kapasitas yang tadinya nganggur tadi.

Tiga Strategi Berbagi GPU: Reserve, Lend, dan Lend & Borrow

Pas kamu nyetel quota share, kamu bisa milih salah satu dari tiga strategi alokasi kapasitas nganggur sesuai kebutuhan tiap tim. Ini tiga pilihannya:

1. RESERVE: Kapasitas GPU bener-bener dikunci khusus buat tim pemilik kuota. Pas tim lagi nggak ada job, GPU bakal tetap dibiarin kosong nungguin tugas datang. Kuota ini nggak bakal dipinjamkan ke tim mana pun, dan tim ini juga nggak bakal minjam kapasitas dari luar. Pilihan ini pas banget buat beban kerja super penting yang nggak boleh kena interupsi sama sekali.
2. LEND: Tim bersedia minjemin kapasitas GPU miliknya ke tim lain kalau lagi nganggur. Tapi, tim ini milih buat nggak minjam kuota dari luar. Begitu tim pemilik ngirim job baru, sistem bakal langsung narik kapasitasnya balik. Strategi ini pas buat tugas prioritas menengah atau job pendek yang pengin antre biasa aja tanpa mau kena risiko preemption gara-gara minjam kuota luar.
3. LEND_AND_BORROW: Strategi paling fleksibel dan hemat. Tim siap minjemin GPU pas nganggur, sekaligus boleh minjam kapasitas sisa dari tim lain waktu kerjaan mereka lagi numpuk di atas jatah kuota normal. Strategi ini cocok banget buat tugas latar belakang (background jobs) atau riset eksperimen yang udah pasang sistem checkpointing rapi.

Biar gampang ngebandingin ketiganya, kamu bisa lihat tabel ringkas berikut:

Perbedaan Cross-Share Preemption dan In-Share Preemption

Istilah preemption di sini artinya penghentian sementara tugas yang lagi jalan demi ngasih jalan ke tugas lain yang lebih berhak. Di sistem quota management AWS Batch, preemption dibagi jadi dua skenario yang berbeda banget:

1. Cross-Share Preemption (Antartim)

Cross-share preemption kejadian pas kapasitas yang lagi dipinjam ditarik balik sama tim yang punya kuota asli. Contohnya gini: Tim QS1 (pakai LEND_AND_BORROW) lagi minjam 1 instance GPU jatah Tim QS2 (yang pakai LEND).

Tiba-tiba Tim QS2 ngirim job training baru. Tanpa nunggu admin bertindak, AWS Batch bakal langsung ngehentiin job Tim QS1 yang minjam tadi dan balikin statusnya jadi RUNNABLE di antrean. Kapasitas GPU langsung balik ke tangan Tim QS2 seketika.

2. In-Share Preemption (Di Dalam Tim Sendiri)

Kalau cross-share preemption urusannya antartim, in-share preemption kejadian di dalam satu quota share yang sama berdasarkan angka prioritas. Fitur ini bisa kamu aktifin lewat parameter in_share_preemption=True.

Misalkan kuota tim kamu lagi penuh kepakai sama tugas prioritas rendah (misalnya prioritas 1 atau 2). Terus ada data scientist di tim kamu yang ngirim tugas mendesak dengan prioritas lebih tinggi (misalnya prioritas 3 atau 4). AWS Batch bakal langsung ngehentiin tugas prioritas rendah yang lagi berstatus SCHEDULED, STARTING, atau RUNNING, biar tugas baru yang prioritasnya tinggi bisa langsung jalan duluan di antrean.

Persiapan dan Setup Komponen Quota Management

Buat nyobain fitur penjadwalan kuota ini, kamu butuh akun AWS yang punya izin IAM buat manggil API AWS Batch dan SageMaker. Selain itu, kamu butuh SageMaker Python SDK v3 yang kompatibel.

Kamu bisa langsung install atau update pustakanya lewat terminal atau notebook environment:

!pip install sagemaker

Ada empat komponen utama yang kudu disiapin bareng-bareng:

1. Scheduling Policy: Kebijakan penjadwalan yang nyimpen konfigurasi quotaSharePolicy.
2. Service Environment: Lingkungan komputasi yang nentuin batasan kapasitas fisik berdasarkan jenis instance GPU tertentu.
3. SageMaker Training Job Queue: Antrean tugas training yang nyambungin Scheduling Policy dan Service Environment.
4. Quota Shares: Pembagian kuota virtual yang ditempelin ke Job Queue.

Tutorial Konfigurasi Tiga Quota Share di Python

Biar makin kebayang, kita bakal bikin skenario dengan tiga quota share berbeda buat tiga proyek di satu tim besar. Masing-masing dapet jatah batas kapasitas 1 instance ml.g5.xlarge:

• QS1 (Background Jobs): Pakai strategi LEND_AND_BORROW, in_share_preemption=True, dan batas pinjam 200%. Di sini tugas nggak ada yang buru-buru, dan preemption nggak masalah karena semua tugas pakai checkpointing.
• QS2 (Medium Priority): Pakai strategi LEND dan in_share_preemption=False. Tim ini mending nunggu kapasitas normal daripada harus sering kena preemption, cocok buat job yang lebih pendek.
• QS3 (Urgent / Reserved): Pakai strategi RESERVE dan in_share_preemption=False. Kapasitas bener-bener dikunci, nggak minjemin dan nggak minjam, biar kerjaan bisa jalan secepatnya tanpa interupsi.

Berikut potongan kode Python buat nyiapin konfigurasinya pakai helper function dari sample notebook AWS:

from sagemaker.train.aws_batch.boto_client import get_batch_boto_client
from utils.aws_batch_resource_management import (
    AwsBatchResourceManager,
    QuotaShareConfig,
    create_quota_management_resources
)

INSTANCE_TYPE = "ml.g5.xlarge"
resource_manager = AwsBatchResourceManager(get_batch_boto_client())

# 1. Konfigurasi QS1: Background jobs
qs1 = QuotaShareConfig(
    name="QS1",
    capacity_unit=INSTANCE_TYPE,
    max_capacity=1,
    in_share_preemption=True,
    sharing_strategy="LEND_AND_BORROW",
    borrow_limit=200
)

# 2. Konfigurasi QS2: Medium priority workloads
qs2 = QuotaShareConfig(
    name="QS2",
    capacity_unit=INSTANCE_TYPE,
    max_capacity=1,
    in_share_preemption=False,
    sharing_strategy="LEND"
)

# 3. Konfigurasi QS3: Workload kritis tanpa interupsi
qs3 = QuotaShareConfig(
    name="QS3",
    capacity_unit=INSTANCE_TYPE,
    max_capacity=1,
    in_share_preemption=False,
    sharing_strategy="RESERVE"
)

# Bikin Scheduling Policy, Service Environment, dan Job Queue barengan
SCHEDULING_POLICY_NAME = "my-qm-scheduling-policy"
JOB_QUEUE_NAME = "my-sm-training-qm-jq"
SERVICE_ENVIRONMENT_NAME = "my-sm-training-qm-se"

resources = create_quota_management_resources(
    resource_manager=resource_manager,
    scheduling_policy_name=SCHEDULING_POLICY_NAME,
    job_queue_name=JOB_QUEUE_NAME,
    service_environment_name=SERVICE_ENVIRONMENT_NAME,
    capacity_unit=INSTANCE_TYPE,
    max_capacity=3,
    quota_share_configs=[qs1, qs2, qs3]
)

Di script ini, kapasitas maksimal Service Environment diisi 3 instance ml.g5.xlarge, ngepas sama total alokasi maksimal dari gabungan QS1, QS2, dan QS3.

Cara Kirim SageMaker Training Jobs ke Quota Share

Setelah resource selesai dibuat, modul aws_batch di dalam SageMaker Python SDK udah siap kamu pakai buat ngirim job training langsung ke antrean yang terhubung sama quota management.

Kita contohin pakai job sederhana PyTorch 2.5:

import logging
from sagemaker.core.helper.session_helper import Session
from sagemaker.core import image_uris
from sagemaker.train.model_trainer import ModelTrainer
from sagemaker.train.configs import SourceCode, Compute, StoppingCondition
from sagemaker.train.aws_batch.training_queue import TrainingQueue, TrainingQueuedJob
from utils.aws_batch_resource_management import JobStatus, await_jobs, list_jobs_by_quota_share

session = Session()
image_uri = image_uris.retrieve(
    framework="pytorch",
    region=session.boto_session.region_name,
    version="2.5",
    instance_type=INSTANCE_TYPE,
    image_scope="training",
)

# Siapkan ModelTrainer sederhana
model_trainer = ModelTrainer(
    training_image=image_uri,
    source_code=SourceCode(command="echo 'Hello World Training Job'"),
    base_job_name="hello-world-simple-job",
    compute=Compute(instance_type=INSTANCE_TYPE, instance_count=1),
    stopping_condition=StoppingCondition(max_runtime_in_seconds=300),
)

# Hubungkan ke Job Queue
queue = TrainingQueue(JOB_QUEUE_NAME)

Sekarang kita kirim tiga job sekaligus ke QS1 dengan tingkatan prioritas yang beda-beda:

# Kirim tiga job ke QS1 dengan prioritas 3, 2, dan 1
qs1_job_high: TrainingQueuedJob = queue.submit(
    job_name="qs1_job_high",
    training_job=model_trainer,
    quota_share_name=qs1.name,
    priority=3,
    inputs=None
)
qs1_job_med: TrainingQueuedJob = queue.submit(
    job_name="qs1_job_med",
    training_job=model_trainer,
    quota_share_name=qs1.name,
    priority=2,
    inputs=None
)
qs1_job_low: TrainingQueuedJob = queue.submit(
    job_name="qs1_job_low",
    training_job=model_trainer,
    quota_share_name=qs1.name,
    priority=1,
    inputs=None
)

# Tunggu transisi status job
await_jobs([([qs1_job_high, qs1_job_med], JobStatus.dispatched() | JobStatus.terminal())])
list_jobs_by_quota_share(queue, [qs1.name, qs2.name, qs3.name], JobStatus.active())

Karena di awal belum ada job yang jalan di QS1 maupun QS2, dua job pertama (qs1_job_high dan qs1_job_med) bakal langsung jalan berbarengan. Job pertama pakai jatah kuota asli QS1, sedangkan job kedua berhasil minjam jatah kapasitas QS2 yang kebetulan lagi kosong. Job ketiga (qs1_job_low) bakal sabar nunggu di antrean.

Nyobain Cross-Share Preemption Pas Tim Pemilik Butuh GPU

Sekarang kita tes gimana reaksinya kalau tim pemilik QS2 tiba-tiba ngirim kerjaan training pas kapasitasnya lagi dipinjam sama QS1:

# Tim QS2 ngirim satu job
qs2_job_1: TrainingQueuedJob = queue.submit(
    job_name="qs2_job_1",
    training_job=model_trainer,
    quota_share_name=qs2.name,
    priority=1,
    inputs=None
)

# Tunggu proses preemption berjalan otomatis
await_jobs([
    ([qs2_job_1], JobStatus.dispatched() | JobStatus.terminal()),
    ([qs1_job_med], {JobStatus.RUNNABLE}) # Job QS1 terendah yang minjam bakal dipreempt
])
list_jobs_by_quota_share(queue, [qs1.name, qs2.name, qs3.name], JobStatus.active())

Begitu qs2_job_1 masuk, AWS Batch langsung ngelakuin cross-share preemption. Tugas qs1_job_med yang minjam kapasitas ditarik balik statusnya jadi RUNNABLE, dan instance GPU langsung diserahin ke qs2_job_1. Nggak perlu koordinasi manual di Slack atau nunggu admin turun tangan, sistem langsung beres nanganin sendiri.

Trik Naikkan Prioritas Job Antrean Pakai UpdateServiceJob API

Gimana kalau tiba-tiba bos minta tugas qs1_job_low yang masih antre diselesaiin sekarang juga? Kamu nggak usah panik ngehapus job terus ngulang submit dari awal. AWS Batch nyediain API baru bernama UpdateServiceJob yang bikin kamu bisa ngeganti angka prioritas job yang udah masuk antrean.

# Naikkan prioritas qs1_job_low jadi prioritas tertinggi (angka 4)
qs1_job_low.update(scheduling_priority=4)

await_jobs([
    ([qs1_job_low], JobStatus.dispatched() | JobStatus.terminal()),
    ([qs1_job_high], {JobStatus.RUNNABLE}) # Job prioritas lebih rendah di share yang sama bakal dipreempt
])
list_jobs_by_quota_share(queue, [qs1.name, qs2.name, qs3.name], JobStatus.active())

Karena di awal kita udah pasang in_share_preemption=True di QS1 dan nggak ada kapasitas nganggur yang bisa dipinjam dari tim lain, kenaikan prioritas ini bakal langsung memicu in-share preemption. Job qs1_job_high yang tadinya lagi jalan bakal dihentikan sementara ke status RUNNABLE, dan qs1_job_low langsung meluncur jalan duluan.

Setelah semua eksperimen selesai, kamu bisa beresin resource yang udah dibikin tadi biar nggak kena charge yang nggak perlu:

from utils.aws_batch_resource_management import delete_resources

delete_resources(resource_manager, resources)

Kalau kamu lagi pengin ningkatin skill rekayasa prompt dan manajemen alur kerja AI buat tim developer kamu, kamu bisa ikutan kelas AI untuk Developer di Classai.

Kamu adalah seorang Cloud Infrastructure Engineer. Buatlah skrip rekomendasi konfigurasi AWS Batch Quota Management dalam Python untuk 3 tim riset:1. Tim Rekomendasi (training terjadwal tiap jam, butuh kepastian tanpa preemption, limit 2 GPU).2. Tim Generatif (riset eksperimen LLM, toleran preemption dan pakai checkpoint S3, butuh pinjam GPU nganggur).3. Tim Analisis Data (hanya jalan sewaktu-waktu di akhir pekan, siap meminjamkan kuota saat hari kerja). Tentukan sharing_strategy dan in_share_preemption yang paling pas untuk masing-masing tim beserta penjelasannya.

Dampak Nyata Buat Tim AI dan Perusahaan di Indonesia

Buat ekosistem teknologi di Indonesia, sewa instance GPU di penyedia cloud publik kayak AWS sering jadi salah satu pengeluaran paling gede di neraca keuangan startup maupun enterprise. Fitur AWS Batch quota management ini ngasih beberapa efek positif yang kerasa banget:

1. Hemat Biaya Infrastruktur Cloud (FinOps): Banyak tim beli atau pesan instance GPU lewat reserved capacity tapi utilisasinya cuma 40-50% karena ada jam-jam kosong pas developer lagi istirahat. Dengan skema pinjam-meminjam kuota otomatis ini, tiap dolar yang kamu keluarin buat sewa GPU jadi jauh lebih efisien.
2. Kombinasi Klop Bareng SageMaker AI Training Plans: Fitur ini nyambung banget kalau perusahaan kamu pakai SageMaker AI training plan. Kamu bisa nentuin kuota reservasi kapasitas yang dibutuhin buat jangka waktu tertentu, terus ngebaginya secara dinamis ke tiap divisi pakai AWS Batch tanpa takut bentrok.
3. Kerja Tim Lebih Santai Tanpa Drama Birokrasi: Nggak ada lagi cerita developer saling sindir di grup chat kantor cuma gara-gara job training modelnya gagal jalan karena server GPU kepenuhan. Sistem kuota yang adil dan transparan bikin kolaborasi antartim jadi lebih rapi.

Nah, kalau tim kamu butuh bikin prototipe atau aplikasi berbasis AI dengan model-model LLM populer tanpa mau ribet ngurusin manajemen server GPU dan antrean komputasi dari nol, kamu bisa manfaatin Classai Router. Lewat satu API key yang kompatibel sama format OpenAI dan Anthropic, kamu bisa langsung panggil model unggulan kayak claude-sonnet-5.5 (Rp3.600 / Rp18.000 per 1 juta token) atau model super hemat kayak deepseek-v4.1-flash (Rp1.155 / Rp4.200 per 1 juta token). Pembayarannya gampang banget pakai mata uang rupiah lewat QRIS atau transfer virtual account lokal tanpa perlu kartu kredit luar negeri.