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

В отчете The State of AI 2025 агентство McKinsey заявляет, что 88% компаний уже используют ИИ хотя бы в одном бизнес-процессе. Grand View Research отмечает, что по их прогнозам глобальный рынок вырастет до 3,5 триллионов долларов к 2033. Уже сейчас мы можем отследить эту динамику.  

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

Однако AI-сервисы не бесплатны. Компании, которые начали с токенизированных API, часто обнаруживают, что при реальной нагрузке их счета растут быстрее, чем польза от ИИ. Поэтому возникает вопрос: как развернуть искусственный интеллект на собственной инфраструктуре и не переплатить.

Привет! Меня зовут Сергей Ковалёв, я менеджер продукта в Selectel. В статье отвечу на этот вопрос, сравню токенизированные API с on-premise и разберу, когда собственное железо будет выгоднее арендованного. Подскажу, как выбрать модель в зависимости от задачи и GPU под разные сценарии: от простого чат-бота на L4 до многоагентных систем на HGX B300. А в конце дам пошаговый план, как перейти с токенов на собственную инфраструктуру и посчитать реальную стоимость запроса.

On-premise вместо токенов

Самый простой запуск AI-проекта выглядит так: покупаем подписку любого популярного сервиса и начинаем взаимодействовать с моделями через веб-интерфейс или приложение. За токены можно работать через API и интегрировать модель в свои сервисы. Конечно, такой подход имеет много плюсов — например, быстрый старт, легкое масштабирование, отсутствие капитальных затрат и значительной экспертизы.

Но и минусы тоже есть. Рассмотрим их подробнее.

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

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

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

• Файнтюнинг. Не всегда можно дообучить модель под собственную специфику. Часть провайдеров вовсе не поддерживают дообучение, другие — только на их условиях. Клиент не выбирает метод обучения, не контролирует процесс и не может забрать веса дообученной модели. Полноценно адаптировать модель под свою специфику — со своими данными и на своем железе — можно только в open-source.

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

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

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

Как только вы примете решение развертывать ИИ самостоятельно, перед вами встанет следующий вопрос: что именно разворачивать и на чем?

Как выбрать модель под задачу

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

Правильный порядок обратный: сначала точно формулируется задача, потом подбираете модель, которая с ней справится при минимальных требованиях к ресурсам. Тот самый price & performance. На каждый рубль вложенных затрат необходимо получать максимальную производительность железа в связке с ИИ-сервисом.

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

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

Каталог готовых ИИ‑моделей

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

Подробнее →

Как выбрать видеокарту под модель

Расскажу про выбор наших GPU. По моему мнению, в этих устройствах оптимальный price & performance.

Ключевой параметр для инференса — объем видеопамяти (VRAM). Он определяет, какую модель вы вообще можете загрузить. Простое правило: чем больше параметров у модели, тем больше VRAM нужно. При этом квантизация (FP8, INT4) позволяет снизить требования, иногда вдвое и больше. Также помимо объема на производительность влияют пропускная способность памяти и вычислительная часть GPU.

Вот варианты карт GPU под разные задачи. 

У меня есть три практических правила при подборе, к которым я пришел за время работы с GPU-инфраструктурой. Давайте я ими с вами поделюсь. 

• Не покупайте с запасом «на вырост». Начните с меньшего железа, добейтесь результата, поймите реальный профиль нагрузки, а потом масштабируйтесь. При аренде серверов апгрейд занимает минимум времени.

• Смотрите на пропускную способность памяти, а не только на объем. HBM3e в H200 с 4,8 ТБ/с и B300 с 8 ТБ/с принципиально быстрее GDDR7 в RTX PRO 6000 с 1,79 ТБ/с. При большой нагрузке и высоком параллелизме пропускная способность напрямую влияет на стоимость одного запроса.

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

Что еще влияет на инфраструктуру

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

