Гонка за ИИ-инфраструктурой: кто победит в 2026 году

Аннотация: В 2026 году преимущество получают не компании с самым большим числом ИИ-пилотов, а те, кто умеет превращать эксперименты в управляемые сервисы. Разбираемся, из чего состоит зрелая ИИ-инфраструктура, сколько она стоит и почему без единой платформы её трудно масштабировать.

 

  

 

 

 

1. 1. Введение
2. 2. Гонка 2026 года в пяти цифрах
3. 3. После пилота начинается инфраструктура
4. 4. Разрозненные сервисы не масштабируются
5. 5. Безопасность ИИ по умолчанию
6. 6. Считать придётся не только токены
7. 7. Разрыв между интересом и готовностью к ИИ
8. 8. Кто же победит в гонке?
9. 9. Выводы

Введение

Ещё год назад разговор о внедрении искусственного интеллекта в компаниях начинался с выбора большой языковой модели (LLM). Какую модель подключить, насколько хорошо она пишет по-русски, можно ли собрать на её основе корпоративный чат или поиск по базе знаний? В 2026 году гораздо важнее другое: способна ли компания превратить удачный ИИ-пилот в эффективный сервис, которым безопасно пользуются сотни или тысячи сотрудников?

По опыту Orion soft, в 2025 году многие заказчики подключали облачные модели и запускали пилоты без полной уверенности в их экономическом эффекте. В 2026 году стало больше крупных проектов, цель которых — перенести успешные эксперименты в промышленную эксплуатацию. Именно на этом этапе выясняется, что сама LLM — лишь часть решения, а одним из главных ограничений становится инфраструктура.

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

Гонка 2026 года в пяти цифрах

Масштаб разрыва между интересом к ИИ и готовностью к его промышленной эксплуатации показывают результаты исследования Orion soft и данные проектов компании. Ключевые показатели выглядят так:

• 108 руководителей и специалистов приняли участие в исследовании Orion soft «Индекс зрелости ИИ-инфраструктуры российских компаний — 2026».
• 38 баллов из 100 составил средний индекс зрелости. По методике исследования это начальный уровень.
• 79 % респондентов сообщили, что в их компаниях нет профильных специалистов для развития ИИ-инфраструктуры.
• 91 % респондентов сообщили, что их компании не располагают собственным кластером из двух и более серверов с промышленными GPU.
• Около 33,5 млн рублей в год составляет фонд оплаты труда минимальной команды, способной развивать внутреннюю ИИ-платформу. Оценка основана на данных примерно 20 компаний.

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

После пилота начинается инфраструктура

Прототип ИИ-сервиса сегодня можно собрать за несколько дней. Иногда для этого достаточно подписки на облачную модель и небольшой разработки. Но между демонстрацией и промышленной эксплуатацией — большая дистанция. На этом этапе появляются требования к доступности, масштабированию, безопасности, мониторингу, бюджету и качеству ответа. Модель нужно обновлять без длительного простоя, запросы — маршрутизировать, действия пользователей — журналировать, а данные — обрабатывать в соответствии с политиками компании.

Поэтому любую ИИ-инициативу предлагаем рассматривать сразу на трёх связанных уровнях:

1. Прикладной: конкретный сервис, встроенный в бизнес-процесс. Это может быть транскрибация встреч, поиск по корпоративной документации, обработка обращений в техподдержку или автоматизация работы с документами.
2. Инфраструктурный: среда, в которой сервис разрабатывается и эксплуатируется. К этому уровню относятся оркестрация, управление доступом, сеть, хранение, наблюдаемость, отказоустойчивость, жизненный цикл моделей и средства информационной безопасности.
3. Аппаратный: GPU, серверы, соединяющая их сеть, хранилище, охлаждение и электропитание.

Проблемы возникают, когда эти уровни проектируют независимо. В одном из разобранных нами случаев компания приобрела сервер примерно за 40 млн рублей, но выбранный инфраструктурный слой не позволил задействовать преимущества аппаратной конфигурации. Стоимость неиспользуемых возможностей оборудования оценивалась примерно в 20 млн рублей на сервер. В другом проекте тяжёлую модель распределили между узлами, соединёнными Ethernet со скоростью 10–20 Гбит/с, и получили падение производительности примерно на 90 %.

