Kaip diegti dirbtinio intelekto modelius

Kaip diegti dirbtinio intelekto modelius

Trumpas atsakymas: Dirbtinio intelekto modelio diegimas reiškia pateikimo modelio pasirinkimą (realiojo laiko, paketinis, srautinis arba periferinis), o tada viso kelio atkartojimą, stebėjimą, saugumą ir grįžtamumą. Kai viską versuojate ir lyginate p95/p99 delsą su gamybiniais tikslais naudojamais paketais, išvengiama daugumos „veikia mano nešiojamajame kompiuteryje“ klaidų.

Svarbiausios išvados:

Diegimo modeliai: prieš pasirinkdami įrankius, pasirinkite diegimą realiuoju laiku, paketiniu būdu, srautiniu būdu arba periferiniu būdu.

Atkuriamumas: modeliuokite, funkcijas, kodą ir aplinką, kad būtų išvengta nukrypimų.

Stebimumas: Nuolat stebimos delsos uodegos, paklaidos, sodrumas ir duomenų arba išvesties pasiskirstymas.

Saugus diegimas: naudokite kintamųjų, mėlynai žalių arba šešėlinių testų nustatymus su automatinio atšaukimo slenksčiais.

Saugumas ir privatumas: taikykite autentifikavimą, dažnio apribojimus ir paslapčių valdymą bei sumažinkite asmeninę informaciją žurnaluose.

Kaip diegti dirbtinio intelekto modelius? Infografika

Straipsniai, kuriuos galbūt norėsite perskaityti po šio: 

🔗 Kaip išmatuoti dirbtinio intelekto našumą
Sužinokite apie metrikas, lyginamuosius rodiklius ir realaus pasaulio patikrinimus, kad gautumėte patikimus dirbtinio intelekto rezultatus.

🔗 Kaip automatizuoti užduotis naudojant dirbtinį intelektą
Pasikartojantį darbą paverskite darbo eigomis naudodami raginimus, įrankius ir integracijas.

🔗 Kaip testuoti dirbtinio intelekto modelius
Projektuokite vertinimus, duomenų rinkinius ir balus, kad modelius būtų galima objektyviai palyginti.

🔗 Kaip kalbėtis su dirbtiniu intelektu
Užduokite geresnius klausimus, pateikite kontekstą ir greitai gaukite aiškesnius atsakymus.

1) Ką iš tikrųjų reiškia „diegimas“ (ir kodėl tai ne tik API) 🧩

Kai žmonės sako „įdiegti modelį“, jie gali turėti omenyje bet kurį iš šių dalykų:

Taigi diegimas yra mažiau „modelio prieinamumo užtikrinimas“ ir labiau panašus į:

Tai panašu į restorano atidarymą. Svarbu pagaminti puikų patiekalą, žinoma. Bet vis tiek reikia pastato, personalo, šaldymo įrangos, valgiaraščių, tiekimo grandinės ir būdo, kaip susidoroti su vakarienės skubėjimu neverkiant šaldymo kameroje. Ne pati tobuliausia metafora... bet supratote. 🍝

2) Kas daro „Kaip diegti dirbtinio intelekto modelius“ versiją gerą ✅

„Geras dislokavimas“ yra nuobodus gerąja prasme. Esant spaudimui, jis elgiasi nuspėjamai, o kai taip nėra, tai galima greitai nustatyti.

Štai kaip paprastai atrodo „gerai“:

  • Atkartojamos versijos
    Tas pats kodas + tos pačios priklausomybės = tas pats elgesys. Jokių šiurpių „veikia mano nešiojamajame kompiuteryje“ nuotaikų 👻 („Docker“: kas yra konteineris?)

  • Aiški sąsajos sutartis.
    Apibrėžti įėjimai, išėjimai, schemos ir kraštiniai atvejai. Jokių netikėtų tipų 2 val. nakties. (OpenAPI: Kas yra OpenAPI?,JSON schema)

  • Realybę atitinkantis našumas.
    Vėlavimas ir pralaidumas, išmatuoti naudojant gamybinę įrangą ir realius naudinguosius krūvius.

  • Stebėjimas su dantimis.
    Metrikos, žurnalai, pėdsakai ir dreifo patikrinimai, kurie suaktyvina veiksmus (ne tik ataskaitų suvestines, kurių niekas neatidaro). (SRE knyga: Paskirstytų sistemų stebėjimas)

  • Saugaus diegimo strategija –
    „Canary“ arba „Blue-Green“, lengvas ankstesnis panaikinimas, versijų kūrimas, kuriam nereikia maldos. („Canary“ leidimas, „Blue-Green“ diegimas).

  • Kainos suvokimas.
    „Greitai“ yra puiku, kol sąskaita neatrodo kaip telefono numeris 📞💸

  • Saugumas ir privatumas, integruoti į
    paslapčių valdymą, prieigos kontrolę, asmeninių duomenų tvarkymą, audituojamumą. („Kubernetes Secrets“, NIST SP 800-122)

