Az OpenAI végpontok közötti csevegés referenciaarchitektúrája

A vállalati csevegőalkalmazások beszélgetési interakciókon keresztül segíthetik az alkalmazottakat. Ez különösen igaz a nyelvi modellek, például az OpenAI GPT-modelljei és a Meta LLaMA-modelljeinek folyamatos fejlődése miatt. Ezek a csevegőalkalmazások egy csevegő felhasználói felületből (UI) állnak, az adattárakból, amelyek a felhasználó lekérdezéseihez kapcsolódó tartományspecifikus információkat tartalmaznak, a tartományspecifikus adatokon alapuló nyelvi modellekből, amelyek releváns választ hoznak létre, valamint egy vezénylőből, amely felügyeli az összetevők közötti interakciót.

Ez a cikk az Azure OpenAI szolgáltatás nyelvi modelljeit használó vállalati csevegőalkalmazások létrehozásához és üzembe helyezéséhez nyújt alaparchitektúrát. Az architektúra az Azure Machine Learning parancssori folyamatát alkalmazza végrehajtható folyamatok létrehozásához. Ezek a végrehajtható folyamatok vezénylik a munkafolyamatot a bejövő kérésektől az adattárakig, hogy lekérje a nyelvi modellek földi adatait, valamint más szükséges Python-logikát. A végrehajtható folyamat egy felügyelt online végpont mögötti Machine Learning számítási fürtön van üzembe helyezve.

Az egyéni csevegőfelület (UI) üzemeltetése az alkalmazásszolgáltatások alapszintű webalkalmazás-útmutatóját követi egy biztonságos, zónaredundáns és magas rendelkezésre állású webalkalmazás üzembe helyezéséhez a Azure-alkalmazás Services szolgáltatásban. Ebben az architektúrában az App Service szolgáltatásként (PaaS) kommunikál az Azure-platformmal a privát végpontokon keresztüli virtuális hálózati integráción keresztül. A csevegési felhasználói felület App Service kommunikál a felügyelt online végponttal a privát végponton keresztüli folyamathoz. A Machine Learning-munkaterület nyilvános hozzáférése le van tiltva.

A Machine Learning-munkaterület felügyelt virtuális hálózati elkülönítéssel van konfigurálva, amelyhez minden kimenő kapcsolat jóváhagyása szükséges. Ezzel a konfigurációval létrejön egy felügyelt virtuális hálózat, valamint felügyelt privát végpontok, amelyek lehetővé teszik a magánerőforrásokhoz, például az Azure Storage, az Azure Container Registry és az Azure OpenAI munkahelyhez való kapcsolódást. Ezeket a privát kapcsolatokat a folyamat létrehozása és tesztelése során, valamint a Machine Learning compute-ben üzembe helyezett folyamatok használják.

Architektúra

Töltse le az architektúra Visio-fájlját.

Összetevők

Az architektúra számos összetevője megegyezik az alapszintű Azure OpenAI végpontok közötti csevegési architektúrával. Az alábbi lista csak az alapvető architektúra módosításait emeli ki.

• Az Azure OpenAI az alapszintű és az alapszintű architektúrában is használatos. Az Azure OpenAI egy teljes körűen felügyelt szolgáltatás, amely REST API-hozzáférést biztosít az Azure OpenAI nyelvi modelljeihez, beleértve a GPT-4, a GPT-3.5-Turbo és a beágyazási modellek készletét. Az alaparchitektúra olyan vállalati funkciókat használ, mint a virtuális hálózat és a privát kapcsolat , amelyeket az alaparchitektúra nem valósít meg.
• Az Application Gateway egy 7. rétegbeli (HTTP/S) terheléselosztó és webes forgalmi útválasztó. URL-alapú útválasztással osztja el a bejövő forgalmat a rendelkezésre állási zónák között, és kiosztja a titkosítást az alkalmazás teljesítményének javítása érdekében.
• A webalkalmazási tűzfal (WAF) egy natív felhőszolgáltatás, amely megvédi a webalkalmazásokat az olyan gyakori biztonsági résektől, mint az SQL-injektálás és a helyek közötti szkriptelés. A webalkalmazás tűzfala betekintést nyújt a webalkalmazásba irányuló és onnan érkező forgalomba, lehetővé téve az alkalmazás figyelését és védelmét.
• Az Azure Key Vault egy szolgáltatás, amely biztonságosan tárolja és kezeli a titkos kulcsokat, a titkosítási kulcsokat és a tanúsítványokat. Központosítja a bizalmas információk kezelését.
• Az Azure-beli virtuális hálózat egy szolgáltatás, amely lehetővé teszi izolált és biztonságos magánhálózatok létrehozását az Azure-ban. Az App Service-en futó webalkalmazások esetében egy virtuális hálózati alhálózatra van szükség, amely privát végpontokat használ az erőforrások közötti hálózati biztonságos kommunikációhoz.
• A Private Link lehetővé teszi az ügyfelek számára, hogy nyilvános IP-címzés nélkül közvetlenül a privát virtuális hálózatokról elérhessék az Azure Platform szolgáltatásként (PaaS) nyújtott szolgáltatásait.
• Az Azure DNS a DNS-tartományok üzemeltetési szolgáltatása, amely a Microsoft Azure-infrastruktúrával biztosít névfeloldást. saját DNS zónák lehetővé teszik a szolgáltatás teljes tartománynevének (FQDN) egy privát végpont IP-címére való leképezését.

Megfontolandó szempontok és javaslatok

Megbízhatóság

A megbízhatóság biztosítja, hogy az alkalmazás megfeleljen az ügyfelek felé vállalt kötelezettségeknek. További információkért tekintse meg a Megbízhatósági terv felülvizsgálati ellenőrzőlistát.

Az alapkonfigurációs App Service-webalkalmazás-architektúra a fő regionális szolgáltatások zonális redundanciájával foglalkozik. A rendelkezésre állási zónák fizikailag különálló helyek egy régión belül. Redundanciát biztosítanak egy régión belül a támogató szolgáltatásokhoz, ha két vagy több példány van üzembe helyezve rajtuk. Ha az egyik zóna állásidőt tapasztal, előfordulhat, hogy a régió többi zónája továbbra sem változik. Az architektúra emellett biztosítja az Azure-szolgáltatások elegendő példányát és ezen szolgáltatások konfigurálását a rendelkezésre állási zónák közötti elterjesztéshez. További információkért tekintse át ezt az útmutatót az alapkonfigurációban .

Ez a szakasz az app service-alapkonfigurációban nem szereplő összetevők, például a Machine Learning, az Azure OpenAI és az AI Search szempontjából foglalkozik a megbízhatóságtal.

Zónaredundancia folyamattelepítésekhez

