English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

гість
1 / ?
назад до уроків

Шістнадцять днів обчислень на одній GPU

Один довгий запуск

ANDREA-120M займає ~23 дні на RTX 4090 (FP16, 6 кроків/хв, 200K кроків). Споживання електроенергії, паніка ядра, збої проксі та навмисні зміни конфігурації — усе це відбувається протягом цього періоду. Без контрольних точок будь-який збій відкидає весь запуск.


v1 втратила 27K кроків через одну помилку (lr=0.001 занадто агресивний), бо жодної контрольної точки не було ближче за точку запуску. v2 засвоїла урок: частота контрольних точок знизилася до кожні 100 кроків, та обробник сигналів CUDA гарантує запис контрольної точки на SIGTERM.


Три ролі

Контрольна точка виконує три завдання одночасно:


1. Точка відновлення. Процес завершується, машина перезавантажується, ядро панікує: відновлення з останнього step_NNNNNN.bin.

2. Шліфований поворот. Крок 112,619: зміна навчальної програми без перенавчання. SIGUSR1 примусово створює чисту контрольну точку, проксі зупиняється, нові обмеження та пороги подаються, CUDA відновлюється з збереженої точки під новою політикою.

3. Аудиторський розгалуження. Порівняння двох конфігурацій з однаковими початковими вагами: копіювання контрольної точки, запуск двох розбіжних гілок вперед, спостереження за тим, яка сходиться.


Кожні 100 кроків дають ~17 хвилин тренування між записами при 6 кроках/хв. 100 кроків також відповідають sample_every: кожен чекпоінт відповідає одному свіжому аудиту зразка, & кожен аудит зразка відповідає відновлюваній точці.

Три ролі для одного файлу

Назвіть дві різні функції, які виконує файл чекпоінту, окрім відновлення після збою. Дайте однореченне пояснення для кожної.

П'ять регіонів в одному файлі

Формат

Кожен step_NNNNNN.bin містить п'ять суцільних регіонів:


[int32 step] [int32 n_params] [n_params x float32 weights] [n_params x float32 m] [n_params x float32 v]

ANDREA Checkpoint Binary Format


Регіон за регіоном


Заголовок (8 байт загалом). 32-бітне число кроку повідомляє нам, де в тренуванні розташований цей знімок; 32-бітний лічильник параметрів повідомляє, наскільки великі три наступні масиви.


Ваги (n_params x 4 байти). Кожен навчений параметр, сплощений. Порядок відповідає ітератору параметрів моделі: вбудування токенів та позицій, потім ваги уваги та MLP на шар, потім голова виходу.


Перший момент Adam m (n_params x 4 байти). EMA минулих градієнтів (beta1 = 0.9). Така ж форма, як у ваг. Потрібен для відновлення AdamW.


Другий момент Adam v (n_params x 4 байти). EMA минулих квадратових градієнтів (beta2 = 0.999). Така ж форма, як у ваг. Потрібен для відновлення AdamW.


Загальний розмір

Загальна кількість байтів = 8 + 12 x n_params. ANDREA-12M (12.8M параметрів): 154 МБ на диску (147 МБ округлено). ANDREA-120M (~120M параметрів) FP32: ~1.44 ГБ. Три масиви однакової форми, розміщені один за одним, з маленьким заголовком.


Чому зберігати m & v

Vanilla Adam відстежує per-parameter learning rates через m & v. Якщо їх скинути під час запису чекпоінту, відновлений запуск почнеться з нульового моментуму та нульової оцінки варіації, що еквівалентно learning rate 0 на один крок, а потім раптовому розгону. Loss стрибає; модель може випасти з поточного басейну. Збереження m & v робить відновлення біт-еквівалентним (модуло випадковості dataloader) до базового сценарію без зупинки.

Розмір одного чекпоінта

ANDREA-120M містить ~120,000,000 параметрів, навчених у FP32 (4 байти на float). Обчисліть: (a) байти, використані лише заголовком; (b) байти, використані трьома масивами float32 разом (ваги + m + v); (c) загальний розмір чекпоінта в МБ. Покажіть обчислення.

SIGTERM & SIGUSR1

Чому CUDA обробляє сигнали

Навчання виконується як довготривалий процес у передньому плані. Коли проксі або оператор хоче зупинити GPU, сигнал надсилається до CUDA-движка. Без обробника стандартний SIGTERM миттєво вбиває процес: обчислення градієнтів у польоті відкидаються, останні ваги з останнього чекпоінту втрачаються. З обробником движок спочатку записує чекпоінт, а потім чисто завершується.


SIGTERM: запис & вихід

Надсилається кнопкою зупинки, systemctl stop або kill від батьківського проксі. CUDA завершує поточний крок, записує step_NNNNNN.bin на диск, а потім виходить. Відновлення з цього стану потребує лише останній .bin: нуль роботи втрачено, окрім часткового кроку в польоті.


SIGUSR1: запис & продовження

Надсилається на вимогу оператором або скриптом проксі. CUDA завершує поточний крок, записує step_NNNNNN.bin, а потім продовжує навчання, ніби нічого не сталося. Корисно для: запуску точки аудиту прямо перед зміною конфігурації; захоплення ваг на відомо-доброму моменті; узгодження чекпоінту з зовнішнім запуском оцінки якості зразків.


Польська послідовність повороту (крок 112,619)

1. Оператор надсилає SIGUSR1 до CUDA. Checkpoint записується на наступній межі 100 кроків (крок 112,700).

