MicrocosmWorksInovasi dan Seni Bina Kosmos Digital
TentangHubungi
MicrocosmWorksMemperbaharui dan Merangka Kosmos Digital

Menyampaikan penyelesaian IT yang penting. Kami bersemangat tentang teknologi, keselamatan, dan membantu perniagaan berkembang melalui infrastruktur IT yang boleh dipercayai dan inovatif.

[email protected]
+91 7011868196
New Delhi, India

Pusat Pertumbuhan AI

AI HubInovasi PermulaanPemecut Perusahaan

Penyelesaian

Semua PenyelesaianAplikasi Kesihatan & KecergasanPlatform Video AIPembangunan Ejen AI

Sumber

WawasanPanduan IndustriPelan Tindakan Kes PenggunaanCorak Seni BinaKajian Kes

Syarikat

Tentang KamiHubungiKerja Kami

Perkhidmatan

Perundingan DigitalInfrastruktur AwanPembangunan SaaSPembangunan AITeknologi Video
Pembangunan ERPPenyesuaian ZohoPembangunan OdooIntegrasi SalesforcePembangunan CRM Tersuai
Integrasi QuickBooksPenyelesaian IoTPembangunan Blockchain
Perundingan Keselamatan SiberSokongan IT - L3

© 2026 MicrocosmWorks. Hak cipta terpelihara.

Dasar PrivasiTerma Perkhidmatan
Kembali ke Pola Arkitektur
InfrastructureAdvanced

Seni Bina Penskalaan On-Off

Jangan bayar untuk GPU yang terbiar. Sediakan komputasi tepat pada masanya, proses beban kerja, dan lupuskannya — mengubah perbelanjaan modal menjadi kos operasi setiap tugas.

June 22, 2026
|
2 topics covered
Bincangkan Arkitektur Ini
on-off-scaling-architecture.webp
Infrastructure
Category
Advanced
Complexity
AI/ML, Media & Hiburan
Industries
2+
Technologies

Bila Anda Memerlukan Ini

Beban kerja anda adalah bercorak lonjakan — tugas pengekodan video yang memuncak apabila kandungan dimuat naik, sesi latihan ML yang memerlukan 8 GPU selama 4 jam kemudian tiada apa-apa, tugas inferens kelompok yang dicetuskan oleh peristiwa perniagaan, atau saluran paip rendering yang berjalan semalaman. Anda sama ada terlebih peruntukan (membayar untuk sumber terbiar 80% daripada masa) atau terkurang peruntukan (tugas beratur selama berjam-jam semasa waktu puncak). Anda memerlukan seni bina yang memperuntukkan komputasi yang anda perlukan dengan tepat, apabila anda memerlukannya, dan melepaskannya apabila tugas selesai — tanpa penalti 'cold-start' yang menjadikan "skala kepada sifar" tidak praktikal untuk beban kerja GPU.

Related Architecture Patterns

Explore more design patterns and system architectures

cloud-native-infrastructure.webp
Infrastructure

Infrastruktur Cloud-Native

Infrastruktur yang divariasi, diuji, dan digunakan seperti kod aplikasi — kerana platform anda hanya boleh dipercayai seperti apa yang ada di bawahnya.

EnterpriseView
security-first-architecture.webp

Perlukah Bantuan Melaksanakan Arkitektur Ini?

Arkitek kami dapat membantu merancang dan membina sistem menggunakan pola ini untuk keperluan khusus anda.

Hubungi Kami

Gambaran Keseluruhan Corak

Seni bina penskalaan On-Off menguruskan sumber komputasi melalui pengumpulan hangat/sejuk (warm/cold pooling), penyediaan didorong giliran tugas, dan pembongkaran automatik. Satu kumpulan hangat (warm pool) mengekalkan sebilangan kecil instans pra-permulaan yang sedia untuk kegunaan segera. Satu kumpulan sejuk (cold pool) menyediakan kapasiti tambahan daripada instans spot/preemptible apabila permintaan melebihi kumpulan hangat. Satu orkestrator tugas menghalakan kerja kepada instans yang tersedia, memantau kemajuan, mengendalikan cubaan semula atas pengusiran spot, dan mencetuskan skala-turun apabila giliran kosong. Corak ini amat kritikal untuk beban kerja GPU di mana 'cold start' (penarikan kontena + pemuatan model) boleh mengambil masa 3-10 minit.

