Опыт развертывания корпоративной/ведомственной ИИ-инфраструктуры

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

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

Почему ИИ-инфраструктура не похожа на обычную ИТ-инфраструктуру

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

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

Отдельно поясню два термина, которые полезно запомнить.

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

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

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

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

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

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

Практический опыт: как мы столкнулись со сложностями

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

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

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

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

В-третьих, у компании начинает формироваться «зоопарк» технологий: разные модели, разные серверы, разные команды поддержки, разные интерфейсы, разные подходы к безопасности и учету затрат. Такой ландшафт плохо масштабируется организационно и почти не управляется экономически.

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

Почему централизация — это не бюрократия, а способ снизить TCO

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

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

Так мы пришли к подходу, который внутри называем концепцией «единых моделей». Важно подчеркнуть: речь не о том, что в компании должна существовать буквально одна-единственная модель. На нынешнем этапе это нереалистично. Речь о другом: о минимально достаточном унифицированном наборе моделей, который централизованно разворачивается и поддерживается владельцем платформы.

 Логика следующая:

роли владельца платформы и владельцев сервисов должны быть четко разделены;

проектные команды не должны самостоятельно закупать GPUинфраструктуру или бесконтрольно покупать токены у внешних SaaS-поставщиков;

вместо этого они получают доступ к централизованному набору моделей через единую платформу;

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

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

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

Какой набор моделей разумен для корпоративного контура

Условно разделим большие языковые модели на три класса.

Малые модели — порядка 1–15 млрд параметров. Их основное преимущество — низкий порог входа. Они могут работать даже на одной относительно недорогой видеокарте с объемом памяти до 16–32 ГБ. Некоторые, самые маленькие, даже без видеокарты. Это хороший способ начать эксперименты, проверить гипотезы, встроить простые ИИ-функции в отдельные процессы. Однако в серьезных корпоративных сценариях их возможностей часто будет недостаточно. Они слабее в сложном анализе, хуже работают на длинном контексте, чаще допускают фактические ошибки и галлюцинации.

Средний класс — условно 20–100 млрд параметров. По нашему опыту, это оптимальный класс для промышленного внедрения: такие модели дают заметно более высокое качество и могут быть развернуты достаточно компактно — например, помещаться вместе с большим контекстным окном на одну современную профессиональную видеокарту высокого класса. Это резко упрощает масштабирование и снижает потери производительности, связанные с обменом данными между несколькими GPU.

Флагманские модели — от 100 млрд параметров и выше. Они действительно сильны, но требуют существенно более сложной и дорогой инфраструктуры: нескольких передовых профессиональных ускорителей на один экземпляр модели, более сложной схемы размещения, более дорогой эксплуатации. Для узкого круга задач это может быть оправдано. Для массовой корпоративной эксплуатации — далеко не всегда.

Важно понимать: увеличение количества параметров не гарантирует пропорционального роста полезности. Между классами нет магической пропасти, но в среднем зависимость между размером модели и ее когнитивными возможностями действительно есть.

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

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

Почему расчет потребности в мощностях — самая недооцененная задача

Когда компания планирует развертывание ИИ-инфраструктуры, она чаще всего задает неправильный стартовый вопрос: «Сколько ускорителей нам нужно?» Правильные вопросы звучат иначе: какую реальную нагрузку будут создавать корпоративные ИИсервисы, какой уровень отклика для них является приемлемым, какая модель и инфраструктура нужна, чтобы обеспечить эти требования?

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

Для прогнозирования нагрузки обычно рассчитываются следующие метрики:

среднее потребление токенов в секунду в рабочее время; y потребление в пиковый час;

прогнозируемое число параллельных сессий;

требования к задержке (SLA);

фактическая пропускная способность модели в токенах в секунду при соблюдении SLA.

Если совокупное потребление начинает превышать эффективную пропускную способность кластера, модель замедляется, возникают деградация пользовательского опыта, а затем — нарушения SLA. С этого момента нужен либо еще один экземпляр модели, либо оптимизация производительности модели или самого сервиса (программного кода).

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

