Njësia 8 / 11

Hosting On-Prem, VPC dhe Openweight

Fitimet:

  • Aftësia për të vlerësuar kompromiset ndërmjet API-së së menaxhuar, VPC-së dhe pritjes on-prem
  • Aftësia për të vendosur për pritjen bazuar në sovranitetin e të dhënave, vëllimin dhe kapacitetin operacional
  • Aftësia për të llogaritur koston totale të pronësisë (TCO) me artikujt e plotë dhe arkitekturën hibride të projektimit

Për disa organizata, "dërgimi i të dhënave te një ofrues" - pavarësisht sa i sigurt - nuk është i pranueshëm. Në industrinë e mbrojtjes, publike, bankare dhe disa skenarë shëndetësorë, të dhënat nuk duhet të shkojnë kurrë përtej kufirit të institucionit. Në këtë pikë, pritja e modelit tuaj del në pah: modele me peshë të hapur, që funksionojnë në rrjetin tuaj cloud (VPC) ose në serverët tuaj (on-prem). Në këtë njësi do të mësojmë shkëmbimet midis API-së së menaxhuar dhe vetë-strehimit, kur ka kuptim, dhe kostos totale të pronësisë (TCO).

konceptet

  • API i menaxhuar: Ekzekutohet në infrastrukturën e ofruesit të modelit; Ju dërgoni një kërkesë dhe merrni një përgjigje. Shpenzimet e përgjithshme operacionale janë minimale, por të dhënat shkojnë te ofruesi.
  • Modeli me peshë të hapur: Parametrat e modelit (peshat) mund të shkarkohen; Mund ta ekzekutoni në pajisjen tuaj. Nuk është domosdoshmërisht e njëjtë me "burim të hapur" (licenca mund të jetë e ndryshme).
  • Pritja VPC (Virtual Private Cloud): Ekzekutimi i modelit në rrjetin tuaj të izoluar cloud; Të dhënat mbeten në kufirin e rrjetit tuaj, por infrastruktura është ende në re.
  • On-prem (on-premises): Ekzekutimi i modelit tërësisht në harduer në qendrën tuaj të të dhënave; kontrolli më i lartë, ngarkesa më e lartë operacionale.
Kujdes: "Pajtimi vetjak është gjithmonë më i sigurt" është një ide e gabuar. Siguria varet më pak nga vendi ku i ruani të dhënat dhe më shumë nga sa mirë i menaxhoni ato. Një server on-prem i papatched, i konfiguruar dobët është më i rrezikshëm se një API i menaxhuar i pjekur.

Boshti i Vendimit: Cili Kur?

Tre pyetje drejtojnë vendimin:

  1. Sovraniteti i të dhënave: A e ndalon ligji ose kontrata largimin e të dhënave nga institucioni/vendi? Nëse po, do të shtyheni drejt VPC/on-prem.
  2. Vëllimi dhe kostoja: A është përdorimi shumë i lartë dhe i parashikueshëm? Vëllimet shumë të larta të vetë-strehimit mund të zvogëlojnë kostot për njësi; API-ja e menaxhuar me volum të ulët/të çrregullt është pothuajse gjithmonë e lirë.
  3. Kapaciteti operacional: A keni ekipin për të mirëmbajtur infrastrukturën GPU, përditësimin e modelit, shkallëzimin dhe rregullimin e sigurisë? Përndryshe pritja juaj është një kosto e fshehur.

Tabela e shkëmbimit

Madhësia

API e menaxhuar

VPC

On-Prem (peshë e hapur)

Sovraniteti i të dhënave

Besoni ofruesit

E lartë (në kufirin e rrjetit tuaj)

Më e larta (nuk ngrihet kurrë)

Ngarkesa e funksionimit

shumë i ulët

e mesme

lartë

Kostoja fillestare

E ulët (paguani si të shkoni)

e mesme

Lartë (hardware)

shkallëzim

automatike

Menaxhuar

përgjegjësinë tuaj

Cilësia/monedha e modelit

më i ri, automatik

varet

Ju përditësoni

kontrollin

të ulëta

