Облако или свой сервер для LLM: где точка безубыточности

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

Точка безубыточности существует всегда. Вопрос в том, где она находится и дойдёте ли вы до неё за разумный срок.

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

Когда считать не нужно

Два случая, где ответ известен заранее.

Своё железо без вариантов, если данные не должны покидать контур: персональные данные с требованием локализации, гостайна, внутренние документы под запретом на передачу. Тогда это не вопрос экономии, а условие задачи — «152-ФЗ и нейросети».

Облако без вариантов, если поток мал, нерегулярен или проект ещё проверяется. Покупать сервер под гипотезу — способ потратить деньги до того, как выяснилось, нужна ли она.

Во всех остальных случаях считаем.

Структура затрат: облако

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

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

Структура затрат: свой сервер

Главное свойство: высокий вход, дальше почти фиксированный расход независимо от потока. Плюс — при большом объёме дешевле. Минус — платите, даже если система простаивает.

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

Формула

Точка безубыточности (месяцев) = Вложения ÷ (Расход в облаке за месяц − Расход на своём за месяц)

Где:

• Вложения — оборудование плюс развёртывание;
• Расход в облаке — обращения × стоимость операции;
• Расход на своём — размещение, электричество, сопровождение.

Если знаменатель отрицательный, точки безубыточности нет: облако дешевле при любом сроке.

Расчёт на примере

Числа иллюстративные. Задача: внутренний ассистент, средняя модель, которая помещается на одну видеокарту.

Вариант «облако».

Вариант «свой сервер».

Точка безубыточности: 570 000 ÷ (48 000 − 26 000) = около 26 месяцев.

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

Теперь тот же расчёт при потоке в 200 000 обращений.

Точка безубыточности: 700 000 ÷ 208 000 = около 3,4 месяца.

Здесь свой сервер оправдан очевидно.

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

Что снижает точку безубыточности

Прежде чем покупать сервер, стоит проверить, нельзя ли просто уменьшить расход в облаке.

Модель поменьше на простых шагах. Часто половина обращений — классификация или приведение к формату, где крупная модель избыточна — «Малые модели».

Сокращение контекста. Передавать меньше текста: отбирать фрагменты точнее, не слать всю историю диалога. Часто основная статья счёта — «Длина контекста и стоимость».

Кеширование. Повторяющиеся запросы не должны идти в модель дважды.

Пакетная обработка. Если ответ не нужен сразу, неспешный режим часто заметно дешевле.

Правила вместо модели. Часть потока обрабатывается без неё — «Когда хватит скрипта».

В моей практике эти меры сокращали счёт в разы, и после них вопрос о покупке сервера нередко снимался.

Смешанная схема

Практичный вариант, который часто оказывается лучшим.

Своё железо для массового потока простых задач: классификация, извлечение полей, приведение к формату. Небольшая модель, скромные требования, предсказуемая стоимость.

Облако для сложного и редкого: задачи, где нужна крупная модель, но их немного.

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

Требует, чтобы доступ к моделям шёл через общий слой — «Шлюз моделей».

Разбор: сервер, который не окупился

Задача. Компания купила сервер под ИИ-проекты: обработка обращений и внутренний ассистент.

Как решали. Аргументы были «данные не должны уходить» и «в перспективе дешевле». Расчёт не делали.

Что вышло.

Фактический поток оказался около 8 000 обращений в месяц вместо ожидаемых 50 000: внутренний ассистент использовался реже, чем предполагалось.

Сопровождение легло на системного администратора, который этим раньше не занимался. Обновление модели заняло у него неделю.

Через полгода вышла модель заметно лучше, но она не помещалась в купленную видеокарту.

Что посчитали задним числом. При фактическом потоке облако обошлось бы примерно в 10 000 ₽ в месяц. Точки безубыточности не существовало вовсе — знаменатель был отрицательным с учётом сопровождения.

Что сделали. Сервер не выбросили: перевели на него массовые простые задачи, где модель поменьше справлялась, а сложные обращения ушли в облако. Смешанная схема сделала вложение хотя бы частично полезным.

Что стоит забрать. Требование «данные не должны уходить» было настоящим, но относилось не ко всему потоку, а к его части. Разделение потока по чувствительности данных — то, что стоило сделать до покупки.

Частые вопросы

При каком объёме свой сервер выгоднее облака?

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

Что чаще всего забывают в расчёте?

Сопровождение своего сервера: обновления, мониторинг, разбор сбоев, замена оборудования. Это постоянная работа, требующая человека с нужными навыками. Забытая строка регулярно переворачивает результат расчёта.

Можно ли сначала попробовать в облаке, а потом перейти?

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

Как быть, если часть данных чувствительна, а часть нет?

Разделить поток: чувствительное обрабатывать своей моделью, остальное в облаке. Это часто дешевле, чем закрывать весь объём своим железом, и позволяет использовать более сильные модели там, где ограничений нет.

Устареет ли купленное оборудование?

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

Что делать, если облако выходит дорого, а сервер не окупается?

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

Что дальше

Что купить, если решение принято, — «Расчёт видеопамяти» и «Квантизация». Чем запускать — «vLLM, Ollama, llama.cpp» и «Локальное развёртывание LLM». Проверка производительности до закупки — «Нагрузочное тестирование».

Расчёт схемы размещения под ваш поток и требования — часть работы по разработке и внедрению ИИ.