# KV-кеш и экономика GPU: зачем считать память активных запросов

Как связать память запросов с полезной ёмкостью GPU-сервера: профили контекста, время занятости, стоимость ограничения и сравнение вариантов конфигурации.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/kv-cache-economics/
Language: ru

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

## От памяти модели к памяти сервиса

Веса занимают только часть ресурса. Во время генерации сохраняется состояние, связанное с обрабатываемой последовательностью. [Документация Hugging Face о KV-кеше](https://huggingface.co/docs/transformers/kv_cache) описывает разные способы организации этого состояния и их компромиссы.

В финансовой модели полезно держать это объяснение коротким: один и тот же GPU нельзя оценить только по максимальному размеру загружаемой модели. Важны ограничения активной работы после загрузки.

Например, сервер может уверенно выполнять одиночные обращения и заметно хуже обслуживать несколько длинных сессий. Это не обязательно неисправность оборудования; меняется потребление ресурса выбранным потоком.

## Сначала измерьте профиль занятости

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

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

Отдельно проверьте, как меняется работа при повторении общего начала запросов. Такой режим следует отделять от независимых документов: [prefix caching](/ru/journal/prefix-caching/) может менять картину теста.

## Сравните варианты без обещания окупаемости

Рассмотрим условное решение о расширении памяти. Стороны могут сравнить три пути: оставить текущую модель с меньшим контекстом, выбрать другой формат весов или проверить конфигурацию с большим объёмом VRAM.

Для каждого варианта нужна одна и та же таблица:

| Вопрос | Что зафиксировать |
| --- | --- |
| Полезная работа | Успешные запросы в согласованных границах |
| Качество | Результаты одинакового проверочного набора |
| Расходы | Эксплуатацию и необходимые изменения |
| Ограничения | Контекст, параллелизм, доступность |

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

## Учитывайте время удержания ресурса

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

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

## Практические выводы

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

Для подготовки прочитайте [экономику инференса](/ru/journal/inference-economics/) и [учёт работы GPU](/ru/journal/capacity-reporting/). Решение о закупке стоит принимать после сопоставления сценариев, а не только по объёму памяти.