Как развернуть модели искусственного интеллекта

Как развернуть модели искусственного интеллекта

Краткий ответ: развертывание модели ИИ означает выбор шаблона обслуживания (в реальном времени, пакетная обработка, потоковая передача или обработка на периферии сети), а затем обеспечение воспроизводимости, наблюдаемости, безопасности и обратимости всего процесса. Когда вы используете версионирование всего и проводите сравнительный анализ задержки p95/p99 на практически работающих приложениях, вы избегаете большинства проблем, связанных с отсутствием поддержки на вашем ноутбуке.

Основные выводы:

Шаблоны развертывания: Прежде чем выбрать инструменты, определитесь с режимом развертывания: в реальном времени, пакетная обработка, потоковая обработка или развертывание на периферии сети.

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

Наблюдаемость: Непрерывный мониторинг задержек, ошибок, насыщения и распределения данных или выходных параметров.

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

Безопасность и конфиденциальность: Применяйте аутентификацию, ограничения скорости запросов и управление секретами, а также минимизируйте количество персональных данных в журналах.

Как развернуть модели ИИ? Инфографика

Статьи, которые могут вас заинтересовать после этой: 

🔗 Как измерить производительность ИИ
Изучите метрики, контрольные показатели и реальные методы проверки для получения надежных результатов в области искусственного интеллекта.

🔗 Как автоматизировать задачи с помощью ИИ
Превратите рутинную работу в рабочие процессы, используя подсказки, инструменты и интеграции.

🔗 Как тестировать модели ИИ
Разработка оценок, наборов данных и системы баллов для объективного сравнения моделей.

🔗 Как общаться с ИИ
Задавайте более качественные вопросы, уточняйте контекст и получайте более ясные ответы быстро.

1) Что на самом деле означает «развертывание» (и почему это не просто API) 🧩

Когда говорят «развернуть модель», могут иметь в виду что-то из перечисленного:

Таким образом, развертывание — это не столько «обеспечение доступности модели», сколько что-то вроде:

Это чем-то похоже на открытие ресторана. Конечно, приготовление отличного блюда важно. Но вам всё равно нужны здание, персонал, холодильное оборудование, меню, цепочка поставок и способ справиться с вечерним наплывом посетителей, не плача в холодильной камере. Не идеальная метафора… но вы поняли. 🍝

2) Что делает версию статьи «Как развертывать модели ИИ» хорошей? ✅

«Удачное развертывание» — это скучно в самом лучшем смысле этого слова. Оно ведет себя предсказуемо под давлением, а если что-то идет не так, можно быстро диагностировать проблему.

Вот как обычно выглядит «хорошо»:

  • Воспроизводимые сборки.
    Тот же код + те же зависимости = то же поведение. Никаких пугающих ощущений типа «работает на моем ноутбуке» 👻 ( Docker: Что такое контейнер? )

  • Чёткий интерфейсный контракт.
    Определены входные и выходные данные, схемы и граничные случаи. Никаких неожиданных типов в 2 часа ночи. ( OpenAPI: Что такое OpenAPI?, JSON Schema )

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

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

  • Безопасная стратегия развертывания:
    канареечный или сине-зеленый подход, простой откат, версионирование, не требующее молитв. ( Канарейный релиз , сине-зеленое развертывание )

  • Информирование о расходах.
    «Быстро» — это здорово, пока счет не выглядит как номер телефона 📞💸

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

Если вы сможете делать это постоянно, вы уже будете впереди большинства команд. Давайте будем честны.

3) Выберите правильный шаблон развертывания (прежде чем выбирать инструменты) 🧠

Вывод данных API в реальном времени ⚡

Лучше всего подходит в следующих случаях:

  • Пользователям нужны мгновенные результаты (рекомендации, проверка на мошенничество, чат, персонализация)

  • Решения должны приниматься в ходе обработки запроса

Осторожно:

Пакетная оценка 📦

Лучше всего подходит в следующих случаях:

  • Прогнозы могут быть отложены (оценка рисков за ночь, прогнозирование оттока клиентов, обогащение ETL-процессов) ( Amazon SageMaker Batch Transform ).

  • Вам нужна экономическая эффективность и упрощение операций?

Осторожно:

  • актуальность данных и заполнение пропущенных данных

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

Потоковая обработка данных 🌊

Лучше всего подходит в следующих случаях:

  • Вы непрерывно обрабатываете события (IoT, потоки кликов, системы мониторинга)

  • Вам нужны решения, принимаемые практически в режиме реального времени, без жестких требований типа «запрос-ответ»

