TCO LLM-шлюза решает не нулевая наценка

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

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

Нулевая наценка не означает минимальную стоимость

Ставка шлюза без наценки обычно повторяет базовую цену поставщика за входные и выходные токены. Если прямой договор даёт компании скидку d, уже на уровне потребления шлюз дороже на величину скидки: при месячном счёте поставщика 10 млн тенге и скидке 12% разница составит 1,2 млн тенге до учёта остальных статей. Это не скрытая комиссия шлюза, а потерянное условие прямого договора.

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

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

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

Сравнивать надо две одинаково полезные архитектуры

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

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

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

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

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

Корпоративная скидка имеет цену входа и выхода

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

Документация поставщиков хорошо показывает механику, хотя конкретные ставки меняются. OpenAI Scale Tier продаёт заранее определённые единицы входной и выходной пропускной способности для конкретного снимка модели с минимальным сроком покупки. Amazon Bedrock Provisioned Throughput выставляет почасовую оплату за Model Units, а более длинное обязательство снижает ставку; биллинг продолжается до удаления ресурса. Microsoft Foundry начисляет плату за развёрнутые PTU независимо от числа обработанных токенов и отдельно предупреждает сначала создать развёртывание, а потом покупать резерв. Google Cloud описывает Provisioned Throughput как обязательство, которое нельзя отменить в середине срока. Общий вывод скучный, но полезный: резерв надо оценивать по утилизации, а не по размеру скидки.

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

Не суммируйте скидку по токенам и скидку на резерв как два независимых процента. Уточните, какие запросы покрывает резерв, как оплачивается превышение, применяются ли к нему общие облачные скидки и переносится ли обязательство между моделями. Если условия нельзя выразить формулой из договора, попросите поставщика дать пример счёта при 60%, 90% и 120% утилизации.

Валюта и расчёты меняют эффективную ставку

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

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

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

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

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

Отдельные интеграции съедают скидку незаметно

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

Не оценивайте интеграцию одной задачей «подключить API». Разделите труд на первоначальную разработку и ежемесячную эксплуатацию. В первую часть входят проверка договора и безопасности, сетевой доступ, управление секретами, адаптер, тесты, наблюдаемость, нагрузочная проверка, документация и запуск. Во вторую входят обновления SDK, миграции моделей, разбор счетов, запросы квот, обработка инцидентов, ревизия ключей и поддержка резервного маршрута.

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

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

Учитывайте только разницу труда между вариантами. Оба контура всё равно требуют evaluation, контроля промптов и наблюдаемости приложения. Шлюзу нельзя приписывать экономию всей LLM-команды; прямому варианту нельзя бесплатно достраивать функции, которые в шлюзе уже входят в согласованный контур.

Поддержка стоит столько, сколько стоит простой

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

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

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

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

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

Рабочая таблица TCO показывает точку безубыточности

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

month,direct_list_usage,direct_discount,direct_commitment_floor,direct_unused_commitment,direct_support,direct_fx_fees,direct_labor_hours,gateway_usage,gateway_fixed_fees,gateway_support,gateway_fx_fees,gateway_labor_hours,internal_hour_rate,direct_total,gateway_total

Для прямого контура используйте direct_usage_net = max(direct_list_usage * (1 - direct_discount), direct_commitment_floor). Не прибавляйте direct_unused_commitment второй раз, если минимум уже учтён через max; эта колонка нужна, чтобы показать долю платежа без полезного потребления. Итог прямого варианта равен чистому потреблению плюс поддержка, валюта, дифференциальные часы труда и ожидаемая цена простоя. Для шлюза формула такая же по смыслу, но без выдуманной нулевой стоимости труда или риска.

Точка безубыточности по объёму находится не из одной универсальной формулы, потому что обязательства создают ступени. Посчитайте объёмы от 50% до 150% прогноза с шагом 10% и найдите первый диапазон, где знак gateway_total - direct_total меняется. Затем уточните его меньшим шагом. Рядом покажите загрузку резерва, число активных поставщиков и часы эксплуатации: читатель модели должен понимать, почему линия пересеклась.

Добавьте контрольные равенства. Сумма месячных итогов должна совпадать с годовым итогом; объёмы токенов по счетам должны сходиться с телеметрией с допустимой разницей; скидка не может применяться к расходам, которые договор исключает; часы не могут быть отрицательными. Отдельно пометьте входные допущения и фактические данные. Таблица, в которой коммерческое предложение, прогноз и факт выглядят одинаково, неизбежно превращается в спор о происхождении цифр.

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

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

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

Модельный микс оформляйте отдельными строками, а не средней ценой токена. Вход и выход стоят по-разному, доля выхода меняется между задачами, а скидка может распространяться не на весь каталог. Для классификации, генерации документов и голосового сценария нужны разные профили. Когда команда заменяет модель, переносите только тот трафик, который прошёл заданный порог качества; иначе экономия возникает из ухудшения продукта и сравнение теряет смысл.

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

Пример показывает, где исчезает выгода

Рассмотрим вымышленную команду, чтобы проверить механику без привязки к текущим тарифам. Публичная стоимость её месячного потребления составляет 40 млн тенге. Прямой поставщик предлагает скидку 15% при минимальном платеже 34 млн тенге в месяц и годовом обязательстве. Шлюз выставляет те же публичные ставки без наценки. На первой строке сравнения прямой вариант стоит 34 млн, шлюз 40 млн, поэтому договор экономит 6 млн.

Теперь добавим дифференциальные расходы. Прямому контуру нужны 140 часов запуска, шлюзу 40; при внутренней ставке 25 000 тенге разовая разница равна 2,5 млн. В эксплуатации прямой вариант требует на 32 часа в месяц больше из-за отдельных квот, счетов и адаптеров, то есть 800 000 тенге. Допустим, поддержка прямого поставщика стоит на 700 000 тенге в месяц больше, а валютные комиссии и спред добавляют ещё 450 000. В первый месяц преимущество прямого договора сокращается до 1,55 млн тенге: 6 - 2,5 - 0,8 - 0,7 - 0,45.

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

Есть и обратный стресс. Если расход растёт до 60 млн по публичным ставкам, прямой платёж после скидки составит 51 млн, если договор применяет скидку ко всему объёму и не вводит отдельную ставку превышения. Тогда валюта и дополнительные часы редко съедят 9 млн разницы. Но этот вывод меняется, если часть трафика переходит на модель, не включённую в скидку, или если резерв ограничивает пропускную способность и превышение оплачивается иначе.

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

Прямой контракт выигрывает при концентрации и предсказуемости

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

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

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

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

Шлюз выигрывает гибкостью, а гибрид часто дешевле обоих крайних вариантов

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

Для команд в Казахстане AI Router сводит маршруты к 500+ моделям через один OpenAI-совместимый эндпоинт, выставляет ежемесячные B2B-инвойсы в тенге и тарифицирует API по ставкам поставщиков без наценки. В TCO эти свойства попадают соответственно в труд интеграций, валютно-бухгалтерские расходы и стоимость потребления; локальное хранение, маскирование PII, аудит-логи и лимиты на уровне ключа следует оценивать только там, где они заменяют отдельную работу вашего контура.

Крайние варианты редко обязательны. Компания может заключить прямой контракт на одну основную модель с предсказуемой базовой нагрузкой, а шлюз использовать для редких моделей, экспериментов, локально размещённых open-weight моделей и резерва. Такой гибрид удерживает скидку на концентрированном объёме и не размножает прямые интеграции ради небольшого хвоста.

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

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