Дешевше, а не точніше

Дванадцять тем поспіль ми ставили мережі одне питання: наскільки точно вона відповідає. AlexNet і VGG відповіли на нього глибиною й кількістю фільтрів, ResNet — скіп-зʼєднанням, яке зробило глибину керованою. А потім мережі довелося вийти з серверної: розблокувати телефон обличчям, знайти документ у кадрі камери, розмити тло під час відеодзвінка просто в браузері. І виявилось, що питання «наскільки точно» — не єдине, а іноді й не головне.

Ця тема про три архітектурні родини, які виникли з другого питання: Inception (2014), MobileNet (2017) і EfficientNet (2019). Але головне в ній не вони, а те, що зʼясувалося дорогою: «дешевше» — не одне число, а три, і вони посварені між собою.

ОбмеженняМережа має кудись поміститись

Коли модель живе на сервері, її обмеження — гроші й нічого більше. Мало памʼяті — докупи. Повільно — постав другу машину. На пристрої в кишені все інакше, і обмежень стає щонайменше чотири.

Останній рядок найпідступніший: його не видно на жодному замірі, зробленому на робочому столі. А браузер додає своє — там немає ані відеокарти в звичному сенсі, ані права качати сотні мегабайтів перед першим кадром.

Три числаТри різні «дешевше»

Спершу треба розібратися, що ми взагалі міряємо: слово «дешевше» ховає три різні величини, і плутати їх коштує дорого.

Легко припустити, що всі три впорядковують архітектури однаково: менше параметрів — менше множень — менше часу. Це припущення хибне. Ось девʼять справжніх архітектур, зібраних без ваг (нам потрібна форма, а не вміння), один потік процесора, без відеокарти; час — найкращий із тридцяти прогонів.

Від VGG16 до MobileNet-v3-small — 54 рази за параметрами. Але подивись на AlexNet. За параметрами він другий із девʼяти: 61 мільйон, більше за ResNet50 і Inception-v3 разом узяті. За часом він — сьомий, тобто третій із кінця. Ті самі девʼять мереж, два різні порядки.

AlexNet: багато ваг, мало роботи. Повнозвʼязний шар на 4096 нейронів має 4096 × 9216 ≈ 37 мільйонів ваг — і робить рівно 37 мільйонів множень. Одна вага — одне множення, і все. Згортковий шар поводиться протилежно: ядро 3×3 на 256 каналів має 590 тисяч ваг, але прикладається до кожного з 28 × 28 положень, тобто робить 462 мільйони множень. Одна вага — сотні множень. Тому мережа з головою на мільйони параметрів важить багато й рахує мало, а мережа з тілом на ті самі мільйони важить мало й рахує довго. Це той самий переїзд ваг з голови в тіло, який тема 14 показала на ResNet, — тільки тепер ми дивимось на нього з боку вартості.

EfficientNet-B0 проти AlexNet: менше всього — а часу стільки ж. У EfficientNet-B0 в 11.6 раза менше параметрів і в 1.85 раза менше множень, ніж в AlexNet. За часом вони практично рівні: 42.5 мс проти 37.9. Тобто зменшили обидва числа, які вміємо рахувати, — і не виграли нічого в тому єдиному, що відчуває користувач.

Це не помилка заміру, а головна незручна правда теми. Повернемось до неї в розділі 06.

InceptionНе обирати розмір ядра

Повернімось у 2014 рік. Проєктувальник мережі мусить для кожного шару відповісти на питання, на яке нема відповіді: яке брати ядро — 1×1, 3×3 чи 5×5?

Питання не дозвільне. Ядро 3×3 бачить дрібну деталь: край, кут, штрих. Ядро 5×5 — більший фрагмент: вигин, кільце, фактуру. А предмети бувають різного розміру навіть в одному кадрі: кіт на передньому плані й кіт удалині займають різну кількість пікселів, і те, що для першого «дрібна деталь», для другого вже цілий кіт.

Класична відповідь — підібрати: побудувати десяток мереж, навчити всі, взяти найкращу. Дорого, а головне — відповідь буде єдиною на всю мережу й на всі зображення.

Автори GoogLeNet відповіли інакше: не обирати. Пропустити вхід через усі варіанти одразу й скласти результати поруч.

вхід: 192 канали, карта 28×28
   │
   ├── 1×1 ────────────────→  64 канали
   ├── 3×3, padding 1 ─────→ 128 каналів
   ├── 5×5, padding 2 ─────→  32 канали
   └── maxpool 3×3 → 1×1 ──→  32 канали
   │
   torch.cat по каналах
   ↓