Осторожно:

  • Семантика "точно один раз" против "как минимум один раз" ( Cloud Dataflow: exactly-once vs at-least-once )

  • Управление состоянием, повторные попытки, странные дубликаты

Развертывание на периферии сети 📱

Лучше всего подходит в следующих случаях:

Осторожно:

Сначала выберите шаблон, а затем — стек. В противном случае вы в итоге заставите квадратную модель работать в круглой среде. Или что-то в этом роде. 😬

4) Упаковка модели таким образом, чтобы она выдержала контакт с производственным процессом 📦🧯

Именно здесь большинство «простых решений» тихонько терпят крах.

Версионируйте всё (да, всё)

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

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

  • Код вывода (предварительная/постобработка)

  • Окружение (Python, CUDA, системные библиотеки)

Простой и эффективный подход:

  • Относитесь к модели как к артефакту выпуска

  • сохранить его с тегом версии

  • Требуется файл метаданных, похожий на карточку модели: схема, метрики, примечания к снимку обучающих данных, известные ограничения ( Карточки моделей для отчетности по моделям ).

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

Контейнеры — это здорово, потому что они:

Но вам все равно нужно будет управлять следующим:

  • обновления базового образа

  • совместимость драйверов графического процессора

  • сканирование безопасности

  • Размер образа (никому не нравится 9-гигабайтный «hello world») ( Рекомендации по сборке Docker )

Стандартизировать интерфейс

Определите формат ввода/вывода на раннем этапе:

  • JSON для простоты (медленнее, но удобнее) ( JSON Schema )

  • Protobuf для повышения производительности ( Обзор протоколов Protocol Buffers )

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

И, пожалуйста, проверяйте входные данные. Некорректные входные данные — главная причина обращений типа «почему возвращается бессмысленный ответ». ( OpenAPI: Что такое OpenAPI?, JSON Schema )

5) Варианты обслуживания — от «простого API» до полнофункциональных серверов 🧰

Существует два распространенных маршрута:

Вариант А: Сервер приложений + код вывода (подход в стиле 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) Производительность и масштабируемость — задержка, пропускная способность и истина 🏁

Оптимизация производительности – это процесс, в ходе которого развертывание превращается в искусство. Цель не в том, чтобы «быстро». Цель – обеспечить стабильно достаточную скорость .

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

  • Задержка p50 : типичный пользовательский опыт

  • Задержка p95/p99 : вызывающий ярость хвост ( The Tail at Scale , SRE Book: Monitoring Distributed Systems )

  • Пропускная способность : количество запросов в секунду (или количество токенов в секунду для генеративных моделей)

  • Частота ошибок : очевидна, но иногда всё же игнорируется.

  • Использование ресурсов : ЦП, ГП, память, видеопамять ( книга по SRE: Мониторинг распределенных систем )

Общие рычаги для воздействия

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

  • Квантование
    с более низкой точностью (например, INT8) может ускорить вывод и уменьшить объем памяти. Может незначительно снизить точность. Иногда, как ни странно, этого не происходит. ( Квантование после обучения )

  • Компиляция/оптимизация,
    экспорт в ONNX, оптимизаторы графов, потоки, подобные TensorRT. Мощно, но отладка может быть сложной 🌶️ ( ONNX , оптимизация моделей во время выполнения ONNX )

  • Кэширование.
    Если входные данные повторяются (или вы можете кэшировать эмбеддинги), вы можете значительно сэкономить.

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

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

8) Мониторинг и наблюдаемость — не действуйте вслепую 👀📈

Мониторинг модели — это не просто мониторинг времени безотказной работы. Вам нужно знать, если:

Что следует отслеживать (минимально допустимый набор)

Служба здравоохранения

  • Распределение количества запросов, частоты ошибок и задержек ( SRE Book: Monitoring Distributed Systems )

  • насыщение (процессор/графический процессор/память)

  • Длина очереди и время пребывания в очереди

Модель поведения

  • Распределение входных признаков (базовая статистика)

  • нормы встраивания (для моделей встраивания)

  • Распределения выходных данных (уровень достоверности, состав классов, диапазоны оценок)

  • Обнаружение аномалий на входных данных (мусор на входе, мусор на выходе)

Сдвиг данных и сдвиг концепций

Ведение журналов, но не подход «все записывать навсегда» 🪵

Бревно:

  • Идентификаторы запросов

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

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

  • минимальные структурированные метаданные полезной нагрузки (не исходные персональные данные) ( NIST SP 800-122 )

