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

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

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

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

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

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

• Стоимость. При растущей и даже стабильной нагрузке токенизированные сервисы быстро перестают быть прогнозируемыми по цене. Их стоимость растет линейно с использованием: чем активнее сотрудники пользуются инструментом, тем дороже сервис каждый месяц. 
• Безопасность. Если вы работаете с чувствительными данными и не готовы передавать их третьим лицам, то такие сервисы не лучший вариант. Вы не сможете полностью контролировать, где и как обрабатываются ваши данные. Кроме того, их могут использовать для дообучения моделей.
• Зависимость от внешнего вендора. Провайдер в любой момент может поднять цены, отключить или заменить модель, ужесточить лимиты и политики. Также существует риск ограничения доступа по региону. В результате критически важный элемент вашего бизнес-процесса оказывается вне вашего контроля.
• Файнтюнинг. Не всегда можно дообучить модель под собственную специфику. Часть провайдеров вовсе не поддерживают дообучение, другие — только на их условиях. Клиент не выбирает метод обучения, не контролирует процесс и не может забрать веса дообученной модели. Полноценно адаптировать модель под свою специфику — со своими данными и на своем железе — можно только в open-source.

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

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

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

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

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

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

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

Задачи	Модели	GPU	Инструменты
Простой чат-бот с ответом	Qwen3-8B, Qwen3.6-27B, Gemma 4, GLM-4.7-Air, T-pro	T4, L4, RTX 4090, RTX PRO 6000	Open Web UI, LobeChat
Сложный чат-бот с поиском / поиск по документации для небольшой команды	Qwen3.6-27B или DeepSeek V4-Flash + эмбеддинги (Qwen3-Embedding, BGE-M3) и реранкер	несколько L4, RTX PRO 6000, H200	Open Web UI, LobeChat, Evidently AI, n8n
Транскрибация и анализ звонков	Qwen3-ASR, Whisper Large-v3 + LLM для саммари	L4, RTX 4090, RTX PRO 6000	Open Web UI, n8n, DSVM
RAG / корпоративная база знаний уровня enterprise	DeepSeek V4-Flash (284B) или GLM-5.2, Qwen3.6 + реранкер, высокая нагрузка	2-8 H200, HGX B300	Open Web UI, LobeChat, Evidently AI, n8n
Распознавание и обработка документов	DeepSeek-OCR-2, dots.ocr-1.5, Qwen3.6-VL	RTX 4090, L4, T4; для интенсивного потока —  RTX PRO 6000, H200	Xtreme1, CVAT, n8n
ИИ-ассистент для кодинга	Qwen3-Coder-30B-A3B, GLM-5.2, DeepSeek V4-Pro	RTX PRO 6000, H200, HGX B300	Open Web UI, LobeChat, DSVM
LLM общего назначения / сложные агенты	GLM-5.2, DeepSeek V4-Pro, Qwen3.6-Max, Kimi K2.6	HGX B300 или H200 для квантованных версий	Open Web UI, LobeChat, n8n, DAVM, DSVM, Evidently AI, MLflow, Invoke AI

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

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

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

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

NVIDIA L4 (24 ГБ GDDR6)	Начальный уровень для инференса. Подходит для моделей до 8B параметров, простых чат-ботов и первых пилотов. Компактный single-slot форм-фактор (72 Вт), устанавливается в стандартный PCIe Gen4 слот большинства серверов.
NVIDIA RTX 4090 (24 или 48 ГБ GDDR6X)	Оптимальный баланс цены и производительности. Кастомная версия на 48 ГБ закрывает большинство задач с моделями до 30B параметров в fp16. Хорошо подходит для транскрибации, OCR, кодового ассистента. Такие GPU существуют на рынке в исполнении Blower, которые позволяют полноценно использовать их в серверах, — и наш опыт это подтверждает.
NVIDIA RTX PRO 6000 (96 ГБ GDDR7)	Уровень workstation-карты, адаптированный для серверов. 96 ГБ VRAM позволяют работать с инференсом крупных моделей и квантизацией или держать несколько экземпляров меньших моделей для параллельного обслуживания запросов. Подходит для корпоративного RAG с высокой нагрузкой.
NVIDIA H200 (141 ГБ HBM3e)	Флагманский сегмент для инференса LLM. DeepSeek, Qwen3, Llama в полном размере без компромиссов. Стандартный выбор для продакшен-систем с высокой нагрузкой и требованиями к качеству ответов. Необходимо использование нескольких GPU, в PCI версии можно объединить мостами по четыре карты.
NVIDIA HGX B300 (8 × 288 ГБ HBM3e)	Максимальная производительность и плотность вычислений. Для инференса самых крупных моделей, многоагентных систем, а также обучения. Суммарно 2304 ГБ быстрой VRAM в одном сервере открывают возможности, недоступные на других конфигурациях.

У меня есть три практических правила при подборе, к которым я пришел за время работы с 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 для инференса, файнтюнинга и распределенного обучения. В нем батчинг, автомасштабирование и выкатка новых версий моделей превращаются из проекта в рутину.

Заключение

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

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