IBM Bob nonāk aiz uzņēmuma ugunsmūra — modelis tomēr jāizvēlas pašam

IBM 30. septembrī izziņoja IBM Bob pašmitinātā izvietojuma vispārēju pieejamību klienta pārvaldītā vidē. Izstrādes palīga servera daļu var izvietot uzņēmuma infrastruktūrā, arī izolētā tīklā, vai savienot ar ārēju modeļa pakalpojumu hibrīdā konfigurācijā. Pirmkoda kontroles robeža tāpēc ir atkarīga no tā, kur darbojas izvēlētais modelis.

Pašmitinātā Bob komplektā nav lietošanai gatava modeļa: klientam pašam jāsagādā atbalstīts modelis vai piekļuve tam. MarkTechPost apskats arī norāda, ka uzņēmumiem paredzētais variants ir pieejams, bet publiska cena nav nosaukta. Latvijas un citu regulētu Eiropas organizāciju iepirkumos tādēļ jāvērtē ne vien Bob izvietojums, bet arī modeļa licence, apstrādes vieta un infrastruktūras izmaksas.

Bob servera daļa darbojas klienta OpenShift klasterī

IBM Bob 1. oktobra laidiena aprakstā norādīts, ka pašmitināšana ir vispārēji pieejama kopš 24. septembra, servera daļa darbojas klienta pārvaldītā Red Hat OpenShift klasterī un lokālai modeļa apstrādei atbalstīti NVIDIA Nemotron 3 Ultra un Poolside Laguna S 2.1. Klasteris var atrasties uzņēmuma telpās vai tā mākoņkontā. Izstrādātāji turpina lietot Bob IDE vai Bob Shell, kas pieslēdzas iekšējam galapunktam. Klasterī darbojas arī identitātes pakalpojums, modeļa pieprasījumu vārteja, audita žurnāli un lietojuma uzskaite.

Uzstādīšanas rīks bobctl vispirms izveido klastera mēroga resursus un operatoru, kam vajadzīgas klastera administratora tiesības. Pēc tam Bob tiek ievietots atsevišķā vārdtelpā, kuru var pārvaldīt ar šīs vārdtelpas tiesībām. Operators automatizē uzstādīšanu un atjauninājumus; klienta platformas komandai joprojām jāuztur OpenShift vide, piekļuve, rezerves kopijas un atjauninājumu ieviešanas kārtība. Izolētā klasterī Bob programmatūras attēli jānogādā privātajā reģistrā.

Trīs konfigurācijas, trīs koda konteksta ceļi

Pašmitināšana nosaka Bob servera daļas atrašanās vietu, savukārt modeļa galapunkts nosaka, kur tiek apstrādāts pieprasījumā iekļautais kods un uzdevuma konteksts. Lokālu modeli klients darbina uz saviem grafiskajiem procesoriem. Hibrīdam ceļam paredzēti ārēji modeļu pakalpojumi; konfigurācijas izvēle jāsaista ar konkrētās darba slodzes datu ierobežojumiem.

• Lokāla konfigurācija. Bob IDE vai Bob Shell nosūta uzdevumu Bob servera daļai klienta OpenShift klasterī, un tā nodod pieprasījumu klienta pārvaldītam modelim. Atbilde atgriežas tajā pašā vidē. Šādi pirmkods, izstrādes konteksts un būvējumu artefakti var palikt organizācijas infrastruktūrā, ja arī pieslēgtie rīki un to galapunkti atbilst šai robežai.
• Izolēta konfigurācija. Datu ceļš līdz lokāli darbinātajam modelim ir līdzīgs, taču klasterim nav izejoša savienojuma ar ārējiem pakalpojumiem. Modelis darbojas uz organizācijas grafiskajiem procesoriem. Programmatūras attēli un atjauninājumi jāpārnes uz privāto reģistru, tāpēc piegādes un izmaiņu apstiprināšanas process kļūst par pastāvīgu ekspluatācijas pienākumu.
• Hibrīda konfigurācija. Bob servera daļa, identitāte, audita žurnāli un lietojuma uzskaite paliek klienta klasterī. Modeļa pieprasījums ar tam pievienoto koda kontekstu tiek nosūtīts ārējam pakalpojumam, izmantojot apstiprinātu privātā savienojuma risinājumu vai organizācijas mākoņkontu. Koda apstrādes vietu tad nosaka arī izvēlētā pakalpojuma reģions, līgums un datu glabāšanas iestatījumi.