Аппаратный слой также нельзя сводить к выбору GPU. Некоторые современные ИИ-системы потребляют свыше 10 кВт, а мощность стоечных комплексов последнего поколения может достигать примерно 120 кВт. Поэтому ещё до закупки GPU-инфраструктуры необходимо проверить, готов ли ЦОД обеспечить требуемые питание, охлаждение и сетевую связность. Планировать ИИ-проект лучше в следующей последовательности:

1. Зафиксировать конкретную бизнес-задачу, владельца процесса и измеримую метрику эффективности.
2. Описать функциональные и нефункциональные требования, включая соглашение об уровне обслуживания (SLA), безопасность и интеграции.
3. Выбрать модель или короткий список моделей и проверить качество на реальных сложных запросах.
4. Рассчитать нагрузку: число одновременных пользователей, количество запросов в секунду (RPS), длину контекста и 95-й процентиль задержки (p95).
5. Только после этого выбирать GPU, серверы, сеть, хранилище и инфраструктурную архитектуру.

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

 

Рисунок 1. Цели использования ИИ в компаниях

 

Хорошая постановка задачи звучит не как «нам нужен корпоративный ИИ», а, например, как «с помощью ИИ мы хотим сократить среднее время обработки обращения с 20 до 10 минут». Состояние процесса до внедрения нужно зафиксировать заранее, иначе компания не сможет отделить эффект ИИ от других изменений.

Разрозненные сервисы не масштабируются

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

Теневой ИИ (Shadow AI) — несанкционированное использование ИИ в корпоративной среде. Оно приводит к появлению разных поставщиков, правил доступа и API-ключей, а также затрудняет контроль данных, которые сотрудники отправляют во внешние модели.

Пока пользователей десять, набором сервисов можно управлять вручную. Но когда их становится сто или тысяча, появляются дублирующие инструменты, конфликтующие правила, непрозрачные расходы и зависимость от людей, которые создавали отдельные системы. Единая корпоративная ИИ-платформа даёт командам изолированные рабочие пространства, управляет квотами и доступом, хранит каталог моделей, поддерживает контуры разработки, тестирования и промышленной эксплуатации, собирает технические и продуктовые метрики. Новую модель или сервис можно подключить по единой процедуре, а не строить для каждого проекта отдельную инфраструктуру.

Важно не путать полноценную платформу с установленной LLM. По опыту Orion soft, один инженер может за две недели развернуть Kubernetes, vLLM и веб-интерфейс, а ещё примерно за неделю добавить прототип системы генерации ответов на основе корпоративных данных (RAG). Такой стенд подходит для экспериментов, но в нём ещё нет полноценного управления секретами и уязвимостями, контроля изменений, резервного копирования, учёта GPU, управления жизненным циклом моделей и стабильной эксплуатации.

По данным примерно 20 компаний, минимальная команда внутренней платформы включает:

• двух платформенных DevOps-инженеров;
• инженера по ML-инфраструктуре с экспертизой по GPU;
• SRE-инженера;
• ML-инженера;
• архитектора или технического лидера.

При использованных в расчёте зарплатах до вычета налогов совокупный ФОТ такой команды составляет около 33,5 млн рублей в год. Это не временная команда разработки: она должна постоянно сопровождать платформу, на которой впоследствии могут работать от 50 до 200 специалистов.

По оценкам представителей десяти внутренних платформенных команд, их рабочее время в среднем распределяется следующим образом:

• 30 % — операционные задачи и инциденты;
• 30 % — обновления и обеспечение совместимости компонентов;
• 20 % — новые функции по запросам пользователей;
• 10 % — безопасность и аудит;
• 10 % — документация и обучение.

До зрелого состояния такие платформы развиваются в среднем около двух лет, а наблюдаемый диапазон составляет от полутора до трёх лет. Только ФОТ минимальной команды за два года приближается к 70 млн рублей.

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