Jei galite tai daryti nuosekliai, jau lenkiate daugumą komandų. Būkime atviri.

3) Pasirinkite tinkamą diegimo modelį (prieš pasirinkdami įrankius) 🧠

Realaus laiko API išvados ⚡

Geriausia, kai:

  • vartotojams reikia momentinių rezultatų (rekomendacijų, sukčiavimo patikrinimų, pokalbių, suasmeninimo)

  • sprendimai turi būti priimami prašymo pateikimo metu

Atsargumo priemonės:

Partijos taškų skaičiavimas 📦

Geriausia, kai:

  • prognozės gali būti atidėtos (rizikos vertinimas per naktį, klientų praradimo prognozavimas, ETL praturtinimas) („Amazon SageMaker Batch Transform“)

  • norite ekonomiško ir paprastesnio veikimo

Atsargumo priemonės:

  • duomenų naujumas ir užpildymas

  • išlaikant funkcijų logiką suderinamą su mokymu

Srautinio perdavimo išvada 🌊

Geriausia, kai:

  • įvykius apdorojate nuolat (daiktų internetas, paspaudimų srautai, stebėjimo sistemos)

  • norite beveik realiuoju laiku priimamų sprendimų be griežto užklausų ir atsakymų proceso

Atsargumo priemonės:

Kraštinių tinklų diegimas 📱

Geriausia, kai:

Atsargumo priemonės:

Pirma pasirinkite šabloną, o tada pasirinkite steką. Priešingu atveju kvadratinį modelį priversite įterpti į apvalų vykdymo aplinką. Ar kažkas panašaus. 😬

4) Modelio supakavimas taip, kad jis atlaikytų sąlytį su gamybos įranga 📦🧯

Čia tyliai miršta dauguma „lengvų diegimų“.

Versija viskas (taip, viskas)

  • Modelio artefaktas (svoriai, grafikas, tokenizeris, etikečių žemėlapiai)

  • Funkcijų logika (transformacijos, normalizavimas, kodavimo įrenginiai)

  • Išvadų kodas (priešapdorojimas / poapdorojimas)

  • Aplinka (Python, CUDA, sistemos bibliotekos)

Paprastas metodas, kuris veikia:

  • traktuokite modelį kaip išleidimo artefaktą

  • išsaugokite jį su versijos žyme

  • Reikalingas modelio kortelės tipo metaduomenų failas: schema, metrikos, mokymo duomenų momentinės kopijos pastabos, žinomi apribojimai (modelio kortelės modelių ataskaitoms)

Konteineriai padeda, bet negarbinkite jų 🐳

Konteineriai yra puikūs, nes jie:

Bet vis tiek reikia tvarkytis:

Standartizuokite sąsają

Iš anksto nuspręskite įvesties / išvesties formatą:

  • JSON paprastumui (lėtesnis, bet draugiškas) (JSON schema)

  • „Protobuf“ našumui (protokolo buferių apžvalga)

  • failų pagrindu sukurtos vaizdų / garso įrašų (ir metaduomenų) naudingosios apkrovos

Ir prašome patikrinti įvestis. Neteisingos įvesties duomenys yra pagrindinė „kodėl grąžinamos nesąmonės“ užklausų priežastis. („OpenAPI“: Kas yra „OpenAPI“?,JSON schema)

5) Aptarnavimo parinktys – nuo ​​„paprasto API“ iki pilno modelio serverių 🧰

Yra du įprasti maršrutai:

A variantas: Programėlės serveris + išvadų kodas („FastAPI“ stiliaus metodas) 🧪

Jūs rašote API, kuri įkelia modelį ir pateikia prognozes. (FastAPI)

Privalumai:

  • lengva pritaikyti

  • puikiai tinka paprastesniems modeliams arba ankstyvos stadijos produktams

  • paprastas autentifikavimas, maršrutizavimas ir integravimas

Minusai:

  • jūsų pačių našumo derinimas (grupavimas, sriegimas, GPU panaudojimas)

  • išradinėsite kai kuriuos ratus, galbūt iš pradžių ir blogai

B variantas: Modelinis serveris („TorchServe“ / „Triton“ stiliaus metodas) 🏎️

Specializuoti serveriai, kurie tvarko:

Privalumai:

  • geresni našumo modeliai iš karto

  • aiškesnis aptarnavimo ir verslo logikos atskyrimas

Minusai:

  • papildomas operacinis sudėtingumas

  • konfigūracija gali atrodyti… sudėtinga, tarsi reguliuojant dušo temperatūrą

Hibridinis modelis yra labai dažnas:

6) Palyginimo lentelė – populiarūs diegimo būdai (su nuoširdžia nuomone) 📊😌

Žemiau pateikiama praktinė apžvalga apie parinktis, kurias žmonės iš tikrųjų naudoja aiškindamiesi, kaip diegti dirbtinio intelekto modelius.

