Cached input растёт квадратично

[Kaluchi]

Добавлю ещё: сам cached-инпут и вообще способы тарификации — это следствие stateless-природы инференса. Ваш запрос с контекстом почти случайным образом диспетчеризируется на один из десятков тысяч серверов. Сервер, получивший запрос, не помнит и не знает ничего о вас. Соответственно, биллинг этого запроса — это функция от его содержимого и результатов генерации. Агентские механики были бы неконкурентоспособны и невыгодны по ценам для one-shot инференса. Зачем позволять агенту бутстрапить контекст за ваши деньги, когда проще самому вручную закинуть все нужное и заплатить только один раз? И чтобы как-то сделать этот режим работы привлекательным для пользователей, разработчики подвязали биллинг на внутреннее временное служебное состояние — KV-кэш контекста (если префикс контекста уже есть в кэше — применяем скидочный коэффициент к инпуту, если вылетел — тарифицируем по полной). Вот и вся кухня.

[Dhwtj]

Зачем позволять агенту бутстрапить контекст за ваши деньги, когда проще самому вручную

Да

[Flux]

stateless-природы инференса

Ну почти, она действительно stateless на уровне API (от того и биллинг за кэш), но на физическом уровне кэш стараются хранить как можно ближе к GPU - сначала в самой памяти, потом в RAM, а уже потом - на диске или в распределенном кэше. Запросы от одного клиента тоже выгодно кидать на одну и ту же ноду, ибо это повышает вероятность того что кэш физически будет ближе, и снижает средний TTFT.

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

[Kaluchi]

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

Мой месседж был был скорее про сам cached input как модель тарификации. Агентские сценарии на каждом шаге заново гоняют весь растущий контекст, и по обычной цене инпута они были бы невыгодны. Просто снизить цену инпута провайдер не может, тогда подешевеют и обычные one-shot запросы, где он ничего не экономит. Нужна скидка, которую получит только тот, кто действительно переиспользует контекст, и которую нельзя выжать из сценария, где экономии нет.

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

[Politura]

В заголовке не хватает слов "от количества шагов". :)

А то в начале статьи идет речь про размер контекста и получается, что читатель (как минимум в моем лице), решит что идет речь о квадратичном росте от размера контекста и уже после слов "объем кэша в сессии растет линейно с ростом контекста." хочется бежать и писать комментарии на тему несоответствия заголовку. Хорошо, что сдержался.