Разница между открытыми моделями и коммерческими API искусственного интеллекта и машинного обучения

Открытые модели и коммерческие API ИИ и машинного обучения разница

Многомерный анализ, выходящий за рамки оценки производительности модели

Фото от Aron Visuals на Unsplash

В последние несколько месяцев вы, вероятно, столкнулись с бесчисленными дебатами о том, следует ли использовать открытые исходные коды или коммерческие API для больших языковых моделей (LLM). Однако это не относится только к LLM, вопрос применяется к машинному обучению (ML) в целом. Этот вопрос мне задавали многие клиенты за последние 5 лет, когда я работал архитектором ML в AWS.

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

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

1. Прежде чем мы начнём, давайте уточним некоторые определения!

Открытая модель ML – это сочетание архитектуры модели (дизайна модели) и весов (знаний, которыми обладает модель). Вы можете перейти на общедоступный хаб моделей, такие как Hugging Face, Pytorch Hub, Tensorflow Hub, и скачать их.

Коммерческое API ML (например, OpenAI API) – это сервис, доступ к которому осуществляется через конечную точку API и включает, среди прочего, модель ML. Эти API ML могут быть найдены среди услуг облачных провайдеров (AWS, Azure, GCP и т. д.) или меньших компаний, специализирующихся в определенных областях/задачах ML (Mindee, Lettria, Gladia и т. д.)

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

2. ML API – это не просто «ML модель, завернутая в API»

Давайте рассмотрим блоки вокруг модели и для чего они используются:

Изображение от автора

2.1 Инфраструктура для хостинга: Первое, что вы делаете при выборе модели ML, это решение, где ее запустить. Если вы экспериментируете и это достаточно маленькая модель, вы можете запустить ее на своей машине. Но это не всегда возможно или масштабируемо, поэтому вы обратитесь к облачному провайдеру (AWS, GCP, Azure) и арендуете серверы.

2.2 Фреймворк обслуживания ML: Модель – не просто «python функция». Чтобы обслуживать прогнозы оптимальным образом, вам придется использовать фреймворк обслуживания (TorcheServe, TFServing и другие, с уклоном на LLM). Эти фреймворки – это необходимое зло для достижения оптимальной задержки и обработки высокой конкурентоспособности, но они имеют кривую обучения.

2.3 Инженерная логика: Это очень зависит от случая и иногда может потребовать огромного количества времени у инженеров ML (дьявол кроется в деталях).

Давайте возьмем, например, анализ настроений – простой случай использования. Ниже приведен отрывок из Hugging Face:

Пример кода с https://huggingface.co/bert-base-uncased

Если все, что вам нужно, это определить настроение нескольких строк текста, то этим все заканчивается.

Однако, если у вас, скажем, 10 тысяч документов (разных форматов: pdf, word, текст) и вы хотите определить их настроение. Вам понадобится:

  • Сначала прогнать PDF-файлы через модель OCR (оптическое распознавание символов).
  • Работать с любыми крайними случаями (несколько страниц, страницы, которые не ориентированы должным образом и т. д.)
  • Возможно, использовать разные модели в зависимости от типа документа и создать оркестровочный рабочий процесс для приведения всех данных к правильному формату.
  • Передать все на анализ настроений. Но вы замечаете, что не можете делать это последовательно, так как это займет вечность.
  • Реализовать параллельный конвейер, который берет X документов, разбивает их на несколько процессов (возможно, на несколько серверов), выполняет прогнозы и возвращает результаты.
  • Создать тесты и автоматизированные процессы, чтобы обеспечить стабильность вышеперечисленного решения.

Эти компоненты – дьявол в деталях, которые абстрагированы с помощью коммерческого ML API. Провайдер API нанимает инженеров в свою команду, чтобы выполнить вышеуказанную работу, поддерживать ее и обновлять ее, чтобы вы могли использовать что-то вроде:

#псевдо-код (не фактическая библиотека)import providerx#Вы устанавливаете ключ API, чтобы получить доступ к провайдеруproviderx.api-key = "123452" #Это будет передавать данные провайдеру, выполнять вышеуказанные шаги и sentiments = providerx.detect_sentiment('./folder-containing-documents/',             document_types=["pdf","word", "txt"]))

2.4 Масштабирование API и инфраструктуры: Это включает два аспекта. Во-первых, упаковать все вышеуказанные компоненты в API, чтобы сделать предсказания модели доступными для остальной части вашего технического стека и продукта. Во-вторых, убедитесь, что он может обрабатывать одновременную нагрузку и внезапное увеличение трафика. Для иллюстрации:

Изображение автора