Įrankis / metodas Auditorija Kaina Kodėl tai veikia
„Docker“ + „FastAPI“ (arba panašus) Mažos komandos, startuoliai Laisvas Paprasta, lankstu, greitai pristatoma – tačiau „pajusite“ kiekvieną mastelio keitimo problemą („Docker“, „FastAPI“)
Kubernetes (pasidaryk pats) Platformos komandos Priklausomas nuo infraraudonųjų spindulių Valdymas + mastelio keitimas… taip pat daug rankenėlių, kai kurios iš jų prakeiktos („Kubernetes HPA“)
Valdoma ML platforma (debesų ML paslauga) Komandos, norinčios mažiau operacijų Mokėkite, kiek naudojate Integruoti diegimo darbo srautai, stebėjimo kabliai – kartais brangūs, jei galiniuose įrenginiuose visada yra įjungtų („Vertex AI“ diegimas, „SageMaker“ realaus laiko išvados).
Serverių neturinčios funkcijos (lengvam išvadų teikimui) Įvykiais pagrįstos programos Mokėti už naudojimą Puikiai tinka staigiam eismui, bet šalti užvedimai ir modelio dydis gali sugadinti dieną 😬 (AWS Lambda šalti užvedimai)
NVIDIA Triton išvadų serveris Į rezultatus orientuotos komandos Nemokama programinė įranga, infrastruktūros išlaidos Puikus GPU panaudojimas, paketavimas, kelių modelių konfigūravimas reikalauja kantrybės („Triton“: dinaminis paketavimas)
TorchServe „PyTorch“ dominuojančios komandos Nemokama programinė įranga Tinkami numatytieji pateikimo modeliai – didelio masto rodymui gali reikėti juos pakoreguoti („TorchServe“ dokumentai)
BentoML (pakuotė + patiekimas) ML inžinieriai Nemokamas branduolys, priedai skiriasi Sklandus paketas, maloni kūrėjo patirtis – vis tiek reikia infrastruktūros pasirinkimų („BentoML“ paketas diegimui)
Ray Serve Paskirstytųjų sistemų žmonės Priklausomas nuo infraraudonųjų spindulių Horizontalus mastelio keitimas, tinka konvejeriams – mažiems projektams atrodo „didelis“ („Ray Serve“ dokumentai)

Pastaba prie stalo: „Nemokama“ yra reali terminologija. Nes tai niekada nebūna nemokama. Visada kažkur yra sąskaita, net jei tai jūsų miegas. 😴

7) Našumas ir mastelio keitimas – delsa, pralaidumas ir tiesa 🏁

Našumo derinimas yra tai, kur diegimas tampa įgūdžiu. Tikslas nėra „greitas“. Tikslas – nuosekliai pakankamai greitas.

Svarbiausi rodikliai

Įprastos traukimo svirtys

  • Paketavimas.
    Apjungia užklausas, kad būtų maksimaliai išnaudotas GPU. Puikiai tinka pralaidumui, bet per daug gali pakenkti delsai. („Triton“: dinaminis paketavimas).

  • Kvantavimas.
    Mažesnis tikslumas (pvz., INT8) gali pagreitinti išvadų darymą ir sumažinti atminties kiekį. Gali šiek tiek sumažinti tikslumą. Kartais, stebėtina, ne. (Kvantavimas po mokymo)

  • kompiliavimas / optimizavimas
    , grafų optimizavimo įrankiai, „TensorRT“ tipo srautai. Galingi, bet derinimas gali būti sudėtingas 🌶️ (ONNX, ONNX vykdymo laiko modelių optimizavimas)

  • Talpyklos talpinimas
    Jei įvestys kartojasi (arba galite talpinti įterpimus), galite daug sutaupyti.

  • Automatinis
    mastelio keitimas pagal procesoriaus / grafikos procesoriaus naudojimą, eilės gylį arba užklausų dažnį. Eilės gylis yra nepakankamai įvertintas. („Kubernetes HPA“)

Keistas, bet teisingas patarimas: matuokite naudodami gamyboje naudojamus naudingosios apkrovos dydžius. Maži testavimo naudingosios apkrovos jums meluoja. Jie mandagiai šypsosi, o vėliau jus išduoda.

8) Stebėjimas ir matomumas – neskraidykite aklai 👀📈

Modelio stebėjimas – tai ne tik veikimo laiko stebėjimas. Norite sužinoti, ar:

Ką stebėti (minimalus tinkamas rinkinys)

Paslaugos būklė

Modelio elgesys

  • įvesties požymių pasiskirstymai (pagrindinė statistika)

  • įterpimo normos (įterpimo modeliams)

  • rezultatų pasiskirstymai (pasitikėjimas, klasių mišinys, balų intervalai)

  • įvesties anomalijų aptikimas (šiukšlių įvedimas, šiukšlių išvedimas)

Duomenų ir koncepcijos dreifas

Registravimas, bet ne „registruoti viską amžinai“ metodas 🪵

Žurnalas:

Saugokite privatumą. Jūs nenorite, kad jūsų žurnalai taptų duomenų nutekėjimu. (NIST SP 800-122)