Безопасность ИИ по умолчанию

При массовом использовании LLM безопасность перестаёт быть отдельным проектом службы ИБ и становится свойством всей инфраструктуры.

Речь не только об утечке конфиденциальных данных во внешнюю модель. Необходимо учитывать и другие риски:

• промпт-инъекции;
• небезопасные или некорректные ответы;
• доступ агентов к внутренним системам;
• уязвимости контейнеров, средств запуска моделей, модельных артефактов и компонентов цепочки поставки;
• хранение API-ключей и других секретов;
• состав данных и права доступа к ним в RAG-системах.

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

• ролевая модель доступа (RBAC);
• централизованное управление секретами;
• аудит и журналирование действий;
• сканирование артефактов и уязвимостей;
• сетевая изоляция;
• разделение контуров разработки, тестирования и промышленной эксплуатации.

На уровне работы с моделями нужен единый ИИ-шлюз с политиками для входящего и исходящего трафика. Он может выявлять в запросе признаки персональных данных, маскировать их, направлять запрос в разрешённую облачную модель или переключать его на локальную. Через тот же слой компания получает централизованный доступ к моделям, учёт потребления и контроль API-адресов, которые используют информационные системы.

 

Рисунок 2. Меры защиты ML-систем

 

Так безопасность перестаёт быть финальной проверкой перед запуском. Защитные механизмы закладываются в архитектуру с первого дня и применяются к каждому новому сервису по единым правилам.

Считать придётся не только токены

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

Для локальных моделей особенно важна загрузка GPU: дорогой кластер, загруженный на 10–20 %, может оказаться менее выгодным, чем облако. При стабильной высокой нагрузке картина меняется. В одном из сравнений Orion soft стоимость месячной аренды сопоставимых конфигураций у крупных облачных провайдеров пересчитали на три года и сопоставили с собственным оборудованием. В расчёт локальной инфраструктуры вошли закупка, размещение и электроэнергия.

При таких допущениях облачный вариант оказался примерно втрое дороже. Стоимость сотрудника, обслуживающего локальную инфраструктуру, в расчёт не входила, поэтому применять это соотношение как универсальную формулу нельзя.

Важен и фактор времени: по опыту проектов Orion soft, поставка GPU-оборудования в России занимает в среднем от шести до восьми месяцев. Поэтому выбор зависит не только от совокупной стоимости владения (TCO), но и от стадии проекта:

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

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

Практический пример показывает, почему расчёт нужно проводить на реальной задаче. В одном промышленном проекте сервер с четырьмя H200 и 564 ГБ видеопамяти обслуживал корпоративный чат для 500 сотрудников. На простых запросах длиной около 1 000 входных и 1 000 выходных токенов система обрабатывала примерно 8 RPS. После добавления RAG, модели векторизации (embedder) и модели ранжирования (reranker) производительность снизилась примерно до 0,5 RPS, а время ответа при фактической нагрузке достигало двух-трёх минут. Формально модель работала, но требования к удобному сервису уже не выполнялись.

Другой проект начинался с конкретной метрики. Финансовой организации требовалось локально транскрибировать до 6 000 часов аудио в сутки для 3 000 сотрудников. Сервис в промышленной эксплуатации на четырёх H200 справлялся с нагрузкой с запасом около 12 %, ещё один сервер использовался для отказоустойчивости. От поставки оборудования до промышленного результата прошло около трёх месяцев. Оборудование и программное обеспечение стоили примерно 120 млн рублей без учёта ФОТ.

По укрупнённой оценке заказчика, автоматизация экономила около 1 000 рабочих часов в день, или примерно 264 млн рублей в год. Эта оценка окупаемости инвестиций (ROI) не проходила независимый аудит, но показывает принцип расчёта: стоимость инфраструктуры нужно сопоставлять с изменением конкретного процесса, а не с количеством купленных GPU.

По мере роста зрелости расчёты становятся подробнее. Сначала компания оценивает затраты на сервер или облачный счёт. Затем она определяет стоимость запроса и токена, загрузку каждого GPU, потребление ресурсов отдельными сервисами и расходы подразделений. Но управление затратами на ИИ (FinOps) не должно заканчиваться на инфраструктуре. Вместе с техническими показателями нужно учитывать продуктовые метрики:

• сэкономленные рабочие часы;
• долю автоматически обработанных обращений;
• скорость документооборота;
• точность и полноту ответа;
• стоимость ошибки;
• влияние на финансовый результат.

Такой набор показателей позволяет увидеть не только стоимость ИИ-сервиса, но и его пользу для бизнеса. Если инфраструктурные расходы не связаны с изменением конкретного процесса, оценить эффективность проекта невозможно.

Разрыв между интересом и готовностью к ИИ

Летом 2026 года Orion soft опросила 108 ИТ-директоров, руководителей AI- и ML-направлений, архитекторов, специалистов по информационной безопасности и цифровой трансформации. Средний индекс зрелости ИИ-инфраструктуры составил 38 баллов из 100. По методике исследования это начальный уровень.

При этом запрос бизнеса уже сформирован: почти половина респондентов сообщила, что их компании внедрили одну-две ИИ-инициативы, ещё 31 % заявили о планах по внедрению. В то же время 79 % участников указали на отсутствие профильных специалистов, а 91 % — собственного кластера из двух и более серверов с промышленными GPU.

 

Рисунок 3. Масштаб GPU-инфраструктуры в компаниях

 

Разрыв особенно заметен при сравнении с промышленным масштабом. В проектах, дошедших до промышленной эксплуатации, вычислительный контур обычно включает несколько реплик и резерв мощности. В практике Orion soft промышленный кластер насчитывал от 10 до 32 GPU-серверов. На крупных платформах, включающих более 30 серверов, одновременно работают несколько проектов и команд. Поэтому количество пилотов само по себе больше не является признаком лидерства.

Зрелость проявляется иначе: компания ограничивает исследования и разработки (R&D) по срокам, сравнивает решения на реальных тестах, закрывает неудачные гипотезы, по единым процедурам выводит успешные сервисы в промышленную эксплуатацию и понимает стоимость каждого сценария.

Кто же победит в гонке?

Больше шансов на лидерство у компаний, которые выстроили зрелое управление ИИ-ресурсами и умеют расставлять приоритеты. Такую организацию можно определить по пяти признакам:

1. Бизнес-задача предшествует закупке. Для каждого сервиса зафиксированы владелец, исходная метрика и целевое изменение процесса.
2. Пилот имеет ограниченный срок и критерии остановки. Команда прекращает исследования и разработки, если модель не даёт нужного качества.
3. Успешный сценарий выводится в промышленную эксплуатацию по единой процедуре. Доступы, окружения, мониторинг, обновление и откат не собираются заново для каждого проекта.
4. Локальные и облачные модели работают в едином управляемом контуре. Маршрутизация учитывает тип данных, качество ответа, задержку, безопасность и стоимость.
5. Технические метрики связаны с бизнес-эффектом. Компания видит не только количество токенов и загрузку GPU, но и сэкономленное время, стоимость ошибки, влияние на выручку или расходы.

В 2026 году конкурентное преимущество создают уже не отдельные сервисы и даже не сами языковые модели. Его определяет способность организации быстро, безопасно и экономически эффективно превращать новые технологии в управляемые бизнес-инструменты.

Искусственный интеллект проходит путь, который ранее прошли виртуализация, облачные платформы и Kubernetes: отдельные внедрения постепенно объединяются в общую инфраструктуру. Преимущество получат компании, которые свяжут вычислительные ресурсы, безопасность, управление доступом, контроль затрат и процессы эксплуатации.

Выводы

В 2026 году зрелость корпоративного ИИ определяется не количеством запущенных пилотов, а способностью компании масштабировать успешные сценарии. Для этого необходимо решить три задачи:

• проектировать прикладной, инфраструктурный и аппаратный уровни как единую систему;
• встроить безопасность, управление доступом и контроль затрат в платформу;
• оценивать ИИ-сервисы по их влиянию на бизнес-процессы, а не только по стоимости моделей и оборудования.

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