Чтобы упаковать вашу модель, вам потребуется объединить код вывода (скрипт inference.py), любые другие файлы предварительной или последующей обработки, создать контейнер Docker и использовать что-то вроде FastAPI, Amazon API gateway, управления API Apigee для создания API.

Затем идет масштабирование, чем больше пользователей или предсказаний вы делаете, тем больше инфраструктуры вам понадобится для созданного вами API. Вы начнете с небольшого сервера (~30$/месяц) и, возможно, придется масштабироваться до (~200$/месяц) в зависимости от трафика ваших пользователей. Затем снова уменьшьте масштаб, когда ваш API никто не использует.

Здесь дела становятся сложными, вы больше не просто делаете предсказания ML, вы создаете небольшое программное / сервисное решение внутри своей команды.

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

2.5 Поддержка клиентов и SLA: И наконец, когда что-то не работает как ожидается или что-то ломается, кто это исправит?

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

Когда вы используете коммерческий ML API, в рамках услуги предоставляется поддержка в соответствии с соглашениями об уровне обслуживания (SLA). Например, SLA может звучать так: “если наш сервис сломается, мы назначим инженера, чтобы исправить это в течение 6 часов”.

Наконец, обратите внимание, что просто потому, что коммерческий ML API делает больше вещей по умолчанию, не означает, что вы не можете делать их самостоятельно. Важно знать, что это элементы, которые вам придется в конечном итоге создать, если вы хотите достичь такого же уровня обслуживания, как у коммерческого ML API.

3. При сравнении затрат используйте общую стоимость владения (TCO)

Большинство останавливаются на “Модель ML бесплатна” или “Вызовы API слишком дорогие”, давайте посмотрим, насколько это правда.

Начнем с затрат на генерацию предсказаний:

1/Использование открытой модели: Хостинг ResNet50 (для классификации изображений) на экземпляре g4dn.xlarge стоит 0,526 долларов в час и может достигать ~75 предсказаний в секунду для этой модели (таблица в конце здесь). Предположим, вам необходимо обеспечить мгновенный ответ вашим пользователям, поэтому вы держите экземпляр активным 24/7, это будет стоить вам около 400 долларов, и вы сможете сделать около 200 миллионов (75*60*60*24*31) предсказаний, если вы будете использовать API без остановки.

2/Использование Amazon Rekognition API: Это будет стоить вам 0,00025 доллара за предсказание, и если вы хотите сделать 200 миллионов предсказаний в месяц, это потребует целых 50 000 долларов.

Так что, ясно, что вы должны выбрать вариант 1, верно? Ну, это зависит от того, сколько вызовов вы делаете в месяц:

Сравнение цены вариантов 1 и 2 в зависимости от количества ежемесячных запросов

Обратите внимание, что график не учитывает “всплески” в трафике. Чем больше пользователей одновременно обращается к вашим моделям машинного обучения, тем больше серверов вам потребуется для обработки нагрузки. Таким образом, стоимость графического процессора не является полностью фиксированной, но для упрощения давайте сосредоточимся на стабильных рабочих нагрузках и придем к следующим выводам:

-> Если вы делаете менее 400 000 прогнозов в месяц, вам лучше платить за Коммерческий ML API. Если ваш объем превышает это, каждый месяц, да, используйте версию с открытым исходным кодом и разместите ее самостоятельно.

Примечание: подобное исследование о LLM было проведено здесь.


До сих пор мы только смотрели на то, сколько стоит делать прогнозы. Однако, рассматривая стоимость, вы должны обратить внимание на TCO (Общую стоимость владения). Это в основном отвечает на вопрос:

Сколько это будет стоить, если мы включим модель, инфраструктуру, затраты на инженерное время, операционные и техническую поддержку?

Инженерная логика, настройка фреймворков, масштабируемость вашей инфраструктуры, обслуживание и поддержка и т. д. Вы оплачиваете все это человеческим капиталом. Это самая сложная часть для оценки, потому что она зависит от того, какую задачу по ML вы хотите выполнить, какой уровень сервиса вы хотите предоставить и какие ресурсы у вас есть.

Предположим, вы нанимаете двух человек, одного с опытом в ML и другого в бэкэнде/облачных технологиях. Среднегодовая зарплата для инженеров-программистов составляет 120 тыс. долларов в США (и 60 тыс. долларов в Европе), что в сумме составляет 240 тыс. долларов (120 тыс. в Европе) минимум* (данные от indeed, glassdoor)

В двух словах, Коммерческий ML API нанимает инженеров, арендует инфраструктуру и через взаимовыгодное использование их услуг они могут “арендовать” кусочки своей инфраструктуры и инженерных ресурсов через свой API, так что вам не нужно брать большие обязательства на своей стороне.