Начну со слоя, который лежит ближе всего к модели, — фреймворк инференса. vLLM, llama.cpp, TGI управляют батчингом запросов, KV-кэшем, распределением нагрузки по нескольким GPU. Правильная настройка инференс-фреймворка может снизить стоимость одного запроса в несколько раз при росте нагрузки. Это как раз-таки то место, где скрыт основной потенциал оптимизации. По моему опыту, именно сюда стоит смотреть в первую очередь, когда счет за инфраструктуру кажется завышенным. Грамотный батчинг и работа с KV-кэшем нередко дают больше, чем апгрейд железа.

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

Дальше по айсбергу — RAG и векторные базы данных. Если задача связана с поиском по внутренним документам, нужны векторная база (Qdrant, pgvector, Redis, OpenSearch) и модели для эмбеддингов и реранкинга. Это отдельные компоненты с отдельными требованиями к железу, поэтому их нужно закладывать в архитектуру заранее. Частая ошибка: про эти компоненты вспоминают, когда GPU уже выбраны, — и в итоге эмбеддинги с реранкером начинают конкурировать за память с основной моделью.

Есть и менее очевидный слой — guardrails: фильтры на входе и выходе модели, ролевые политики, логирование нежелательных запросов. Блокировка бессодержательных запросов типа «привет» ощутимо снижает нагрузку. Для публичных сервисов фильтрация выходных данных — это еще и репутационный вопрос. Звучит как мелочь, но посмотрите на реальный трафик — доля бессодержательных запросов вас удивит.

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

Про мониторинг скажу коротко. Задержки, пропускная способность, утилизация GPU, размер очереди запросов — все это нужно видеть в реальном времени. Без мониторинга невозможно ни оптимизировать производительность, ни понять, когда система начнет деградировать, ни увидеть недозагрузку системы.

И наконец, слой, о котором забывают чаще всего, — оценка качества. Evaluation-пайплайны, A/B-тесты, версионирование промптов. Без них нет ответа на вопрос, улучшила ли смена модели или промпта реальные результаты или только циферки на тестовых данных.

Каждый из этих слоев добавляет требования к инфраструктуре: дополнительные серверы, сетевая пропускная способность, хранилище. Зная их заранее, вы не будете переоснащать систему на ходу.

Референс продвинутой корпоративной системы ИИ-сервисов от гиперскейлера:

На схеме архитектура для enterprise AI с несколькими агентами. Запрос проходит через цепочку фильтров безопасности, затем роутер направляет его в изолированный проект нужного отдела — например, поддержки, финансов или продаж. Каждый отдел работает со своим агентом, инструментами и базой данных, поэтому сотрудник физически не может получить доступ к чужим данным. Это наглядно показывает, что продакшен-инфраструктура для ИИ — это не только модель и GPU, вокруг нее выстраивается полноценный инженерный стек с маршрутизацией, изоляцией, аудитом и защитой.

Как как оптимизировать затраты на инфраструктуру для ИИ

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

Вот конкретная последовательность для тех, кто начинает или переходит с токенов на on-premise.

Шаг 1. Сформулируйте задачу до того, как откроете Hugging Face. Определите, что именно должна делать система, кто пользователи, какой объем запросов в сутки, насколько критична задержка ответа, есть ли ограничения на передачу данных. Без этого любой выбор модели — угадывание.

Шаг 2. Запустите пилот на минимальном железе. Арендуйте серверы — это не требует капитальных затрат и долгих закупок, зато позволит понять реальный профиль нагрузки. Цель пилота не «сделать красиво», а измерить, сколько запросов в секунду, какая задержка, насколько качество ответов устраивает реальных пользователей. Фиксируйте эти цифры. Зачастую для пилотов хватает одной-двух карт уровня L4 или RTX 4090 — этого достаточно, чтобы собрать честные метрики, не расходуя бюджет.

