Azure és OpenAI: fordulat az enterprise AI piacán?

| Olvasási idő: 5 perc |

Az előző cikkben megnéztük, hogy a Microsoft hogyan mozdul el a saját AI–modellek irányába, és miért csökkenti hosszú távon a függőségét az OpenAI-tól.

Most viszont beszélek a legfontosabb kérdésről: Mit jelent ez nekünk, akik Azure-t és OpenAI-modellt használunk?

Néhány fontos és mindenkiben felmerülő kérdést igyekszem megválaszolni.

Stabil marad az Azure OpenAI?

A rövid válasz: igen.

Az Microsoft és az OpenAI között több évre szóló megállapodás van érvényben. Az Azure OpenAI Service jelenleg működik, frissül, támogatott.

Ha ma:

• chatbot-ot futtatsz Azure-on
• RAG rendszert építesz
• belső tudásbázist generatív AI-val egészítesz ki

akkor nincs ok azonnali aggodalomra.

Ez nem egy hirtelen váltás, sőt az is lehet, hogy hosszú távon sem fog ez Téged érinteni.

Mit csináljunk máshogy az AI-al?

Amit én sok cégnél látok: az LLM-et fix, központi komponensként kezelik. Konkrét modell névre és típusra építik a szolgáltatásokat.

Nagyon ritka, hogy valaki megfelelően, konfigurációs állományban definiálva használja a modelleket. És néhány esetben láttam már olyat is, hogy egy modellre specifikusan van írva a kód. Nincs fallback, nincs B terv.

Ez rövid távon működik, vagy prototípusok esetén kiválóan működik, de hosszú távon nagyon kockázatos.

Ha a Microsoft saját foundation modelleket (alapmodell) vezet be Azure-on belül, akkor valószínűleg még a jelenleginél is több modell közül választhatunk majd. Ez jó hír, hiszen még több lehetőségünk van megtalálni a megoldásunkhoz tökéletesen passzoló modellt.

Ez azonban csak akkor működőképes, ha az architektúránk erre fel van készítve. Ha tanácstalan vagy, hogyan tudod ezt megtenni, az alábbiak segíthetnek:

• Service layer: Az LLM-hívás legyen egy központi backend szolgáltatásból megvalósítva, és ne a UI réteg (frontend) vagy minden mikroszolgáltatás saját, egyedi integrációja. Így ha később modellt kell cserélni, azt nem az egész kódbázisban kell átírni, hanem csak a backend-hez kell hozzányúlni.

• Konfigurálható modellválasztás: A használt AI-modell ne legyen fixen beégetve a kódba, hanem konfigurációból lehessen meghatározni, hogy éppen melyik modellt és annak melyik verzióját használja a rendszer. Ez lehetővé teszi, hogy teszteléskor egy olcsóbb (akár helyi) modellt használjunk, éles környezetben pedig egy erősebbet, vagy hogy gyorsan váltsunk, ha változik az ár vagy a teljesítmény.

• Monitoring token- és költségszinten: Az AI-hívások költsége token alapú, ezért nagy forgalomnál gyorsan elszállhat, ha nincs rálátásunk a használatra. A felhőszolgáltató ad alap költségfigyelést, de enterprise környezetben alkalmazás szinten is érdemes mérni, mely funkció mennyi AI-erőforrást fogyaszt. A token az AI világában ugyanaz, mint korábban a CPU-idő volt: ha nem mérjük, nem tudjuk kontrollálni.

• Fallback modell logika: Érdemes úgy megtervezni a rendszert, hogy ha az elsődlegesen használt modell nem elérhető, túl lassú vagy túl drága, akkor a rendszer automatikusan át tudjon váltani egy alternatív modellre. Ez növeli az üzletmenet-folytonosságot és csökkenti a szolgáltatáskimaradás kockázatát.

Ezek nem felesleges lépések, hanem a hosszútávú stabilitást biztosító praktikák.

Ugyanúgy, ahogy nem kötjük egyetlen availability zone-hoz a rendszert, ne kössük egyetlen modellhez sem.

AI vendor lock-in kérdés