A vállalati üzemelő példányok általában zonális redundanciát igényelnek. Az Azure-ban a zónaszintű redundancia eléréséhez az erőforrásoknak támogatniuk kell a rendelkezésre állási zónákat , és az erőforrás legalább három példányát üzembe kell helyeznie, vagy engedélyeznie kell a platformtámogatást, ha a példányvezérlés nem érhető el. A Machine Learning compute jelenleg nem nyújt támogatást a rendelkezésre állási zónákhoz. Az adatközpontszintű katasztrófa Machine Learning-összetevőkre gyakorolt lehetséges hatásának csökkentése érdekében különböző régiókban kell fürtöket létrehozni, valamint terheléselosztót kell üzembe helyezni a hívások ezen fürtök közötti elosztásához. Állapotellenőrzések használatával biztosíthatja, hogy a hívások csak a megfelelően működő fürtökre legyenek irányítva.

A parancssori folyamatok üzembe helyezése nem korlátozódik a Machine Learning számítási fürtöire. A végrehajtható folyamat tárolóalapú alkalmazásként bármely olyan Azure-szolgáltatásban üzembe helyezhető, amely kompatibilis a tárolókkal. Ilyen lehetőségek például az Azure Kubernetes Service (AKS), az Azure Functions, az Azure Container Apps és az App Service. Mindegyik szolgáltatás támogatja a rendelkezésre állási zónákat. A többrégiós üzembe helyezés további összetettsége nélkül, a gyors folyamatvégrehajtáshoz szükséges zónaredundancia eléréséhez a folyamatokat az egyik ilyen szolgáltatásban kell üzembe helyeznie.

Az alábbi ábra egy alternatív architektúrát mutat be, amelyben a parancssori folyamatok az App Service-ben vannak üzembe helyezve. Az App Service-t ebben az architektúrában használják, mert a számítási feladat már használja a csevegési felhasználói felületen, és nem járna előnyökkel, ha új technológiát vezetne be a számítási feladatba. Az AKS-szel tapasztalattal rendelkező számítási feladatokért felelős csapatoknak érdemes megfontolni az adott környezetben való üzembe helyezést, különösen akkor, ha az AKS-t a számítási feladat más összetevőihez használják.

A diagram az architektúra jelentős területeire van számozott:

1. A folyamatok továbbra is a Machine Learning parancssori folyamatában vannak megszerkesztettek, és a Machine Learning hálózati architektúrája nem változik. A folyamatkészítők továbbra is privát végponton keresztül csatlakoznak a munkaterület szerzői felületéhez, a felügyelt privát végpontok pedig az Azure-szolgáltatásokhoz való csatlakozásra szolgálnak a folyamatok tesztelése során.

2. Ez a pontozott vonal azt jelzi, hogy a tárolóalapú végrehajtható folyamatok le lesznek küldve a Container Registrybe. A diagramon nem láthatók azok a folyamatok, amelyek tárolóba helyezik a folyamatokat, és leküldik a Tárolóregisztrációs adatbázisba.

3. Ugyanahhoz az App Service-csomaghoz egy másik webalkalmazás is telepítve van, amely már üzemelteti a csevegőfelületet. Az új webalkalmazás üzemelteti a tárolóalapú parancssori folyamatot, amely ugyanazon az App Service-csomagon van tárolva, amely már legalább három példányon fut, és a rendelkezésre állási zónák között oszlik el. Ezek az App Service-példányok privát végponton keresztül csatlakoznak a Tárolóregisztrációs adatbázishoz a parancssori folyamat tárolólemezképének betöltésekor.

4. A folyamatvégrehajtáshoz a parancssori folyamattárolónak csatlakoznia kell az összes függő szolgáltatáshoz. Ebben az architektúrában a parancssori folyamat tárolója csatlakozik az AI Searchhez és az Azure OpenAI-hoz. A csak a Machine Learning által felügyelt privát végpont alhálózatán közzétett PaaS-szolgáltatásokat most már a virtuális hálózaton is közzé kell tenni, hogy az App Service-ből létre lehessen hozni a látóvonalat.

Azure OpenAI – megbízhatóság

Az Azure OpenAI jelenleg nem támogatja a rendelkezésre állási zónákat. Az adatközpontszintű katasztrófa lehetséges hatásának az Azure OpenAI-ban történő modelltelepítésekre gyakorolt lehetséges hatásának csökkentése érdekében az Azure OpenAI-t több régióban is üzembe kell helyezni, valamint egy terheléselosztót kell üzembe helyezni a hívások régiók közötti elosztásához. Állapotellenőrzések használatával biztosíthatja, hogy a hívások csak a megfelelően működő fürtökre legyenek irányítva.

Több példány hatékony támogatásához javasoljuk, hogy külsőleg finomhangolja a fájlokat, például egy georedundáns Tárfiókot. Ez a megközelítés minimálisra csökkenti az Egyes régiókHoz tartozó Azure OpenAI-ban tárolt állapotot. A modell üzembe helyezésének üzemeltetéséhez továbbra is finomhangolnia kell az egyes példányok fájljait.

Fontos figyelni a szükséges átviteli sebességet a tokenek percenkénti (TPM) és a kérések percenkénti (RPM) szempontjából. Győződjön meg arról, hogy elegendő TPM van hozzárendelve a kvótához, hogy megfeleljen az üzemelő példányok iránti igényeknek, és megakadályozza az üzembe helyezett modellek hívásainak szabályozását. Az olyan átjárók, mint az Azure API Management, üzembe helyezhetők az OpenAI-szolgáltatás vagy -szolgáltatások előtt, és konfigurálhatók újrapróbálkozáshoz, ha átmeneti hibák és szabályozások állnak fenn. Az API Management kapcsolatcsoport-megszakítóként is használható, hogy megakadályozza, hogy a szolgáltatás túlterhelje a hívásokat, és túllépje a kvótáját.

AI Search – megbízhatóság

A rendelkezésre állási zónákat támogató régióban a Standard tarifacsomaggal vagy magasabb tarifacsomaggal üzembe helyezheti az AI Search szolgáltatást, és három vagy több replikát helyezhet üzembe. A replikák automatikusan egyenletesen oszlanak el a rendelkezésre állási zónák között.

A replikák és partíciók megfelelő számának meghatározásához tekintse meg az alábbi útmutatást:

• AI-keresés figyelése.

• A lekérdezésalapú szabályozás és partíciók elkerülése és az indexalapú szabályozás elkerülése érdekében használjon monitorozási metrikákat, naplókat és teljesítményelemzést a replikák megfelelő számának meghatározásához.

Machine Learning – megbízhatóság

Ha a Machine Learning által felügyelt online végpont mögött található számítási fürtökön helyezi üzembe az üzembe helyezést, vegye figyelembe a skálázással kapcsolatos alábbi útmutatást:

