Многие компании уже внедряют искусственный интеллект (ИИ) в свои бизнес-процессы или планируют это сделать в ближайшие пару лет. И, как в случае с «традиционными» информационными системами, им нужно ответить на принципиальный вопрос: на какой инфраструктуре развивать интеллектуальные сервисы — собственной или облачной. Какой вариант оптимален в разных случаях и какие ошибки допускают компании при формировании собственной инфраструктуры для ИИ, рассказывает Кирилл Пляшкевич, продакт-менеджер по серверам и СХД компании FIGURA.
90 из 100 крупнейших предприятий страны применяют технологии машинного обучения и искусственного интеллекта при разработке продуктов для внешнего рынка и решении внутренних задач. При этом ИИ перестает быть уделом ИТ-гигантов и лидеров отраслей — активный интерес к ним проявляют представители малого и среднего бизнеса из разных сфер.
Между тем, искусственный интеллект отличается высокими требованиями к вычислительной инфраструктуре, на которой он базируется. И аппаратное обеспечение таких систем становится проблемой для компаний, которые намерены разворачивать собственные ИИ-сервисы.
Даже крупные заказчики, которые располагают собственными дата-центрами, сталкиваются с необходимостью наращивания вычислительных мощностей. Тем более проблематичной может стать задача внедрения ИИ-сервиса для средних компаний, инфраструктура которых часто не столь развита.
SaaS или On-Premise?
Проблему с наличием инфраструктуры для отдельных сервисов и систем решают облака. ИИ-сервисы, конечно, можно базировать на мощностях провайдеров, получая при этом традиционные для облаков экономические преимущества (перевод затрат в операционные, простое масштабирование и т. п.). Но есть ряд ИИ-решений, которые требуют собственных вычислительных мощностей.
Прежде всего, это речевая аналитика. В голосовых записях с онлайн-совещаний, встреч, переговоров часто содержится весьма чувствительная для бизнеса информация, и передавать ее в публичные облака рискованно. Содержание разговоров и эмоции участников должны остаться внутри своего периметра.
То же самое касается видеоаналитики, но здесь к корпоративным данным добавляется биометрия. Стоит иметь в виду, что с 30 мая 2025 года вводятся оборотные штрафы за утечку персональных данных, и самые высокие — за «потерю» биометрических данных (от 15 млн до 20 млн рублей для организаций и ИП согласно) ч. 17 ст. 13.11 КоАП).
Ряд задач с использованием ИИ должны решаться на собственных серверах в силу критического значения скорости работы. Например, ИИ в системах видеоконтроля производственных линий — даже доли секунды могут обеспечить физическую безопасность работников, предотвратить травмы или выполнение ошибочных операций.
Использование собственной инфраструктуры помогает повысить эффективность LLM. Виртуальный аватар (модное и активно развивающееся явление) или чат-бот, которые размещены на собственных серверах, будут работать быстрее, и взаимодействие с ними будет естественным. Это особенно важно в коммуникациях с клиентами. Если боты используются в рамках HR-сервисов или для юридических консультаций сотрудников компании, их быстродействие не так критично — такие решения можно выносить в облако.
Как создать свою инфраструктуру для ИИ
С облаком для ИИ все более или менее очевидно: нужно выбрать провайдера, который обеспечит оптимальное соотношение цены, SLA и безопасности данных. На российском рынке довольно большой выбор облачных инфраструктурных сервисов.
Намного сложнее подготовить инфраструктуру для ИИ в собственном периметре. На этапе формирования вычислительных мощностей можно совершить три ошибки, которые серьезно влияют на результат всего проекта.
Ошибка 1: Отсутствие тщательного анализа потребностей будущего сервиса
У каждого ИИ-сервиса — свои требования к производительности инфраструктуры. Их необходимо учитывать при планировании вычислительных мощностей. Так, речевая аналитика на базе ИИ требует одной мощности, машинное обучение — совершенно другой.
Кроме этого, важно учитывать ожидания компании от работы сервиса и планы по его развитию. Например, целевую скорость обработки запросов и реакции, возможности для масштабирования.
И только после анализа всех возможных факторов необходимо определяться с поставщиком оборудования и выбором конкретной конфигурации. Точно так же, кстати, как и при выборе сервера для размещения на нем любой информационной системы — первичны требования ПО и ожидания компании в отношении него.
Ошибка 2: ПО — отдельно, оборудование — отдельно
Желая развернуть собственный ИИ-сервис, компании начинают с экспериментов: нанимают разработчиков, приобретают дорогое оборудование и на основе решений с открытым исходным кодом пытаются разработать свое решение. Как показывает практика, часто эти усилия и затраты оказываются бесполезными — заказчики начинают искать на рынке готовое специализированное решение, которое подходило бы под уже приобретенное оборудование.
Похожая ситуация: вследствие высоких ожиданий в отношении искусственного интеллекта компании получают гранты, на которые приобретают оборудование для будущих проектов, а как его использовать в дальнейшем — не понимают.
В итоге есть сервер, к которому необходимо адаптировать будущее решение. А это тупиковый путь в большинстве случаев.
Проблема особенно остро ощущается в проектах по внедрению видеоаналитики и сервисов, использующих генеративный ИИ. Несмотря на то, что в последние два года компании много экспериментировали с этими технологиями и уже перешли к их коммерческому использованию, до сих пор нет комплексного подхода к проектированию, что чревато низкой эффективностью реализуемого решения.
Так, системы не оправдывают ожидания из-за низкого качества аналитики или недостаточной скорости работы. И самая частая причина такого результата — в несоответствии ПО и вычислительной инфраструктуры, когда софт и оборудование закупали отдельно, без проверки совместимости и соответствия требованиям.
Такой «лоскутный» принцип создания сервисов не позволит обеспечить их доступность на уровне 99,99%. А кроме того, крайне усложнит поддержку систем и значительно увеличит ее стоимость.
Ошибка 3: Затягивание проекта из-за длительных сроков поставки оборудования
Само по себе оборудование не создает проблем при внедрении системы. Это обычный набор действий по монтированию стоек, инсталляции, установке необходимого системного ПО, драйверов и пр. Затем следует развертывание, тестирование модели и самих сервисов.
А вот сроки поставки серверов могут колебаться. Мощный сервер с GPU может доставляться в Россию 8-10 недель. Часто в течение этих месяцев проект останавливается в ожидании оборудования.
ПАК как решение проблем
Избежать все ошибки помогает использование специализированных программно-аппаратных комплексов для разработки и развития ИИ-сервисов.
Современные высокопроизводительные вычисления и искусственный интеллект давно перестали быть экспериментальными технологиями — они становятся частью бизнес-процессов. Но как именно это выглядит на практике? Рассмотрим два подхода: облачную инфраструктуру для разработки ИИ и комплексные корпоративные решения.
Когда компании нужны серьезные вычислительные ресурсы, но нет смысла строить собственный дата-центр, на помощь приходят облачные HPC-платформы. Например, некоторые поставщики предлагают доступ к мощным GPU NVIDIA H100/A100 с поддержкой технологии MIG, которая позволяет гибко распределять ресурсы между задачами.
Инфраструктура уже включает в себя популярные фреймворки вроде TensorFlow и PyTorch, инструменты для инференса, такие как TritonServer, и удобные интерфейсы управления — от Jupyter Notebook до API. Это позволяет разработчикам сосредоточиться на создании моделей, не тратя время на настройку окружения.
Но что, если компании нужен не просто доступ к GPU, а полноценные ИИ-сервисы? Здесь на первый план выходят комплексные решения, которые объединяют оборудование, ПО и поддержку.
Некоторые вендоры предлагают предустановленные большие языковые модели вместе с MLOps-платформой для их обучения и развертывания. В комплекте могут идти и готовые продукты — например, ИИ-ассистенты для сотрудников или системы интеллектуального поиска по внутренним документам.
Ключевое преимущество таких решений — проверенная совместимость всех компонентов. Оборудование подбирается под конкретные задачи, ПО тестируется на стабильность, а за работоспособность всей системы отвечает один поставщик. Это снижает риски и ускоряет внедрение.
Вместо месяцев настройки инфраструктуры компании получают готовую среду для экспериментов или даже работающие ИИ-сервисы. Кроме того, такой подход снижает операционные риски — особенно когда критически важна бесперебойная работа.
Сегодня ИИ в ПАК — это не абстрактная концепция, а вполне конкретные рабочие инструменты. ПАК — наиболее удобная форма развертывания ИИ-сервиса внутри инфраструктуры компании и с точки зрения заказчика, и с точки зрения поставщика. Она позволяет упростить разработку сервиса и его внедрение, сократить сроки развертывания решения.
ПАК дает гарантию производительности системы и обеспечивает ее прогнозируемость. А кроме того, в значительной мере облегчает дальнейшую поддержку, потому что позволяет четко разграничить компетенции ИТ-отдела заказчика и службы поддержки поставщика.