Az Azure használata önmagában nem feltétlenül probléma. Az viszont igen, ha az AI logika teljesen egy adott modell viselkedésére optimalizált, az már kockázat.

A piac abba az irányba megy, hogy a nagy cloud szolgáltatók (kivéve Azure) kínál saját modelleket. A Google (Gemini, Imagen, stb) és az AWS (Amazon Titan) is kínálnak saját modelleket.

Ha te Azure-on maradsz, az teljesen jogos döntés, de az AI-réteg legyen cserélhető.

Egy jól átgondolt architektúrában az alábbiakat követjük:

• Platformfüggetlen: A rendszer ne egy konkrét cloud szolgáltató vagy modell sajátosságaira épüljön, hanem általános LLM-képességre.
• API-absztrakció: Az LLM-hívásokat egy központi backend API kezelje, ne a frontend vagy több különálló komponens közvetlenül a modellt.
• Tudatos modellválasztás: A modell kiválasztása use case, teljesítmény és költség alapján történjen, ne alapértelmezett döntésként.

Copilot jövője

A Microsoft 365 Copilot és a GitHub Copilot jelenleg jelentős részben OpenAI modellekre épülnek, de tudunk már egyéb modelleket is használni, például a Sonnet-et vagy a Opus-t.

Ha a Microsoft saját modelleket integrál, az nem feltétlenül jelent minőségromlást. Én úgy gondolom, inkább előrelépést hozhat, mert nem egy általános modellt kapunk majd, hanem specializált megoldásokat.

A Microsoft célja inkább a:

• költségcsökkentés
• adatkontroll
• stratégiai függetlenség

Felhasználói oldalról nagyobb változás csak akkor várható, ha a modellváltás érezhetően befolyásolja a minőséget.

AI költségtudatosság

Ez az a pont, amit nem lehet megkerülni. Az AI nem olcsó és bármit is hoz a jövő a költség az egyik legfontosabb tényező marad.

Az AI-szolgáltatások token alapú számlázással működnek, vagyis minden elküldött és generált szöveg után fizetünk, és mivel a modellek komoly számítási kapacitást igényelnek, nagy forgalomnál a költség nagyon gyorsan meg tud nőni.

Ha a Microsoft saját modellekkel optimalizálni tudja a költségstruktúrát Azure-on belül, az enterprise ügyfeleknek előny lehet.

Ma még nem tudjuk, hogy az új modellstratégia pontosan milyen árszinten jelenik meg, ezért különösen fontos a használat folyamatos monitorozása és a költséglimitek beállítása. Érdemes a teszt- és éles környezetet szigorúan elkülöníteni, valamint kontroll alatt tartani a fejlesztői környezeteket is, hogy ne maradjanak feleslegesen futó, költséget termelő AI-folyamatok.

Igen, ez AI-nál is ugyanaz a jelenség, mint VM-eknél: ha nem figyelsz, elszáll a költség.

Karrier szempontból mit tanulj?

Ha Azure + OpenAI irányba haladsz, ne csak prompt engineeringet tanulj.

Tanuld meg az alapokat és az általános AI világ rejtelmeit:

• hogyan működik egy RAG architektúra
• miként mérünk modell teljesítményt
• milyen módon optimalizálunk költséget
• miért tervezzünk multi-model környezetet
• stb.

A piac nem egy modell köré szerveződik. Hanem AI megoldások és technikák köré.

A lényeg

Nem kell kétségbe esni, a két cég nem szakít és nem vállnak azonnal ketté útjaik. Inkább járjunk nyitott szemmel és készüljünk fel a változásra.

• Az Azure OpenAI ma stabil
• A stratégia változik
• A piac érik és fejlődik
• Az architektúrának rugalmasnak kell lennie

Ha AI-rendszert építesz Azure-on, most van itt az ideje annak, hogy enterprise szinten gondolkodj: költség, biztonság, rugalmasság.

---

Érdekelnek a hasonló Cloud és AI tartalmak?

• Iratkozz fel az InfoPack hírlevélre.
• Kövess LinkedIn-en.
• Iratkozz fel a YouTube csatornámra, ahol rendszeresen jelentkezem új szakmai videókkal.
• És ne feledkezz el megkeresni TikTok-on sem.