Nyereség:
- Képes kiértékelni a felügyelt API, a VPC és az on-prem hosting közötti kompromisszumot
- Az adatszuverenitás, a mennyiség és a működési kapacitás alapján dönthet a tárhelyről
- Képes a teljes tulajdonlási költség (TCO) kiszámítására teljes tételekkel és hibrid architektúrával
Egyes szervezetek számára az „adatküldés egy szolgáltatónak” – bármilyen biztonságos is legyen – nem elfogadható. A védelmi iparban, az állami, a banki és egyes egészségügyi forgatókönyvekben az adatok soha nem léphetnek túl az intézmény határain. Ezen a ponton a saját modell hosztolása kerül előtérbe: nyílt súlyú modellek, amelyek saját felhőhálózatban (VPC) vagy saját szervereken (on-prem) futnak. Ebben az egységben megismerjük a felügyelt API és az önkiszolgáló üzemeltetése közötti kompromisszumokat, amikor annak van értelme, valamint a teljes tulajdonlási költséget (TCO).
fogalmak
- Felügyelt API: A modellszolgáltató infrastruktúráján fut; Küldsz egy kérelmet és kapsz választ. Az üzemeltetési rezsi minimális, de az adatok a szolgáltatóhoz kerülnek.
- Nyitott súlyú modell: A modell paraméterei (súlyok) letölthetők; Futtathatja saját hardverén. Ez nem feltétlenül ugyanaz, mint a „nyílt forráskód” (a licenc eltérő lehet).
- VPC hosting (virtuális privát felhő): a modell futtatása saját elszigetelt felhőhálózatában; Az adatok a hálózat határán maradnak, de az infrastruktúra továbbra is a felhőben van.
- Helyszíni (on-premises): A modell teljes egészében a saját adatközpontjának hardverén történő futtatása; legmagasabb vezérlés, legnagyobb üzemi terhelés.
Figyelem: „A saját tárhely mindig biztonságosabb” tévhit. A biztonság kevésbé attól függ, hogy hol tárolja az adatokat, hanem inkább attól, hogy mennyire jól kezeli azokat. Egy javítatlan, rosszul konfigurált helyszíni szerver kockázatosabb, mint egy kiforrott felügyelt API.
Döntési tengely: melyik mikor?
Három kérdés vezérli a döntést:
- Adatszuverenitás: Törvény vagy szerződés tiltja-e az adatok elhagyását az intézményből/országból? Ha igen, akkor a VPC/on-prem felé tolják.
- Mennyiség és költség: A felhasználás nagyon magas és kiszámítható? A nagyon nagy mennyiségű önálló üzemeltetés csökkentheti az egységköltségeket; Az alacsony/szabálytalan mennyiségen kezelt API szinte mindig olcsó.
- Működési kapacitás: Megvan a csapat a GPU-infrastruktúra karbantartására, a modellfrissítésre, a méretezésre és a biztonsági javításokra? Ellenkező esetben a saját tárhely rejtett költség.
Kompromisszum táblázat
Méret
Felügyelt API
VPC
On-Prem (nyitott súly)
Adatszuverenitás
Bízzon a szolgáltatóban
Magas (a hálózati korláton)
A legmagasabb (soha nem emelkedik)
Működési terhelés
túl alacsony
közepes
magas
Kezdeti költség
Alacsony (kirovó fizetés)
közepes
Magas (hardver)
méretezés
automatikus
Kezelve
a te felelősséged
Modell minősége/valuta
legújabb, automata
attól függ
Frissítesz
irányítani
alacsony
magas
tele
Lépésről lépésre: Hosting döntés
- Határozza meg az adatosztályt. Milyen titoktartási szinten kezelik az adatokat?
- Ellenőrizze a jogi korlátozást. Kikerülhetnek az adatok? (KVKK, ágazati szabályozás, szerződés.)
- Becsülje meg a hangerőt. Havi kérés/token mennyiség és növekedési görbe.
- Számítsa ki a TCO-t. Nem csak a GPU; energia, karbantartás, csapat, biztonság, redundancia.
- Gondolj hibridre. Gyakran a legstabilabb az a hibrid modell, amely érzékeny adatokat dolgoz fel az on-prem/VPC-ben, és nem érzékeny adatokat a felügyelt API-ban.
Négy másolható sablon
Tárhelyről szóló döntés:
Döntse el a tárhelyet a következő felhasználásra: {{ forgatókönyv }}Kérdések:- Milyen adatvédelmi osztályba tartoznak a feldolgozandó adatok? (nyilvános/belső/bizalmas/szigorúan titkos)- A törvény/szerződés lehetővé teszi, hogy az adatok a szervezeten kívülre kerüljenek?- Havi mennyiség előrejelzés és kiszámíthatóság?- Van-e működési/GPU csapatkapacitás? Javaslat: "Felügyelt API / VPC / On-prem / Hibrid" + indoklás.
TCO-elemlista (önálló tároláshoz):
A teljes tulajdonlási költség kiszámítása a következők szerint: - Hardver (GPU) vásárlása/lízingje - Energia és hűtés - Ember: MLOps + biztonsági csapatidő - Modellfrissítés és tesztelő munkaerő - Redundancia/katasztrófa utáni helyreállítás - Biztonsági javítások és felügyelet Hasonlítsa össze ezt a felügyelt API havi számlájával 12-24 hónapos távon.
Hibrid útválasztási szabály:
Minden kérés irányítása adatosztály alapján:- "titkos / szigorúan titkos" adatok -> on-prem/VPC modell- "nyilvános / belső" adatok -> kezelt API (hatékonyabb/olcsóbb) Írja be a továbbítási döntést és az adatosztályt az auditnaplóba.
Nyissa meg a súlybiztonsági ellenőrzést:
Értékelje saját üzemeltetésű modellünket:- A licenc lehetővé teszi-e a kereskedelmi felhasználást és a mi forgatókönyvünkben?- Megbízható forrásból származó modellsúlyok, sértetlenség (hash) ellenőrzött?- Szerverfoltozás, hálózati elkülönítés, hozzáférés-vezérlés telepítve van?- A felügyelet és a naplózás olyan kiforrott, mint a felügyelt API? A hiányzó elemeket "BE"-ként jelölje.
Gyenge felszólítás / Erős felszólítás
rossz megközelítés
Erős megközelítés
"Az on-prem biztonságosabb, mindig használd"
Döntés adatszuverenitás + mennyiség + kapacitás alapján
Csak a GPU költségét nézzük
Teljes TCO (energia, személyzet, frissítések, biztonság)
Egyetlen tárhelymodellbe zárva
Hibrid: adatosztály szerinti útválasztás
Futás a nyitott súly leengedése és ellenőrzése nélkül
Licenc + integritás + javítás + nyomkövetés
Három mini tok
1. eset – A helyszíni megbízás helyes döntés volt. Egy védelmi vállalkozónak magasan titkosított dokumentumokat kellett feldolgoznia; A szerződés megtiltotta, hogy adatokat vigyenek ki az országból. A menedzselt API kezdettől fogva megszűnt. Létrehozták az on-prem nyitott súlymodellt; A költség magas volt, de ez volt az egyetlen kompatibilis lehetőség.
2. eset – A bizalmas TCO visszavont határozata. Egy startup azt tervezte, hogy áttér az önálló üzemeltetésre, mert „az API drága”. A TCO számításba nem csak a GPU-t veszi figyelembe; Adjon hozzá 2 teljes munkaidős MLOps mérnököt, frissítési terhelést és redundanciát, és a 24 hónap teljes összege kétszerese a felügyelt API-énak. Az API-ban maradtak, mert mennyiségük alacsony és szórványos volt.
3. eset – A hibrid a legjobbat nyújtotta. Egy bank call center-asszisztense kétféle adatot dolgozott fel: általános termékkérdéseket és ügyfélspecifikus számlaadatokat. A fiókadatok a VPC-n belüli modellhez, az általános kérdések pedig a hatékony menedzselt API-hoz irányulnak. Az érzékeny adatok soha nem kerültek ki, általános kérdéseknél a legerősebb modell minőségét használták fel; a költség és az illeszkedés együtt van optimalizálva.
Tipp: A döntésnek nem kell binárisnak lennie (mindent vagy semmit). A hibrid architektúra – az adatok osztályonkénti útválasztása – egyszerre oldja meg a megfelelőséget és a költségeket a legtöbb vállalati forgatókönyvben.
Gyakori hibák
- Tegyük fel, hogy „a saját tárhely automatikusan biztonságosabb”; míg a biztonság az irányítás minőségétől függ.
- Azt gondolva, hogy a TCO csak a GPU költsége; csapat, energia, frissítés és a biztonság elfelejtése.
- Váltás saját üzemeltetésre alacsony/szabálytalan hangerő mellett és az egységköltség növelése.
- Nyílt súlyú modell használata engedély és integritás (hash) ellenőrzése nélkül.
- Nincs olyan kiforrott megfigyelési/naplózási telepítés, mint a felügyelt API a helyszíni kiszolgálón.
- Bináris döntés meghozatala a hibrid opció megfontolása nélkül.
Összefoglalva
- A felügyelt API a legegyszerűbb működési szempontból, de az adatok a szolgáltatóhoz kerülnek; A VPC/on-prem a határon tartja az adatokat.
- Három kérdés vezérli a döntést: adatszuverenitás, mennyiség/költség kiszámíthatóság és működési kapacitás.
- "Az önálló tárhely biztonságosabb" tévhit; A biztonság nem attól függ, hogy hol tárolja az adatokat, hanem attól, hogy mennyire jól kezeli azokat.
- Számítsa ki a pontos TCO-t: energia, csapat, frissítés, redundancia és biztonság, valamint GPU.
- A hibrid architektúra (az adatok osztályonkénti útválasztása) a legtöbb vállalati forgatókönyvben egyidejűleg egyensúlyba hozza a megfelelőséget és a költségeket.
Pályázati feladat
Válasszon egy mesterséges intelligencia használatot, és válassza szét a feldolgozandó adatokat egy adatvédelmi osztályba. Hozzon létre egy ajánlást a tárhelyről szóló döntéssel. Ezután töltse ki a TCO tétellistát saját tárhelyéhez, és hasonlítsa össze a 24 havi végösszeget a kezelt API-számlával. Végül írjon egy hibrid útválasztási szabály tervezetet: milyen adatok hova kerülnek?
ellenőrző lista
- [ ] Meghatároztam a kezelendő adatok titoktartási osztályát és törvényi korlátozását.
- [ ] A fogadási döntést a szuverenitás + mennyiség + kapacitás alapján hoztam meg.
- [ ] A TCO-t teljes tételekkel számoltam (beleértve a nem GPU-t is).
- [ ] Ellenőriztem a licencet, az integritást, a foltozást és a monitorozást az öntárhelyen.
- [ ] Megfontoltam a hibrid útválasztási lehetőséget.
- [ ] A határozatot és annak indoklását dokumentáltam.