• Az online végpontok automatikus méretezése annak érdekében, hogy elegendő kapacitás álljon rendelkezésre az igények kielégítéséhez. Ha a kihasználtság miatt a használati jelek nem elég időszerűek, fontolja meg a túlterjedést, hogy ne legyen hatással a megbízhatóságra túl kevés példány.

• Fontolja meg a skálázási szabályok létrehozását olyan üzembehelyezési metrikák alapján, mint a CPU-terhelés és a végpontmetrikák, például a kérelmek késése.

• Egy aktív éles üzembe helyezéshez legalább három példányt kell üzembe helyezni.

• Kerülje a használatban lévő példányok üzembe helyezését. Ehelyett helyezzen üzembe egy új üzembe helyezést, és helyezze át a forgalmat, miután az üzembe helyezés készen áll a forgalom fogadására.

Biztonság

A biztonság biztosítékokat nyújt a szándékos támadások és az értékes adatokkal és rendszerekkel való visszaélés ellen. További információkért lásd a Biztonsági terv felülvizsgálati ellenőrzőlistát.

Ez az architektúra kiterjeszti az Azure OpenAI-architektúrával folytatott alapszintű csevegésben implementált biztonsági lábnyomot. Bár az alaparchitektúra rendszer által hozzárendelt felügyelt identitásokat és rendszer által hozzárendelt szerepkör-hozzárendeléseket használ, ez az architektúra felhasználó által hozzárendelt identitásokat használ manuálisan létrehozott szerepkör-hozzárendelésekkel.

Az architektúra egy hálózati biztonsági szegélyt, valamint az alapszintű architektúrában implementált identitáshatárt valósít meg. Hálózati szempontból az egyetlen dolog, amelyet az internetről kell elérni, az az Application Gatewayen keresztüli csevegés felhasználói felülete. Identitás szempontjából a csevegés felhasználói felületének hitelesítenie és engedélyeznie kell a kéréseket. A felügyelt identitások lehetőség szerint az Alkalmazások Azure-szolgáltatásokban való hitelesítésére szolgálnak.

A hálózatkezelési szempontok mellett ez a szakasz a kulcsforgatás és az Azure OpenAI-modellek finomhangolásának biztonsági szempontjait ismerteti.

Identitás- és hozzáférés-kezelés

Felhasználó által hozzárendelt felügyelt identitások használatakor vegye figyelembe az alábbi útmutatást:

• Szükség esetén hozzon létre külön felügyelt identitásokat a következő Machine Learning-erőforrásokhoz:
  • Folyamatok szerkesztéséhez és kezeléséhez használható munkaterületek
  • Számítási példányok a folyamatok teszteléséhez
  • Online végpontok az üzembe helyezett folyamatban, ha a folyamat egy felügyelt online végponton van üzembe helyezve
• Identitás-hozzáférési vezérlők implementálása a csevegési felhasználói felülethez a Microsoft Entra ID használatával

Machine Learning szerepköralapú hozzáférési szerepkörök

A Machine Learning-munkaterülethez való hozzáférés kezeléséhez öt alapértelmezett szerepkör használható: AzureML adattudós, AzureML Számítási operátor, Olvasó, Közreműködő és Tulajdonos. Az alapértelmezett szerepkörök mellett van egy Azure Machine Learning-munkaterület kapcsolati titkos kódolvasója és egy AzureML-beállításjegyzék-felhasználó, amely hozzáférést biztosíthat a munkaterület erőforrásaihoz, például a munkaterület titkos kulcsaihoz és a beállításjegyzékhez.

Mivel az architektúra felhasználó által hozzárendelt felügyelt identitásokat használ, Önnek kell létrehoznia a megfelelő szerepkör-hozzárendeléseket. Ez az architektúra a minimális jogosultság elvét követi, mivel csak az előző identitásokhoz rendel szerepköröket, ahol szükség van rájuk. Vegye figyelembe a következő szerepkör-hozzárendeléseket.

Felügyelt identitás	Hatókör	Szerepkör-hozzárendelések
Munkaterület felügyelt identitása	Erőforráscsoport	Közreműködő
Munkaterület felügyelt identitása	Munkaterület tárfiókja	Storage blobadat-közreműködő
Munkaterület felügyelt identitása	Munkaterület tárfiókja	Tárfájl adatainak kiemelt közreműködője
Munkaterület felügyelt identitása	Munkaterület kulcstartója	Key Vault-rendszergazda
Munkaterület felügyelt identitása	Munkaterület tárolóregisztrációs adatbázisa	AcrPush
Online végpont felügyelt identitása	Azure OpenAI	Cognitive Services OpenAI-felhasználó
Online végpont felügyelt identitása	Munkaterület tárolóregisztrációs adatbázisa	AcrPull
Online végpont felügyelt identitása	Munkaterület tárfiókja	Storage Blob adatolvasó
Online végpont felügyelt identitása	Machine Learning-munkaterület	AzureML-munkaterület kapcsolatkulcs-olvasója
Számítási példány felügyelt identitása	Munkaterület tárolóregisztrációs adatbázisa	AcrPull
Számítási példány felügyelt identitása	Munkaterület tárfiókja	Storage Blob adatolvasó

Hálózat

Az identitásalapú hozzáférés mellett a hálózati biztonság az OpenAI-t használó alapszintű csevegési architektúra középpontjában áll. Magas szinten a hálózati architektúra biztosítja, hogy:

• Csak egyetlen biztonságos belépési pont a csevegés felhasználói felületének forgalmához.
• A hálózati forgalom szűrve van.
• Az átvitt adatok végpontok közötti titkosítása a Transport Layer Security (TLS) használatával történik.
• Az adatkiszivárgás minimalizálható a Private Link használatával az Azure-beli forgalom megtartásához.
• A hálózati erőforrások logikailag vannak csoportosítva és elkülönítve egymástól a hálózat szegmentálásán keresztül.

Hálózati folyamatok

A diagram két folyamatát az alapkonfigurációs App Service-webalkalmazás-architektúra tartalmazza: a végfelhasználótól a csevegés felhasználói felületére (1) irányuló bejövő folyamatot, valamint az App Service-ből az Azure PaaS-szolgáltatásokba irányuló folyamatot (2). Ez a szakasz a Machine Learning online végpontfolyamatára összpontosít. A következő folyamat az alapszintű App Service-webalkalmazásban futó csevegési felhasználói felületről a Machine Learning compute-ben üzembe helyezett folyamatra vonatkozik:

1. Az App Service által üzemeltetett csevegőfelületről érkező hívás egy privát végponton keresztül irányítja át a Machine Learning online végpontjához.
2. Az online végpont átirányítja a hívást az üzembe helyezett folyamatot futtató kiszolgálóra. Az online végpont terheléselosztóként és útválasztóként is működik.
3. Az üzembe helyezett folyamat által igényelt Azure PaaS-szolgáltatások hívásait a rendszer felügyelt privát végpontokon keresztül irányítja át.

