Скорбалл OpenAI «Полезный интеллект на доллар»: чек-лист роутинговой политики для каждого оператора AI-шлюза

Метрика, под которую, скорее всего, оптимизирована ваша роутинговая политика, — стоимость токена — неправильная метрика. OpenAI прямо заявила об этом 17 июля, опубликовав фреймворк для CFO, который переопределяет оценку AI-ценности как «Useful Intelligence per Dollar» («Полезный интеллект на доллар»). Для команд, управляющих AI-шлюзами, последствия конкретны и требуют немедленных действий: ваша логика роутинга должна за этим успеть.

Что опубликовала OpenAI

Scorecard вводит четыре метрики для оценки ROI от AI:

1. Объём выполненной полезной работы — задачи, завершённые с приемлемым качеством, а не потреблённые токены.
2. Стоимость успешной задачи — полная стоимость достижения правильного результата (цена модели + повторные попытки + latency + время ревью человеком), а не стоимость токена.
3. Показатель надёжности (Dependability Rate) — какая доля результатов «готова к использованию» vs. «требует исправления» или «требует эскалации».
4. Ценность при масштабировании — растёт ли объём работы на каждый AI-доллар по мере улучшения моделей, инфраструктуры и роутинга.

OpenAI использует этот фреймворк для позиционирования трёхуровневой линейки GPT‑5.6 (Sol/Terra/Luna) как основы для роутинговых решений: Sol — для задач, где сильный reasoning снижает число повторных попыток; Terra — для балансировки производительности и throughput; Luna — для высоконагруженных сценариев, где стоимость токена доминирует. Аргумент: модель «дешевле» по-настоящему только тогда, когда в расчёт включены её failure rate и накладные расходы на retry.

Почему это важно для AI-инженерных команд

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

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

Это требует конкретных изменений от инженерных команд:

• Отслеживайте completion rate по маршрутам, а не только latency и cost. Если дешёвый маршрут даёт 20% отказов и требует повтора, его реальная стоимость уже составляет 1,2× от номинала — плюс latency и деградация UX.
• Сегментируйте workload по чувствительности к повторным попыткам. Разрешение тикета поддержки, генерация кода и ревью контракта — разные профили стоимости retry. Роутинговая политика должна это кодировать, а не обращаться со всеми задачами одинаково.
• Используйте «escalation rate» как роутинговый сигнал. Если маршрут часто вызывает эскалацию к человеку, он недостаточен по размерности надёжности — переключайтесь на более мощный tier модели или отмечайте его для eval.

Роутинговый и операторский угол

Scorecard OpenAI адресован CFO, но для операторов роутинга это подарок: фреймворк позволяет обосновывать решения о tier-роутинге в финансовых терминах, понятных руководству.

Перевод в язык gateway-операций:

Практический вывод: роутинговые политики без обратной связи от данных о результатах устаревают с первого дня. Каждому шлюзу нужен механизм корреляции стоимости запроса с сигналами о downstream-результате — даже простой флаг «был ли повторный запрос?» запускает этот цикл обратной связи.

Позиционирование OpenAI «более умного роутинга» как драйвера ROI от вычислений неслучайно. Оно сигнализирует: компания ожидает, что дифференциация на уровне routing — между tier-ами модели, provider-ами и конфигурациями инференса — станет ключевым рычагом экономики корпоративного AI.

На что обратить внимание

• Выбор tier GPT‑5.6. Если вы роутите запросы к OpenAI, трёхуровневая структура Sol/Terra/Luna требует явной политики выбора модели. Luna — не безопасный default для генерации кода, несмотря на меньшую стоимость: сниженная частота retry Sol нередко выигрывает по метрике «стоимость успешной задачи».
• Eval-driven routing. Формулировка надёжности в scorecard подталкивает к созданию eval-наборов, отслеживающих «готово к использованию» vs «требует исправления», а не только benchmark-точность. Команды без task-specific eval-наборов должны рассматривать это как пробел.
• Диверсификация provider-ов. Логика scorecard применима не только к GPT‑5.6. DeepSeek V4 Pro, варианты Claude Fable 5 и модели Qwen3.7 — у каждого свой профиль retry-стоимости по типам задач. Следующий шаг зрелости — мультипровайдерная роутинговая политика, построенная вокруг outcome rate, а не просто номинальных цен на токены.

Что стоит попробовать пользователям TheRouter

TheRouter маршрутизирует запросы через настроенные provider-ы и записывает стоимость и latency каждого запроса в биллинговый журнал. Команды, движущиеся к измерению «стоимости успешного результата», могут начать с тегирования повторных запросов заголовком X-TheRouter-Retry: true и корреляции этих событий со стоимостью маршрута — подробнее в документации.

Следующий шаг — task-specific pass rate по provider/модели. Если ваша команда переходит к политикам роутинга, ориентированным на результат, руководства по роутингу provider-ов и конфигурация fallback — правильные отправные точки.

Формулировка «Useful Intelligence per Dollar» полезна далеко за пределами продуктовой линейки OpenAI. Это язык, на котором CFO будут оценивать AI-расходы — и именно этот язык операторы роутинга должны использовать, предлагая руководству политику выбора tier-ов модели.