ROI внутренней LLM-платформы: как считать без иллюзий

Почему ROI часто не сходится

Обычно ошибка начинается с базы сравнения. Команда берет цену токенов у двух провайдеров, видит разницу в 10-20% и на этом строит весь ROI внутренней LLM-платформы. Такой расчет почти всегда искажает картину, потому что токены - это только одна строка расходов.

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

Еще одна типичная ошибка - считать интеграцию быстрой, а закупку почти бесплатной. На практике недели уходят на договор, проверку ИБ, согласование с юристами, оплату, вопросы по персональным данным и доступам. Для российских компаний сюда часто добавляются требования по 152-ФЗ, хранению логов и расчетам внутри РФ. Даже если модель сама по себе дешевле, задержка пилота на месяц легко съедает эту экономию. Самое неприятное происходит, когда разработчики уже готовы, а запуск стопорится на административной части.

С простоями та же проблема. Внутренний сервис часто считают "некритичным", потому что он не продается клиенту напрямую. Но если внутренний помощник для поддержки, поиска по документам или генерации ответов недоступен два часа, люди возвращаются к ручной работе. Компания все равно платит им зарплату, копит очередь задач и сдвигает сроки. У таких простоев есть цена, даже если ее не видно в выручке по минутам.

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

С чем сравнивать новую платформу

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

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

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

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

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

Отдельно зафиксируйте допущения по трафику и росту. Не пишите "трафик вырастет кратно". Пишите конкретно: сейчас 2 млн токенов в день, через полгода ожидаем 3 млн; сейчас 4 команды, через год будет 9; доля запросов с персональными данными - 30%. Тогда спор идет не о впечатлениях, а о цифрах.

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

Где платформа экономит время разработки

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

Если платформа дает один API и один способ работы с моделями, этот слой кода пишут один раз. Для ROI это часто первый крупный источник выгоды: меньше ветвлений в коде, меньше специальных адаптеров и меньше регрессий при замене модели.

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

По отдельности это выглядит терпимо. В сумме - уже нет. Например, backend-разработчик тратит 5 часов на адаптер и ретраи, QA - 4 часа на регрессию, ML-инженер - 3 часа на повторную проверку промптов и качества, DevOps - 2 часа на секреты, лимиты и мониторинг. Получается 14 часов на одну смену модели. Если таких замен восемь за квартал, это 112 часов.

Платформа с единым OpenAI-совместимым входом обычно срезает большую часть этой работы. В случае RU LLM команда может заменить base_url и сохранить текущие SDK, код и промпты. Тесты никуда не исчезают, но задача нередко сжимается с пары дней до нескольких часов.

Что включить в расчет

Не ограничивайтесь только временем backend-команды. Деньги уходят и в соседних ролях.

Считайте часы отдельно для DevOps, ML и безопасности. DevOps держит секреты, квоты, наблюдаемость и маршруты. ML-команда перепроверяет качество, шаблоны и fallback. Безопасность смотрит логи, маскирование данных, аудит и доступы. Если платформа закрывает это централизованно, экономия растет быстрее, чем кажется в начале.

Рабочая формула простая: возьмите среднее число смен модели за квартал, умножьте на часы без платформы, вычтите часы с платформой и умножьте разницу на внутреннюю стоимость часа каждой роли. Считать лучше по табелю за последние 2-3 релиза, а не по памяти. Именно там видно, сколько времени команда теряет на повторяющуюся обвязку.

Как перевести закупочное трение в деньги

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

Обычно этот срок складывается из понятных частей: согласование с безопасностью, проверка юристами, запуск платежа, договор, доступы, обмен реквизитами, иногда отдельная проверка по персональным данным. Чтобы получить честную цифру, не берите идеальный сценарий. Возьмите медиану по 3-5 последним подключениям.

Простая формула выглядит так:

• дни задержки
• x число людей, которых задержка реально тормозит
• x дневная стоимость одного человека
• x коэффициент блокировки

Коэффициент блокировки нужен почти всегда. Не вся команда сидит без дела на 100%. Кто-то ждет полностью, кто-то уходит в смежные задачи. Если доступ к модели нужен для интеграции, оценки качества и запуска пилота, коэффициент 0,5-0,7 обычно ближе к правде, чем 1,0.

Небольшой пример: пять инженеров и один ML-специалист ждут 10 рабочих дней, пока пройдут юристы, финансы и ИБ. Средняя дневная стоимость человека для компании - 18 000 рублей. При коэффициенте блокировки 0,6 потери составят 648 000 рублей. И это только один цикл согласования.

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

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

