Огляд оптимізаторів для нейромереж під ідентифікатором arXiv:2608.28557, опублікований у серпні 2026 року, зводить докупи шлях від класичного SGD до новітніх адаптивних методів на кшталт Lion і Sophia, з прямими практичними порівняннями їхньої поведінки під час тренування.

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

Ціна помилки тут вимірюється не абстрактно: перезапуск тренування великої моделі через невдалий вибір гіперпараметрів оптимізатора коштує реальних годин оренди GPU-кластерів.

За даними arXiv, саме такі систематизовані огляди покликані закрити цей розрив: замість того щоб гортати десяток окремих статей про кожен алгоритм, інженер отримує одну шпаргалку з порівнянням підходів у практичному контексті.

Які алгоритми потрапили в поле огляду?

Огляд рухається класичною лінією розвитку методів оптимізації — від SGD і SGD з momentum до адаптивних сімей, які оцінюють крок навчання окремо для кожного параметра. У практиці AI-білдерів найчастіше трапляються такі варіанти:

• SGD з momentum — усе ще базовий вибір для частини задач комп'ютерного зору, де важлива якість генералізації;
• Adam і AdamW — стандарт для тренування великих мовних моделей і трансформерів;
• RMSProp — проміжний варіант, що адаптує крок навчання, але без окремого моменту першого порядку;
• новіші методи на кшталт Lion і Sophia — претендують на економію пам'яті або обчислень порівняно з AdamW.

Чим адаптивні методи відрізняються від SGD під капотом?

Ключова різниця — в тому, як алгоритм визначає розмір кроку для кожного параметра моделі. SGD (з моментом чи без нього) використовує один глобальний крок навчання для всіх ваг, тоді як адаптивні методи на кшталт Adam ведуть окрему статистику — оцінки першого і другого моменту градієнта — і масштабують крок індивідуально під кожен параметр.

Це пояснює, чому адаптивні оптимізатори зазвичай швидше сходяться на старті тренування: вони автоматично «пригальмовують» на параметрах з шумним градієнтом і прискорюються там, де сигнал стабільний. Плата за це — додаткова пам'ять під зберігання моментів (вдвічі-втричі більше стану оптимізатора, ніж просто SGD) і чутливість до вибору гіперпараметрів на кшталт beta1/beta2. Типові дефолтні значення 0,9 і 0,999 для цих параметрів у бібліотеках на кшталт PyTorch працюють як прийнятний компроміс для більшості задач, але не є оптимальними для кожної.

Як підібрати оптимізатор під конкретне тренування?

Універсального переможця немає — і саме це головний практичний висновок для тих, хто підбирає інструмент під задачу, а не копіює дефолти. Для тренування трансформерів з нуля AdamW лишається розумною стартовою точкою через передбачувану поведінку на великих батчах. Для fine-tuning на обмежених ресурсах варто дивитися в бік методів з меншим споживанням пам'яті — вони дозволяють збільшити розмір батчу на тому самому GPU. Якщо ж кінцева якість генералізації важливіша за швидкість збіжності, SGD з momentum і ретельним підбором learning rate schedule усе ще конкурує з адаптивними методами, особливо в задачах зору.

Ймовірно, найбільша практична цінність такого огляду — не в тому, щоб назвати «найкращий» оптимізатор, а в тому, щоб дати структуру для швидкого A/B-порівняння двох-трьох кандидатів на невеликій вибірці даних перед тим, як запускати повне тренування. Такий A/B-тест на 5-10% даних коштує значно дешевше, ніж виявити проблему вже на етапі повного тренування.

Висновок AiiN

Наша теза проста: систематизовані огляди на кшталт цього корисні саме як інструмент скорочення простору пошуку, а не як заміна власного експерименту. Команда, яка витрачає годину на читання такої шпаргалки перед стартом тренування, економить не години — вона економить дні переранів на дорогих GPU-кластерах, коли з'ясовується, що обраний за замовчуванням оптимізатор погано лягає на конкретну архітектуру чи розмір датасету. Рейтинг «найкращого» оптимізатора з чужого бенчмарку майже нічого не каже про поведінку алгоритму на вашій архітектурі й вашому датасеті — переносити висновки один в один ризиковано.

Чи можна просто завжди брати Adam або AdamW за замовчуванням?

Для більшості трансформерних архітектур це розумний і безпечний старт, оскільки поведінка AdamW добре вивчена на великих моделях. Але для задач з обмеженою пам'яттю GPU чи специфічних доменів (наприклад, дрібні згорткові мережі) варто перевірити хоча б одну альтернативу — виграш може бути суттєвим.

Що робити, якщо тренування розходиться (diverges) з обраним оптимізатором?

Спочатку варто зменшити learning rate й перевірити стабільність на короткому прогоні, перш ніж міняти сам алгоритм. Якщо проблема лишається — часто причина не в оптимізаторі, а в масштабі ініціалізації ваг або відсутності gradient clipping.