Seni Bina Rujukan

Sistem ini berpusat pada giliran tugas (job queue) (SQS, Redis, atau tersuai) yang menampan permintaan kerja yang masuk. Satu pengawal penskalaan memantau kedalaman giliran dan memperuntukkan instans daripada kumpulan hangat terlebih dahulu, kemudian daripada kumpulan sejuk (instans spot). Setiap instans pekerja menarik tugas daripada giliran, melaksanakan beban kerja (pengekodan, latihan, inferens), melaporkan penyelesaian, dan kembali ke kumpulan atau ditamatkan. Satu pengurus titik semak (checkpoint manager) mengendalikan pengusiran spot dengan menyimpan keadaan pertengahan ke S3, membolehkan tugas disambung semula pada instans yang berbeza tanpa bermula dari awal.

Komponen Teras
  • Giliran Tugas & Penjadual: Giliran tugas berprioriti dengan had serentak yang boleh dikonfigurasi bagi setiap jenis tugas. Menyokong pelaksanaan tertunda, 'dead-letter queues' untuk tugas yang gagal, dan laluan keutamaan (tugas ekspres mendapat instans kumpulan hangat, tugas standard menggunakan kumpulan sejuk). AWS SQS, BullMQ pada Redis, atau Temporal untuk aliran kerja yang kompleks
  • Pengurus Kumpulan Hangat: Mengekalkan N instans pra-permulaan dengan model dimuatkan dalam memori GPU, kontena berjalan, dan pemeriksaan kesihatan lulus. Instans berputar melalui: terbiar → ditugaskan → memproses → terbiar. Saiz kumpulan boleh dikonfigurasi mengikut masa (lebih besar pada waktu perniagaan, lebih kecil semalaman) dan boleh disesuaikan berdasarkan corak permintaan sejarah
  • Penyedia Kumpulan Sejuk: Menyediakan kapasiti tambahan daripada instans spot (AWS), VM preemptible (GCP), atau penyedia GPU tanpa pelayan (RunPod, Modal, Salad). Mengendalikan pemberitahuan gangguan spot dengan memindahkan tugas ke instans yang tersedia. Menggunakan strategi jenis instans yang pelbagai (pelbagai jenis GPU, pelbagai AZ) untuk memaksimumkan ketersediaan spot
  • Titik Semak & Pemulihan: Untuk tugas yang berjalan lama (latihan ML, pengekodan video besar), titik semak berkala menyimpan keadaan pertengahan ke S3. Apabila pengusiran spot berlaku, tugas akan dimasukkan semula ke giliran dan disambung semula dari titik semak terakhir. Untuk tugas pendek (< 10 min), kos titik semak melebihi kos permulaan semula — tugas ini hanya mencuba semula dari awal

Keputusan Reka Bentuk & Pertukaran

Saiz Kumpulan Hangat
Kumpulan hangat adalah pertukaran antara kos (membayar untuk instans terbiar) dan kependaman (masa 'cold start' untuk tugas pertama). MW menentukan saiz kumpulan hangat berdasarkan corak ketibaan giliran: jika tugas tiba secara berterusan pada waktu perniagaan, kumpulan hangat meliputi purata daya pemprosesan; kumpulan sejuk meliputi puncak. Jika tugas tiba dalam lonjakan yang tidak dapat diramal, kami mengekalkan kumpulan hangat yang lebih kecil dan menerima kependaman 'cold-start' untuk tugas lonjakan pertama sementara kumpulan sejuk disediakan.
Instans Spot vs. GPU Tanpa Pelayan (RunPod/Modal)
Instans spot lebih murah setiap jam tetapi memerlukan anda menguruskan penyediaan, pengendalian pengusiran, dan kitaran hayat instans. Penyedia GPU tanpa pelayan (RunPod Serverless, Modal, Banana) mengendalikan penyediaan dan menawarkan bil per-saat tetapi pada kadar per-komputasi-saat yang lebih tinggi. MW menggunakan instans spot untuk beban kerja yang boleh diramal, berjalan lama (>30 min) dan GPU tanpa pelayan untuk tugas pendek, bercorak lonjakan (<10 min) di mana overhead penyediaan akan mendominasi.
Keagresifan Skala-Turun
Skala-turun terlalu cepat dan anda akan membayar penalti 'cold-start' apabila tugas seterusnya tiba. Skala-turun terlalu perlahan dan anda akan membayar untuk instans terbiar. MW melaksanakan strategi "cooldown dengan pereputan": selepas giliran kosong, instans kekal hangat untuk tempoh yang boleh dikonfigurasi (lalai: 10 minit). Jika tiada tugas baharu tiba, instans akan skala-turun secara progresif (50% pada 10 minit, baki pada 30 minit). Tempoh 'cooldown' boleh ditala dan disesuaikan secara automatik berdasarkan statistik masa antara ketibaan.
Pengoptimuman Pemuatan Model GPU
Untuk inferens ML, hambatan 'cold-start' selalunya adalah pemuatan model (memuat turun dari S3 + memuatkan ke dalam memori GPU), bukan permulaan kontena. MW mengoptimumkan ini dengan: (a) pra-memasak model ke dalam imej kontena (untuk model kecil), (b) menggunakan storan NVMe kongsi merentasi instans dengan kaching model (untuk model besar), dan (c) mengekalkan instans kumpulan hangat dengan model pra-muat dalam memori GPU.

