Описание того, что остаётся в памяти
Во время авторегрессионной генерации ключи и значения уже обработанных токенов можно сохранять для последующих шагов. Этот кэш принадлежит слоям внимания. Поэтому его объём зависит от модели и сохранённой истории, а не только от числа параметров. Контекст беседы также включает инструкции, предыдущие сообщения и документы, добавленные приложением.
Ваше первое решение — операционное: сколько последовательностей должно оставаться активными и до какой длины? Очередь из двадцати запросов, из которых два выполняются одновременно, не обязательно означает двадцать резидентных кэшей. Учитывайте реальный приём запросов и возможные дополнительные последовательности, создаваемые при генерации.
Подготовьте карточку с ревизией модели, слоями внимания, KV-головами, размерностью ключей и значений, их dtype и стратегией кэширования. Считайте токены после токенизатора и шаблона беседы. Ограничение по символам не описывает это выделение памяти.
Технические источники: Hugging Face — работа и форма кэшей по слоям
Использование KV-голов, в частности с GQA
Число голов запроса Q и число KV-голов могут различаться. В классическом многоголовом внимании они совпадают. В MQA используется одна общая KV-голова; GQA объединяет несколько голов Q вокруг одной KV-головы. Читайте num_key_value_heads в конфигурации, когда это поле присутствует, и уточняйте его значение для данной архитектуры.
Например, сорок голов Q и восемь голов KV образуют пять голов Q на группу KV. Формула для хранимого кэша использует восемь, а не сорок. Это соотношение не описывает всю память внимания: операции или преобразования могут создавать временные буферы.
Не меняйте это число просто так, чтобы снизить потребность в памяти уже обученной модели. Схема внимания — часть её архитектуры. Две модели с разным числом голов не становятся эквивалентными вариантами после пересчёта ёмкости; их качество нужно оценивать отдельно.
Технические источники: Hugging Face — поля LlamaConfig и различие MHA, MQA, GQA · PyTorch — размерности Q/K/V и ограничения внимания GQA
Зафиксировать формулу и её единицы измерения
В однородном случае L — число слоёв, Hkv — число голов KV, D — их размерность, T — число сохраняемых позиций на последовательность, B — число последовательностей, q — число байтов на значение. Множитель два учитывает K и V. Это приближение предполагает одинаковую размерность и одинаковый формат ключей и значений, без сжатия и без разделения префикса.
Переводите только конечный результат: один ГиБ равен 1 073 741 824 байтам; один десятичный ГБ равен 1 000 000 000 байтам. Сохраняйте байты в своих расчётах, чтобы округление или смена единицы не скрыли разницу.
Для разных длин без выравнивания замените B × T на сумму фактически хранимых позиций. Для неоднородных слоёв суммируйте слой за слоем. Плотное хранилище с выравниванием, поблочное выделение или статическое резервирование требуют подсчёта выделенных ячеек, которые могут превышать число полезных токенов.
Технические источники: Hugging Face — размерности тензоров кэша · NIST — десятичные единицы и двоичные приставки
Разобранный пример: шесть последовательностей, без измерения на GPU
Возьмём вымышленную архитектуру из сорока слоёв, с восемью головами KV и размерностью 128. Предположим однородный кэш в два байта на значение. Каждая последовательность получает не более 3 072 входных токенов и резерв на 1 024 дополнительных токена, то есть верхнюю границу в 4 096 позиций. Это учебные допущения, а не подтверждённая конфигурация какой-либо модели.
Расчётная стоимость на позицию и на последовательность составляет 2 × 40 × 8 × 128 × 2 = 163 840 байт. Последовательность из 4 096 позиций тогда занимает 671 088 640 байт, то есть 0,625 ГиБ. Шесть последовательностей дают 4 026 531 840 байт, то есть 3,75 ГиБ только под кэш.
Удвоение сохраняемой длины удваивает эту статью в данной формуле. Замена восьми голов KV на сорок увеличивает её в пять раз при всех прочих неизменных допущениях. Эти пропорции не обещают ни ускорения, ни потери качества, ни совместимости какой-либо реальной модели.
| Последовательности B | Позиции T | Голов KV | Вычисленные байты | GiB |
|---|---|---|---|---|
| 1 | 4 096 | 8 | 671 088 640 | 0,625 |
| 6 | 4 096 | 8 | 4 026 531 840 | 3,75 |
| 6 | 8 192 | 8 | 8 053 063 680 | 7,5 |
| 6 | 4 096 | 40 | 20 132 659 200 | 18,75 |
Адаптировать бюджет под стратегию кэширования
Динамический кэш растёт вместе с сохраняемыми позициями. Статический кэш резервирует максимальную ёмкость: рассчитывайте именно этот резерв, а не только короткий запрос, наблюдаемый при запуске. При скользящем окне внимания некоторые слои могут ограничивать свою историю; слои с полным вниманием требуют отдельного расчёта.
Квантование кэша и его вынос на CPU — другие стратегии, зависящие от модели и программного обеспечения. Они меняют ограничения по хранению, передаче или вычислениям. Квантование весов не доказывает, что кэш имеет тот же формат.
Отметьте класс кэша и его явные параметры. Проверьте также освобождение ячеек после завершения или отмены запроса. Для нагрузки, сочетающей короткие и длинные последовательности, единый максимальный резерв может весить больше, чем одна лишь сумма полезного содержимого.
Технические источники: Hugging Face — динамические, статические, квантованные и вынесенные кэши
Проверять репрезентативную нагрузку поэтапно
Постройте три случая: обычный ввод, ожидаемый длинный ввод и максимально допустимое число одновременных запросов. Зафиксируйте модель, tokenizer, шаблон, ограничение генерации и правило остановки. Меняйте по одной размерности за раз; сокращённый ответ или усечённый документ меняют выполняемую работу.
Измеряйте отдельно загрузку, первичную обработку входа и генерацию. Синхронизируйте device вокруг замеряемых фаз, сохраняйте стартовые уровни памяти и пики. Методология памяти объясняет, почему allocated и reserved не складываются и почему разность их максимумов не изолирует кэш.
Ваша проверка должна завершиться проверенной границей и приемлемыми выходными данными: ID завершённых запросов, ошибки, длина сгенерированного текста и критерий качества. Запуск, который проходит на коротком входе, не подтверждает максимальную конкурентность. Ошибка памяти до завершения не является измерением потребности для полного выполнения.
Технические источники: PyTorch — синхронизация работы на выбранном device · PyTorch — охват счётчиков памяти
Отсеять ошибки, которые искажают выбор
Не превращайте вычисленный кэш в общую ёмкость GPU. Добавьте анализ весов, временных активаций, сохраняемых выходных данных и программного обеспечения. Не делите этот объём автоматически на число карт: размещение слоёв или голов должно быть реально настроено и проверено на каждом device.
Ноутбук IteraGPU Lab — это упражнение по инструментированию на небольшой плотной сети без attention. Он помогает читать фазы памяти; его параметр context не подтверждает этот расчёт KV. Используйте карточку нагрузки и папку инференса, чтобы подготовить тест вашей собственной модели.
Сравнивайте ёмкости предложений только после того, как различили арифметический объём, реально наблюдаемый максимум и ещё не протестированные случаи. Тариф аренды организует ваше рабочее окно; он не гарантирует ни длину контекста, ни темп генерации.
- Путать головы Q и головы KV: сверьтесь с конфигурацией архитектуры.
- Бюджетировать только промпт: учитывайте генерацию и фактическое резервирование.
- Читать «веса 4 бита» как «кэш 4 бита»: фиксируйте оба формата.
- Забывать о конкурентности: считайте реально резидентные последовательности.
- Обещать общую память между картами: проверяйте фактическое размещение.
Практические вопросы
Можно ли узнать кэш KV только по числу параметров?
Нет. Нужны также архитектура слоёв attention, головы KV, их размерности, формат кэша, сохраняемые позиции и резидентные последовательности. Две модели близкого размера могут требовать разных бюджетов KV.
Статический кэш потребляет только длину моего запроса?
Нужно рассчитать его зарезервированную ёмкость. Короткий запрос не позволяет вывести это максимальное выделение. Фиксируйте параметры кэша и измеряйте фактически созданную конфигурацию.
Достаточно ли результата формулы для выбора карты?
Он оценивает только кэш согласно объявленным допущениям. При выборе нужно также учитывать другие статьи расхода памяти, совместимость ПО и полный тест с репрезентативными контекстом, конкурентностью и качеством.