KV-кэш (KV Cache)

KV-кэш (кэш «ключ-значение») — это память, которую LLM использует во время генерации, чтобы не пересчитывать уже сделанную работу. Генерируя каждый новый токен, трансформер нуждается в ключах и значениях внимания всех предыдущих токенов; вместо того чтобы пересчитывать их на каждом шаге, он их кэширует. Именно поэтому генерация тысячного токена происходит быстро — но при этом объём памяти растёт линейно с длиной контекста, так что долгий диалог или большой документ могут занимать гигабайты памяти GPU только под кэш. Для SaaS-разработчиков KV-кэш объясняет сразу несколько реалий: почему длинный контекст стоит дороже и работает медленнее, почему функции «кэширования промпта» (сохраняющие KV-кэш для повторно используемого префикса) резко снижают задержку и цену на одинаковых системных промптах, и почему обслуживание множества одновременных пользователей с длинным контекстом упирается в память. Если счёт за инференс или задержка растут вместе с длиной контекста, причина обычно в KV-кэше — повторное использование кэшированных префиксов и обрезка контекста и есть главные доступные рычаги. Механически кэш держит проекционные векторы ключей и значений, которые каждый слой внимания уже вычислил для всех токенов последовательности, так что модель их больше не выводит заново: на каждом шаге свежими считаются только проекции самого нового токена. Занимаемый объём растёт одновременно и с длиной последовательности, и с размером батча — поэтому именно кэш, а не веса, обычно определяет, сколько параллельных запросов удержит одна GPU. Это ограничение доходит до прайс-листа напрямую: давление на кэш ограничивает число запросов на GPU у провайдера, а число запросов на GPU задаёт нижнюю границу цены за токен. На этом же держатся скидки на «кэшированный ввод», которые сейчас рекламируют несколько провайдеров. Стоит развести два заблуждения. Первое: KV-кэш по умолчанию не сохраняется между отдельными вызовами API — он живёт в памяти того сервера инференса, который обрабатывает активный или недавно активный контекст; именно поэтому межзапросное кэширование промпта должно быть явной функцией провайдера, а не чем-то, что случается само собой. Второе: больший кэш не делает модель умнее — это исключительно механизм эффективности, а не прирост способностей, так что «больше кэша» никогда не бывает ответом на проблему качества. На практике доступные вам рычаги скорее структурные, чем настроечные: ставьте стабильную часть промпта (системные инструкции, примеры, неизменный справочный документ) в начало, чтобы префиксный кэш провайдера попадал в неё, оставляйте изменчивую часть в конце и не дописывайте неограниченную историю диалога там, где хватит скользящего резюме. Серверные стеки управляют кэшем постранично, чтобы ограничить фрагментацию, — потому paged attention и continuous batching почти всегда обсуждают в паре. Не путайте кэш с контекстным окном: окно говорит, сколько модель способна увидеть за раз, а KV-кэш — это аппаратная цена переноса уже увиденного через всю генерацию.