Bejövő forgalom a Machine Learningbe

Ebben az architektúrában a Machine Learning-munkaterület nyilvános hozzáférése le van tiltva. A felhasználók privát hozzáféréssel érhetik el a munkaterületet, mert az architektúra a Machine Learning-munkaterület konfigurációjának privát végpontját követi. Valójában a privát végpontok az architektúra egészében az identitásalapú biztonság kiegészítésére szolgálnak. Az App Service által üzemeltetett csevegőfelület például olyan PaaS-szolgáltatásokhoz tud csatlakozni, amelyek nem jelennek meg a nyilvános interneten, beleértve a Machine Learning-végpontokat is.

Privát végpont-hozzáférésre is szükség van a Machine Learning-munkaterülethez való csatlakozáshoz a folyamat létrehozásához.

Az ábra egy parancssori folyamatot ábrázoló szerzőt mutat be, aki az Azure Bastionon keresztül csatlakozik egy virtuálisgép-ugrómezőhöz. Ebből a jump boxból a szerző egy privát végponton keresztül csatlakozhat a Machine Learning-munkaterülethez ugyanabban a hálózatban, mint a jump box. A virtuális hálózathoz való kapcsolódás expressRoute-on vagy VPN-átjárókon és virtuális hálózatok közötti társviszony-létesítésen keresztül is elvégezhető.

Folyamat a Machine Learning által felügyelt virtuális hálózatról az Azure PaaS-szolgáltatásokba

Azt javasoljuk, hogy konfigurálja a Machine Learning-munkaterületet felügyelt virtuális hálózatok elkülönítéséhez, amelyhez minden kimenő kapcsolat jóváhagyása szükséges. Ez az architektúra ezt a javaslatot követi. Kétféle jóváhagyott kimenő szabály létezik. A szükséges kimenő szabályok a megoldás működéséhez szükséges erőforrásokra vonatkoznak, például a Container Registryre és a Storage-ra. A felhasználó által definiált kimenő szabályok olyan egyéni erőforrásokra vonatkoznak, mint például az Azure OpenAI vagy az AI Search, amelyeket a munkafolyamat használni fog. Felhasználó által definiált kimenő szabályokat kell konfigurálnia. A szükséges kimenő szabályok a felügyelt virtuális hálózat létrehozásakor vannak konfigurálva.

A kimenő szabályok lehetnek privát végpontok, szolgáltatáscímkék vagy teljes tartománynevek (teljes tartománynevek) külső nyilvános végpontokhoz. Ebben az architektúrában az Olyan Azure-szolgáltatásokhoz való kapcsolódás, mint a Container Registry, a Storage, az Azure Key Vault, az Azure OpenAI és az AI Search, privát kapcsolaton keresztül csatlakozik. Bár ebben az architektúrában nem, néhány gyakori művelet, amely fQDN kimenő szabály konfigurálását igényelheti, a pipcsomag letöltése, a GitHub-adattár klónozása vagy az alaptároló lemezképének letöltése külső tárházakból.

Virtuális hálózatok szegmentálása és biztonsága

Az architektúra hálózata az alábbi célokra külön alhálózatokkal rendelkezik:

• Alkalmazási átjáró
• App Service-integrációs összetevők
• Privát végpontok
• Azure Bastion
• Jump box virtuális gép
• Betanítás – ebben az architektúrában nem használható modellbetanításhoz
• Pontozás

Minden alhálózat rendelkezik egy hálózati biztonsági csoporttal (NSG), amely az alhálózatok bejövő és kimenő forgalmát is a szükségesre korlátozza. Az alábbi táblázat az alapterv által az egyes alhálózatokhoz hozzáadott NSG-szabályok egyszerűsített nézetét mutatja be. A tábla a szabály nevét és függvényét tartalmazza.

Alhálózat	Bejövő	Kimenő
snet-appGateway	A csevegés felhasználói felületének felhasználói ip-címei (például nyilvános internet), valamint a szolgáltatáshoz szükséges elemek.	Hozzáférés az App Service privát végponthoz, valamint a szolgáltatáshoz szükséges elemekhez.
snet-PrivateEndpoints	Csak a virtuális hálózatról érkező forgalom engedélyezése.	Csak a virtuális hálózat felé történő forgalom engedélyezése.
snet-AppService	Csak a virtuális hálózatról érkező forgalom engedélyezése.	A privát végpontokhoz és az Azure Monitorhoz való hozzáférés engedélyezése.
AzureBastionSubnet	Útmutatás az NSG-hozzáférés és az Azure Bastion használatával kapcsolatban.	Útmutatás az NSG-hozzáférés és az Azure Bastion használatával kapcsolatban.
snet-jumpbox	Engedélyezze a bejövő távoli asztali protokollt (RDP) és az SSH-t az Azure Bastion gazdagép alhálózatából.	A privát végpontokhoz való hozzáférés engedélyezése
snet-agents	Csak a virtuális hálózatról érkező forgalom engedélyezése.	Csak a virtuális hálózat felé történő forgalom engedélyezése.
snet-training	Csak a virtuális hálózatról érkező forgalom engedélyezése.	Csak a virtuális hálózat felé történő forgalom engedélyezése.
snet-scoring	Csak a virtuális hálózatról érkező forgalom engedélyezése.	Csak a virtuális hálózat felé történő forgalom engedélyezése.

Minden más forgalom kifejezetten megtagadva.

A virtuális hálózatok szegmentálásának és biztonságának megvalósításakor vegye figyelembe az alábbi szempontokat.

• Engedélyezze a DDoS Protectiont a virtuális hálózat számára egy olyan alhálózattal, amely egy nyilvános IP-címmel rendelkező application gateway része.

• Ha lehetséges, adjon hozzá egy NSG-t minden alhálózathoz. Használja a legszigorúbb szabályokat, amelyek lehetővé teszik a teljes megoldás működését.

• Az NSG-k csoportosításához használjon alkalmazásbiztonsági csoportokat . Az NSG-k csoportosítása megkönnyíti a szabályok létrehozását az összetett környezetekben.

Kulcsrotálás

Ebben az architektúrában két szolgáltatás használja a kulcsalapú hitelesítést: az Azure OpenAI-t és a Machine Learning által felügyelt online végpontot. Mivel kulcsalapú hitelesítést használ ezekhez a szolgáltatásokhoz, fontos:

• Tárolja a kulcsot egy biztonságos tárolóban, például a Key Vaultban, amely igény szerinti hozzáférést biztosít az arra jogosult ügyfelektől, például a parancssori folyamat tárolóját üzemeltető Azure Web Apptól.

