Як розгортати моделі штучного інтелекту

Як розгортати моделі штучного інтелекту

Коротка відповідь: розгортання моделі штучного інтелекту означає вибір шаблону обслуговування (у режимі реального часу, пакетна, потокова або на периферії), а потім забезпечення відтворюваності, спостереження, безпеки та зворотності всього шляху. Коли ви перевіряєте версії всього та тестуєте затримку p95/p99 на робочих навантаженнях, подібних до робочих, ви уникаєте більшості збоїв, пов'язаних з проблемою «працює на моєму ноутбуці».

Ключові висновки:

Шаблони розгортання: оберіть режим реального часу, пакетне розгортання, потокове розгортання або розгортання на периферії, перш ніж переходити на інструменти.

Відтворюваність: Версіонування моделі, функцій, коду та середовища для запобігання дрейфу.

Спостережуваність: Постійний моніторинг хвостів затримки, помилок, насичення та розподілів даних або виводу.

Безпечне розгортання: використовуйте канареєчне, синьо-зелене або тіньове тестування з автоматичними порогами відкату.

Безпека та конфіденційність: Застосовуйте автентифікацію, обмеження швидкості та керування секретами, а також мінімізуйте кількість ідентифікаційних даних у журналах.

Як розгортати моделі штучного інтелекту? Інфографіка

Статті, які вам, можливо, буде цікаво прочитати після цієї: 

🔗 Як виміряти продуктивність ШІ
Вивчайте метрики, бенчмарки та реальні перевірки для отримання надійних результатів ШІ.

🔗 Як автоматизувати завдання за допомогою штучного інтелекту
Перетворіть повторювану роботу на робочі процеси за допомогою підказок, інструментів та інтеграцій.

🔗 Як тестувати моделі штучного інтелекту
Розробляйте оцінки, набори даних та оцінювання для об'єктивного порівняння моделей.

🔗 Як розмовляти зі штучним інтелектом
Ставте кращі запитання, встановлюйте контекст і швидко отримуйте чіткіші відповіді.

1) Що насправді означає «розгортання» (і чому це не просто API) 🧩

Коли люди кажуть «розгорнути модель», вони можуть мати на увазі будь-що з цього:

Отже, розгортання — це не стільки «зробити модель доступною», скільки:

Це щось на кшталт відкриття ресторану. Приготувати смачну страву – це, звісно, ​​важливо. Але вам все одно потрібні будівля, персонал, охолодження, меню, ланцюг поставок і спосіб впоратися з ажіотажем за вечерею, не плачучи в морозильній камері. Не ідеальна метафора… але ви розумієте. 🍝

2) Що робить версію «Як розгортати моделі штучного інтелекту» гарною ✅

«Гарне розгортання» — це нудне в найкращому сенсі. Воно поводиться передбачувано під тиском, а коли ні, це можна швидко діагностувати.

Ось як зазвичай виглядає слово «добре»:

  • Відтворювані збірки
    Той самий код + ті самі залежності = та сама поведінка. Жодних моторошних натяків на «працює на моєму ноутбуці» 👻 ( Docker: Що таке контейнер? )

  • Чіткий інтерфейсний контракт.
    Вхідні дані, вихідні дані, схеми та граничні випадки визначені. Жодних несподіваних типів о 2-й годині ночі. ( OpenAPI: Що таке OpenAPI?, JSON Schema )

  • Продуктивність, що відповідає реальності.
    Затримка та пропускна здатність вимірюються на обладнанні, подібному до виробничого, та з реалістичними корисними навантаженнями.

  • Моніторинг за допомогою зубів.
    Метрики, журнали, трасування та перевірки дрейфу, які запускають дії (не лише панелі інструментів, які ніхто не відкриває). ( Книга SRE: Моніторинг розподілених систем )

  • Стратегія безпечного розгортання.
    Канарський або синьо-зелений варіант, легке відкатування, керування версіями, яке не потребує «молитва». ( Випуск Canary , синьо-зелене розгортання ).

  • Усвідомлення витрат.
    «Швидко» – це чудово, поки рахунок не виглядає як номер телефону 📞💸

  • Безпека та конфіденційність, забезпечені
    управлінням секретами, контролем доступу, обробкою ідентифікаційних даних та аудитністю. ( Секрети Kubernetes , NIST SP 800-122 )

Якщо ви можете робити це послідовно, ви вже випереджаєте більшість команд. Будемо відверті.

3) Виберіть правильний шаблон розгортання (перед тим, як вибрати інструменти) 🧠

