ԱԻ (Արհեստական Բանականության) սերվերի օգտագործումը բիզնեսում սկսվում է ոչ թե տեսաքարտի մոդելի ընտրությամբ, այլ կոնկրետ աշխատանքային ծանրաբեռնվածության սահմանմամբ: Եթե ընկերությունը ցանկանում է ավտոմատացնել փաստաթղթերի մշակումը, դասակարգել հաճախորդների հարցումները, իրականացնել տեսողական որակի վերահսկողություն կամ ստեղծել ներքին գիտելիքների բազայի վրա աշխատող լեզվական մոդել, հարցը արագորեն տեղափոխվում է ենթակառուցվածքների հարթություն՝ որտե՞ղ կմշակվեն տվյալները, ի՞նչ արագությամբ պետք է ստանանք պատասխանը և որքանո՞վ են կանխատեսելի ծախսերը:

Հանրային ԱԻ հարթակները կարող են լինել ճիշտ մեկնարկային կետ, սակայն ոչ բոլոր գործընթացների համար: Այն բիզնեսը, որն ունի գաղտնի տվյալներ, մեծ ծավալի հարցումներ կամ մշտական 24/7 ծանրաբեռնվածություն, հաճախ սեփական հաշվարկային ռեսուրսների կարիքն ունի: Նման դեպքում ԱԻ սերվերը պարզապես հզոր համակարգիչ չէ, այլ նախագծված համակարգ՝ հաշվարկային, պահպանման, ցանցային, էներգամատակարարման և կառավարման բաղադրիչներով:

Ի՞նչ խնդիրներ է լուծում ԱԻ սերվերը ընկերությունում

ԱԻ ծանրաբեռնվածությունները հիմնականում բաժանվում են երկու մասի՝ մոդելի ուսուցում (Training) և ինֆերենս (Inference)՝ այսինքն՝ արդեն պատրաստի մոդելի միջոցով պատասխանի կամ կանխատեսման ստեղծում: Ուսուցումը զգալիորեն ավելի ծանր գործընթաց է: Օրինակ, եթե ընկերությունն իր սեփական տվյալների հիման վրա պատրաստում է համակարգչային տեսողության մոդել՝ արտադրական թերությունները հայտնաբերելու համար, նրան անհրաժեշտ կլինի զգալի GPU ռեսուրս, արագ պահոց և տևական հաշվարկային ժամանակ:

Ինֆերենսի պահանջները հաճախ ավելի չափավոր են, սակայն այստեղ վճռորոշ են դառնում պատասխանի ժամանակը և միաժամանակյա օգտատերերի քանակը: Բանկի ներքին աշխատակիցների համար փաստաթղթերում որոնման համակարգը կարող է լավ աշխատել նույնիսկ մեկ կամ երկու պրոֆեսիոնալ GPU-ով: Իսկ բազմամասնաճյուղ ընկերությունում, որտեղ հարյուրավոր աշխատակիցներ միաժամանակ օգտագործում են ներքին օգնականը, կպահանջվեն ավելի շատ GPU-ներ, հիշողություն և ծանրաբեռնվածության բաշխում:

Սեփական սերվերի գլխավոր գործնական առավելությունը տվյալների վերահսկողությունն է: Օգտատերերի պայմանագրերը, ֆինանսական փաստաթղթերը, HR արխիվը կամ տեխնիկական գծագրերը մնում են ընկերության տիրույթում: Սա չի վերացնում անվտանգության պատասխանատվությունը. անհրաժեշտ է իրականացնել հասանելիության վերահսկողություն, մատյանների վարում (logging), տվյալների կոդավորում և պահուստային պատճենում (backup): Այնուամենայնիվ, IT թիմը կարող է հստակորեն սահմանել, թե ով, ինչ և ինչ ժամկետով է մշակում:

ԱԻ սերվերի օգտագործումը բիզնեսում. երբ է արդարացված ներդրումը

