Yksikkö 8 / 11

On-Prem, VPC ja Openweight Hosting

Voitot:

  • Kyky arvioida kompromisseja hallitun API:n, VPC:n ja on-prem hosting-palvelun välillä
  • Kyky päättää isännöinnistä datasuvereniteetin, määrän ja toimintakapasiteetin perusteella
  • Kyky laskea kokonaiskustannukset (TCO) täydellä tuotteella ja suunnittelemalla hybridiarkkitehtuuria

Joillekin organisaatioille "tietojen lähettäminen palveluntarjoajalle" - riippumatta siitä kuinka suojattua - ei ole hyväksyttävää. Puolustusteollisuudessa, julkisessa sektorissa, pankkitoiminnassa ja joissakin terveydenhuollon skenaarioissa datan ei pitäisi koskaan mennä laitoksen rajojen ulkopuolelle. Tässä vaiheessa oman mallin isännöinti tulee etualalle: avoimet mallit, jotka toimivat omassa pilviverkossa (VPC) tai omilla palvelimilla (on-prem). Tässä osiossa opimme kompromisseja hallitun API:n ja itseisännöinnin välillä, kun se on järkevää, sekä kokonaisomistuskustannusten (TCO) välillä.

käsitteitä

  • Managed API: Toimii mallintoimittajan infrastruktuurissa; Lähetät pyynnön ja saat vastauksen. Käyttökustannukset ovat minimaaliset, mutta tiedot menevät palveluntarjoajalle.
  • Avoin painomalli: Mallin parametrit (painot) voidaan ladata; Voit käyttää sitä omalla laitteistollasi. Se ei välttämättä ole sama kuin "avoin lähdekoodi" (lisenssi voi olla erilainen).
  • VPC-hosting (Virtual Private Cloud): Mallin käyttäminen omassa eristetyssä pilviverkossasi; Tiedot pysyvät verkkosi rajoilla, mutta infrastruktuuri on edelleen pilvessä.
  • On-prem (on-premises): Mallin käyttäminen kokonaan oman datakeskuksesi laitteistolla; korkein ohjaus, suurin käyttökuorma.
Varoitus: "Oma isännöinti on aina turvallisempaa" on väärinkäsitys. Turvallisuus riippuu vähemmän siitä, missä säilytät tietoja, vaan enemmän siitä, kuinka hyvin hallitset niitä. Korjaamaton, huonosti määritetty on-prem-palvelin on riskialtisempi kuin kypsä hallittu API.

Päätösakseli: mikä milloin?

Päätöstä ohjaa kolme kysymystä:

  1. Tietojen itsemääräämisoikeus: Kieltääkö laki tai sopimus tietojen poistumisen laitoksesta/maasta? Jos kyllä, sinut työnnetään kohti VPC/on-prem.
  2. Määrä ja hinta: Onko käyttö erittäin korkea ja ennustettavissa? Erittäin suuret itseisännöintimäärät voivat vähentää yksikkökustannuksia; Alhaisella / epäsäännöllisellä volyymilla hallittu API on lähes aina halpaa.
  3. Toimintakapasiteetti: Onko sinulla tiimiä ylläpitämään GPU-infrastruktuuria, päivittämään mallia, skaalaamaan ja parantamaan tietoturvakorjauksia? Muuten oma isännöinti on piilohinta.

Vaihtoehtotaulukko

Koko

Hallittu API

VPC

On-Prem (avopaino)

Tietojen suvereniteetti

Luota palveluntarjoajaan

Korkea (verkkorajoituksellasi)

Korkein (ei koskaan nouse)

Toiminnan kuormitus

liian matala

keskikokoinen

korkea

Alkukustannukset

alhainen (maksaa mukaan)

keskikokoinen

Korkea (laitteisto)

skaalaus

automaattinen

Hallittu

sinun vastuullasi

Mallin laatu/valuutta

uusin, automaattinen

Riippuu

Päivität

ohjata

alhainen

korkea

täynnä

