Фреймворк для CIO: как выбрать AI-инфраструктуру под задачи бизнеса. Когда нужен собственный сервер, а когда достаточно облака или гибрида. Критерии, экономика, чек-лист перед пилотом.
Разговор, который сегодня происходит в каждом совете директоров
Финансовый директор кладёт на стол счёт от облачного провайдера и спрашивает: «Мы правда собираемся платить это каждый месяц дальше?». Через неделю юрист приходит с вопросом: «А вы уверены, что переписка наших менеджеров с клиентами не уходит на серверы за пределами страны?». Ещё через месяц кто-то из ключевых заказчиков просит письменную гарантию, что его данные не окажутся в чужой языковой модели.
К этому моменту CIO обычно уже понимает: тема с искусственным интеллектом больше не про «нужно ли нам это». Она про то, где именно должна работать инфраструктура для ИИ: в публичном облаке, в гибридной модели или в собственном контуре компании. И решение это, в отличие от многих ИТ-выборов последних лет, придётся принимать не под давлением тренда, а под давлением конкретных цифр и конкретных рисков.
Этот текст — рабочий фреймворк, чтобы принять предварительное решение самостоятельно. Не заказ на сервер и не рекламная брошюра. Финальный выбор всё равно потребует обследования, расчётов и разговора с командой, которая будет это внедрять, но большую часть предварительной оценки CIO сегодня в состоянии сделать сам, если у него под рукой правильная система координат.
Три сценария: облако, гибрид, собственный сервер
Инфраструктура для ИИ — это совокупность вычислительных ресурсов, систем хранения, сетей и программной среды, на которой обучаются, разворачиваются и работают модели искусственного интеллекта. Практически все реальные архитектуры сегодня строятся вокруг трёх опорных моделей. Между ними нет «правильной»: есть подходящая под конкретную комбинацию задач, данных и ограничений.
Облачные AI-сервисы — это использование готовых моделей крупных провайдеров через API, когда вычисления идут на инфраструктуре провайдера. Компания не покупает собственное вычислительное оборудование и не обслуживает его внутри. Требования к инфраструктурной команде ниже, но интеграция, контроль качества моделей и управление данными всё равно остаются на стороне компании. Платит за использование: за токены, за вызовы, за подписку. Быстрый старт, минимальный порог входа, максимальная гибкость по мощности.
Гибридная модель — это архитектура, при которой одни задачи ИИ работают в облаке, а другие в собственном контуре компании. Часть контура остаётся в облаке (обычно публичные модели общего назначения, работа с внешними или обезличенными данными), часть на собственной инфраструктуре (задачи с чувствительными данными или высокими требованиями к отклику). Разделение чаще всего проходит по типу данных и задач, но также учитывает объём нагрузки, требования к отклику и экономику использования.
Собственный сервер для ИИ (on-premise) — это размещение всей AI-инфраструктуры в контуре компании: свои вычислительные мощности, свои данные, свои модели. Инфраструктура целиком в контуре компании: собственное оборудование, модели, развёрнутые под контролем компании, и собственная либо привлечённая команда сопровождения. Максимальный контроль над данными, кодом и стоимостью на длинной дистанции, при существенных первоначальных вложениях и требованиях к экспертизе.
Далее приведена таблица, по которой можно предварительно оценить, к какому сценарию тяготеет ваша ситуация. Три критерия, отмеченные оранжевым, определяющие: именно они чаще всего перевешивают все остальные и задают направление решения. Остальные уточняющие.
| Критерий | Облако | Гибрид | Собственный сервер |
|---|---|---|---|
| Чувствительность данных | Публичные, обезличенные | Смешанные, часть чувствительная | Персональные, коммерческая тайна, регулируемые |
| Регуляторные требования | Нет ограничений на трансграничную передачу | Часть данных должна оставаться внутри контура | Строгие требования к локализации и аудиту |
| Характер нагрузки | Пилоты, эпизодические задачи | Прогнозируемая нагрузка + пики | Постоянная высокая нагрузка, продакшн |
| Требования к отклику | Секунды, приемлемо | Смешанные | Предсказуемый низкий отклик, минимальная зависимость от внешних каналов |
| Горизонт использования | 6–12 месяцев, эксперименты | 1–2 года, отдельные направления | 3+ года, стратегическое направление |
| Наличие MLOps-компетенции | Минимальные компетенции или поддержка со стороны провайдера | Частично требуется | Требуется на постоянной основе |
| Готовность к капвложениям | Нет | Средняя | Высокая |
Таблица не даёт ответа автоматически, она показывает, к какому полюсу тянет каждый критерий. Если по большинству строк ситуация тяготеет к правой колонке (особенно если три отмеченных критерия смотрят вправо), разговор о собственной инфраструктуре обоснован. Если большинство слева, облако закрывает задачу дешевле и быстрее. Гибрид — не «золотая середина по умолчанию», а осознанный выбор, когда компания понимает, какой именно кусок и почему остаётся внутри.
Если предварительная оценка показывает, что компании действительно нужен собственный контур, следующий этап: определить технические требования к оборудованию. Подробнее об этом в статье «Как выбрать сервер для ИИ по техническим требованиям».
Когда собственная инфраструктура пока не нужна
Отдельно и честно. Часть компаний, которые сегодня задумываются о собственном AI-сервере, в реальности пока в нём не нуждаются. Это не значит «никогда», это значит «не сейчас».
Признаки, по которым можно понять, что момент ещё не настал:
- Компания находится на этапе первых пилотов, сценарии применения меняются каждые несколько месяцев, требования к моделям и мощностям ещё не устоялись
- Объём запросов небольшой и предсказуемо не вырастет в разы в ближайший год
- Данные, с которыми работает ИИ, не содержат чувствительной информации либо могут быть обезличены без потери качества
- Внутри нет команды, готовой сопровождать инфраструктуру, а нанимать её ради пилота не рационально
- Экономика облачных API комфортна и не создаёт давления на бюджет
В таких случаях облачные сервисы объективно выгоднее. Собственная инфраструктура — это долгосрочная инвестиция, которая окупается на стабильной, повторяющейся нагрузке и на данных, которые нельзя вынести наружу. Покупать её «на вырост», пока сценарии не сформированы, самый частый способ получить дорогой актив с низкой утилизацией.
Мы говорим об этом отдельно потому, что не считаем железо самоцелью. Правильный ответ для компании на раннем этапе часто именно облако с планом пересобрать инфраструктуру через год-два, когда картина прояснится.
Когда своё становится экономически оправданным
Экономика — второй по частоте вопрос после безопасности данных. И здесь важно разделить два уровня разговора: логику принятия решения и точные цифры. Первое можно освоить самостоятельно, второе всегда требует расчёта под конкретную конфигурацию.
Логика такая. Расходы на облачные сервисы обычно растут вместе с объёмом использования, хотя тарифные модели и скидки могут менять эту зависимость. В собственном контуре большая часть затрат возникает заранее (крупная первоначальная инвестиция плюс относительно постоянные расходы на электропитание, обслуживание, амортизацию и команду), поэтому при росте утилизации оборудования стоимость единицы обработки может снижаться.
Точка, где эти две кривые пересекаются, зависит от многих переменных: типа моделей, объёма запросов, требований к отклику, стоимости электроэнергии, зарплатных ожиданий команды, горизонта планирования. Универсального порога не существует, есть логика оценки, которую можно применить к своей ситуации.
При расчёте важно учитывать не только очевидные строки. Совокупная стоимость владения (TCO) — это все прямые и косвенные расходы на систему за выбранный горизонт, а не только цена железа. TCO включает подготовку и хранение данных, MLOps-команду, обновления, простои и запас на масштабирование. Это не «сколько стоит сервер», а сколько компания тратит на всю работоспособную систему за выбранный горизонт.
При первичной оценке полезно считать несколько горизонтов: например, год, три года и пять лет. На коротком горизонте облако часто выигрывает за счёт отсутствия крупных первоначальных вложений. На более длинном собственная инфраструктура может стать выгоднее, если нагрузка стабильна, мощности хорошо утилизируются, а расходы на сопровождение учтены реалистично. Универсального срока окупаемости нет, его нужно рассчитывать под конкретный сценарий.
Как меняются требования к инфраструктуре по мере развития AI в компании
Один из самых частых просчётов — выбирать инфраструктуру под текущий уровень зрелости, не глядя на то, куда компания движется через год-два. Далее три этапа развития AI-практики внутри бизнеса, и как на каждом из них меняется правильный ответ на вопрос про инфраструктуру.
Этап 1. Первый пилот. У компании один-два сценария применения, обычно вокруг внутренних задач: суммаризация документов, помощь с текстами, чат-бот для сотрудников или клиентов. Модели используются готовые, данных немного, требования к отклику мягкие. Наиболее практичным вариантом на этом этапе часто становится облако. Минимальный порог входа, быстрая проверка гипотез, никаких капвложений. Задача этапа — не оптимизировать стоимость, а понять, работает ли AI на вашем бизнесе в принципе.
Этап 2. Несколько рабочих сценариев. Пилоты прошли, часть сценариев переведена в постоянную работу. Появляются задачи с чувствительными данными: работа с внутренней документацией, обработка клиентских обращений, аналитика. Растёт нагрузка, стоимость облачных API становится заметной. На этом этапе компании часто начинают рассматривать гибридную модель. Публичные модели общего назначения остаются в облаке, а всё, что связано с внутренними данными и стабильной нагрузкой, переезжает в собственный контур. Появляется первая MLOps-функция, не полноценная команда, но выделенные компетенции.
Этап 3. Корпоративная AI-платформа. ИИ встроен в ключевые процессы: обслуживание клиентов, внутренняя аналитика, поддержка сделок, автоматизация внутренних операций. Есть постоянная нагрузка, десятки сценариев, требования по безопасности и отклику. На этом этапе основой становится собственный on-premise-контур. Локальная AI-инфраструктура используется там, где критичны безопасность данных, производительность и контроль, а облако остаётся для задач, где оно объективно эффективнее (обучение больших моделей, эксперименты, работа с внешними данными). Полноценная MLOps-команда, регламент управления моделями, аудит и мониторинг уже не «в идеале», а обязательные элементы.
Смысл этой шкалы — не в том, чтобы обозначить «правильную» траекторию, по которой должна пройти каждая компания. Не всем нужен третий этап; для многих оптимум — остаться на втором.
Смысл в том, чтобы решение по инфраструктуре принималось с оглядкой на следующий шаг, а не только на текущий. Купить сервер для первого пилота — почти всегда преждевременно. Оставаться в облаке, когда сценариев уже десятки и данные критичны, может приводить к росту затрат и рисков.
Типовые ошибки
По нашим наблюдениям, большинство неудачных или разочаровывающих AI-проектов повторяют одни и те же ошибки. Первые три почти всегда среди причин, когда «дорого купили, а результата нет».
Инфраструктура без бизнес-результата. Решение о покупке AI-сервера принимается «на будущее», без описанного сценария, метрики эффекта и владельца результата. Через год у компании есть железо и нет понимания, что оно должно делать. Правильный порядок — сначала сценарий применения и метрика, потом инфраструктура под них.
Данные, к которым не готовы. Главная причина, по которой AI-проекты не выходят за пределы пилота. Даже сильная модель не даст надёжного результата, если данные неполные, устаревшие, противоречивые или недоступны в нужном процессе. Если данные разбросаны по десяткам систем, дублируются или не имеют единой структуры — никакая инфраструктура этого не спасёт.
Отсутствие команды сопровождения. Собственная AI-инфраструктура — это операционная функция, а не разовая закупка. Модели нужно обновлять, метрики отслеживать, безопасность контролировать. Без выделенных ролей или подрядчика сервер быстро превращается в дорогой актив с низкой утилизацией.
Копирование чужой архитектуры. Соблазн повторить решение, о котором рассказали на конференции. Но архитектура другой компании отражает её объёмы, её данные и её команду, не ваши. Чужие кейсы полезны как источник вопросов, а не как готовый ответ.
Игнорирование горизонта. Выбор под сегодняшнюю нагрузку без учёта того, куда бизнес движется через год-два. Работает в обе стороны: и «купили большое на вырост, не выросли», и «сэкономили на старте, теперь пересобираем всё». Средний горизонт при принятии решения — 3 года.
Чек-лист перед пилотом
Прежде чем принимать решение о собственной инфраструктуре — тем более до закупки, имеет смысл честно ответить себе на четыре вопроса. Отмечайте каждый пункт для себя. Если хотя бы один ответ «пока нет», это сигнал вернуться к подготовке, а не двигаться к закупке.
Если все четыре ответа «Да», можно предметно обсуждать инфраструктуру. Если ответы есть не на все, сначала соберите их, потом возвращайтесь к разговору про сервер.
Частые вопросы
Что дальше
Этот текст даёт фреймворк для предварительной оценки: понять, куда тяготеет ваша ситуация, отсеять сценарии, которые точно не подходят, задать правильные вопросы внутри команды до разговора с интегратором. Он не заменяет обследования данных, расчёта архитектуры под конкретные нагрузки и оценки TCO под вашу конфигурацию. Всё это делается индивидуально, с погружением в бизнес.
Если после прочтения появилось ощущение, что вашей компании обоснованно нужна собственная или гибридная инфраструктура для ИИ, не откладывайте следующий шаг. Чем раньше эта оценка будет сделана предметно, тем меньше шансов принять решение под давлением счёта от облачного провайдера или запроса от юриста в последний момент. Мы готовы разобрать вашу ситуацию по фреймворку из этой статьи и подсказать, что нужно подготовить для точного расчёта.
Инком интер проектирует и поставляет серверы для корпоративной инфраструктуры с учётом нагрузки, требований к данным и дальнейшего масштабирования.