Questo è un guest post scritto in collaborazione con il team dirigente di Iambic Therapeutics.
Terapia Giambica è una startup per la scoperta di farmaci con la missione di creare tecnologie innovative basate sull'intelligenza artificiale per portare farmaci migliori ai malati di cancro, più velocemente.
I nostri strumenti avanzati di intelligenza artificiale (AI) generativa e predittiva ci consentono di cercare nel vasto spazio di possibili molecole farmaceutiche in modo più rapido ed efficace. Le nostre tecnologie sono versatili e applicabili in tutte le aree terapeutiche, classi proteiche e meccanismi d'azione. Oltre a creare strumenti di intelligenza artificiale differenziati, abbiamo creato una piattaforma integrata che unisce software di intelligenza artificiale, dati basati su cloud, infrastruttura di calcolo scalabile e capacità di chimica e biologia ad alto rendimento. La piattaforma abilita la nostra intelligenza artificiale, fornendo dati per perfezionare i nostri modelli, ed è abilitata da essa, sfruttando le opportunità di processo decisionale automatizzato e di elaborazione dei dati.
Misuriamo il successo in base alla nostra capacità di produrre candidati clinici superiori per rispondere alle esigenze urgenti dei pazienti, a una velocità senza precedenti: siamo passati dal lancio del programma ai candidati clinici in soli 24 mesi, significativamente più velocemente dei nostri concorrenti.
In questo post ci concentriamo su come abbiamo utilizzato Karpenter on Servizio Amazon Elastic Kubernetes (Amazon EKS) per scalare l'addestramento e l'inferenza dell'intelligenza artificiale, che sono elementi fondamentali della piattaforma di scoperta Iambic.
La necessità di formazione e inferenza AI scalabili
Ogni settimana, Iambic esegue l'inferenza dell'intelligenza artificiale su dozzine di modelli e milioni di molecole, servendo due casi d'uso principali:
- I chimici farmaceutici e altri scienziati utilizzano la nostra applicazione web, Insight, per esplorare lo spazio chimico, accedere e interpretare dati sperimentali e prevedere le proprietà delle molecole di nuova concezione. Tutto questo lavoro viene svolto in modo interattivo in tempo reale, creando la necessità di inferenza con bassa latenza e throughput medio.
- Allo stesso tempo, i nostri modelli di intelligenza artificiale generativa progettano automaticamente molecole mirate al miglioramento in numerose proprietà, cercando milioni di candidati e richiedendo un throughput enorme e una latenza media.
Guidata da tecnologie di intelligenza artificiale e da esperti cacciatori di farmaci, la nostra piattaforma sperimentale genera migliaia di molecole uniche ogni settimana e ciascuna è sottoposta a molteplici test biologici. I punti dati generati vengono elaborati automaticamente e utilizzati per mettere a punto i nostri modelli di intelligenza artificiale ogni settimana. Inizialmente, la messa a punto del nostro modello richiedeva ore di CPU, quindi era fondamentale un framework per scalare la messa a punto del modello sulle GPU.
I nostri modelli di deep learning hanno requisiti non banali: hanno dimensioni di gigabyte, sono numerosi ed eterogenei e richiedono GPU per inferenza rapida e messa a punto. Guardando all'infrastruttura cloud, avevamo bisogno di un sistema che ci permettesse di accedere alle GPU, scalare verso l'alto e verso il basso rapidamente per gestire carichi di lavoro spinosi ed eterogenei ed eseguire immagini Docker di grandi dimensioni.
Volevamo creare un sistema scalabile per supportare l'addestramento e l'inferenza dell'intelligenza artificiale. Utilizziamo Amazon EKS e stavamo cercando la soluzione migliore per ridimensionare automaticamente i nostri nodi di lavoro. Abbiamo scelto Karpenter per la scalabilità automatica dei nodi Kubernetes per una serie di motivi:
- Facilità di integrazione con Kubernetes, utilizzando la semantica Kubernetes per definire i requisiti dei nodi e le specifiche dei pod per il dimensionamento
- Scalabilità orizzontale dei nodi a bassa latenza
- Facilità di integrazione con la nostra infrastruttura come strumenti di codice (Terraform)
I provisioner dei nodi supportano l'integrazione semplice con Amazon EKS e altre risorse AWS come Cloud di calcolo elastico di Amazon (Amazon EC2) istanze e Negozio di blocchi elastici di Amazon volumi. La semantica Kubernetes utilizzata dai fornitori supporta la pianificazione diretta utilizzando costrutti Kubernetes come incompatibilità o tolleranze e specifiche di affinità o anti-affinità; facilitano inoltre il controllo sul numero e sui tipi di istanze GPU che possono essere pianificate da Karpenter.
Panoramica della soluzione
In questa sezione presentiamo un'architettura generica simile a quella che utilizziamo per i nostri carichi di lavoro, che consente l'implementazione elastica dei modelli utilizzando un'efficiente scalabilità automatica basata su metriche personalizzate.
Il diagramma seguente illustra l'architettura della soluzione.
L'architettura distribuisce a servizio semplice in un pod Kubernetes all'interno di un file Cluster EKS. Potrebbe trattarsi di un'inferenza del modello, di una simulazione di dati o di qualsiasi altro servizio containerizzato, accessibile tramite richiesta HTTP. Il servizio è esposto dietro un proxy inverso utilizzando Traefik. Il proxy inverso raccoglie le metriche relative alle chiamate al servizio e le espone tramite un'API di metriche standard Prometeo. Il scalatore automatico basato sugli eventi Kubernetes (KEDA) è configurato per ridimensionare automaticamente il numero di pod di servizio, in base ai parametri personalizzati disponibili in Prometheus. Qui utilizziamo il numero di richieste al secondo come metrica personalizzata. Lo stesso approccio architetturale si applica se scegli una metrica diversa per il tuo carico di lavoro.
Karpenter monitora eventuali pod in sospeso che non possono essere eseguiti a causa della mancanza di risorse sufficienti nel cluster. Se vengono rilevati tali pod, Karpenter aggiunge più nodi al cluster per fornire le risorse necessarie. Al contrario, se nel cluster sono presenti più nodi di quelli necessari ai pod pianificati, Karpenter rimuove alcuni nodi di lavoro e i pod vengono ripianificati, consolidandoli su un numero inferiore di istanze. Il numero di richieste HTTP al secondo e il numero di nodi possono essere visualizzati utilizzando a graminacee pannello di controllo. Per dimostrare il ridimensionamento automatico, ne eseguiamo uno o più semplici pod generatori di carico, che inviano richieste HTTP al servizio utilizzando arricciare.
Distribuzione della soluzione
Nel procedura dettagliata passo dopo passo, noi usiamo AWS Cloud9 come ambiente per distribuire l'architettura. Ciò consente di completare tutti i passaggi da un browser web. Puoi anche distribuire la soluzione da un computer locale o da un'istanza EC2.
Per semplificare l'implementazione e migliorare la riproducibilità, seguiamo i principi del fare-quadro e la struttura del modello dipendente dalla finestra mobile. Cloniamo il aws-do-eks progetto e, utilizzando docker, creiamo un'immagine del contenitore dotata degli strumenti e degli script necessari. All'interno del contenitore, eseguiamo tutti i passaggi della procedura guidata end-to-end, dalla creazione di un cluster EKS con Karpenter al dimensionamento Istanze EC2.
Per l'esempio in questo post, utilizziamo quanto segue Manifesto del cluster EKS:
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: do-eks-yaml-karpenter
version: '1.28'
region: us-west-2
tags:
karpenter.sh/discovery: do-eks-yaml-karpenter
iam:
withOIDC: true
addons:
- name: aws-ebs-csi-driver
version: v1.26.0-eksbuild.1
wellKnownPolicies:
ebsCSIController: true
managedNodeGroups:
- name: c5-xl-do-eks-karpenter-ng
instanceType: c5.xlarge
instancePrefix: c5-xl
privateNetworking: true
minSize: 0
desiredCapacity: 2
maxSize: 10
volumeSize: 300
iam:
withAddonPolicies:
cloudWatch: true
ebs: true
Questo manifest definisce un cluster denominato do-eks-yaml-karpenter
con il driver EBS CSI installato come componente aggiuntivo. Un gruppo di nodi gestiti con due c5.xlarge
nodes è incluso per eseguire i pod di sistema necessari al cluster. I nodi di lavoro sono ospitati in sottoreti private e l'endpoint API del cluster è pubblico per impostazione predefinita.
Puoi anche utilizzare un cluster EKS esistente invece di crearne uno. Distribuiamo Karpenter seguendo il istruzioni nella documentazione Karpenter o eseguendo quanto segue copione, che automatizza le istruzioni di distribuzione.
Il codice seguente mostra la configurazione Karpenter utilizzata in questo esempio:
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: default
spec:
template:
metadata: null
labels:
cluster-name: do-eks-yaml-karpenter
annotations:
purpose: karpenter-example
spec:
nodeClassRef:
apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
name: default
requirements:
- key: karpenter.sh/capacity-type
operator: In
values:
- spot
- on-demand
- key: karpenter.k8s.aws/instance-category
operator: In
values:
- c
- m
- r
- g
- p
- key: karpenter.k8s.aws/instance-generation
operator: Gt
values:
- '2'
disruption:
consolidationPolicy: WhenUnderutilized
#consolidationPolicy: WhenEmpty
#consolidateAfter: 30s
expireAfter: 720h
---
apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
name: default
spec:
amiFamily: AL2
subnetSelectorTerms:
- tags:
karpenter.sh/discovery: "do-eks-yaml-karpenter"
securityGroupSelectorTerms:
- tags:
karpenter.sh/discovery: "do-eks-yaml-karpenter"
role: "KarpenterNodeRole-do-eks-yaml-karpenter"
tags:
app: autoscaling-test
blockDeviceMappings:
- deviceName: /dev/xvda
ebs:
volumeSize: 80Gi
volumeType: gp3
iops: 10000
deleteOnTermination: true
throughput: 125
detailedMonitoring: true
Definiamo un Karpenter NodePool predefinito con i seguenti requisiti:
- Karpenter può avviare istanze da entrambi
spot
edon-demand
pool di capacità - Le istanze devono provenire da "
c
" (ottimizzato per il calcolo), "m
" (scopo generale), "r
" (ottimizzata per la memoria) o "g
" e "p
" (con accelerazione GPU) famiglie di computer - La generazione dell'istanza deve essere maggiore di 2; Per esempio,
g3
è accettabile, mag2
non è
Il NodePool predefinito definisce anche le politiche di interruzione. I nodi sottoutilizzati verranno rimossi in modo che i pod possano essere consolidati per essere eseguiti su un numero inferiore di nodi o più piccoli. In alternativa, possiamo configurare i nodi vuoti da rimuovere dopo il periodo di tempo specificato. IL expireAfter
L'impostazione specifica la durata massima di qualsiasi nodo, prima che venga arrestato e sostituito, se necessario. Ciò aiuta a ridurre le vulnerabilità della sicurezza ed evitare i problemi tipici dei nodi con tempi di attività lunghi, come la frammentazione dei file o le perdite di memoria.
Per impostazione predefinita, Karpenter effettua il provisioning dei nodi con un volume root ridotto, che può essere insufficiente per l'esecuzione di carichi di lavoro di intelligenza artificiale o machine learning (ML). Alcune delle immagini del contenitore di deep learning possono avere dimensioni di decine di GB e dobbiamo assicurarci che ci sia spazio di archiviazione sufficiente sui nodi per eseguire i pod utilizzando queste immagini. Per fare ciò, definiamo EC2NodeClass
con blockDeviceMappings
, come mostrato nel codice precedente.
Karpenter è responsabile della scalabilità automatica a livello di cluster. Per configurare il ridimensionamento automatico a livello di pod, utilizziamo KEDA per definire una risorsa personalizzata chiamata ScaledObject
, come mostrato nel codice seguente:
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: keda-prometheus-hpa
namespace: hpa-example
spec:
scaleTargetRef:
name: php-apache
minReplicaCount: 1
cooldownPeriod: 30
triggers:
- type: prometheus
metadata:
serverAddress: http://prometheus- server.prometheus.svc.cluster.local:80
metricName: http_requests_total
threshold: '1'
query: rate(traefik_service_requests_total{service="hpa-example-php-apache-80@kubernetes",code="200"}[2m])
Il manifest precedente definisce a ScaledObject
detto keda-prometheus-hpa
, che è responsabile della scalabilità della distribuzione di php-apache e mantiene sempre in esecuzione almeno una replica. Ridimensiona i pod di questa distribuzione in base alla metrica http_requests_total
disponibile in Prometheus ottenuto dalla query specificata e mira a ingrandire i pod in modo che ciascun pod non soddisfi più di una richiesta al secondo. Riduce le repliche dopo che il carico della richiesta è rimasto al di sotto della soglia per più di 30 secondi.
I specifiche di distribuzione per il nostro servizio di esempio contiene quanto segue richieste e limiti delle risorse:
resources:
limits:
cpu: 500m
nvidia.com/gpu: 1
requests:
cpu: 200m
nvidia.com/gpu: 1
Con questa configurazione, ciascuno dei pod di servizio utilizzerà esattamente una GPU NVIDIA. Quando vengono creati nuovi pod, saranno nello stato In sospeso finché non sarà disponibile una GPU. Karpenter aggiunge nodi GPU al cluster secondo necessità per accogliere i pod in sospeso.
A pod generatore di carico invia richieste HTTP al servizio con una frequenza preimpostata. Aumentiamo il numero di richieste aumentando il numero di repliche nel file distribuzione del generatore di carico.
Un ciclo di scalabilità completo con consolidamento dei nodi basato sull'utilizzo viene visualizzato in una dashboard Grafana. Il dashboard seguente mostra il numero di nodi nel cluster per tipo di istanza (in alto), il numero di richieste al secondo (in basso a sinistra) e il numero di pod (in basso a destra).
Iniziamo solo con le due istanze CPU c5.xlarge con cui è stato creato il cluster. Quindi distribuiamo un'istanza del servizio, che richiede una singola GPU. Karpenter aggiunge un'istanza g4dn.xlarge per soddisfare questa esigenza. Quindi distribuiamo il generatore di carico, che fa sì che KEDA aggiunga più pod di servizio e Karpenter aggiunga più istanze GPU. Dopo l'ottimizzazione, lo stato si assesta su un'istanza p3.8xlarge con 8 GPU e un'istanza g5.12xlarge con 4 GPU.
Quando ridimensioniamo la distribuzione che genera carico a 40 repliche, KEDA crea pod di servizio aggiuntivi per mantenere il carico di richieste richiesto per pod. Karpenter aggiunge i nodi g4dn.metal e g4dn.12xlarge al cluster per fornire le GPU necessarie per i pod aggiuntivi. Nello stato ridimensionato, il cluster contiene 16 nodi GPU e serve circa 300 richieste al secondo. Quando riduciamo il generatore di carico a 1 replica, avviene il processo inverso. Dopo il periodo di raffreddamento, KEDA riduce il numero di service pod. Quindi, quando vengono eseguiti meno pod, Karpenter rimuove i nodi sottoutilizzati dal cluster e i pod del servizio vengono consolidati per essere eseguiti su un numero inferiore di nodi. Quando il pod del generatore di carico viene rimosso, un singolo pod di servizio su una singola istanza g4dn.xlarge con 1 GPU rimane in esecuzione. Quando rimuoviamo anche il pod di servizio, il cluster viene lasciato nello stato iniziale con solo due nodi CPU.
Possiamo osservare questo comportamento quando il NodePool
ha l'impostazione consolidationPolicy: WhenUnderutilized
.
Con questa impostazione, Karpenter configura dinamicamente il cluster con il minor numero di nodi possibile, fornendo risorse sufficienti per l'esecuzione di tutti i pod e riducendo al minimo i costi.
Il comportamento di ridimensionamento mostrato nel dashboard seguente viene osservato quando il file NodePool
è impostata la politica di consolidamento WhenEmpty
, insieme a consolidateAfter: 30s
.
In questo scenario, i nodi vengono arrestati solo quando non ci sono pod in esecuzione su di essi dopo il periodo di riflessione. La curva di ridimensionamento appare regolare, rispetto alla politica di consolidamento basata sull’utilizzo; tuttavia, si può vedere che nello stato scalato vengono utilizzati più nodi (22 contro 16).
Nel complesso, la combinazione della scalabilità automatica di pod e cluster garantisce che il cluster si ridimensioni dinamicamente con il carico di lavoro, allocando le risorse quando necessario e rimuovendole quando non in uso, massimizzando così l'utilizzo e riducendo al minimo i costi.
Risultati
Iambic ha utilizzato questa architettura per consentire un uso efficiente delle GPU su AWS e migrare i carichi di lavoro dalla CPU alla GPU. Utilizzando le istanze basate su GPU EC2, Amazon EKS e Karpenter, siamo stati in grado di consentire un'inferenza più rapida per i nostri modelli basati sulla fisica e tempi rapidi di iterazione degli esperimenti per gli scienziati applicati che si affidano alla formazione come servizio.
La tabella seguente riepiloga alcune delle metriche temporali di questa migrazione.
Task | CPU | GPU |
Inferenza utilizzando modelli di diffusione per modelli ML basati sulla fisica | 3,600 secondi |
100 secondi (a causa del batching intrinseco delle GPU) |
Formazione sui modelli ML come servizio | 180 minuti | 4 minuti |
La tabella seguente riassume alcuni dei nostri parametri di tempo e costo.
Task | Prestazioni/costi | |
CPU | GPU | |
Formazione del modello ML |
240 minuti media di $ 0.70 per attività di formazione |
20 minuti media di $ 0.38 per attività di formazione |
Sommario
In questo post, abbiamo mostrato come Iambic ha utilizzato Karpenter e KEDA per scalare la nostra infrastruttura Amazon EKS per soddisfare i requisiti di latenza dei nostri carichi di lavoro di formazione e inferenza AI. Karpenter e KEDA sono potenti strumenti open source che aiutano a scalare automaticamente i cluster EKS e i carichi di lavoro in esecuzione su di essi. Ciò aiuta a ottimizzare i costi di elaborazione soddisfacendo i requisiti di prestazioni. Puoi controllare il codice e distribuire la stessa architettura nel tuo ambiente seguendo la procedura dettagliata completa in questo Repository GitHub.
Informazioni sugli autori
Matteo Welborn è il direttore del Machine Learning presso Iambic Therapeutics. Lui e il suo team sfruttano l’intelligenza artificiale per accelerare l’identificazione e lo sviluppo di nuove terapie, portando più rapidamente farmaci salvavita ai pazienti.
Paolo Whittemore è un ingegnere principale presso Iambic Therapeutics. Supporta la fornitura dell'infrastruttura per la piattaforma di scoperta di farmaci Iambic basata sull'intelligenza artificiale.
Alex Iankoulski è un Principal Solutions Architect, ML/AI Frameworks, che si concentra sull'aiutare i clienti a orchestrare i propri carichi di lavoro AI utilizzando contenitori e infrastrutture di calcolo accelerate su AWS.
- Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
- PlatoData.Network Generativo verticale Ai. Potenzia te stesso. Accedi qui.
- PlatoAiStream. Intelligenza Web3. Conoscenza amplificata. Accedi qui.
- PlatoneESG. Carbonio, Tecnologia pulita, Energia, Ambiente, Solare, Gestione dei rifiuti. Accedi qui.
- Platone Salute. Intelligence sulle biotecnologie e sulle sperimentazioni cliniche. Accedi qui.
- Fonte: https://aws.amazon.com/blogs/machine-learning/scale-ai-training-and-inference-for-drug-discovery-through-amazon-eks-and-karpenter/
- :ha
- :È
- :non
- ][P
- $ SU
- 1
- 10
- 100
- 125
- 16
- 200
- 200m
- 22
- 24
- 26%
- 28
- 30
- 300
- 40
- 600
- 7
- 70
- 8
- 80
- a
- capacità
- capace
- Chi siamo
- accelerare
- accelerata
- accettabile
- accesso
- accessibile
- ospitare
- operanti in
- Action
- aggiungere
- Aggiungi su
- aggiuntivo
- indirizzo
- Aggiunge
- Avanzate
- affinità
- Dopo shavasana, sedersi in silenzio; saluti;
- AI
- Modelli AI
- Addestramento AI
- Tutti
- consente
- lungo
- anche
- sempre
- Amazon
- Amazon EC2
- Amazon Web Services
- an
- ed
- in qualsiasi
- api
- App
- appare
- applicabile
- Applicazioni
- applicato
- si applica
- approccio
- architettonico
- architettura
- SONO
- aree
- artificiale
- intelligenza artificiale
- Intelligenza artificiale (AI)
- AS
- At
- auto
- Automatizzata
- automatizza
- automaticamente
- disponibile
- evitare
- AWS
- basato
- dosaggio
- BE
- stato
- prima
- comportamento
- dietro
- sotto
- MIGLIORE
- Meglio
- Al di là di
- biologia
- Bloccare
- entrambi
- Parte inferiore
- portare
- Portare
- del browser
- costruire
- ma
- by
- detto
- Bandi
- Materiale
- Cancro
- i candidati
- funzionalità
- Ultra-Grande
- capitalizzando
- casi
- cause
- dai un'occhiata
- chimico
- chimica
- Scegli
- ha scelto
- classi
- Info su
- Cloud
- infrastruttura cloud
- Cluster
- codice
- raccoglie
- combinando
- rispetto
- concorrenti
- completamento di una
- Completato
- calcolo
- Calcolare
- computer
- informatica
- Configurazione
- configurato
- consolidamento
- consolidamento
- costrutti
- Contenitore
- Tecnologie Container
- contiene
- di controllo
- al contrario
- cooldown
- Nucleo
- Costo
- Costi
- potuto
- creare
- creato
- crea
- Creazione
- CSI
- curva
- costume
- Clienti
- ciclo
- cruscotto
- dati
- punti dati
- elaborazione dati
- Decision Making
- deep
- apprendimento profondo
- Predefinito
- definire
- definisce
- consegna
- dimostrare
- schierare
- deployment
- Distribuisce
- Design
- progettato
- rilevato
- Mercato
- diagramma
- diverso
- diversificato
- Emittente
- indirizzato
- Direttore
- scoperta
- Rottura
- do
- docker
- documentazione
- fatto
- giù
- decine
- spinto
- autista
- droga
- dovuto
- dinamicamente
- ogni
- in maniera efficace
- efficiente
- senza sforzo
- elementi
- enable
- abilitato
- Abilita
- da un capo all'altro
- endpoint
- ingegnere
- enorme
- abbastanza
- Ambiente
- attrezzato
- sviluppate
- Evento
- Ogni
- di preciso
- esempio
- esistente
- esperimento
- sperimentale
- esperto
- esplora
- esposto
- facilitare
- FAST
- più veloce
- pochi
- meno
- Compila il
- Focus
- si concentra
- seguire
- i seguenti
- Nel
- frammentazione
- Contesto
- quadri
- Frequenza
- da
- pieno
- Generale
- generato
- genera
- ELETTRICA
- generativo
- AI generativa
- generatore
- ottenere
- GPU
- GPU
- maggiore
- Gruppo
- GUEST
- Ospite Messaggio
- maniglia
- Avere
- he
- Aiuto
- aiutare
- aiuta
- qui
- il suo
- ospitato
- ORE
- Come
- Tuttavia
- http
- HTTPS
- Identificazione
- if
- illustra
- Immagine
- immagini
- imperativo
- competenze
- miglioramento
- in
- incluso
- Aumento
- crescente
- Infrastruttura
- inerente
- inizialmente
- inizialmente
- creativi e originali
- intuizione
- installato
- esempio
- invece
- istruzioni
- integrato
- integrazione
- Intelligence
- interpretare
- sicurezza
- IT
- iterazione
- jpg
- ad appena
- continua
- Le
- Genere
- per il tuo brand
- Dipingere
- grandi
- Latenza
- lanciare
- Leadership
- Perdite
- apprendimento
- meno
- a sinistra
- Livello
- Leva
- tutta la vita
- limiti
- caricare
- locale
- Lunghi
- più a lungo
- cerca
- Basso
- macchina
- machine learning
- mantenere
- make
- FA
- gestito
- massimizzando
- massimo
- Maggio..
- misurare
- meccanismi di
- medie
- Soddisfare
- incontro
- Memorie
- unioni
- Metadati
- metallo
- metrico
- Metrica
- migrare
- migrazione
- milioni
- minimizzando
- Missione
- ML
- modello
- modelli
- monitor
- mese
- Scopri di più
- multiplo
- devono obbligatoriamente:
- Nome
- Detto
- necessaria
- Bisogno
- di applicazione
- New
- recentemente
- no
- nodo
- nodi
- romanzo
- numero
- numerose
- Nvidia
- osservare
- ottenuto
- of
- on
- On-Demand
- ONE
- esclusivamente
- aprire
- open source
- operatore
- Opportunità
- ottimizzazione
- OTTIMIZZA
- ottimizzati
- or
- Altro
- nostro
- su
- ancora
- proprio
- paziente
- pazienti
- in attesa di
- per
- performance
- esegue
- periodo
- posto
- piattaforma
- Platone
- Platone Data Intelligence
- PlatoneDati
- punti
- Termini e Condizioni
- politica
- possibile
- Post
- alimentato
- potente
- precedente
- predire
- presenti
- primario
- Direttore
- principi
- un bagno
- processi
- Elaborato
- lavorazione
- produrre
- Programma
- progetto
- proprietà
- Proteine
- fornire
- fornitura
- delega
- la percezione
- scopo
- domanda
- rapidamente
- R
- di rose
- tempo reale
- motivi
- ridurre
- riduce
- raffinare
- regione
- fare affidamento
- resti
- rimuovere
- rimosso
- rimuove
- rimozione
- sostituito
- replica
- richiesta
- richieste
- richiedere
- necessario
- Requisiti
- richiede
- risorsa
- Risorse
- responsabile
- invertire
- destra
- Ruolo
- radice
- Correre
- running
- stesso
- scalabile
- Scala
- scala ai
- scalato
- bilancia
- scala
- scenario
- in programma
- programmazione
- scienziati
- script
- Cerca
- ricerca
- Secondo
- secondo
- Sezione
- problemi di
- visto
- semantica
- inviare
- invia
- server
- serve
- servizio
- Servizi
- servizio
- set
- regolazione
- deposita
- in mostra
- mostrato
- Spettacoli
- significativamente
- simile
- semplificare
- simulazione
- singolo
- Taglia
- piccole
- inferiore
- lisciare
- So
- Software
- soluzione
- Soluzioni
- alcuni
- Fonte
- lo spazio
- Specifiche tecniche
- specificato
- occhiali
- velocità
- Spot
- Standard
- inizia a
- startup
- Regione / Stato
- Passi
- fermato
- conservazione
- La struttura
- sottoreti
- il successo
- tale
- sufficiente
- superiore
- fornitura
- supporto
- supporti
- sicuro
- svc
- sistema
- tavolo
- prende
- mira
- obiettivi
- team
- Tecnologie
- modello
- decine
- Terraform
- di
- che
- I
- Lo Stato
- loro
- Li
- poi
- terapeutica
- Là.
- in tal modo
- Strumenti Bowman per analizzare le seguenti finiture:
- di
- questo
- migliaia
- soglia
- Attraverso
- portata
- tempo
- volte
- a
- ha preso
- strumenti
- top
- Training
- vero
- seconda
- Digitare
- Tipi di
- tipico
- unico
- inaudito
- fino a quando
- tempi di attività
- urgente
- us
- uso
- utilizzato
- utilizzando
- v1
- Valori
- Fisso
- versatile
- versione
- via
- volume
- volumi
- vs
- vulnerabilità
- walkthrough
- ricercato
- Prima
- we
- sito web
- applicazione web
- browser web
- servizi web
- settimana
- WELL
- sono stati
- Che
- Che cosa è l'
- quando
- quale
- while
- OMS
- volere
- con
- entro
- Lavora
- lavoratore
- YAML
- Tu
- Trasferimento da aeroporto a Sharm
- zefiro