4. Настройка

“Да, но я хотел бы настроить свои модели под свои данные и свой случай использования”. Вы можете сделать это как с моделями с открытым исходным кодом, так и с коммерческими ML API. Разница заключается в степени настройки и усилиях, которые вам потребуются для настройки.

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

Для моделей с открытым исходным кодом у вас определенно больше гибкости. Поскольку у вас есть доступ к модели, вы можете углубиться и даже изменить архитектуру модели. Однако это требует наличия специалиста по ML, который не только понимает, как правильно настроить модель, но и архитектуру модели и ее параметры.

Для коммерческих ML API у вас будет меньше гибкости, но и меньше работы с вашей стороны. Лучшим примером коммерческого API для настройки является недавно выпущенная GPT-3.5 fine-tuning. Другие примеры – это настраиваемые метки с использованием Amazon Rekognition, что очень полезно, если вы используете конкретные изображения, или API для настройки OCR документов от Mindee.

Коммерческий ML API попросит вас предоставить данные и метки через их API/интерфейс, и они заботятся об остальном: обучение, оптимизация и развертывание настраиваемой модели для вас с использованием того же стека, что и у общих моделей.

Начните с API для настройки, подайте входные и выходные данные, если производительность не очень хорошая, сначала обратитесь к провайдеру. Они могут оценить ваш случай использования и сказать вам, возможно ли это. Если нет, то рассмотрите возможность найма специалиста по ML, который может глубоко изучить детали моделей с открытым исходным кодом и адаптировать их.

5. Безопасность и конфиденциальность

Безопасность – это то, насколько безопасна ваша система от атак. Если у вас нет специалистов по безопасности в вашей команде, то грубая правда заключается в том, что вероятнее всего вы создадите менее безопасные системы, чем у Коммерческого ML API. У них есть отдельная команда по безопасности, они реализуют отраслевые стандарты и постоянно проверяют свои системы.

Если вы этого не делаете, вы не можете пометить модели с открытым исходным кодом и самоуправляемые модели как “безопасные” только потому, что вы сами управляете ими.

Конфиденциальность, с другой стороны, разная; когда ваши данные покидают ваш центр данных/серверы и проходят через API, вы рискуете тем, что кто-то еще, кроме вас, сможет прочитать ваши данные. Когда это связано с регуляторными правилами (например, если данные вашей компании проходят через сервис x, то вам нужно сделать y), тогда это просто вопрос соблюдения этих правил и прохождения одобрений.

Когда речь идет о приватности и беспокойстве о том, что “поставщик будет смотреть на мои данные”, имейте в виду, что их бизнес заключается в продаже вам вызовов API, и они не могут этого делать, если им нельзя доверять. Проверьте, кто предоставляет API, прежде чем использовать его, кто они точно, и каковы их правила конфиденциальности. Установленные поставщики четко объясняют, что они делают с вашими данными, шифруют ваши данные в пути и в покое, а иногда даже предлагают варианты отказаться от использования ваших данных для целей обучения и т.д.

Резюме и выводы

Ниже приведена таблица, которая дает рекомендации о том, когда выбрать что

Таблица резюме, изображение автора

Самое главное, помните, что как Open Source ML модели, так и Commercial ML API необходимы, они просто служат разным целям. Какой из них лучше зависит от вышеупомянутых критериев и вашей ситуации. Вот краткое руководство по рекомендациям:

  • Чем выше ежемесячный объем прогнозов (>~400–500k), тем больше шансов, что вам выгоднее использовать Open Source модели и размещать их у себя.
  • Всегда сначала попробуйте Commercial ML API. Если они выполняют работу и цена соответствует вашему бюджету, оставайтесь при этом. Если цена немного выше, рассмотрите, сколько вам потребуется денег, чтобы нанять людей для создания и поддержки подобного сервиса.
  • Если результаты плохие, попробуйте настроить функции Commercial ML API, работайте с вашими данными и/или обратитесь за помощью к поставщику. Если все равно результаты плохие, подумайте о вложении в ML-специалиста, и если результаты ML отличные, то вложите в ML-инженера/DevOps, чтобы помочь внедрить модель в производство.

Спасибо за чтение! Если мы еще не знакомы, я Отман и я работал 5 лет на AWS в качестве инженера по машинному обучению, помогая более 30 компаниям внедрять ML в свои продукты/бизнес.

Если у вас есть вопросы, не стесняйтесь обращаться в Twitter (@OHamzaoui1) или Linkedin (hamzaouiothmane).