9) CI/CD ir diegimo strategijos – modelius traktuokite kaip tikrus leidimus 🧱🚦

Jei norite patikimų diegimų, sukurkite kanalą. Net ir paprastą.

Tvirtas srautas

  • Vienetų testai išankstiniam ir papildomam apdorojimui

  • Integravimo testas su žinomu įvesties-išvesties „auksiniu rinkiniu“

  • Apkrovos bandymo bazinė linija (net ir lengva)

  • Sukurti artefaktą (konteineris + modelis) („Docker“ kūrimo geriausios praktikos)

  • Įdiegimas testavimo etape

  • „Canary“ išleidimas nedidelei srauto daliai („Canary Release“)

  • Palaipsniui didinkite

  • Automatinis pagrindinių slenksčių atšaukimas (mėlynai žalias diegimas)

Išvyniojimo modeliai, kurie išsaugo jūsų sveiką protą

Ir versuokite savo galinius taškus arba maršrutą pagal modelio versiją. Ateityje jums padėkosite. Dabartiniu metu jūs taip pat jums padėkosite, bet tyliai.

10) Saugumas, privatumas ir „prašome nenutekinti informacijos“ 🔐🙃

Apsauga dažniausiai pasirodo vėlai, kaip nekviestas svečias. Geriau jį pakviesti anksti.

Praktinis kontrolinis sąrašas

  • Autentifikavimas ir autorizavimas (kas gali iškviesti modelį?)

  • Spartos ribojimas (apsauga nuo piktnaudžiavimo ir atsitiktinių audrų) (API šliuzo greičio mažinimas)

  • Paslapčių valdymas (nėra raktų kode, nėra raktų konfigūracijos failuose...) („AWS Secrets Manager“, „Kubernetes Secrets“)

  • Tinklo valdikliai (privatūs potinkliai, paslaugų tarpusavio politikos)

  • Audito žurnalai (ypač jautrių prognozių)

  • Duomenų kiekio mažinimas (saugokite tik tai, ką būtina) (NIST SP 800-122)

Jei modelis liečia asmens duomenis:

  • redagavimo arba maišos identifikatoriai

  • vengti neapdorotų naudingųjų duomenų registravimo (NIST SP 800-122)

  • apibrėžti saugojimo taisykles

  • dokumentų duomenų srautas (nuobodus, bet saugus)

Be to, generatyviniams modeliams gali būti svarbus greitas įterpimas ir išvesties piktnaudžiavimas. Pridėti: (OWASP 10 geriausių LLM programų, OWASP: greitas įterpimas)

  • įvesties valymo taisyklės

  • išvesties filtravimas, jei reikia

  • apsauginiai turėklai įrankių iškvietimui arba duomenų bazės veiksmams

Nė viena sistema nėra tobula, bet jūs galite ją padaryti mažiau trapią.

11) Dažni spąstai (dar žinomi kaip įprasti spąstai) 🪤

Štai klasika:

Jei skaitote tai ir galvojate „taip, mes darome du tokius“, sveiki atvykę į klubą. Klube yra užkandžių ir lengvas stresas. 🍪

12) Apibendrinimas – Kaip diegti dirbtinio intelekto modelius neišeinant iš proto 😄✅

Diegimas yra ta vieta, kur dirbtinis intelektas tampa tikru produktu. Tai nėra žavinga, bet būtent taip užsitarnaujamas pasitikėjimas.

Trumpa apžvalga

Taip, dirbtinio intelekto modelių diegimas iš pradžių gali atrodyti kaip žongliravimas liepsnojančiais boulingo kamuoliais. Tačiau kai jūsų srautas tampa stabilus, tai tampa keistai malonus procesas. Tarsi pagaliau sutvarkytumėte netvarkingą stalčių... tik stalčius skirtas gamybiniam srautui.

Realus pavyzdys: pagalbos bilietų triažo modelio diegimas

Scenarijus

Įsivaizduokite išgalvotą, bet realią SaaS įmonę su 12 palaikymo agentų ir apie 900 klientų užklausų per savaitę. Komanda nori dirbtinio intelekto modelio, kuris klasifikuotų gaunamas užklausas pagal kategoriją, skubumą ir siūlomą maršrutą prieš žmogui agentui atsakant.

Tai nėra visiškai automatizuotas palaikymo robotas. Šis modelis nesiunčia atsakymų klientams. Jis tiesiog padeda greičiau nukreipti užklausas, pažymėti rizikingas bylas ir suteikti agentams aiškesnę pradžios poziciją.

Geriausias diegimo modelis čia paprastai yra realaus laiko API išvados. Kiekvieną naują užklausą gauna pagalbos tarnyba, dirbtinio intelekto tarnyba ją įvertina per kelis šimtus milisekundžių, o pagalbos tarnyba išsaugo numatomą kategoriją, prioritetą, patikimumo balą ir modelio versiją.

Ko reikia asistentui

Naudingi įėjimai:

bilieto tema

bilieto turinys

kliento plano tipas

paskyros regionas

produkto sritis, jei jau žinoma