Виведення API в режимі реального часу ⚡

Найкраще, коли:

  • користувачам потрібні миттєві результати (рекомендації, перевірки на шахрайство, чат, персоналізація)

  • рішення мають прийматися під час запиту

Обережно:

Пакетне підрахунок балів 📦

Найкраще, коли:

  • прогнози можуть бути затримані (оцінка ризику протягом ночі, прогнозування відтоку, збагачення ETL) ( пакетне перетворення Amazon SageMaker )

  • ви хочете економічної ефективності та простішої експлуатації

Обережно:

  • актуальність даних та зворотні заповнення

  • забезпечення узгодженості логіки функцій з навчанням

Потоковий висновок 🌊

Найкраще, коли:

  • ви безперервно обробляєте події (IoT, кліки, системи моніторингу)

  • ви хочете приймати рішення майже в режимі реального часу без суворого зв'язку між запитами та відповідями

Обережно:

Розгортання на периферії 📱

Найкраще, коли:

  • низька затримка без залежності від мережі ( LiteRT на пристрої )

  • обмеження конфіденційності

  • офлайн-середовища

Обережно:

Спочатку виберіть шаблон, а потім стек. Інакше ви змусите квадратну модель працювати в круглому середовищі виконання. Або щось подібне. 😬

4) Упаковка моделі, щоб вона витримала контакт з виробництвом 📦🧯

Саме тут більшість «простих розгортань» тихо помирають.

Версія всього (так, всього)

  • Артефакт моделі (ваги, графік, токенізатор, карти міток)

  • Логіка ознак (перетворення, нормалізація, кодери)

  • Код виведення (до/після обробки)

  • Середовище (Python, CUDA, системні бібліотеки)

Простий підхід, який працює:

  • ставитися до моделі як до артефакту випуску

  • зберігати його з тегом версії

  • потрібен файл метаданих, схожий на картку моделі: схема, метрики, примітки до знімків навчальних даних, відомі обмеження ( картки моделей для звітності про моделі )

Контейнери допомагають, але не поклоняйтеся їм 🐳

Контейнери чудові, тому що вони:

Але вам все одно потрібно керувати:

  • оновлення базових зображень

  • Сумісність драйверів графічного процесора

  • сканування безпеки

  • розмір зображення (нікому не подобаються 9 ГБ «привіт, світ») ( найкращі практики збірки Docker )

Стандартизуйте інтерфейс

Заздалегідь визначте формат введення/виведення:

  • JSON для простоти (повільніший, але зручніший) ( JSON Schema )

  • Protobuf для підвищення продуктивності ( огляд буферів протоколів )

  • корисні навантаження на основі файлів для зображень/аудіо (плюс метадані)

І, будь ласка, перевірте вхідні дані. Недійсні вхідні дані є основною причиною запитів на помилку «чому повертається нісенітниця». ( OpenAPI: Що таке OpenAPI?, JSON Schema )

5) Варіанти обслуговування — від «простого API» до повноцінних серверів моделей 🧰

Існує два поширених маршрути:

Варіант A: Сервер додатків + код виводу (підхід у стилі FastAPI) 🧪

Ви пишете API, який завантажує модель та повертає прогнози. ( FastAPI )

Плюси:

  • легко налаштувати

  • чудово підходить для простіших моделей або продуктів на ранніх стадіях

  • проста автентифікація, маршрутизація та інтеграція

Мінуси:

  • ви самі налаштовуєте продуктивність (пакетування, потоки, використання графічного процесора)

  • ти винайдеш колеса заново, можливо, спочатку погано

Варіант B: Модельний сервер (підхід у стилі TorchServe / Triton) 🏎️

Спеціалізовані сервери, що обслуговують:

Плюси:

  • кращі моделі продуктивності одразу після встановлення

  • чіткіше розділення між обслуговуванням та бізнес-логікою

Мінуси:

  • додаткова операційна складність

  • налаштування може здаватися… складним, як регулювання температури душу

Гібридний візерунок є надзвичайно поширеним:

6) Порівняльна таблиця – популярні способи розгортання (з чесними настроями) 📊😌

Нижче наведено практичний огляд варіантів, які люди насправді використовують, коли з'ясовують, як розгортати моделі штучного інтелекту .