Pilihan Teknologi

LapisanTeknologi
KomputasiAWS EC2 Spot (G5/P4), GCP Preemptible (A2/L4), RunPod Serverless, Modal
OrkestrasiKubernetes (Karpenter for autoscaling), AWS Batch, custom job orchestrator
Giliran TugasAWS SQS, BullMQ (Redis), Temporal, Celery
StoranS3 (titik semak, artifak model), NVMe (kaching model), EFS (ruang kerja kongsi)
PemantauanCloudWatch/Prometheus (kedalaman giliran, penggunaan instans, kependaman tugas), papan pemuka kos tersuai

Bila Menggunakan / Bila Mengelak

Gunakan ApabilaElakkan Apabila
Beban kerja adalah bercorak lonjakan — permintaan puncak adalah 5x+ purata permintaanTrafik adalah stabil dan boleh diramal — instans terpelihara bersaiz tepat lebih murah
Tugas GPU/komputasi tinggi yang mahal apabila terbiarBeban kerja adalah pemprosesan CPU ringan yang sesuai untuk tanpa pelayan (Lambda)
Tugas boleh menahan 'cold start' 1-5 minit untuk penyediaan kumpulan sejukKependaman permulaan tugas bawah satu saat diperlukan — anda memerlukan infrastruktur sentiasa aktif
Pengoptimuman kos adalah kebimbangan utama dan harga spot menawarkan penjimatan 60-90%Gangguan spot akan menyebabkan kehilangan data yang tidak dapat dikurangkan oleh titik semak

Pendekatan Kami

MW mereka penskalaan On-Off dengan lensa "kos per tugas" — kami memodelkan jumlah kos memproses satu unit kerja (satu video, satu sesi latihan, satu inferens kelompok) merentasi strategi penskalaan yang berbeza dan memilih yang meminimumkan kos pada SLA kependaman yang diperlukan. Pelaksanaan kami termasuk papan pemuka kos masa nyata yang menunjukkan kos per tugas, penggunaan infrastruktur, dan penjimatan spot. Kami telah membina infrastruktur GPU On-Off yang mengurangkan kos pemprosesan video sebanyak 70% berbanding instans terpelihara, dan kluster latihan ML yang menyediakan 64 GPU untuk sesi latihan 4 jam dan melepaskannya secara automatik.

Pelan Tindakan Berkaitan

  • Orkestrasi Kluster GPU untuk Beban Kerja AI — Penyediaan dan orkestrasi GPU untuk latihan ML
  • Sistem Pengawasan Video AI Masa Nyata — Inferens lonjakan untuk peristiwa analisis video
  • Penjana Sorotan Sukan Langsung — Pemprosesan video didorong peristiwa dengan komputasi lonjakan

Kajian Kes Berkaitan

  • Pemprosesan Video Corak On-Off — Penyediaan GPU dengan kumpulan hangat/sejuk untuk beban kerja pengekodan video
  • Platform Pengekodan Video — Pengekodan tanpa pelayan dan berasaskan spot dengan kumpulan pekerja berskala automatik
Related Technologies
Penyelesaian AwanPembangunan AI
Infrastructure

Seni Bina Mengutamakan Keselamatan

Keselamatan bukanlah ciri yang anda tambah selepas pelancaran. Ia adalah sifat seni bina — sama ada sistem itu direka bentuk untuknya, atau tidak.