Askel askeleelta: isännöintipäätös

  1. Määritä dataluokka. Millä luottamuksellisuustasolla tietoja käsitellään?
  2. Tarkista laillinen rajoitus. Voivatko tiedot päästä ulos? (KVKK, alasääntely, sopimus.)
  3. Arvioi äänenvoimakkuus. Kuukausittainen pyyntö/token määrä ja kasvukäyrä.
  4. Laske TCO. Ei vain GPU; energia, huolto, tiimi, turvallisuus, redundanssi.
  5. Ajattele hybridiä. Hybridimalli, joka käsittelee arkaluonteisia tietoja on-prem/VPC:ssä ja ei-arkaluonteisia tietoja hallitussa API:ssa, on usein vakain.

Neljä kopioitavaa mallia

Isännöintipäätöskehote:

Päätä isännöinti seuraavaa käyttöä varten: {{ skenaario }}Kysymyksiä: - Mikä on käsiteltävien tietojen tietosuojaluokka? (julkinen/sisäinen/luottamuksellinen/täysin salainen)- Salliiko laki/sopimus tietojen siirtymisen organisaation ulkopuolelle?- Kuukausittainen volyymiennuste ja ennustettavuus?- Onko toiminta-/GPU-tiimin kapasiteettia? Suositus: "Managed API / VPC / On-prem / Hybrid" + perustelu.

TCO-tuoteluettelo (itseisännöintiin):

Laske kokonaiskustannukset: - Laitteiston (GPU) osto/vuokraus - Energia ja jäähdytys - Ihminen: MLOps + turvallisuustiimin työaika - Mallin päivitys ja testaustyövoima - Redundanssi/katastrofipalautus - Tietoturvakorjaukset ja -valvonta Vertaa tätä hallitun API:n kuukausilaskuun 12-24 kuukauden aikavälillä.

Hybridireitityssääntö:

Reititä jokainen pyyntö tietoluokan perusteella:- "salainen / huippusalainen" data -> on-prem/VPC-malli- "julkinen / sisäinen" data -> hallittu API (tehokkaampi/halvempi) Kirjoita edelleenlähetyspäätös ja tietoluokka tarkastuslokiin.

Avaa painon turvatarkistuskehote:

Arvioi itseisännöity mallimme:- Salliiko lisenssi kaupallisen käytön ja skenaariossamme?- Mallin painot luotetusta lähteestä, eheys (hash) varmistettu?- Onko palvelimen korjaus, verkon eristys, kulunvalvonta asennettu?- Ovatko valvonta ja kirjaus yhtä kypsä kuin hallittu API? Merkitse puuttuvat kohteet tilaan "ON".

Heikko kehote / Vahva kehote

huono lähestymistapa

Vahva lähestymistapa

"On-prem on turvallisempi, käytä sitä aina"

Päätös perustuu datan itsemääräämisoikeuteen + määrä + kapasiteetti

Katsotaan vain GPU-kustannuksia

Täysi TCO (energia, miehistö, päivitykset, turvallisuus)

Lukittuina yhteen isännöintimalliin

Hybridi: reititys tietoluokan mukaan

Juoksu laskematta avointa painoa ja tarkistamatta sitä

Lisenssi + eheys + korjaustiedosto + jäljitys

Kolme minikoteloa

Tapaus 1 – On-prem-mandaatti oli oikea päätös. Puolustusurakoitsijan piti käsitellä erittäin turvaluokiteltuja asiakirjoja; Sopimus kielsi tietojen viemisen maasta. Hallittu API poistettiin alusta alkaen. On-prem avoimen painon malli perustettiin; Hinta oli korkea, mutta se oli ainoa yhteensopiva vaihtoehto.

Tapaus 2 – Luottamuksellinen TCO:n kumottu päätös. Startup suunnitteli siirtyvän itseisännöintiin, koska "sovellusliittymä on kallis". TCO-laskelmaan sisällytät paitsi GPU:n; Lisää 2 kokopäiväistä MLOps-insinööriä, päivityskuormitus ja redundanssi, ja 24 kuukauden kokonaismäärä on kaksinkertainen hallitun API:n kokonaismäärään verrattuna. Ne pysyivät API:ssa, koska niiden määrät olivat pieniä ja satunnaisia.