Будьте осторожны с конфиденциальностью. Не допускайте утечки данных из ваших журналов. ( NIST SP 800-122 )

9) Стратегии CI/CD и развертывания — относитесь к моделям как к реальным релизам 🧱🚦

Если вам нужны надежные развертывания, создайте конвейер. Даже самый простой.

твердый поток

  • Модульные тесты для предварительной и постобработки

  • Интеграционный тест с использованием известного «золотого набора» входных и выходных данных

  • Базовый уровень нагрузочного тестирования (даже при небольшой нагрузке)

  • Создание артефакта (контейнера + модели) ( Рекомендации по сборке Docker )

  • Развернуть на тестовой платформе

  • Выпуск тестовой версии (Canary Release) для небольшой части трафика ( Canary Release )

  • Постепенно наращивайте темп

  • Автоматический откат ключевых пороговых значений ( сине-зеленое развертывание )

Внедрение схем, которые спасут ваше душевное равновесие

  • Canary : сначала выпустить версию для 1-5% трафика ( Canary Release )

  • Сине-зеленый подход : запуск новой версии параллельно со старой, переключение на новую версию при готовности ( сине-зеленое развертывание ).

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

И версионируйте свои конечные точки или маршрут в соответствии с версией модели. В будущем вы сами себя поблагодарите. И сейчас вы тоже себя поблагодарите, но тихо.

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

Охрана, как правило, появляется с опозданием, словно незваный гость. Лучше пригласить её заранее.

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

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

  • Ограничение скорости запросов (защита от злоупотреблений и случайных скачков трафика) ( ограничение скорости API Gateway )

  • Управление секретами (без ключей в коде, без ключей в конфигурационных файлах…) ( AWS Secrets Manager , Kubernetes Secrets )

  • Сетевые элементы управления (частные подсети, политики взаимодействия между сервисами)

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

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

Если модель затрагивает персональные данные:

  • идентификаторы редактирования или хеша

  • Избегайте регистрации необработанных данных полезной нагрузки ( NIST SP 800-122 ).

  • определить правила хранения

  • документирование потока данных (скучно, но обеспечивает защиту)

Кроме того, внедрение подсказок и злоупотребление выходными данными могут иметь значение для генеративных моделей. Дополнение: ( OWASP Top 10 for LLM Applications , OWASP: Prompt Injection )

  • правила очистки входных данных

  • фильтрация выходных данных там, где это необходимо

  • Ограничения для вызова инструментов или действий с базой данных

Ни одна система не идеальна, но вы можете сделать её менее уязвимой.

11) Распространенные ошибки (или, как их еще называют, обычные ловушки) 🪤

Вот классика:

Если вы читаете это и думаете: «Да, у нас есть два таких мероприятия», добро пожаловать в клуб. В клубе есть закуски и немного стресса. 🍪

12) Заключение — Как развернуть модели ИИ, не сойдя с ума 😄✅

Внедрение — это тот этап, когда ИИ становится реальным продуктом. Это не самый привлекательный процесс, но именно на этом этапе завоевывается доверие.

Краткое резюме

Да, развертывание моделей ИИ может показаться жонглированием горящими шарами для боулинга. Но как только ваш конвейер стабилизируется, это становится странно приятным. Как наконец-то навести порядок в захламленном ящике… только в этом ящике находится производственный поток. 🔥🎳

Часто задаваемые вопросы

Что значит внедрить модель ИИ в производство?

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

Как выбрать между развертыванием в реальном времени, пакетной обработкой, потоковой обработкой или развертыванием на периферии сети?

Выберите схему развертывания в зависимости от того, когда необходимы прогнозы и в каких условиях вы работаете. API реального времени подходят для интерактивных взаимодействий, где важна задержка. Пакетная обработка оценок наиболее эффективна, когда задержки приемлемы и приоритет отдается экономической эффективности. Потоковая обработка подходит для непрерывной обработки событий, особенно когда семантика доставки становится сложной. Развертывание на периферии идеально подходит для работы в автономном режиме, обеспечения конфиденциальности или требований к сверхнизкой задержке, хотя в этом случае управление обновлениями и изменениями оборудования становится сложнее.

Какую версию установить, чтобы избежать сбоев при развертывании, когда приложение работает на ноутбуке?

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

Выбрать ли для развертывания простой сервис в стиле FastAPI или выделенный сервер моделей?

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

