Визначте навантаження, перш ніж обирати лічильник
«Модель 7B» не уточнює ні представлення ваг, ні роботу, яку потрібно виконати. Зафіксуйте її ревізію, фреймворк, версії розширень, формат, який фактично завантажується, та операцію: навчання, адаптація чи генерація. Для тексту занотуйте довжини входу та виходу; для зору — роздільну здатність і кількість зображень. Мультимодальна модель вимагає зберігати обидва ці виміри.
Підготуйте звичайний вхід, довгий, але очікуваний, і близький до вашої функціональної межі. Зберігайте їх під час порівнянь. Перевіряйте форми після токенізації, padding, групування чи зміни розміру: значення, вписане в конфігурацію, не доводить фактично оброблену форму.
Також визначте, що залишається одночасно в пам’яті: одна послідовність, один мікробатч, кілька запитів чи оцінювання, запущене після навчання. Ваше питання стає перевірним: чи вміщається це повне навантаження на кожному використаному пристрої, зокрема під час його найвимогливішого етапу?
- Ідентичність спроби: модель або код, ревізія, набір входів і зерно, коли це доречно.
- Розміри: batch, контекст, згенеровані токени, роздільна здатність або кількість одночасних запитів.
- Середовище: обраний GPU, драйвер, Python, PyTorch, бекенд CUDA або HIP/ROCm і налаштування алокатора.
- Обсяг: завантаження, обчислення, передавання, оцінювання, експорт; перший прохід або прохід після прогріву.
Обчислення ваг без змішування ГБ і ГіБ
Один ГБ дорівнює 1 000 000 000 байтів; один ГіБ — 1 073 741 824 байтів. Лічильники PyTorch, використані тут, повертають байти. Зберігайте це початкове значення у файлі результатів, а потім застосуйте єдине перетворення, щоб порівняти рядки. Комерційна назва карти не замінює фактично заявлену пристроєм ємність.
Для щільного набору з семи мільярдів параметрів, збережених по два байти кожен, ваги становлять 14 000 000 000 байтів: 14 ГБ, або приблизно 13,04 ГіБ. Ця операція не включає ні активації, ні градієнти, ні KV-кеш, ні стани оптимізатора. Додавання запасу в 4 ГіБ дає приблизно 17,04 ГіБ як гіпотезу підготовки; це не доводить, що навантаження вміститься в цю межу.
Теоретичний поділ на чотири біти передбачає однорідне компактне зберігання. Справжнє квантоване завантаження може додавати масштаби та іншу інформацію, а також зберігати деякі модулі в іншій точності. Тому формат зберігання ваг і формат обчислень мають бути вказані у вашій довідці окремо.
| Гіпотеза зберігання | Обчислені байти | Приблизні ГіБ |
|---|---|---|
| 32 біти однорідно | 28 000 000 000 | 26,08 |
| 16 бітів однорідно | 14 000 000 000 | 13,04 |
| 4 біти компактно, без метаданих | 3 500 000 000 | 3,26 |
Технічні джерела: NIST — двійкові префікси та порівняння GB/GiB · Hugging Face — формати та квантовані модулі з bitsandbytes
Під час навчання вимірюйте повний крок
Ваги співіснують з іншими об'єктами: градієнтами, станами оптимізатора, активаціями, потрібними для зворотного проходу, і тимчасовими тензорами. Їхні розміри залежать від циклу, точності та розмірностей навантаження. Універсальна константа в байтах на параметр приховала б, зокрема, вплив мікробатчу та входів.
Інструментуйте прямий прохід, обчислення втрат, зворотне поширення та оновлення. Щоб спостерігати стани, які фактично створює ваш оптимізатор, не зупиняйтеся на завантаженні моделі. Також зберігайте вимірювання першого повного кроку: успішний прогрів міг уже виконати ініціалізацію, яку ви маєте мати змогу профінансувати в пам'яті під час запуску.
Додайте оцінювання та експорт, які потрібні вашому проєкту. Якщо збій трапляється під час оцінювання, зменшення лише навчального батчу не виправить цю фазу. Адаптація, яка навчає мало параметрів, може все ще зберігати базову модель і об'ємні активації.
Технічні джерела: Hugging Face — категорії пам'яті під час навчання
В інференсі слідкуйте за контекстом і паралельністю
У автогенерації з увагою KV-кеш зберігає стани, пов'язані з токенами. Для щільного однорідного кешу його розмір залежить від шарів, KV-голів, їхньої розмірності, збережених токенів і послідовностей, присутніх одночасно. Використовуйте KV-голови моделі, а не автоматично її голови запитів.
Арифметичний приклад: 32 шари, 8 KV-голів, розмірність 128, 8 192 токени, два байти на значення та одна послідовність дають 1 073 741 824 байтів, тобто 1 ГіБ для K і V разом. Чотири ідентичні послідовності дають 4 ГіБ лише для цієї статті. Цей розрахунок не вимірює ні пропускну здатність, ні повне завантаження GPU.
Адаптуйте формулу до кешу, який фактично використовується. Ковзне вікно не обов'язково зберігає всю історію; статичний кеш може попередньо виділяти свою максимальну ємність. Квантовані та винесені кеші також змінюють задачу. Вимірюйте окремо початкову обробку входу та генерацію, не приписуючи автоматично всю їхню різницю кешу.
Технічні джерела: Hugging Face — стратегії кешу, статичне виділення та вікна
Allocated і reserved: два показники, які не додаються
memory_allocated описує байти, зайняті тензорами, які відстежує PyTorch на пристрої. memory_reserved описує пам'ять, керовану його алокатором із кешем, у тому числі ту, що вже використовується цими тензорами. Додавання обох враховує частину пам'яті двічі. Зберігайте їх у двох окремих стовпцях.
Їхні варіанти max фіксують кожен свій пік від початку відстеження або з моменту останнього скидання. Це абсолютні піки за період, які враховують і виділення, наявні вже на початку. Результат не обов'язково відображає лише об'єкти, створені під час цієї фази.
Системний огляд може мати ширший периметр. Виділення, зроблені безпосередньо бібліотекою CUDA, наприклад певні комунікації NCCL, не всі видно в алокаторі PyTorch. Тож розбіжність із системним інструментом сама по собі не доводить наявність витоку.
| Лічильник | Запитання, на яке він відповідає | Помилка, якої слід уникати |
|---|---|---|
| memory_allocated | Скільки тензори займають на цей момент зчитування? | Сприймати його як усе зайняте обсягом карти. |
| memory_reserved | Скільки алокатор обслуговує на цей момент зчитування? | Додавати його до allocated. |
| max_memory_allocated | Який пік тензорів відстежувався протягом періоду? | Плутати його зі значенням наприкінці фази. |
| max_memory_reserved | Який пік резервування повідомляє алокатор? | Припускати, що він виникає в той самий момент, що й інший пік. |
Технічні джерела: PyTorch — memory_allocated · PyTorch — memory_reserved · PyTorch — max_memory_allocated · PyTorch — виділення поза його алокатором
Чому різниця між двома піками не вимірює кеш
Розгляньмо лише два вигадані моменти з таблиці. Пік allocated становить 8 ГіБ, а пік reserved — 12 ГіБ. Їхня різниця, 4 ГіБ, не є різницею, спостережуваною в жоден із цих двох моментів: там вона становить відповідно 2 і 6 ГіБ. Два максимуми не обов'язково описують один і той самий стан.
Щоб дослідити їхню розбіжність у певний момент, зніміть allocated і reserved в одній точці контролю, після синхронізації та без нової навмисної операції між зчитуваннями. Ви отримаєте розбіжність лічильників у цей момент, а не вимірювання KV-кешу моделі й не гарантію, що вся ця різниця зможе задовольнити наступне виділення.
Також зберігайте в звіті бекенд алокатора. Документація PyTorch 2.14 зазначає, що з cudaMallocAsync max_memory_reserved може поєднувати найвищі рівні двох пулів і давати верхню межу одночасного піку. Це посилює потребу зберігати назву й периметр лічильника.
| Ілюстративний момент | Allocated | Reserved | Reserved − allocated у цей момент |
|---|---|---|---|
| A | 8 ГіБ | 10 ГіБ | 2 ГіБ |
| B | 6 ГіБ | 12 ГіБ | 6 ГіБ |
Технічні джерела: PyTorch — визначення та межа max_memory_reserved
Окреслити кожну фазу перед зняттям її піку
Операції GPU можуть ставати в чергу, перш ніж завершитися. Для вимірювання за фазами завершіть попередні роботи перед скиданням піків, а потім дочекайтеся завершення фази перед зчитуванням. torch.cuda.synchronize очікує на ядра з усіх потоків вибраного пристрою; цей вибір визначає явну межу для цього протоколу.
reset_peak_memory_stats скидає відстеження піків, починаючи з поточного стану; він не звільняє тензори програми. Спершу зніміть початкові рівні. Наприкінці збережіть обидва абсолютні піки та обидва поточні рівні. Не подавайте віднімання початкового рівня як точний обсяг усіх тимчасових тензорів: попередні об'єкти також могли бути звільнені протягом фази.
Ця інструментація може змінити звичайне перекриття фаз. Використовуйте її, щоб локалізувати проблему, а потім перевірте також повний цикл із його реальним упорядкуванням. За багатокартковості повторіть зчитування для кожного пристрою; вимірювання на cuda:0 не описує інші GPU.
- 1. Дати фазі назву та занотувати її точні вхідні дані.
- 2. Синхронізувати пристрій, а потім зняти початкові allocated і reserved.
- 3. Викликати reset_peak_memory_stats на цьому самому пристрої.
- 4. Виконати визначену фазу, зберігши виходи, потрібні для подальшої роботи.
- 5. Синхронізувати, зняти піки й кінцеві рівні, а потім зафіксувати успіх або помилку.
- 6. Зберегти необроблений результат, розміри та конфігурацію; не заповнювати жодне відсутнє вимірювання нулем.
Технічні джерела: PyTorch — синхронізація пристрою · PyTorch — скидання статистики піків
Розрізняти перший прохід і проходи після прогрівання
Перша спроба та вже підготовлений цикл відповідають на різні запитання. Збережіть слід завантаження та першого проходу, а потім задокументуйте кількість ітерацій розігріву перед повтореннями. Не видаляйте невдалу ініціалізацію лише тому, що наступні проходи були нібито легшими.
Скрипт IteraGPU розрізняє model_load, inputs, cold_forward, warmup і warm_forward. Його cold_forward — це перший прохід малої моделі після ініціалізації пристрою. Він не вимірює все завантаження сервера, драйвера чи служби. Повторення warm_forward залишаються в тому самому процесі та використовують його наявний стан.
Для вашої моделі починайте нову серію в новому процесі, коли ви змінюєте умову, здатну залишити попередні об'єкти чи резервування. Занотуйте порядок спроб і політику розігріву. П'ять перезапусків одного й того самого циклу та запуск п'яти процесів — це не той самий протокол.
Використання ноутбука та скрипту IteraGPU Lab v1
Почніть із README, а потім завантажте автономний ноутбук або скрипт Python. Обчислення estimate використовує стандартну бібліотеку. Вимірювання потребує встановленого PyTorch із сумісним бекендом GPU та доступним пристроєм; воно не завантажує ні модель, ні пакет. Ноутбук потребує середовища, здатного читати файли ipynb.
Вправа з вимірювання використовує невелику оригінальну повнозв'язну мережу та синтетичні вхідні дані. Параметри batch, context і width описують її тензори; context тут — це не довжина справжньої LLM із кешем KV. Цей матеріал слугує для вивчення методики вимірювання та варіювання однієї вимірності. Він не демонструє спроможність карти для вашої дослідницької моделі.
Виконуйте наведені нижче команди з теки, що містить скрипт. Спершу перегляньте звіт environment. Якщо PyTorch або GPU відсутні, measure має явно зупинитися з кодом 2; жоден результат на CPU не повинен тлумачитися як вимірювання на GPU. Вихідний JSON успішного вимірювання створюється у вашому середовищі. Виберіть нову назву файлу для кожної серії: скрипт відмовляється перезаписувати наявний результат.
Перша команда повторює обчислення ваг і гіпотетичного резерву в 4 Gio. Для наступних використовуйте пристрій, який вам дозволено задіювати, і спочатку тримайте помірні розмірності. Зафіксуйте фактично використану версію PyTorch: технічні довідки на цій сторінці описують зокрема версію 2.14, не вимагаючи, щоб вона була встановлена у вас.
Роботу скрипту було перевірено на невеликому випадку: локальна RTX 5070 поза каталогом, драйвер 610.62, Python 3.14.6 і PyTorch 2.11.0+cu128. У спробі використовувалися batch 1, контекст 16, ширина 64, float32, один розігрів і два повторення. Це підтверджує цей шлях виконання, не характеризуючи LLM, навчання чи GPU, пропоновані в оренду. Ноутбук постачається без виводів, а таблиця порівняння — без результатів; перевірку відсутності PyTorch також було виконано в окремому середовищі.
python mesure_memoire.py estimate --parameters 7000000000 --bits 16 --reserve-gib 4
python mesure_memoire.py environment --device cuda:0
python mesure_memoire.py measure --device cuda:0 --batch 2 --context 128 --width 1024 --dtype float32 --warmup 3 --repeats 5 --output mesures.json- Ноутбук для обчислень і вимірювань
Автономний ноутбук, який можна відкрити, переглянути та виконати у вашому середовищі.
- Скрипт mesure_memoire.py
Обчислення без зовнішніх залежностей, перевірка середовища та явне вимірювання GPU.
- Інструкція до теки
Передумови, команди, межі фаз і обмеження тлумачення.
- Архів IteraGPU Lab v1
Зібрані версіоновані ресурси разом з інструкцією та ліцензією.
- Ліцензія на ресурси
Умови повторного використання наданих файлів.
Тлумачення збою перед заміною карти
Неповна спроба залишається корисною спостережуваною величиною. Збережіть фазу, запитані розмірності, повідомлення про помилку та останні доступні значення. Частковий пік перед насиченням не становить потреби в пам'яті для повного виконання. Зменште одну вимірність, щоб побудувати випадок, який завершується успішно, а потім шукайте межу між успіхом і невдачею.
empty_cache звільняє невикористані блоки з кешу алокатора, не звільняючи тензори, які ще живі. Це не універсальне виправлення для завеликого навантаження. Виклик між кожним повторенням змінює умови: задокументуйте цей вибір, а не змішуйте такі спроби з тими, що зберігають кеш.
Якщо прості лічильники не пояснюють ситуацію, трасування пам'яті може допомогти визначити алокації з часом. Його межі залишаються в межах алокацій, видимих для PyTorch. Тому низький пік allocated не виключає зовнішньої алокації або іншого користувача карти.
| Спостереження | Корисна перевірка | Наступна спроба |
|---|---|---|
| Збій під час завантаження | Формат завантажено, розміщення ваг і вже зайнята пам'ять. | Відтворити завантаження окремо в новому процесі. |
| Завантаження успішне, зворотний прохід неможливий | Мікробатч, входи, збережені активації та стан циклу. | Зменшити один вимір, потім повторити повний крок. |
| Збій лише під час оцінювання | Батч оцінювання, збережені виходи та контекст обчислень. | Виміряти оцінювання з його власними обмеженнями. |
| Allocated зростає з кожним повторенням | Посилання, збережені у списках, кешах застосунку або графах. | Перевірити їхній час життя, перш ніж звинувачувати алокатор. |
| Reserved залишається високим після обчислень | Ще живі тензори та політика кешу. | Порівняти поточні значення, не додаючи лічильники. |
| Системний інструмент показує більше | Межі інструмента, контекст GPU, інші процеси та бібліотеки. | Ізолювати навантаження та зіставити показники, зняті в той самий момент. |
Технічні джерела: PyTorch — що звільняє empty_cache · PyTorch — трасування та межі видимості пам'яті
Побудувати запас на основі порівнянних навантажень
Уникайте відсотка запасу, поданого як універсальний. Запас має покривати визначені варіації: довший вхід, дозволений батч, оцінювання, експорт, версія бібліотеки або інше використання карти. Перевірте очікувані граничні випадки, потім зафіксуйте те, що залишається поза межами. Успішний запуск на одному малому вході не підтверджує максимальне навантаження.
Змінюйте одну змінну за раз: батч 1, потім 2 при сталій довжині контексту, або контексти 2 048, потім 4 096 при сталому батчі. Зберігайте той самий вміст і ті самі правила підготовки. Урізання, яке прибирає необхідну інформацію, робить завдання іншим, навіть якщо воно знижує пік.
Якщо домінують ваги, розгляньте інший формат, контролюючи якість. Якщо домінують активації, мікробатч або чекпойнтинг активацій можуть бути шляхами. Останній обмінює пам'ять на переобчислення: виміряйте також тривалість і перевірте результати. Якщо домінує KV-кеш, розгляньте контекст, паралелізм і стратегію кешу. Порівняльна справа доповнює цей підхід спільним правилом якості.
Технічні джерела: PyTorch — чекпойнтинг активацій і переобчислення
Перейти від трасування до рішення щодо конфігурації
Ваш очікуваний результат — коротка картка: оцінка ваг, максимальне перевірене навантаження, успішні або невдалі фази, чотири лічильники з одиницями, середовище та обраний варіант. Додайте сирий результат до цієї картки. Відокремте те, що ви обчислили, те, що ви спостерігали, і те, що ще припускаєте.
Потім порівняйте потребу з можливостями кожної карти, зберігаючи програмні обмеження. Кілька GPU вимагають розподілу роботи та даних; їхня наявність не створює автоматично єдиного резерву пам'яті для застосунку. Збій на одній карті може зберігатися попри вільну пам'ять на іншій.
Протокол PyTorch використовує інтерфейс torch.cuda; збірка PyTorch на HIP/ROCm повторно використовує цю назву. Визначте бекенд, який фактично встановлено, перш ніж порівнювати дві родини обладнання. Використання тієї самої функції Python не доводить, що ядра, точності або результати еквівалентні.
Калькулятор розмірів дає змогу повернутися до початкового припущення; картки GPU дають змогу порівняти можливості. Потім поверніться до того самого робочого випадку, щоб перевірити вибір. Мала мережа із завантаження залишається вправою з інструментування: лише запуск вашого навантаження в його задокументованому середовищі може підтвердити ваш власний запас.
Технічні джерела: NVIDIA — розподіл роботи на кілька GPU · PyTorch — інтерфейс torch.cuda у збірках HIP/ROCm