• Kulcsforgatási stratégia implementálása. Ha manuálisan elforgatja a kulcsokat, hozzon létre egy kulcslejárati szabályzatot, és az Azure Policy használatával figyelje meg, hogy a kulcs elforgatva lett-e.

OpenAI-modell finomhangolása

Ha finomhangolja az OpenAI-modelleket a megvalósításban, vegye figyelembe az alábbi útmutatást:

• Ha betanítási adatokat tölt fel a finomhangoláshoz, fontolja meg az ügyfél által felügyelt kulcsok használatát az adatok titkosításához.

• Ha betanítási adatokat tárol egy olyan tárolóban, mint az Azure Blob Storage, fontolja meg egy ügyfél által felügyelt kulcs használatát az adattitkosításhoz, egy felügyelt identitást az adatokhoz való hozzáférés szabályozásához, valamint egy privát végpontot az adatokhoz való csatlakozáshoz.

Szabályozás szabályzaton keresztül

A biztonsághoz való igazodás érdekében fontolja meg az Azure Policy és a hálózati szabályzat használatát, hogy az üzembe helyezés megfeleljen a számítási feladat követelményeinek. A platformautomatizálás szabályzaton keresztüli használata csökkenti a manuális ellenőrzési lépések terheit, és akkor is biztosítja a szabályozást, ha a folyamatokat megkerüli. Vegye figyelembe a következő biztonsági szabályzatokat:

• Tiltsa le a kulcs- vagy egyéb helyi hitelesítési hozzáférést olyan szolgáltatásokban, mint az Azure AI-szolgáltatások és a Key Vault.
• A hálózati hozzáférési szabályok vagy NSG-k speciális konfigurációjának megkövetelése.
• Titkosítást igényel, például az ügyfél által felügyelt kulcsok használatát.

Azure Machine Learning-munkaterület szerepkör-hozzárendelései az Azure Key Vaulthoz

Az Azure Machine Learning-munkaterület felügyelt identitásához a vezérlősík (Közreműködő) és az adatsík (Key Vault-rendszergazda) szerepkör-hozzárendelése is szükséges. Ez azt jelenti, hogy ez az identitás olvasási és írási hozzáféréssel rendelkezik az Azure Key Vaultban tárolt összes titkos kulcshoz, kulcshoz és tanúsítványhoz. Ha a számítási feladat olyan szolgáltatásokkal rendelkezik, mint az Azure Machine Learning, amelyek titkos kulcsokhoz, kulcsokhoz vagy tanúsítványokhoz való hozzáférést igényelnek a Key Vaultban, előfordulhat, hogy a számítási feladat vagy a biztonsági csapat nem biztos abban, hogy az Azure Machine Learning-munkaterület felügyelt identitása hozzáfér ezekhez az összetevőkhöz. Ebben az esetben fontolja meg egy Key Vault-példány üzembe helyezését kifejezetten az Azure Machine Learning-munkaterülethez, valamint a számítási feladatok más részeihez megfelelő egyéb Azure Key Vault-példányokat.

Költségoptimalizálás

A költségoptimalizálás a szükségtelen kiadások csökkentésének és a működési hatékonyság javításának módjairól szól. További információt a Költségoptimalizálás tervezési felülvizsgálati ellenőrzőlistájában talál.

A forgatókönyvre vonatkozó díjszabási példa megtekintéséhez használja az Azure díjkalkulátorát. A példát a használatnak megfelelően kell testre szabnia, mert ez a példa csak az architektúra összetevőit tartalmazza. A forgatókönyv legdrágább összetevői a csevegési felhasználói felület, a parancssori folyamat kiszámítása és az AI Search. Optimalizálja ezeket az erőforrásokat a legtöbb költség megtakarításához.

Compute

A Machine Learning parancssori folyamata több lehetőséget is támogat a végrehajtható folyamatok üzemeltetésére. A lehetőségek közé tartoznak a felügyelt online végpontok a Machine Learningben, az AKS-ben, az App Service-ben és az Azure Kubernetes Service-ben. Mindegyik beállítás saját számlázási modellel rendelkezik. A számítás kiválasztása befolyásolja a megoldás teljes költségét.

Azure OpenAI

Az Azure OpenAI egy fogyasztásalapú szolgáltatás, és mint minden használatalapú szolgáltatás esetében, a kínálati igények szabályozása az elsődleges költségkontroll. Ehhez az Azure OpenAI-ban a következő módszerek kombinációját kell használnia:

• Ügyfelek vezérlése. Az ügyfélkérések a használati modell elsődleges költségforrásai, ezért az ügyfél viselkedésének szabályozása kritikus fontosságú. Minden ügyfélnek a következőnek kell lennie:

  • Hagyja jóvá. Kerülje a szolgáltatás olyan módon történő felfedését, amely támogatja az ingyenes hozzáférést. Korlátozza a hozzáférést mind a hálózati, mind az identitásvezérlők, például kulcsok vagy szerepköralapú hozzáférés-vezérlés (RBAC) használatával.

  • Legyen önkontraszt. Megkövetelheti az ügyfelektől, hogy használják az API-hívások által kínált jogkivonat-korlátozó korlátozásokat, például max_tokens és max_completions.

  • Használjon kötegelést, ahol praktikus. Tekintse át az ügyfeleket, és győződjön meg arról, hogy megfelelően kötegelik a kéréseket.

  • Optimalizálja a parancssori bemenet és a válasz hosszát. A hosszabb kérések több jogkivonatot használnak fel, ami növeli a költségeket, de a megfelelő környezetből hiányzó kérések nem segítik a modelleket a jó eredmények eléréséhez. Tömör utasításokat hozhat létre, amelyek elegendő kontextust biztosítanak ahhoz, hogy a modell hasznos választ adjon. Hasonlóképpen, győződjön meg arról, hogy optimalizálja a válaszhossz korlátját.

• Az Azure OpenAI-játszótér használatának szükség szerint és a gyártás előtti példányokon kell lennie, hogy ezek a tevékenységek ne járjanak termelési költségekkel.

• Válassza ki a megfelelő AI-modellt. A modell kiválasztása nagy szerepet játszik az Azure OpenAI teljes költségében is. Minden modell rendelkezik erősségekkel és gyengeségekkel, és egyedileg árazva vannak. A használati esethez a megfelelő modellt használva győződjön meg arról, hogy nem függ túl egy drágább modellen, ha egy kevésbé költséges modell elfogadható eredményeket ad. Ebben a csevegési referencia-implementációban a GPT 3.5-turbo a GPT-4-hez képest lett kiválasztva, hogy a modell üzembe helyezési költségeinek nagyságrendjét megtakarítani lehessen, miközben elegendő eredményt érjünk el.

