Amazon SageMaker мультимодельні кінцеві точки (MME) є повністю керованою можливістю висновку SageMaker, яка дозволяє розгортати тисячі моделей на одній кінцевій точці. Раніше MME заздалегідь розподіляли обчислювальну потужність ЦП моделям статично незалежно від навантаження трафіку моделі, використовуючи Багатомодельний сервер (MMS) як модель сервера. У цій публікації ми обговорюємо рішення, у якому MME може динамічно регулювати обчислювальну потужність, призначену кожній моделі, на основі шаблону трафіку моделі. Це рішення дає змогу ефективніше використовувати базові обчислення MME та заощаджувати витрати.
MME динамічно завантажують і вивантажують моделі на основі вхідного трафіку до кінцевої точки. Використовуючи MMS як сервер моделі, MME виділяють фіксовану кількість робочих моделей для кожної моделі. Для отримання додаткової інформації див Моделювання шаблонів хостингу в Amazon SageMaker, частина 3: Запуск і оптимізація мультимодельного висновку за допомогою мультимодельних кінцевих точок Amazon SageMaker.
Однак це може призвести до кількох проблем, якщо ваш трафік змінюється. Припустімо, у вас є одна або кілька моделей, які отримують великий обсяг трафіку. Ви можете налаштувати MMS, щоб призначити велику кількість працівників для цих моделей, але це призначається всім моделям, що стоять за MME, оскільки це статична конфігурація. Це призводить до того, що велика кількість працівників використовує апаратні обчислення, навіть неактивні моделі. Зворотна проблема може статися, якщо ви встановите невелике значення для кількості працівників. Популярні моделі не матимуть достатньо працівників на рівні сервера моделі, щоб правильно розподілити достатньо апаратного забезпечення за кінцевою точкою для цих моделей. Основна проблема полягає в тому, що важко залишатися агностиком шаблону трафіку, якщо ви не можете динамічно масштабувати своїх працівників на рівні сервера моделі, щоб розподілити необхідний обсяг обчислень.
Рішення, яке ми обговорюємо в цій публікації, використовує DJLServing як модельний сервер, який може допомогти пом’якшити деякі проблеми, які ми обговорювали, увімкнути масштабування для кожної моделі та дозволити MME бути агностиком шаблонів трафіку.
Архітектура MME
MME SageMaker дозволяють розгортати кілька моделей за однією кінцевою точкою висновку, яка може містити один або більше екземплярів. Кожен екземпляр призначений для завантаження та обслуговування кількох моделей у межах об’єму пам’яті та ЦП/ГП. Завдяки цій архітектурі бізнес «програмне забезпечення як послуга» (SaaS) може подолати лінійно зростаючу вартість розміщення кількох моделей і досягти повторного використання інфраструктури відповідно до моделі багатокористування, що застосовується в інших частинах стеку програм. Наступна діаграма ілюструє цю архітектуру.
SageMaker MME динамічно завантажує моделі з Служба простого зберігання Amazon (Amazon S3) під час виклику замість завантаження всіх моделей під час першого створення кінцевої точки. У результаті початкове звернення до моделі може мати вищу затримку висновків, ніж наступні висновки, які завершуються з низькою затримкою. Якщо модель уже завантажено в контейнер під час виклику, тоді крок завантаження пропускається, і модель повертає висновки з низькою затримкою. Наприклад, припустимо, що у вас є модель, яка використовується лише кілька разів на день. Він автоматично завантажується на вимогу, тоді як моделі, до яких часто звертаються, зберігаються в пам’яті та викликаються з незмінно низькою затримкою.
За кожним MME стоять модельні екземпляри розміщення, як показано на наступній схемі. Ці екземпляри завантажують і видаляють кілька моделей до та з пам’яті на основі шаблонів трафіку до моделей.
SageMaker продовжує направляти запити на висновок для моделі до екземпляра, де модель уже завантажено, так що запити обслуговуються з кешованої копії моделі (див. наступну діаграму, на якій показано шлях запиту для першого запиту передбачення проти кешованого передбачення шлях запиту). Однак, якщо модель отримує багато запитів на виклик і є додаткові екземпляри для MME, SageMaker направляє деякі запити до іншого екземпляра, щоб врахувати збільшення. Щоб скористатися перевагами автоматичного масштабування моделі в SageMaker, переконайтеся, що у вас є налаштувати автоматичне масштабування екземпляра для надання додаткової потужності інстанції. Налаштуйте політику масштабування на рівні кінцевої точки за допомогою спеціальних параметрів або викликів за хвилину (рекомендовано), щоб додати більше екземплярів до парку кінцевих точок.
Огляд моделі сервера
Сервер моделей — це програмний компонент, який забезпечує середовище виконання для розгортання та обслуговування моделей машинного навчання (ML). Він діє як інтерфейс між навченими моделями та клієнтськими програмами, які хочуть робити прогнози за допомогою цих моделей.
Основна мета сервера моделей — забезпечити без зусиль інтеграцію та ефективне розгортання моделей ML у виробничих системах. Замість того, щоб вбудовувати модель безпосередньо в програму або певну структуру, сервер моделі забезпечує централізовану платформу, на якій можна розгортати, керувати та обслуговувати декілька моделей.
Моделі серверів зазвичай пропонують такі функції:
- Завантаження моделі – Сервер завантажує навчені моделі ML у пам’ять, готуючи їх до надання прогнозів.
- API висновків – Сервер надає API, який дозволяє клієнтським програмам надсилати вхідні дані та отримувати прогнози від розгорнутих моделей.
- Масштабування – Моделі серверів розроблені для обробки одночасних запитів від кількох клієнтів. Вони забезпечують механізми для паралельної обробки та ефективного керування ресурсами для забезпечення високої пропускної здатності та низької затримки.
- Інтеграція з серверними двигунами – Сервери моделей мають інтеграцію з серверними фреймворками, як-от DeepSpeed і FasterTransformer, для розділення великих моделей і виконання високооптимізованого висновку.
Архітектура DJL
Обслуговування DJL це високопродуктивний сервер універсальної моделі з відкритим кодом. Служба DJL створена на основі Djl, бібліотека глибокого навчання, написана мовою програмування Java. Він може взяти модель глибокого навчання, кілька моделей або робочих процесів і зробити їх доступними через кінцеву точку HTTP. Служба DJL підтримує розгортання моделей із багатьох фреймворків, таких як PyTorch, TensorFlow, Apache MXNet, ONNX, TensorRT, Hugging Face Transformers, DeepSpeed, FasterTransformer тощо.
DJL Serving пропонує багато функцій, які дозволяють розгортати ваші моделі з високою продуктивністю:
- Простота використання – Служба DJL може обслуговувати більшість моделей із коробки. Просто принесіть артефакти моделі, і DJL Serving зможе їх розмістити.
- Підтримка кількох пристроїв і прискорювачів – Служба DJL підтримує розгортання моделей на CPU, GPU та AWS Inferentia.
- продуктивність – Служба DJL запускає багатопотоковий висновок в одній JVM для підвищення пропускної здатності.
- Динамічне дозування – DJL Serving підтримує динамічне пакетування для збільшення пропускної здатності.
- Автоматичне масштабування – Обслуговування DJL буде автоматично масштабувати працівників відповідно до трафіку.
- Підтримка кількох двигунів – Служба DJL може одночасно розміщувати моделі за допомогою різних фреймворків (таких як PyTorch і TensorFlow).
- Моделі ансамблю та робочого процесу – Обслуговування DJL підтримує розгортання складних робочих процесів, що складаються з кількох моделей, і запускає частини робочого процесу на ЦП, а частини — на ГП. Моделі в робочому процесі можуть використовувати різні структури.
Зокрема, функція автоматичного масштабування DJL Serving дозволяє легко забезпечити відповідне масштабування моделей для вхідного трафіку. За замовчуванням DJL Serving визначає максимальну кількість працівників для моделі, яка може підтримуватися на основі доступного апаратного забезпечення (ядра ЦП, пристрої ГП). Ви можете встановити нижню та верхню межі для кожної моделі, щоб переконатися, що мінімальний рівень трафіку завжди може обслуговуватися та що одна модель не споживає всі доступні ресурси.
Служба DJL використовує a Нетті інтерфейс поверх пулів потоків бекенд-воркера. Інтерфейс використовує одну настройку Netty з кількома HttpRequestHandlers. Різні обробники запитів забезпечать підтримку для API висновків, API керуванняабо інші API, доступні з різних плагінів.
Сервер базується на WorkLoadManager (WLM). WLM піклується про декілька робочих потоків для кожної моделі разом із групуванням і маршрутизацією запитів до них. Коли обслуговується кілька моделей, WLM спочатку перевіряє розмір черги запитів на висновок для кожної моделі. Якщо розмір черги вдвічі перевищує розмір пакета моделі, WLM збільшує кількість працівників, призначених цій моделі.
Огляд рішення
Реалізація DJL з MME відрізняється від налаштування MMS за замовчуванням. Для обслуговування DJL з MME ми стискаємо такі файли у форматі model.tar.gz, який очікує SageMaker Inference:
- model.joblib – Для цієї реалізації ми безпосередньо надсилаємо метадані моделі в архів. У цьому випадку ми працюємо з а
.joblib
файл, тому ми надаємо цей файл у нашому архіві для читання нашим сценарієм висновків. Якщо артефакт завеликий, ви також можете передати його в Amazon S3 і вказати на нього в конфігурації обслуговування, яку ви визначаєте для DJL. - обслуговуючі.властивості – Тут ви можете налаштувати будь-яку модель, пов’язану з сервером змінні середовища. Потужність DJL тут полягає в тому, що ви можете налаштувати
minWorkers
таmaxWorkers
для кожної моделі архіву. Це дозволяє масштабувати кожну модель на рівні сервера моделей. Наприклад, якщо окрема модель отримує більшу частину трафіку для MME, сервер моделі буде динамічно масштабувати працівників. У цьому прикладі ми не налаштовуємо ці змінні й дозволяємо DJL визначати необхідну кількість працівників залежно від нашого шаблону трафіку. - model.py – Це сценарій висновку для будь-якої спеціальної попередньої або постобробки, яку ви бажаєте застосувати. Model.py очікує, що ваша логіка буде інкапсульована в методі ручки за замовчуванням.
- requirements.txt (необов'язково) – За замовчуванням DJL встановлюється разом із PyTorch, але будь-які додаткові залежності, які вам потрібні, можна додати сюди.
У цьому прикладі ми демонструємо потужність DJL з MME, взявши зразок моделі SKLearn. Ми проводимо навчальну роботу з цією моделлю, а потім створюємо 1,000 копій цього артефакту моделі для підтримки нашого MME. Потім ми демонструємо, як DJL може динамічно масштабуватися для обробки будь-якого типу трафіку, який може отримати ваш MME. Це може включати рівномірний розподіл трафіку між усіма моделями або навіть кількома популярними моделями, які отримують більшу частину трафіку. Ви можете знайти весь код нижче GitHub репо.
Передумови
У цьому прикладі ми використовуємо екземпляр блокнота SageMaker із ядром conda_python3 та екземпляр ml.c5.xlarge. Щоб виконати навантажувальні тести, ви можете використовувати an Обчислювальна хмара Amazon Elastic (Amazon EC2) або більший екземпляр ноутбука SageMaker. У цьому прикладі ми масштабуємо понад тисячу транзакцій за секунду (TPS), тому ми пропонуємо тестувати на більш важкому екземплярі EC2, такому як ml.c5.18xlarge, щоб у вас було більше обчислювальних ресурсів для роботи.
Створіть артефакт моделі
Спочатку нам потрібно створити артефакт моделі та дані, які ми використовуємо в цьому прикладі. Для цього випадку ми генеруємо деякі штучні дані за допомогою NumPy і навчаємося за допомогою моделі лінійної регресії SKLearn із таким фрагментом коду:
Після виконання попереднього коду у вас має бути a model.joblib
файл, створений у вашому локальному середовищі.
Витягніть образ DJL Docker
Образ Docker djl-inference:0.23.0-cpu-full-v1.0 — це наш контейнер для обслуговування DJL, який використовується в цьому прикладі. Ви можете налаштувати таку URL-адресу залежно від свого регіону:
inference_image_uri = "474422712127.dkr.ecr.us-east-1.amazonaws.com/djl-serving-cpu:latest"
За бажанням ви також можете використовувати це зображення як базове зображення та розширити його для створення власного образу Docker Реєстр контейнерів Amazon Elastic (Amazon ECR) з будь-якими іншими залежностями, які вам потрібні.
Створіть файл моделі
Спочатку ми створюємо файл під назвою serving.properties
. Це вказує DJLServing використовувати механізм Python. Ми також визначаємо max_idle_time
робочого 600 секунд. Це гарантує, що нам знадобиться більше часу, щоб зменшити кількість працівників, які мають на модель. Ми не підлаштовуємось minWorkers
та maxWorkers
які ми можемо визначити, і ми дозволяємо DJL динамічно обчислювати необхідну кількість працівників залежно від трафіку, який отримує кожна модель. Властивості serving.properties показано таким чином. Щоб переглянути повний список параметрів конфігурації, див Конфігурація двигуна.
Далі ми створюємо файл model.py, який визначає завантаження моделі та логіку висновку. Для MME кожен файл model.py є специфічним для моделі. Моделі зберігаються в окремих шляхах у сховищі моделей (зазвичай /opt/ml/model/
). Під час завантаження моделей вони завантажуватимуться під шляхом до магазину моделей у власному каталозі. Повний приклад model.py у цій демонстрації можна побачити в GitHub репо.
Ми створюємо model.tar.gz
файл, який містить нашу модель (model.joblib
), model.py
та serving.properties
:
Для демонстраційних цілей ми робимо 1,000 копій того самого model.tar.gz
файл для представлення великої кількості моделей, які будуть розміщені. У виробництві вам потрібно створити a model.tar.gz
файл для кожної вашої моделі.
Нарешті, ми завантажуємо ці моделі на Amazon S3.
Створіть модель SageMaker
Тепер ми створюємо a Модель SageMaker. Ми використовуємо зображення ECR, визначене раніше, і артефакт моделі з попереднього кроку для створення моделі SageMaker. У налаштуваннях моделі ми налаштовуємо Mode як MultiModel. Це повідомляє DJLServing, що ми створюємо MME.
Створіть кінцеву точку SageMaker
У цій демонстрації ми використовуємо 20 екземплярів ml.c5d.18xlarge для масштабування до TPS у діапазоні тисяч. Переконайтеся, що ви збільшили ліміт для свого типу екземпляра, якщо це необхідно, щоб досягти TPS, який ви націлюєте.
Тестування навантаженням
На момент написання статті це був власний інструмент навантажувального тестування SageMaker Amazon SageMaker Inference Recommender не підтримує тестування для MME. Тому ми використовуємо інструмент Python з відкритим кодом сарана. Locust простий у налаштуванні та може відстежувати такі показники, як TPS і наскрізна затримка. Для повного розуміння того, як налаштувати його за допомогою SageMaker, див Найкращі методи навантажувального тестування кінцевих точок висновку в реальному часі Amazon SageMaker.
У цьому випадку використання ми маємо три різні шаблони трафіку, які ми хочемо імітувати за допомогою MME, тому ми маємо наступні три сценарії Python, які відповідають кожному шаблону. Наша мета тут — довести, що, незважаючи на структуру нашого трафіку, ми можемо досягти однакової цільової TPS і належним чином масштабувати.
Ми можемо вказати вагу в нашому сценарії Locust, щоб призначити трафік між різними частинами наших моделей. Наприклад, у нашій одній гарячій моделі ми реалізуємо два методи:
Тоді ми можемо призначити певну вагу кожному методу, коли певний метод отримує певний відсоток трафіку:
Для 20 екземплярів ml.c5d.18xlarge ми бачимо такі показники виклику на Amazon CloudWatch консоль. Ці значення залишаються досить постійними для всіх трьох моделей трафіку. Щоб краще зрозуміти показники CloudWatch для висновків SageMaker у реальному часі та MME, див Метрики виклику кінцевої точки SageMaker.
Ви можете знайти решту сценаріїв Locust у каталог locust-utils у сховищі GitHub.
Підсумки
У цій публікації ми обговорили, як MME може динамічно регулювати обчислювальну потужність, призначену кожній моделі, на основі шаблону трафіку моделі. Ця нещодавно запущена функція доступна в усіх регіонах AWS, де доступний SageMaker. Зауважте, що на момент оголошення підтримуються лише екземпляри ЦП. Щоб дізнатися більше, зверніться до Підтримувані алгоритми, фреймворки та екземпляри.
Про авторів
Рам Вегіражу є архітектором ML у команді SageMaker Service. Він зосереджується на допомозі клієнтам створювати й оптимізувати свої рішення AI/ML на Amazon SageMaker. У вільний час любить подорожувати та писати.
Цінвей Лі є спеціалістом з машинного навчання в Amazon Web Services. Отримав ступінь доктора філософії. в дослідженні операцій після того, як він зламав грантовий рахунок свого радника і не вручив обіцяну Нобелівську премію. Зараз він допомагає клієнтам у сфері фінансових послуг і страхування створювати рішення машинного навчання на AWS. У вільний час любить читати та викладати.
Джеймс Ву є старшим архітектором рішень для AI/ML у AWS. допомога клієнтам у проектуванні та створенні рішень AI/ML. Робота Джеймса охоплює широкий спектр випадків використання машинного машинного навчання, з головним інтересом до комп’ютерного зору, глибокого навчання та масштабування машинного машинного навчання на підприємстві. До того, як приєднатися до AWS, Джеймс був архітектором, розробником і технологічним лідером понад 10 років, у тому числі 6 років у галузі інженерії та 4 роки в галузі маркетингу та реклами.
Саураб Тріканде є старшим менеджером із продуктів Amazon SageMaker Inference. Він захоплений роботою з клієнтами та мотивований метою демократизації машинного навчання. Він зосереджується на основних проблемах, пов’язаних із розгортанням складних програм ML, моделями ML з кількома клієнтами, оптимізацією витрат і забезпеченням більшої доступності розгортання моделей глибокого навчання. У вільний час Саураб любить піші прогулянки, вивчає інноваційні технології, стежить за TechCrunch і проводить час із сім’єю.
Сюй Ден є менеджером інженера-програміста в команді SageMaker. Він зосереджується на допомозі клієнтам створювати та оптимізувати їхній досвід штучного інтелекту/ML на Amazon SageMaker. У вільний час він любить подорожувати та кататися на сноуборді.
Сіддхарт Венкатесан є розробником програмного забезпечення в AWS Deep Learning. Зараз він зосереджується на розробці рішень для виведення великих моделей. До AWS він працював в організації Amazon Grocery, розробляючи нові платіжні функції для клієнтів у всьому світі. Поза роботою він любить кататися на лижах, гуляти на природі та дивитися спортивні змагання.
Рохіт Налламадді є інженером з розробки програмного забезпечення в AWS. Він працює над оптимізацією робочих навантажень глибокого навчання на графічних процесорах, створенням високопродуктивних рішень для логічного моделювання та обслуговування. До цього він працював над створенням мікросервісів на базі AWS для бізнесу Amazon F3. Поза роботою любить грати та дивитися спорт.
- Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
- PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
- PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
- ПлатонЕСГ. вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
- PlatoHealth. Розвідка про біотехнології та клінічні випробування. Доступ тут.
- джерело: https://aws.amazon.com/blogs/machine-learning/run-ml-inference-on-unplanned-and-spiky-traffic-using-amazon-sagemaker-multi-model-endpoints/
- :є
- :де
- $UP
- 000
- 1
- 10
- 100
- 116
- 118
- 12
- 16
- 17
- 20
- 23
- 31
- 600
- 7
- 9
- a
- МЕНЮ
- прискорювач
- доступний
- доступною
- розмістити
- рахунки
- Achieve
- через
- акти
- додавати
- Додатковий
- Перевага
- реклама
- після
- AI / ML
- алгоритми
- вирівнювати
- ВСІ
- виділяти
- виділено
- дозволяти
- дозволяє
- по
- вже
- Також
- завжди
- Amazon
- Amazon EC2
- Amazon SageMaker
- Amazon Web Services
- кількість
- an
- та
- Оголошення
- Інший
- будь-який
- Apache
- API
- Інтерфейси
- додаток
- застосування
- прикладної
- відповідним чином
- архітектура
- ЕСТЬ
- навколо
- штучний
- AS
- призначений
- припустити
- At
- автоматичний
- Автоматизований
- автоматично
- доступний
- AWS
- назад
- Backend
- база
- заснований
- дозування
- BE
- оскільки
- за
- Краще
- між
- тіло
- підвищення
- межі
- Box
- Перерва
- приносити
- Зламав
- будувати
- Створюємо
- побудований
- бізнес
- але
- by
- званий
- CAN
- можливості
- потужність
- який
- випадок
- випадків
- осередок
- централізована
- певний
- проблеми
- Перевірки
- клас
- клієнт
- клієнтів
- код
- приходить
- повний
- Зроблено
- комплекс
- компонент
- У складі
- обчислення
- комп'ютер
- Комп'ютерне бачення
- обчислення
- обчислювальна потужність
- одночасно
- конфігурація
- послідовний
- послідовно
- Консоль
- споживати
- містити
- Контейнер
- контекст
- триває
- Core
- Коштувати
- витрати
- Обкладинки
- створювати
- створений
- створення
- В даний час
- виготовлений на замовлення
- Клієнти
- дані
- день
- глибокий
- глибоке навчання
- дефолт
- визначати
- певний
- Визначає
- доставляти
- Попит
- демонстрація
- Демократизувати
- залежно
- Залежно
- зображено
- розгортання
- розгорнути
- розгортання
- розгортання
- дизайн
- призначений
- Визначати
- визначає
- Розробник
- розробка
- пристрій
- прилади
- схема
- різний
- важкий
- безпосередньо
- каталог
- обговорювати
- обговорювалися
- розподіл
- Docker
- Ні
- Не знаю
- вниз
- скачати
- Завантаження
- динамічний
- динамічно
- кожен
- Раніше
- ефективний
- продуктивно
- без зусиль
- або
- в іншому місці
- вбудовування
- включіть
- дозволяє
- інкапсульований
- кінець в кінець
- Кінцева точка
- двигун
- інженер
- Машинобудування
- досить
- забезпечувати
- підприємство
- Навколишнє середовище
- помилка
- Навіть
- приклад
- виняток
- очікував
- чекає
- досвід
- продовжити
- Face
- не вдалося
- достатньо
- сім'я
- особливість
- риси
- кілька
- філе
- Файли
- фінансовий
- фінансова служба
- знайти
- Перший
- фіксованою
- ФЛЕТ
- фокусується
- після
- слідує
- для
- формат
- Рамки
- каркаси
- часто
- від
- Frontend
- Повний
- повністю
- функціональні можливості
- породжувати
- отримати
- отримує
- GitHub
- мета
- GPU
- Графічні процесори
- надавати
- великий
- обробляти
- траплятися
- апаратні засоби
- Мати
- he
- допомога
- допомогу
- допомагає
- тут
- Високий
- вище
- дуже
- його
- господар
- відбувся
- хостинг
- ГАРЯЧА
- Як
- How To
- Однак
- HTML
- HTTP
- HTTPS
- Idle
- if
- ілюструє
- зображення
- здійснювати
- реалізація
- імпорт
- in
- включати
- includes
- У тому числі
- Вхідний
- Augmenter
- зростаючий
- промисловості
- промисловість
- інформація
- Інфраструктура
- початковий
- інноваційний
- інноваційні технології
- вхід
- встановлений
- екземпляр
- замість
- страхування
- інтеграція
- інтеграцій
- інтерес
- інтерфейс
- в
- викликали
- питання
- питання
- IT
- ЙОГО
- Джеймс
- Java
- робота
- приєднання
- JPG
- просто
- мова
- великий
- більше
- Затримка
- останній
- запущений
- вести
- лідер
- Веде за собою
- УЧИТЬСЯ
- вивчення
- дозволяти
- рівень
- бібліотека
- як
- Сподобалося
- МЕЖА
- лінійний
- список
- загрузка
- погрузка
- вантажі
- місцевий
- логіка
- довше
- любить
- низький
- знизити
- машина
- навчання за допомогою машини
- головний
- Більшість
- зробити
- РОБОТИ
- Робить
- вдалося
- менеджер
- управління
- багато
- Маркетинг
- Маркетинг та реклама
- максимальний
- Може..
- механізми
- пам'ять
- метадані
- метод
- методика
- Метрика
- мікросервіс
- може бути
- мінімальний
- хвилин
- Пом'якшити
- ML
- режим
- модель
- Моделі
- Модулі
- більше
- найбільш
- мотивовані
- множинний
- ім'я
- спочатку
- необхідно
- Необхідність
- необхідний
- Нові
- нещодавно
- Нобелівська премія
- ніхто
- увагу
- ноутбук
- зараз
- номер
- нумпі
- of
- пропонувати
- Пропозиції
- on
- ONE
- тільки
- відкрити
- з відкритим вихідним кодом
- операції
- протилежний
- оптимізації
- Оптимізувати
- оптимізований
- оптимізуючий
- Опції
- or
- Інше
- наші
- з
- на відкритому повітрі
- вихід
- поза
- над
- власний
- Паралельні
- параметри
- частина
- приватність
- частини
- пристрасний
- шлях
- стежки
- Викрійки
- моделі
- оплата
- для
- відсоток
- Виконувати
- продуктивність
- труба
- платформа
- plato
- Інформація про дані Платона
- PlatoData
- ігри
- plugins
- точка
- політика
- Басейни
- популярний
- пошта
- влада
- практики
- попередній
- прогноз
- Прогнози
- попередній
- раніше
- первинний
- попередній
- приз
- Проблема
- процес
- обробка
- Product
- менеджер по продукції
- Production
- Програмування
- пообіцяв
- правильно
- властивості
- Доведіть
- забезпечувати
- забезпечує
- забезпечення
- мета
- цілей
- Штовхати
- штовхнув
- Python
- піторх
- випадковий
- діапазон
- Читати
- читання
- готовий
- реального часу
- отримати
- отримано
- отримує
- отримання
- рекомендований
- послатися
- Незалежно
- регіон
- райони
- пов'язаний
- залишатися
- замінювати
- Сховище
- представляти
- запросити
- запитів
- Вимога
- дослідження
- ресурси
- відповідь
- REST
- результат
- Умови повернення
- знову використовувати
- Маршрут
- маршрути
- Маршрутизація
- прогін
- пробіжки
- час виконання
- SaaS
- мудрець
- Висновок SageMaker
- то ж
- зразок
- зберегти
- say
- шкала
- масштабний
- ваги
- Масштабування
- сценарій
- scripts
- другий
- seconds
- побачити
- бачив
- SELF
- послати
- старший
- служити
- служив
- сервер
- Сервери
- обслуговування
- Послуги
- виступаючої
- комплект
- набори
- установка
- кілька
- Повинен
- демонстрації
- показаний
- Шоу
- простий
- імітувати
- одночасно
- один
- особливий
- Розмір
- невеликий
- уривок
- So
- Софтвер
- програмне забезпечення як послуга
- розробка програмного забезпечення
- Інженер-програміст
- рішення
- Рішення
- деякі
- Source
- спеціаліст
- конкретний
- Витрати
- розкол
- SPORTS
- стек
- статичний
- Крок
- зберігання
- зберігати
- зберігати
- просто
- наступні
- такі
- пропонувати
- підтримка
- Підтриманий
- Опори
- Переконайтеся
- Systems
- Приймати
- приймає
- взяття
- Мета
- націлювання
- Навчання
- команда
- TechCrunch
- Технології
- Технологія
- розповідає
- тензорний потік
- Тестування
- Тести
- ніж
- Що
- Команда
- їх
- Їх
- потім
- Там.
- отже
- Ці
- вони
- це
- ті
- тисяча
- тисячі
- три
- через
- пропускна здатність
- час
- times
- до
- занадто
- інструмент
- топ
- до
- TPS
- трек
- трафік
- поїзд
- навчений
- Навчання
- Transactions
- Трансформатори
- Подорож
- намагатися
- два
- тип
- типово
- при
- що лежить в основі
- розуміти
- розуміння
- Universal
- URL
- використання
- використання випадку
- використовуваний
- використовує
- використання
- зазвичай
- використовує
- значення
- Цінності
- змінна
- різний
- бачення
- vs
- хотіти
- було
- спостереження
- we
- Web
- веб-сервіси
- вага
- Що
- коли
- в той час як
- який
- широкий
- Широкий діапазон
- волі
- з
- в
- Work
- працював
- робочий
- робочі
- робочий
- Робочі процеси
- робочий
- працює
- б
- лист
- письмовий
- X
- років
- Ти
- вашу
- зефірнет