Главная
→
Блог
→
Как ИИ снижает CAPEX на инфраструктуру для работы с LLM

Как ИИ снижает CAPEX на инфраструктуру для работы с LLM

“

Саммари: CAPEX (capital expenditure — капитальные затраты, то есть разовые вложения в оборудование) на серверы для собственной языковой модели может доходить до сотен тысяч долларов. Разберём простыми словами, когда его действительно можно сократить, а когда экономия на бумаге на самом деле не экономия.

Откуда вообще берутся большие расходы

Чтобы запустить крупную языковую модель (LLM, large language model) у себя, нужны мощные видеокарты. Одна карта уровня H100 стоит от 25 до 40 тысяч долларов, а на вторичном рынке — от 15 до 20 тысяч долларов за штуку. Для модели с 70 миллиардами параметров обычно нужно уже несколько таких карт, что быстро превращается в сотни тысяч долларов вложений ещё до того, как система заработала.

Отсюда и главный вопрос компании: покупать это железо самим (это и есть CAPEX) или арендовать вычисления в облаке, платя по мере использования (это уже OPEX — операционные расходы). Ниже — четыре реальных способа снизить именно капитальные вложения, а не просто перенести их в другую графу бюджета.

Способ 1: не покупать железо, а арендовать его с длинным контрактом

Первый и самый простой способ обойтись вообще без CAPEX — арендовать вычисления в облаке, но не по часовой ставке, а по долгосрочному контракту. Годовая аренда снижает цену на 30–40%, а трёхлетняя — на 50–60% по сравнению с почасовой оплатой.

Но здесь стоит сразу отрезвить ожидания: если видеокарты будут загружены меньше чем на 70% времени, аренда в облаке всё равно выйдет дешевле, чем покупка собственного оборудования — даже с учётом всех расходов на его содержание. Другими словами: покупать своё железо ради экономии имеет смысл только тогда, когда оно будет постоянно занято работой, а не простаивать большую часть времени.

Способ 2: считать не «дешевле вообще», а точку безубыточности по объёму

Второй способ — не гадать, что выгоднее, а честно посчитать порог, после которого собственное оборудование окупается. Для небольшой модели с 7 миллиардами параметров такой порог — около 500 тысяч обращений к модели в день, для более крупной модели с 70 миллиардами параметров — около 2 миллионов в день. Ниже этого порога дешевле облако, выше — собственное оборудование экономит 60–80% на стоимости каждого запроса.

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

Способ 3: не забыть посчитать людей, которые будут обслуживать железо

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

Способ 4: когда вопрос вообще не в деньгах

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

Именно с такой задачей мы в AllSee столкнулись в проекте для медицинского центра, микрофинансовой организации и страховой компании. Но решили её не покупкой собственных видеокарт, а обратным путём — построили систему, которая обезличивает персональные данные перед тем, как отправить запрос в облачную модель. Это позволило безопасно пользоваться облаком вместо закупки собственного оборудования и сэкономило заказчику до 10 млн рублей капитальных затрат на GPU, подняв ROI (return on investment — возврат от инвестиций) на 35% за счёт сокращения срока окупаемости с 3 лет до 8 месяцев. То есть иногда способ снизить CAPEX — не покупать железо умнее, а вообще обойтись без покупки за счёт архитектуры решения.

А в другом нашем проекте — для научно-исследовательского центра — выбор был обратным: там данные должны были остаться строго внутри периметра заказчика, поэтому модель развёрнута полностью на его собственных серверах. Оба случая — правильные решения, просто отвечающие на разные вопросы: где действительно нужен CAPEX, а где от него можно уйти вообще. Подробнее — на allsee.team.

Итог

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