Kasu:
- Võimalus hinnata hallatud API, VPC ja kohapealse hostimise vahelisi kompromisse
- Võimalus otsustada hostimise üle andmete suveräänsuse, mahu ja töövõime põhjal
- Võimalus arvutada kogu omamise kulu (TCO) täisesemete ja disainilahenduse hübriidarhitektuuriga
Mõne organisatsiooni jaoks ei ole andmete saatmine teenusepakkujale vastuvõetav – olenemata sellest, kui turvaline see on. Kaitsetööstuses, avalikus sektoris, panganduses ja mõnes tervisestsenaariumis ei tohiks andmed kunagi ulatuda institutsiooni piiridest kaugemale. Siinkohal tuleb esiplaanile oma mudeli hostimine: avatud mudelid, mis töötavad teie enda pilvevõrgus (VPC) või teie enda serverites (on-prem). Selles üksuses õpime hallatud API ja isehostimise vahelisi kompromisse, kui see on mõttekas, ning kogu omamise kulu (TCO).
mõisted
- Hallatud API: töötab mudeli pakkuja infrastruktuuris; Saadad päringu ja saad vastuse. Tegevuskulud on minimaalsed, kuid andmed lähevad pakkujale.
- Avatud kaaluga mudel: mudeli parameetrid (kaalud) saab alla laadida; Saate seda oma riistvaras käivitada. See ei pruugi olla sama mis "avatud lähtekoodiga" (litsents võib olla erinev).
- VPC hostimine (virtuaalne privaatpilv): mudeli käitamine oma isoleeritud pilvevõrgus; Andmed jäävad teie võrgupiirile, kuid infrastruktuur on endiselt pilves.
- Kohapealne (on-premises): mudeli käitamine täielikult teie enda andmekeskuse riistvaral; kõrgeim kontroll, suurim töökoormus.
Ettevaatust: "Oma hostimine on alati turvalisem" on eksiarvamus. Turvalisus sõltub vähem sellest, kus te andmeid hoiate, vaid rohkem sellest, kui hästi te neid haldate. Paigaldamata, halvasti konfigureeritud kohapealne server on riskantsem kui täiskasvanud hallatav API.
Otsustustelg: milline millal?
Otsuse tegemisel juhivad kolm küsimust:
- Andmete suveräänsus: kas seadus või leping keelab andmete asutusest/riigist lahkumise? Kui jah, siis suunatakse teid VPC/on-prem poole.
- Maht ja maksumus: kas kasutus on väga suur ja prognoositav? Väga suured isehostimise mahud võivad vähendada ühikukulusid; Väikese / ebaühtlase helitugevusega hallatav API on peaaegu alati odav.
- Kasutusvõime: kas teil on meeskond GPU infrastruktuuri hooldamiseks, mudelite värskendamiseks, skaleerimiseks ja turvapaikadeks? Vastasel juhul on teie enda hostimine varjatud kulu.
Kompromissi tabel
Suurus
Hallatud API
VPC
On-Prem (avatud kaal)
Andmete suveräänsus
Usalda teenusepakkujat
Kõrge (teie võrgupiirangu juures)
Kõrgeim (ei tõuse kunagi)
Töökoormus
liiga madal
keskmine
kõrge
Esialgne maksumus
Madal (maksa kui lähete)
keskmine
Kõrge (riistvara)
skaleerimine
automaatne
Hallatud
teie vastutus
Mudeli kvaliteet/valuuta
uusim, automaatne
Oleneb
Sa uuendad
kontrolli
madal
kõrge
täis
Samm-sammult: hostimisotsus
- Määrake andmeklass. Millisel konfidentsiaalsustasemel andmeid töödeldakse?
- Kontrollige juriidilist piirangut. Kas andmed võivad välja tulla? (KVKK, valdkondlik regulatsioon, leping.)
- Hinnake helitugevust. Igakuine päringu/märgi maht ja kasvukõver.
- Arvutage TCO. Mitte ainult GPU; energia, hooldus, meeskond, turvalisus, koondamine.
- Mõelge hübriidile. Hübriidmudel, mis töötleb tundlikke andmeid kohapealses/VPC-s ja mittetundlikke andmeid hallatavas API-s, on sageli kõige stabiilsem.
Neli kopeeritavat malli
Majutusotsuse viip:
Otsustage hostimine järgmise kasutuse jaoks: {{ stsenaarium }}Küsimused:- Mis on töödeldavate andmete privaatsusklass? (avalik/sisemine/konfidentsiaalne/täiesti salajane)- Kas seadus/leping lubab andmetel organisatsioonist väljapoole minna?- Kuumahu prognoos ja prognoositavus?- Kas operatsioonide/GPU meeskonna võimekus on olemas? Soovitus: "Hallatud API / VPC / On-prem / hübriid" + põhjendus.
TCO kaupade loend (isehostimiseks):
Arvutage omamise kogukulu järgmiselt: - Riistvara (GPU) ost/liising - Energia ja jahutus - Inimene: MLOps + turvameeskonna tööaeg - Mudeli värskendamine ja testimise tööjõud - Koondamine / avariitaaste - Turvapaigad ja -jälgimine Võrrelge seda hallatava API igakuise arvega 12–24 kuu jooksul.
Hübriidmarsruutimise reegel:
Marsruutage iga päring andmeklassi alusel:- "salajane / ülisalajane" andmed -> kohapealne/VPC mudel- "avalikud / sisemised" andmed -> hallatud API (võimsam/odavam)Kirjutage auditi logisse edastamisotsus ja andmeklass.
Ava kaalu turvakontrolli viip:
Hinnake meie isehostitavat mudelit:- Kas litsents lubab kommertskasutust ja meie stsenaariumi korral?- Usaldusväärsest allikast pärit mudelite kaalud, terviklikkus (räsi) on kinnitatud?- Kas serveri paigad, võrgu isoleerimine, juurdepääsukontroll on installitud?- Kas jälgimine ja logimine on sama küpsed kui hallatud API?Märkige kõik puuduvad üksused olekuga "SEES".
Nõrk viip / Tugev viip
halb lähenemine
Tugev lähenemine
"On-prem on turvalisem, kasutage seda alati"
Otsus põhineb andmete suveräänsusel + maht + mahutavus
Lihtsalt vaadates GPU maksumust
Täielik TCO (energia, meeskond, värskendused, turvalisus)
Olles lukustatud ühte hostimismudelisse
Hübriid: marsruutimine andmeklassi järgi
Jooks ilma avatud raskust langetamata ja seda kontrollimata
Litsents + terviklikkus + plaaster + jälgimiskontroll
Kolm miniümbrist
Juhtum 1 – kohapealne mandaat oli õige otsus. Kaitsetöövõtja pidi töötlema kõrgelt salastatud dokumente; Leping keelas andmete riigist väljaviimise. Hallatud API eemaldati algusest peale. Kehtestati on-prem avatud kaalumudel; Maksumus oli kõrge, kuid see oli ainus sobiv variant.
Juhtum 2 – konfidentsiaalne TCO tühistatud otsus. Startup plaanis minna üle isehostimisele, kuna API on kallis. TCO arvutusse ei kaasata ainult GPU; Lisage kaks täiskohaga MLOps-i inseneri, värskendage koormust ja koondamist ning 24 kuu kogusumma on hallatava API-ga võrreldes kaks korda suurem. Need jäid API-sse, kuna nende mahud olid väikesed ja juhuslikud.
Juhtum 3 – hübriid andis parima. Panga kõnekeskuse assistent töötles kahte tüüpi andmeid: üldiseid tooteküsimusi ja kliendipõhiseid kontoandmeid. Konto andmed suunatakse VPC-s olevale mudelile, üldised küsimused suunatakse võimsale hallatavale API-le. Tundlikud andmed ei jõudnudki välja, üldiste küsimuste puhul kasutati tugevaima mudeli kvaliteeti; maksumus ja sobivus on optimeeritud koos.
Näpunäide: otsus ei pea olema binaarne (kõik või mitte midagi). Hübriidarhitektuur – andmete klasside kaupa marsruutimine – lahendab enamiku ettevõtte stsenaariumide puhul samaaegselt vastavuse ja kulud.
Levinud vead
- Oletame, et "oma hostimine on automaatselt turvalisem"; samas kui turvalisus sõltub juhtimise kvaliteedist.
- Arvestades, et TCO on lihtsalt GPU kulu; meeskond, energia, uuendused ja turvalisuse unustamine.
- Isehostimisele üleminek madalal/ebaregulaarsel helitugevusel ja ühikuhinna suurendamine.
- Avatud kaalumudeli kasutamine ilma litsentsi ja terviklikkuse kontrollimiseta (räsi).
- Ei installita kohapealsesse serverisse nii küpset jälgimist/logimist kui hallatud API-d.
- Binaarse otsuse tegemine hübriidvarianti üldse kaalumata.
Kokkuvõttes
- Hallatud API on operatiivselt kõige lihtsam, kuid andmed lähevad pakkujale; VPC/on-prem hoiab andmeid teie piiril.
- Otsuse aluseks on kolm küsimust: andmete suveräänsus, mahu/kulude prognoositavus ja töövõime.
- "Isehostimine on turvalisem" on eksiarvamus; Turvalisus ei sõltu mitte sellest, kus te andmeid hoiate, vaid sellest, kui hästi te neid haldate.
- Arvutage täpne TCO: energia, meeskond, värskendus, koondamine ja turvalisus, samuti GPU.
- Hübriidarhitektuur (andmete suunamine klasside kaupa) tasakaalustab enamiku ettevõtte stsenaariumide puhul samaaegselt vastavust ja kulusid.
Rakenduse ülesanne
Valige tehisintellekti kasutusviis ja eraldage töödeldavad andmed privaatsusklassi. Looge soovitus koos hostimisotsuse viipaga. Seejärel täitke oma hostimise TCO üksuste loend ja võrrelge 24 kuu kogusummat hallatud API arvega. Lõpuks kirjutage hübriidmarsruutimise reegli mustand: millised andmed kuhu lähevad?
kontrollnimekiri
- [ ] Olen määranud töödeldavate andmete konfidentsiaalsusklassi ja seadusliku piirangu.
- [ ] Tegin hostimise otsuse suveräänsuse + mahu + mahu põhjal.
- [ ] Arvutasin TCO täisüksustega (sh mitte-GPU).
- [ ] Kontrollisin isehostimise litsentsi, terviklikkust, paikamist ja jälgimist.
- [ ] Kaalusin hübriidmarsruutimise võimalust.
- [ ] Dokumenteerisin otsuse ja selle põhjendused.