Detta är ett gästinlägg som skrivits tillsammans med ledargruppen för Iambic Therapeutics.
Iambic Therapeutics är en startup för läkemedelsupptäckt med ett uppdrag att skapa innovativa AI-drivna teknologier för att ge bättre mediciner till cancerpatienter, snabbare.
Våra avancerade verktyg för generativ och prediktiv artificiell intelligens (AI) gör det möjligt för oss att snabbare och mer effektivt söka igenom det stora utrymmet av möjliga läkemedelsmolekyler. Våra teknologier är mångsidiga och applicerbara inom terapeutiska områden, proteinklasser och verkningsmekanismer. Utöver att skapa differentierade AI-verktyg har vi etablerat en integrerad plattform som kombinerar AI-mjukvara, molnbaserad data, skalbar beräkningsinfrastruktur och kapacitet inom kemi och biologi med hög genomströmning. Plattformen möjliggör både vår AI – genom att tillhandahålla data för att förfina våra modeller – och möjliggörs av den, och utnyttjar möjligheterna till automatiserat beslutsfattande och databearbetning.
Vi mäter framgång genom vår förmåga att producera överlägsna kliniska kandidater för att tillgodose akuta patientbehov, i oöverträffad hastighet: vi avancerade från programlansering till kliniska kandidater på bara 24 månader, betydligt snabbare än våra konkurrenter.
I det här inlägget fokuserar vi på hur vi använde Snickare on Amazon Elastic Kubernetes-tjänst (Amazon EKS) för att skala AI-träning och slutledning, som är kärnelementen i Iambic-plattformen.
Behovet av skalbar AI-träning och slutledning
Varje vecka utför Iambic AI-inferens över dussintals modeller och miljontals molekyler, vilket tjänar två primära användningsfall:
- Läkemedelskemister och andra forskare använder vår webbapplikation Insight för att utforska kemiskt utrymme, komma åt och tolka experimentella data och förutsäga egenskaper hos nydesignade molekyler. Allt detta arbete görs interaktivt i realtid, vilket skapar ett behov av slutsatser med låg latens och medelhög genomströmning.
- Samtidigt designar våra generativa AI-modeller automatiskt molekyler som är inriktade på förbättringar över många egenskaper, söker efter miljontals kandidater och kräver enorm genomströmning och medelhög latens.
Guidad av AI-teknologier och expertjägare, genererar vår experimentella plattform tusentals unika molekyler varje vecka, och var och en utsätts för flera biologiska analyser. De genererade datapunkterna bearbetas automatiskt och används för att finjustera våra AI-modeller varje vecka. Inledningsvis tog vår modellfinjustering timmar av CPU-tid, så ett ramverk för skalning av modellfinjustering på GPU:er var absolut nödvändigt.
Våra modeller för djupinlärning har icke-triviala krav: de är gigabyte stora, är många och heterogena och kräver GPU:er för snabb slutledning och finjustering. När vi tittade på molninfrastruktur behövde vi ett system som gör det möjligt för oss att komma åt GPU: er, skala upp och ner snabbt för att hantera taggiga, heterogena arbetsbelastningar och köra stora Docker-avbildningar.
Vi ville bygga ett skalbart system för att stödja AI-träning och slutledning. Vi använder Amazon EKS och letade efter den bästa lösningen för att automatiskt skala våra arbetarnoder. Vi valde Karpenter för Kubernetes nod automatisk skalning av ett antal anledningar:
- Enkel integration med Kubernetes, med Kubernetes semantik för att definiera nodkrav och podspecifikationer för skalning
- Utskalning av noder med låg latens
- Enkel integration med vår infrastruktur som kodverktyg (Terraform)
Nodprovisionerarna stöder enkel integration med Amazon EKS och andra AWS-resurser som t.ex Amazon Elastic Compute Cloud (Amazon EC2) instanser och Amazon Elastic Block Store volymer. Kubernetes-semantiken som används av leverantörerna stöder riktad schemaläggning med Kubernetes-konstruktioner såsom fläckar eller tolerationer och affinitets- eller antiaffinitetsspecifikationer; de underlättar också kontroll över antalet och typer av GPU-instanser som kan schemaläggas av Karpenter.
Lösningsöversikt
I det här avsnittet presenterar vi en generisk arkitektur som liknar den vi använder för våra egna arbetsbelastningar, vilket möjliggör elastisk distribution av modeller med effektiv automatisk skalning baserad på anpassade mätvärden.
Följande diagram illustrerar lösningsarkitekturen.
Arkitekturen använder en enkel service i en Kubernetes-pod i en EKS-kluster. Detta kan vara en modellinferens, datasimulering eller någon annan containerservice, tillgänglig via HTTP-förfrågan. Tjänsten exponeras bakom en omvänd proxy som använder Traefik. Den omvända proxyn samlar in mätvärden om anrop till tjänsten och exponerar dem via ett standardmätnings-API för Prometheus. Kubernetes Event Driven Autoscaler (Keda) är konfigurerad för att automatiskt skala antalet servicepods, baserat på anpassade mätvärden som finns tillgängliga i Prometheus. Här använder vi antalet förfrågningar per sekund som ett anpassat mått. Samma arkitektoniska tillvägagångssätt gäller om du väljer ett annat mått för din arbetsbelastning.
Karpenter övervakar efter eventuella väntande pods som inte kan köras på grund av brist på tillräckliga resurser i klustret. Om sådana pods upptäcks lägger Karpenter till fler noder till klustret för att tillhandahålla de nödvändiga resurserna. Omvänt, om det finns fler noder i klustret än vad som behövs av de schemalagda podarna, tar Karpenter bort några av arbetarnoderna och podarna schemaläggs om, vilket konsoliderar dem på färre instanser. Antalet HTTP-förfrågningar per sekund och antalet noder kan visualiseras med hjälp av en grafana instrumentbräda. För att demonstrera automatisk skalning kör vi en eller flera enkla lastgenererande kapslar, som skickar HTTP-förfrågningar till tjänsten med hjälp av curl.
Implementering av lösning
I steg-för-steg genomgång, vi använder AWS Cloud9 som en miljö för att distribuera arkitekturen. Detta gör att alla steg kan slutföras från en webbläsare. Du kan också distribuera lösningen från en lokal dator eller EC2-instans.
För att förenkla distributionen och förbättra reproducerbarheten följer vi principerna för göra ramverk och strukturen för beroende på dockare mall. Vi klonar aws-do-eks projekt och, använda Hamnarbetare, bygger vi en containerbild som är utrustad med nödvändiga verktyg och skript. Inom containern går vi igenom alla steg i genomgången från början till slut, från att skapa ett EKS-kluster med Karpenter till att skala EC2-instanser.
För exemplet i det här inlägget använder vi följande EKS-klustermanifest:
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
Detta manifest definierar ett kluster som heter do-eks-yaml-karpenter
med EBS CSI-drivrutinen installerad som ett tillägg. En hanterad nodgrupp med två c5.xlarge
noder ingår för att köra systempods som behövs av klustret. Arbetarnoderna finns i privata undernät, och klustrets API-slutpunkt är offentlig som standard.
Du kan också använda ett befintligt EKS-kluster istället för att skapa ett. Vi distribuerar Karpenter genom att följa instruktioner i Karpenter-dokumentationen eller genom att köra följande skript, som automatiserar installationsinstruktionerna.
Följande kod visar Karpenter-konfigurationen vi använder i det här exemplet:
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
Vi definierar en standard Karpenter NodePool med följande krav:
- Karpenter kan starta instanser från båda
spot
ochon-demand
kapacitetspooler - Förekomster måste vara från "
c
" (beräkningsoptimerad), "m
" (generell mening), "r
” (minnesoptimerat) eller ”g
"Och"p
” (GPU-accelererade) datorfamiljer - Inkomstgenereringen måste vara större än 2; till exempel,
g3
är acceptabelt, meng2
är inte
Standard NodePool definierar också avbrottspolicyer. Underutnyttjade noder kommer att tas bort så att pods kan konsolideras för att köras på färre eller mindre noder. Alternativt kan vi konfigurera tomma noder som ska tas bort efter den angivna tidsperioden. De expireAfter
inställningen anger den maximala livslängden för en nod, innan den stoppas och byts ut vid behov. Detta hjälper till att minska säkerhetssårbarheter samt undvika problem som är typiska för noder med lång drifttid, som filfragmentering eller minnesläckor.
Som standard tillhandahåller Karpenter noder med en liten rotvolym, vilket kan vara otillräckligt för att köra AI eller maskininlärning (ML) arbetsbelastningar. Vissa av deep learning container-bilderna kan vara tiotals GB stora, och vi måste se till att det finns tillräckligt med lagringsutrymme på noderna för att köra pods med dessa bilder. För att göra det, definierar vi EC2NodeClass
med blockDeviceMappings
, som visas i föregående kod.
Karpenter ansvarar för automatisk skalning på klusternivå. För att konfigurera automatisk skalning på podnivå använder vi KEDA för att definiera en anpassad resurs som kallas ScaledObject
, som visas i följande kod:
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])
Det föregående manifestet definierar a ScaledObject
som heter keda-prometheus-hpa
, som är ansvarig för att skala php-apache-distributionen och alltid håller minst en replik igång. Den skalar poddarna för denna distribution baserat på måtten http_requests_total
tillgängligt i Prometheus som erhållits av den angivna frågan, och har som mål att skala upp poddarna så att varje pod inte betjänar mer än en begäran per sekund. Den skalar ner replikerna efter att begäranden har legat under tröskeln i mer än 30 sekunder.
Smakämnen distributionsspecifikation för vår exempeltjänst innehåller följande resursbegäranden och begränsningar:
resources:
limits:
cpu: 500m
nvidia.com/gpu: 1
requests:
cpu: 200m
nvidia.com/gpu: 1
Med den här konfigurationen kommer var och en av servicepodarna att använda exakt en NVIDIA GPU. När nya pods skapas kommer de att vara i väntande läge tills en GPU är tillgänglig. Karpenter lägger till GPU-noder till klustret efter behov för att ta emot de väntande podarna.
A lastgenererande pod skickar HTTP-förfrågningar till tjänsten med en förinställd frekvens. Vi ökar antalet förfrågningar genom att öka antalet repliker i lastgeneratorinstallation.
En fullskalningscykel med användningsbaserad nodkonsolidering visualiseras i en Grafana-instrumentpanel. Följande instrumentpanel visar antalet noder i klustret efter instanstyp (överst), antalet förfrågningar per sekund (nedre till vänster) och antalet pods (nedre till höger).
Vi börjar med bara de två c5.xlarge CPU-instanser som klustret skapades med. Sedan distribuerar vi en tjänsteinstans, som kräver en enda GPU. Karpenter lägger till en g4dn.xlarge-instans för att tillgodose detta behov. Vi distribuerar sedan belastningsgeneratorn, vilket gör att KEDA lägger till fler servicepods och Karpenter lägger till fler GPU-instanser. Efter optimering sätter sig staten på en p3.8xlarge-instans med 8 GPU:er och en g5.12xlarge-instans med 4 GPU:er.
När vi skalar den belastningsgenererande distributionen till 40 repliker skapar KEDA ytterligare servicepods för att upprätthålla den erforderliga förfrågningsbelastningen per pod. Karpenter lägger till g4dn.metal- och g4dn.12xlarge-noder till klustret för att tillhandahålla de GPU:er som behövs för de extra poddarna. I det skalade tillståndet innehåller klustret 16 GPU-noder och betjänar cirka 300 förfrågningar per sekund. När vi skalar ner lastgeneratorn till 1 kopia sker den omvända processen. Efter nedkylningsperioden minskar KEDA antalet servicepods. Sedan när färre poddar körs tar Karpenter bort de underutnyttjade noderna från klustret och servicepodarna konsolideras för att köras på färre noder. När belastningsgeneratorn tas bort, fortsätter en enda servicepod på en enda g4dn.xlarge-instans med 1 GPU att köras. När vi också tar bort servicepodden lämnas klustret i initialtillståndet med endast två CPU-noder.
Vi kan observera detta beteende när NodePool
har inställningen consolidationPolicy: WhenUnderutilized
.
Med den här inställningen konfigurerar Karpenter dynamiskt klustret med så få noder som möjligt, samtidigt som det tillhandahåller tillräckliga resurser för alla pods att köra och även minimerar kostnaderna.
Skalningsbeteendet som visas i följande instrumentpanel observeras när NodePool
konsolideringspolicy är inställd på WhenEmpty
, tillsammans med consolidateAfter: 30s
.
I det här scenariot stoppas noder endast när det inte finns några pods som körs på dem efter avkylningsperioden. Skalningskurvan verkar jämn jämfört med den utnyttjandebaserade konsolideringspolicyn; det kan dock ses att fler noder används i skalat tillstånd (22 mot 16).
Genom att kombinera automatisk skalning av pod och kluster säkerställs att klustret skalas dynamiskt med arbetsbelastningen, allokerar resurser när det behövs och tar bort dem när de inte används, vilket maximerar utnyttjandet och minimerar kostnaderna.
Utkomster
Iambic använde den här arkitekturen för att möjliggöra effektiv användning av GPU:er på AWS och migrera arbetsbelastningar från CPU till GPU. Genom att använda EC2 GPU-drivna instanser, Amazon EKS och Karpenter, kunde vi möjliggöra snabbare slutsatser för våra fysikbaserade modeller och snabba experimentiterationstider för tillämpade vetenskapsmän som förlitar sig på utbildning som en tjänst.
Följande tabell sammanfattar några av tidsmåtten för denna migrering.
uppgift | CPU: er | GPUs |
Inferens med användning av diffusionsmodeller för fysikbaserade ML-modeller | 3,600 sekunder |
100 sekunder (på grund av inneboende batchning av GPU:er) |
ML modellutbildning som tjänst | 180 minuter | 4 minuter |
Följande tabell sammanfattar några av våra tids- och kostnadsmått.
uppgift | Prestanda/kostnad | |
CPU: er | GPUs | |
ML modell utbildning |
240 minuter i genomsnitt 0.70 USD per träningsuppgift |
20 minuter i genomsnitt 0.38 USD per träningsuppgift |
Sammanfattning
I det här inlägget visade vi upp hur Iambic använde Karpenter och KEDA för att skala vår Amazon EKS-infrastruktur för att möta latenskraven för vår AI-inferens och träningsbelastningar. Karpenter och KEDA är kraftfulla verktyg med öppen källkod som hjälper till att automatiskt skala EKS-kluster och arbetsbelastningar som körs på dem. Detta hjälper till att optimera beräkningskostnaderna samtidigt som prestandakraven uppfylls. Du kan kolla in koden och distribuera samma arkitektur i din egen miljö genom att följa hela genomgången i denna GitHub repo.
Om författarna
Matthew Welborn är chef för Machine Learning på Iambic Therapeutics. Han och hans team utnyttjar AI för att påskynda identifieringen och utvecklingen av nya terapier, vilket ger patienterna livräddande läkemedel snabbare.
Paul Whittemore är chefsingenjör på Iambic Therapeutics. Han stöder leverans av infrastrukturen för den Iambic AI-drivna läkemedelsupptäcktsplattformen.
Alex Iankoulski är en Principal Solutions Architect, ML/AI Frameworks, som fokuserar på att hjälpa kunder att orkestrera sina AI-arbetsbelastningar med hjälp av containrar och accelererad datorinfrastruktur på AWS.
- SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
- PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
- PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
- Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
- PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
- Källa: https://aws.amazon.com/blogs/machine-learning/scale-ai-training-and-inference-for-drug-discovery-through-amazon-eks-and-karpenter/
- : har
- :är
- :inte
- ][s
- $UPP
- 1
- 10
- 100
- 125
- 16
- 200
- Ner till 200m
- 22
- 24
- 26%
- 28
- 30
- 300
- 40
- 600
- 7
- 70
- 8
- 80
- a
- förmåga
- Able
- Om oss
- accelerera
- accelererad
- godtagbart
- tillgång
- tillgänglig
- rymma
- tvärs
- Handling
- lägga till
- Tillägg
- Annat
- adress
- Lägger
- avancerat
- affinitet
- Efter
- AI
- AI-modeller
- AI-utbildning
- Alla
- tillåter
- längs
- också
- alltid
- amason
- Amazon EC2
- Amazon Web Services
- an
- och
- vilken som helst
- api
- app
- visas
- tillämplig
- Ansökan
- tillämpas
- applicerar
- tillvägagångssätt
- arkitektoniska
- arkitektur
- ÄR
- områden
- konstgjord
- artificiell intelligens
- Konstgjord intelligens (AI)
- AS
- At
- bil
- Automatiserad
- automatiserar
- automatiskt
- tillgänglig
- undvika
- AWS
- baserat
- dosering
- BE
- varit
- innan
- beteende
- bakom
- nedan
- BÄST
- Bättre
- Bortom
- biologi
- Blockera
- båda
- Botten
- föra
- Föra
- webbläsare
- SLUTRESULTAT
- men
- by
- kallas
- Samtal
- KAN
- Cancer
- kandidater
- kapacitet
- Kapacitet
- kapitalisera
- fall
- Orsakerna
- ta
- kemisk
- kemi
- Välja
- valde
- klasser
- Klinisk
- cloud
- molninfrastruktur
- kluster
- koda
- samlar
- kombinera
- jämfört
- konkurrenter
- fullborda
- Avslutade
- beräkning
- Compute
- dator
- databehandling
- konfiguration
- konfigurerad
- konsolidera
- konsolidering
- konstrukt
- Behållare
- Behållare
- innehåller
- kontroll
- omvänt
- kyla ner
- Kärna
- Pris
- Kostar
- kunde
- skapa
- skapas
- skapar
- Skapa
- CSI
- kurva
- beställnings
- Kunder
- cykel
- instrumentbräda
- datum
- datapunkter
- databehandling
- Beslutsfattande
- djup
- djupt lärande
- Standard
- definiera
- definierar
- leverans
- demonstrera
- distribuera
- utplacering
- vecklas ut
- Designa
- utformade
- detekterad
- Utveckling
- Diagrammet
- olika
- differentierad
- Diffusion
- riktad
- Direktör
- Upptäckten
- Störningar
- do
- Hamnarbetare
- dokumentation
- gjort
- ner
- dussintals
- driven
- chaufför
- drog
- grund
- dynamiskt
- varje
- effektivt
- effektiv
- enkel
- element
- möjliggöra
- aktiverad
- möjliggör
- början till slut
- Slutpunkt
- ingenjör
- enorm
- tillräckligt
- Miljö
- utrustad
- etablerade
- händelse
- Varje
- exakt
- exempel
- befintliga
- experimentera
- experimentell
- expert
- utforska
- utsatta
- främja
- SNABB
- snabbare
- få
- färre
- Fil
- Fokus
- fokuserar
- följer
- efter
- För
- fragmentering
- Ramverk
- ramar
- Frekvens
- från
- full
- Allmänt
- genereras
- genererar
- generering
- generativ
- Generativ AI
- Generatorn
- skaffa sig
- GPU
- GPUs
- större
- Grupp
- Gäst
- gäst inlägg
- hantera
- Har
- he
- hjälpa
- hjälpa
- hjälper
- här.
- hans
- värd
- ÖPPETTIDER
- Hur ser din drömresa ut
- Men
- http
- HTTPS
- Identifiering
- if
- illustrerar
- bild
- bilder
- nödvändigt
- förbättra
- förbättring
- in
- ingår
- Öka
- ökande
- Infrastruktur
- inneboende
- inledande
- initialt
- innovativa
- insikt
- installerad
- exempel
- istället
- instruktioner
- integrerade
- integrering
- Intelligens
- tolka
- problem
- IT
- iteration
- jpg
- bara
- håller
- Nyckel
- Snäll
- Etiketter
- Brist
- Large
- Latens
- lansera
- Ledarskap
- Läckor
- inlärning
- t minst
- vänster
- Nivå
- Hävstång
- livstid
- gränser
- läsa in
- lokal
- Lång
- längre
- du letar
- Låg
- Maskinen
- maskininlärning
- bibehålla
- göra
- GÖR
- förvaltade
- maximera
- maximal
- Maj..
- mäta
- mekanismer
- Medium
- Möt
- möte
- Minne
- går samman
- metadata
- metall
- metriska
- Metrics
- migrera
- migration
- miljoner
- minimerande
- Mission
- ML
- modell
- modeller
- monitorer
- månader
- mer
- multipel
- måste
- namn
- Som heter
- nödvändigt för
- Behöver
- behövs
- Nya
- nytt
- Nej
- nod
- noder
- roman
- antal
- talrik
- Nvidia
- observera
- erhållna
- of
- on
- On-Demand
- ONE
- endast
- öppet
- öppen källkod
- Operatören
- möjligheter
- optimering
- Optimera
- optimerad
- or
- Övriga
- vår
- ut
- över
- egen
- Patienten
- patienter
- väntan
- för
- prestanda
- utför
- perioden
- Plats
- plattform
- plato
- Platon Data Intelligence
- PlatonData
- poäng
- Strategier
- policy
- möjlig
- Inlägg
- drivs
- den mäktigaste
- föregående
- förutse
- presentera
- primär
- Principal
- Principerna
- privat
- process
- Bearbetad
- bearbetning
- producera
- Program
- projektet
- egenskaper
- Protein
- ge
- tillhandahålla
- ombud
- allmän
- Syftet
- fråga
- snabbt
- R
- verklig
- realtid
- skäl
- minska
- minskar
- förfina
- region
- förlita
- resterna
- ta bort
- avlägsnas
- avlägsnar
- bort
- ersättas
- svara
- begära
- förfrågningar
- kräver
- Obligatorisk
- Krav
- Kräver
- resurs
- Resurser
- ansvarig
- vända
- höger
- Roll
- rot
- Körning
- rinnande
- Samma
- skalbar
- Skala
- skala ai
- skalad
- skalor
- skalning
- scenario
- planerad
- schemaläggning
- vetenskapsmän
- skript
- Sök
- söka
- Andra
- sekunder
- §
- säkerhet
- sett
- semantik
- sända
- sänder
- server
- serverar
- service
- Tjänster
- portion
- in
- inställning
- lägger sig
- utställningsmonter
- visas
- Visar
- signifikant
- liknande
- förenkla
- simulering
- enda
- Storlek
- Small
- mindre
- släta
- So
- Mjukvara
- lösning
- Lösningar
- några
- Källa
- Utrymme
- specifikationer
- specificerade
- specifikationer
- fart
- Spot
- standard
- starta
- start
- Ange
- Steg
- slutade
- förvaring
- struktur
- subnät
- framgång
- sådana
- tillräcklig
- överlägsen
- leverera
- stödja
- Stöder
- säker
- svc
- system
- bord
- tar
- targeting
- mål
- grupp
- Tekniken
- mall
- tiotals
- Terraform
- än
- den där
- Smakämnen
- Staten
- deras
- Dem
- sedan
- terapeutika
- Där.
- vari
- Dessa
- de
- detta
- tusentals
- tröskelvärde
- Genom
- genomströmning
- tid
- gånger
- till
- tog
- verktyg
- topp
- Utbildning
- sann
- två
- Typ
- typer
- typisk
- unika
- utan motstycke
- tills
- drifttider
- brådskande
- us
- användning
- Begagnade
- med hjälp av
- v1
- Värden
- Omfattande
- mångsidig
- version
- via
- volym
- volymer
- vs
- sårbarheter
- genomgång
- ville
- var
- we
- webb
- webbapplikation
- webbläsare
- webbservice
- vecka
- VÄL
- były
- Vad
- Vad är
- när
- som
- medan
- VEM
- kommer
- med
- inom
- Arbete
- arbetstagaren
- jaml
- Om er
- Din
- zephyrnet