EnterpriseView
serverless-first-architecture.webp
Infrastructure

Seni Bina Serverless-First

Bayar mengikut penggunaan anda, berskala kepada sifar apabila tidak digunakan, dan berhenti mengurus pelayan sepenuhnya — tetapi ketahui bila ekonomi tidak lagi berkesan.

AdvancedView

Soalan Lazim

Pelanggan MicrocosmWorks dengan beban kerja berat batch atau berkala biasanya melihat pengurangan kos awan sebanyak 60-80% selepas melaksanakan on-off scaling, kerana sumber pengiraan hanya berjalan semasa tetingkap pemprosesan aktif dan bukannya 24/7. Kami mereka dasar penskalaan berdasarkan telemetri penggunaan sebenar—sebagai contoh, saluran pemprosesan data yang berjalan selama 4 jam sehari hanya membayar untuk 4 jam tersebut dan bukannya sepanjang 24 jam. Arkitek kami menganalisis corak beban kerja anda semasa fasa penemuan untuk mengunjurkan penjimatan tepat sebelum sebarang pelaksanaan bermula.

Masa `cold-start` berbeza dari 2-3 saat untuk aplikasi terkontena pada `pre-warmed node pools` hingga 5-10 minit untuk beban kerja yang memerlukan `GPU instances` khusus atau pemuatan model besar, dan `MicrocosmWorks` menggunakan beberapa teknik untuk meminimumkan kelewatan ini. Kami melaksanakan `predictive scaling` yang mengaktifkan sumber sebelum permintaan yang dijangka menggunakan corak trafik sejarah dan acara terjadual, dan kami menggunakan `pre-pulling image` kontena serta tempahan `warm pool` untuk beban kerja yang sensitif terhadap latensi. Untuk aplikasi yang tidak dapat menoleransi sebarang `cold start`, kami mengekalkan garis dasar `warm` yang minimum yang meningkatkan skala secara agresif apabila permintaan tiba.

MicrocosmWorks melaksanakan reactive auto-scaling dengan polisi scale-up yang agresif yang dicetuskan oleh queue depth, CPU utilization, atau custom application metrics, digabungkan dengan polisi scale-down yang lebih beransur-ansur yang merangkumi cooldown periods untuk mengelakkan thrashing. Kami mengkonfigurasi over-provisioning buffers semasa scale-up events supaya sistem menjangkakan pertumbuhan berterusan daripada mengejar permintaan satu instans pada satu masa. Untuk lonjakan yang benar-benar tidak dapat diramalkan seperti flash sales atau viral events, kami pre-provision kapasiti menggunakan event-driven triggers dari kalendar pemasaran atau operasi anda.

MicrocosmWorks mengaplikasikan penskalakan on-off pada pangkalan data menggunakan penawaran pangkalan data tanpa pelayan (serverless) seperti Aurora Serverless, Neon, atau PlanetScale yang menskalakan komputasi kepada sifar semasa tempoh terbiar sambil mengekalkan storan yang berterusan (persistent) dan tersedia serta-merta. Untuk beban kerja berkeadaan (stateful workloads) yang tidak boleh menggunakan pangkalan data tanpa pelayan (serverless databases), kami melaksanakan penskalakan replika-baca (read-replica scaling) yang menambah dan mengalih keluar replika berdasarkan beban pertanyaan sambil mengekalkan instans utama yang minimum sentiasa beroperasi. Pendekatan hibrid ini memberikan pelanggan faedah kos penskalakan untuk lapisan data mereka tanpa kerumitan mengurus keadaan pangkalan data semasa kitaran penutupan dan permulaan semula.

MicrocosmWorks menggunakan kebolehlihatan penskalaan yang komprehensif yang menjejaki jumlah instance, latensi acara penskalaan, percobaan penskalaan yang gagal, dan jurang antara kapasiti yang diingini dan sebenar secara masa nyata menggunakan dashboard Grafana atau Datadog. Kami mengkonfigurasi amaran berbilang saluran untuk kegagalan penskalaan, utilisasi tinggi yang berterusan yang menunjukkan had penskalaan terlalu rendah, dan anomali kos yang menunjukkan penskalaan tidak terkawal. Runbook kami merangkumi pemulihan automatik untuk mod kegagalan biasa seperti mencapai had instance penyedia cloud atau menghadapi ralat kapasiti tidak mencukupi di zon ketersediaan tertentu.