Шаг 3. Посчитайте стоимость запроса, а не токены. Формула простая: (стоимость железа в месяц) / (число запросов в месяц) = стоимость одного запроса. Сравните с тем, что вы платите сейчас за облачный API. При каком объеме нагрузки on-premise становится дешевле? Как увеличить число запросов? Предположим, что сервер с двумя RTX 4090 стоит 100 000 ₽/мес. При 200 000 запросов в месяц один запрос обходится в 50 копеек, а при 20 000 — уже в 5 ₽. Железо одно и то же, а экономика отличается в 10 раз. Поэтому вопрос «как загрузить систему полезной работой» не менее важен, чем «как удешевить железо». 

Шаг 4. Протестируйте несколько моделей на своих реальных данных. Не на бенчмарках, а на ваших настоящих запросах в реальной работе. Возьмите 100–200 примеров из реального трафика и прогоните через два-три кандидата. Меньшая модель с правильным промптом часто бьет большую с плохим.

Шаг 5. Зафиксируйте конфигурацию, потом масштабируйте. Когда качество вас устраивает и стоимость запроса понятна, переходите к продакшен-конфигурации. 

Шаг 6. Выстройте мониторинг до того, как система уйдет в продакшен. Не после. Вы должны видеть утилизацию GPU, очередь запросов и задержки с первого дня. Без этого вы управляете вслепую.

Шаг 7. Пересматривайте конфигурацию каждые три-четыре месяца. Ландшафт моделей меняется быстро. Модель, которая полгода назад требовала H200, сегодня может работать на RTX PRO 6000 после выхода более эффективной версии. Заложите в процесс регулярный анализ, чтобы иметь возможность сэкономить.

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

Чем интересного есть в Selectel

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

Если вы только присматриваетесь к on-premise и хотите начать с токенов, есть промежуточный шаг. ИИ-роутер — единое окно доступа к 340+ генеративным моделям через один API-ключ.  Оплата по потреблению токенов в рублях и автоматическое переключение на резервную модель при сбоях провайдера модели. Selectel при этом не использует данные для дообучения, не хранит и не видит ваши промпты. Таким образом, ИИ-роутер — это способ навести порядок в разнообразии токенизированных сервисов и собрать аналитику потребления перед переходом на собственную инфраструктуру.

Следующая ступень — Foundation Models Catalog. Вы выбираете готовую преднастроенную модель из каталога, а платформа сама разворачивает ее на подходящей инфраструктуре и выдает endpoint с токеном доступа — интеграция и бизнес-логика остаются на вашей стороне. Модель при этом работает в изолированном контуре, запросы не выходят в публичный интернет — только по защищенным каналам или локальной сети. 

Важное отличие от токенов: вы платите за ресурсы облака (GPU, vCPU, RAM), а не за количество токенов — это та самая предсказуемая экономика, о которой мы говорили выше.

Быстро развернуть готовое ML-окружение поможет AI-маркетплейс — хаб виртуальных машин с преднастроенными инструментами: от PyTorch и JupyterLab до open-source RAG-платформы с векторным поиском и генерацией ответов. Сервис экономит недели на настройке окружения

Когда профиль нагрузки понятен и пора в продакшен, в дело идут облачные и выделенные серверы с GPU — от L4 до HGX B300. Если планируете развертывать в собственном периметре, есть вариант GPU-серверов на вашей площадке с помесячной оплатой и возможностью выкупа. 

Наконец, если нужно масштабировать инференс или обслуживать несколько моделей параллельно, используйте Managed Kubernetes для AI/ML. Это готовые GPU-кластеры в облаке или на bare metal для инференса, файнтюнинга и распределенного обучения. В нем батчинг, автомасштабирование и выкатка новых версий моделей превращаются из проекта в рутину.

Как вы внедряете ИИ?

Поделитесь своим опытом за 7–10 минут. Разыгрываем 5 сертификатов по 1 500 ₽ на маркетплейсе и 10 наборов мерча.

Ответить на вопросы →

Заключение

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

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

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

Источник: habr.com