• A számlázási töréspontok ismertetése. A finomhangolás óránként történik. A leghatékonyabban az óránként rendelkezésre álló idő nagy részét szeretné felhasználni a finomhangolási eredmények javítására, miközben elkerülheti a következő számlázási időszakba való becsúszást. Hasonlóképpen, a képgenerálásból származó 100 kép költsége megegyezik egy kép költségével. Maximalizálja az ártörési pontokat az előnyére.

• A számlázási modellek ismertetése. Az Azure OpenAI egy kötelezettségvállalásalapú számlázási modellben is elérhető a kiosztott átviteli sebesség ajánlatán keresztül. A kiszámítható használati minták használata után érdemes lehet erre az elővásárlási számlázási modellre váltani, ha az költséghatékonyabb a használati mennyiségnél.

• Kiépítési korlátok beállítása. Győződjön meg arról, hogy az összes kiépítési kvóta csak olyan modellekhez van lefoglalva, amelyek várhatóan a számítási feladat részét képezik modellenként. A már üzembe helyezett modellek átviteli sebessége nem korlátozódik erre a kiépített kvótára, miközben a dinamikus kvóta engedélyezve van. A kvóta nem felel meg közvetlenül a költségeknek, és ez a költség eltérő lehet.

• Használatalapú fizetéses használat figyelése. Ha használatalapú fizetéses díjszabást használ, figyelje a TPM és az RPM használatát . Ezekkel az információkkal tájékoztathatja az architekturális tervezési döntéseket, például hogy milyen modelleket használjon, és optimalizálja a parancssori méreteket.

• A kiosztott átviteli sebesség használatának figyelése. Ha kiosztott átviteli sebességet használ, monitorozza a kiépítés által felügyelt használatot, hogy ne használja fel a megvásárolt kiosztott átviteli sebességet.

• Költségkezelés. Kövesse a költségkezelési funkciók OpenAI-val való használatával kapcsolatos útmutatást a költségek monitorozásához, a költségek kezeléséhez költségvetések beállításához, valamint riasztások létrehozásához, amelyek értesítik az érintetteket a kockázatokról vagy a rendellenességekről.

Működés eredményessége

Az üzemeltetési kiválóság azokat az üzemeltetési folyamatokat fedi le, amelyek üzembe helyeznek egy alkalmazást, és éles környezetben tartják azt. További információ: Az operatív kiválóság tervezési felülvizsgálati ellenőrzőlistája.

Machine Learning – beépített parancssori folyamat futtatókörnyezetei

Az alapvető architektúrához hasonlóan ez az architektúra az Automatikus futtatókörnyezetet használja a működési terhelés minimalizálása érdekében. Az automatikus futtatókörnyezet egy kiszolgáló nélküli számítási lehetőség a Machine Learningben, amely leegyszerűsíti a számításkezelést, és a parancssori folyamat konfigurációjának nagy részét delegálja a futó alkalmazás fájljába és flow.dag.yaml konfigurációjábarequirements.txt. Így ez a választás alacsony karbantartást, rövid élettartamot és alkalmazásvezérelt. A számítási példány futtatókörnyezetének vagy külső számítási környezetének (például ebben az architektúrában) használata a számítási feladat csapat által felügyelt életciklusát igényli, és akkor kell kiválasztani, ha a számítási feladatokra vonatkozó követelmények túllépik az automatikus futtatókörnyezet beállítás konfigurációs képességeit.

Figyelés

Az alapvető architektúrához hasonlóan a diagnosztika minden szolgáltatáshoz konfigurálva van. A Machine Learning és az App Service ki nem minden szolgáltatása az összes napló rögzítésére van konfigurálva. A Machine Learning-diagnosztika úgy van konfigurálva, hogy rögzítse azokat az auditnaplókat, amelyek mind olyan erőforrásnaplók, amelyek rögzítik az adatokkal vagy a szolgáltatás beállításaival folytatott felhasználói interakciókat. Az App Service az AppServiceHTTPLogs, az AppServiceConsoleLogs, az AppServiceAppLogs és az AppServicePlatformLogs rögzítésére van konfigurálva.

Értékelje ki az architektúra erőforrásaira vonatkozó egyéni riasztások készítését, például az Azure Monitor alapszintű riasztásaiban találhatóakat. Példa:

• Tárolóregisztrációs adatbázis riasztásai
• Machine Learning- és Azure OpenAI-riasztások
• Azure Web Apps-riasztások

Nyelvi modellműveletek

Az Azure OpenAI-alapú csevegőmegoldásokhoz, mint ez az architektúra, az Azure DevOps és a GitHub gyors folyamatával kövesse a GenAIOps útmutatását. Emellett figyelembe kell vennie a folyamatos integráció és a folyamatos teljesítés (CI/CD) és a hálózat által védett architektúrák ajánlott eljárásait is. Az alábbi útmutató a folyamatok és azok kapcsolódó infrastruktúrájának implementálásával foglalkozik a GenAIOps-javaslatok alapján. Ez az üzembe helyezési útmutató nem tartalmazza az előtérbeli alkalmazáselemeket, amelyek nem változnak az alapkonfiguráció magas rendelkezésre állású zónaredundáns webalkalmazás-architektúrában leírtaktól.

Fejlesztés

A Machine Learning parancssori folyamata böngészőalapú szerzői élményt nyújt a Machine Learning Studióban vagy egy Visual Studio Code-bővítményen keresztül. Mindkét beállítás fájlként tárolja a folyamatkódot. A Machine Learning Studio használatakor a fájlok egy Storage-fiókban lesznek tárolva. Amikor a Microsoft Visual Studio Code-ban dolgozik, a fájlok a helyi fájlrendszerben lesznek tárolva.

Az együttműködésen alapuló fejlesztés ajánlott eljárásainak betartása érdekében a forrásfájlokat egy online forráskódtárban, például a GitHubon kell tartani. Ez a megközelítés megkönnyíti az összes kódmódosítás nyomon követését, a folyamatkészítők közötti együttműködést, valamint az üzembehelyezési folyamatokkal való integrációt, amelyek tesztelik és ellenőrzik az összes kódmódosítást.

Nagyvállalati fejlesztéshez használja a Microsoft Visual Studio Code bővítményt és a parancssori folyamat SDK/CLI-t a fejlesztéshez. A parancssori folyamat szerzői létrehozhatják és tesztelhetik a folyamataikat a Microsoft Visual Studio Code-ból, és integrálhatják a helyileg tárolt fájlokat az online forrásvezérlő rendszerrel és folyamatokkal. Bár a böngészőalapú élmény kiválóan alkalmas feltáró jellegű fejlesztésre, némi munkával integrálható a forrásvezérlő rendszerrel. A folyamatmappa letölthető a panel folyamatlapjáról Files , kibontva és leküldve a forrásvezérlő rendszerbe.

