Piattaforma applicativa per carichi di lavoro di intelligenza artificiale in Azure
È necessario considerare attentamente la piattaforma di hosting dell'applicazione su cui viene distribuito il carico di lavoro di intelligenza artificiale per garantire che sia possibile ottimizzare l'efficienza, la sicurezza delle operazioni e l'affidabilità.
Questa area di progettazione copre diversi tipi di applicazioni che potrebbero essere rilevanti per il carico di lavoro di intelligenza artificiale:
- Analisi esplorativa dei dati
- Training e ottimizzazione dei modelli
- Inferenza
Questo articolo fornisce indicazioni per selezionare la piattaforma migliore per ognuna di queste funzioni per soddisfare le esigenze aziendali. Esistono anche raccomandazioni generali che è possibile applicare a tutte queste funzioni.
Consigli
Ecco il riepilogo delle raccomandazioni fornite in questo articolo.
| Suggerimento | Descrizione |
|---|---|
| Riutilizzare gli strumenti. | Per iniziare, valutare gli strumenti già usati per capire se possono essere riutilizzati per il carico di lavoro di intelligenza artificiale. Se supportano le funzionalità necessarie e possono soddisfare i requisiti di affidabilità, sicurezza, costi e prestazioni, l'introduzione di un nuovo strumento potrebbe non valerne i costi e le prestazioni. |
| Prendere in considerazione i requisiti di conformità per i dati e le aree in cui si prevede di eseguire la distribuzione. | Potrebbe essere necessario limitare le aree distribuite in o isolare parti del carico di lavoro l'una dall'altra per soddisfare i requisiti di conformità. Entrare nella fase di progettazione con queste informazioni consente di proteggere l'utente dalla necessità di riprogettare in un secondo momento. |
| Ridurre al minimo l'edificio. | Prendere in considerazione soluzioni PaaS (Platform as a Service) o Software as a Service (SaaS) per ridurre al minimo il carico operativo che crea una soluzione personalizzata, ad esempio l'applicazione di patch e altre operazioni di manutenzione. Ridurre al minimo il carico di lavoro del giorno 2 necessario per la nuova tecnologia semplifica l'adozione. Molte funzioni di intelligenza artificiale sono complesse, quindi non è consigliabile creare una piattaforma personalizzata. |
| Comprendere le quote e i limiti. | Quando si progetta per l'uso di soluzioni PaaS o SaaS, comprendere le quote o i limiti applicabili. La possibilità di aumentare il numero di istanze per soddisfare richieste di traffico elevate potrebbe essere influenzata da quote o limiti, pertanto potrebbe essere necessario modificare la progettazione per ridurre al minimo il rischio. |
| Distribuire nella stessa area. | Provare a distribuire tutte le risorse correlate nella stessa area per ridurre la latenza e semplificare la progettazione. |
| Praticare la distribuzione sicura. | In generale, è consigliabile considerare le API per il carico di lavoro di intelligenza artificiale come qualsiasi altra API nell'ambiente in uso. Tutte le API devono essere posizionate dietro un gateway e tutto il codice deve essere gestito con le stesse procedure di distribuzione sicure di ogni altro asset di codice. |
| Stabilire benchmark delle prestazioni tramite la sperimentazione. | Ogni carico di lavoro di intelligenza artificiale è diverso e la quantità di calcolo necessaria dipende dal caso d'uso. Determinare la quantità e i tipi di calcolo ottimali per il carico di lavoro eseguendo test di benchmark completi. Questa guida consente di scegliere una piattaforma, ma si conosceranno solo gli SKU appropriati per il carico di lavoro dopo il test del benchmark. |
Considerazioni sulla piattaforma EDA
EDA è una funzione preliminare comune eseguita dai data scientist prima della modellazione o dell'analisi statistica. Può quindi essere considerata una fase di sviluppo, il che significa che gli obiettivi per l'affidabilità e le prestazioni potrebbero essere significativamente inferiori rispetto a quelli per le risorse di produzione e mantenere la produttività è il fattore più importante.
Questa sezione fornisce indicazioni sulle funzionalità da considerare quando si seleziona una soluzione di piattaforma EDA.
Requisiti funzionali
Quando si valuta una piattaforma EDA, considerare le domande seguenti:
La piattaforma supporta l'utilizzo temporaneo?
La piattaforma deve supportare aree di lavoro temporanee e risorse di calcolo, il che significa che è necessario arrestare le risorse necessarie quando non vengono usate. Questa funzionalità consente di controllare i costi. I processi EDA sono in genere interattivi, quindi gli utenti devono essere in grado di avviare le macchine virtuali e arrestarli durante l'esecuzione dei processi.
La piattaforma supporta la funzionalità di calcolo facoltativa?
La piattaforma deve abilitare l'accesso su richiesta alle GPU in base alle esigenze e fornire varie opzioni di calcolo per facilitare le dimensioni corrette della piattaforma.
La piattaforma supporta MLflow?
La piattaforma EDA dovrebbe consentire di scegliere una tecnologia che consenta l'integrazione con MLflow per tenere traccia degli esperimenti. È consigliabile usare MLflow come protocollo di sviluppo, distribuzione e gestione di modelli perché offre i vantaggi seguenti:
- Rilevamento dell'esperimento. MLflow consente di tenere traccia degli esperimenti registrando parametri, metriche e artefatti. Questa funzionalità è essenziale durante EDA, in modo da poter tenere traccia dei diversi passaggi di pre-elaborazione dei dati e delle tecniche di progettazione delle funzionalità e dei relativi effetti sulle prestazioni del modello.
- Riproducibilità. Poiché registra tutti i dettagli degli esperimenti, MLflow consente di riprodurre i risultati, che è fondamentale per convalidare i risultati.
- Controllo delle versioni dei dati e del modello. MLflow consente di controllare i set di dati e i modelli di controllo delle versioni, semplificando la gestione di versioni diverse delle trasformazioni dei dati e dei modelli testati.
- Lavoro collaborativo. MLflow offre una piattaforma centralizzata in cui i data scientist possono condividere esperimenti e risultati, semplificando la collaborazione e la condivisione delle conoscenze.
Requisiti non funzionali
Considerare anche queste domande:
In che modo la piattaforma può aiutare a controllare i costi?
La piattaforma deve consentire ai data scientist di svolgere il proprio lavoro in base ai requisiti di pianificazione, ma deve essere ridimensionata correttamente per garantire che vengano soddisfatte le aspettative dei costi.
Quali requisiti di sicurezza devono essere seguiti per la piattaforma?
I dati usati durante la fase EDA saranno probabilmente dati di produzione, che richiedono di seguire le procedure di produzione per proteggere i dati e monitorare la piattaforma. A tale scopo, la piattaforma deve supportare tutti i controlli di sicurezza necessari, tra cui:
- Accesso e autorizzazione.
- Crittografia dei dati inattivi e in transito.
- Requisiti di protezione dei dati a livello di area.
- Funzionalità di monitoraggio e avvisi affidabili, tra cui registrazione e controllo.
- Accesso di rete privato ai repository centralizzati per le immagini, i dati e gli asset di codice dei contenitori.
Strumenti
Usare un'istanza di calcolo di Azure Machine Learning con condivisioni file a livello di team come piattaforma EDA. Un'eccezione è se il team o l'organizzazione usa già una piattaforma di hosting appropriata, ad esempio cluster di calcolo abilitati per GPU in Databricks. In tal caso, potrebbe essere più appropriato rimanere su tale piattaforma.
Nota
Non creare una piattaforma EDA completa, a meno che non sia necessario. Il calcolo ottimizzato per GPU è costoso e non è appropriato se il caso d'uso non lo richiede.
Considerazioni sul training del modello e sulla piattaforma di ottimizzazione
Quando si passa al training del modello e all'ottimizzazione, è probabile che siano necessarie risorse di calcolo ottimizzate per GPU ad alte prestazioni per il lavoro a elevato utilizzo di calcolo richiesto da tali attività. L'affidabilità in genere non è importante quanto le prestazioni perché la maggior parte di questo lavoro si verifica in background. Se l'affidabilità elevata è un requisito, valutare se è necessario distribuire il carico di lavoro tra zone o aree di disponibilità. L'affidabilità elevata diventa più importante quando l'aggiornamento del modello viene aggiornato di frequente, che richiede il completamento del training in base a una pianificazione più stretta. L'obiettivo RTO deve determinare la progettazione dell'affidabilità scelta dall'utente.
Le indicazioni contenute in questa sezione si applicano sia al training del modello che all'ottimizzazione. A meno che non si sia costretti a usare piattaforme separate per queste funzioni, è consigliabile usare una singola piattaforma.
Requisiti funzionali
Quando si valutano le piattaforme per il training del modello e l'ottimizzazione, considerare le domande seguenti:
La piattaforma supporta l'utilizzo temporaneo?
Come le attività EDA, il training dei modelli e l'ottimizzazione non vengono in genere eseguiti a tempo pieno, quindi è consigliabile usare una piattaforma che può essere arrestata quando non è in uso per controllare i costi. A differenza di EDA, tuttavia, il training del modello è in genere un processo batch, quindi il calcolo è necessario solo quando il batch viene eseguito e può essere arrestato fino all'esecuzione successiva.
La piattaforma fornisce l'orchestrazione?
A causa della complessità necessaria per la gestione del calcolo per il training del modello e l'ottimizzazione, è consigliabile un agente di orchestrazione.
Le tecnologie esistenti nell'ambiente possono far parte della soluzione?
Se la piattaforma dati esistente include funzionalità di Machine Learning, come Azure Databricks , è possibile usarla per determinati passaggi, ad esempio la trasformazione dei dati e la progettazione delle funzionalità, il training, l'ottimizzazione e altri passaggi in Machine Learning. La combinazione di tecnologie consente di ridurre al minimo i costi e la complessità associati all'uso di una piattaforma dati per le funzioni per cui potrebbe non essere ideale.
Requisiti non funzionali
Si consideri anche questa domanda:
Qual è il compromesso tollerabile tra costi e prestazioni?
In base ai requisiti di calcolo ottimizzati per GPU a prestazioni elevate, assicurarsi di testare e confrontare il training e ottimizzare ampiamente per determinare lo SKU ideale che bilancia le prestazioni rispetto ai costi.
Strumenti
È consigliabile usare Azure Machine Learning per il training del modello e la piattaforma di ottimizzazione perché offre funzionalità di orchestrazione con supporto per il calcolo batch. Sono disponibili due opzioni di calcolo da valutare:
- Il calcolo serverless è ideale per brevi esecuzioni poco frequenti che possono tollerare effetti rumorosi vicini. È possibile scegliere prezzi standard o prezzi spot. I prezzi spot sono consigliati solo per il training altamente interrompibile. Non usare il calcolo serverless per le operazioni a tempo pieno. I costi possono aumentare rapidamente.
- I cluster di calcolo offrono un controllo significativo sull'hardware disponibile e vengono ottimizzati per il training parallelo o distribuito.
Nota
Per i modelli di base, la scelta della piattaforma di hosting del modello potrebbe limitare le opzioni di ottimizzazione. Ad esempio, l'uso del servizio Azure OpenAI per l'hosting di modelli limita le opzioni di ottimizzazione alle funzionalità di ottimizzazione predefinite di Azure OpenAI.
Considerazioni sull'hosting del modello e sulla piattaforma di inferenza
Le funzioni di hosting e inferenza del modello costituiscono il livello di servizio del carico di lavoro di intelligenza artificiale. Queste funzioni vengono eseguite con endpoint specifici del software usato. Le soluzioni software di gestione dei modelli, ad esempio NVIDIA Explorer, TorchServe e TensorFlow Serving, sono essenzialmente SDK Python che fanno fronte a un modello con un'API e aggiungono funzionalità specifiche per la soluzione. È possibile scegliere la piattaforma di hosting in base alla scelta del software o scegliere il software in base alla piattaforma di hosting scelta.
Quando si usano soluzioni SaaS o PaaS con modelli preconfezionati, ad esempio i modelli linguistici di grandi dimensioni disponibili in Azure OpenAI, sono disponibili poche o nessuna opportunità per selezionare un software di gestione. Al contrario, il servizio che si sta usando fornisce un'API. In questo modo si riduce la flessibilità nel processo di creazione di una distribuzione di modelli, che può offrire vantaggi e svantaggi. Ad esempio, può semplificare il processo di sviluppo del carico di lavoro. D'altra parte, riduce la flessibilità nel modo in cui l'applicazione può chiamare e interagire con il modello.
Fondamentalmente, le API per il livello di servizio sono microservizi, quindi è necessario seguire le stesse procedure per queste API seguite per altri microservizi nell'ambiente. Devono essere in contenitori, testa in blocco da altri servizi e avere cicli di vita personalizzati indipendenti da altri servizi e API. Tenere presente, tuttavia, che servono API di livello in genere richiedono una potenza di calcolo basata su GPU significativamente maggiore e immagini di contenitori di dimensioni maggiori rispetto alle API tradizionali.
Questa sezione fornisce indicazioni sulle funzionalità da considerare quando si seleziona una piattaforma di hosting e inferenza di modelli.
Requisiti funzionali
Quando si valutano le piattaforme per l'hosting e l'inferenza di modelli, considerare queste domande:
Il carico di lavoro richiede l'inferenza batch o online?
Gli endpoint di inferenza vengono usati per i processi batch o di inferenza online e il metodo di inferenza consente di determinare la piattaforma di hosting corretta. L'inferenza batch è ospitato in modo ottimale in una piattaforma che supporta l'utilizzo temporaneo e consente l'arresto del calcolo quando non viene usato. L'inferenza online è ospitato in modo ottimale in una piattaforma che supporta l'utilizzo di calcolo elastico, che viene ridimensionato automaticamente in base al carico in qualsiasi momento.
La piattaforma supporta la tracciabilità?
La tracciabilità è fondamentale per mantenere l'integrità dei modelli usati nel carico di lavoro. È importante conoscere informazioni sul modello, ad esempio la versione corrente, chi l'ha distribuita, quando è stata distribuita e la derivazione dei dati del modello.
Applicare tag significativi alle immagini nel registro contenitori per assicurarsi che il servizio di hosting del modello esestra una versione specifica che il team possa facilmente identificare. Questo approccio consente di gestire la governance dei dati riducendo il rischio di modelli obsoleti o non corretti usati nell'ambiente di produzione.
La piattaforma di hosting sarà una risorsa centralizzata?
Molte organizzazioni usano una piattaforma di hosting centralizzata di modelli usata da team diversi per i propri carichi di lavoro. Se la piattaforma di hosting è centralizzata, è consigliabile valutare se è necessario il supporto per il chargeback. Questa funzionalità consente di tenere traccia dell'utilizzo della piattaforma in base al team e al carico di lavoro.
Requisiti non funzionali
Considerare anche queste domande:
Quali sono i requisiti di affidabilità per la piattaforma?
Le API del livello di servizio sono risorse di produzione, quindi è consigliabile applicare gli stessi requisiti di affidabilità a essi applicati ad altri flussi di carico di lavoro che corrispondono alla classificazione di criticità . Se la loro criticità richiede disponibilità elevata, la piattaforma di hosting deve supportare le zone di disponibilità o una progettazione multiregione.
Quali controlli di rete sono necessari per la piattaforma?
Determinare se è necessaria una rete privata o un firewall in uscita per garantire la protezione per la piattaforma.
Quali sono i requisiti di sicurezza per l'identità e l'accesso per la piattaforma?
Determinare l'identità e i controlli di accesso necessari per gli endpoint. Valutare se è necessario il controllo degli accessi in base al ruolo nativo o il supporto predefinito per la piattaforma di identità e accesso, ad esempio Microsoft Entra ID.
Quali funzionalità di monitoraggio supportano la piattaforma?
Determinare le funzionalità di monitoraggio necessarie per gli endpoint. A seconda della piattaforma, è possibile avere accesso limitato ai log e alle metriche, che potrebbero limitare la possibilità di controllare le attività o rilevare malfunzionamenti.
Quali sono i requisiti di prestazioni per la piattaforma?
La latenza di inferenza è un problema comune e diverse piattaforme hanno profili di prestazioni diversi. I servizi Serverless e PaaS che usano un modello di utilità possono essere influenzati dal problema del vicino rumoroso e spesso non hanno garanzie di velocità effettiva. D'altra parte, le stesse piattaforme possono offrire un'opzione self-hosted che offre una velocità effettiva garantita con un modello di pre-acquisto. È anche possibile prendere in considerazione l'hosting automatico in Kubernetes per un comportamento di latenza più prevedibile.
Tenere presente i limiti e le quote del servizio che potrebbero influire sulle prestazioni, ad esempio quelle per Azure OpenAI. Spesso queste quote e limiti sono impostati in modo aggressivo per soddisfare le esigenze di capacità, quindi se la scelta della piattaforma non fornisce le prestazioni necessarie, potrebbe essere necessario adottare strategie per distribuire la domanda di calcolo tra istanze.
Le architetture avanzate possono combinare più distribuzioni per ottenere una velocità effettiva fissa per la maggior parte del carico di lavoro e le funzionalità di bursting per un calcolo più flessibile.
Strumenti
Inferenze in batch
Se si esegue l'inferenza sui dati che risiedono in una piattaforma che supporta l'hosting di modelli, ad esempio Databricks, è consigliabile usare tale piattaforma per l'inferenza. Assicurarsi di isolare il calcolo di inferenza da altre funzioni eseguite dalla piattaforma dati.
È consigliabile usare l'API Batch OpenAI di Azure per i modelli di base.
Per i modelli non di base, prendere in considerazione questi consigli:
Prendere in considerazione l'uso degli endpoint batch di Azure Machine Learning per gli scenari seguenti:
È necessario eseguire l'inferenza in un set di dati di grandi dimensioni distribuito in più file e non è necessaria una bassa latenza.
È necessario eseguire operazioni batch a esecuzione prolungata su set di dati di grandi dimensioni e sfruttare i vantaggi della parallelizzazione.
È necessario distribuire i componenti della pipeline per l'elaborazione batch.
Se è necessario eseguire processi Spark per l'elaborazione dati distribuita, è consigliabile usare l'ambiente di calcolo Spark serverless di Azure Synapse Analytics, Databricks o Machine Learning.
Se nessuno di questi scenari si applica, è consigliabile usare endpoint batch di Machine Learning.
Inferenza online
Valutare la piattaforma PaaS e le soluzioni serverless come primo passaggio. Questi servizi sono in genere il più semplice da adottare e gestire perché semplificano la progettazione e riducono al minimo il carico operativo. Ad esempio, Azure OpenAI è una scelta ottimale per i modelli di base.
- Prendere in considerazione l'uso dell'API serverless di Azure Machine Learning per aggregare l'accesso agli endpoint anche se si usa Azure OpenAI o un'altra soluzione di hosting del modello di base.
Prendere in considerazione Machine Learning con cluster di calcolo gestiti quando le soluzioni PaaS o serverless non sono le più adatte. Il calcolo gestito da Machine Learning supporta la suddivisione del traffico e il mirroring per test A/B, debug e controllo affidabile. Poiché il calcolo è gestito dal servizio, le operazioni day-2 sono più semplici quando si ospita il modello in modalità self-host. Il calcolo gestito offre anche un'ampia gamma di configurazioni di calcolo e funzionalità di ridimensionamento.
Se si sceglie di ospitare in modo autonomo il modello in un cluster servizio Azure Kubernetes (AKS) collegato a Machine Learning o a un'altra piattaforma basata su contenitori, assicurarsi che il pool di nodi sia isolato da altre API o da altri carichi di lavoro nel cluster per ottenere prestazioni prevedibili e ottimizzare la sicurezza. Evitare di usare risorse di calcolo basate su GPU o ottimizzate per GPU per qualsiasi cosa diversa dalle funzioni del carico di lavoro di intelligenza artificiale per ridurre i costi. Definire invece la baseline delle prestazioni tramite test e dimensioni appropriate per soddisfare i requisiti di prestazioni senza eseguire il provisioning eccessivo.
È anche possibile ospitare in autonomia il modello usando soluzioni IaaS (Infrastructure as a Service), ad esempio Data Science Virtual Machine di Azure.
Considerazioni sulla piattaforma di orchestrazione
L'orchestrazione, nel contesto delle piattaforme dell'applicazione del carico di lavoro di intelligenza artificiale, fa riferimento a strumenti come il flusso di prompt in Machine Learning e portale di Azure AI Foundry. Questi strumenti sono progettati per semplificare l'intero ciclo di sviluppo delle applicazioni di intelligenza artificiale automatizzando molte funzioni comuni del flusso di lavoro.
Requisiti non funzionali
Come per tutti gli altri carichi di lavoro di produzione nel cloud, quando si valutano gli strumenti di orchestrazione, è necessario prendere in considerazione:
Affidabilità, sicurezza e monitoraggio. Gli strumenti di orchestrazione devono rispettare gli standard di affidabilità, sicurezza e monitoraggio per i carichi di lavoro di produzione.
Prestazioni. Gli strumenti di orchestrazione non richiedono risorse di calcolo ottimizzate per GPU o basate su GPU, prendere in considerazione SKU per utilizzo generico.
Ottimizzazione dei costi. Gli strumenti di orchestrazione sono sempre on, considerare le opzioni di calcolo elastiche per ridurre al minimo i costi di utilizzo.
Strumenti
Preferisce una soluzione off-the-shelf come il flusso di prompt. Determinare se le relative funzionalità corrispondono alle esigenze di orchestrazione prima di esaminare l'hosting personalizzato con strumenti come LangChain o Semantic Kernel.
Endpoint host per soluzioni come il flusso di prompt in Machine Learning con istanze di calcolo o nel servizio Azure Kubernetes con self-hosting.