Современные LLM10 / 20

Модуль 10. KV-кэши и эффективный инференс

Сначала попробуйте решить упражнение. Ответы, подробные решения и проектные ориентиры раскрываются отдельно и сохраняют своё состояние при переключении RU/EN.

Скачать файлы курса (.zip) 2588,1 КБ

Архив содержит файлы на обоих языках и вспомогательные материалы с сохранением структуры каталогов.

У1. Лестница KV-кэша

Выведите формулу числа байтов KV на токен и восстановите значения для 70B эквивалента MHA, Llama-3.3-70B GQA, Llama-3-8B GQA и DeepSeek-V3 MLA. Для 70B GQA посчитайте объём контекста 8K, 32K, 128K и 1M и точку, где он сравнивается со 140 GB весов в bf16.

Показать ответ и решение

Решение. Для обычного механизма внимания $b_{KV}=2L H_{kv}d_h b$ байт/токен. Подстановка конфигураций даёт соответственно 2 560, 320 и 128 KiB/токен; для MLA хранятся латентные и координаты RoPE, что даёт 68.625 KiB/токен. У 70B GQA $b_{KV}=327{,}680$ B, поэтому объём равен 2.5 GiB (8 192), 10 GiB (32 768), 40 GiB (131 072) и 305.176 GiB = 327.68 GB (1M). Пересечение со 140 GB весов: $140\cdot10^9/327{,}680\approx\mathbf{427{,}246}$ токенов. После этого один KV-кэш при пакете из одного запроса тяжелее самих весов. Воспроизводимая таблица находится в разделах «1. Типизированная геометрия KV» и «2. Лестница KV/токен» ноутбука module_10_notebook_kvcache.ipynb.

У2. Модель roofline для decode с дополнительной ценой KV

Для модели 8B в bf16 ( $W=16$ GB), $b_{KV}=128$ KiB/токен, пропускной способности 3.35 TB/s и пиковой производительности 990 TFLOP/s посчитайте верхние границы, ограниченные памятью, арифметическую интенсивность при 128K, точки насыщения пакета и цену KV при пакете 32 и контексте 8K.

Показать ответ и решение

Решение. Верхняя граница суммарной пропускной способности равна $Q(N)=BW/(W+Nb_{KV})$ . Отсюда $Q(0)=209.375$ , $Q(8K)=196.208$ , $Q(128K)=100.965$ и $Q(1M)=\mathbf{22.778}$ ток/с. При 128K интенсивность по проекциям равна 0.4822 FLOP/B; с QK/AV — 2.55334 FLOP/B. Гребень $990/3.35=295.52$ FLOP/B выше второй оценки в 115.74 раза. Точка $B^*=W/(Nb_{KV})$ равна 14.90, 3.73 и 0.93 для 8K, 32K и 128K. При $B=32$ и 8K получаем 2 128.7 ток/с вместо идеальных 6 700, то есть поток данных KV уменьшает верхнюю границу в 3.15 раза. Полный расчёт — в разделе «3. Модель roofline для decode, интенсивность и точки насыщения пакета».

У3. Попадание в кэш префикса и взаимное влияние фаз

Для сценария ноутбука сравните полный prefill с попаданием в кэш, затем сложите время prefill с нижней границей времени decode и покажите, как обработка частями меняет всплеск задержки.

Показать ответ и решение

Решение. Проекции дают 132.396 ms для полного входа и 8.275 ms для суффикса: 16×. С причинным вниманием получаем 150.168 и 10.427 ms, отношение 14.402. Для иллюстрации планирования складываем только выбранные исходные границы: $4.776+132.396=137.172$ ms и $4.776+8.275=13.051$ ms. Это не прогноз измеренной ITL; поздние фрагменты дополнительно читают длинную историю.

Стоимость считаем отдельно. Пусть запись префикса стоит 1.25, чтение — 0.1, а каждый суффикс оплачивается полностью. Один тёплый запрос стоит $7680\cdot0.1+512=1280$ входных токенов в эквиваленте базовой цены: это 6.4× дешевле полного входа. За десять запросов с одной записью: $7680(1.25+9\cdot0.1)+10\cdot512=21632$ против 81920, выигрыш 3.787×. Выходные токены, истечение TTL и дополнительные записи исключены. Ноутбук проверяет вычислительную и тарифную модели отдельно.

У4 [проект]

Начните с CPU-опыта «Демо 1»: сравните резервирование 4096 слотов со страницами по 16 на 500 длинах. Затем проследите пять запросов каждого из 100 пользователей: в потоке есть десять общих шаблонов. Раздельно посчитайте долю запросов с попаданием и долю повторно использованных входных токенов при общем и изолированном кэше. Измените распределение длин или число шаблонов и объясните результат. Необязательное расширение — повторить измерения в движке, зафиксировав поток, прогрев, границы совместного использования и SLO. Сравнение разделённого и общего prefill/decode требует подходящих устройств и отдельного учёта переноса KV.

Демо и критерии проекта

Демо к проектному упражнению: русскоязычный демонстрационный ноутбук модуля 10, раздел «Демо 1». В нём дан исходный опыт; упражнение предлагает изменить его условия и объяснить результат.

У5 [проект]

В «Демо 2» сравните выход внимания до и после учебного квантования на 8 и 3 бита, затем измените запрос так, чтобы ему понадобилась ранее маловажная позиция. Проверьте две политики сохранения при бюджетах 25%, 10% и 5%: округление бюджета задайте явно. Объясните, почему знание прошлого внимания не гарантирует сохранения будущего ответа.

При наличии модели можно добавить небольшой фиксированный срез LongBench — набора разных задач на длинный контекст — либо отдельный опыт needle-in-a-haystack: вставить факт в длинный текст и задать вопрос о нём. Последний проверяет извлечение заданного факта, а не всё качество длинного контекста. Зафиксируйте текст, токенизатор, длину, глубину вставки, seed и правило проверки ответа; 128K обозначает длину опыта, а не универсальную версию бенчмарка. Сравнение реальных KIVI/TurboQuant требует их реализаций и измерения памяти и скорости; учебное квантование их не воспроизводит.

Демо и критерии проекта

Демо к проектному упражнению: русскоязычный демонстрационный ноутбук модуля 10, раздел «Демо 2». В нём дан исходный опыт; упражнение предлагает изменить его условия и объяснить результат.