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

Вместо введения

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

Хранение кэша далеко не бесплатно. Есть огромное количество техник оптимизации, которые используются для того, чтобы сократить количество памяти, которое используется для кеширования одного токена (в частности, особых успехов достигли ребята из Deepseek с их последним 4.1-flash), но неизменным остается то, что объем каша в сессии растет линейно с ростом контекста.

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

Если вас много

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

И именно тут появляется проблемное место, которое проявляется и в сценариях чат‑ботов, и в сценарии агентного производства нейрослопа кодинга — с точки зрения пользователя генерация разорвана во времени. Временной промежуток между окончанием инференса модели и получением нового запроса (который будет обязан переиспользовать тот же префикс кэша что уже был вычислен на предыдущем ходу) составляет в лучшем случае несколько секунд, а в худшем — десятки минут. Следовательно, хранить KV кэш каждой пользовательской сессии прямо на GPU не представляется возможным вообще, потому что даже с ультимативными техниками сжатия контекста, такими как в Deepseek v4.1 flash, KV‑кэш на один миллион токенов занимает около одного гигабайта памяти. Резервировать такой объем для каждого пользователя на среднее время ожидания следующего сообщения невозможно, потому что за те несколько минут, что мы ожидаем продолжения сессии, ускоритель должен успеть обслужить десятки или сотни новых клиентов которым нужен свой кэш — все не поместятся. Следовательно, кэш вытесняется сначала в оперативную память, а потом и в постоянное хранилище, и загружается обратно при продолжении инференса.

Именно поэтому чтение из кэша вообще тарифицируется — оно действительно не бесплатно для провайдера.

Именно на этом моменте мы и приходим к теме статьи.

В чем дело‑то?

Мы читаем об очередном релизе фронтирной модели, смотрим на цену токенов и видим там что‑то очень неприятное:

Смотрим цену 1M input и 1M output, после чего скрепя сердце думаем что подписка — наш единственный выход, заносим $200 Сэму и он на следующий день нерфит ее вдвое, предлагая заплатить $500 с чистой совестью продолжаем дальше понижать bus factor своей команды до нуля.

Или идём на Reddit и читаем что Deepseek, между прочим, новая мета, а их харнесс — ну это круто вообще, вы видели эти скриншоты биллинга? 97–99% токенов — чтение из кеша, а оно стоит по $0.003 за миллион. Скриншоты на которых очередной счастливчик потратил сэкономленные со школьных обедов 5 баксов на 18 триллионов токенов да еще и получил впридачу кошка‑жена от великий лидер Xi — далеко не редкость, и они не врут.

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

Большинство современных harness'ов (в моём случае — Codex и DSH) хранят историю в открытом виде и позволяют читать не только сами сообщения, но и метаданные о том сколько токенов было прочитано, взято из кеша и сгенерировано для каждого из них.

Извлекаем эти данные, строим столбчатую диаграмму с накоплением и изучаем случайный сеанс:

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

Если сессия общей длиной N токенов состоит из K примерно одинаковых по длине шагов, то общее число прочитанных из кэша токенов имеет порядок

Или, если посмотреть на это иначе, при средней длине шага в S токенов общее количество прочитанных из кэша токенов имеет порядок

Именно этой динамикой объясняется аномально высокая доля чтения из кэша — кэшированное чтение растет квадратично, в то время как некэшированное чтение и вывод растут линейно.

Чем больше шагов делает ваш агент для решения задачи, тем больше вы платите за кэш. Каждый возврат управления от инференс сервера к клиентскому коду это новый шаг модели. Каждый tool call, каждое чтение файла, каждый пользовательский запрос.

Ирония состоит в том, что современные модели как раз и учатся такому сценарию поведения. Кодовые бенчи оценивают производительность моделей на долгих агентских сценариях. Модели учатся точечно доставать нужную информацию из файлов, делая пять tool calloв вместо того чтобы прочитать файл целиком (тут, конечно, немного выручает parallel tool call). Люди, проектирующие агентские сценарии, интуитивно разбивают работу агента на наиболее мелкие шаги, максимизируя суммарные чтения из кэша.

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

А в итоге?

А в итоге, если вы платите за облачный инференс в агентских сценариях, будь то кодинг генерация кода или другие продолжительные многошаговые пайплайны, цена кешированного чтения будет основной графой расходов, в то время как большинство людей её либо игнорируют на фоне большей цены за input/output, либо наоборот учитывают только её из‑за того как современные дашборды показывают статистику по токенам. Последние, конечно, намного ближе к истине но часто забывают что чем длиннее сценарий — тем непропорционально больше они платят за кэш, и первые сто ходов агента будут стоить втрое дешевле чем вторые сто.

Помни — cached input растёт квадратично!