Фреймворк для 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 под вашу конфигурацию — всё это делается индивидуально, с погружением в бизнес.
Если после прочтения появилось ощущение, что вашей компании обоснованно нужна собственная или гибридная инфраструктура для ИИ — не откладывайте следующий шаг. Чем раньше эта оценка будет сделана предметно, тем меньше шансов принять решение под давлением счёта от облачного провайдера или запроса от юриста в последний момент. Мы готовы разобрать вашу ситуацию по фреймворку из этой статьи и подсказать, что нужно подготовить для точного расчёта.
Инком интер проектирует и поставляет серверы для корпоративной инфраструктуры с учётом нагрузки, требований к данным и дальнейшего масштабирования.