2. Оператор зупиняє проксі.

3. .samples.json & .state.json архівуються (журнал зразків та стан бандита зберігаються як історичний запис).

4. .loss.json залишається на місці. Кумулятивна історія тренування; ніколи не архівується.

5. Проксі перезапускається з новими верхніми & нижніми межами.

6. CUDA відновлює роботу з step_112700.bin з новим бандитом, але повними вагами, m & v.


Історія втрат продовжується безперервно через поворот. Зразковий лог скидається чисто. Бандит отримує свіжий старт під новою політикою.

Вибір сигналу

Два сценарії. (a) Проксі-скрипт хоче захопити знімок ПРЯМО ПЕРЕД перемиканням з v3-base на v3-polish caps, без зупинки тренування. Який сигнал? Чому? (b) На хості запускається `systemctl stop unhomeschool-train` під час планового перезавантаження. Який сигнал надсилає systemd за замовчуванням? Що робить обробник CUDA?

Кумулятивна історія тренування

Три бічні файли

Поряд з кожним чекпоінтом проксі підтримує три JSON бічні файли в директорії запуску:


- .loss.json -- один запис на крок, завжди. ~200,000 записів до кінця запуску. Кумулятивна історія тренування.

- .samples.json -- недавні згенеровані зразки для аудиту. Скидається під час pivot'ів полірування.

- .state.json -- витягування рук бандита, EMA винагороди, лічильники фаз. Скидається під час pivot'ів полірування.


Що скидається, що зберігається

Польські повороти — це зміни політики, а не скидання запуску. Вага моделі, m, v та історія втрат продовжуються безперервно. Накопичені нагороди бандита НЕ продовжуються: нові стелі та підлоги визначають іншу політику, і бандит повинен переучуватися під новою політикою з чистого стану.


Чому .loss.json Залишається

Історія втрат слугує аудиторським шляхом запуску. Кожне опубліковане твердження про ANDREA-120M (EMA втрат на кроці 110K, відновлення після польського повороту, збіжність на кроці 112K) відстежується до записів у цьому файлі. Архівування .loss.json між фазами змусило б читачів зшивати фрагменти для реконструкції запуску; збереження його лише для дописування та незмінним зберігає походження.


Урок Зомбі-Руки

Крок 112,619 знайшов руку repo-docstrings у .state.json з вагою 1.546 з попереднього запуску. Стан бандита був збережений через попередній перезапуск, але джерело даних більше не було доступним, що створювало зомбі-запити, які спотворювали облік дослідження. Урок: стан бандита Дозволено дрейфувати через перезапуски в несподіваних способах. Історія втрат — єдиний файл, який мусить залишатися незмінним на весь термін життя запуску.


Одне Правило, Щоб Вправляти Всіма

Архівуйте .samples.json та .state.json вільно між фазами. Ніколи не архівуйте .loss.json. Найновіший .loss.json завжди є канонічною історією тренування.

Застосування Правило

Три дії під час polish pivot на кроці 112,619. Для кожної вкажіть ARCHIVE, KEEP IN PLACE або RESET, та дайте одне речення пояснення: (a) `.samples.json`; (b) `.loss.json`; (c) `.state.json` (пам'ять бандита).

Що було створено та чому

П'ять рішень

1. Частота: кожні 100 кроків. Гранулярність точки відновлення ~17 хвилин. Узгоджено з sample_every, тому кожен чекпоінт відповідає одному свіжому аудиту зразка.

2. Формат: заголовок + 3 масиви. Мінімальний: 8-байтний заголовок повідомляє, наскільки великими є кожен наступний масив. Без надлишку метаданих. Точне відновлення біт-за-бітом, коли зберігаються m та v.

3. Сигнали: SIGTERM & SIGUSR1. Дві ролі, два сигнали. Стандартне завершення systemd отримує чистий чекпоінт через SIGTERM; точки аудиту на вимогу отримують чистий чекпоінт через SIGUSR1 без зупинки.

4. Безперервність втрат: ніколи не архівується. Кумулятивна історія тренування зберігається під час поворотів полірування, перезапусків та змін політики. Один слід аудиту для всього запуску.

5. Стан бандита: скидання дозволені. Політика бандита існує під однією конфігурацією за раз. Повороти полірування скидають; історія втрат продовжується. Два різні життєві цикли ділять одну директорію запуску.


До чого це уроки пов’язане


- Діяльність 23 (grow_a_language_model_sample_audit). Частота sample_every збігається з частотою чекпоінтів; обидві спрацьовують кожні 100 кроків.

- Діяльність 24 (grow_a_language_model_microgpt_to_andrea). v1 collapse, v2.5 patch, v3 polish pivot all required clean checkpoints to operate.

- Діяльність 10 (grow_a_language_model_adamw). Збереження m & v у чекпоінті має значення, оскільки правило оновлення AdamW залежить від обох. Видаліть їх & продовження розходиться.


Остінна інженерна істина

Код переживає авторів. Інфраструктура переживає будівників. Простий формат чекпоінту переживає кожну вишукану схему продовження, яка обіцяла пропустити збереження стану оптимізатора. Збережіть байти; збережіть запуск.

Що Ви Збудуєте?

Якщо ви тренуватимете маленьку модель самостійно, яке з цих п'яти рішень ви б прийняли без змін, а яке б адаптували? Оберіть одне для обговорення в 2-3 реченнях. Немає неправильної відповіді; питання полягає в тому, чи можете ви міркувати про компроміс.