Інструмент / Підхід Аудиторія Ціна Чому це працює
Docker + FastAPI (або подібний) Невеликі команди, стартапи Вільний Простий, гнучкий, швидкий у постачанні — ви «відчуєте» кожну проблему масштабування ( Docker , FastAPI )
Kubernetes (самостійне створення) Команди платформи Інфразалежний Керування + масштабованість… також, багато ручок, деякі з них прокляті ( Kubernetes HPA )
Керована платформа машинного навчання (хмарний сервіс машинного навчання) Команди, які хочуть менше операцій Платіть по мірі використання Вбудовані робочі процеси розгортання, перехоплювачі моніторингу – іноді дорогі для постійно увімкнених кінцевих точок ( розгортання Vertex AI , виведення в реальному часі в SageMaker )
Безсерверні функції (для легкого виведення) Програми, керовані подіями Оплата за використання Чудово підходить для гострих заторів, але холодний запуск та розмір моделі можуть зіпсувати вам день 😬 ( холодний запуск AWS Lambda )
Сервер виводу NVIDIA Triton Команди, орієнтовані на продуктивність Безкоштовне програмне забезпечення, вартість інфраструктури Відмінне використання графічного процесора, пакетна обробка, багатомодельність - конфігурація вимагає терпіння ( Triton: Динамічне пакетне оброблення )
TorchServe Команди з великим навантаженням на PyTorch Безкоштовне програмне забезпечення Пристойні шаблони обслуговування за замовчуванням — можливо, знадобиться налаштування для високого масштабування ( документація TorchServe )
BentoML (упаковка + подача) Інженери машинного навчання Безкоштовне ядро, додаткові опції різняться Гладка упаковка, приємний досвід розробника — вам все ще потрібні варіанти інфраструктури ( пакет BentoML для розгортання )
Рей Серв Фахівці з розподілених систем Інфразалежний Масштабується горизонтально, добре для конвеєрів — відчувається «великим» для крихітних проектів ( документація Ray Serve )

Примітка до столу: «Безкоштовно-просто» – це термінологія з реального життя. Бо безкоштовного ніколи не буває. Завжди десь є рахунок, навіть якщо це ваш сон. 😴

7) Продуктивність та масштабування — затримка, пропускна здатність та правда 🏁

Налаштування продуктивності – це процес, коли розгортання стає майстерністю. Мета не «швидко». Мета – стабільно достатньо швидко .

Ключові показники, що мають значення

Звичайні важелі для потягування

  • Пакетна обробка.
    Об'єднання запитів для максимального використання графічного процесора. Чудово підходить для пропускної здатності, але може призвести до зниження затримки, якщо перестаратися. ( Triton: Динамічне пакетування ).

  • Квантування.
    Нижча точність (як у INT8) може пришвидшити висновок і зменшити обсяг пам'яті. Може дещо погіршити точність. Іноді ні, що дивно. ( Квантування після навчання ).

  • Компіляція/оптимізація
    експорту ONNX, оптимізатори графів, потоки, подібні до TensorRT. Потужно, але налагодження може бути складним 🌶️ ( ONNX , оптимізація моделі ONNX Runtime )

  • Кешування.
    Якщо вхідні дані повторюються (або ви можете кешувати вбудовані дані), ви можете значно заощадити.

  • Автоматичне
    масштабування. Масштабування залежить від використання процесора/графічного процесора, глибини черги або частоти запитів. Глибина черги недооцінена. ( Kubernetes HPA )

Дивна, але правдива порада: вимірюйте з розмірами корисного навантаження, подібними до виробничих. Крихітні тестові корисні навантаження вам брешуть. Вони чемно посміхаються, а потім зраджують вас.

8) Моніторинг та спостережливість – не літайте наосліп 👀📈

Моніторинг моделі – це не просто моніторинг безвідмовної роботи. Ви хочете знати, чи:

Що слід контролювати (мінімальний життєздатний набір)

Стан служби

Поведінка моделі

  • розподіл вхідних ознак (базова статистика)

  • норми вбудовування (для моделей вбудовування)

  • розподіл результатів (впевненість, склад класів, діапазони балів)

  • виявлення аномалій на входах (сміття на вході, сміття на виході)

Дрейф даних та дрейф концепцій

Ведення журналу, але не підхід «реєструвати все назавжди» 🪵

Журнал:

  • ідентифікатори запитів

  • версія моделі

  • результати перевірки схеми ( OpenAPI: Що таке OpenAPI? )

  • мінімальні структуровані метадані корисного навантаження (не необроблені персональні дані) ( NIST SP 800-122 )

Будьте обережні з конфіденційністю. Ви ж не хочете, щоб ваші журнали стали місцем витоку даних. ( NIST SP 800-122 )