вихід: 256 каналів, карта 28×28

Це і є модуль Inception (Inception module). Чотири гілки рахуються незалежно від одного й того самого входу, а потім їхні виходи склеюються по каналах — операцією torch.cat(..., dim=1).

«Склеюються по каналах» варто розкрити. Кожна гілка дає карту тієї самої висоти й ширини — 28×28, це забезпечено підбором padding; різняться вони лише кількістю каналів. Склеювання ставить ці стоси один на одного: 64 + 128 + 32 + 32 = 256 каналів тієї самої карти. Нічого не додається й не усереднюється — результати гілок лежать поруч, і наступний шар сам вирішить, на які з них дивитись.

Гілка з пулінгом стоїть там із тієї самої логіки: пулінг із теми 08 — теж спосіб подивитись на околицю, тож нехай і він буде одним із варіантів.

ГорлоПляшкове горло 1×1

У щойно намальованому модулі є проблема, і вона арифметична. Порахуймо гілку 5×5 чесно, за формулою параметрів згорткового шару з теми 07:

Підставляємо: вхід 192 канали, вихід 32 канали, ядро 5×5.

Сто пʼятдесят три тисячі параметрів на одну гілку, яка дає всього 32 канали з 256. Гілка 3×3 із її 128 каналами коштує ще більше: 192 × 128 × 9 + 128 = 221 312. Разом модуль важить 393 472 параметри. А таких модулів у GoogLeNet девʼять, і кожен наступний працює з більшою кількістю каналів.

Джерело витрати видно з формули: перший множник — cin, тобто 192. Дороге не саме ядро 5×5, а те, що воно мусить дивитись на всі 192 вхідні канали одночасно.

Рішення — те, що ми вже вміємо. Згортка 1×1 з теми 07 не дивиться на сусідів у просторі взагалі: вона бере один піксель і змішує його канали. Тому вона дешева. Поставимо її перед дорогим ядром — щоб стиснути 192 канали до 16, а вже потім прикласти 5×5.

Ця стисла проміжна ділянка й зветься пляшковим горлом (bottleneck): широкий вхід, вузьке місце посередині, широкий вихід. Те саме зробимо з гілкою 3×3 — стиснемо 192 канали до 96, — і порахуємо модуль повністю.

Гілка 1×1 не міняється — вона вже й є згорткою 1×1, горло їй ні до чого. Гілка з пулінгом теж: пулінг не має ваг, а 1×1 після нього і є її єдиним шаром.

Тепер зрозуміло, чому модуль Inception узагалі можна собі дозволити. Горло — не прикраса до ідеї паралельних гілок, а умова її існування.

РозділитиРоздільна згортка по глибині

Горло 1×1 — напівзахід: воно зменшує кількість каналів перед дорогим ядром, але саме ядро й далі робить дві справи одночасно. MobileNet запитав: а навіщо взагалі дві справи в одній операції?

Придивімось до звичайної згортки 3×3 із 64 каналів у 128. Кожен із 128 вихідних каналів — це сума по всіх 64 вхідних каналах, і в кожному з них ще й сума по вікну 3×3. Тобто одна операція відповідає на два різні питання:

• «де» — як пікселі поєднуються зі своїми сусідами в просторі (це робота вікна 3×3);
• «що» — як поєднуються між собою канали, тобто різні виявлені ознаки (це робота підсумовування по 64 каналах).

Ідея MobileNet: розділити ці два питання на дві окремі операції. Спершу тільки «де», окремо в кожному каналі. Потім тільки «що», без огляду на сусідів. Результат зветься роздільною згорткою по глибині (depthwise separable convolution).

Ми нічого не відкинули: обидві операції разом і далі дивляться на вікно 3×3 в усіх каналах. Змінилось інше — замість 64 × 128 = 8192 окремих ядер 3×3 (по одному на кожну пару «вхідний канал → вихідний канал») тепер є 64 ядра 3×3 плюс таблиця змішування 64 × 128. Добуток розпався на суму.

Ось як економія росте з кількістю каналів:

Числа наближаються до девʼяти й не переходять межу. Це не збіг — межу видно з формул. Якщо на секунду відкинути зсуви (їх мало й вони нічого не вирішують), відношення дорівнює:

Прочитаймо це словами. Скоротилось cin — кількість вхідних каналів на відношення не впливає взагалі. Лишились дві величини: розмір ядра й кількість вихідних каналів. Коли вихідних каналів багато, доданок 1/cout стає мізерним, і відношення прямує до k² = 9. Для ядра 5×5 межа була б 25.

Перевіримо на числах: при k=3 і cout=128 маємо 1 ÷ (0.1111 + 0.0078) = 8.41; у таблиці стоїть 8.24, і різниця — це саме ті зсуви, які ми відкинули.

РозривЧому економія в 9 разів не дає прискорення в 9 разів

Ми щойно скоротили параметри у 8.24 раза; множення скорочуються приблизно так само — формула та сама, лише помножена на розмір карти. Здається, що й час має впасти у вісім разів. Заміряймо.

Вхід 64 канали, карта 56×56, один шар, один потік процесора:

Виграш є, але вдвічі менший за обіцяний — і це ще добрий випадок. На нашій маленькій мережі з фігурами 28×28 роздільна згортка скоротила параметри в 6.2 раза, а час не скоротила майже ніяк:

Параметрів у шість разів менше, множень у пʼять разів менше, точність та сама — а часу заощаджено вісім відсотків, і це менше за розкид самого заміру. Чому?

Причина в тому, що процесор не витрачає час на множення. Він витрачає його на очікування чисел із памʼяті.

Це не здогад — це видно в замірах, якщо поділити множення на час. Величина «скільки мільйонів множень залізо встигає за мілісекунду» показує, наскільки повно використано процесор.

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

І це пояснює, чому AlexNet у нашій першій таблиці такий швидкий, попри 61 мільйон параметрів. Його вага сидить у повнозвʼязних шарах, а повнозвʼязний шар — це множення матриці на вектор, найкраще відлагоджена операція в усій обчислювальній техніці.

Останній доказ того самого — на роздільності входу. Візьмемо одну й ту саму нашу мережу й подамо їй різні за розміром зображення. Параметри не зміняться зовсім: завдяки глобальному усередненню голова мережі не знає, якого розміру була карта. Множення виростуть квадратично. А час?

РучкиДві ручки MobileNet

Досі ми міняли саму операцію. Але автори MobileNet зробили ще одну річ, зовсім просту й щонайменше таку ж корисну.

Вони визнали, що не знають, який бюджет буде в користувача. Тому замість однієї моделі випустили сімейство й дали дві ручки, якими користувач сам рухається по кривій «точність проти вартості».

Ручка перша: множник ширини

Множник ширини (width multiplier), позначається α — це просто число, на яке множиться кількість каналів у кожному шарі. Було 16, 32, 64 канали — при α = 0.5 стане 8, 16, 32.

Параметри згорткового шару — це cin × cout × k², і множник зменшує обидва множники одразу. Отже:

Половина ширини — чверть параметрів, а не половина. Це щедра ручка: невелике зменшення каналів дає велике зменшення вартості. Заміряємо на нашій мережі з фігурами:

Від 1.00 до 0.50 параметрів стало вчетверо менше, а точність упала на 1.1 пункту: з 0.973 до 0.962. Виглядає як безкоштовна економія — але наскільки стійкі ці числа?

Ми навчили ту саму мережу при α = 0.5 ще двічі, змінивши лише випадкове зерно: 0.962, 0.935, 0.978. Розкид — 4.3 пункту, тобто вчетверо більший за різницю між α = 0.5 і α = 1.0.

Це типова ситуація, а не вада заміру: фігури — легка задача, і мережа з 6 тисячами параметрів розвʼязує її не гірше за мережу з 24 тисячами. Саме тому ручка й потрібна: оптимальна ширина залежить від задачі, а автор архітектури твоєї задачі не знає.

Ручка друга: множник роздільності

Множник роздільності (resolution multiplier), позначається ρ — це просто менше вхідне зображення. Замість 224×224 подати 192×192, або 160×160, або 128×128.

Діє вона зовсім інакше за першу:

Отже ручки не взаємозамінні: вагу завантаження зменшує тільки α, а час і батарею — обидві. На нашій задачі та сама мережа на 23 798 параметрів при вході 20×20 замість 28×28 робить 979 584 множення замість 1 919 616 (удвічі менше), витрачає 7.13 мс замість 13.02, а точність дає 0.957 проти 0.973. Параметрів, як і обіцяно, рівно стільки ж.

РазомEfficientNet: масштабувати треба все разом

До 2019 року в інженера було три способи зробити мережу більшою, і кожен використовували поодинці:

• глибина d — більше шарів. Так росла VGG (11 → 16 → 19) і ResNet (18 → 34 → 50 → 101 → 152);
• ширина w — більше каналів у шарі. Так росла Wide ResNet і так само працює ручка α з попереднього розділу;
• роздільність r — більше вхідне зображення.

Автори EfficientNet поставили питання інакше: якщо в тебе вдвічі більший бюджет, куди його вкласти? І показали замірами, що кожен окремий шлях швидко вичерпується. Глибока, але вузька мережа не має чим представляти складні ознаки. Широка, але мілка — не встигає зібрати з простих ознак складні. Велика роздільність без глибини й ширини дає купу пікселів, які нема кому опрацювати.

Звідси складене масштабування (compound scaling): рости треба за всіма трьома осями одночасно й у сталій пропорції. Пропорція задається одним числом — коефіцієнтом φ, який каже, у скільки разів більший бюджет ти готовий витратити:

Тут α, β, γ — три сталі, свої для родини архітектур, а φ — єдина ручка, яку крутить користувач. Запис αφ означає «α, помножене саме на себе φ разів». Самі сталі не довільні — вони повʼязані бюджетом, і ось як кожна вісь впливає на кількість множень:

Значення, які автори EfficientNet опублікували: α = 1.2, β = 1.1, γ = 1.15. Перевіримо множення: 1.2 × 1.1² × 1.15² = 1.2 × 1.21 × 1.3225 = 1.92 — справді близько до двійки.

ПошукАрхітектуру можна не вигадувати, а шукати

Складене масштабування каже, як збільшувати мережу. Але від чого відштовхуватись? У EfficientNet є базова модель B0, з якої розгортаються B1…B7. Звідки взялась сама B0?

Її не вигадала людина. Її знайшла програма — методом, що зветься пошук архітектур (neural architecture search, NAS): описати простір можливих мереж (скільки блоків, які ядра, де роздільні згортки), а далі перебирати варіанти, навчати кожен і залишати кращі.

Перше, чого не варто недооцінювати: це дорого. Не «треба потужний компʼютер», а сотні й тисячі відеокарто-днів на один пошук. Беручи готову EfficientNet, ти користуєшся результатом обчислення, яке не повториш.

Друге: критерій пошуку вирішує все. MobileNet-v3 шукали не за кількістю множень, а за заміряним часом на реальному телефоні — і саме тому вона вийшла іншою, ніж мережі, підібрані за FLOPs. Це той самий висновок розділу 06, тільки зроблений авторами архітектури: оптимізуєш не ту величину — отримаєш не ту мережу.

ВибірЩо обирати під задачу

Питання «яка архітектура найкраща» відповіді не має. Питання «яка вкладається в мій бюджет» — має завжди.

Найчастіша помилка тут — обрати архітектуру за таблицею з чужої статті: там міряли на іншому залізі й, найімовірніше, у FLOPs. Правильний порядок інший: назви свій бюджет числом, візьми дві-три кандидатури, заміряй їх на своєму залізі — і лише потім дивись на точність серед тих, що вклались.

ПідсумокЩо лишається в голові

Ця тема не додала жодного нового способу зробити мережу точнішою. Вона додала інше — уміння називати ціну.

І один висновок, важливіший за всі шість. Економія параметрів — не економія часу. Ми бачили це тричі: роздільна згортка дала 8.24× за параметрами й 4.45× за часом на одному шарі; 6.19× за параметрами й 1.08× за часом на нашій мережі; а мережі на роздільних згортках використовують процесор у три-сім разів гірше за грубу VGG16. Кількість множень — міра роботи, а не швидкості, і між ними стоїть памʼять.

Місток до наступної теми

Девʼять архітектур із наших таблиць різняться між собою в 54 рази за вагою й у 40 разів за часом. Але є одне, у чому вони не різняться зовсім: усі вони навчені на ImageNet — базі з мільйона зображень, де кожне має мітку, поставлену людиною.

Скільки коштує та мітка, ми рахували ще в темі 02: розмітка — найдорожча частина будь-якого проєкту компʼютерного зору. Ми навчилися робити мережу вдесятеро дешевшою в обчисленнях — і не зрушили найбільшу статтю витрат ані на копійку.

Наступна тема — 16. Самонаглядове навчання — про спробу прибрати саме її. Питання там просте на слух і незручне по суті: чи може мережа навчитися дивитись на зображеннях, яких ніхто не розмічав?