Älä maksa käyttämättömistä GPU:ista. Varaa laskentatehoa juuri ajoissa, käsittele työkuorma ja pura se – muuttaen pääomakustannukset työkohtaisiksi käyttökustannuksiksi.

Työkuormasi on purskeista – videokoodaustyöt, jotka piikkaavat sisällön lataamisen yhteydessä, ML-koulutusajot, jotka tarvitsevat 8 GPU:ta 4 tunnin ajan ja sen jälkeen eivät mitään, eräpäättelytyöt, jotka käynnistyvät liiketoimintatapahtumista, tai renderöintiputket, jotka ajetaan yön yli. Olet joko yliresursoitu (maksat käyttämättömistä resursseista 80 % ajasta) tai aliresursoitu (työt jonottavat tunteja ruuhka-aikoina). Tarvitset arkkitehtuurin, joka varaa täsmälleen tarvitsemasi laskentatehon, kun sitä tarvitset, ja vapauttaa sen työn valmistuttua – ilman kylmäkäynnistysrangaistusta, joka tekee ”skaalaa nollaan” -mallista epäkäytännöllisen GPU-työkuormille.
Explore more design patterns and system architectures
Arkkitehtehtemme voivat auttaa suunnittelemaan ja rakentamaan järjestelmiä käyttäen tätä mallia omiin vaatimuksiin.
Ota yhteyttäPäälle/pois-skaalausarkkitehtuuri hallinnoi laskentaresursseja lämpimän/kylmän poolin, työjonovetoisen resurssien varauksen ja automatisoidun purkamisen avulla. Lämmin pooli ylläpitää pientä määrää esialustettuja instansseja, jotka ovat valmiina välittömään käyttöön. Kylmä pooli varaa lisäkapasiteettia spot-/preemptible-instansseista, kun kysyntä ylittää lämpimän poolin kapasiteetin. Työn orkestraattori reitittää työt saatavilla oleviin instansseihin, valvoo edistystä, käsittelee uudelleenyritykset spot-instanssien poiston sattuessa ja laukaisee alas skaalauksen, kun jono tyhjenee. Malli on erityisen kriittinen GPU-työkuormille, joissa kylmäkäynnistys (kontin haku + mallin lataus) voi kestää 3-10 minuuttia.
Järjestelmän keskiössä on työjono (SQS, Redis tai mukautettu), joka puskuroi saapuvat työpyynnöt. Skaalausohjain valvoo jonon syvyyttä ja varaa instansseja ensin lämpimästä poolista, sitten kylmästä poolista (spot-instanssit). Jokainen työskentelyinstanssi hakee töitä jonosta, suorittaa työkuorman (koodaus, koulutus, päättely), raportoi valmistumisesta ja palaa pooliin tai päättyy. Tarkistuspisteiden hallitsija käsittelee spot-instanssin poiston tallentamalla välitilan S3:een, mikä mahdollistaa töiden jatkamisen eri instanssilla alusta aloittamatta.
| Kerros | Teknologiat |
|---|---|
| Laskentateho | AWS EC2 Spot (G5/P4), GCP Preemptible (A2/L4), RunPod Serverless, Modal |
| Orkestrointi | Kubernetes (Karpenter for autoscaling), AWS Batch, custom job orchestrator |
| Työjono | AWS SQS, BullMQ (Redis), Temporal, Celery |
| Tallennustila | S3 (checkpoints, model artifacts), NVMe (model cache), EFS (shared workspace) |
| Valvonta | CloudWatch/Prometheus (jonon syvyys, instanssin käyttöaste, työn viive), mukautetut kustannuskoontinäytöt |
| Käytä, kun | Vältä, kun |
|---|---|
| Työkuorma on purskeista – huippukysyntä on yli 5-kertainen keskimääräiseen kysyntään verrattuna | Liikenne on tasaista ja ennustettavaa – oikein mitoitetut varatut instanssit ovat edullisempia |
| GPU/paljon laskentatehoa vaativat työt, jotka ovat kalliita tyhjäkäynnillä | Työkuorma on kevyttä suoritinkäsittelyä, joka sopii palvelimettomaan arkkitehtuuriin (Lambda) |
| Työt voivat sietää 1-5 minuutin kylmäkäynnistyksen kylmän poolin varausta varten | Alle sekunnin työtehtävän käynnistysviive vaaditaan – tarvitset aina päällä olevan infrastruktuurin |
| Kustannusoptimointi on ensisijainen huolenaihe ja spot-hinnoittelu tarjoaa 60-90 % säästöt | Spot-instanssin keskeytys aiheuttaisi tiedon katoamisen, jota tarkistuspisteiden tallennus ei voi lieventää |
MW suunnittelee päälle/pois-skaalauksen ”työkohtaisten kustannusten” näkökulmasta – mallinnamme yhden työskentelyyksikön (yhden videon, yhden koulutusajon, yhden eräpäättelyn) kokonaiskustannukset eri skaalausstrategioilla ja valitsemme sen, joka minimoi kustannukset vaaditulla viiveen SLA:lla. Toteutuksemme sisältävät reaaliaikaiset kustannuskoontinäytöt, jotka näyttävät työkohtaiset kustannukset, infrastruktuurin käyttöasteen ja spot-säästöt. Olemme rakentaneet päälle/pois-GPU-infrastruktuurin, joka vähensi videonkäsittelykustannuksia 70 % verrattuna varattuihin instansseihin, sekä ML-koulutusklustereita, jotka varaavat 64 GPU:ta 4 tunnin koulutusajoa varten ja vapauttavat ne automaattisesti.
Turvallisuus ei ole ominaisuus, jonka lisäät julkaisun jälkeen. Se on arkkitehtuurin ominaisuus – järjestelmä joko suunniteltiin sitä varten tai sitten ei.
MicrocosmWorksin asiakkaat, joilla on eräpainotteisia tai jaksottaisia työkuormia, havaitsevat tyypillisesti 60-80 %:n pilvikustannussäästöjä on-off skaalauksen käyttöönoton jälkeen, koska laskentaresurssit ovat käytössä vain aktiivisten käsittelyikkunoiden aikana 24/7-käytön sijaan. Suunnittelemme skaalauskäytäntöjä todellisen käyttötelemetrian perusteella – esimerkiksi tiedonkäsittelyputki, joka on käytössä 4 tuntia päivässä, maksaa vain niistä 4 tunnista koko 24 tunnin sijaan. Arkkitehtimme analysoivat työkuormamallejasi tutkimusvaiheen aikana projisoidakseen tarkat säästöt ennen kuin varsinainen käyttöönotto alkaa.
Cold-start-ajat vaihtelevat 2-3 sekunnista kontitetyille sovelluksille esilämmitetyissä node-pooleissa 5-10 minuuttiin työkuormille, jotka vaativat erikoistuneita GPU-instansseja tai suurten mallien lataamista, ja MicrocosmWorks käyttää useita tekniikoita tämän viiveen minimoimiseksi. Toteutamme ennakoivaa skaalausta, joka käynnistää resursseja ennen ennakoitua kysyntää hyödyntäen historiallisia liikennemalleja ja aikataulutettuja tapahtumia, ja käytämme konttikuvien esilatausta ja warm pool -varauksia viiveherkille työkuormille. Sovelluksille, jotka eivät siedä lainkaan cold startia, ylläpidämme minimaalista lämmintä perustasoa, joka skaalautuu aggressiivisesti ylöspäin kysynnän saapuessa.
MicrocosmWorks toteuttaa reaktiivista auto-scalingia aggressiivisilla scale-up-politiikoilla, jotka laukaistaan queue depthin, CPU utilizationin tai mukautettujen sovellusmittareiden perusteella, yhdistettynä asteittaisempiin scale-down-politiikkoihin, jotka sisältävät cooldown-jaksoja thrashingin välttämiseksi. Konfiguroimme over-provisioning-puskureita scale-up-tapahtumien aikana, jotta järjestelmä ennakoi jatkuvaa kasvua sen sijaan, että se jahtaisi kysyntää yksi instance kerrallaan. Todella ennustamattomia piikkejä varten, kuten flash sales tai viral events, esivaraamme kapasiteettia käyttämällä event-driven triggereitä markkinointi- tai operatiivisesta kalenteristasi.
MicrocosmWorks soveltaa on-off-skaalausta tietokantoihin käyttämällä serverless database offerings -palveluita, kuten Aurora Serverless, Neon tai PlanetScale, jotka skaalaavat compute-resurssit nollaan käyttämättömien jaksojen aikana pitäen storage-tilan pysyvänä ja välittömästi saatavilla. Stateful workloads -työkuormille, jotka eivät voi käyttää serverless-tietokantoja, toteutamme read-replica scaling -ratkaisun, joka lisää ja poistaa replicas-instansseja query load -kuormituksen perusteella pitäen samalla minimaalisen primary instance -instanssin aina käynnissä. Tämä hybridi lähestymistapa tarjoaa asiakkaille skaalauksen kustannushyödyt heidän data tier -tasolleen ilman database state -tilan hallinnan monimutkaisuutta sammutus- ja uudelleenkäynnistysjaksojen aikana.
MicrocosmWorks ottaa käyttöön kattavan skaalauksen observabilityn, joka seuraa instanssien määriä, skaalaustapahtumien viivettä, epäonnistuneita skaalausyrityksiä sekä toivotun ja todellisen kapasiteetin välistä eroa reaaliaikaisesti käyttäen Grafana- tai Datadog-hallintapaneeleita. Määritämme monikanavaisia hälytyksiä skaalausvirheistä, jatkuvasta korkeasta käyttöasteesta, joka viittaa liian matalaan skaalauskattoon, sekä kustannusanomalioista, jotka kertovat hallitsemattomasta skaalauksesta. Ajokirjamme (runbooks) sisältävät automatisoidun korjauksen yleisiin vikatilanteisiin, kuten pilvipalveluntarjoajan instanssirajojen saavuttamiseen tai riittämättömän kapasiteetin virheiden kohtaamiseen tietyillä saatavuusalueilla.