Илья Борняков: «Мало хотеть внедрить ИИ. Нужен человек, который отвечает за результат и бюджет»
Сегодня тема ИИ-инфраструктуры звучит почти в каждом втором проекте. Что, на ваш взгляд, изменилось за последний год в запросах со стороны бизнеса?
Первое, что мы видим, бизнес перестал запрашивать какой-то абстрактный ИИ. Год назад многие приходили со словами «нам нужно попробовать», «бизнес хочет внедрять», «ИТ-директору поставили задачу». А что именно внедрять и зачем, часто было не очень понятно.
Сейчас компании все чаще приходят уже с конкретной задачей. Например, нужно сократить время обработки заявок первой линии поддержки, ускорить работу аналитиков, улучшить поиск по внутренней базе знаний, автоматизировать отдельный workflow. То есть запрос стал гораздо более прикладным.
Еще один важный момент — все начали считать деньги. Принципиально вырос запрос на прозрачность. Компании хотят понимать, сколько вычислительных ресурсов потребляет конкретное подразделение, какие подписки используются, сколько дополнительных затрат появляется на рабочее место сотрудника. ИИ уже перестает быть экспериментом ради эксперимента. Компании начинают смотреть на него как на рабочий инструмент — с затратами, эффектом и понятной экономикой. Кроме того, экономическая составляющая смещает интерес от больших универсальных моделей к более локальным сценариям. Год назад многие хотели развернуть у себя что-то очень масштабное. Но это дорого. Сейчас тренд скорее в сторону локально развернутых моделей под конкретные отделы и задачи — маркетинг, первая линия поддержки, поиск по внутренней базе знаний, автоматизация понятных процессов.
Когда компания-заказчик приходит к вам с запросом «нам нужен ИИ», с чего вы начинаете разговор?
Всегда надо начинать с постановки бизнес-задачи и желательно сразу определить метрики. Иначе очень легко построить решение, которым потом никто не будет пользоваться.
Мы обычно просим описать процесс как он устроен сейчас. Сколько людей задействовано, сколько времени занимает работа, где возникают ошибки, сколько стоит ошибка сотрудника. И, наверное, самый важный вопрос — что изменится, если этот процесс ускорить, например, в два раза. Будет ли реальный эффект для бизнеса. Без такого разговора все быстро скатывается к запросу на «волшебную кнопку», а техническое задание в итоге просто не кристаллизуется.
Здесь есть важный нюанс. Сотрудник хорошо знает свою рутину, понимает, что делает каждый день, но часто не знает, как эту работу можно облегчить. У него нет времени или специальных знаний, чтобы разобраться, где нужен RAG-пайплайн, где имеет смысл подключить распознавание речи, а где ИИ вообще не даст ощутимого эффекта. Поэтому в компании должен быть человек или команда, которые смотрят на процессы сверху и понимают, где автоматизация действительно принесет пользу, а где получится автоматизация ради автоматизации.
И только после этого мы уже подбираем архитектуру. Здесь возникает важная развилка — нужен ли полный контроль над данными или компания готова использовать гибридный подход. Если данные нельзя выпускать наружу, речь идет про on-prem-инфраструктуру, когда модели разворачиваются локально, внутри защищенного контура. Компания получает полный контроль над данными, защиту коммерческой тайны и возможность самостоятельно управлять всей инфраструктурой. В таком сценарии, как правило, используются GPU-серверы ITPOD и платформа Ainergy (подразделения корпорации ITG), которая позволяет централизованно управлять моделями, пользователями, биллингом и доступом внутри компании.
Если же задачи разные по уровню чувствительности, возможен гибридный сценарий. Например, небольшие прикладные задачи работают на локальной инфраструктуре, а для более сложных вычислений дополнительно подключаются облачные сервисы.
Часто к нам приходят ИТ-директора, которым руководство говорит, что «с ИИ надо что-то делать». Но технологии развиваются настолько быстро, что даже сильным ИТ-руководителям сложно успевать за изменениями. Человек двадцать лет работал с классической инфраструктурой, хорошо понимал, как все устроено, а здесь появляются новые подходы, новые инструменты, новые ограничения. Поэтому часто сначала приходят просто за консультацией — понять, что вообще сейчас имеет смысл внедрять, а уже потом обсуждают это с бизнесом.
Бывает и обратная ситуация. Приходит бизнес и спрашивает, насколько жизнеспособны инициативы, которые предлагает ИТ-департамент. В итоге стороны начинают перепроверять гипотезы вместе с интеграторами или вендорами. И, на самом деле, это нормальный процесс — рынок еще только вырабатывает зрелые подходы к внедрению ИИ.
Бывают случаи, когда вы не рекомендуете начинать ИИ-проект?
Самый простой стоп-фактор — отсутствие оцифрованных процессов. Если мы не понимаем, что именно хотим улучшить, а просто «хотим ИИ», проект начинать рано. Но это в принципе можно исправить — сначала описать и оцифровать процессы. ИИ по умолчанию хаос не лечит. Он скорее будет масштабировать то, что уже есть.
Второй важный момент — отсутствие владельца изменений внутри компании. Мало просто хотеть внедрять ИИ и разговаривать об этом. Должен быть человек, который отвечает за результат, за бюджет и за сам процесс изменений. Нужно понимать, сколько это будет стоить и какую выгоду принесет.
Локальные нейросети, особенно в крупных внедрениях, требуют серьезных инвестиций. Не все это понимают. Часто смотрят на цену подписок и думают, что собственная инфраструктура будет стоить примерно столько же или даже дешевле. Но в реальности, если мы говорим про крупный бизнес и большие внедрения, собственная инфраструктура может оказаться кратно дороже.
Зато здесь появляется контроль. Если компания просто покупает сотрудникам подписки на внешние сервисы, она не контролирует, какие данные туда уходят. Люди начинают загружать рабочие документы, внутренние материалы, коммерчески чувствительную информацию. Например, документы по потенциальной сделке или покупке другой компании.
Вот для этого и нужны специальные платформы управления. Без платформы вроде Ainergy компания, по сути, просто раздает сотрудникам доступы к внешним сервисам и дальше уже не всегда понимает, что туда уходит, какие данные надо обезличивать и какие сценарии вообще допустимы.
Когда за внедрение берутся ИТ и ИБ, они начинают выстраивать отдельный workflow. Какие данные можно передавать во внешний контур, какие нужно обезличивать, где использовать локальную инфраструктуру, а где можно подключать внешние модели. Ainergy как раз позволяет настраивать такие сценарии по умолчанию — с контролем, аудитом и управлением передачей данных. Без этого ИИ быстро становится не только инструментом, но и источником рисков.
Вы развиваете ПАК для задач, связанных с искусственным интеллектом. Под какие сценарии он создавался в первую очередь?
Я бы сказал, что ПАК ITPOD и платформа Ainergy прежде всего ориентированы на корпоративный сектор, в котором высоки требования к безопасности и прозрачности. Это финансы, промышленность, госсектор — все отрасли, где много юридически значимых документов и данные не должны выходить за периметр компании. В таких случаях облачные API и внешние сервисы часто просто не рассматриваются, модели нужно разворачивать локально.
Именно здесь и помогает Ainergy. В платформе есть библиотека готовых моделей — обновляемых, поддерживаемых, протестированных под разные сценарии. Заказчик может не начинать с нуля, а выбирать подходящие модели под свои задачи и разворачивать их в защищенном контуре.
Второй важный сценарий — когда одна инфраструктура обслуживает разные подразделения с разными моделями, правами и квотами. Компании важно видеть, кто сколько потребляет ресурсов и во что это обходится. В Ainergy это можно отслеживать через дашборды, чтобы ИТ-директор или руководитель бизнеса понимал, как используется инфраструктура и сколько это стоит в деньгах.
Третий сценарий — low-code-конструктор workflow. Не в каждой компании есть сильная команда разработки, а автоматизировать процессы все равно нужно.
Например, компания хочет ускорить обработку обращений в поддержку. Люди до сих пор любят звонить и говорить с реальными операторами, поэтому возникает задача потоковой транскрибации в реальном времени или постобработки звонков. Для этого можно использовать, например, российские решения вроде GigaAM или, если есть такая необходимость, зарубежные аналоги.
Дальше эти данные нужно передать в CRM, ITSM или тикет-систему, разложить по нужным полям и встроить в рабочий процесс. Важно, что такие workflow можно собирать не через полноценную разработку с нуля, а в более прикладном режиме — с понятной логикой, куда какие данные передаются и что с ними происходит дальше.
Давайте еще поговорим о ПАК. Это типовое решение или все-таки индивидуальная история?
Скорее конструктор. У всех компаний задачи разные, поэтому единого шаблона здесь нет. В ITPOD мы подбираем инфраструктуру под конкретную задачу — серверы, GPU, необходимую производительность. Дальше разворачиваются нужные модели, подключаются необходимые сервисы, а уже поверх этого выстраивается последовательность действий, которую компания хочет получить.
Если заказчик понимает, сколько у него пользователей, какой ожидается объем запросов и какие задачи нужно решать, можно довольно точно подобрать и архитектуру, и оборудование. То есть это не история «один продукт для всех», а скорее сборка под конкретную нагрузку и конкретные бизнес-процессы.
Какие задачи ПАК закрывает лучше, чем классический подход?
Классический подход — это, по сути, самостоятельные упражнения. Компания собирается, решает, что «нам надо автоматизироваться», и ИТ-отдел начинает выбирать железо, смотреть модели, что-то тестировать.
И на первом этапе это вполне рабочая история. Почти у всех сначала появляется пилот. Мало кто готов сразу идти в крупное внедрение. Часто такой пилот запускается либо на существующих мощностях, либо компания арендует у сервис-провайдера виртуальную машину с GPU, чтобы быстро собрать демо и проверить, работает идея или нет.
Но дальше начинается самое интересное — переход от пилота в продуктив. Пока решением пользуются несколько человек, многое можно делать вручную. Где-то не заниматься полноценным обезличиванием данных, где-то быстро настроить процесс и посмотреть результат.
Когда речь уже идет об использовании на уровне отделов, появляются совсем другие задачи. Нужно поддерживать и «железо», и программную часть, появляются роли MLOps или инженеров технической поддержки — все это надо масштабировать. Возникает интеграция с корпоративными учетными записями, ролями доступа, аудитом, мониторингом, подготовкой и обезличиванием данных. То есть в пилоте можно что-то сделать быстро и даже где-то руками. В продуктиве это уже не работает.
И вот здесь ПАК ITPOD для задач ИИ позволяет многие вещи получить фактически «из коробки». Если делать все самостоятельно, на это легко можно потратить полгода или год, а иногда и просто подорвать доверие внутри компании к самому инструменту, потому что ожидания были одни, а результат оказался совсем другим.
Часто ли компании отказываются от идеи собрать все самостоятельно и приходят к готовому решению? Почему?
Чаще всего возвращаются те, кто уже что-то попробовал сам. Пилот на стенде заработал, все вроде выглядит хорошо, а дальше начинают вылезать реальные вопросы.
Например, становится понятно, что не хватает мониторинга и прозрачного биллинга. Уже сложно понять, кто сколько потребляет ресурсов, особенно если используется не только локальная инфраструктура, но и внешние облачные сервисы по подписке. Начинаются неконтролируемые расходы, а сотрудники иногда используют сервисы не только для рабочих задач.
Дальше все начинает быстро обрастать дополнительными требованиями. Интеграция с корпоративными мессенджерами, разграничение прав доступа, аудит, требования ИБ. И в какой-то момент компания понимает, что для поддержки всей этой истории нужен уже отдельный набор специалистов.
В итоге многие начинают считать экономику и понимают, что им важнее прогнозируемая стоимость владения и понятные расходы. Тогда и возникает интерес к готовым решениям.
Насколько ваши решения остаются гибкими? Можно ли адаптировать их под конкретные задачи заказчика?
Гибкость — это, наверное, обязательное свойство такой системы, потому что задачи у всех разные. С точки зрения инфраструктуры мы можем масштабироваться очень по-разному — от одной-двух GPU до восьми карт в сервере и больше. Бывают сценарии, когда заказчик начинал пилот буквально на двух-трех десктопных картах, например RTX 5090, а потом захотел постепенно расти. Для таких случаев у нас тоже есть серверные решения, которые позволяют использовать и такой сценарий, без резкого перехода на совсем другую архитектуру. То есть с точки зрения «железа» конфигурация подбирается под задачу — одна карта, две, восемь или больше, в зависимости от нагрузки и требований.
У вас собственные серверы или арендованные?
Собственные. Мы работаем под брендом ITPOD, производство контрактное, в Китае. Эти серверы мы и предлагаем заказчикам.
Плюс у нас в группе компаний есть сервис-провайдер с GPU-инфраструктурой и несколькими точками присутствия по миру. За счет этого решения достаточно серьезно протестированы на реальных нагрузках.
На уровне программной части поверх серверов устанавливается платформа Ainergy. Уже в ней заказчик выбирает модели под конкретные задачи. Например, можно локально развернуть сценарии речевой аналитики или генерации изображений для маркетинга. Можно подключать и внешних провайдеров — OpenAI, Сбер, МТС и других — если нужен гибридный сценарий.
То есть часть задач работает локально, на собственных серверах заказчика, а более тяжелые вычисления или отдельные аналитические сценарии можно отправлять во внешние модели. При этом все остается в едином контуре — с общим биллингом, аудитом и понятным контролем использования.
Давайте тогда подробнее поговорим об аппаратной части. Какие серверы ITPOD используются в составе ПАК и на что заказчикам здесь важно обращать внимание?
В большинстве случаев — примерно в 90% сценариев — это четырехъюнитовые серверы, построенные на архитектуре NVIDIA MGX. Они позволяют устанавливать до восьми GPU, включая топовые ускорители уровня NVIDIA H200.
Здесь важный момент связан с охлаждением. Такие карты очень энергоемкие. Если говорить про восемь GPU по 600 Вт каждая, то это уже почти 5 кВт тепла, которое нужно эффективно отводить. Поэтому система охлаждения становится критически важной частью сервера.
На рынке встречаются решения, которые внешне выглядят похожими, но рассчитаны, например, на карты с существенно меньшим энергопотреблением. Такие нюансы иногда прописаны мелким шрифтом, а потом выясняется, что сервер просто не рассчитан на нужную нагрузку.
Есть и другой сценарий, который нам кажется интересным. Мы уже говорили про постепенный рост от пилота к промышленному использованию. Для таких случаев у нас есть восьмиюнитовые серверы, где можно использовать десктопные карты уровня RTX 4090 или RTX 5090.
Насколько я знаю, крупные бренды вроде Dell или Hewlett Packard таких решений практически не предлагают.
Причем это не только история про ИИ. Такой подход востребован и для высокопроизводительных вычислений, математического моделирования, медицинских исследований, разработки лекарств — везде, где нужны GPU-расчеты, но не обязательно требуется максимально отказоустойчивая инфраструктура уровня «24×7».
Если задача не критична к непрерывной работе, а расчеты запускаются периодически, использование десктопных GPU позволяет существенно снизить стоимость владения без потери результата.
Если задача не критична к непрерывной работе, а расчеты запускаются периодически, использование десктопных GPU позволяет существенно снизить стоимость владения без потери результата.
Что сегодня формирует основную стоимость ИИ-инфраструктуры? Это GPU, хранение, серверы или что-то еще?
Если совсем просто, основная капитальная статья — это, конечно, сами серверы с GPU. Но часто забывают, что сервер мало купить, его еще нужно где-то разместить.
GPU-инфраструктура — это уже совсем другой уровень энергопотребления по сравнению с обычными серверами под виртуализацию или корпоративные системы. Соответственно, растут требования к питанию и охлаждению. Если компания размещает оборудование в ЦОДе, растут и расходы на размещение. В России это пока не всегда воспринимается как критичная статья расходов, но именно здесь часто возникают ограничения. Не каждый ЦОД сегодня готов размещать такие мощности. Где-то просто нет места, где-то не хватает питания, где-то ограничения по охлаждению.
Особенно это заметно, когда компании пытаются развернуть инфраструктуру у себя, например на производственных площадках. Нередко оказывается, что существующая серверная не рассчитана ни на нужную мощность, ни на охлаждение. И тогда проект начинает требовать дополнительных инвестиций уже в инженерную инфраструктуру ЦОД.
Вторая важная статья расходов — система хранения данных. Про нее часто думают в последнюю очередь. Раньше аналитик мог делать условные 50 запросов в день, и инфраструктура спокойно с этим справлялась. Сейчас, когда используются ИИ-агенты и аналитические инструменты, количество запросов резко растет. Если система хранения данных не готова к такой нагрузке, она быстро становится узким местом. Поэтому здесь важно заранее понимать, насколько инфраструктура вообще рассчитана на интенсивную работу.
При этом в ИИ есть и позитивный момент. Очень много инструментов доступны в open source и не требуют дополнительного лицензирования. В этом смысле экономика часто оказывается проще, чем в классических корпоративных приложениях.
Если говорить про тренды, то, как мне кажется, рынок постепенно будет двигаться в сторону более компактной инфраструктуры. Не обязательно строить большие кластеры под крупные модели. Во многих случаях эффективнее использовать серверы с относительно небольшими GPU — условно на 32–48 ГБ видеопамяти — и решать на них конкретные прикладные задачи. Это позволяет заметно снижать TCO и не инвестировать сразу в избыточные мощности.
Как правильно считать затраты при планировании таких проектов? Где компании чаще всего ошибаются?
Первая ошибка — считать только стоимость GPU-сервера и не учитывать инфраструктурные ограничения.
Важно заранее понимать, где оборудование вообще будет стоять. Не каждый ЦОД готов принять GPU-серверы, не каждая серверная выдержит нагрузку по питанию и охлаждению. Иногда выясняется, что вместе с внедрением ИИ приходится перестраивать инфраструктуру, а это уже совсем другие расходы.
Вторая история связана с облачными моделями. Если компания использует внешние сервисы, важно сразу понимать, как будут считаться расходы и какие ограничения нужно вводить.
Проблема в том, что внедрение ИИ обычно идет постепенно. На старте пользователей немного, счет кажется вполне комфортным. Но потом сотрудники начинают понимать, насколько это ускоряет работу, использование растет, а вместе с ним начинает быстро расти и стоимость.
Поэтому биллинг здесь становится критически важной историей. Нужно видеть, кто сколько потребляет, какие подразделения используют ресурсы и во что это обходится компании. В платформу Ainergy, например, такие механизмы уже встроены — можно отслеживать использование локальной инфраструктуры, внешних сервисов и видеть всю экономику в едином контуре. Это помогает избежать ситуации, когда расходы начинают расти незаметно и выходят из-под контроля.
Какова, на ваш взгляд, зависимость рынка от NVIDIA, и есть ли уже рабочие альтернативы, которые можно рассматривать всерьез?
Сейчас действительно есть определенная монополия NVIDIA, особенно если мы говорим про обучение больших языковых моделей. По сути, этот сегмент пока остается за ними.
При этом рынок уже начинает искать альтернативы. Не потому, что все хотят отказаться от NVIDIA любой ценой, а скорее потому, что бизнес хочет снизить зависимость и стоимость решений.
Здесь появляется интерес к китайским производителям и специализированным GPU-решениям. Пока они, конечно, не могут полноценно конкурировать в задачах обучения самых больших моделей, но для прикладных сценариев уже выглядят вполне рабочим вариантом.
Речь идет о более специализированном подходе. Не обязательно строить огромную инфраструктуру под универсальную модель, которая должна уметь все сразу. Все чаще компании хотят решать конкретную задачу — например, речевую аналитику, поиск по документам или работу с изображениями — и подбирать под нее более специализированное оборудование.
Мне кажется, это и есть один из ключевых трендов ближайших лет. Если раньше рынок двигался в сторону максимально больших и универсальных моделей, то сейчас постепенно появляется спрос на специализацию — когда под конкретную задачу подбирается конкретная архитектура и конкретный тип ускорителей.
Поэтому есть ощущение, что к 2028 году мы увидим гораздо больше решений на базе китайских GPU и меньшую зависимость от NVIDIA, особенно в сегменте прикладных корпоративных задач.
И последний вопрос. Понятно, что заглядывать в будущее сложно, но какой, на ваш взгляд, будет типовая ИИ-инфраструктура через два–три года?
Мне кажется, что стоимость внедрения должна заметно снижаться, и рынок, скорее всего, пойдет именно в эту сторону.
Есть ощущение, что в реальном бизнесе гигантские универсальные модели постепенно уступят место набору небольших специализированных моделей. То есть у компании будет не одна система, которая «умеет все», а набор ИИ-агентов под конкретные роли и задачи.
Мы, наверное, наконец поймем, что ИИ — это инструмент не только для разработчиков или людей, связанных с кодом. Он станет полезным и для обычных офисных сотрудников, и для линейного персонала.
И это, как мне кажется, повлияет и на инфраструктуру. Вместо гигантских GPU-кластеров рынок будет искать более доступные и специализированные решения. Мы в ITPOD как раз видим этот запрос уже сейчас — заказчики все чаще хотят не универсальную «большую модель», а инфраструктуру под конкретный бизнес-сценарий. А значит, постепенно может снижаться и зависимость от NVIDIA и других американских производителей. Вероятно, мы увидим гораздо больше решений на базе китайских, а возможно, и других азиатских разработок.
Реклама ООО "ИТПОД" erid: 2W5zFFvHQFB
Опубликовано 25.05.2026