Értékelés

Tesztelje a csevegőalkalmazásban használt folyamatokat ugyanúgy, mint a többi szoftverösszetevőt. A nyelvi modell kimeneteihez nehéz egyetlen "helyes" választ megadni és érvényesíteni, de a válaszok kiértékeléséhez maga a nyelvi modell is használható. Fontolja meg a nyelvi modellfolyamatok következő automatizált kiértékelését:

• Besorolási pontosság: Kiértékeli, hogy a nyelvi modell "helyes" vagy "helytelen" pontszámot ad-e, és összesíti az eredményeket a pontossági osztályzat létrehozásához.

• Koherencia: Kiértékeli, hogy egy modell előrejelzett válaszában milyen jól vannak megírva a mondatok, és hogyan kapcsolódnak koherensen egymáshoz.

• Fluency: Felméri a modell előrejelzett válaszát a nyelvhelyességi és nyelvi pontosságára vonatkozóan.

• A környezet alapkövetelményei: Kiértékeli, hogy a modell előrejelzett válaszai milyen jól alapulnak az előre konfigurált környezeten. Még ha a nyelvi modell válaszai helyesek is, ha azokat nem lehet érvényesíteni az adott kontextusban, akkor az ilyen válaszok nem lesznek megalapozottak.

• Relevancia: Kiértékeli, hogy a modell előrejelzett válaszai mennyire összhangban vannak a feltett kérdéssel.

Vegye figyelembe az alábbi útmutatást az automatizált értékelések implementálásakor:

• Pontszámokat hozhat létre az értékelésekből, és egy előre meghatározott sikerküszöbön méri őket. Ezekkel a pontszámokkal jelentheti a tesztátvételt/feladatokat a folyamatokban.

• Néhány ilyen teszthez előre konfigurált adatbevitelre van szükség a kérdések, a környezet és az alapigazságok esetében.

• Adjon meg elegendő kérdés-válasz párot, hogy a tesztek eredményei megbízhatóak legyenek, és legalább 100-150 pár ajánlott. Ezeket a kérdés-válasz párokat az "arany adatkészletnek" nevezzük. Az adathalmaz méretétől és tartományától függően nagyobb sokaságra lehet szükség.

• Ne használjon nyelvi modelleket az arany adathalmazban lévő adatok létrehozásához.

Üzembehelyezési folyamat

1. A parancssori mérnök/adatelemző megnyit egy szolgáltatáságat, ahol az adott feladaton vagy szolgáltatáson dolgoznak. A parancssori mérnök/adatelemző a Microsoft Visual Studio Code parancssori folyamatával iterálja a folyamatot, rendszeres időközönként véglegesíti a módosításokat, és leküldi ezeket a módosításokat a szolgáltatáságba.

2. A helyi fejlesztés és kísérletezés befejezése után a parancssori mérnök/adatelemző megnyitja a szolgáltatáságból a főágba irányuló lekéréses kérelmet. A lekéréses kérelem (PR) elindít egy PR-folyamatot. Ez a folyamat gyors minőségi ellenőrzéseket futtat, amelyeknek tartalmazniuk kell a következőket:

   • Kísérletezési folyamatok végrehajtása
   • Konfigurált egységtesztek végrehajtása
   • A kódbázis összeállítása
   • Statikus kódelemzés

3. A folyamat tartalmazhat olyan lépést, amelyhez legalább egy csapattagnak manuálisan jóvá kell hagynia a kérelemkérést az egyesítés előtt. A jóváhagyó nem lehet a véglegesítő, és gyors folyamattudással és a projektkövetelmények ismeretével rendelkezik. Ha a kérelem nincs jóváhagyva, az egyesítés le lesz tiltva. Ha a lekéréses kérelem jóváhagyásra került, vagy nincs jóváhagyási lépés, a szolgáltatáságat a főágba egyesíti a program.

4. A fő egyesítés aktiválja a fejlesztési környezet buildelési és kiadási folyamatát. Ezek konkrétan a következők:

   1. A CI-folyamat az egyesítésből a Főbe aktiválódik. A CI-folyamat végrehajtja a PR-folyamatban végrehajtott összes lépést, és a következő lépéseket:
   • Kísérletezési folyamat
   • Kiértékelés-folyamat
   • A folyamatokat regisztrálja a Machine Learning Registryben a változások észlelésekor
   1. A CD-folyamat a CI-folyamat befejezése után aktiválódik. Ez a folyamat a következő lépéseket hajtja végre:
   • A folyamat üzembe helyezése a Machine Learning-beállításjegyzékből egy Machine Learning online végpontra
   • Az online végpontot célzó integrációs tesztek futtatása
   • Az online végpontot megcélzó füsttesztek futtatása

5. A jóváhagyási folyamat beépül a kiadás-előléptetési folyamatba – jóváhagyás után a 4.a lépésben leírt CI & CD-folyamatok. & 4.b. ismétlődik, és a tesztkörnyezetet célozza meg. Az a. és b. lépések ugyanazok, kivéve, hogy a felhasználói elfogadási tesztek a tesztkörnyezetben végzett füsttesztek után futnak.

6. A 4.a lépésben leírt CI & CD-folyamatok. & 4.b. futtatva előlépteti a kiadást az éles környezetbe a tesztkörnyezet ellenőrzése és jóváhagyása után.

7. Az élő környezetbe való kiadás után a teljesítménymetrikák monitorozásával és az üzembe helyezett nyelvi modellek kiértékelésével kapcsolatos operatív feladatokra kerül sor. Ez magában foglalja, de nem korlátozódik a következőkre:

   • Adateltolódások észlelése
   • Az infrastruktúra megfigyelése
   • Költségek kezelése
   • A modell teljesítményének kommunikálása az érdekelt felekkel

Üzembe helyezési útmutató

A Machine Learning-végpontokkal olyan modelleket helyezhet üzembe, amelyek rugalmasságot biztosítanak az éles környezetben való kiadáskor. A modell legjobb teljesítményének és minőségének biztosítása érdekében vegye figyelembe az alábbi stratégiákat:

• Kék/zöld üzemelő példányok: Ezzel a stratégiával biztonságosan üzembe helyezheti a webszolgáltatás új verzióját a felhasználók vagy kérések egy korlátozott csoportjában, mielőtt az összes forgalmat az új üzembe helyezésre irányítanák.

• A/B tesztelés: Nem csak a kék/zöld környezetek hatékonyak a módosítások biztonságos bevezetéséhez, hanem új viselkedés üzembe helyezésére is használhatók, amelyek lehetővé teszik a felhasználók egy részhalmazának, hogy értékeljék a változás hatását.