Для российских компаний полезно посчитать и стоимость повторных согласований. Если юристы и ИБ каждый раз заново проверяют зарубежного провайдера, цикл растягивается. Если вместо этого команда использует один API-шлюз с биллингом в рублях, data residency в РФ и привычным OpenAI-совместимым доступом, часть этой задержки может исчезнуть. Экономия тут возникает не из "магии платформы", а из сокращения числа согласований и повторной работы.

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

Как считать цену простоя

Простой LLM-платформы часто считают слишком мягко. Берут только часы недоступности сервиса и забывают, что деньги сгорают не в сервере, а в работе людей и в сдвиге сроков.

Начните с двух чисел за период, обычно за квартал или год: частота инцидентов и средняя длительность каждого. Если за квартал было 6 инцидентов по 35 минут, это уже 210 минут потерь. Дальше считайте не абстрактный простой, а то, сколько времени он забрал у команд.

Самая полезная формула выглядит так:

Цена простоя = потерянное время затронутых сотрудников
+ цена ручных обходов
+ цена сдвига релизов
+ прямые потери от сорванных операций

Потерянное время считают просто. Если во время инцидента 30 разработчиков, 8 аналитиков и 5 сотрудников поддержки не могут использовать LLM в обычном потоке, умножьте длительность сбоя на число людей и на стоимость их часа. Лучше брать не среднюю зарплату "по компании", а внутреннюю ставку часа с налогами и накладными расходами. Иначе сумма получится слишком оптимистичной.

Потом добавьте ручные обходы. Во время сбоя люди не сидят молча. Они пишут черновики руками, гоняют запросы через временные аккаунты, переключают пайплайны, чистят очереди, проверяют ответы вручную. Эти действия тоже стоят денег. И нередко именно они съедают больше, чем сам простой.

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

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

При деградации берите не 100% потерянного времени, а долю. Если ответы стали идти не за 8 секунд, а за 45, люди не перестают работать полностью, но заметно теряют темп. Для такого случая удобно вводить коэффициент потери, например 0,2 или 0,4 от времени инцидента.

Если у вас есть резерв через нескольких провайдеров или через шлюз вроде RU LLM, полных отказов может стать меньше, но деградации все равно останутся. Для ROI это важно: резерв уменьшает не только число крупных аварий, но и мелкие ежедневные потери, которые обычно не попадают в отчет.

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

Как собрать модель расчета по шагам

Считать ROI внутренней LLM-платформы лучше не с общей суммы бюджета, а с разницы между двумя схемами: "как работает сейчас" и "как будет после запуска". Иначе цифры быстро становятся декоративными.

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

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

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

Формула простая:

Годовой эффект = (экономия разработки + экономия на закупках + предотвращенные потери от простоев)
- (стоимость платформы + внедрение + операционная поддержка)

Дальше проверьте три сценария. В осторожном берите только ту экономию, которую можно подтвердить табелями, тикетами и инцидентами. В базовом используйте средние значения за 6-12 месяцев. В верхнем добавляйте только те эффекты, для которых есть понятный механизм, а не надежда на то, что "станет удобнее".

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

Срок окупаемости = единовременные затраты / среднемесячный чистый эффект

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

Пример для команды из 40 человек

Возьмем команду из 40 человек: 25 разработчиков и 15 смежных ролей - QA, аналитики, ML-инженеры, SRE и продакты. Для простоты возьмем среднюю полную стоимость часа 3 400 руб. Это не оклад, а полный час команды с налогами и накладными расходами.

Сейчас команда тратит 120 часов в месяц на интеграции с LLM: разные SDK, авторизация у провайдеров, обработка ошибок, переключение моделей, ручные правки конфигов. Если внутренняя платформа дает один совместимый API, этот объем можно снизить хотя бы до 30 часов. Экономия составит 90 часов в месяц, то есть 306 000 руб. За год выходит 3,67 млн руб.

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

Теперь закупочное трение. Доступ к новому провайдеру согласуют 3 недели. Пока юристы, ИБ и закупки двигают заявку, 8 человек из команды тратят по 3 часа в неделю на временные обходы, ручные проверки и повторные согласования. Это 72 часа на один цикл, или 244 800 руб. Если таких циклов 4 в год, потери составят 979 200 руб.

Простои считают еще реже, хотя бьют они больнее. Пусть два инцидента в квартал суммарно сдвигают релиз на 2 рабочих дня. На выпуск завязаны 18 человек. Цена такого сдвига: 18 x 16 x 3 400 = 979 200 руб за квартал, или 3,92 млн руб в год. Если релиз влияет на выручку, SLA или обязательства перед заказчиком, сумма будет выше.

