Разговор о проблемах развертывания ИИ-инфраструктуры часто ведется на макроуровне: дефицит вычислительных мощностей, стоимость ускорителей, зависимость от внешних поставщиков, регуляторные ограничения. Все это важно, но если посмотреть на ситуацию глазами специалиста, которому предстоит решить эту задачу, вопрос становится более прикладным: как развернуть корпоративную ИИ-инфраструктуру, чтобы она не превратилась в дорогой, трудноуправляемый и слабо загруженный набор серверов?
За последние два года многие компании, в том числе и IBS, прошли путь от первых экспериментов с генеративным ИИ до промышленной эксплуатации корпоративной платформы, на которой работают большие языковые модели и множество корпоративных сервисов и информационных систем. Этот опыт показал: главный дефицит сегодня — не в санкционном оборудовании. Гораздо более остро ощущается дефицит зрелых решений в области построения эффективной модели управления корпоративной инфраструктурой ИИ: архитектурных и организационных стандартов, программного обеспечения и методики расчета потребностей.
Мы проанализировали, где компании чаще всего ошибаются при оценке потребности в вычислительных ресурсах, почему локальная ИИ-инфраструктура плохо сочетается с «зоопарком» моделей ИИ и разрозненными инициативами, как меняется логика расчета TCO и почему централизованная платформа ИИ почти всегда выгоднее множества отдельных внедрений. Кроме того, сфокусировались именно на инфраструктуре генеративного искусственного интеллекта и больших языковых моделей как ключевом драйвере, обеспечивающим быструю трансформацию бизнеса.
Первая ошибка в расчетах ТСО может заключаться в том, что инфраструктуру генеративного ИИ пытаются рассчитать в категориях традиционных корпоративных систем. Однако в случае с большими языковыми моделями это работает плохо.
Классическую инфраструктуру мы обычно оцениваем через CPU, RAM, дисковую подсистему, сетевые характеристики и запас по отказоустойчивости. Для ИИ этого недостаточно. Здесь ключевое значение приобретают совсем другие параметры: пропускная способность конкретной модели в токенах в секунду, размер контекста, характеристики инференс-движка, эффективность кэширования, режимы параллельной обработки запросов, профиль пользовательской нагрузки.
Отдельно поясню два термина, которые полезно запомнить.
Инференс — это стадия практической эксплуатации модели, когда она уже не обучается, а обрабатывает реальные запросы пользователей и прикладных систем. Именно инференс в корпоративном контуре генеративного ИИ обычно формирует основную долю текущих операционных расходов, т. е. OPEX.
Плотность интеллекта — условный, но полезный практический термин. Под ним подразумевается соотношение полезных когнитивных возможностей модели к стоимости ее эксплуатации. Иными словами, насколько «умна» модель на единицу инфраструктурных затрат. Для бизнеса это часто важнее, чем абстрактная гонка за максимальным числом параметров.
Уже в самом начале пути специалист, занимающийся подготовкой ИИ-инфраструктуры, столкнется с первыми сложностями: он обнаружит, что языковая модель — это не виртуальная машина, которую можно быстро «поднять» под конкретную задачу и затем быстро «погасить». Чтобы корпоративный сервис, интегрированный с ИИ, работал оперативно, модель должна постоянно находиться в памяти GPU, а загрузка крупной модели в видеопамять занимает минуты, иногда и десятки минут.
Это означает, что инфраструктуру приходится проектировать не под точечные вычисления и конкретные задачи, а под постоянное присутствие модели в памяти и с прогнозируемой рабочей нагрузкой.
Есть и вторая важная особенность. Один экземпляр развернутой модели чаще всего оказывается слишком производительным для одного отдельно взятого корпоративного сервиса. За счет кэширования, параллельной обработки и других методов оптимизации один экземпляр может обслуживать сразу несколько, а иногда и десятки сервисов и команд. Это, конечно, зависит от способа реализации, количества активных пользователей и других параметров, но в абсолютном большинстве сценариев отдельный сервис просто не способен эффективно «выбрать» весь потенциал модели.
Решение, которое лежит на поверхности, — развернуть менее требовательную модель для экономии ресурсов — на практике оказывается нежизнеспособным. Меньшая модель означает худшее качество обработки данных и, соответственно, меньшие бизнес-эффекты, а зачастую и полное их отсутствие (модель слишком слаба для целевой бизнес-задачи). Именно поэтому разрозненные внедрения всегда менее эффективны и экономически оправданы по сравнению с комплексной стратегией ИИ-трансформации, предусматривающей дорожную карту внедрения сразу целого ряда ИИ-сервисов, работающих на централизованной инфраструктуре ИИ.
Эксперименты с локальными языковыми моделями мы начинали еще в 2023-м году. Первые сценарии были понятными: помощь разработчикам, генерация кода, тестов, автоматизация ревью, работа с корпоративными знаниями, поддержка текстовых процессов.
На раннем этапе инициативы росли естественным образом — снизу — вверх. Разные команды самостоятельно выбирали модели, искали способы развертывания, решали вопрос с арендой или закупкой вычислительных ресурсов, настраивали интеграции и пытались обеспечить эксплуатацию своими силами. Такой подход кажется логичным, когда технология только появляется, но очень быстро становятся видны его ограничения.
Во-первых, порог входа в каждый новый ИИ-проект остается стабильно высоким. Команде нужно не только придумать бизнес-сценарий, но и решить инфраструктурную задачу, которая сама по себе сложный и дорогой проект.
Во-вторых, из-за бюджетных ограничений большинство пилотов, где требуется локальный ИИ, строятся на малых моделях. Они доступны, помещаются в недорогие видеокарты, но зачастую не обеспечивают нужного качества: хуже держат длинный контекст, чаще ошибаются, менее устойчивы в сложных рассуждениях и агентных сценариях.
В-третьих, у компании начинает формироваться «зоопарк» технологий: разные модели, разные серверы, разные команды поддержки, разные интерфейсы, разные подходы к безопасности и учету затрат. Такой ландшафт плохо масштабируется организационно и почти не управляется экономически.
Постепенно становится очевидным, что децентрализованный подход одновременно создает высокий порог входа и высокий риск неудачи, потому что команды экономят на модели и инфраструктуре, а затем получают слабый результат и разочаровываются в самой технологии. Именно в этот момент мы пришли к необходимости централизации.
Идея централизации ИИ-инфраструктуры может вызвать скепсис. Например, есть мнение, что это замедляет инновации. На практике при зрелом управлении происходит обратное.
Большая языковая модель — универсальное вычислительное ядро. Она может применяться в разработке, аналитике, финансах, документообороте, обучении, поддержке пользователей, поиске по знаниям, обработке текста, а в случае мультимодальных моделей — и изображений, аудио, видео. Это значит, что дорогостоящий вычислительный ресурс целесообразно использовать коллективно, а не выделять под каждую отдельную инициативу.
Так мы пришли к подходу, который внутри называем концепцией «единых моделей». Важно подчеркнуть: речь не о том, что в компании должна существовать буквально одна-единственная модель. На нынешнем этапе это нереалистично. Речь о другом: о минимально достаточном унифицированном наборе моделей, который централизованно разворачивается и поддерживается владельцем платформы.
Логика следующая:
Это не административное ограничение ради ограничения, а способ удерживать OPEX под контролем, повышать загрузку вычислительных узлов и извлекать максимум эффекта из кэширования и совместного использования ресурсов.
В контексте эффективности бизнеса это принципиально. В обычной ИТ-инфраструктуре мы можем позволить себе избыточность: выделить отдельный сервер, взять запас по ресурсам, продублировать контур для надежности. В мире больших языковых моделей такие решения могут оказаться неоправданно дорогими. Один хорошо оснащенный ИИ-сервер по стоимости легко сопоставим со всей серверной небольшого предприятия.
Условно разделим большие языковые модели на три класса.
Малые модели — порядка 1–15 млрд параметров. Их основное преимущество — низкий порог входа. Они могут работать даже на одной относительно недорогой видеокарте с объемом памяти до 16–32 ГБ. Некоторые, самые маленькие, даже без видеокарты. Это хороший способ начать эксперименты, проверить гипотезы, встроить простые ИИ-функции в отдельные процессы. Однако в серьезных корпоративных сценариях их возможностей часто будет недостаточно. Они слабее в сложном анализе, хуже работают на длинном контексте, чаще допускают фактические ошибки и галлюцинации.
Средний класс — условно 20–100 млрд параметров. По нашему опыту, это оптимальный класс для промышленного внедрения: такие модели дают заметно более высокое качество и могут быть развернуты достаточно компактно — например, помещаться вместе с большим контекстным окном на одну современную профессиональную видеокарту высокого класса. Это резко упрощает масштабирование и снижает потери производительности, связанные с обменом данными между несколькими GPU.
Флагманские модели — от 100 млрд параметров и выше. Они действительно сильны, но требуют существенно более сложной и дорогой инфраструктуры: нескольких передовых профессиональных ускорителей на один экземпляр модели, более сложной схемы размещения, более дорогой эксплуатации. Для узкого круга задач это может быть оправдано. Для массовой корпоративной эксплуатации — далеко не всегда.
Важно понимать: увеличение количества параметров не гарантирует пропорционального роста полезности. Между классами нет магической пропасти, но в среднем зависимость между размером модели и ее когнитивными возможностями действительно есть.
По нашему опыту, оптимальный выбор для большинства корпоративных сценариев — сильные модели среднего класса, которые дают наилучший баланс между качеством, универсальностью и себестоимостью эксплуатации. Именно здесь чаще всего достигается хорошая «плотность интеллекта».
Практический принцип выбора можно сформулировать так: для локального корпоративного развертывания стоит искать модель, которая дает максимальное качество на единицу ресурса и при этом помещается на одну современную профессиональную видеокарту вместе с необходимым контекстом. Это уменьшает накладные расходы, облегчает масштабирование и делает экономику более предсказуемой.
Когда компания планирует развертывание ИИ-инфраструктуры, она чаще всего задает неправильный стартовый вопрос: «Сколько ускорителей нам нужно?» Правильные вопросы звучат иначе: какую реальную нагрузку будут создавать корпоративные ИИсервисы, какой уровень отклика для них является приемлемым, какая модель и инфраструктура нужна, чтобы обеспечить эти требования?
Для ИИ-инфраструктуры важно не просто наличие ресурсов, а соответствие между потреблением корпоративных сервисов и пропускной способностью конкретной модели в конкретной конфигурации.
Для прогнозирования нагрузки обычно рассчитываются следующие метрики:
Если совокупное потребление начинает превышать эффективную пропускную способность кластера, модель замедляется, возникают деградация пользовательского опыта, а затем — нарушения SLA. С этого момента нужен либо еще один экземпляр модели, либо оптимизация производительности модели или самого сервиса (программного кода).
Проблема в том, что на этапе пилота эти показатели почти всегда оцениваются плохо. Бизнес еще не понимает будущего масштаба спроса, а инфраструктурная команда не имеет достаточной статистики. При этом все равно очень важно выполнить максимально точный прогноз масштабирования, чтобы не попасть ни в одну из крайностей:
В результате бизнес несет необоснованные затраты, себестоимость токена оказывается высокой настолько, что OPEX ряда сервисов может перекрывать получаемые бизнес-эффекты. В зрелой модели эксплуатации расчет мощностей должен быть непрерывным процессом, а не разовым действием на старте проекта.
Еще одна частая ошибка — считать только стоимость сервера или аренды мощностей. Для генеративного ИИ этого недостаточно.
Полный TCO включает как минимум следующие компоненты:
На практике эти затраты часто недооценивают. Многие компании привыкли, что стоимость инфраструктуры для сервиса — это фон, который перекрывается бизнесэффектом почти автоматически, но с генеративным ИИ ситуация иная. Расходы на эксплуатацию могут достигать миллионов рублей в месяц и в отдельных сценариях полностью поглощать ожидаемый экономический эффект от сервиса.
Отсюда возникает критически важная задача — сделать потребление ИИ-ресурсов прозрачным. Иными словами, построить токен-экономику — систему учета, которая позволяет видеть, кто и сколько реально потребляет, как это конвертируется в инфраструктурную нагрузку и какова фактическая себестоимость конкретного сервиса или группы пользователей (токен — единица потребления инфраструктурных ресурсов для большой языковой модели).
Если говорить о промышленной эксплуатации, то компаниям нужна не просто ферма GPU, а корпоративная инференс-платформа.
Мы пришли к этому на собственном опыте. Только наличие платформы позволяет превратить ИИ из серии разрозненных экспериментов в управляемую и эффективную модель потребления.
Что принципиально важно в такой платформе: y единая точка входа к моделям;
Особенно важен единый интерфейс доступа. Он позволяет проектным командам быстро встраивать ИИ в свои решения, не погружаясь в детали конкретной модели и конкретной схемы развертывания. Для бизнеса это означает одно: скорость внедрения растет, а зависимость успеха проекта от редкой инфраструктурной экспертизы в конкретной команде снижается.
Когда речь заходит об ИИ-инфраструктуре, многие сразу закладывают в план и мощности под обучение моделей. На мой взгляд, для большинства компаний на раннем этапе это избыточно.
Важно различать два принципиально разных сценария.
Первый — полноценное обучение или дообучение с изменением весов модели. Это требует больших объемов специально подготовленных данных, сильной ML-команды, выделенных GPU-ресурсов и отдельной системы оркестрации вычислений. Такой контур оправдан у компаний, для которых разработка собственных моделей — стратегическая деятельность.
Второй — использование предобученных моделей с грамотной инженерией промптов, контекстом, инструментами, внешней памятью, поиском по знаниям и агентной оркестрацией. Для корпоративной ИИ-трансформации именно этот путь чаще всего дает самый быстрый и экономически оправданный эффект. Причина проста — предобученная модель универсальна и может обслуживать множество разных сервисов. Узкоспециализированная дообученная модель, как правило, лучше решает одну конкретную задачу, но теряет универсальность. В результате она может занимать дорогой ресурс, но быть востребованный лишь эпизодически, что ухудшает общую экономику платформы.
Для большинства организаций стартовая рекомендация выглядит так: если цель — быстрые прикладные эффекты от генеративного ИИ, не стоит закладывать отдельный крупный контур под обучение без веских причин. В подавляющем числе сценариев начальные задачи можно решить на предобученных моделях за счет качественной настройки промптов и архитектуры приложения.
Есть еще один аспект, который часто недооценивают даже технически зрелые команды, — оптимизация инференса.
В промышленной эксплуатации ИИ значимая часть экономии достигается не покупкой нового оборудования, а правильным выбором программного стека, параметров развертывания и режима работы модели. Грамотная работа с батчингом, кэшированием, форматом весов, режимами квантования, маршрутизацией, профилем запросов и балансировкой может заметно повысить пропускную способность без потери качества.
По нашим оценкам, разница между «развернули как получилось» и «развернули профессионально и оптимизировали под реальную нагрузку» может достигать десятков процентов в TCO. В разрезе масштаба корпоративной платформы это уже не техническая деталь, а значимый экономический фактор.
Из этого следует важный вывод для руководителей: компетенции по инференсу — не узкая инженерная экзотика, а один из ключевых активов компании, которая строит собственную ИИ-инфраструктуру.
Помимо экономики и архитектуры корпоративная ИИ-инфраструктура в России сталкивается с целым набором рисков.
Во-первых, это регуляторика, особенно если речь идет о государственных системах, критической информационной инфраструктуре, чувствительных данных и отраслевых ограничениях. Здесь необходимо заранее ориентироваться на решения, которые можно встроить в российский нормативный контур и сертификационные требования.
Во-вторых, санкционные и логистические риски. Поставки оборудования в целом возможны, но условия рынка могут меняться. Самая чувствительная сложность — не доставка как таковая, а отсутствие полноценной вендорской поддержки, что осложняет гарантийное обслуживание и ремонт.
В-третьих, риск неоправданно высокого OPEX. Именно он наиболее недооценен. Компания может относительно быстро развернуть ИИ-сервис, получить интересный функциональный результат, а затем обнаружить, что стоимость эксплуатации превышает бизнес-выгоду.
В-четвертых, эксплуатационная сложность. Высокая надежность, отказоустойчивость и стабильная производительность в мире дорогих GPU стоят существенно дороже, чем в обычной серверной инфраструктуре. Стандартные подходы, такие как зеркалирование или постоянный двойной резерв, не всегда экономически оправданы. Поэтому особое значение приобретают мониторинг, прогнозирование нагрузки, продуманные процессы масштабирования и контроля деградации.
Наконец, есть и стратегический риск — возможное сокращение доступности сильных открытых моделей и усиление зависимости от ограниченного круга поставщиков. Для российских компаний это означает необходимость заранее строить архитектуру, устойчивую к изменению внешнего технологического ландшафта.
Если обобщить наш опыт, то можно сформулировать несколько практических рекомендаций для компаний, которые только начинают строить собственную ИИинфраструктуру или хотят сократить затраты на уже развернутую.
В последнее время в России часто обсуждают, хватит ли стране вычислительных мощностей для полноценного развития ИИ. Это правильный вопрос, но в корпоративной практике я бы поставил рядом другой: умеем ли мы экономно и грамотно использовать уже доступные мощности?
Мой ответ — да, если компания воспринимает ИИ не как набор модных пилотов, а как новую инфраструктурную реальность. Для этого нужны централизованная платформа, единая модель управления, внимательный расчет нагрузки, прозрачная токен-экономика и дисциплина в выборе моделей.
Генеративный ИИ действительно способен стать ключевым драйвером изменений в бизнесе, но только в том случае, если за эффектным интерфейсом чата стоит зрелая инженерная и экономическая конструкция.