9) Стратегії CI/CD та впровадження – ставтеся до моделей як до справжніх релізів 🧱🚦

Якщо вам потрібні надійні розгортання, створіть конвеєр. Навіть простий.

Суцільний потік

  • Модульні тести для попередньої та постобробки

  • Інтеграційний тест із відомим «золотим набором» вхідних-вихідних даних

  • Базовий рівень навантажувального тесту (навіть полегшеного)

  • Збірка артефакту (контейнер + модель) ( найкращі практики збірки Docker )

  • Розгортання до проміжної версії

  • Випуск Canary для невеликої частини трафіку ( Випуск Canary )

  • Поступово збільшуйте

  • Автоматичне відкати на ключові пороги ( синьо-зелене розгортання )

Шаблони розгортання, які рятують ваш здоровий глузд

  • Canary : спочатку реліз для 1-5% трафіку ( реліз Canary )

  • Синьо-зелений : запускати нову версію разом зі старою, перевертати, коли буде готове ( Синьо-зелене розгортання )

  • Тіньове тестування : надсилайте реальний трафік до нової моделі, але не використовуйте результати (чудово підходить для оцінки) ( Microsoft: Тіньове тестування )

І версіонуйте свої кінцеві точки або маршрути за версією моделі. Майбутнє вам подякує. Поточне також вам подякує, але тихо.

10) Безпека, конфіденційність та «будь ласка, не розголошуйте інформацію» 🔐🙃

Охорона має звичку з'являтися пізно, як непроханий гість. Краще запросити її раніше.

Практичний контрольний список

  • Аутентифікація та авторизація (хто може викликати модель?)

  • Обмеження швидкості (захист від зловживань та випадкових штормів) ( дроселювання API Gateway )

  • Керування секретами (немає ключів у коді, немає ключів у конфігураційних файлах також…) ( AWS Secrets Manager , Kubernetes Secrets )

  • Мережеві елементи керування (приватні підмережі, політики взаємодії між службами)

  • Журнали аудиту (особливо для конфіденційних прогнозів)

  • Мінімізація даних (зберігайте лише необхідну кількість даних) ( NIST SP 800-122 )

Якщо модель стосується персональних даних:

  • ідентифікатори редагування або хешування

  • уникати реєстрації необроблених корисних навантажень ( NIST SP 800-122 )

  • визначити правила зберігання

  • потік даних документів (нудно, але захисно)

Також, швидке впровадження та зловживання виводом можуть мати значення для генеративних моделей. Додайте: ( OWASP Top 10 for LLM Applications , OWASP: Швидке впровадження )

  • правила санітарної обробки вхідних даних

  • фільтрація виходу, де це доречно

  • захист для виклику інструментів або дій з базою даних

Жодна система не є ідеальною, але ви можете зробити її менш крихкою.

11) Поширені підводні камені (тобто звичайні пастки) 🪤

Ось класика:

  • Перекіс під час навчання та обслуговування.
    Попередня обробка відрізняється під час навчання та виробництва. Раптово точність падає, і ніхто не знає чому. ( Валідація даних TensorFlow: виявлення перекісу під час навчання )

  • Відсутність перевірки схеми.
    Одна зміна в початковому коді ламає все. І не завжди гучно… ( JSON Schema , OpenAPI: Що таке OpenAPI? )

  • Ігнорування затримки хвоста
    p99 – це те, де користувачі живуть, коли вони зляться. ( Хвіст у масштабі )

  • Забути про витрати,
    коли кінцеві точки GPU працюють у режимі очікування, це як залишити все світло увімкненим у вашому будинку, але лампочки зроблені з грошей.

  • Без плану скорочення.
    «Ми просто передислокуємо» – це не план. Це надія в плащі. ( Синьо-зелене розгортання ).

  • Моніторинг лише часу безвідмовної роботи.
    Сервіс може працювати, навіть коли модель неправильна. Це, можливо, ще гірше. ( Vertex AI: Monitor feature skew and drift , Amazon SageMaker Model Monitor )

Якщо ви читаєте це і думаєте: «Так, ми робимо два таких», ласкаво просимо до клубу. У клубі є закуски та легкий стрес. 🍪

12) Підсумок - Як розгортати моделі штучного інтелекту, не втрачаючи глузду 😄✅

Розгортання – це те, де ШІ стає реальним продуктом. Це не гламурно, але саме так заробляється довіра.

Короткий огляд