ankstesnių bilietų skaičius per pastarąsias 30 dienų

Naudingos taisyklės:

niekada neregistruoti neapdorotų klientų pranešimų, jei juose yra asmens duomenų

siųsti sąskaitų ginčus, teisines grėsmes, paskyros ištrynimo užklausas ir saugumo problemas peržiūrėti žmogui

automatiškai parinkti maršrutą tik tada, kai patikimumas viršija nustatytą ribą, pvz., 0,85

išsaugoti modelio versiją su kiekviena prognoze

jei modelio paslauga lėta arba nepasiekiama, grįžkite prie rankinio triažo

Instrukcijos pavyzdys

Esate pagalbos užklausų atrankos asistentas. Kiekvieną užklausą suskirstykite į vieną kategoriją: Atsiskaitymas, Prisijungimas, Pranešimas apie klaidą, Funkcijos užklausa, Paskyros panaikinimas, Saugumas arba Kita.

Grąžinkite kategoriją, skubumo lygį, patikimumo balą, trumpą priežastį ir rekomenduojamą palaikymo eilę.

Neišgalvokite trūkstamų faktų. Jei užklausoje yra teisinės, saugumo, mokėjimo nesėkmės, paskyros ištrynimo ar pikto kliento informacijos, pažymėkite ją, kad ją peržiūrėtų žmogus.

Jei patikimumas yra mažesnis nei 0,85, kaip rekomenduojamą eilę grąžinkite „Rankinė peržiūra“.

Pavyzdinė išvestis

Silpna išvestis:

Kategorija: Klaida
Prioritetas: Aukštas
Siųsti palaikymo komandai.

Geresnis našumas:

Kategorija: Prisijungimas
Skubumas: Vidutinis
Patikimumas: 0,91
Rekomenduojama eilė: Prieiga prie paskyros
Priežastis: Klientas negali prisijungti prie savo paskyros iš naujo nustatęs slaptažodį. Neužsiminta apie jokią saugumo grėsmę ar mokėjimo problemą.
Reikalinga žmogaus peržiūra: Ne
Modelio versija: ticket-triage-v1.3

Geresnę išvestį lengviau audituoti, nes ji apima patikimumo balą, maršruto parinkimo sprendimą, priežastį ir modelio versiją.

Kaip tai išbandyti

Prieš siųsdami tiesioginį srautą modeliui, sukurkite nedidelį „auksinį rinkinį“ iš tikrų, bet anonimizuotų bilietų.

Paprastas bandymų rinkinys gali apimti:

50 atsiskaitymo kvitų

50 prisijungimo bilietų

50 klaidų pranešimų

30 atšaukimo prašymų

20 slaptumo požiūriu jautrių bilietų

20 painių arba mišrių kategorijų bilietų

Tada patikrinkite:

Ar modelis pasirenka tą pačią kategoriją kaip ir žmogus, vertinantis asmenį?

Ar teisingai perduodamos saugumo, teisinės ir atšaukimo baudos?

Ar grąžina „Rankinė peržiūra“, kai patikimumas mažas?

Ar p95 delsa išlieka mažesnė už komandos tikslinį rodiklį?

Ar paslauga saugiai sugenda, kai modelis nepasiekiamas?

Diegimui pirmiausia naudokite šešėlinį testavimą. Nusiųskite realius bilietus į naują modelį, bet dar nenaudokite jo prognozių. Palyginkite jo rezultatus su įprastu žmonių atliktu triažu kelias dienas. Jei rezultatai stabilūs, pereikite prie 5 % „canary release“, tada 25 %, o galiausiai 100 %.

Rezultatas

Iliustracinis rezultatas, pagrįstas 100 pavyzdinių bilietų laiko matavimu prieš ir po darbo eigos panaudojimo:

rankinio atrankos laikas sutrumpėjo nuo 6 minučių vienam bilietui iki 1 minutės 40 sekundžių vienam bilietui

komanda sutaupė apie 7,2 valandos, tvarkydama 100 bilietų

kategorijos atitikimas su žmogumi recenzentu buvo 87 %, vertinant 220 bilietų auksinį rinkinį

100 % iš 20 su saugumu susijusių testo užklausų buvo perduotos žmonių peržiūrai

p95 delsa buvo 480 ms gamybinės paskirties naudingosiose apkrovose

p99 delsa buvo 910 ms

Atšaukimo laikas buvo mažesnis nei 2 minutės, nes senasis modelio galinis taškas liko aktyvus „canary“ leidimo metu

Šie skaičiai nėra universalūs etalonai. Tai yra pavyzdiniai matavimai, kuriuos komanda galėtų atkurti nustatydama triažo užduočių laiką, lygindama prognozes su paženklintu testų rinkiniu ir atlikdama galinio taško apkrovos testavimą su realiais bilietų paketais.

Kas gali nutikti ne taip

Didžiausia rizika – per didelis pasitikėjimas modeliu. Užklausa, pažymėta kaip „maža skuba“, vis tiek gali turėti rimtą saugumo problemą, ypač jei klientas rašo neaiškiai.

