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

Обновление от 9 сентября означает, что разработчики теперь могут передавать значения per_cache_read_token и per_cache_write_token в Заголовок cf-aig-custom-cost. Cloudflare сообщает, что при наличии любой скорости, специфичной для кэша, AI Gateway активирует ценообразование на токены кэша и учитывает различия между поставщиками, поэтому одно и то же использование кэша не учитывается дважды.

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

Что изменилось

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

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

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

Почему учет кэша теперь важен

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

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

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

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

Кого это затронет

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

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

Разработчики, создающие уровни шлюза, совместимые с OpenAI, страдают, даже если они не используют Cloudflare напрямую. Это изменение отражает более широкое направление развития рынка: платежные системы поставщиков становятся более детализированными, в то время как клиенты по-прежнему ожидают чистых счетов и предсказуемых отчетов об использовании.Такие продукты, как Model Gate, должны рассматривать поля токенов кэша как первоклассные данные бухгалтерской книги, если им нужны точные отчеты на уровне клиентов, ограничения использования и анализ маржи между несколькими поставщиками.

Практические последствия

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

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

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

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

Что остается открытым

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

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