І так, спочатку « Як розгортати моделі штучного інтелекту»

Найчастіші запитання

Що означає розгортання моделі штучного інтелекту у виробництві

Розгортання моделі штучного інтелекту зазвичай включає набагато більше, ніж просто розкриття API прогнозування. На практиці це включає пакування моделі та її залежностей, вибір шаблону обслуговування (в режимі реального часу, пакетне, потокове або на периферії), масштабування з урахуванням надійності, моніторинг справності та дрейфу, а також налаштування безпечних шляхів розгортання та відкату. Надійне розгортання залишається передбачувано стабільним під навантаженням і залишається діагностованим, якщо щось піде не так.

Як вибрати між розгортанням у режимі реального часу, пакетним, потоковим або периферійним розгортанням

Оберіть шаблон розгортання на основі того, коли потрібні прогнози, та обмежень, з якими ви працюєте. API реального часу підходять для інтерактивного досвіду, де важлива затримка. Пакетна оцінка працює найкраще, коли затримки прийнятні, а економічна ефективність переважає. Потокове передавання підходить для безперервної обробки подій, особливо коли семантика доставки стає складною. Розгортання на периферії ідеально підходить для роботи в автономному режимі, конфіденційності або вимог до наднизької затримки, хоча оновлення та варіації обладнання стають складнішими в управлінні.

Яку версію встановити, щоб уникнути помилок розгортання, які працюють на моєму ноутбуці

Версія – це більше, ніж просто вагові коефіцієнти моделі. Зазвичай вам потрібен артефакт моделі з версіями (включаючи токенізатори або карти міток), логіка попередньої обробки та функцій, код виведення та повне середовище виконання (бібліотеки Python/CUDA/системи). Розглядайте модель як артефакт випуску з тегами версій та легкими метаданими, що описують очікування схеми, нотатки щодо оцінки та відомі обмеження.

Чи розгортати за допомогою простого сервісу в стилі FastAPI, чи за допомогою виділеного сервера моделей

Простий сервер додатків (підхід у стилі FastAPI) добре працює для ранніх продуктів або простих моделей, оскільки ви зберігаєте контроль над маршрутизацією, автентифікацією та інтеграцією. Сервер моделей (у стилі TorchServe або NVIDIA Triton) може забезпечити кращу пакетну обробку, паралельність та ефективність графічного процесора одразу після встановлення. Багато команд обирають гібрид: сервер моделей для логічного висновку плюс тонкий шар API для автентифікації, формування запитів та обмежень швидкості.

Як покращити затримку та пропускну здатність без порушення точності

Почніть з вимірювання затримки p95/p99 на обладнанні, подібному до продакшн-версії, з реалістичними корисними навантаженнями, оскільки невеликі тести можуть вводити в оману. Звичайні засоби включають пакетну роботу (краща пропускна здатність, потенційно нижча затримка), квантування (менше та швидше, іноді з незначними компромісами в точності), потоки компіляції та оптимізації (подібні до ONNX/TensorRT) та кешування повторюваних вхідних даних або вбудовувань. Автоматичне масштабування на основі глибини черги також може запобігти зростанню затримки хвоста.

Який моніторинг потрібен окрім «кінцева точка активна»

Одного часу безвідмовної роботи недостатньо, оскільки сервіс може виглядати справним, тоді як якість прогнозування знижується. Як мінімум, слід контролювати обсяг запитів, коефіцієнт помилок та розподіл затримки, а також сигнали насичення, такі як CPU/GPU/пам'ять та час очікування в черзі. Для поведінки моделі відстежуйте розподіл вхідних та вихідних даних разом із базовими сигналами аномалій. Додайте перевірки дрейфу, які запускають дії, а не шумні сповіщення, та реєструйте ідентифікатори запитів, версії моделі та результати перевірки схеми.

Як безпечно розгортати нові версії моделей та швидко відновлюватися

Ставтеся до моделей як до повноцінних релізів, з конвеєром CI/CD, який тестує попередню та постобробку, виконує перевірки інтеграції на відповідність «золотому набору» та встановлює базовий рівень навантаження. Для розгортання canary-релізи поступово нарощують трафік, тоді як blue-green зберігає старішу версію для негайного відновлення. Тіньове тестування допомагає оцінити нову модель на реальному трафіку, не впливаючи на користувачів. Відкат має бути першокласним механізмом, а не другорядним.

Найпоширеніші помилки під час навчання розгортанню моделей штучного інтелекту