недооценка нагрузки. В этом случае запуск вроде бы и состоится, но спустя короткое время система начнет «тормозить». В итоге пилот создает плохое впечатление, а бизнес делает вывод, что технология переоценена;

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

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

Что на самом деле входит в TCO ИИ-инфраструктуры

Еще одна частая ошибка — считать только стоимость сервера или аренды мощностей. Для генеративного ИИ этого недостаточно.

Полный TCO включает как минимум следующие компоненты:

стоимость закупки или аренды GPU-инфраструктуры;

расходы на программный стек инференса и платформенные компоненты;

расходы на команду эксплуатации и поддержки;

стоимость обновления моделей и обязательного регрессионного тестирования качества ИИ сервисов;

потери от недозагрузки инфраструктуры;

затраты на безопасность, контуры доступа, аудит и контроль использования.

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

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

Почему платформа важнее, чем просто набор серверов

Если говорить о промышленной эксплуатации, то компаниям нужна не просто ферма GPU, а корпоративная инференс-платформа.

Мы пришли к этому на собственном опыте. Только наличие платформы позволяет превратить ИИ из серии разрозненных экспериментов в управляемую и эффективную модель потребления.

Что принципиально важно в такой платформе: y единая точка входа к моделям;

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

корпоративная аутентификация и разграничение прав;

удобное самообслуживание по ключам доступа;

централизованное развертывание и масштабирование моделей;

маршрутизация и балансировка нагрузки;

мониторинг производительности и загрузки;

лимиты, бюджеты и административные механизмы;

учет потребления и расчет стоимости для потребителей.

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

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

Важно различать два принципиально разных сценария.

Первый — полноценное обучение или дообучение с изменением весов модели. Это требует больших объемов специально подготовленных данных, сильной ML-команды, выделенных GPU-ресурсов и отдельной системы оркестрации вычислений. Такой контур оправдан у компаний, для которых разработка собственных моделей — стратегическая деятельность.

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

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

Скрытая статья экономии: оптимизация инференса

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

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

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

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

Основные риски, которые нельзя игнорировать

Помимо экономики и архитектуры корпоративная ИИ-инфраструктура в России сталкивается с целым набором рисков.

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

Во-вторых, санкционные и логистические риски. Поставки оборудования в целом возможны, но условия рынка могут меняться. Самая чувствительная сложность — не доставка как таковая, а отсутствие полноценной вендорской поддержки, что осложняет гарантийное обслуживание и ремонт.

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

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

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

Основные рекомендации для бизнеса

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

1. Начинайте не с закупки GPU, а с проектирования корпоративной модели потребления ИИ. Нужно понять, какие сервисы будут использовать модели, какие SLA им нужны, какова ожидаемая динамика нагрузки, как будет устроен учет потребления.
2. Старайтесь как можно раньше уходить от очаговых внедрений к централизованной платформе. Это почти всегда снижает порог входа для новых команд и уменьшает TCO.
3. Минимизируйте «зоопарк» моделей. Унифицированный набор из нескольких тщательно выбранных моделей обычно эффективнее и дешевле, чем множество специальных развертываний под каждый кейс.
4. Для массовых корпоративных сценариев ориентируйтесь прежде всего на сильные модели среднего класса. Именно они чаще всего дают лучший баланс между качеством и стоимостью эксплуатации.
5. Не переоценивайте необходимость собственного обучения моделей на старте. Во многих случаях наибольший эффект дает не обучение весов, а правильная инженерия решения вокруг предобученной модели.
6. Закладывайте в проект не только CAPEX, но и полноценный OPEX: платформу, команду, обновления моделей, тестирование, безопасность, мониторинг и учет потребления.
7. Развивайте компетенции по инференсу как самостоятельное направление. Именно здесь скрыт крупный резерв снижения затрат без потери качества.

Что в итоге

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

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

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