startup

Egy bizonyíték a fogalomra megbocsát egy törékeny adatfolyamnak. Az operatív mesterséges intelligencia nem.

Forrás: venturebeat.com 6 perc olvasás

Megosztás

Egy bizonyíték a fogalomra megbocsát egy törékeny adatfolyamnak. Az operatív mesterséges intelligencia nem.

Összefoglalót olvas. A teljes tartalom itt érhető el: venturebeat.com.

Amikor a vállalatok az AI munkaterheléseket a próbafázisból a termelési szakaszba helyezik át, az adatátvitel gyakran az a tényező, amely meghatározza, hogy a rendszerek megbízhatóan léptethetők-e. A tárolót közvetlenül a feldolgozó egységhez kapcsoló pont-pont architektúrák bemutatási körülmények között működnek, de gyakran összeomlanak a tartós, egyidejű termelési forgalom alatt. Ennek eredménye a leálló következtetési csövek, késlekedő RAG rendszerek, alulhasznált GPU-k és SLA megsértések, amelyek közvetlen üzleti következményekkel járnak. "A szervezetek akkor tudják sikeresen működtetni az AI-t, amikor az infrastruktúrájuk képes kezelni a valóságos hibákat, nem csak az irányított körülményeket" - mondja Hunter Smit, az F5 termékmenedzsmentje. A termelési forgalom felfedi az architekturális gyengeségeket A próbafázisban a leálló átvitelt kellemetlenségnek tekintjük, míg a termelésben ugyanaz a leállás egy olyan leállás, amiért valakinek most már felelősséget kell vállalnia. Az alapul szolgáló architektúra gyakran mindkét esetben azonos: amikor egy kliens közvetlenül a tárolóra van csatlakoztatva, a rendszert egyre törékenyebbé válik a tartós, egyidejű termelési forgalom alatt, mert ez a közvetlen kapcsolat nem reagál, amikor egy csomópont meghibásodik vagy a forgalom megugrik. Ebből kiindulva a próbálkozások és időtúllépések „kibővülnek”, és az egész csővezeték leáll éppen abban a pillanatban, amikor az üzlet a kimenetre támaszkodik. "A pont-pont architektúrák, ahol az S3 kliens közvetlenül az S3 tárolóra csatlakozik, nem ellenállóak" - mondja Paul Pindell, az F5 technológiai szövetségekért felelős fő megoldásarchitektája. "Ha egyetlen tároló csomópont meghibásodik, minden forgalom az adott klaszterhez romlik, és bizonyos esetekben a klaszter teljesen leállhat." A probléma az, hogy az AI munkafolyamatok, beleértve a RAG-alapú következtetéseket és az agentikus AI-t, egyre inkább első osztályú állampolgárként kezelik az S3 tárolót az AI klaszterben. Azonban a tároló és a klaszter közötti hálózati kapcsolatot soha nem úgy tervezték, hogy kezelje a nagy áteresztőképességű, megszakítás nélküli adatátvitelt, amely szükséges a GPU-k optimális működésének fenntartásához. A leálló csövek és alulhasznált GPU-k valódi költsége "A vállalati vezetők általában az AI infrastruktúráját a GPU kihasználtság köré építik, de amitől az AI különböző a hagyományos determinisztikus munkaterhektől, az az, hogy az infrastruktúra folyamatosan befolyásolja az eredményeket minden interakció során" - mondja Tanu Mutreja, az F5 termékmenedzsmentjének vezető igazgatója. "Az AI környezetekben az infrastruktúra már nem csupán a háttér kérdése. Minden tranzakcióval alakítja a felhasználói élményt, a minőséget, az ellenálló képességet és a költségeket." Jelentős üzleti következmények lehetnek. Például, amikor a következtetési csövek leállnak, ez SLA és ügyfélélmény problémássá válik. Amikor a RAG rendszerek késlekednek, a modellek elveszítik a megfelelő, időben elérhető kontextust, ami pontatlan, elavult vagy hallucinált válaszokat eredményez, amelyek mind működési, megfelelőségi és hírnévbeli kockázatokat teremtenek. Ugyanakkor az infrastruktúra problémái, amelyek ezeket a gondokat teremtik, a magas költségeket is növelhetik az alulhasznált vagy tétlen GPU erőforrások miatt. "Ha a GPU-k alulhasználtak, az infrastruktúra hatékonysághiányokat jelez, amelyek a költségeket növelik, miközben korlátozzák a skálázhatóságot és a reakcióképességet" - mondja Mutreja. "A vezetőségi kérdés az, hogy az end-to-end AI infrastruktúra következetesen biztosít-e megbízható, biztonságos, magas színvonalú és szabályozott AI élményeket fenntartható egységgazdasági keretek között." Termelésre kész adatátviteli réteg kiépítése Az F5 az adatátvitelt első osztályú infrastruktúra rétegként kezeli, ahelyett, hogy egyszerűen feltételezné, hogy a hálózati útvonal működni fog. Míg az alkalmazás átadás optimalizálta a kérések áramlását a felhasználók és az alkalmazások között, az adatátvitel a tárolók, hálózatok és számítás, beleértve az AI számítást is, közötti adatáram optimalizálására összpontosít. Az adatátvitel első osztályú rétegként történő kezelése három tulajdonság beépítését jelenti: Az észlelhetőség valós idejű láthatóságot biztosít a késlekedés, áteresztőképesség és áramlás állapotáról. A programozhatóság lehetővé teszi a szabályozási alapú kontrollt az adatmozgások felett, dinamikus irányítással, forgalomoptimalizálással, sebességmenedzsmenttel és automatizált átváltással. A hibafelismerés ellenállóságot épít a degradált hálózatok, tárolókorlátozások és szolgáltatásmegszakítások esetére. Az F5 által a Dell ObjectScale számára kifejlesztett architektúrában az F5 BIG-IP az ObjectScale és az AI számítás között helyezkedik el, mint programozható vezérlőpont a tároló peremén. "Láttunk olyan eseteket, amikor az AI számítási rétegben történt hibás konfiguráció gyakorlatilag DDoS-t indított az S3 tároló infrastruktúráján" - mondja Pindell. "Nem rosszindulatúan, inkább egy 'Ó nem, mit tettem?' pillanatként, de ez mégis leállította a tárolást az egész szervezet számára." A BIG-IP alkalmazásátviteli vezérlő, amely a tárolás és a számítás rétegei között helyezkedik el, megvédi a tárolót QoS, sebességkorlátozások és kapcsolatkorlátozások révén, ezzel fenntartva az ellenállást és az üzemeltethetőséget ilyen terhelés alatt. A SecureIQLab által validált tesztelések megerősítették, hogy ez a védelem nem megy a teljesítmény rovására, ami architekturálisan fontos - mondja Pindell. "A teljesítmény megőrzése, sőt, még javítása is elengedhetetlen" - magyarázza. "Ez az, ami lehetővé teszi, hogy magasabb szintű funkcionalitásokat, ellenállóságot és fokozott biztonságot építsünk be anélkül, hogy a teljesítményt feladnánk." A hibrid és multicloud AI hozzáadott bonyolultsága A hibrid multicloud környezetekben végrehajtott AI telepítések még nagyobb adatátviteli kihívásokkal néznek szembe a részek heterogenitása miatt. Más szóval, az ilyen környezetekben mozgó adatnak meg kell küzdenie az eltérő irányelvekkel, biztonsági ellenőrzésekkel, identitásrendszerekkel, irányítási követelményekkel, töredezett láthatósággal és eltérő hibahatárokkal. A programozható forgalomkezelés és az észlelhetőség együtt kezelik ezt a komplexitást. Az észlelhetőség egységes képet nyújt az alkalmazás, a hálózat és az infrastruktúra állapotáról, különben azt elkülönült környezetekben. A programozható forgalomkezelés ezeket az ismereteket felhasználva intelligensen irányítja, egyensúlyozza és átkapcsolja a forgalmat valós időben. Együtt egy zárt hurkú visszajelző rendszert alkotnak, amely érvényesíti a következetes irányelveket, javítja az ellenállást a hibahatárok között és biztosítja a megbízható, magas teljesítményű AI adatátvitelt függetlenül attól, hogy az alkalmazások, adatok vagy felhasználók hol tartózkodnak. Mik a különbségek a termelési AI és a folyamatos próbák között A vállalatok, amelyek átlépik a folytonos próbafázisokat, egy specifikus mérnöki diszciplínát osztanak meg - mondja Smit. "Ők azok, akik olyan termelési tervezéssel rendelkeznek, ahol a hiba a normális állapot, nem pedig kivétel" - magyarázza. "Feltételezik, hogy a késlekedés, a torlódás és a részleges leállások előfordulnak. Olyan adatpályát építenek, amely elég jól észlelhető és hibaérzékeny, hogy képes legyen felszívni ezeket, explicit mitigaáló intézkedésekkel minden degradált állapot esetén, nem csupán reménykedve abban, hogy a hálózat stabil marad." Azok a szervezetek, amelyek beragadtak a vég nélküli próbákba, még mindig az optimális laboratóriumi eredmény elérésére optimalizálják, és csak akkor találják meg a valóságos szakadékot, amikor egy munkaterhelés élőbe kerül. A probléma nem a modell minőségében vagy a GPU-k számában rejlik, hanem abban, hogy az adatátviteli réteget ugyanazzal a szigorral tervezték-e, mint a feldolgozást. "A csapatoknak meg kell érteniük, hogy a valóságbeli hálózat nagyon másként viselkedik, mint egy optimalizált laboratóriumi hálózat" - mondja Pindell. "Szükségük van egy mitigációs tervre a hibás állapotokkal és teljesítménybottleneckekkel szemben, amelyekkel a termelés során találkozni fognak." A szponzorált cikkek olyan tartalom, amelyet egy cég készít, aki vagy fizet a bejegyzésért, vagy üzleti kapcsolata van a VentureBeat-tel, és mindig egyértelműen meg van jelölve. További információért forduljon a sales@venturebeat.com címhez.

A teljes cikk az eredeti weboldalon

Külső link: venturebeat.com

Kapcsolódó cikkek