Kitos dažnos klaidos:

naudojant nupoliruotus bandomuosius bilietus, kurie neatitinka tikrų klientų bilietų

registruojant visus klientų pranešimus su asmens duomenimis

modelio versijos neišsaugojimas su kiekviena prognoze

automatiškai nukreipti kiekvieną bilietą, net kai pasitikėjimas yra žemas

pamiršta rankinė atsarginė eilė

matuojant vidutinį delsos laiką, bet ignoruojant p95 ir p99

leisti senoms kategorijoms likti modelyje, kai palaikymo komanda pakeičia eiles

Praktiškas išsinešimui skirtas maistas

Geras dirbtinio intelekto diegimas nebūtinai turi prasidėti dideliu mastu. Pradėkite nuo vieno siauro darbo srauto, vienos aiškios sąsajos, vieno auksinio testų rinkinio ir vieno saugaus atšaukimo kelio. Jei modelis taupo laiką neslėpdamas rizikos, diegimas vertas plėtimo.

DUK

Ką reiškia diegti dirbtinio intelekto modelį gamyboje

Dirbtinio intelekto modelio diegimas paprastai apima daug daugiau nei vien prognozavimo API atskleidimą. Praktiškai tai apima modelio ir jo priklausomybių pakavimą, pateikimo modelio pasirinkimą (realiojo laiko, paketinis, srautinis arba periferinis), mastelio keitimą atsižvelgiant į patikimumą, būklės ir dreifo stebėjimą bei saugaus diegimo ir atšaukimo kelių nustatymą. Tvirtas diegimas išlieka nuspėjamai stabilus esant apkrovimui ir išlieka diagnozuojamas, jei kas nors nepavyksta.

Kaip pasirinkti diegimą realiuoju laiku, paketiniu, srautiniu būdu arba periferiniu būdu

Pasirinkite diegimo modelį pagal tai, kada reikalingos prognozės ir kokie apribojimai taikomi jūsų veiklai. Realaus laiko API tinka interaktyvioms patirtims, kur svarbus delsos laikas. Paketinis vertinimas geriausiai veikia, kai delsos yra priimtinos ir lemia ekonomiškumą. Srautinis perdavimas tinka nuolatiniam įvykių apdorojimui, ypač kai pristatymo semantika tampa sudėtinga. Diegimas periferiniame tinkle idealiai tinka darbui neprisijungus, privatumui arba itin mažo delsos reikalavimams, nors atnaujinimus ir aparatinės įrangos skirtumus valdyti tampa sunkiau.

Kokių versijų vengti diegimo klaidų atveju, kai „veikia mano nešiojamajame kompiuteryje“

Versijų kūrimas apima ne tik modelio svorius. Paprastai reikės versijuoto modelio artefakto (įskaitant tokenizerius arba etikečių žemėlapius), išankstinio apdorojimo ir funkcijų logikos, išvadų kodo ir visos vykdymo aplinkos („Python“ / „CUDA“ / sistemos bibliotekos). Modelį traktuokite kaip išleidimo artefaktą su pažymėtomis versijomis ir lengvais metaduomenimis, apibūdinančiais schemos lūkesčius, vertinimo pastabas ir žinomus apribojimus.

Ar diegti naudojant paprastą „FastAPI“ stiliaus paslaugą, ar dedikuotą modelio serverį

Paprastas programų serveris (panašus į „FastAPI“) gerai veikia su ankstyvaisiais produktais arba nesudėtingais modeliais, nes išlaikote maršrutizavimo, autentifikavimo ir integravimo kontrolę. Modelių serveris („TorchServe“ arba „NVIDIA Triton“ stiliaus) gali užtikrinti geresnį paketavimą, lygiagretumą ir GPU efektyvumą iš karto. Daugelis komandų pasirenka hibridinį serverį: modelio serverį išvadoms ir ploną API sluoksnį autentifikavimui, užklausų formavimui ir greičio apribojimams.

Kaip pagerinti delsą ir pralaidumą nepažeidžiant tikslumo

Pradėkite nuo p95/p99 delsos matavimo gamybinėje įrangoje su realiomis naudingosiomis apkrovomis, nes maži testai gali klaidinti. Įprasti svertai apima paketavimą (geresnis pralaidumas, potencialiai blogesnė delsa), kvantavimą (mažesnis ir greitesnis, kartais su nedideliais tikslumo kompromisais), kompiliavimo ir optimizavimo srautus (panašius į ONNX/TensorRT) ir pasikartojančių įvesčių ar įterpimų kaupimą talpykloje. Automatinis mastelio keitimas pagal eilės gylį taip pat gali neleisti uodegos delsai didėti.

Kokio stebėjimo reikia, jei „galinis taškas veikia“?

