Це гостьовий пост, написаний у співавторстві з керівництвом Iambic Therapeutics.
Ямбічна терапія – це стартап із розробки ліків, місія якого полягає у створенні інноваційних технологій на основі штучного інтелекту, щоб швидше надавати кращі ліки хворим на рак.
Наші передові інструменти генеративного та прогнозного штучного інтелекту (ШІ) дозволяють нам швидше та ефективніше шукати величезний простір можливих молекул ліків. Наші технології є універсальними та застосовними в різних терапевтичних областях, класах білків і механізмах дії. Окрім створення диференційованих інструментів ШІ, ми створили інтегровану платформу, яка об’єднує програмне забезпечення ШІ, хмарні дані, масштабовану обчислювальну інфраструктуру та високопродуктивні можливості хімії та біології. Платформа забезпечує наш штучний інтелект, надаючи дані для вдосконалення наших моделей, і підтримується ним, використовуючи можливості для автоматизованого прийняття рішень і обробки даних.
Ми вимірюємо успіх нашою здатністю створювати чудові клінічні кандидати для вирішення нагальних потреб пацієнтів із безпрецедентною швидкістю: ми просунулися від запуску програми до клінічних кандидатів лише за 24 місяці, значно швидше, ніж наші конкуренти.
У цій публікації ми зосередимося на тому, як ми використовували Карпентер on Послуга Amazon Elastic Kubernetes (Amazon EKS) для масштабування навчання штучного інтелекту та висновків, які є основними елементами платформи відкриття Iambic.
Потреба в масштабованому навчанні ШІ та висновках
Щотижня Iambic виконує штучний інтелект для десятків моделей і мільйонів молекул, обслуговуючи два основних випадки використання:
- Хіміки-медики та інші вчені використовують нашу веб-програму Insight, щоб досліджувати хімічний простір, отримувати доступ до експериментальних даних і інтерпретувати їх, а також прогнозувати властивості новостворених молекул. Уся ця робота виконується в інтерактивному режимі в реальному часі, створюючи потребу в висновках із низькою затримкою та середньою пропускною здатністю.
- Водночас наші генеративні моделі штучного інтелекту автоматично проектують молекули, націлені на покращення багатьох властивостей, шукають мільйони кандидатів і вимагають величезної пропускної здатності та середньої затримки.
Керуючись технологіями штучного інтелекту та експертами-мисливцями за наркотиками, наша експериментальна платформа щотижня генерує тисячі унікальних молекул, кожна з яких піддається численним біологічним аналізам. Згенеровані точки даних автоматично обробляються та використовуються для точного налаштування наших моделей ШІ щотижня. Спочатку тонке налаштування нашої моделі займало години процесорного часу, тому структура для масштабування точного налаштування моделі на графічних процесорах була обов’язковою.
Наші моделі глибокого навчання мають нетривіальні вимоги: вони мають розмір у гігабайтах, є численними та різнорідними та потребують графічних процесорів для швидкого висновку та тонкого налаштування. Розглядаючи хмарну інфраструктуру, нам потрібна була система, яка б дозволяла нам отримувати доступ до графічних процесорів, швидко збільшувати та зменшувати масштаб, щоб справлятися з різкими неоднорідними робочими навантаженнями та запускати великі образи Docker.
Ми хотіли створити масштабовану систему для підтримки навчання ШІ та висновків. Ми використовуємо Amazon EKS і шукали найкраще рішення для автоматичного масштабування наших робочих вузлів. Ми вибрали Karpenter для автоматичного масштабування вузла Kubernetes з кількох причин:
- Простота інтеграції з Kubernetes, використання семантики Kubernetes для визначення вимог до вузлів і специфікацій модулів для масштабування
- Масштабування вузлів із низькою затримкою
- Простота інтеграції з нашою інфраструктурою як інструментарій кодування (Terraform)
Провайдери вузлів підтримують легку інтеграцію з Amazon EKS та іншими ресурсами AWS, як-от Обчислювальна хмара Amazon Elastic (Amazon EC2) примірники та Магазин еластичних блоків Amazon обсяги. Семантика Kubernetes, яку використовують провайдери, підтримує спрямоване планування за допомогою конструкцій Kubernetes, таких як плями або допуски, а також специфікації спорідненості або антиспорідненості; вони також полегшують контроль над кількістю та типами екземплярів GPU, які можуть бути заплановані Карпентером.
Огляд рішення
У цьому розділі ми представляємо загальну архітектуру, подібну до тієї, яку ми використовуємо для наших власних робочих навантажень, яка дозволяє еластичне розгортання моделей за допомогою ефективного автоматичного масштабування на основі користувацьких показників.
Наступна діаграма ілюструє архітектуру рішення.
Архітектура розгортає a простий сервіс у модулі Kubernetes у межах an Кластер EKS. Це може бути висновок моделі, симуляція даних або будь-який інший контейнерний сервіс, доступний через запит HTTP. Служба розкрита за допомогою зворотного проксі Traefik. Зворотний проксі-сервер збирає метрики про виклики служби та надає їх через стандартний API метрик Прометей. Керований подіями автомасштабувальник Kubernetes (KEDA) налаштовано на автоматичне масштабування кількості пакетів послуг на основі спеціальних показників, доступних у Prometheus. Тут ми використовуємо кількість запитів за секунду як спеціальний показник. Той самий архітектурний підхід застосовується, якщо ви виберете інший показник для свого робочого навантаження.
Karpenter стежить за будь-якими модулями, що очікують на розгляд, які не можуть працювати через відсутність достатніх ресурсів у кластері. Якщо такі модулі виявлені, Карпентер додає додаткові вузли до кластера, щоб забезпечити необхідні ресурси. І навпаки, якщо в кластері більше вузлів, ніж потрібно для запланованих модулів, Карпентер видаляє деякі робочі вузли, і модулі переплановуються, консолідуючи їх у меншій кількості екземплярів. Кількість HTTP-запитів за секунду та кількість вузлів можна візуалізувати за допомогою a Grafana панель приладів. Щоб продемонструвати автоматичне масштабування, ми запускаємо один або декілька прості вантажоутворювальні контейнери, які надсилають HTTP-запити до служби за допомогою витися.
Розгортання рішення
У покрокова інструкція, ми використовуємо AWS Cloud9 як середовище для розгортання архітектури. Це дає змогу виконувати всі кроки з веб-браузера. Ви також можете розгорнути рішення з локального комп’ютера або інсталяції EC2.
Щоб спростити розгортання та покращити відтворюваність, ми дотримуємося принципів do-framework та структура шаблон depend-on-docker. Ми клонуємо aws-do-eks проект і, використовуючи Docker, ми створюємо образ контейнера, оснащений необхідними інструментами та сценаріями. Усередині контейнера ми проходимо всі кроки наскрізного керівництва, від створення кластера EKS за допомогою Karpenter до масштабування екземпляри EC2.
Для прикладу в цій публікації ми використовуємо наступне Маніфест кластера 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
Цей маніфест визначає кластер під назвою do-eks-yaml-karpenter
з драйвером EBS CSI, встановленим як доповнення. Керована група вузлів із двома c5.xlarge
вузлів включено для запуску системних модулів, необхідних кластеру. Робочі вузли розміщені в приватних підмережах, а кінцева точка API кластера загальнодоступна за замовчуванням.
Ви також можете використовувати наявний кластер EKS замість того, щоб його створювати. Ми розгортаємо Karpenter, дотримуючись інструкції у документації Karpenter або виконавши наступне сценарій, що автоматизує інструкції з розгортання.
Наступний код показує конфігурацію Karpenter, яку ми використовуємо в цьому прикладі:
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
Ми визначаємо типовий пул вузлів Karpenter із такими вимогами:
- Karpenter може запускати екземпляри з обох
spot
таon-demand
місткість пулів - Екземпляри мають бути з "
c
” (оптимізовано для обчислень), “m
" (Головна мета), "r
” (оптимізовано пам’ять) або „g
"І"p
” (прискорений GPU) обчислювальних сімейств - Генерація екземплярів має бути більше 2; наприклад,
g3
прийнятно, алеg2
НЕ
Пул вузлів за замовчуванням також визначає політики зриву. Вузли, які не використовуються, буде видалено, щоб модулі можна було консолідувати для роботи на меншій кількості вузлів. Крім того, ми можемо налаштувати видалення порожніх вузлів після зазначеного періоду часу. The expireAfter
Параметр визначає максимальний термін служби будь-якого вузла, перш ніж його буде зупинено та замінено, якщо необхідно. Це допомагає зменшити вразливість системи безпеки, а також уникнути проблем, типових для вузлів із тривалим часом безвідмовної роботи, таких як фрагментація файлів або витік пам’яті.
За замовчуванням Karpenter надає вузли з невеликим кореневим об’ємом, якого може бути недостатньо для виконання робочих навантажень AI або машинного навчання (ML). Розмір деяких зображень контейнерів глибокого навчання може становити десятки ГБ, і нам потрібно переконатися, що на вузлах достатньо місця для зберігання, щоб запускати модулі за допомогою цих зображень. Для цього ми визначаємо EC2NodeClass
з blockDeviceMappings
, як показано в попередньому коді.
Карпентер відповідає за автоматичне масштабування на рівні кластера. Щоб налаштувати автоматичне масштабування на рівні модуля, ми використовуємо KEDA для визначення спеціального ресурсу під назвою ScaledObject
, як показано в наступному коді:
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])
Попередній маніфест визначає a ScaledObject
названий keda-prometheus-hpa
, який відповідає за масштабування розгортання php-apache і завжди підтримує роботу принаймні однієї репліки. Він масштабує пакети цього розгортання на основі метрики http_requests_total
доступний у Prometheus, отриманий за вказаним запитом, і націлений на збільшення модулів таким чином, щоб кожен пакет обслуговував не більше одного запиту на секунду. Він зменшує репліки після того, як навантаження запиту було нижче порогового значення протягом довше 30 секунд.
Команда розгортання спец для нашого прикладу служба містить наступне запити на ресурси та обмеження:
resources:
limits:
cpu: 500m
nvidia.com/gpu: 1
requests:
cpu: 200m
nvidia.com/gpu: 1
За такої конфігурації кожен із пакетів послуг використовуватиме лише один графічний процесор NVIDIA. Коли створюються нові пакети, вони перебувають у стані очікування, доки не стане доступним графічний процесор. Karpenter додає вузли графічного процесора до кластера за потреби для розміщення модулів, що очікують на розгляд.
A навантажувальний под надсилає HTTP-запити до служби із заданою частотою. Ми збільшуємо кількість запитів за рахунок збільшення кількості реплік у розгортання генератора навантаження.
Повний цикл масштабування з консолідацією вузлів на основі використання відображається на інформаційній панелі Grafana. На наступній інформаційній панелі показано кількість вузлів у кластері за типом екземпляра (угорі), кількість запитів на секунду (унизу ліворуч) і кількість пакетів (внизу праворуч).
Ми починаємо лише з двох екземплярів ЦП c5.xlarge, з якими було створено кластер. Потім ми розгортаємо один екземпляр служби, для якого потрібен один графічний процесор. Karpenter додає екземпляр g4dn.xlarge, щоб задовольнити цю потребу. Потім ми розгортаємо генератор навантаження, що змушує KEDA додавати більше пакетів служб, а Karpenter додає більше екземплярів GPU. Після оптимізації стан установлюється на один екземпляр p3.8xlarge з 8 графічним процесором і один екземпляр g5.12xlarge з 4 графічним процесором.
Коли ми масштабуємо розгортання, що генерує навантаження, до 40 реплік, KEDA створює додаткові пакети служб, щоб підтримувати необхідне навантаження запитів на пакет. Карпентер додає вузли g4dn.metal і g4dn.12xlarge до кластера, щоб забезпечити необхідні графічні процесори для додаткових модулів. У масштабованому стані кластер містить 16 вузлів GPU і обслуговує близько 300 запитів на секунду. Коли ми зменшуємо генератор навантаження до 1 репліки, відбувається зворотний процес. Після періоду відновлення KEDA зменшує кількість службових контейнерів. Потім, коли запущено менше модулів, Карпентер видаляє вузли, що недостатньо використовуються, з кластера, а пакети служб консолідуються для роботи на меншій кількості вузлів. Коли модуль генератора навантаження видаляється, один модуль служби в одному екземплярі g4dn.xlarge з 1 графічним процесором продовжує працювати. Коли ми також видаляємо пакет обслуговування, кластер залишається у початковому стані лише з двома вузлами ЦП.
Ми можемо спостерігати таку поведінку, коли NodePool
має налаштування consolidationPolicy: WhenUnderutilized
.
За допомогою цього параметра Karpenter динамічно налаштовує кластер із якомога меншою кількістю вузлів, забезпечуючи достатні ресурси для роботи всіх модулів і мінімізуючи витрати.
Поведінка масштабування, показана на наступній інформаційній панелі, спостерігається, коли NodePool
встановлено політику консолідації WhenEmpty
, разом з consolidateAfter: 30s
.
У цьому сценарії вузли зупиняються лише тоді, коли на них не працюють модулі після періоду охолодження. Крива масштабування виглядає гладкою порівняно з політикою консолідації на основі використання; однак можна побачити, що в масштабованому стані використовується більше вузлів (22 проти 16).
Загалом поєднання автоматичного масштабування модуля й кластера гарантує, що кластер динамічно масштабується відповідно до робочого навантаження, розподіляючи ресурси за потреби та видаляючи їх, коли вони не використовуються, тим самим максимізуючи використання та мінімізуючи витрати.
Результати
Iambic використовував цю архітектуру, щоб забезпечити ефективне використання GPU на AWS і перенести навантаження з CPU на GPU. Використовуючи екземпляри з графічним процесором EC2, Amazon EKS і Karpenter, ми змогли забезпечити швидший висновок для наших моделей на основі фізики та короткий час ітерації експерименту для вчених-прикладників, які покладаються на навчання як на послугу.
У наведеній нижче таблиці підсумовано деякі часові показники цієї міграції.
Завдання | Процесори | Графічні процесори |
Висновок із використанням моделей дифузії для моделей ML на основі фізики | 3,600 секунд: |
100 секунд: (через невід'ємне пакетування GPU) |
Навчання моделі ML як послуга | 180 хвилин | 4 хвилин |
У таблиці нижче наведено деякі з наших показників часу та вартості.
Завдання | Продуктивність/Вартість | |
Процесори | Графічні процесори | |
Навчання моделі ML |
240 хвилин в середньому 0.70 доларів США за навчальне завдання |
20 хвилин в середньому 0.38 доларів США за навчальне завдання |
Підсумки
У цьому дописі ми продемонстрували, як Iambic використовував Karpenter і KEDA для масштабування нашої інфраструктури Amazon EKS, щоб відповідати вимогам щодо затримки наших висновків ШІ та навчальних навантажень. Karpenter і KEDA — це потужні інструменти з відкритим кодом, які допомагають автоматично масштабувати кластери EKS і робочі навантаження, які на них виконуються. Це допомагає оптимізувати витрати на обчислення, одночасно задовольняючи вимоги до продуктивності. Ви можете перевірити код і розгорнути ту саму архітектуру у своєму власному середовищі, виконавши повну інструкцію в цьому GitHub репо.
Про авторів
Меттью Велборн є директором машинного навчання в Iambic Therapeutics. Він і його команда використовують штучний інтелект, щоб прискорити ідентифікацію та розробку нових терапевтичних засобів, швидше доставляючи життєво важливі ліки пацієнтам.
Пол Віттемор є головним інженером компанії Iambic Therapeutics. Він підтримує створення інфраструктури для платформи виявлення ліків на основі ШІ Iambic.
Алекс Янкульський є головним архітектором рішень, ML/AI Frameworks, який зосереджується на допомозі клієнтам організовувати робочі навантаження ШІ за допомогою контейнерів та прискореної обчислювальної інфраструктури на AWS.
- Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
- PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
- PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
- ПлатонЕСГ. вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
- PlatoHealth. Розвідка про біотехнології та клінічні випробування. Доступ тут.
- джерело: https://aws.amazon.com/blogs/machine-learning/scale-ai-training-and-inference-for-drug-discovery-through-amazon-eks-and-karpenter/
- : має
- :є
- : ні
- ][стор
- $UP
- 1
- 10
- 100
- 125
- 16
- 200
- 200m
- 22
- 24
- 26%
- 28
- 30
- 300
- 40
- 600
- 7
- 70
- 8
- 80
- a
- здатність
- Здатний
- МЕНЮ
- прискорювати
- прискорений
- прийнятний
- доступ
- доступною
- розмістити
- через
- дію
- додавати
- Додатковий
- Додатковий
- адреса
- Додає
- просунутий
- спорідненість
- після
- AI
- Моделі AI
- Навчання AI
- ВСІ
- дозволяє
- по
- Також
- завжди
- Amazon
- Amazon EC2
- Amazon Web Services
- an
- та
- будь-який
- API
- додаток
- з'являється
- застосовно
- додаток
- прикладної
- застосовується
- підхід
- архітектурний
- архітектура
- ЕСТЬ
- області
- штучний
- штучний інтелект
- Штучний інтелект (AI)
- AS
- At
- автоматичний
- Автоматизований
- автоматизує
- автоматично
- доступний
- уникнути
- AWS
- заснований
- дозування
- BE
- було
- перед тим
- поведінка
- за
- нижче
- КРАЩЕ
- Краще
- За
- біологія
- Блокувати
- обидва
- дно
- приносити
- Приведення
- браузер
- будувати
- але
- by
- званий
- Виклики
- CAN
- рак
- кандидатів
- можливості
- потужність
- капіталізація
- випадків
- Причини
- перевірка
- хімічний
- хімія
- Вибирати
- вибрав
- класів
- Клінічний
- хмара
- інфраструктура хмари
- кластер
- код
- збирає
- об'єднання
- порівняний
- конкурентів
- повний
- Зроблено
- обчислення
- обчислення
- комп'ютер
- обчислення
- конфігурація
- налаштувати
- консолідація
- консолідація
- конструкти
- Контейнер
- Контейнери
- містить
- контроль
- навпаки
- cooldown
- Core
- Коштувати
- витрати
- може
- створювати
- створений
- створює
- створення
- CSI
- крива
- виготовлений на замовлення
- Клієнти
- цикл
- приладова панель
- дані
- точки даних
- обробка даних
- Прийняття рішень
- глибокий
- глибоке навчання
- дефолт
- визначати
- Визначає
- доставка
- демонструвати
- розгортання
- розгортання
- розгортає
- дизайн
- призначений
- виявлено
- розробка
- схема
- різний
- диференційований
- радіомовлення
- спрямований
- Директор
- відкриття
- Зрив
- do
- Docker
- документація
- зроблений
- вниз
- безліч
- керований
- водій
- наркотик
- два
- динамічно
- кожен
- фактично
- ефективний
- без зусиль
- елементи
- включіть
- включений
- дозволяє
- кінець в кінець
- Кінцева точка
- інженер
- величезний
- досить
- Навколишнє середовище
- обладнаний
- встановлений
- Event
- Кожен
- точно
- приклад
- існуючий
- експеримент
- експериментальний
- експерт
- дослідити
- піддаватися
- фасилітувати
- ШВИДКО
- швидше
- кілька
- менше
- філе
- Сфокусувати
- фокусується
- стежити
- після
- для
- фрагментація
- Рамки
- каркаси
- частота
- від
- Повний
- Загальне
- генерується
- генерує
- покоління
- генеративний
- Генеративний ШІ
- generator
- отримати
- GPU
- Графічні процесори
- великий
- Group
- гість
- Guest Post
- обробляти
- Мати
- he
- допомога
- допомогу
- допомагає
- тут
- його
- відбувся
- ГОДИННИК
- Як
- Однак
- HTTP
- HTTPS
- Ідентифікація
- if
- ілюструє
- зображення
- зображень
- імператив
- удосконалювати
- поліпшення
- in
- включені
- Augmenter
- зростаючий
- Інфраструктура
- притаманне
- початковий
- спочатку
- інноваційний
- розуміння
- встановлений
- екземпляр
- замість
- інструкції
- інтегрований
- інтеграція
- Інтелект
- інтерпретувати
- питання
- IT
- ітерація
- JPG
- просто
- тримає
- ключ
- Дитина
- етикетки
- відсутність
- великий
- Затримка
- запуск
- Керівництво
- Витоку
- вивчення
- найменш
- залишити
- рівень
- Важіль
- термін
- рамки
- загрузка
- місцевий
- Довго
- довше
- шукати
- низький
- машина
- навчання за допомогою машини
- підтримувати
- зробити
- РОБОТИ
- вдалося
- максимізація
- максимальний
- Може..
- вимір
- механізми
- середа
- Зустрічатися
- засідання
- пам'ять
- зливається
- метадані
- метал
- метрика
- Метрика
- мігрувати
- міграція
- мільйони
- мінімізація
- Місія
- ML
- модель
- Моделі
- монітори
- місяців
- більше
- множинний
- повинен
- ім'я
- Названий
- необхідно
- Необхідність
- необхідний
- Нові
- нещодавно
- немає
- вузол
- вузли
- роман
- номер
- численний
- Nvidia
- спостерігати
- отриманий
- of
- on
- On-Demand
- ONE
- тільки
- відкрити
- з відкритим вихідним кодом
- оператор
- Можливості
- оптимізація
- Оптимізувати
- оптимізований
- or
- Інше
- наші
- з
- над
- власний
- пацієнт
- pacientes
- в очікуванні
- для
- продуктивність
- виступає
- period
- місце
- платформа
- plato
- Інформація про дані Платона
- PlatoData
- точок
- Політика
- політика
- це можливо
- пошта
- Харчування
- потужний
- попередній
- передбачати
- представити
- первинний
- Головний
- Принципи
- приватний
- процес
- Оброблено
- обробка
- виробляти
- програма
- проект
- властивості
- Білок
- забезпечувати
- забезпечення
- повноваження
- громадськість
- мета
- запит
- швидко
- R
- реальний
- реального часу
- Причини
- зменшити
- знижує
- удосконалювати
- регіон
- покладатися
- залишається
- видаляти
- Вилучено
- видаляє
- видалення
- замінити
- відповідь
- запросити
- запитів
- вимагати
- вимагається
- Вимога
- Вимагається
- ресурс
- ресурси
- відповідальний
- зворотний
- право
- Роль
- корінь
- прогін
- біг
- то ж
- масштабовані
- шкала
- масштаб ai
- масштабний
- ваги
- Масштабування
- сценарій
- плановий
- планування
- Вчені
- scripts
- Пошук
- Грати короля карти - безкоштовно Nijumi логічна гра гри
- другий
- seconds
- розділ
- безпеку
- бачив
- семантика
- послати
- посилає
- сервер
- служить
- обслуговування
- Послуги
- виступаючої
- комплект
- установка
- осідає
- продемонстрований
- показаний
- Шоу
- істотно
- аналогічний
- спростити
- моделювання
- один
- Розмір
- невеликий
- менше
- згладити
- So
- Софтвер
- рішення
- Рішення
- деякі
- Source
- Простір
- специфікації
- зазначений
- дані
- швидкість
- Spot
- standard
- старт
- введення в експлуатацію
- стан
- заходи
- зупинений
- зберігання
- структура
- підмережі
- успіх
- такі
- достатній
- чудовий
- поставки
- підтримка
- Опори
- Переконайтеся
- SVC
- система
- таблиця
- приймає
- націлювання
- цілі
- команда
- Технології
- шаблон
- тензор
- Terraform
- ніж
- Що
- Команда
- Держава
- їх
- Їх
- потім
- терапевтичні засоби
- Там.
- тим самим
- Ці
- вони
- це
- тисячі
- поріг
- через
- пропускна здатність
- час
- times
- до
- прийняли
- інструменти
- топ
- Навчання
- правда
- два
- тип
- Типи
- типовий
- створеного
- безпрецедентний
- до
- час безвідмовної роботи
- терміново
- us
- використання
- використовуваний
- використання
- v1
- Цінності
- величезний
- різнобічний
- версія
- через
- обсяг
- Обсяги
- vs
- Уразливості
- покрокове керівництво
- хотів
- було
- we
- Web
- Веб-додаток
- веб-браузер
- веб-сервіси
- week
- ДОБРЕ
- були
- Що
- Що таке
- коли
- який
- в той час як
- ВООЗ
- волі
- з
- в
- Work
- робочий
- ямл
- Ти
- вашу
- зефірнет