Описати те, що залишається в пам'яті
Під час авторегресивної генерації ключі та значення вже оброблених токенів можна зберігати для наступних кроків. Цей кеш належить шарам уваги. Тож його обсяг залежить від моделі та збереженої історії, а не лише від кількості параметрів. Контекст розмови також охоплює інструкції, попередні повідомлення та документи, додані застосунком.
Ваше перше рішення є операційним: скільки послідовностей мають залишатися активними і до якої довжини? Черга з двадцяти запитів, з яких два виконуються одночасно, не обов'язково означає двадцять резидентних кешів. Зафіксуйте реальний допуск запитів і можливі додаткові послідовності, створені генерацією.
Підготуйте картку з ревізією моделі, шарами уваги, 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. Це наближення припускає, що ключі та значення мають однакову розмірність і однаковий формат, без стиснення чи спільного префікса.
Перетворюйте лише кінцевий результат: один Gio дорівнює 1 073 741 824 байтів; один десятковий GB дорівнює 1 000 000 000 байтів. Залишайте байти у своїй таблиці, щоб округлення чи зміна одиниці не приховали різницю.
Для різних довжин без padding замініть B × T на суму фактично збережених позицій. Для неоднорідних шарів підсумовуйте шар за шаром. Щільне зберігання з padding, виділення блоками або статичне резервування вимагає враховувати виділені слоти, які можуть перевищувати корисні токени.
Технічні джерела: 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 Gio. Шість послідовностей дають 4 026 531 840 байтів, тобто 3,75 Gio лише на кеш.
Подвоєння збереженої довжини подвоює цю статтю витрат у цій формулі. Заміна восьми голів 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, шаблон, ліміт генерації та правило завершення. Змінюйте одну розмірність за раз; скорочена відповідь або обрізаний документ змінює виконану роботу.
Вимірюйте окремо завантаження, початкову обробку входу та генерацію. Синхронізуйте пристрій навколо фаз, що вимірюються, зберігайте початкові рівні пам’яті та пікові значення. Метод обліку пам’яті пояснює, чому allocated і reserved не додаються і чому різниця їхніх максимумів не ізолює кеш.
Ваша перевірка має дати випробувану межу та прийнятні результати: ID завершених запитів, помилки, довжину згенерованого тексту й критерій якості. Запуск, що вкладається в короткий вхід, не підтверджує максимальну конкурентність. Помилка пам’яті до завершення не є вимірюванням потреби в повному виконанні.
Технічні джерела: PyTorch — синхронізація роботи на вибраному пристрої · PyTorch — межі охоплення лічильників пам’яті
Відкиньте помилки, що спотворюють вибір
Не перетворюйте обчислений кеш на загальну місткість GPU. Додайте аналіз ваг, тимчасових активацій, збережених виходів і програмного забезпечення. Так само не діліть цей обсяг автоматично на кількість карт: розміщення шарів чи голів потрібно реально налаштувати й перевірити на кожному пристрої.
Ноутбук IteraGPU Lab — це вправа з інструментування на невеликій щільній мережі без уваги. Він допомагає читати фази пам’яті; його параметр context не підтверджує цей розрахунок KV. Використовуйте картку навантаження та теку inference, щоб підготувати випробування власної моделі.
Порівнюйте місткості пропозицій лише після того, як розрізнили арифметичний обсяг, реально спостережений максимум і ще не перевірені випадки. Тариф оренди організовує ваше робоче вікно; він не гарантує жодної довжини контексту чи швидкості генерації.
- Плутати Q-голови та KV-голови: перегляньте конфігурацію архітектури.
- Бюджетувати лише промпт: врахуйте генерацію та фактичне резервування.
- Читати «ваги 4 біти» як «кеш 4 біти»: зафіксуйте обидва формати.
- Забувати про конкурентність: рахуйте послідовності, що реально перебувають у пам’яті.
- Обіцяти спільну пам’ять між картами: перевірте фактичне розміщення.
Практичні питання
Чи можу я дізнатися кеш KV лише з кількості параметрів?
Ні. Потрібні також архітектура шарів уваги, KV-голови, їхні розмірності, формат кешу, збережені позиції та послідовності, що перебувають у пам’яті. Дві моделі близького розміру можуть вимагати різних бюджетів KV.
Чи споживає статичний кеш лише довжину мого запиту?
Потрібно розрахувати його зарезервовану місткість. Короткий запит не дає змоги вивести це максимальне виділення. Зафіксуйте параметри кешу та виміряйте фактично створену конфігурацію.
Чи достатньо результату формули, щоб вибрати карту?
Він оцінює лише кеш за оголошеними припущеннями. Вибір має також враховувати інші статті витрат пам’яті, сумісність програмного забезпечення та повне випробування з репрезентативним контекстом, конкурентністю й якістю.