Tapaus 3 – Hybridi antoi parhaan. Pankin puhelinpalveluassistentti käsitteli kahdenlaisia ​​tietoja: yleisiä tuotekysymyksiä ja asiakaskohtaisia ​​tilitietoja. Tilitiedot ohjataan malliin VPC:n sisällä, yleiset kysymykset ohjataan tehokkaaseen hallintaliittymään. Arkaluonteiset tiedot eivät koskaan päässeet ulos, yleisiin kysymyksiin käytettiin vahvimman mallin laatua; hinta ja istuvuus optimoidaan yhdessä.

Vinkki: Päätöksen ei tarvitse olla binäärinen (kaikki tai ei mitään). Hybridiarkkitehtuuri – tietojen reitittäminen luokkien mukaan – ratkaisee samanaikaisesti vaatimustenmukaisuuden ja kustannusten useimmissa yritysskenaarioissa.

Yleisiä virheitä

  • Oletetaan, että "oma isännöinti on automaattisesti turvallisempaa"; kun taas turvallisuus riippuu hallinnon laadusta.
  • Ajatellaan, että TCO on vain GPU-kustannuksia; tiimi, energia, päivitys ja turvallisuuden unohtaminen.
  • Vaihtaminen omaan isännöintiin alhaisella/epäsäännöllisellä äänenvoimakkuudella ja yksikkökustannusten nostaminen.
  • Avoimen painomallin käyttäminen ilman lisenssin ja eheyden varmistamista (hash).
  • Ei asenneta valvontaa/lokikirjaa yhtä kypsä kuin hallittu API paikalliseen palvelimeen.
  • Binääripäätöksen tekeminen ottamatta huomioon hybridivaihtoehtoa ollenkaan.

Yhteenvetona

  • Hallittu API on toiminnallisesti helpoin, mutta tiedot menevät palveluntarjoajalle; VPC/on-prem pitää tiedot rajallasi.
  • Päätöksen taustalla on kolme kysymystä: tiedon riippumattomuus, volyymien/kustannusten ennustettavuus ja toimintakyky.
  • "Oma isännöinti on turvallisempaa" on väärinkäsitys; Turvallisuus ei riipu siitä, missä säilytät tietoja, vaan siitä, kuinka hyvin hallitset niitä.
  • Laske tarkka TCO: energia, tiimi, päivitys, redundanssi ja turvallisuus sekä GPU.
  • Hybridiarkkitehtuuri (tiedon reititys luokan mukaan) tasapainottaa samanaikaisesti vaatimustenmukaisuuden ja kustannusten kanssa useimmissa yritysskenaarioissa.

Sovellustehtävä

Valitse tekoälyn käyttötapa ja erottele käsiteltävät tiedot tietosuojaluokkaan. Luo suositus isännöintipäätöskehotteen avulla. Täytä sitten oman hostingsi TCO-tuoteluettelo ja vertaa 24 kuukauden kokonaissummaa hallinnoituun API-laskuun. Kirjoita lopuksi hybridireitityssäännön luonnos: mitkä tiedot menevät minne?

tarkistuslista

  • [ ] Olen määritellyt käsiteltäville tiedoille luottamuksellisuusluokan ja lakisääteisen rajoituksen.
  • [ ] Tein isännöintipäätöksen suvereniteetin + volyymin + kapasiteetin perusteella.
  • [ ] Laskin TCO:n täydellä kohteella (mukaan lukien ei-GPU).
  • [ ] Tarkistin lisenssin, eheyden, korjauksen ja valvonnan itseisännöinnistä.
  • [ ] Harkitsin hybridireititysvaihtoehtoa.
  • [ ] Dokumentoin päätöksen ja sen perustelut.