Vien veikimo laiko nepakanka, nes paslauga gali atrodyti sveika, o prognozavimo kokybė prastėja. Bent jau stebėkite užklausų kiekį, klaidų dažnį ir delsos pasiskirstymą, taip pat prisotinimo signalus, tokius kaip procesoriaus / grafikos procesoriaus / atminties ir eilės laikas. Modelio elgsenai stebėkite įvesties ir išvesties pasiskirstymą kartu su pagrindiniais anomalijų signalais. Pridėkite dreifo patikrinimus, kurie suaktyvina veiksmus, o ne triukšmingus įspėjimus, ir registruokite užklausų ID, modelio versijas ir schemos patvirtinimo rezultatus.

Kaip saugiai įdiegti naujas modelių versijas ir greitai atkurti

Modelius traktuokite kaip pilnus leidimus, naudodami CI/CD srautą, kuris testuoja išankstinį ir vėlesnį apdorojimą, atlieka integracijos patikrinimus pagal „auksinį rinkinį“ ir nustato apkrovos bazę. Diegimo metu „canary“ leidimai palaipsniui didina srautą, o mėlynai žalia versija palieka aktyvią senesnę versiją, kad būtų galima nedelsiant atkurti senesnę versiją. Šešėlinis testavimas padeda įvertinti naują modelį realiame sraute, nepaveikiant vartotojų. Atšaukimas turėtų būti pirmos klasės mechanizmas, o ne antraeilis dalykas.

Dažniausios klaidos mokantis diegti dirbtinio intelekto modelius

Klasikinis atvejis yra mokymo ir aptarnavimo iškraipymas: išankstinis apdorojimas skiriasi mokymo ir gamybos aplinkoje, o našumas nepastebimai blogėja. Kita dažna problema yra schemos patvirtinimo stoka, kai ankstesnis pakeitimas subtiliai sutrikdo įvestis. Komandos taip pat nepakankamai įvertina uodegos delsą ir per daug susitelkia į vidurkius, nepastebi išlaidų (neveikimo grafikos procesoriai greitai kaupiasi) ir praleidžia atšaukimo planavimą. Ypač rizikinga stebėti tik veikimo laiką, nes „veikia, bet ne“ gali būti blogiau nei neveikia.

Nuorodos

  1. „Amazon Web Services“ (AWS) – „Amazon SageMaker“: išvados realiuoju laiku – docs.aws.amazon.com

  2. „Amazon Web Services“ (AWS) – „Amazon SageMaker“ paketinė transformacija – docs.aws.amazon.com

  3. „Amazon Web Services“ (AWS) – „Amazon SageMaker“ modelio monitorius – docs.aws.amazon.com

  4. „Amazon Web Services“ (AWS) – API šliuzo užklausų apribojimas – docs.aws.amazon.com

  5. „Amazon Web Services“ (AWS) – AWS paslapčių tvarkyklė: įvadas – docs.aws.amazon.com

  6. „Amazon Web Services“ (AWS) – AWS Lambda vykdymo aplinkos gyvavimo ciklas – docs.aws.amazon.com

  7. „Google Cloud“ – „Vertex AI“: modelio diegimas galiniame taške – docs.cloud.google.com

  8. „Google Cloud“ – „Vertex AI“ modelio stebėjimo apžvalga – docs.cloud.google.com

  9. „Google Cloud“ – „Vertex AI“: funkcijų iškraipymo ir poslinkio stebėjimas – docs.cloud.google.com

  10. „Google Cloud“ tinklaraštis – Duomenų srautas: tiksliai vieną kartą ir bent kartą transliuojami režimai – cloud.google.com

  11. „Google Cloud“ – debesies duomenų srauto srautinio perdavimo režimai – docs.cloud.google.com

  12. „Google SRE“ knyga – paskirstytųjų sistemų stebėjimas – sre.google

  13. „Google“ tyrimai – „The Tail at Scale“ – research.google

  14. LiteRT (Google AI) – LiteRT apžvalga – ai.google.dev

  15. „LiteRT“ („Google AI“) – „LiteRT“ išvada įrenginyje – ai.google.dev

  16. Docker – Kas yra konteineris? – docs.docker.com

  17. „Docker“ – geriausios „Docker“ kūrimo praktikos – docs.docker.com

  18. Kubernetes – Kubernetes paslaptys – kubernetes.io

  19. „Kubernetes“ – horizontalus pod'o automatinis mastelio keitimas – kubernetes.io

  20. Martin Fowler - Kanarėlių išleidimas - martinfowler.com

  21. Martinas Fowleris – Mėlynai žalias dislokavimas – martinfowler.com

  22. „OpenAPI“ iniciatyva – kas yra „OpenAPI“? – openapis.org

  23. JSON schema – (nuoroda į svetainę) – json-schema.org

  24. Protokolo buferiai – protokolo buferių apžvalga – protobuf.dev

  25. FastAPI – (nuoroda į svetainę) – fastapi.tiangolo.com

  26. NVIDIA – „Triton“: dinaminis paketavimas ir lygiagretus modelių vykdymas – docs.nvidia.com

  27. NVIDIA – Triton: lygiagretus modelio vykdymas – docs.nvidia.com

  28. NVIDIA – „Triton Inference Server“ dokumentai – docs.nvidia.com

  29. „PyTorch“ – „TorchServe“ dokumentai – docs.pytorch.org

  30. „BentoML“ – diegimo paketai – docs.bentoml.com

  31. Ray – Ray Serve dokumentai – docs.ray.io

  32. „TensorFlow“ – kvantizavimas po mokymo („TensorFlow“ modelio optimizavimas) – tensorflow.org

  33. „TensorFlow“ – „TensorFlow“ duomenų patvirtinimas: aptikite mokymo aptarnavimo iškraipymą – tensorflow.org

  34. ONNX - (nuoroda į svetainę) - onnx.ai

  35. ONNX vykdymo laikas – modelio optimizavimas – onnxruntime.ai

  36. NIST (Nacionalinis standartų ir technologijų institutas) – NIST SP 800-122 – csrc.nist.gov

  37. arXiv – Modelių kortelės modelių ataskaitoms – arxiv.org

  38. „Microsoft“ – šešėlinis testavimas – microsoft.github.io

  39. OWASP – OWASP 10 geriausių LLM programų – owasp.org

  40. OWASP GenAI saugumo projektas – OWASP: greitas įskiepijimas – genai.owasp.org