lartë

plot

Hap pas hapi: Vendimi i pritjes

  1. Përcaktoni klasën e të dhënave. Në çfarë niveli konfidencialiteti do të përpunohen të dhënat?
  2. Verifikoni kufizimet ligjore. A mund të dalin të dhënat? (KVKK, rregullore sektori, kontratë.)
  3. Vlerësoni volumin. Kërkesa mujore/token vëllimi dhe kurba e rritjes.
  4. Llogaritni TCO. Jo vetëm GPU; energjia, mirëmbajtja, ekipi, siguria, teprica.
  5. Mendoni hibrid. Një model hibrid që përpunon të dhëna të ndjeshme në on-prem/VPC dhe të dhëna jo të ndjeshme në API-në e menaxhuar është shpesh më i qëndrueshëm.

Katër modele të kopjueshme

Kërkesa e vendimit të pritjes:

Vendosni hostimin për përdorimin e mëposhtëm: {{ skenar }}Pyetje:- Cila është klasa e privatësisë së të dhënave që do të përpunohen? (publik/i brendshëm/konfidencial/tepër sekret)- A lejon ligji/kontrata të dalin jashtë organizatës?- Parashikimi mujor i vëllimit dhe parashikueshmëria?- A ka kapacitet operacionesh/grupi GPU? Rekomandim: "API i menaxhuar / VPC / On-prem / Hybrid" + justifikimi.

Lista e artikujve TCO (për vetë-pritje):

Llogaritni koston totale të pronësisë nga:- Blerja/qiraja e harduerit (GPU)- Energjia dhe ftohja- Njeriu: MLOps + koha e ekipit të sigurisë- Përditësimi i modelit dhe testimi i fuqisë punëtore- Teprica/rikuperimi nga fatkeqësitë- Rregullimi dhe monitorimi i sigurisë Krahasoni këtë me faturën mujore për API-në e menaxhuar për një horizont 12-24 mujor.

Rregulli hibrid i rrugëtimit:

Drejtoni çdo kërkesë bazuar në klasën e të dhënave:- të dhënat "sekret / top sekret" -> modeli on-prem/VPC- të dhënat "publike / të brendshme" -> API i menaxhuar (më i fuqishëm/më i lirë) Shkruani vendimin e përcjelljes dhe klasën e të dhënave në regjistrin e auditimit.

Hap njoftimin e kontrollit të sigurisë së peshës:

Vlerësoni modelin tonë të vetë-strehuar:- A lejon licenca përdorim komercial dhe në skenarin tonë?- Peshat e modelit nga burimi i besuar, integriteti (hash) i verifikuar?- A janë instaluar korrigjimi i serverit, izolimi i rrjetit, kontrolli i aksesit?- A janë monitorimi dhe regjistrimi po aq i pjekur sa API-ja e menaxhuar? Shënoni ndonjë artikull që mungon si "ON".

Prompt i dobët / Prompt i fortë

qasje e dobët

Qasje e fortë

"On-prem është më i sigurt, përdorni gjithmonë atë"

Vendim i bazuar në sovranitetin e të dhënave + vëllim + kapacitet

Vetëm duke parë koston e GPU-së

TCO e plotë (energjia, ekuipazhi, përditësimet, siguria)

Duke u mbyllur në një model të vetëm pritës

Hibrid: kursimi sipas klasës së të dhënave

Vrapim pa ulur peshën e hapur dhe verifikuar atë

Licenca + integriteti + patch + kontrolli i gjurmës

Tre Mini Rastet

Rasti 1 - Mandati i paraburgimit ishte vendimi i duhur. Një kontraktor i mbrojtjes duhej të përpunonte dokumente shumë të klasifikuara; Kontrata ndalonte nxjerrjen e të dhënave jashtë vendit. API-ja e menaxhuar u eliminua që në fillim. U krijua modeli me peshë të hapur on-prem; Kostoja ishte e lartë, por ishte opsioni i vetëm i pajtueshëm.

