Штучний Інтелект05.11.2026

Як перетворити Conv2D на практичний шаблон GPU-обчислень

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

У цій статті розглянуто практичний спосіб реалізації двовимірної згортки (Conv2D) як структурованого різновиду множення матриць. Мета — не рекламувати продукт чи результат тестування, а показати підхід до оптимізації, який стане в пригоді розробникам GPU-ядер.

Ключова ідея: згортка 1×1 фактично є множенням матриць, а більші згортки K×K можна подати як послідовність матричних накопичень. Для цього важливо враховувати роботу кешу й порядок циклів.

Чому це важливо

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

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

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

Почнімо з форм тензорів

Стандартну операцію Conv2D можна описати як застосування тензора навчених фільтрів до вхідного тензора для отримання вихідного.

C = A * B

Тут A — вхідний тензор розміром N × H × W × C_in; B — тензор ваг розміром H_filter × W_filter × C_in × C_out; C — вихідний тензор розміром N × H_out × W_out × C_out.

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

Чим особлива згортка 1×1

Згортка 1×1 найнаочніше демонструє зв’язок із множенням матриць. У кожній просторовій позиції вхідні дані задають вектор ознак довжини C_in. Ваги перетворюють його на вихідний вектор довжини C_out.

Якщо вхідний тензор уже збережений у форматі NHWC, вектор ознак у кожній просторовій позиції природно можна трактувати як рядок матриці — без явного переставляння даних.

Практичний висновок: для вхідних даних у форматі NHWC згортку 1×1 можна безпосередньо реалізувати як множення матриць із C_in каналів у C_out. Результат також матиме формат NHWC, і транспонування не знадобиться.

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

Від 1×1 до згортки K×K

Коли фільтр більший за 1×1, кожен вихідний елемент залежить від кількох просторових позицій. Наприклад, згортка 3×3 поєднує дев’ять окремих внесків. Концептуально це набір матричних добутків, результати яких накопичуються.

Отже, завдання вже не зводиться до простого множення матриць: потрібно багаторазово виконувати матричні обчислення й накопичення, водночас мінімізуючи марні звернення до пам’яті.

Для фільтра 3×3 у кожній вихідній позиції є дев’ять внесків розміром C_in × C_out. Наївна реалізація може ефективно використовувати обчислювальні ресурси, але водночас багаторазово вивантажувати й повторно завантажувати вхідні дані в ієрархії кешу. Тому порядок виконання має вирішальне значення.

Порядок циклів — частина оптимізації

Один із важливих уроків оптимізації згорток полягає в тому, що математично еквівалентні обчислення можуть по-різному навантажувати пам’ять.

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

Зміна порядку циклів може поліпшити локальність даних, зменшити повторні завантаження й підвищити повторне використання кешу. Арифметика залишається тією самою, але шаблон доступу до пам’яті стає ефективнішим.

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

Типовий шаблон ядра

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

VEC_TYPE out_vec = 0.0; // accumulator for results, with _N_STRIDE length
 while ((idx_x += 2) < K_STEPS * 2) {
 for (int fh = 0; fh < F_H; ++fh) {
 for (int fw = 0; fw < F_W; ++fw) {
 int idx_in2 =
 IDX_FROM_4D(fh, fw, F_W, idx_x * 4 + load_in2_k_offset, CI, load_in2_n_offset, CO);
 ((__local float *)localBuf)[local_idx] = (load_in2_n_offset >= CO) ? 0 : in2[idx_in2];

      const int hi = h * STRIDE_H + fh * DILATION_H - PAD_TOP;

      const int wi = w * STRIDE_W + fw * DILATION_W - PAD_LEFT;

idx_y = IDX_FROM_3D(b, hi, IN_H, wi, IN_W);
 input1_8.lo = (float4)read_imagef(in1, samp, (int2){idx_x, idx_y});
 input1_8.hi = (float4)read_imagef(in1, samp, (int2){idx_x + 1, idx_y});
 barrier(CLK_LOCAL_MEM_FENCE);
 batch8_F32_MM(input1_8, (__local float16 *)localBuf, (float2 *)&out_vec,
 (float2 *)&out_vec);
 barrier(CLK_LOCAL_MEM_FENCE);
 }
 }
 }

У такому ядрі добре видно, де зазвичай прихований потенціал продуктивності:

Векторизоване читання замість скалярних звернень.
Розміщення даних у локальній пам’яті для повторного використання ваг.
Структуроване накопичення за позиціями фільтра.
Явна синхронізація під час роботи зі спільними даними.
Паралелізм на рівні потоків для обробки кількох виходів.

Доповнення нулями, крок і обробка меж

На реальні ядра згортки впливають не лише фільтри, а й такі параметри, як доповнення, крок і дилатація. Вони позначаються і на коректності, і на продуктивності.

Стратегія доповнення

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

float8 input1_8 = 0;
 if ((hi >= 0) && (hi < IN_H) && (wi >= 0) && (wi < IN_W))
 {
 input1_8[i] = { ... }
 }

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

Важливо: перевірки меж потрібні не лише для коректності. Їхнє місце у вкладених циклах може помітно впливати на пропускну здатність.

Крок і розмір фільтра

Розмір фільтра й крок також впливають на продуктивність, хоча цей вплив не завжди очевидний.

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

Ці ефекти зазвичай не абсолютні. Більший фільтр не обов’язково робить ядро швидшим, так само як більший крок не обов’язково сповільнює його. Проте обидва параметри змінюють баланс між обчисленнями й трафіком пам’яті — саме на цьому часто залежить продуктивність Conv2D.

Що інженери можуть узяти з цього підходу

Найцінніше в цій реалізації Conv2D — не окрема мікрооптимізація, а метод, на якому вона ґрунтується.

Починати з чіткого розуміння структури тензорів.
Визначати, коли операцію природно можна подати як множення матриць.
За можливості зберігати початковий формат даних, щоб уникнути зайвого переміщення.
На ранніх етапах зосереджуватися на порядку циклів і повторному використанні кешу.
Вважати доповнення, крок і логіку обробки меж важливими рішеннями для продуктивності.

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

Поширені помилки

Під час перетворення Conv2D на GPU-ядро з матричними обчисленнями часто припускаються таких помилок:

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

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

Практична модель мислення

Під час розробки або аналізу GPU-ядра згортки корисно розглядати завдання на трьох рівнях:

Математика: які значення потрібно перемножити й накопичити?
Розташування даних: як значення організовані в пам’яті та чи можна використати цей формат без перетворень?
Виконання: у якому порядку запускати роботу, щоб ефективно використовувати кеш, локальну пам’ять і векторні блоки?

Ефективні ядра зазвичай виникають тоді, коли узгоджено всі три рівні, а не коли надмірно оптимізовано лише один із них.

Підсумок

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

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

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

Маріо Флореа — директор з інженерії в Imagination Technologies. Він керує розробкою програмного забезпечення для ШІ та GPU-прискореного інференсу на периферійних пристроях. Його робота зосереджена на ефективному виконанні навантажень ШІ на пристроях з обмеженими ресурсами та на поєднанні сучасних моделей ШІ з оптимізованим GPU-обладнанням.

Нагадаємо, GPT — це сімейство великих мовних моделей, навчених на великих обсягах текстових даних.