Կարճ պատասխան. Արհեստական բանականության մոդելի տեղակայումը նշանակում է սպասարկման ձևաչափի ընտրություն (իրական ժամանակում, խմբաքանակով, հոսքային կամ եզրային), այնուհետև ամբողջ ուղին դարձնել վերարտադրելի, դիտարկելի, անվտանգ և շրջելի: Երբ դուք ամեն ինչ տարբերակում եք և համեմատում p95/p99 լատենտությունը արտադրական բեռների վրա, դուք շրջանցում եք «աշխատում եմ իմ նոութբուքի վրա» խափանումների մեծ մասը:
Հիմնական եզրակացություններ՝
Տեղակայման ձևանմուշներ. գործիքներին անցնելուց առաջ ընտրեք իրական ժամանակի, խմբային, հոսքային կամ Edge տարբերակ։
Վերարտադրելիություն. մոդելի, գործառույթների, կոդի և միջավայրի տարբերակում՝ շեղումը կանխելու համար։
Դիտարկելիություն. անընդհատ վերահսկել լատենտության պոչերը, սխալները, հագեցվածությունը և տվյալների կամ ելքային բաշխումները։
Անվտանգ տեղակայումներ. Օգտագործեք դեղին, կապույտ-կանաչ կամ ստվերային թեստավորում՝ ավտոմատ հետադարձման շեմերով։
Անվտանգություն և գաղտնիություն. Կիրառեք հաստատման, արագության սահմանափակումներ և գաղտնիքների կառավարում, և նվազագույնի հասցրեք անձնական տեղեկությունները գրանցամատյաններում։
Հոդվածներ, որոնք կարող են ձեզ դուր գալ կարդալ սրանից հետո
🔗 Ինչպես չափել արհեստական բանականության արդյունավետությունը
Սովորեք չափանիշներ, չափորոշիչներ և իրական աշխարհի ստուգումներ՝ հուսալի արհեստական բանականության արդյունքների համար։.
🔗 Ինչպես ավտոմատացնել առաջադրանքները արհեստական բանականության միջոցով
Կրկնվող աշխատանքը վերածեք աշխատանքային հոսքերի՝ օգտագործելով հուշումներ, գործիքներ և ինտեգրացիաներ։.
🔗 Ինչպես փորձարկել արհեստական բանականության մոդելները
Նախագծեք գնահատումներ, տվյալների հավաքածուներ և գնահատման միավորներ՝ մոդելները օբյեկտիվորեն համեմատելու համար։.
🔗 Ինչպես խոսել արհեստական բանականության հետ
Ավելի լավ հարցեր տվեք, սահմանեք համատեքստը և արագ ստացեք ավելի հստակ պատասխաններ։.
1) Ի՞նչ է իրականում նշանակում «տեղակայում» (և ինչու՞ այն պարզապես API չէ) 🧩
Երբ մարդիկ ասում են «տեղադրել մոդելը», նրանք կարող են նկատի ունենալ հետևյալներից որևէ մեկը
-
Վերջնակետի բացահայտում , որպեսզի հավելվածը կարողանա իրական ժամանակում եզրակացություն անել (Vertex AI: մոդելի տեղակայում վերջնակետում, Amazon SageMaker: իրական ժամանակում եզրակացություն)
-
Գործարկեք խմբային գնահատականը ամեն գիշեր՝ տվյալների բազայում կանխատեսումները թարմացնելու համար (Amazon SageMaker խմբային փոխակերպում)
-
Հոսքային եզրակացություն (իրադարձությունները անընդհատ են գալիս, կանխատեսումները՝ անընդհատ դուրս գալիս) (Cloud Dataflow: ճիշտ մեկ անգամ ընդդեմ առնվազն մեկ անգամ, Cloud Dataflow հոսքային ռեժիմներ)
-
Edge տեղակայում (հեռախոս, զննարկիչ, ներկառուցված սարք կամ «գործարանում այդ փոքրիկ տուփը») (LiteRT սարքի վրա եզրակացություն, LiteRT-ի ակնարկ)
-
Ներքին գործիքների տեղակայում (վերլուծաբանի առջև կանգնած ինտերֆեյս, տետրեր կամ պլանավորված սկրիպտներ)
Այսպիսով, տեղակայումը ավելի քիչ է «մոդելը մատչելի դարձնելու» իմաստով և ավելի շատ նման է հետևյալին
-
փաթեթավորում + սպասարկում + մասշտաբավորում + մոնիթորինգ + կառավարում + հետադարձ կապ (կապույտ-կանաչ տեղակայում)
Դա մի տեսակ ռեստորան բացելու նման է։ Համեղ ուտեստ պատրաստելը կարևոր է, անշուշտ։ Բայց ձեզ դեռ պետք է շենք, անձնակազմ, սառնարանային համակարգ, ճաշացանկեր, մատակարարման շղթա և միջոց՝ ընթրիքի շտապողականությունը կառավարելու համար՝ առանց սառցարանում լաց լինելու։ Ոչ կատարյալ փոխաբերություն է… բայց հասկացաք։ 🍝
2) Ի՞նչն է «Ինչպես տեղակայել արհեստական բանականության մոդելները» տարբերակի լավ տարբերակը դարձնում ✅
«Լավ տեղակայումը» ձանձրալի է լավագույն իմաստով։ Այն կանխատեսելիորեն է գործում ճնշման տակ, իսկ երբ դա այդպես չէ, դուք կարող եք արագ ախտորոշել այն։.
Ահա, թե ինչ տեսք ունի սովորաբար «լավը»
-
Վերարտադրելի կառուցվածքներ
Նույն կոդը + նույն կախվածությունները = նույն վարքագիծը։ Ոչ մի սարսափելի «աշխատում է իմ նոութբուքի վրա» տպավորություն 👻 (Docker: Ի՞նչ է կոնտեյները): -
Ինտերֆեյսի հստակ պայմանագիր։
Մուտքային և ելքային տվյալներ, սխեմաներ և եզրային դեպքեր սահմանված են։ Ժամը 2-ին անակնկալ տեսակներ չկան։ (OpenAPI: Ի՞նչ է OpenAPI-ն, JSON սխեմա) -
Իրականությանը համապատասխանող կատարողականություն։
Լատենտությունը և թողունակությունը չափվում են արտադրական սարքավորումների և իրատեսական բեռնվածության վրա։ -
Ատամների միջոցով մոնիթորինգ՝
չափորոշիչներ, գրանցամատյաններ, հետագծեր և շեղումների ստուգումներ, որոնք ակտիվացնում են գործողությունները (ոչ միայն վահանակներ, որոնք ոչ ոք չի բացում): (SRE գիրք՝ Բաշխված համակարգերի մոնիթորինգ) -
Անվտանգ տեղակայման ռազմավարություն
՝ Canary կամ կապույտ-կանաչ, հեշտ հետադարձում, տարբերակների ստեղծում, որը աղոթք չի պահանջում: (Canary Release, Blue-Green Deployment) -
Արժեքի մասին տեղեկացվածությունը
«Արագ» ռեժիմով հիանալի է, մինչև հաշիվը հեռախոսահամարի տեսք ունենա 📞💸 -
Անվտանգություն և գաղտնիություն՝ հիմնված
գաղտնիքների կառավարման, մուտքի վերահսկման, անձնական տվյալների մշակման, աուդիտի ունակության վրա: (Kubernetes Secrets, NIST SP 800-122)
Եթե կարողանաք դրանք անել հետևողականորեն, ապա արդեն իսկ առաջ եք անցել թիմերի մեծ մասից։ Եկեք անկեղծ լինենք։.
3) Ընտրեք ճիշտ տեղակայման ձևը (մինչև գործիքներ ընտրելը) 🧠
Իրական ժամանակի API եզրակացություն ⚡
Լավագույնը, երբ՝
-
օգտատերերին անհրաժեշտ են անհապաղ արդյունքներ (առաջարկություններ, խարդախության ստուգումներ, զրույց, անհատականացում)
-
որոշումները պետք է կայացվեն հարցման ընթացքում
Զգուշացումներ՝
-
p99 լատենտությունը ավելի կարևոր է, քան միջինը (The Tail at Scale, SRE Book: Monitoring Distributed Systems)
-
ավտոմատ մասշտաբավորումը պահանջում է զգույշ կարգավորում (Kubernetes Horizontal Pod Autoscaling)
-
Սառը մեկնարկները կարող են խորամանկ լինել… ինչպես կատուն, որը սեղանից բաժակ է հրում (AWS Lambda-ի կատարման միջավայրի կյանքի ցիկլ)
Խմբային միավորների հաշվարկ 📦
Լավագույնը, երբ՝
-
կանխատեսումները կարող են հետաձգվել (գիշերային ռիսկի գնահատում, արտահոսքի կանխատեսում, ETL հարստացում) (Amazon SageMaker խմբաքանակի փոխակերպում)
-
Դուք ցանկանում եք ծախսարդյունավետություն և պարզ գործողություններ
Զգուշացումներ՝
-
տվյալների թարմացում և լրացումներ
-
պահպանելով հատկանիշների տրամաբանությունը համապատասխան մարզմանը
Հոսքային եզրակացություն 🌊
Լավագույնը, երբ՝
-
Դուք անընդհատ մշակում եք իրադարձությունները (IoT, clickstreams, մոնիթորինգի համակարգեր)
-
Դուք ցանկանում եք գրեթե իրական ժամանակում որոշումներ՝ առանց խիստ հարցման-պատասխանի
Զգուշացումներ՝
-
ճիշտ մեկ անգամ ընդդեմ առնվազն մեկ անգամ իմաստաբանություն (Cloud Dataflow: ճիշտ մեկ անգամ ընդդեմ առնվազն մեկ անգամ)
-
նահանգային կառավարում, կրկնակի փորձեր, տարօրինակ կրկնօրինակներ
Edge տեղակայում 📱
Լավագույնը, երբ՝
-
ցածր լատենտություն առանց ցանցային կախվածության (LiteRT սարքի վրա հիմնված եզրակացություն)
-
գաղտնիության սահմանափակումներ
-
անցանց միջավայրեր
Զգուշացումներ՝
-
մոդելի չափս, մարտկոց, քվանտացում, սարքավորումների մասնատում (հետուսուցողական քվանտացում (TensorFlow մոդելի օպտիմալացում))
-
թարմացումներն ավելի դժվար են (դուք չեք ուզում 30 տարբերակ ունենալ…)
Սկզբում ընտրեք նախշը, ապա՝ կույտը։ Հակառակ դեպքում, կստիպեք քառակուսի մոդելը վերածել կլոր մոդելի։ Կամ նման մի բան։ 😬
4) Մոդելի փաթեթավորում այնպես, որ այն մնա արտադրության հետ շփումից անփոփոխ 📦🧯
Ահա թե որտեղ է «հեշտ տեղակայումների» մեծ մասը աննկատելիորեն մահանում։.
Ամեն ինչի տարբերակ (այո, ամեն ինչ)
-
Մոդելի արտեֆակտ (կշիռներ, գրաֆիկ, տոկենիզատոր, պիտակների քարտեզներ)
-
Հատկանիշների տրամաբանություն (կերպափոխություններ, նորմալացում, կոդավորիչներ)
-
Եզրակացության կոդ (նախնական/հետմշակում)
-
Միջավայր (Python, CUDA, համակարգային գրադարաններ)
Պարզ մոտեցում, որը գործում է
-
վերաբերվեք մոդելին որպես թողարկման արտեֆակտի
-
պահեք այն տարբերակի պիտակով
-
պահանջում է մոդելի քարտի նման մետատվյալների ֆայլ՝ սխեմա, չափանիշներ, մարզման տվյալների ակնթարթային պատկերի նշումներ, հայտնի սահմանափակումներ (մոդելային քարտեր մոդելի հաշվետվության համար)
Տարաները օգնում են, բայց մի՛ երկրպագեք դրանց 🐳
Կոնտեյներները հիանալի են, քանի որ դրանք՝
-
սառեցնել կախվածությունները (Docker: Ի՞նչ է կոնտեյները):
-
ստանդարտացնել կառուցվածքները
-
պարզեցնել տեղակայման նպատակները
Բայց դուք դեռ պետք է կառավարեք
-
հիմնական պատկերի թարմացումներ
-
GPU դրայվերների համատեղելիություն
-
անվտանգության սկանավորում
-
պատկերի չափս (ոչ ոք չի սիրում 9 ԳԲ «բարև աշխարհ») (Docker-ի կառուցման լավագույն փորձը)
Ստանդարտացրեք ինտերֆեյսը
Վաղուց որոշեք ձեր մուտքային/ելքային ձևաչափը
-
JSON պարզության համար (ավելի դանդաղ, բայց հարմար) (JSON Schema)
-
Protobuf կատարողականի համար (Protocol Buffers-ի ակնարկ)
-
պատկերների/ձայնային տվյալների (գումարած մետատվյալների) ֆայլային բեռներ
Եվ խնդրում եմ ստուգել մուտքագրված տվյալները։ Անվավեր մուտքագրումները «ինչու՞ է այն վերադարձնում անհեթեթություններ» տոմսերի հիմնական պատճառն են։ (OpenAPI: Ի՞նչ է OpenAPI-ն, JSON սխեմա)
5) Սպասարկման տարբերակներ՝ «պարզ API»-ից մինչև լիարժեք մոդելային սերվերներ 🧰
Կան երկու տարածված երթուղիներ
Ընտրանք A: Հավելվածի սերվեր + եզրակացության կոդ (FastAPI ոճի մոտեցում) 🧪
Դուք գրում եք API, որը բեռնում է մոդելը և վերադարձնում կանխատեսումներ: (FastAPI)
Առավելություններ՝
-
հեշտ է հարմարեցնել
-
հիանալի է ավելի պարզ մոդելների կամ վաղ փուլի արտադրանքի համար
-
պարզ վավերացում, երթուղայնացում և ինտեգրում
Թերություններ՝
-
Ձեր սեփական կատարողականի կարգավորումը (փաթեթավորում, թելավորում, գրաֆիկական պրոցեսորի օգտագործում)
-
դու նորովի կհորինես որոշ անիվներ, գուցե սկզբում վատ
Տարբերակ B: Մոդելային սերվեր (TorchServe / Triton ոճի մոտեցում) 🏎️
Մասնագիտացված սերվերներ, որոնք սպասարկում են
-
խմբաքանակավորում (Triton: Դինամիկ խմբաքանակավորում և միաժամանակյա մոդելի կատարում)
-
զուգահեռություն (Տրիտոն. զուգահեռ մոդելի կատարում)
-
բազմաթիվ մոդելներ
-
Գրաֆիկական գրաֆիկական պրոցեսորի (GPU) արդյունավետությունը
-
ստանդարտացված վերջնակետեր (TorchServe փաստաթղթեր, Triton Inference Server փաստաթղթեր)
Առավելություններ՝
-
ավելի լավ կատարողականության մոդելներ՝ անմիջապես տուփից դուրս
-
սպասարկման և բիզնես տրամաբանության միջև ավելի հստակ տարանջատում
Թերություններ՝
-
լրացուցիչ գործառնական բարդություն
-
կարգավորումը կարող է անհարմար թվալ, ինչպես ցնցուղի ջերմաստիճանը կարգավորելը
Հիբրիդային օրինաչափությունը շատ տարածված է
-
մոդելային սերվեր եզրակացության համար (Triton: Դինամիկ խմբաքանակավորում)
-
բարակ API դարպաս՝ վավերացման, հարցման ձևավորման, բիզնես կանոնների և արագության սահմանափակման համար (API դարպասի սահմանափակում)
6) Համեմատական աղյուսակ - տեղակայման հայտնի եղանակներ (անկեղծ տպավորություններով) 📊😌
Ստորև ներկայացված է այն տարբերակների գործնական համառոտ նկարագրությունը, որոնք մարդիկ իրականում օգտագործում են՝ պարզելիս, թե ինչպես տեղակայել արհեստական բանականության մոդելները։
| Գործիք / մոտեցում | Լսարան | Գինը | Ինչու է այն աշխատում |
|---|---|---|---|
| Docker + FastAPI (կամ նմանատիպ) | Փոքր թիմեր, ստարտափներ | Ազատի նման | Պարզ, ճկուն, արագ առաքվող՝ դուք կզգաք մասշտաբավորման յուրաքանչյուր խնդիր (Docker, FastAPI) |
| Կուբեռնետես (ինքդ արա) | Հարթակի թիմեր | Ինֆրակարմիրից կախված | Կառավարում + մասշտաբայնություն… նաև, շատ կոճակներ, որոնցից մի քանիսը անիծված են (Kubernetes HPA) |
| Կառավարվող մեքենայական ուսուցման հարթակ (ամպային մեքենայական ուսուցման ծառայություն) | Թիմեր, որոնք ցանկանում են ավելի քիչ օպերացիաներ | Վճարեք ըստ օգտագործման | Ներկառուցված տեղակայման աշխատանքային հոսքեր, մոնիթորինգի կեռիկներ՝ երբեմն թանկ են միշտ միացված վերջնակետերի համար (Vertex AI տեղակայում, SageMaker իրական ժամանակի եզրակացություն) |
| Առանց սերվերի ֆունկցիաներ (թեթև եզրակացության համար) | Միջոցառումների վրա հիմնված հավելվածներ | Վճարել օգտագործման համար | Հիանալի է սուր երթևեկության համար, բայց սառը մեկնարկը և մոդելի չափսը կարող են փչացնել ձեր օրը 😬 (AWS Lambda սառը մեկնարկներ) |
| NVIDIA Triton Inference Server | Արդյունավետության վրա կենտրոնացած թիմեր | Անվճար ծրագրակազմ, ենթակառուցվածքների արժեք | Գերազանց գրաֆիկական պրոցեսորի օգտագործում, խմբաքանակային մշակում, բազմամոդել - կարգավորումը պահանջում է համբերություն (Triton: Դինամիկ խմբաքանակային մշակում) |
| TorchServe | PyTorch-ով ծանր թիմեր | Անվճար ծրագրակազմ | Լավ լռելյայն մատուցման ձևանմուշներ - կարող է կարգավորման կարիք լինել բարձր մասշտաբի համար (TorchServe փաստաթղթեր) |
| BentoML (փաթեթավորում + մատուցում) | մեքենայական ուսուցման ինժեներներ | Անվճար միջուկ, լրացուցիչները տարբեր են | Հարթ փաթեթավորում, հաճելի մշակողի փորձ - ձեզ դեռ անհրաժեշտ են ենթակառուցվածքային տարբերակներ (BentoML փաթեթավորում տեղակայման համար) |
| Ռեյ Սերվ | Բաշխված համակարգերի մասնագետներ | Ինֆրակարմիրից կախված | Հորիզոնական մասշտաբ, հարմար է խողովակաշարերի համար - «մեծ» է թվում փոքր նախագծերի համար (Ռեյ Սերվի փաստաթղթեր) |
Աղյուսակի նշում. «Անվճար»-ը իրական կյանքի տերմինաբանություն է։ Որովհետև այն երբեք անվճար չէ։ Միշտ ինչ-որ տեղ հաշիվ կա, նույնիսկ եթե դա ձեր քունն է։ 😴
7) Արդյունավետություն և մասշտաբավորում - լատենտություն, թողունակություն և ճշմարտություն 🏁
Արդյունավետության կարգավորումը այն վայրն է, որտեղ տեղակայումը վերածվում է արհեստի։ Նպատակը «արագը» չէ։ Նպատակը բավականաչափ կայուն արագությունն։
Կարևորագույն չափանիշներ
-
p50 լատենտություն. տիպիկ օգտագործողի փորձ
-
p95 / p99 լատենտություն. զայրույթ առաջացնող պոչը (Պոչը մասշտաբով, SRE գիրք. Բաշխված համակարգերի մոնիթորինգ)
-
թողունակություն՝ հարցումներ վայրկյանում (կամ տոկեններ վայրկյանում գեներատիվ մոդելների համար)
-
սխալի մակարդակ՝ ակնհայտ է, բայց երբեմն անտեսվում է
-
Ռեսուրսների օգտագործում՝ CPU, GPU, հիշողություն, VRAM (SRE Գիրք՝ Բաշխված համակարգերի մոնիթորինգ)
Սովորական լծակներ քաշելու համար
-
Խմբաքանակային
խմբ... -
Քվանտացում։
Ավելի ցածր ճշգրտությունը (ինչպես INT8-ը) կարող է արագացնել եզրակացությունը և նվազեցնել հիշողությունը։ Կարող է փոքր-ինչ նվազեցնել ճշգրտությունը։ Երբեմն՝ ոչ, ինչը զարմանալի է։ (Հետմարզումային քվանտացում) -
Կոմպիլյացիա/օպտիմալացում
ONNX արտահանում, գրաֆիկների օպտիմիզատորներ, TensorRT-անման հոսքեր։ Հզոր է, բայց վրիպազերծումը կարող է բարդանալ 🌶️ (ONNX, ONNX Runtime մոդելի օպտիմիզացիաներ) -
Քեշավորում։
Եթե մուտքագրված տվյալները կրկնվեն (կամ կարող եք քեշավորել ներդրված տվյալները), կարող եք շատ բան խնայել։ -
Ավտոմատ
մասշտաբավորում՝ ըստ CPU/GPU-ի ծանրաբեռնվածության, հերթի խորության կամ հարցման հաճախականության։ Հերթի խորությունը թերագնահատված է։ (Kubernetes HPA)
Տարօրինակ, բայց ճշմարիտ խորհուրդ. չափեք արտադրական բեռների չափսերով։ Փոքրիկ փորձարկման բեռները ստում են ձեզ։ Նրանք քաղաքավարի ժպտում են, ապա ավելի ուշ դավաճանում են ձեզ։.
8) Մոնիթորինգ և դիտարկելիություն՝ մի՛ թռչեք կուրորեն 👀📈
Մոդելի մոնիթորինգը միայն աշխատանքային ժամանակի մոնիթորինգ չէ։ Դուք կցանկանայիք իմանալ, թե արդյոք՝
-
ծառայությունը առողջ է
-
մոդելը վարվում է
-
տվյալները տատանվում են
-
կանխատեսումները դառնում են պակաս հավաստի (Vertex AI մոդելի մոնիտորինգի ակնարկ, Amazon SageMaker մոդելի մոնիտորինգ)
Ինչը վերահսկել (նվազագույն կենսունակ հավաքածու)
Ծառայության առողջությունը
-
հարցումների քանակը, սխալների մակարդակը, լատենտության բաշխումները (SRE գիրք. Բաշխված համակարգերի մոնիթորինգ)
-
հագեցվածություն (CPU/GPU/հիշողություն)
-
հերթի տևողությունը և հերթում գտնվելու ժամանակը
Մոդելի վարքագիծ
-
մուտքային հատկանիշների բաշխումներ (հիմնական վիճակագրություն)
-
ներդրման նորմեր (ներդրման մոդելների համար)
-
արդյունքի բաշխումներ (վստահություն, դասերի խառնուրդ, միավորների միջակայքեր)
-
մուտքային տվյալների վրա անոմալիաների հայտնաբերում (աղբի մուտք, աղբի դուրսբերում)
Տվյալների շեղում և հասկացությունների շեղում
-
շեղման մասին ահազանգերը պետք է կիրառելի լինեն (Vertex AI: Monitor feature skew and drift, Amazon SageMaker Model Monitor)
-
խուսափեք ահազանգերի սպամից. այն մարդկանց սովորեցնում է անտեսել ամեն ինչ
Գրանցել, բայց ոչ «ամեն ինչ ընդմիշտ գրանցել» մոտեցումը 🪵
Գրանցամատյան:
-
հարցում ID-ների համար
-
մոդելի տարբերակ
-
սխեմայի վավերացման արդյունքներ (OpenAPI: Ի՞նչ է OpenAPI-ն):
-
նվազագույն կառուցվածքային մետատվյալներ (ոչ թե հում անձնական տվյալներ) (NIST SP 800-122)
Զգույշ եղեք գաղտնիության հետ։ Դուք չեք ցանկանա, որ ձեր գրանցամատյանները դառնան ձեր տվյալների արտահոսքի աղբյուր։ (NIST SP 800-122)
9) CI/CD և տեղակայման ռազմավարություններ՝ մոդելներին վերաբերվեք ինչպես իրական թողարկումների 🧱🚦
Եթե ցանկանում եք հուսալի տեղակայումներ, կառուցեք խողովակաշար։ Նույնիսկ պարզ մեկը։.
Հաստատուն հոսք
-
Նախամշակման և հետմշակման միավորային թեստեր
-
Ինտեգրման թեստ հայտնի մուտք-ելք «ոսկե հավաքածուով»
-
Բեռնվածության թեստի բազային արժեքը (նույնիսկ թեթևը)
-
Կառուցեք արտեֆակտ (կոնտեյներ + մոդել) (Docker-ի կառուցման լավագույն փորձը)
-
Տեղակայել բեմականացմանը
-
Canary-ի թողարկումը երթևեկության փոքր հատվածի համար (Canary Release)
-
Աստիճանաբար բարձրացրեք
-
Ավտոմատ հետադարձում ստեղնային շեմերի դեպքում (կապույտ-կանաչ տեղակայում)
Գլանման նախշեր, որոնք կփրկեն ձեր հոգեկան առողջությունը
-
Canary. թողարկում 1-5% տրաֆիկի համար նախ (Canary Release)
-
Կապույտ-կանաչ. գործարկել նոր տարբերակը հինի հետ միասին, շրջել, երբ պատրաստ լինի (Կապույտ-կանաչ տեղակայում)
-
Ստվերային թեստավորում. իրական տրաֆիկ ուղարկել նոր մոդելին, բայց արդյունքները չօգտագործել (հիանալի է գնահատման համար) (Microsoft: Ստվերային թեստավորում)
Եվ տարբերակեք ձեր վերջնակետերը կամ երթուղին՝ ըստ մոդելի տարբերակի։ Ապագայում դուք շնորհակալ կլինեք։ Ներկայիս նույնպես շնորհակալ կլինեք, բայց աննկատ։.
10) Անվտանգություն, գաղտնիություն և «խնդրում եմ՝ մի՛ արտահոսեք» 🔐🙃
Անվտանգության աշխատակիցները սովորաբար ուշ են հայտնվում, ինչպես անկոչ հյուրը։ Ավելի լավ է շուտ հրավիրել։.
Գործնական ստուգաթերթիկ
-
Նույնականացում և լիազորում (ո՞վ կարող է զանգահարել մոդելին):
-
Արագության սահմանափակում (պաշտպանություն չարաշահումից և պատահական փոթորիկներից) (API Gateway-ի սահմանափակում)
-
Գաղտնիքների կառավարում (կոդում բանալիներ չկան, կարգավորման ֆայլերում նույնպես բանալիներ չկան…) (AWS Secrets Manager, Kubernetes Secrets)
-
Ցանցի կառավարում (մասնավոր ենթացանցեր, ծառայությունից ծառայություն քաղաքականություններ)
-
Աուդիտի գրանցամատյաններ (հատկապես զգայուն կանխատեսումների համար)
-
Տվյալների նվազագույնի հասցնելը (պահել միայն անհրաժեշտը) (NIST SP 800-122)
Եթե մոդելը վերաբերում է անձնական տվյալներին
-
խմբագրման կամ հեշման նույնականացուցիչներ
-
խուսափել հում բեռների գրանցումից (NIST SP 800-122)
-
սահմանել պահպանման կանոնները
-
փաստաթղթային տվյալների հոսք (ձանձրալի, բայց պաշտպանիչ)
Բացի այդ, արագ ներարկումը և ելքային տվյալների չարաշահումը կարող են նշանակություն ունենալ գեներատիվ մոդելների համար: Ավելացնել՝ (OWASP-ի լավագույն 10-յակը LLM կիրառությունների համար, OWASP: Արագ ներարկում)
-
մուտքային ախտահանման կանոններ
-
ելքային ֆիլտրացում, որտեղ դա անհրաժեշտ է
-
պաշտպանիչ ցանկապատեր գործիքներ կանչելու կամ տվյալների բազայի գործողությունների համար
Ոչ մի համակարգ կատարյալ չէ, բայց դուք կարող եք այն դարձնել պակաս փխրուն։.
11) Հաճախակի հանդիպող թակարդներ (այսինքն՝ սովորական թակարդներ) 🪤
Ահա դասականները
-
Նախամշակումը
տարբերվում է ուսուցման և արտադրության միջև։ Հանկարծակի ճշգրտությունը ընկնում է, և ոչ ոք չգիտի, թե ինչու։ (TensorFlow տվյալների վավերացում. ուսուցման և սպասարկման շեղման հայտնաբերում) -
Սխեմայի վավերացում չկա։
Մեկ վերևում կատարված փոփոխությունը ամեն ինչ խաթարում է։ Նաև միշտ չէ, որ բարձրաձայն է հնչում… (JSON սխեմա, OpenAPI: Ի՞նչ է OpenAPI-ն): -
Անտեսելով պոչի լատենտությունը
p99-ում, օգտատերերը ապրում են այնտեղ, երբ զայրացած են։ (Պոչը մասշտաբով) -
արժեքը մոռանալը
անգործուն վիճակում նույնն է, ինչ տան բոլոր լույսերը միացված թողնելը, բայց լամպերը փողից են պատրաստված։ -
Հետ քաշման պլան չկա։
«Մենք պարզապես կվերատեղակայվենք» արտահայտությունը պլան չէ։ Դա հույս է՝ հագած թրենչ-խալաթ։ (Կապույտ-կանաչ տեղակայում) -
Միայն անխափան աշխատանքի մոնիթորինգ։
Ծառայությունը կարող է անխափան լինել, երբ մոդելը սխալ է։ Սա, թերևս, ավելի վատ է։ (Vertex AI: Մոնիտորի առանձնահատկության թեքություն և շեղում, Amazon SageMaker Model Monitor)
Եթե կարդում եք սա և մտածում եք՝ «այո, մենք երկուսն էլ կանենք», ողջույն ակումբ։ Ակումբում կան խորտիկներ և թեթև սթրես։ 🍪
12) Ամփոփում - Ինչպես տեղակայել արհեստական բանականության մոդելներ՝ առանց խելագարվելու 😄✅
Արհեստական բանականությունը (AI) դառնում է իրական արտադրանք տեղակայման ժամանակ։ Այն շքեղ չէ, բայց այստեղ է, որ վստահությունը վաստակվում է։.
Հակիրճ ամփոփում
-
Նախ որոշեք ձեր տեղակայման ձևը (իրական ժամանակում, խմբաքանակային, հոսքային, եզրային) 🧭 (Amazon SageMaker խմբաքանակային փոխակերպում, Cloud Dataflow հոսքային ռեժիմներ, LiteRT սարքի վրա եզրակացություն)
-
Վերարտադրելիության համար փաթեթավորում (տարբերակեք ամեն ինչ, պատասխանատու կերպով կոնտեյներավորեք) 📦 (Docker կոնտեյներներ)
-
Ընտրեք մատուցման ռազմավարություն՝ հիմնվելով կատարողականի կարիքների վրա (պարզ API vs մոդելային սերվեր) 🧰 (FastAPI, Triton: Դինամիկ խմբաքանակավորում)
-
Չափեք p95/p99 լատենտությունը, ոչ միայն միջինները 🏁 (The Tail at Scale)
-
Ավելացրեք ծառայության առողջության և մոդելի վարքագծի մոնիթորինգ 👀 (SRE գիրք. Բաշխված համակարգերի մոնիթորինգ, Vertex AI մոդելի մոնիթորինգ)
-
Անվտանգ գլորեք Canary-ի կամ կապույտ-կանաչի միջոցով և հեշտացրեք հետ գլորումը 🚦 (Canary Release, Blue-Green Deployment)
-
Առաջին օրվանից ծանոթացեք անվտանգությանը և գաղտնիությանը 🔐 (AWS Secrets Manager, NIST SP 800-122)
-
Թող այն ձանձրալի, կանխատեսելի և փաստաթղթավորված լինի՝ ձանձրալիությունը գեղեցիկ է 😌
Եվ այո, արհեստական բանականության մոդելների տեղակայման գործընթացը սկզբում կարող է նման լինել բոցավառվող բոուլինգի գնդակներով ժոնգլիորիայի։ Բայց երբ ձեր աշխատանքային հոսքը կայունանում է, այն դառնում է տարօրինակորեն բավարարող։ Ինչպես վերջապես անկարգ դարակը կազմակերպելը… միայն դարակն է արտադրական երթևեկությունը։
Իրական աշխարհի օրինակ՝ աջակցության տոմսերի տեսակավորման մոդելի տեղակայում
Սցենար
Պատկերացրեք մի հորինված, բայց իրատեսական SaaS ընկերություն՝ 12 աջակցության գործակալներով և շաբաթական մոտ 900 հաճախորդների տոմսերով: Թիմը ցանկանում է ունենալ արհեստական բանականության մոդել, որը կդասակարգի մուտքային տոմսերը ըստ կատեգորիայի, հրատապության և առաջարկվող երթուղիների, նախքան մարդ գործակալի պատասխանը:.
Սա լիովին ավտոմատացված աջակցության բոտ չէ։ Մոդելը պատասխաններ չի ուղարկում հաճախորդներին։ Այն պարզապես օգնում է ավելի արագ ուղղորդել տոմսերը, նշել ռիսկային դեպքերը և գործակալներին տրամադրել ավելի մաքուր մեկնարկային կետ։.
Այստեղ լավագույն տեղակայման սխեման սովորաբար իրական ժամանակի API եզրակացությունն: Յուրաքանչյուր նոր տոմս մտնում է օգնության կենտրոն, արհեստական բանականության ծառայությունը գնահատում է այն մի քանի հարյուր միլիվայրկյանների ընթացքում, և օգնության կենտրոնը պահպանում է կանխատեսված կատեգորիան, առաջնահերթությունը, վստահության միավորը և մոդելի տարբերակը:
Ինչ է պետք օգնականին
Օգտակար մուտքագրումներ՝
տոմսի թեմա
տոմսի մարմին
հաճախորդի պլանի տեսակը
հաշվի տարածաշրջան
ապրանքի ոլորտը, եթե արդեն հայտնի է
նախորդ տոմսերի քանակը վերջին 30 օրվա ընթացքում
Օգտակար կանոններ՝
երբեք չգրանցել հաճախորդների չմշակված հաղորդագրությունները, եթե դրանք պարունակում են անձնական տվյալներ
ուղարկել հաշվարկային վեճերը, իրավական սպառնալիքները, հաշվի ջնջման հարցումները և անվտանգության խնդիրները մարդկային վերանայման
ավտոմատ երթուղի միայն այն դեպքում, երբ վստահության մակարդակը գերազանցում է սահմանված շեմը, օրինակ՝ 0.85-ը
պահպանել մոդելի տարբերակը յուրաքանչյուր կանխատեսման հետ միասին
ձեռքով տեսակավորման փոխարինում, եթե մոդելի ծառայությունը դանդաղ է կամ անհասանելի
Օրինակային հրահանգ
Դուք աջակցության տոմսերի տեսակավորման օգնական եք: Դասակարգեք յուրաքանչյուր տոմս մեկ կատեգորիայի մեջ՝ Հաշիվ, Մուտք, Սխալի մասին հաղորդում, Հնարավորության հարցում, Հաշվի չեղարկում, Անվտանգություն կամ Այլ:.
Վերադարձրեք կատեգորիան, հրատապության մակարդակը, վստահության միավորը, կարճ պատճառը և առաջարկվող աջակցության հերթը։.
Մի՛ հորինեք բացակայող փաստեր: Եթե հայտը պարունակում է իրավական, անվտանգության, վճարման ձախողման, հաշվի ջնջման կամ հաճախորդի զայրացած արտահայտություններ, նշեք այն մարդկային դիտարկման համար:.
Եթե վստահության մակարդակը 0.85-ից ցածր է, վերադարձրեք «Ձեռքով վերանայում» որպես խորհուրդ տրվող հերթ։.
Օրինակի արդյունք
Թույլ ելքային հզորություն
Կատեգորիա՝ Սխալի
առաջնահերթություն՝ Բարձր
Ուղարկել աջակցությանը։
Ավելի լավ ելք
Կատեգորիա՝ Մուտք գործելու
հրատապություն՝ միջին
Հուսալիություն՝ 0.91
Առաջարկվող հերթ՝ Հաշվի մուտք
Պատճառ՝ Հաճախորդը չի կարող մուտք գործել իր հաշիվ գաղտնաբառի վերականգնումից հետո: Անվտանգության սպառնալիք կամ վճարման խնդիր չի նշվում:
Պահանջվում է մարդկային ստուգում՝ Ոչ
Մոդելի տարբերակ՝ ticket-triage-v1.3
Ավելի լավ արդյունքն ավելի հեշտ է աուդիտի ենթարկել, քանի որ այն ներառում է վստահության գնահատական, երթուղայնացման որոշում, պատճառ և մոդելի տարբերակ։.
Ինչպես փորձարկել այն
Մինչև մոդելին ուղիղ երթևեկության տվյալներ ուղարկելը, ստեղծեք իրական, բայց անանուն տոմսերի փոքր «ոսկե հավաքածու»։.
Պարզ թեստային հավաքածուն կարող է ներառել
50 հաշվարկային տոմս
50 մուտքի տոմս
50 սխալի մասին հաղորդում
30 չեղարկման հարցում
20 անվտանգության նկատառումներով զգայուն տոմս
20 շփոթեցնող կամ խառը կատեգորիայի տոմսեր
Այնուհետև ստուգեք՝
Մոդելը նույն կատեգորիան է ընտրո՞ւմ, ինչ մարդ-գնահատողը։
Արդյո՞ք այն ճիշտ է ներկայացնում անվտանգության, իրավական և չեղարկման տոմսերը։
Արդյո՞ք այն վերադարձնում է «Ձեռքով վերանայում», երբ վստահությունը ցածր է։
p95-ի լատենտությունը մնում է թիմի նպատակային սահմանից ցածր՞։
Արդյո՞ք ծառայությունը անվտանգ կերպով խափանվում է, երբ մոդելը հասանելի չէ։
Տարածման համար նախ օգտագործեք ստվերային թեստավորումը: Ուղարկեք իրական տոմսեր նոր մոդելին, բայց դեռ մի օգտագործեք դրա կանխատեսումները: Համեմատեք դրա արդյունքը մարդկային սովորական տեսակավորման հետ մի քանի օրվա ընթացքում: Եթե արդյունքները կայուն են, անցեք 5% կանարիի թողարկման, ապա 25%, ապա 100%:.
Արդյունք
Նկարազարդ արդյունք, որը հիմնված է աշխատանքային հոսքի օգտագործումից առաջ և հետո 100 նմուշային տոմսերի ժամանակագրման վրա
ձեռքով տեսակավորման ժամանակը մեկ տոմսի համար 6 րոպեից կրճատվել է մինչև 1 րոպե 40 վայրկյան մեկ տոմսի համար
Թիմը խնայեց մոտ 7.2 ժամ 100 տոմսերի վրա
մարդ-գնահատողի հետ կատեգորիայի համաձայնությունը կազմել է 87% 220 տոմսանոց ոսկե հավաքածուի համար
Անվտանգության նկատառումներով զգայուն 20 թեստային տոմսերի 100%-ը ուղարկվել է մարդկային դիտարկման։
p95-ի լատենտությունը 480 մվ էր արտադրական բեռների վրա
p99 լատենտությունը 910 մվ էր
հետադարձման ժամանակը 2 րոպեից պակաս էր, քանի որ հին մոդելի վերջնակետը շարունակում էր ակտիվ մնալ Canary-ի թողարկման ժամանակ։
Այս թվերը համընդհանուր չափորոշիչներ չեն։ Դրանք օրինակելի չափումներ են, որոնք թիմը կարող է վերարտադրել՝ ժամանակային տեսակավորման առաջադրանքներ կատարելով, կանխատեսումները համեմատելով պիտակավորված թեստային հավաքածուի հետ և վերջնակետը իրատեսական տոմսերի բեռներով փորձարկելով։.
Ի՞նչը կարող է սխալ ընթանալ
Ամենամեծ ռիսկը մոդելին չափազանց վստահելն է։ «Ցածր հրատապություն» նշումով տոմսը կարող է լուրջ անվտանգության խնդիր պարունակել, հատկապես, եթե հաճախորդը գրում է անհասկանալի։.
Այլ տարածված սխալներ՝
օգտագործելով հղկված թեստային տոմսեր, որոնք չեն համապատասխանում իրական հաճախորդների տոմսերին
գրանցել հաճախորդների ամբողջական հաղորդագրությունները՝ անձնական տվյալներով
մոդելի տարբերակը չի պահվում յուրաքանչյուր կանխատեսման հետ միասին
յուրաքանչյուր տոմսի ավտոմատ ուղղորդում, նույնիսկ երբ վստահությունը ցածր է
մոռացեք ձեռքով պահեստային հերթը
չափելով միջին լատենտությունը, բայց անտեսելով p95-ը և p99-ը
թույլ տալով հին կատեգորիաներին մնալ մոդելում աջակցության թիմի կողմից հերթերի փոփոխությունից հետո
Գործնական ուսուցողական նյութ
Լավ արհեստական բանականության տեղակայումը պարտադիր չէ, որ սկսվի հսկայական ծավալով։ Սկսեք մեկ նեղ աշխատանքային հոսքից, մեկ հստակ ինտերֆեյսից, մեկ ոսկեգույն թեստային հավաքածուից և մեկ անվտանգ հետկանչի ուղուց։ Եթե մոդելը խնայում է ժամանակ՝ առանց թաքցնելու ռիսկը, ապա դուք ունեք տեղակայում, որը արժանի է մասշտաբավորման։.
Հաճախակի տրվող հարցեր
Ի՞նչ է նշանակում արհեստական բանականության մոդելը արտադրության մեջ տեղակայելը
Արհեստական բանականության մոդելի տեղակայումը սովորաբար ներառում է շատ ավելին, քան պարզապես կանխատեսման API-ի բացահայտումը: Գործնականում դա ներառում է մոդելի և դրա կախվածությունների փաթեթավորում, սպասարկման ձևանմուշի ընտրություն (իրական ժամանակում, խմբաքանակով, հոսքային կամ եզրային), հուսալիությամբ մասշտաբավորում, առողջության և շեղման մոնիթորինգ, ինչպես նաև անվտանգ տեղակայման և հետադարձ կապի ուղիների կարգավորում: Հուսալի տեղակայումը մնում է կանխատեսելիորեն կայուն ծանրաբեռնվածության տակ և մնում է ախտորոշելի, երբ ինչ-որ բան սխալ է ընթանում:.
Ինչպես ընտրել իրական ժամանակի, խմբաքանակի, հոսքային կամ եզրային տեղակայման միջև
Ընտրեք տեղակայման ձևը՝ հիմնվելով կանխատեսումների անհրաժեշտության և ձեր գործունեության սահմանափակումների վրա: Իրական ժամանակի API-ները համապատասխանում են ինտերակտիվ փորձառություններին, որտեղ լատենտությունը կարևոր է: Փաթեթային գնահատումը լավագույնս աշխատում է, երբ ուշացումները ընդունելի են, և ծախսերի արդյունավետությունը հանգեցնում է: Հոսքային հեռարձակումը հարմար է անընդհատ իրադարձությունների մշակմանը, հատկապես, երբ առաքման իմաստաբանությունը դժվարանում է: Edge տեղակայումը իդեալական է անցանց աշխատանքի, գաղտնիության կամ ծայրահեղ ցածր լատենտության պահանջների համար, չնայած թարմացումները և սարքավորումների տատանումները դժվարանում են կառավարել:.
Ի՞նչ տարբերակ ընտրել՝ «աշխատում է իմ նոութբուքի վրա» տեղակայման ձախողումներից խուսափելու համար
Տարբերակ՝ ոչ միայն մոդելի կշիռներ։ Սովորաբար ձեզ անհրաժեշտ կլինի տարբերակված մոդելի արտեֆակտ (ներառյալ տոկենիզատորները կամ պիտակների քարտեզները), նախնական մշակում և գործառույթների տրամաբանություն, եզրակացության կոդ և ամբողջական աշխատանքային միջավայր (Python/CUDA/համակարգային գրադարաններ)։ Մոդելը դիտարկեք որպես թողարկման արտեֆակտ՝ պիտակավորված տարբերակներով և թեթև մետատվյալներով, որոնք նկարագրում են սխեմայի սպասումները, գնահատման նշումները և հայտնի սահմանափակումները։.
Տեղակայել պարզ FastAPI ոճի ծառայության կամ նվիրված մոդելային սերվերի միջոցով
Պարզ ծրագրային սերվերը (FastAPI ոճի մոտեցում) լավ է աշխատում վաղ շրջանի արտադրանքի կամ պարզ մոդելների համար, քանի որ դուք պահպանում եք վերահսկողությունը երթուղայնացման, վավերացման և ինտեգրման վրա: Մոդելային սերվերը (TorchServe կամ NVIDIA Triton ոճի) կարող է ապահովել ավելի ուժեղ խմբաքանակային, զուգահեռական և GPU արդյունավետություն անմիջապես: Շատ թիմեր ընտրում են հիբրիդային տարբերակ՝ մոդելային սերվեր եզրակացության համար, գումարած բարակ API շերտ վավերացման, հարցման ձևավորման և արագության սահմանափակումների համար:.
Ինչպես բարելավել լատենտությունը և թողունակությունը՝ առանց ճշգրտությունը խաթարելու
Սկսեք p95/p99 լատենտությունը չափելով արտադրական սարքավորումների վրա՝ իրատեսական բեռնվածությամբ, քանի որ փոքր թեստերը կարող են մոլորեցնել: Հաճախ օգտագործվող լծակներից են խմբաքանակավորումը (ավելի լավ թողունակություն, հնարավոր է՝ ավելի վատ լատենտություն), քվանտացումը (ավելի փոքր և արագ, երբեմն չափավոր ճշգրտության փոխզիջումներով), կոմպիլյացիայի և օպտիմալացման հոսքերը (ONNX/TensorRT-ի նման) և կրկնվող մուտքագրումները կամ ներդրումները քեշավորելը: Հերթի խորության վրա հիմնված ավտոմատ մասշտաբավորումը կարող է նաև կանխել պոչի լատենտության սողալը դեպի վեր:.
Ի՞նչ մոնիթորինգ է անհրաժեշտ «վերջնակետը վերևում է» կետից այն կողմ։
Անխափան աշխատանքի ժամանակը բավարար չէ, քանի որ ծառայությունը կարող է առողջ տեսք ունենալ, մինչդեռ կանխատեսման որակը կարող է քայքայվել: Առնվազն, վերահսկեք հարցումների ծավալը, սխալների հաճախականությունը և լատենտության բաշխումները, գումարած հագեցվածության ազդանշանները, ինչպիսիք են CPU/GPU/հիշողությունը և հերթի ժամանակը: Մոդելի վարքագծի համար հետևեք մուտքային և ելքային բաշխումներին՝ հիմնական անոմալիաների ազդանշանների հետ միասին: Ավելացրեք շեղման ստուգումներ, որոնք ակտիվացնում են գործողություններ՝ աղմկոտ ահազանգերի փոխարեն, և գրանցեք հարցումների ID-ները, մոդելի տարբերակները և սխեմայի վավերացման արդյունքները:.
Ինչպես անվտանգ կերպով թողարկել նոր մոդելների տարբերակները և արագ վերականգնել
Մոդելները վերաբերվեք որպես լիարժեք թողարկումներ՝ CI/CD խողովակաշարով, որը ստուգում է նախնական և հետմշակումը, իրականացնում է ինտեգրման ստուգումներ «ոսկե հավաքածուի» նկատմամբ և սահմանում է բեռնվածության բազային գիծ: Տեղադրումների համար Canary-ն աստիճանաբար թողարկում է ռամպային երթևեկությունը, մինչդեռ կապույտ-կանաչը պահպանում է հին տարբերակը՝ անհապաղ պահեստային ռեժիմի համար: Ստվերային թեստավորումը օգնում է գնահատել նոր մոդելը իրական երթևեկության վրա՝ առանց ազդելու օգտատերերի վրա: Հետադարձումը պետք է լինի առաջնակարգ մեխանիզմ, այլ ոչ թե երկրորդական միտք:.
Արհեստական բանականության մոդելների տեղակայումը սովորելիս ամենատարածված թերությունները
Դասական դեպք է մարզման և արտադրության միջև նախնական մշակումը, և արտադրողականությունը աննկատելիորեն վատանում է: Մեկ այլ հաճախակի խնդիր է սխեմայի վավերացման բացակայությունը, երբ վերևում կատարված փոփոխությունը աննկատելիորեն խզում է մուտքային տվյալները: Թիմերը նաև թերագնահատում են պոչի լատենտությունը և չափազանց կենտրոնանում են միջինների վրա, անտեսում են արժեքը (անգործուն GPU-ները արագ են գումարվում) և բաց են թողնում վերականգնման պլանավորումը: Միայն աշխատանքի ժամանակի մոնիթորինգը հատկապես ռիսկային է, քանի որ «վերևում, բայց սխալ» ռեժիմը կարող է ավելի վատ լինել, քան անկումը:.
Հղումներ
-
Amazon Web Services (AWS) - Amazon SageMaker. Իրական ժամանակի եզրակացություն - docs.aws.amazon.com
-
Amazon Web Services (AWS) - Amazon SageMaker խմբաքանակային փոխակերպում - docs.aws.amazon.com
-
Amazon Web Services (AWS) - Amazon SageMaker մոդելի մոնիտոր - docs.aws.amazon.com
-
Amazon Web Services (AWS) - API Gateway հարցման սահմանափակում - docs.aws.amazon.com
-
Amazon Web Services (AWS) - AWS Secrets Manager: Ներածություն - docs.aws.amazon.com
-
Amazon Web Services (AWS) - AWS Lambda կատարման միջավայրի կյանքի ցիկլ - docs.aws.amazon.com
-
Google Cloud - Vertex AI. Մոդելի տեղակայում վերջնակետում - docs.cloud.google.com
-
Google Cloud - Vertex AI մոդելի մոնիթորինգի ակնարկ - docs.cloud.google.com
-
Google Cloud - Vertex AI. Մոնիտորի գործառույթների թեքում և շեղում - docs.cloud.google.com
-
Google Cloud Blog - Տվյալների հոսք. ուղիղ մեկ անգամ ընդդեմ առնվազն մեկ անգամ հոսքային ռեժիմների - cloud.google.com
-
Google Cloud - Cloud Dataflow հոսքային ռեժիմներ - docs.cloud.google.com
-
Google SRE գիրք - Բաշխված համակարգերի մոնիթորինգ - sre.google
-
Google Research - Պոչը մասշտաբով - research.google
-
LiteRT (Google AI) - LiteRT ակնարկ - ai.google.dev
-
LiteRT (Google AI) - LiteRT սարքի վրա եզրակացություն - ai.google.dev
-
Docker - Ի՞նչ է կոնտեյները: - docs.docker.com
-
Docker - Docker-ի կառուցման լավագույն փորձը - docs.docker.com
-
Kubernetes - Kubernetes Secrets - kubernetes.io
-
Kubernetes - Հորիզոնական Pod ավտոմատ մասշտաբավորում - kubernetes.io
-
Մարտին Ֆաուլեր - Canary Release - martfowler.com
-
Մարտին Ֆաուլեր - Կապույտ-Կանաչ տեղակայում - martinfowler.com
-
OpenAPI նախաձեռնություն - Ի՞նչ է OpenAPI-ն: - openapis.org
-
JSON սխեմա - (կայքում հղումներ են արվել) - json-schema.org
-
Արձանագրության բուֆերներ - Արձանագրության բուֆերների ակնարկ - protobuf.dev
-
FastAPI - (կայքում հղումներ են արվել) - fastapi.tiangolo.com
-
NVIDIA - Triton: Դինամիկ փաթեթավորում և միաժամանակյա մոդելի կատարում - docs.nvidia.com
-
NVIDIA - Triton: Միաժամանակյա մոդելի կատարում - docs.nvidia.com
-
NVIDIA - Triton Inference Server-ի փաստաթղթեր - docs.nvidia.com
-
PyTorch - TorchServe փաստաթղթեր - docs.pytorch.org
-
BentoML - Տեղակայման համար փաթեթավորում - docs.bentoml.com
-
Ռեյ - Ռեյ Սերվի փաստաթղթեր - docs.ray.io
-
TensorFlow - Հետմարզումային քվանտացում (TensorFlow մոդելի օպտիմալացում) - tensorflow.org
-
TensorFlow - TensorFlow տվյալների վավերացում. հայտնաբերեք մարզման-ծառայության շեղումը - tensorflow.org
-
ONNX - (կայքում հղումներ են արվել) - onnx.ai
-
ONNX Runtime - Մոդելների օպտիմիզացումներ - onnxruntime.ai
-
NIST (Ստանդարտների և տեխնոլոգիաների ազգային ինստիտուտ) - NIST SP 800-122 - csrc.nist.gov
-
arXiv - Մոդելային քարտեր մոդելային հաշվետվությունների համար - arxiv.org
-
Microsoft - Ստվերային թեստավորում - microsoft.github.io
-
OWASP - OWASP-ի լավագույն 10-ը LLM դիմումների համար - owasp.org
-
OWASP GenAI անվտանգության նախագիծ - OWASP: Արագ ներարկում - genai.owasp.org