Когда маршрутизация через Jev действительно снижает расходы на LLM

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

В этом руководстве есть формула безубыточности, три разобранных сценария и Python-калькулятор для скачивания. Оно предназначено для разработчиков, сравнивающих полные архитектуры маршрутизации. Расчёты иллюстративны и проверены локально; это не реальные измерения Jev и не ценовое предложение Ofox. Об интерфейсе и ограничениях Jev читайте во введении в API Jev.

Определите, какие архитектуры вы сравниваете

Начните с системы, которую развернули бы без Jev. Вариант, отправляющий всё сильной модели, — одна базовая система, но слой правил или дешёвая генеративная модель могут оказаться более экономичной альтернативой.

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

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

Конкретный результат REFLEX показывает, почему база сравнения важна. В валидации на τ²-bench опубликованная стоимость эпизода составила $0,2111 для системы только с сильной моделью, $0,0572 для REFLEX и $0,0411 для дешёвого каскада. Наблюдаемая доля успехов — соответственно 90,0%, 85,0% и 91,7%. Парные различия в успешности статистически не были установлены, поэтому эти числа не доказывают равного качества и не определяют универсального победителя. Однако они показывают, почему покупателя вводит в заблуждение снижение стоимости относительно сильной модели без упоминания более дешёвого каскада.

Отдельный межсемейный эксперимент работы различает число вызовов и деньги: число вызовов сильной модели Qwen снизилось на 71,9%, а подтверждённые денежные расходы — на 52,2%. Для строк Kimi и DeepSeek подтверждённая денежная экономия не приведена. Ваш счёт зависит от длины в токенах и тарифов, а не только от числа исключённых вызовов. Это исторические результаты исследования, а не допущения калькулятора и не наши измерения.

Используйте правильную единицу тарификации Jev

По проверке от 2 октября 2026 года, документация TypeSafe для прямого доступа к моделям указывает цену jev-1.13.0: 0,042 доллара США за миллион входных токенов, выходные токены бесплатны. Страница также различает общий лимит запроса и лимит состояния вместе с самым длинным вопросом. Это опубликованный прямой тариф TypeSafe, а не предложение Ofox и не обещание для любого шлюза. Актуальная документация моделей.

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

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

Для иллюстративного запроса с 2000 входных токенов и одной оплаченной попыткой:

Стоимость Jev = 2,000 × 0.042 / 1,000,000
              = USD 0.000084 за запрос
100,000 таких запросов = USD 8.40

Эти 8,40 доллара США покрывают этап решения Jev при указанных допущениях. Они ничего не говорят о последующей генерации, повторных попытках, мониторинге или цене ошибочного действия.

Рассчитайте стоимость запроса, затем проверьте стоимость успешной задачи

Пусть J — ожидаемая стоимость Jev на входящий запрос, включая оплаченные попытки. a — доля входящих запросов, принятых на более дешёвую ветку; L — её средняя последующая стоимость; H — средняя последующая стоимость резервной ветки; X — дополнительные ожидаемые расходы. Все затраты выражены в одной валюте и в одинаковых границах одного запроса.

Для упрощённой системы с двумя ветками:

Прямая стоимость запроса = H
Стоимость с маршрутизацией = J + a × L + (1 − a) × H + X
Экономия на запрос = a × (H − L) − J − X
Доля принятия для безубыточности = (J + X) / (H − L), когда H > L

a нужно измерять по всем допустимым входящим запросам, включая сбои маршрутизации. Это не значение confidence модели. Например, порог 0,9 не означает принятие 90% запросов. Используйте порядок оценки confidence, чтобы оценить охват на репрезентативных размеченных данных.

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

Три сценария, меняющих решение

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

В первом сценарии доля принятия для безубыточности составляет около 0,933%, потому что каждый принятый запрос исключает большую разницу в стоимости. В третьем — 84%, потому что разница между ветками мала. Ни одно из этих чисел не является рекомендуемым порогом или прогнозом реальной доли принятия.

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

Для иллюстративной проверки качества первого сценария предположим, что прямая система успешно завершает 95 000 из 100 000 запросов, а маршрутизация — только 40 000. Стоимость успеха напрямую равна $1,000 / 95,000 = $0.01053, с маршрутизацией — $468.40 / 40,000 = $0.01171. Меньший общий счёт теперь означает более дорогой успешный результат и гораздо больше неудач. Число успехов здесь придумано только для демонстрации знаменателя и не является измеренным результатом. Приложенный калькулятор не моделирует качество и не вычисляет эту метрику автоматически.

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

Запустите калькулятор и измените параметры

Скачайте офлайн-набор инструментов, распакуйте его и выполните команды из его каталога:

python3 cost.py
python3 cost.py --accepted 0.005
python3 cost.py --cheap 0.0001 --strong 0.0002

Запуск по умолчанию возвращает direct_total: 1000.0, routed_total: 468.4 и savings: 531.6. Мы выполнили его локально. Скрипт использует стандартную библиотеку Python, не вызывает API и не требует ключа.

Замените допущения наблюдаемыми входными значениями:

python3 cost.py --requests 100000 --tokens 2000 \
  --rate 0.042 --attempts 1.2 --accepted 0.6 \
  --cheap 0.001 --strong 0.01 --extra 0.0001

Здесь --attempts 1.2 — предполагаемое среднее число оплаченных попыток Jev, а не утверждение, что каждый повтор тарифицируется. Проверьте начисления по записям использования своего провайдера. --extra — ожидаемые дополнительные расходы на входящий запрос, например оплаченная проверка или измеренная дополнительная стоимость эскалации сверх простых веток. Не учитывайте расход дважды, если он уже включён в cheap или strong.

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

Учтите повторы, кеш и задержку

Повторы: различайте транспортную попытку, оплаченный запрос и завершённую задачу. Тайм-аут не говорит, обработал ли вышестоящий сервис запрос и выставил ли за него плату. Используйте ID запросов и записи использования. Ограничивайте повторы и не повторяйте последующие действия с побочными эффектами без контроля идемпотентности.

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

Общее состояние: несколько независимых вопросов иногда помещаются в один запрос Jev. Это может избавить от повторной отправки состояния, но ограничения контекста и смысл вопросов сохраняются. Для вопросов, зависящих от предыдущих ответов, нужна реальная зависимость в коде, а не предположение, что ответы внутри одного запроса передаются друг другу. Шаблон fan-out в TypeSafe.

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

Проверьте трассы, затем запустите ограниченную долю трафика

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

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

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

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

Какое решение принять

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

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