Как улучшить задержку и пропускную способность без ущерба для точности

Начните с измерения задержки p95/p99 на оборудовании, приближенном к производственному, с реалистичными полезными нагрузками, поскольку небольшие тесты могут ввести в заблуждение. К распространенным способам решения проблемы относятся пакетная обработка (лучшая пропускная способность, потенциально худшая задержка), квантование (меньшее и более быстрое, иногда с небольшим компромиссом в точности), процессы компиляции и оптимизации (подобные ONNX/TensorRT), а также кэширование повторяющихся входных данных или эмбеддингов. Автомасштабирование на основе глубины очереди также может предотвратить увеличение задержки в хвосте распределения.

Какой мониторинг необходим помимо проверки работоспособности конечной точки?

Одного лишь времени безотказной работы недостаточно, поскольку сервис может выглядеть работоспособным, в то время как качество прогнозирования снижается. Как минимум, необходимо отслеживать объем запросов, частоту ошибок и распределение задержек, а также сигналы насыщения, такие как загрузка ЦП/ГП/памяти и время ожидания в очереди. Для оценки поведения модели следует отслеживать распределение входных и выходных данных, а также основные сигналы аномалий. Добавьте проверки на отклонения, которые запускают действия, а не ложные оповещения, и регистрируйте идентификаторы запросов, версии моделей и результаты проверки схемы.

Как безопасно внедрять новые версии моделей и быстро восстанавливать работу

Подход к моделям следует рассматривать как полноценные релизы, используя конвейер CI/CD, который тестирует предварительную и постобработку, выполняет интеграционные проверки на «эталонном наборе» и устанавливает базовый уровень нагрузки. При развертывании канареечные релизы постепенно увеличивают трафик, а сине-зеленые поддерживают старую версию в рабочем состоянии для немедленного резервного копирования. Теневое тестирование помогает оценить новую модель на реальном трафике, не затрагивая пользователей. Откат должен быть первостепенным механизмом, а не второстепенным.

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

Классическим примером является неравномерность обработки данных при обучении и в производственной среде: предварительная обработка различается между обучающей и производственной средами, и производительность незаметно снижается. Другая распространенная проблема — отсутствие проверки схемы, когда изменение в исходном коде незаметно нарушает работу входных данных. Команды также недооценивают задержку в хвосте распределения и чрезмерно концентрируются на средних значениях, упускают из виду затраты (простаивающие графические процессоры быстро накапливают расходы) и игнорируют планирование отката. Мониторинг только времени безотказной работы особенно рискован, поскольку ситуация «работает, но неправильно» может быть хуже, чем простоя.

Ссылки

  1. Amazon Web Services (AWS) - Amazon SageMaker: Выполнение вычислений в реальном времени - docs.aws.amazon.com

  2. Amazon Web Services (AWS) - Amazon SageMaker Batch Transform - docs.aws.amazon.com

  3. Amazon Web Services (AWS) - Монитор модели Amazon SageMaker - docs.aws.amazon.com

  4. Amazon Web Services (AWS) — регулирование запросов через API Gateway — docs.aws.amazon.com

  5. Amazon Web Services (AWS) - AWS Secrets Manager: Введение - 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. Google Cloud — Обзор системы мониторинга моделей Vertex AI — docs.cloud.google.com

  9. Google Cloud - Vertex AI: Мониторинг искажений и дрейфа характеристик - docs.cloud.google.com

  10. Блог Google Cloud - Dataflow: режимы потоковой передачи данных «точно один раз» и «как минимум один раз» - cloud.google.com

  11. Google Cloud — потоковые режимы Cloud Dataflow — 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 Schema - (ссылка на сайт) - json-schema.org

  24. Protocol Buffers - Обзор Protocol Buffers - protobuf.dev

  25. FastAPI - (указанный сайт) - fastapi.tiangolo.com

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

  27. NVIDIA - Triton: параллельное выполнение моделей - docs.nvidia.com

  28. NVIDIA - Документация по серверу вывода Triton - docs.nvidia.com

  29. PyTorch - TorchServe - docs.pytorch.org

  30. BentoML — Упаковка для развертывания — docs.bentoml.com

  31. Ray - Документация Ray Serve - 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 - OWASP Топ-10 для поступления на магистерские программы (LLM) - owasp.org

  40. Проект OWASP GenAI по безопасности — OWASP: Внедрение подсказок — genai.owasp.org

Найдите новейшие разработки в области ИИ в официальном магазине ИИ-помощников

О нас

Вернуться в блог