Atšķirība starp šiem ceļiem nav tikai tīkla shēmā. Vienā Bob izvietojumā dažādu lietojumu pieprasījumi var būt pakļauti atšķirīgām datu rezidences prasībām. Finanšu sistēmas pirmkoda kontekstam, piemēram, var izvēlēties lokālu modeli, kamēr mazāk ierobežotu darbu apstrādā ārējs pakalpojums; tas ir iespējamas arhitektūras piemērs, nevis ziņa par konkrētu klienta ieviešanu.

Ko pašmitināšana dod datu kontrolei

Klienta pārvaldīts OpenShift klasteris ļauj piemērot Bob servera daļai organizācijas piekļuves noteikumus un uzturēt tās žurnālus savā vidē. Iebūvēto identitātes pakalpojumu, kas balstīts uz Keycloak, var pieslēgt LDAP vai Active Directory, lai lietotāju piekļuve sekotu uzņēmuma katalogam. Tas palīdz sasaistīt izstrādātāju piekļuvi ar jau esošu tiesību pārvaldību, tomēr žurnālu glabāšanas ilgums un piekļuve tiem joprojām jānosaka pašai organizācijai.

Modeļa izvietojums ir atsevišķs kontroles lēmums. Ja pieprasījums dodas uz ārēju modeli, no pārvaldītās vides iziet tas koda un uzdevuma konteksts, ko Bob pievieno pieprasījumam; pārējie klienta klastera komponenti paliek turpat. Arī lokālā režīmā jāņem vērā citi pieslēgtie rīki, izstrādātāju darba vides un rezerves kopijas. Datu rezidenci nosaka viss darba ceļš, nevis tikai Bob servera adrese.

Modeļa izvēle paliek iepirkuma un ekspluatācijas lēmums

Atbalstītā modeļa licence jāvērtē atsevišķi no Bob lietošanas tiesībām. Esošu licenci var izmantot tikai tad, ja modelis ir atbalstīto modeļu sarakstā un licences nosacījumi pieļauj izvēlēto izvietojumu. Lokālam modelim nepieciešama arī atbilstoša grafisko procesoru jauda; tās apjoms ir atkarīgs no modeļa konfigurācijas, konteksta garuma un vienlaikus strādājošo izstrādātāju skaita. Kopējās izmaksās tādēļ jāiekļauj OpenShift, modeļa infrastruktūra, uzturēšana un rezerves kopijas.

Iepirkuma dokumentos četri jautājumi palīdz nošķirt Bob programmatūru no pakalpojumiem, kas apstrādās kodu:

• Kura modeļa versija ir atbalstīta izraudzītajā režīmā, un kurš nodrošina tās licenci un atjauninājumus?
• Kādi pieprasījumu, atbilžu un lietojuma dati nonāk Bob audita žurnālos; kur tie glabājas un cik ilgi?
• Kurš apstiprina Bob, OpenShift un modeļa atjauninājumus, ieskaitot programmatūras attēlu pārvietošanu izolētā tīklā?
• Kurā reģionā ārējais modelis apstrādā koda kontekstu, un kādi līguma noteikumi attiecas uz pakalpojuma žurnāliem?

Pašmitinātais izvietojums tiek piedāvāts ar IBM pārdošanas komandas starpniecību. Atbalstīto modeļu klāsta paplašināšana un vairāku modeļu maršrutēšana ir iecerētas nākotnes iespējas, kurām pieejamības datums nav nosaukts. Kamēr maršrutēšana nav pieejama, modeļa apstrādes vieta jānosaka izvēlētajā konfigurācijā katrai darba slodzei.

Lasiet arī:

• NetApp Console automatizē krātuves — uzņēmums var paturēt savu MI modeli
• Hugging Face modelis var palaist svešu kodu — drošāk ir piesaistīt versiju
• Meta veido uzņēmumu MI platformu, bet vēl neatklāj cenu un pārvaldības rīkus