Սեփական ենթակառուցվածքը հատկապես արդարացված է, երբ ԱԻ-ի նկատմամբ պահանջները կրկնվող են, իսկ ծավալները՝ կայուն աճող: Ամպային ժամավճարով GPU ռեսուրսը լավ է պիլոտային ծրագրերի, սեզոնային ծանրաբեռնվածության կամ փորձարկումների համար: Բայց եթե մոդելն ամեն օր մշակում է հազարավոր հաշիվ-ապրանքագրեր, զանգերի ձայնագրություններ կամ տեսախցիկից ստացված կադրեր, ամսական օպերատիվ ծախսը կարող է մի քանի տարում հավասարվել կամ գերազանցել տեղական սերվերի արժեքին:

Երկրորդ դեպքը ցածր հապաղման (latency) պահանջն է: Պահեստում տեսախցիկի հոսքից բարկոդի և ծանրոցի ճանաչումը, արտադրամասում անվտանգության վերահսկողությունը կամ դրամարկղային գործառնությունների իրական ժամանակում վերլուծությունը չեն կարող սպասել հեռավոր տվյալների կենտրոնի հետ մշտական հաղորդակցությանը: Տեղական ԱԻ սերվերը նվազեցնում է կախվածությունը ցանցից և շարունակում է աշխատել նույնիսկ ինտերնետի խափանման ժամանակ, եթե տեղական մնացած ենթակառուցվածքները սարքին են:

Երրորդ գործոնը ինտեգրումն է: ԱԻ մոդելը հազվադեպ է աշխատում մեկուսացված: Նրան անհրաժեշտ են ERP, CRM, ֆայլային պահոց, IP տեսախցիկներ, SQL տվյալների բազաներ կամ փաստաթղթաշրջանառության համակարգեր: Երբ տվյալներն արդեն ընկերության ցանցում են, ԱԻ սերվերի տեղադրումը նույն պաշտպանված միջավայրում պարզեցնում է հասանելիության կանոնների, տվյալների հոսքերի և մոնիտորինգի կառավարումը:

Այդուհանդերձ, ոչ բոլոր ընկերություններին է անհրաժեշտ սեփական GPU սերվեր: Եթե օգտագործումը սահմանափակվում է մի քանի աշխատակցի ոչ կանոնավոր տեքստային առաջադրանքներով, սերվերի ձեռքբերումը կարող է լինել ավելորդ կապիտալ ծախս: Ճիշտ պատասխանը կախված է ծանրաբեռնվածության պրոֆիլից, այլ ոչ թե միայն այն փաստից, որ ԱԻ նախագիծը ռազմավարական նշանակություն ունի:

Կոնֆիգուրացիան սկսվում է մոդելից, այլ ոչ թե պրոցեսորից

ԱԻ սերվերի ընտրության ժամանակ GPU-ն կենտրոնական բաղադրիչն է, բայց ոչ միակը: Առաջին հերթին պետք է պարզել, թե ինչ տիպի մոդել է աշխատելու, տվյալների ինչ ծավալ է մշակվելու և քանի օգտատեր է միաժամանակ դիմելու դրան: Խոշոր լեզվական մոդելները (LLMs), պատկերների գեներացումը և համակարգչային տեսողությունը GPU հիշողության նկատմամբ տարբեր պահանջներ ունեն:

GPU-ն և դրա հիշողությունը

Պրոֆեսիոնալ GPU ընտրելիս միայն հաշվարկային հզորությունը բավարար չէ: GPU հիշողությունը սահմանում է, թե ինչ չափի մոդել կամ տվյալների ինչ ծավալ կտեղավորվի մեկ սարքի վրա: Փոքր փաստաթղթային օգնականը կարող է սկսել մեկ GPU-ով, մինչդեռ բազմաօգտատեր համակարգը կամ ավելի մեծ մոդելը կպահանջեն մի քանի GPU-ներ: Նման դեպքում պետք է ստուգվեն սերվերի շասսիի PCIe սլոտները, GPU-ի ֆիզիկական չափերը, սառեցման հնարավորությունը և կապուղու ու էլեկտրասնուցման բլոկի իրական հզորությունը:

Սովորական սպառողական տեսաքարտը երբեմն բավարար է լաբորատոր փորձարկումների համար, սակայն արտադրական միջավայրում պրոֆեսիոնալ լուծումը հաճախ ավելի նախընտրելի է դրայվերների կայունության, մշտական ծանրաբեռնվածության համար նախատեսված դիզայնի և արտադրողի աջակցության շնորհիվ: Ընտրությունը պետք է հիմնվի կոնկրետ ծրագրային փաթեթի վրա՝ CUDA, կոնտեյներացում, վիրտուալացում և օգտագործվող մոդելի պահանջներ:

CPU, RAM և պահոց

CPU-ն մշակում է տվյալների նախապատրաստումը, API հարցումները, կապը տվյալների բազաների հետ և այլ զուգահեռ գործընթացներ: Երկսոկետանի (dual-socket) սերվերը միշտ չէ, որ անհրաժեշտ է, սակայն ավելի շատ միջուկներն ու PCIe գծերը կարևոր են դառնում մի քանի GPU-ների դեպքում: Օպերատիվ հիշողությունը (RAM) պետք է համապատասխանի տվյալների հոսքին. փոքր փորձնական նախագծի համար 64 GB-ը կարող է բավարար լինել, բայց արտադրական փաստաթղթաշրջանառությունը, վեկտորային բազան կամ բազմաթիվ կոնտեյներները հաճախ պահանջում են 128 GB, 256 GB կամ ավելին:

Պահոցում ցանկալի է օգտագործել NVMe SSD-ներ ակտիվ տվյալների, մոդելների և ինդեքսների համար: RAID կոնֆիգուրացիան պաշտպանում է սկավառակի խափանումից, բայց չի փոխարինում պահուստային պատճենմանը (backup): Մեծ արխիվների համար առանձին NAS-ը կամ SAN-ը կարող է ավելի ռացիոնալ լինել, հատկապես երբ տվյալները ԱԻ սերվերի հետ միասին օգտագործում են նաև այլ համակարգեր:

Ցանց, սնուցում և սառեցում

10 GbE ցանցը հաճախ նվազագույն գործնական մակարդակն է, երբ սերվերը սպասարկում է մեծ ֆայլեր, կենտրոնական պահոց կամ մի քանի աշխատանքային կայաններ: Ավելի բարձր թողունակություն է պահանջվում բազմա-GPU միջավայրերում, մասշտաբային տվյալների հոսքերում կամ մի քանի սերվերներից կազմված կլաստերներում:

GPU սերվերը զգալիորեն ավելի շատ էներգիա է սպառում և ջերմություն արտադրում, քան ստանդարտ ֆայլային սերվերը: Գնումից առաջ անհրաժեշտ է հաշվարկել լիարժեք էներգասպառումը ծանրաբեռնվածության պայմաններում, անխափան սնուցման սարքի (UPS) հզորությունը, PDU-ի հնարավորությունները և սերվերային սենյակի սառեցումը: Սխալ ընտրված UPS-ը կարող է աշխատանքը պահպանել ընդամենը մի քանի րոպե, իսկ անբավարար օդորակումը կարող է կրճատել բաղադրիչների կյանքի ցիկլը կամ առաջացնել արտադրողականության ավտոմատ նվազում (thermal throttling):

Պիլոտից մինչև արտադրական համակարգ

Ճիշտ նախագիծը սկսվում է փոքր, չափելի պիլոտային ծրագրով: Օրինակ, լոգիստիկ ընկերությունը կարող է մեկ հոսքի վրա փորձարկել հաշիվ-ապրանքագրերից տվյալների արտահանումը և արդյունքը համեմատել ձեռքով մուտքագրված տվյալների հետ: Պետք է չափվեն ճշգրտությունը, պատասխանի միջին ժամանակը, օրական հարցումների քանակը, էներգասպառումը և կառավարման ժամանակը:

Այնուհետև սահմանվում է հաջողության չափանիշը: Եթե համակարգը կրճատում է օպերատորի աշխատանքային ժամանակը, կարևոր է ոչ միայն մոդելի ճշգրտությունը, այլև բացառիկ դեպքերի կառավարումը: Եթե ԱԻ օգնականը աշխատակիցներին պատասխանում է ներքին կանոնակարգերի հիման վրա, անհրաժեշտ է թարմացված գիտելիքների բազա, պատասխանի աղբյուրի վերահսկողություն և թույլտվությունների սահմանում՝ ըստ դերերի: Տեխնիկապես հզոր մոդելը բիզնեսի համար թույլ լուծում է, եթե դրա պատասխանների ստուգումը և սխալների ուղղումը հնարավոր չէ իրականացնել:

Արտադրական միջավայրում անհրաժեշտ է մոնիտորինգ՝ GPU-ի ծանրաբեռնվածություն և ջերմաստիճան, սկավառակի վիճակ, ցանցի հապաղումներ, API սխալներ և մոդելի պատասխանի ժամանակ: Անհրաժեշտ է նաև թարմացումների պլան: Օպերացիոն համակարգը, հիպերվիզորը, դրայվերները և ԱԻ գրադարանները կապված են միմյանց հետ, ուստի փոփոխությունները նախ պետք է ստուգվեն թեստային միջավայրում:

Գնումներ կատարելիս ինչ պետք է ներառվի տեխնիկական առաջադրանքում

Տեխնիկական առաջադրանքում միայն «ԱԻ սերվեր» գրելը բավարար նկարագրություն չէ: Նշեք թիրախային հավելվածը, օգտատերերի առավելագույն քանակը, տվյալների տեսակը, պատասխանի պահանջվող ժամանակը, GPU մոդելը և քանակը, RAM-ի ծավալը, պահոցի տեսակը, ցանցային պորտերը, էլեկտրասնուցման ռեզերվային բլոկները և երաշխիքային պայմանները: Եթե սերվերը տեղադրվելու է ռեկի (rack) մեջ, նախապես ստուգեք դրա չափսերը (form-factor), խորությունը, քաշը և առկա ռեկի էներգետիկ ու սառեցման ռեսուրսները:

Վրաստանում ընկերությունների համար գործնական խնդիր է նաև սպասարկման հասանելիությունը. ո՞վ կփոխարինի վնասված սկավառակը, ի՞նչ ժամկետում կստացվի պահեստամասը և ինչպե՞ս է կազմակերպված արտադրողի երաշխիքը: Բիզնես-դասի ենթակառուցվածքի արժեքը չի չափվում միայն նախնական հաշիվ-ապրանքագրով: Պետք է հաշվի առնվեն շահագործումը, ընդլայնումը, աջակցությունը և պարապուրդի (downtime) գինը:

ithub.ge-ի նման B2B մատակարարի հետ խորհրդակցելիս օգտակար է նախապես ներկայացնել ոչ միայն ցանկալի բյուջեն, այլև ծանրաբեռնվածության նկարագրությունը: Սա նվազեցնում է ինչպես չափազանց թանկարժեք, այնպես էլ անբավարար կոնֆիգուրացիայի ռիսկը:

Ենթակառուցվածքը սկսեք ծանրաբեռնվածությունից, ոչ թե GPU-ից

ԱԻ նախագծի հաջողությունը հաճախ որոշվում է ոչ թե ամենահզոր տեսաքարտով, այլ ճիշտ դրված խնդրով, հուսալի տվյալներով և ընդլայնման իրատեսական պլանով: Նախ չափեք պահանջարկը մեկ կոնկրետ գործընթացով, հաստատեք բիզնես էֆեկտը, իսկ այնուհետև ընտրեք սերվերը, որն այս ծանրաբեռնվածությունը կայուն կերպով կսպասարկի և ռեսուրս կթողնի նաև հաջորդ փուլի համար:

Backend engineering note: for Node.js server troubleshooting, this NodeWire backend engineering notes is a useful related reference.