Rasti 2 — Vendimi konfidencial TCO anulohet. Një startup planifikoi të kalonte në vetë-hosting sepse "API është i shtrenjtë". Në llogaritjen e TCO-së, ju përfshini jo vetëm GPU-në; Shtoni 2 inxhinierë MLOps me kohë të plotë, ngarkesën e përditësimit dhe tepricën, dhe totali 24-mujor është dyfishi i API-së së menaxhuar. Ata mbetën në API sepse vëllimet e tyre ishin të ulëta dhe sporadike.

Rasti 3 - Hybrid dha më të mirën. Asistenti i qendrës së thirrjeve të një banke po përpunonte dy lloje të dhënash: pyetjet e përgjithshme të produktit dhe të dhënat e llogarisë specifike të klientit. Të dhënat e llogarisë i drejtohen modelit brenda VPC, pyetjet e përgjithshme i drejtohen API-së së fuqishme të menaxhuar. Të dhënat e ndjeshme nuk dolën kurrë, cilësia e modelit më të fortë u përdor për pyetje të përgjithshme; kostoja dhe përshtatja janë optimizuar së bashku.

Këshillë: Vendimi nuk duhet të jetë binar (të gjitha ose asgjë). Arkitektura hibride - kursimi i të dhënave sipas klasës - zgjidh njëkohësisht pajtueshmërinë dhe koston në shumicën e skenarëve të ndërmarrjes.

Gabimet e zakonshme

  • Supozoni se "hotja e vet është automatikisht më e sigurt"; kurse siguria varet nga cilësia e menaxhimit.
  • Duke menduar se TCO është vetëm kosto GPU; ekipi, energjia, përditësimi dhe harrimi i sigurisë.
  • Kalimi në vetë-strehim me volum të ulët/të parregullt dhe rritja e kostos së njësisë.
  • Përdorimi i modelit me peshë të hapur pa verifikuar licencën dhe integritetin (hash).
  • Mos instalimi i monitorimit/regjistrimit aq të pjekur sa API-ja e menaxhuar në serverin on-prem.
  • Marrja e një vendimi binar pa marrë parasysh fare opsionin hibrid.

Në përmbledhje

  • API-ja e menaxhuar është më e lehta nga ana operative, por të dhënat shkojnë te ofruesi; VPC/on-prem mban të dhënat në kufirin tuaj.
  • Tre pyetje nxisin vendimin: sovraniteti i të dhënave, parashikueshmëria e vëllimit/kostos dhe kapaciteti operacional.
  • "Vetë-strehimi është më i sigurt" është një keqkuptim; Siguria nuk varet nga vendi ku i ruani të dhënat, por nga sa mirë i menaxhoni ato.
  • Llogaritni TCO-në e saktë: energjinë, ekipin, përditësimin, tepricën dhe sigurinë, si dhe GPU.
  • Arkitektura hibride (drejtimi i të dhënave sipas klasës) balancon njëkohësisht pajtueshmërinë dhe koston në shumicën e skenarëve të ndërmarrjes.

Detyra e aplikimit

Zgjidhni një përdorim të AI dhe ndani të dhënat që do të përpunohen në një klasë të privatësisë. Gjeneroni një rekomandim me kërkesën e vendimit pritës. Më pas plotësoni listën e artikujve TCO për pritjen tuaj dhe krahasoni totalin 24-mujor me faturën e menaxhuar të API-së. Më në fund, shkruani një draft rregulli hibrid të rrugëtimit: cilat të dhëna shkojnë ku?

listë kontrolli

  • [ ] Kam përcaktuar klasën e konfidencialitetit dhe kufizimin ligjor të të dhënave që do të përpunohen.
  • [ ] Kam marrë vendimin e pritjes bazuar në sovranitetin + vëllimin + kapacitetin.
  • [ ] Kam llogaritur TCO-në me artikujt e plotë (përfshirë jo GPU).
  • [ ] Kam kontrolluar licencën, integritetin, rregullimin dhe monitorimin në vetë-hosting.
  • [ ] Kam konsideruar opsionin hibrid të rrugëtimit.
  • [ ] Kam dokumentuar vendimin dhe arsyetimin e tij.