Raskite naujausią dirbtinį intelektą oficialioje dirbtinio intelekto asistentų parduotuvėje

Apie mus

Atgal į tinklaraštį

Papildomi DUK

  • Kaip žinoti, kurį diegimo modelį pasirinkti savo dirbtinio intelekto modeliui?

    Tinkamo diegimo modelio pasirinkimas priklauso nuo jūsų konkrečių poreikių. Atsižvelkite į tokius veiksnius kaip tai, ar jums reikia realaus laiko prognozių, ar priimtinas paketinis apdorojimas, ar jūsų programai reikalingas srautinis duomenų perdavimas. Įvertinę šiuos veiksnius, galėsite pasirinkti tarp realaus laiko, paketinio, srautinio ar periferinio diegimo.

  • Kokius metodus galiu naudoti, kad užtikrinčiau savo dirbtinio intelekto modelio diegimo atkuriamumą?

    Siekiant užtikrinti atkuriamumą, svarbu versuoti visus modelio diegimo aspektus, įskaitant modelio artefaktą, funkcijų logiką, išvadų kodą ir aplinką, kurioje veikia jūsų modelis. Metodiškas versijų žymėjimas padės išvengti problemų, dažnai apibūdinamų kaip „veikiančios mano nešiojamajame kompiuteryje“.

  • Kaip galiu stebėti savo įdiegto dirbtinio intelekto modelio našumą?

    Efektyvus stebėjimas apima įvairių rodiklių, tokių kaip užklausų skaičius, klaidų dažnis, delsos pasiskirstymas ir išteklių panaudojimas, stebėjimą. Taip pat labai svarbu stebėti modelio elgseną analizuojant įvesties ir išvesties pasiskirstymą, užtikrinant, kad bet koks duomenų poslinkis būtų aptiktas anksti.

  • Kokie yra geriausi naujų modelių versijų diegimo būdai?

    Norint saugiai įdiegti naujas modelio versijas, įdiekite CI/CD srautą, apimantį testavimą ir patvirtinimą įvairiuose etapuose. Tokie metodai kaip „canary releases“ arba „Blue-Green“ diegimai leidžia palaipsniui diegti naujas versijas, tuo pačiu turint paprastą atšaukimo planą, jei kiltų problemų.

  • Į kokias dažniausiai pasitaikančias spąstus turėčiau atkreipti dėmesį diegdamas dirbtinio intelekto modelius?

    Būkite atsargūs dėl mokymo ir aptarnavimo iškraipymų, kai atsiranda neatitikimų tarp modelio mokymo ir gamybinės aplinkos. Kitos dažnos klaidos yra schemos patvirtinimo nepaisymas, uodegos delsos stebėjimo nepaisymas ir sąnaudų valdymo planavimo nebuvimas. Visada įsitikinkite, kad turite grįžimo prie ankstesnių versijų strategiją.

  • Kiek svarbus saugumas ir privatumas diegiant dirbtinio intelekto modelį?

    Saugumas ir privatumas yra svarbiausi dirbtinio intelekto modelio diegimo komponentai. Įdiekite autentifikavimo ir autorizacijos valdiklius, greičio ribojimą ir paslapčių valdymą. Jei jūsų modelis tvarko asmens duomenis, užtikrinkite, kad būtų įdiegtos duomenų mažinimo praktikos ir žurnaluose nebūtų neskelbtinos informacijos.

  • Ar savo diegimui galiu naudoti ir paprastą API, ir dedikuotą modelio serverį?

    Taip, daugelis komandų renkasi hibridinį metodą, kai naudoja modelinį serverį išvadoms ir paprastą API autentifikavimui, užklausų formavimui ir dažnio ribojimui. Šis metodas suderina efektyvumą ir naudojimo paprastumą, todėl tinka daugeliui diegimo scenarijų.