Перекіс між навчанням та обслуговуванням – це класичний випадок: попередня обробка відрізняється під час навчання та виробництва, і продуктивність непомітно знижується. Ще однією поширеною проблемою є відсутність валідації схеми, коли зміна в початковому етапі непомітно порушує вхідні дані. Команди також недооцінюють затримку хвоста та надмірно зосереджуються на середніх значеннях, нехтують витратами (продуктивність графічних процесорів у режимі очікування швидко накопичується) та пропускають планування відкату. Моніторинг лише часу безвідмовної роботи особливо ризикований, оскільки «працює, але неправильно» може бути гіршим, ніж простоєм.

Посилання

  1. Amazon Web Services (AWS) – Amazon SageMaker: Виведення даних у режимі реального часу – docs.aws.amazon.com

  2. Веб-сервіси Amazon (AWS) – пакетне перетворення Amazon SageMaker – docs.aws.amazon.com

  3. Веб-сервіси Amazon (AWS) – Монітор моделей Amazon SageMaker – docs.aws.amazon.com

  4. Amazon Web Services (AWS) – Регулювання запитів API Gateway – docs.aws.amazon.com

  5. Amazon Web Services (AWS) – Менеджер секретів AWS: Вступ – docs.aws.amazon.com

  6. Amazon Web Services (AWS) – життєвий цикл середовища виконання AWS Lambda – docs.aws.amazon.com

  7. Google Cloud – Vertex AI: Розгортання моделі на кінцевій точці – docs.cloud.google.com

  8. Огляд моніторингу моделей Vertex AI у Google Cloud – docs.cloud.google.com

  9. Google Cloud – Vertex AI: моніторинг перекосу та дрейфу об'єктів – docs.cloud.google.com

  10. Блог Google Cloud – Потік даних: режими потокової передачі «рівно один раз» та «принаймні один раз» – cloud.google.com

  11. Google Cloud – Режими потокової передачі даних у хмарі – docs.cloud.google.com

  12. Книга Google SRE - Моніторинг розподілених систем - sre.google

  13. Google Research - Хвіст у масштабі - research.google

  14. LiteRT (Google AI) – огляд LiteRT – ai.google.dev

  15. LiteRT (Google AI) – визначення LiteRT на пристрої – ai.google.dev

  16. Docker - Що таке контейнер? - docs.docker.com

  17. Docker - Найкращі практики збірки Docker - docs.docker.com

  18. Kubernetes – секрети Kubernetes – kubernetes.io

  19. Kubernetes - Автоматичне масштабування горизонтальних подів - kubernetes.io

  20. Мартін Фаулер - Реліз Канарських островів - martinfowler.com

  21. Мартін Фаулер - Синьо-зелене розгортання - martinfowler.com

  22. Ініціатива OpenAPI - Що таке OpenAPI? - openapis.org

  23. Схема JSON - (посилання на сайт) - json-schema.org

  24. Буфери протоколів - Огляд буферів протоколів - protobuf.dev

  25. FastAPI - (посилання на сайт) - fastapi.tiangolo.com

  26. NVIDIA - Triton: Динамічне пакетування та паралельне виконання моделей - docs.nvidia.com

  27. NVIDIA - Triton: Паралельне виконання моделі - docs.nvidia.com

  28. NVIDIA - Документація сервера Triton Inference - docs.nvidia.com

  29. PyTorch - Документація TorchServe - docs.pytorch.org

  30. BentoML — Пакування для розгортання — docs.bentoml.com

  31. Рей - Рей Сервує документи - docs.ray.io

  32. TensorFlow - Квантування після навчання (Оптимізація моделі TensorFlow) - tensorflow.org

  33. TensorFlow - Перевірка даних TensorFlow: виявлення перекосу під час навчання - tensorflow.org

  34. ONNX - (посилання на сайт) - onnx.ai

  35. ONNX Runtime - Оптимізація моделі - onnxruntime.ai

  36. NIST (Національний інститут стандартів і технологій) - NIST SP 800-122 - csrc.nist.gov

  37. arXiv - Картки моделей для звітності про моделі - arxiv.org

  38. Microsoft - Тіньове тестування - microsoft.github.io

  39. OWASP - Топ-10 програм OWASP для отримання ступеня магістра права (LLM) - owasp.org

  40. Проект безпеки OWASP GenAI - OWASP: Оперативне введення - genai.owasp.org

Знайдіть найновіший штучний інтелект в офіційному магазині помічників зі штучним інтелектом

Про нас

Повернутися до блогу