ИИ-пилот можно запустить быстро: взять готовую модель, подключить небольшой набор данных — и обкатать сценарий на ограниченной группе пользователей. Но в промышленной эксплуатации с нагрузкой дела обстоят иначе. По оценке IDC, глобальные расходы на ИИ-инфраструктуру в 2026 году достигнут 487 млрд. долл., прибавив около 53% за год. Такой рост показывает простую вещь: инфраструктура становится одной из главных статей ИИ-бюджета, а не технической деталью на стороне ИТ.
При этом сама по себе закупка мощностей ничего не гарантирует — можно купить дорогие карты и получить простои. Поэтому компании, которые выводят ИИ из пилота, начинают адаптировать не один сервер, а весь контур: от профиля нагрузки до метрик, безопасности и финансового учета.
Рассмотрим, как адаптировать инфраструктуру под новые нагрузки и почему недостаточно просто приобрести GPU.
Сначала сценарий, потом железо
Выражение «ИИ-инфраструктура» звучит так, будто речь идет об одном типе нагрузки — но на деле под ним скрываются разные задачи: обучение модели с нуля, дообучение, классический ML, генерация эмбеддингов. И у каждой задачи — свои узкие места, например голосовому ассистенту важна низкая задержка ответа, а для аналитики критична стоимость обработки большого объема данных.
Поэтому зрелые компании начинают с классификации сценариев. Они отвечают на несколько простых вопросов:
● кто будет пользоваться искусственным интеллектом;
● сколько запросов ожидается;
● насколько важна скорость первого ответа;
● какой объем контекста нужен;
● можно ли обрабатывать запросы пакетно;
● что происходит при задержке.
Без этого закупка «железа под ИИ» превращается в лотерею — инфраструктура может и не выдержать реальный сценарий.
Не всем нужен собственный обучающий кластер
Многие компании по инерции думают об ИИ-инфраструктуре как о кластере для обучения моделей. На практике большинству организаций он не нужен — у них нет ни объема данных, ни задач, ради которых стоит учить модель с нуля.
Для внутренних ассистентов, поиска по базе знаний, обработки обращений, подготовки документов и поддержки разработчиков лучше идти другим, более простым путем. Достаточно взять готовую модель, развернуть ее у себя или провайдера, подключить корпоративные данные и настроить инференс.
«Спроектировать инференс-платформу» звучит не так эффектно, как «построить суперкомпьютер» — зато это ближе к реальным задачам бизнеса.
GPU недостаточно просто купить — нужно научиться использовать
Самая дорогая ошибка — считать, что проблема решается количеством карт. В действительности GPU часто простаивают, в то время как команды жалуются на нехватку мощностей.
Это видно и по рынку: в отчете Cast AI за 2026 год средняя утилизация GPU в Kubernetes-кластерах составила всего 5%. Проблема эта редко связана с плохой организацией — чаще всего она структурная. В Kubernetes GPU в большинстве случаев воспринимается как неделимая единица: приложение запросило карту — получило ее целиком, а использует только часть мощности. В итоге дорогое оборудование формально занято, а фактически не загружено.
Компании решают этот вопрос несколькими способами, например делят карту на изолированные части или выбирают инференс-серверы, которые умеют эффективнее упаковывать запросы.
Карты без сети и хранилища тоже простаивают
ИИ-нагрузки быстро показывают, что GPU — лишь часть инфраструктуры. Если данные и веса модели не успевают подаваться на узел, карта ждет. Бизнес при этом платит за дорогое оборудование, которое не делает полезной работы.
Для больших моделей это становится отдельной инженерной задачей. Модель на 70 млрд. параметров в FP8 может весить около 70 Гб, а флагманские модели — сотни гигабайт. Их нужно быстро доставлять, хранить, обновлять и переиспользовать между узлами.
Поэтому инфраструктура под ИИ должна включать сеть, хранилище, интерконнект, параллельную файловую систему и механику доставки весов. Если этого не сделать, компания покупает не мощность, а дорогую очередь ожидания.
Обычные метрики не показывают качество ИИ-сервиса
Классический мониторинг приложений плохо описывает ИИ-нагрузку. Для
Важно, что эти показатели нельзя оптимизировать для всех сценариев. Голосовому боту важен быстрый первый ответ, batch-аналитике — минимальная стоимость обработки. Поэтому зрелые команды задают SLO под конкретную ситуацию: для кого работает ИИ, какая задержка допустима, сколько компания готова платить за миллион токенов.
Модель нельзя встраивать напрямую в каждое приложение
Быстрый путь — подключить LLM прямо к монолиту или внутреннему порталу. На пилоте это удобно, однако в промышленной эксплуатации такой подход становится дорогим.
Почему это происходит:
● становится сложнее переключить провайдера;
● приложение оказывается привязано к конкретной модели;
● почти невозможно нормально рассчитать расходы по командам;
● промпты и ответы выпадают из общего мониторинга.
Рабочий вариант в таком случае — вынести работу с моделями в отдельный слой, ИИ-шлюз. Он становится единой точкой для квот, логирования, PII-фильтрации, кэширования, переключения моделей и контроля расходов.
RAG требует архитектуры доступа
RAG часто становится первым массовым корпоративным ИИ-сценарием: компания подключает документы, базы знаний, инструкции и хочет, чтобы сотрудники задавали вопросы на естественном языке. Однако вместе с пользой возникает и новый риск.
Если права пользователя не участвуют в самом поисковом запросе, а фильтрация происходит уже после извлечения документов, векторная база превращается в канал переноса информации между отделами — быстрый, удобный и не оставляющий следов в привычных журналах доступа. Надеяться на фильтрацию постфактум нельзя, так как она регулярно пропускает содержимое чужих документов в ответы.
Именно поэтому в корпоративном RAG роль, права доступа и подразделение пользователя должны быть частью самого запроса к индексу. Если гарантировать это архитектурно не получается, корпус должен сужаться до публичных документов — сегодня других надежных и безопасных вариантов тут нет.
Стоимость нужно считать в токенах с первого дня
ИИ-инфраструктура меняет привычный финансовый учет ИТ. Раньше компания считала серверы, лицензии, облачные ресурсы и человеко-часы. В ИИ-сервисах новой единицей стоимости становится токен.
На пилоте это легко недооценить — слишком мало пользователей и запросов. В промышленной эксплуатации растут конкурентность, длина контекста, число пользователей, резервирование и объем логирования. Стоимость начинает расти нелинейно.
Подсчет токенов нужен с первого дня. Компания должна понимать, кто генерирует расходы, какие сценарии самые дорогие, где можно кэшировать ответы, где подойдет более дешевая модель, а где оправдана премиальная.
Платформа лучше разрозненных запусков
Один из частых антипаттернов — когда каждый отдел сам разворачивает модель. На старте это кажется отличной возможностью не тормозить команды, однако вскоре компания получает дублирование расходов, разный уровень безопасности, отсутствие прозрачности и несколько точек риска.
Но зрелая схема устроена иначе. Есть единый платформенный слой: инфраструктура, ИИ-шлюз, квоты, аудит, мониторинг, безопасность и SLA. Продуктовые команды отвечают за свои сценарии — промпты, корпус знаний, качество ответов, бизнес-эффект.
Отдельный признак зрелости системы — оценка качества, evals. Без «золотого» набора примеров и регрессионного прогона невозможно ответить на вопрос, стало ли лучше после смены промпта или модели — и таким образом решения принимаются лишь на ощущениях.
Зрелые команды относятся к промпту как к артефакту релиза: он версионируется, выкатывается постепенно и откатывается при деградации. Важно тут то, что закладывать evals нужно с первого дня, так как задним числом их уже не собрать. Так искусственный интеллект становится частью корпоративной архитектуры, переставая быть набором локальных экспериментов.
Подведем итоги
Адаптация ИТ-инфраструктуры под ИИ-нагрузки начинается с понимания сценариев: кому нужен искусственный интеллект, как часто, на каких данных, с какими рисками и за какие деньги.
Компании, которые проходят этот путь осознанно, проектируют управляемый контур — инференс-платформу, правильные метрики, ИИ-шлюз, безопасный RAG, подсчет токенов и единые правила для всех команд. Не нужно делать его максимальным, перегружать всем и сразу — достаточно контроля, ясности и обратимости, то есть готовности сменить модель или провайдера, когда профиль нагрузки изменится.