• A folyamat parancssori folyamatának részét képező Python-fájlok szöszítését is belefoglalhatja. A linting ellenőrzi a stílussztenderdeknek, hibáknak, a kód összetettségének, a nem használt importálásoknak és a változók elnevezésének megfelelőségét.

• Amikor üzembe helyezi a folyamatot a hálózat által elkülönített Machine Learning-munkaterületen, egy saját üzemeltetésű ügynökkel telepíthet összetevőket az Azure-erőforrásokra.

• A Machine Learning-modell beállításjegyzékét csak akkor kell frissíteni, ha a modell módosul.

• A nyelvi modelleket, a folyamatokat és az ügyfél felhasználói felületét lazán kell összekapcsolni. A folyamatok és az ügyfél felhasználói felületének frissítései a modell befolyásolása nélkül és fordítva is végezhetők el.

• Több folyamat fejlesztésekor és üzembe helyezésekor minden folyamatnak saját életciklussal kell rendelkeznie, ami lazán összekapcsolt élményt tesz lehetővé a kísérletezéstől az éles környezetig tartó folyamatok előmozdítása során.

Infrastruktúra

Az alapkonfigurációjú Azure OpenAI végpontok közötti csevegési összetevők üzembe helyezésekor a kiépített szolgáltatások némelyike alapvető és állandó az architektúrában, míg más összetevők inkább rövid élettartamúak, és létezésük egy üzembe helyezéshez kötődik.

Alapvető összetevők

Az architektúra egyes összetevői olyan életciklussal léteznek, amely túlmutat az egyes parancssori folyamatokon vagy a modellek üzembe helyezésén. Ezeket az erőforrásokat általában egyszer helyezi üzembe a számítási feladatokkal kapcsolatos csapat az alapszintű üzembe helyezés részeként, és a parancssori folyamatok vagy modelltelepítések új, eltávolított vagy frissítésektől eltekintve megmarad.

• Machine Learning-munkaterület
• A Machine Learning-munkaterület tárfiókja
• Container Registry
• AI-keresés
• Azure OpenAI
• Azure Application Insights
• Azure Bastion
• Azure Virtual Machine a jump boxhoz

Rövid élettartamú összetevők

Egyes Azure-erőforrások szorosabban kapcsolódnak az adott parancssori folyamatok tervezéséhez. Ez a megközelítés lehetővé teszi, hogy ezek az erőforrások az összetevő életciklusához legyenek kötve, és rövid élettartamúvá váljanak ebben az architektúrában. Az Azure-erőforrásokra a számítási feladat fejlődése, például a folyamatok hozzáadása vagy eltávolítása, illetve új modellek bevezetésekor van hatással. Ezek az erőforrások újra létrejönnek, és a korábbi példányok el lesznek távolítva. Ezen erőforrások némelyike közvetlen Azure-erőforrás, néhány pedig adatsík-megnyilvánulás a bennük található szolgáltatáson belül.

• A Machine Learning-modell beállításjegyzékében lévő modellt módosítani kell a CD-folyamat részeként.

• A tárolórendszerképet a CD-folyamat részeként frissíteni kell a tárolóregisztrációs adatbázisban.

• Egy Machine Learning-végpont akkor jön létre, amikor a rendszer parancssori folyamatot helyez üzembe, ha az üzembe helyezés nem létező végpontra hivatkozik. A végpontot frissíteni kell a nyilvános hozzáférés kikapcsolásához.

• A Machine Learning-végpont üzembe helyezései frissülnek egy folyamat üzembe helyezésekor vagy törlésekor.

• Új végpont létrehozásakor az ügyfél felhasználói felületéhez tartozó kulcstartót frissíteni kell a végpont kulcsával.

Teljesítmény hatékonysága

A teljesítménybeli hatékonyság lehetővé teszi, hogy a számítási feladatok hatékonyan méretezhetők legyenek a felhasználók igényei szerint. További információt a Teljesítményhatékonyság tervezési felülvizsgálati ellenőrzőlistájában talál.

Ez a szakasz az Azure Search, az Azure OpenAI és a Machine Learning szempontjából ismerteti a teljesítményhatékonyságot.

Azure Search – teljesítményhatékonyság

Kövesse az útmutatást az AI Search teljesítményének elemzéséhez.

Azure OpenAI – teljesítményhatékonyság

• Annak meghatározása, hogy az alkalmazás kiosztott átviteli sebességet vagy megosztott üzemeltetési vagy használati modellt igényel-e. A kiosztott átviteli sebesség fenntartott feldolgozási kapacitást biztosít az OpenAI-modellek üzembe helyezéséhez, amely kiszámítható teljesítményt és átviteli sebességet biztosít a modellek számára. Ez a számlázási modell eltér a megosztott üzemeltetési vagy fogyasztási modelltől. A fogyasztási modell a legjobb erőfeszítés, és zajos szomszéd vagy más stresszorok lehetnek kitéve a platformon.

• A kiosztott átviteli sebesség kiépítés által felügyelt kihasználtságának figyelése.

Machine Learning – teljesítményhatékonyság

Ha a Machine Learning online végpontjaira telepíti az üzembe helyezést:

• Kövesse az online végpontok automatikus méretezésével kapcsolatos útmutatást. Ezt úgy teheti meg, hogy a túlzott túlterjedés nélkül is szorosan igazodjon a kereslethez, különösen az alacsony kihasználtságú időszakokban.

• Válassza ki a megfelelő virtuálisgép-termékváltozatot az online végponthoz a teljesítménycélok teljesítéséhez. Az optimális konfiguráció megtalálásához tesztelje az alacsonyabb példányszám és a nagyobb termékváltozatok teljesítményét a nagyobb példányszám és a kisebb termékváltozatok helyett.

A forgatókönyv üzembe helyezése

A referencia-implementáció üzembe helyezéséhez és futtatásához kövesse az OpenAI végpontok közötti referencia-implementáció lépéseit.

Közreműködők

Ezt a cikket a Microsoft tartja karban. Eredetileg a következő közreműködők írták.

• Rob Bagby | Minták és eljárások – Microsoft
• Freddy Ayala | Felhőmegoldás-tervező – Microsoft
• Prabal Deb | Vezető szoftvermérnök – Microsoft
• Raouf Aliouat | Szoftvermérnök II . – Microsoft
• Ritesh Modi | Vezető szoftvermérnök – Microsoft
• Ryan Pfalz | Vezető megoldástervező – Microsoft

A nem nyilvános LinkedIn-profilok megtekintéséhez jelentkezzen be a LinkedInbe.

Következő lépés

Kapcsolódó erőforrások

• Azure OpenAI
• Azure OpenAI nyelvi modellek
• Machine Learning-parancssori folyamat
• Munkaterület által felügyelt virtuális hálózat elkülönítése
• Privát végpont konfigurálása Machine Learning-munkaterülethez
• Tartalomszűrés