Соберем эффект в одну модель:

• Экономия времени разработки: 3,67 млн руб в год
• Снижение закупочного трения: 0,98 млн руб в год
• Снижение цены простоев: 3,92 млн руб в год
• Экономия на токенах и маршрутизации, допустим: 3,0 млн руб в год

Итого - 11,57 млн руб в год. Если сама платформа обходится компании в 7 млн руб в год, получаем ROI = (11,57 - 7) / 7 = 65%. Срок окупаемости - около 7 месяцев.

Этот пример хорошо показывает главное: токены дают только часть эффекта. Основные деньги часто лежат в другом месте - в сокращении часов на интеграции, ожидания между командами и сдвигов релизов.

Где обычно ошибаются

Самая частая ошибка - посчитать одни и те же часы дважды. Например, команда записывает экономию на подключении нового провайдера через единый API, а потом добавляет те же часы в строку "ускорение выпуска фич". Если разработчик уже сэкономил 20 часов на интеграции, эти 20 часов нельзя продавать как отдельный эффект еще раз.

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

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

Часто модель выглядит красиво только потому, что в нее не положили внедрение. А внедрение почти всегда стоит денег и времени: настройка доступа, логирование, аудит, миграция промптов, тесты, обучение команд, поддержка в первые недели. Даже если переход технически простой, люди все равно тратят время на смену привычек.

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

Перед защитой бюджета полезно проверить пять вещей:

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

Если после такой проверки ROI заметно падает, это нормально. Зато у вас появляется модель, которую можно сверить с фактом через квартал, а не только показать на одном слайде.

Быстрая проверка перед защитой бюджета

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

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

На финальной проверке достаточно пройтись по нескольким вещам. База сравнения должна лежать в одном файле: текущие расходы на доступ к моделям, часы команды, потери от ожидания закупки и потери от простоя. У каждой ставки и каждого диапазона часов должен быть владелец: финансы подтверждают cost rate, руководитель разработки подтверждает время команды, закупка - сроки согласования, SRE или платформа - инциденты и SLA. Простой нужно выносить в отдельный блок и не смешивать с задержками закупки. Это разные деньги: простой бьет по ежедневной работе, закупка тормозит запуск новых задач.

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

Формула тоже должна читаться за минуту: чистый эффект за период = подтвержденная экономия - стоимость платформы - затраты на внедрение. Срок окупаемости = разовые затраты / средний месячный чистый эффект.

Если вы сравниваете не абстрактную "LLM-платформу", а конкретный вариант вроде внутреннего шлюза или OpenAI-совместимого proxy, зафиксируйте это прямо в названии сценария. Иначе на встрече кто-то начнет спорить с другой архитектурой и сломает весь расчет. Для российских команд это частая история: в одной модели внезапно смешивают расходы на свою GPU-инфраструктуру, требования 152-ФЗ, закупку зарубежных сервисов и потери от ручного переключения между провайдерами.

Нормальная защита бюджета заканчивается не фразой "это выгодно", а двумя ответами: когда окупится и какие числа в модели можно проверить уже сегодня. Если вы можете показать оба ответа на одном экране, ROI внутренней LLM-платформы выглядит как рабочее решение, а не как идея на будущее.

Что делать дальше

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

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

За пилот должны отвечать те, кто действительно тратит время: разработка, ИБ, закупки и команда, которая пользуется сервисом. Не собирайте цифры "на глаз". Берите фактические часы, реальные задержки и каждый инцидент, даже если он длился 20 минут.

Как провести пилот

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

Сравнение должно быть честным. Не берите идеальный будущий режим. Берите тот же процесс, ту же команду и тот же объем запросов. Тогда видно, где платформа экономит часы, где убирает закупочное трение, а где почти ничего не меняет.

Если вам нужен единый OpenAI-совместимый эндпоинт в РФ, такой пилот можно проверить на RU LLM. В простом варианте команда меняет base_url на api.rullm.com и сохраняет текущие SDK, код и промпты. Это особенно полезно там, где дорого переписывать интеграции и где есть требования по хранению логов и данных внутри РФ.

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

Через 8-12 недель у вас будет простая таблица: сколько часов ушло сейчас, сколько ушло с платформой, сколько стоили задержки и сколько денег съел простой. С такой базой легче защищать бюджет. И так же легче вовремя отказаться от проекта, если экономия не подтверждается.