Стоит ли бизнесу переносить инференс на новый ИИ-чип в 2026 году или облако всё ещё выгоднее?

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Облачные API дают предсказуемый старт, но при росте объёма запросов счёт растёт линейно и перестаёт помещаться в юнит-экономику продукта. Новый ИИ-чип обещает снизить стоимость инференса, однако требует капитальных затрат, интеграции и постоянной поддержки. Бизнес оказывается между двумя рисками: переплатить за облако или вложиться в железо, которое не окупится при нестабильной загрузке.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

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

Разговор в 2026 году обычно начинается одинаково. Технический директор приносит счёт за облачные API за последние 6 мес и говорит: «выросло, дальше так нельзя». Дальше на стол ложится презентация вендора с графиком, где локальный инференс дешевле облачного. График построен для загрузки, которая отличается от вашей в разы, и в этом весь фокус.

Сначала стоит выяснить, за что вы платите сейчас. Половина счетов, которые я видел, раздута не объёмом полезных запросов, а retry после таймаутов, длинным контекстом «на всякий случай» и повторной обработкой одних и тех же документов. Собственное железо такое не лечит — оно просто переносит перерасход в капитальные затраты.

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

Что изменилось к 2026 году и почему вопрос стал острым

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

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

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

Три силы, которые двигают решение

• Железо стало доступнее по форм-фактору, но не по цене владения.
• Облако стало гибче по функциям и сложнее по тарификации.
• Команда осталась прежней: 1–3 разработчика без выделенного ML-инженера.

Где ломается юнит-экономика облака

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

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

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

Своё железо: из чего складывается цена

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

Отдельная строка — амортизация. Горизонт окупаемости железа для SMB обычно считают на 24–36 месяцев. Это оценка, а не гарантия: модельный ряд за это время сменится, и часть чипов перестанет быть оптимальной под новые веса. Если смета сходится только на горизонте, который больше срока жизни оборудования, смета не сходится.

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

Порог окупаемости считают не в токенах, а в стоимости запроса

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

Что собрать за 3–6 месяцев

1. Объём запросов в месяц и распределение по дням — не среднее, а профиль.
2. Пиковую нагрузку: сколько запросов в секунду приходит в худшие 10 минут суток.
3. Среднюю и предельную задержку, которую терпит продукт.
4. Фактические расходы на инференс по каждой строке счёта.
5. Долю повторных вызовов и среднюю длину контекста.

Дальше арифметика становится скучной, и это хороший признак. Стоимость своего запроса = (амортизация за период + электричество и охлаждение + часы команды на поддержку + доля резерва) / число запросов за период. Сравниваете с облачной стоимостью того же запроса, подставленной из счёта, а не из прайс-листа.

В расчёт закладывайте запас на рост не менее 30–50% сверх текущего объёма. Без запаса вы купите железо ровно под сегодняшнюю нагрузку и через квартал снова пойдёте в облако за пиками. С запасом — часть мощностей будет простаивать и напоминать о себе каждый месяц в отчёте.

Где нельзя обещать цифру заранее: если у вас нет 3–6 мес собственной статистики, любой прогноз окупаемости — это гипотеза. Не подписывайте капитальные затраты под гипотезу.

Гибрид: рабочая схема для команды из 1–3 человек

Для SMB самый прагматичный вариант — не перенос, а разделение. Базовая, ровная нагрузка уходит на локальное железо. Пики, редкие тяжёлые модели и всё, что требует быстрой смены версии, остаётся в облаке.

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

Что оставить в облаке

• Пиковые окна и всё, что выше согласованного порога запросов в секунду.
• Модели, которые вы тестируете: переносить экспериментальную модель на железо бессмысленно.
• Функции с редким вызовом — платить за простой незачем.
• Аварийный режим как резерв, а не как основной путь.

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

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