Якщо ви колись намагалися «просто додати ще одну GPU» і очікували, що графік піде вгору і вправо, ви вже зустріли головного антагоніста цієї історії:
реальний світ. Мульти‑GPU у споживчих іграх — NVIDIA SLI та AMD CrossFire — виглядали як чиста інженерна справедливість: паралелізм,
більше кремнію, більше кадрів, і все готово.
А потім ви відправили продукт у реліз. Часи кадрів перетворилися на пікетний паркан. Стек драйверів став політикою переговорів між рушієм гри, планувальником GPU, PCIe
та тим таймінгом монітора, який ви вважали відомим. Ваш дорогий другий диск часто ставав просто обігрівачем із резюме.
Обіцянка: масштабування шляхом додавання GPU
Мульти‑GPU, як його продавали геймерам, був операційною казкою: ваша гра завантажує GPU, отже ще один GPU означає майже вдвічі більше продуктивності.
Ось цей меседж. Це також перше хибне припущення. Системи не масштабуються тому, що маркетинговий слайд каже «2×»; системи масштабуються, коли найповільніша
частина конвеєра перестає бути вузьким місцем.
Сучасний ігровий кадр — це брудна лінія зборки: симуляція на CPU, відправка викликів малювання, рендеринг на GPU, пост‑обробка, композитинг, презентація
і таймінгова угода з вашим дисплеєм. SLI/CrossFire намагалися приховати складність мульти‑GPU за драйверами, профілями та містком. Це приховування і
стало причиною їхньої загибелі.
Мульти‑GPU‑мрія померла, бо воювала з фізикою (затримки й синхронізація), економікою програмного забезпечення (розробники не тестують рідкісні конфігурації) та
змінами платформ (DX12/Vulkan передали відповідальність від драйвера до рушія). І тому, що «середній FPS» виявився брехнею через замовчування: те,
що відчувають ваші очі — це консистентність фреймтаймів, а не середнє.
Як SLI/CrossFire працювали насправді
Драйвер‑кероване мульти‑GPU: профілі всюди
У класичну епоху SLI/CrossFire покладалися на евристики драйвера та профілі для кожної гри. Драйвер вирішував, як розділити рендеринг між GPU,
без явного знання цього рушієм гри. Це звучить зручно. Воно також стало операційним кошмаром: тепер у вас розподілена система, де один вузол
(гра) не знає, що він розподілений.
Профілі мали значення, бо більшість ігор не писалися так, щоб їх безпечно паралелізувати між GPU. Драйвер потребував ігрово‑специфічних «підказок», щоб уникнути
небезпек на кшталт читання даних, які ще не були створені, або застосування пост‑обробки, що припускає повну історію кадрів.
Основні режими: AFR, SFR і «будь ласка, так не робіть»
Alternate Frame Rendering (AFR) був робочою конячкою. GPU0 рендерить кадр N, GPU1 — кадр N+1, і так далі. На папері: фантастично.
На практиці: AFR — машина для затримок і проблем з кадруванням. Якщо кадр N займає 8 мс, а кадр N+1 — 22 мс, ваш «середній FPS» може виглядати прийнятно, тоді як
очі побачать слайдшоу з пропусками.
Split Frame Rendering (SFR) ділить один кадр на області. Це вимагає акуратного балансування навантаження: одна половина екрана може містити вибух,
шейдери волосся, обʼємну графіку і ваші жаління; інша — просто стіну. Вгадайте, який GPU закінчить першим і буде сидіти в холості.
Були також гібридні режими та вендор‑специфічні хаки. Чим більше хаків потрібно, тим менш загальним стає ваше рішення. В певний момент ви вже не «підтримуєте мульти‑GPU»;
ви пишете драйвер як постійний інцидент‑респонс під кожну гру.
Мости, PCIe і чому інтерконект ніколи не був героєм
Мости SLI (а в ранні епохи — мости CrossFire) забезпечували шлях з вищою пропускною здатністю та нижчою затримкою для певних операцій синхронізації й
обміну буферами, ніж один тільки PCIe. Але міст не зливав VRAM магічно. Кожен GPU усе одно мав власну памʼять. У AFR кожному GPU зазвичай потрібна була
власна копія тих самих текстур і геометрії. Тому «два 8 ГБ карти» не ставали «16 ГБ». Вони ставали «8 ГБ, двічі».
Коли розробники почали інтенсивніше використовувати тимчасові техніки — TAA, screen‑space reflections з буферами історії, тимчасові апскейлери — AFR став
все більш несумісним. Ви не можете легко відрендерити кадр N+1 на GPU1, якщо йому потрібна історія з кадру N, що живе на GPU0, без додавання синхронізації і
передачі даних, які знищать виграш у продуктивності.
Одна перефразована ідея, широко приписувана духу мислення про надійність систем (і часто кажуть інженери з орбіти Google SRE): надія — це не стратегія
.
Вона ідеально підходить для мульти‑GPU. SLI/CrossFire просили вас сподіватися, що рендер‑конвеєр вашої гри співпаде з припущеннями драйвера.
Чому це провалилося: смерть від тисячі країв випадків
1) Кадрування вбило відчуття «швидко»
AFR може давати високий середній FPS, одночасно створюючи нерівномірні часи кадрів (мікростаттер). Люди помічають варіацію. Ваш оверлей для моніторингу може показувати
«120 FPS», а ваш мозок реєструє «нестабільно». Це була центральна проблема для користувацького досвіду: SLI/CrossFire могли вигравати в бенчмарках і програвати по відчуттях.
Кадрування — це не просто «трохи сіпання». Воно взаємодіє з VSync, VRR (G‑SYNC/FreeSync), глибиною черги рендеру і плануванням CPU. Якщо драйвер ставить у чергу кадри занадто агресивно, ви отримуєте затримку вводу. Якщо він ставить занадто мало — зʼявляються бульбашки й сіпання.
Жарт №1: Мульти‑GPU — як мати двох стажерів, що по черзі пишуть сторінки одного звіту — швидко, поки ви не помітите, що вони не сходяться по сюжету.
2) Дзеркалення VRAM: ви платили за памʼять, якою не могли скористатися
У споживчому мульти‑GPU майже завжди відбувалося дзеркалення активів у памʼяті кожного GPU. Це дозволяло масштабувати без розгляду памʼяті як узгодженої спільної купи,
але також означало, що великі текстури, складна геометрія і сучасні структури для прискорення трасування обмежувалися обʼємом VRAM однієї карти.
Коли ігри стали більшими за вимогами до VRAM, план «просто додати другу GPU» став тільки гіршим: вузьке місце перемістилося з обчислень до ємності памʼяті, і мульти‑GPU
не допомагав. Гірше того, друга GPU підвищувала споживання енергії, тепло й вимоги до обдуву корпусу, при цьому даючи той самий ліміт VRAM, що й одна карта.
3) CPU став координатором, і він теж не масштабувався
Мульти‑GPU — це не просто «дві GPU». Це додаткова робота драйвера, додаткове управління командними буферами, більше синхронізації і часто більше викликів малювання.
Багато рушіїв вже були CPU‑звʼязані на потоці рендерингу. Додавання другої GPU може пересунути вузьке місце вгору, і CPU стає обмежувачем.
В термінах продакшену: ви додали пропускну здатність до сервісу‑споживача, не збільшивши пропускання сервісу‑постачальника. Вітаю, ви винайшли нову чергу.
4) Модель профілів драйвера не вижила в ланцюгу постачання ПЗ
Драйвер‑кероване SLI/CrossFire вимагало від вендорів встигати за новими релізами ігор, патчами, оновленнями рушіїв і новими техніками рендерингу. Студії гри
випускали щотижневі оновлення. Постачальники GPU випускали драйвери повільнішим темпом і мали тестувати тисячі комбінацій.
Профіль мульти‑GPU, який працював у версії 1.0, може зламатися у 1.0.3 через те, що змінився порядок пост‑обробки або новий тимчасовий фільтр почав читати попередній буфер кадру.
Драйвер, що «оптимізує» без контексту, може стати тим, що пошкоджує кадр.
5) VRR (змінна частота оновлення) та мульти‑GPU зробили одне одному пакості
Змінна частота оновлення — одне з найкращих покращень якості життя в ПК‑іграх. Вона також ускладнює кадрування мульти‑GPU: дисплей адаптується до кадрувальної подачі,
тому якщо AFR створює сплески й паузи, VRR не «згладить» це; він відобразить нерівномірність чесно.
Багато користувачів апгрейдилися до VRR‑моніторів і виявили, що їхня раніше «нормальна» мульти‑GPU конфігурація виглядає гірше. Це не провина монітора. Це ви, що нарешті бачите правду.
6) Явне мульти‑GPU зʼявилося, і індустрія не захотіла платити рахунок
DX12 і Vulkan зробили можливим explicit multi‑adapter: рушій може керувати кількома GPU без посередництва драйвера. Це технічно чистіше, ніж драйверна магія.
Але це також дорога інженерна робота, яка приносить користь лише крихітній частці клієнтів.
Студії віддавали пріоритет фічам, які доходили до всіх: кращі апскейлери, кращий анти‑аліасинг, кращі пайплайни контенту, краща паритетність з консолями.
Мульти‑GPU був тягарем підтримки з низьким ROI. Він помер так само, як багато корпоративних фіч: тихо, бо ніхто не фінансував ротацію on‑call.
7) Енергоспоживання, тепловий режим і обмеження корпусу: фізичний шар дав відсіч
Дві флагманські GPU вимагають серйозного запасу по живленню, гарного повітряного потоку і часто материнської плати, яка може надати достатньо PCIe‑лінів без тротлінгу.
Конфігурація «користувацький корпус + дві флагманські GPU» — це проєкт теплової інженерії. А більшість людей хотіли компʼютер, а не хобі, що палить пил.
8) Безпека і стабільність: стек драйверів став більшим радіусом ураження
Чим складніша логіка планування драйвера і синхронізації між GPU, тим більше режимів відмов: чорні екрани, TDR (timeout detection and recovery),
дивні артефакти, краші конкретних ігор. В операційних термінах: ви підвищили складність системи і знизили середній час до невинності.
Жарт №2: SLI обіцяв «двічі більше GPU», але іноді давав «двічі більше вирішення проблем», що не є фічею, яку хтось вимірює в бенчмарках.
Історичний контекст: факти, які люди забувають
- Факт 1: Початкове імʼя «SLI» походить від Scan‑Line Interleave компанії 3dfx наприкінці 1990‑х; NVIDIA пізніше знову використала абревіатуру з іншим технічним підходом.
- Факт 2: Раннє споживче мульти‑GPU часто сильно покладалося на AFR, бо це був найпростіший спосіб масштабування без переписування рушіїв.
- Факт 3: Масштабування мульти‑GPU було відомо як непослідовне: деякі тайтли бачили майже лінійний приріст, інші — нуль, а деякі ставали повільнішими через накладні витрати CPU/драйвера.
- Факт 4: «Мікростаттер» став масовою скаргою на початку 2010‑х, коли оглядачі почали вимірювати фрамтайми, а не тільки середній FPS.
- Факт 5: AMD інвестувала в покращення кадрування у драйверах після широкої критики; це допомогло, але не змінило фундаментальних обмежень AFR.
- Факт 6: Багато рушіїв дедалі більше використовували тимчасові буфери історії (TAA, тимчасові апскейлери, вектори руху), що природно незручно для AFR.
- Факт 7: Пропускна здатність PCIe зростала покоління за поколінням, але затримки та накладні витрати на синхронізацію залишалися центральними проблемами для залежностей між кадрами.
- Факт 8: Явне мульти‑GPU у DX12/Vulkan передало контроль у застосунок; більшість студій вирішили не впроваджувати його через вибух тестової матриці.
- Факт 9: NVIDIA поступово обмежувала/змінювала підтримку SLI у пізніших поколіннях, фокусуючись на високому сегменті і конкретних випадках використання замість широкої підтримки ігор.
Що їх замінило (певною мірою): явне мульти‑GPU і сучасні альтернативи
Явне мульти‑GPU: краща архітектура, гірша економіка
Явне мульти‑GPU (DX12 multi‑adapter, Vulkan device groups) — це те, як би ви спроектували систему, якщо б були тверезі: рушій знає, які навантаження можуть виконуватися
на якій GPU, які дані потрібно ділити і коли синхронізувати. Це прибирає багато здогадок драйвера.
Це також вимагає, щоб рушій був структурований для паралелізму між пристроями: дублювання ресурсів, барʼєри між пристроями, акуратна робота з тимчасовими ефектами
та різними стратегіями для різних комбінацій GPU. Це не «підтримка SLI». Це створення другого рендерера.
Кілька тайтлів експериментували з цим. Більшість студій порахували і купили щось інше: тимчасові апскейлери, кращу багатопоточність CPU і оптимізації контенту, які допомагають усім користувачам.
Сучасне «мульти‑GPU», яке працює: спеціалізація
Мульти‑GPU живе там, де навантаження природно паралельне і не вимагає жорсткої когерентності між кадрами:
- Офлайн‑рендеринг / path tracing: можна розподіляти вибірки або тайли між GPU та зливати результати.
- Обчислення / навчання ML: дата‑паралелізм у явних фреймворках, хоч і з власними болями синхронізації.
- Пайплайни кодування відео: окремі GPU можуть обробляти окремі потоки або стадії.
Для реального часу в іграх виграла стратегія: одна потужна GPU, кращий планувальник, кращі апскейлери і кращі техніки генерації кадрів. Не тому, що це «круто», а тому,
що це операційно розумно.
Швидкий план діагностики
Коли хтось каже «мій другий GPU ніби нічого не робить» або «SLI зробив гірше», не починайте з містичних перемикачів драйвера. Спробуйте поставитися до цього як до інциденту.
Визначте, що є вузьким місцем, а потім ізолюйте.
Спочатку: підтвердьте, що система бачить обидві GPU і лінк нормальний
- Чи обидва пристрої присутні в PCIe?
- Чи працюють вони на очікуваному PCIe поколінні/ширині?
- Чи встановлений потрібний міст (якщо він потрібен)?
- Чи правильно підключені силові конектори і чи стабільне живлення?
По‑друге: підтвердьте, що програмний шлях справді мульти‑GPU
- Чи відомо, що гра підтримує SLI/CrossFire для вашого покоління GPU?
- Чи присутній/увімкнений профіль драйвера?
- Чи сумісний API‑шлях (DX11 vs DX12 vs Vulkan) з мульти‑GPU‑режимом вендора?
По‑третє: виміряйте фреймтайми і визначте обмежений ресурс
- Завантаження GPU по карті (не лише «загальне»).
- Насичення потоку рендерингу CPU.
- Використання VRAM і поведінка пагінгу.
- Кадрування (фреймтайм 99‑го перцентиля), а не лише середній FPS.
По‑четверте: прибирайте змінні, поки поведінка не стане зрозумілою
- Тимчасово вимкніть VRR/VSync, щоб подивитися сире кадрування.
- Протестуйте відому добру гру/бенчмарк з задокументованим масштабуванням.
- Протестуйте кожну GPU окремо, щоб виключити марґінальну карту.
Практичні завдання: команди, виводи та рішення
Це передбачає Linux‑робочі станції, які використовують для тестування/CI стендів, лабораторного відтворення або просто тому, що вам подобається біль в передбачуваний спосіб.
Суть не в тому, що Linux — це місце піку SLI у іграх; справа в тому, що Linux дає спостережуваність без пошуку у GUI.
Завдання 1: Перелічити GPU і підтвердити топологію PCIe
cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|display'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] [10de:1b06]
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP102 [GeForce GTX 1080 Ti] [10de:1b06]
Що це означає: Дві GPU перелічені на шині PCIe. Якщо ви бачите лише одну — зупиніться: у вас апаратна/прошивкова проблема.
Рішення: Якщо одна GPU відсутня, переставте в слот, перевірте живлення, налаштування BIOS (Above 4G decoding, конфігурація слотів PCIe), потім повторіть тест.
Завдання 2: Перевірити ширину та покоління PCIe для кожної GPU
cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 8GT/s, Width x16
LnkSta: Speed 8GT/s, Width x16
Що це означає: GPU узгоджує PCIe Gen3 x16 як очікується. Якщо ви бачите x8 або Gen1 — ви знайшли вузьке місце або фолбек.
Рішення: Якщо лінк понижений, перевірте підключення слотів, шаринг ліній на материнській платі (M.2 відбирає лінії), налаштування BIOS PCIe, райзери і цілісність сигналу.
Завдання 3: Підтвердити, що драйвер NVIDIA бачить обидві GPU і звітує завантаження
cr0x@server:~$ nvidia-smi -L
GPU 0: GeForce GTX 1080 Ti (UUID: GPU-aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee)
GPU 1: GeForce GTX 1080 Ti (UUID: GPU-ffffffff-1111-2222-3333-444444444444)
Що це означає: Драйвер бачить обидва пристрої. Якщо одна відсутня тут, але присутня в lspci, ймовірно проблема з привʼязкою драйвера або невідповідністю прошивки.
Рішення: Якщо відсутня, перевірте dmesg на помилки GPU, перевірте модулі ядра і підтвердьте, що обидві GPU підтримуються встановленим драйвером.
Завдання 4: Дивитися завантаження та памʼять по кожній GPU під навантаженням
cr0x@server:~$ nvidia-smi dmon -s pucvmet
# gpu pwr gtemp mtemp sm mem enc dec mclk pclk pviol rxpci txpci
0 210 78 - 92 55 0 0 5500 1582 0 120 110
1 95 64 - 18 52 0 0 5500 1582 0 40 35
Що це означає: GPU0 робить реальну роботу; GPU1 здебільшого простає, але тримає схожу кількість VRAM (дзеркалення активів). Це класична поведінка «друга GPU не використовується».
Рішення: Якщо GPU1 залишається простою, перевірте, чи додаток підтримує мульти‑GPU; інакше припиніть витрачати час на виправлення неможливої фічі.
Завдання 5: Підтвердити деталі сесії Xorg/Wayland (щоб уникнути сюрпризів від композитора)
cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland
Що це означає: Ви на Wayland. Деякі інструменти і деякі застарілі шляхи мульти‑GPU поводяться по‑різному під Wayland і під Xorg.
Рішення: Якщо ви налагоджуєте рендеринг/презентацію, відтворіть під Xorg як контроль, щоб ізолювати ефекти композитора.
Завдання 6: Перевірити логи ядра на помилки PCIe і ресети GPU
cr0x@server:~$ sudo dmesg -T | egrep -i 'pcie|aer|nvrm|gpu|xid' | tail -n 12
[Mon Jan 13 10:19:22 2026] NVRM: Xid (PCI:0000:02:00): 79, GPU has fallen off the bus.
[Mon Jan 13 10:19:22 2026] pcieport 0000:00:03.1: AER: Corrected error received: 0000:02:00.0
Що це означає: «Fallen off the bus» часто вказує на нестабільність живлення/термічну проблему, поганий райзер, ненадійний слот або проблеми цілісності сигналу — мульти‑GPU робить це більш імовірним.
Рішення: Розглядайте це як проблему апаратної надійності: знизьте ліміт потужності, покращіть охолодження, переставте карту, замініть слоти, приберіть райзери, оновіть BIOS і повторно протестуйте стабільність перед тим, як звинувачувати драйвери.
Завдання 7: Перевірити індикатори вузького місця CPU (завантаження, черга runnable, тротлінг)
cr0x@server:~$ uptime
10:22:11 up 3 days, 6:41, 1 user, load average: 14.82, 13.97, 12.10
Що це означає: Високе значення load average може вказувати на насичення CPU або накопичення runnable‑потоків. Ігри можуть бути CPU‑звʼязані на одному потоці рендеру, навіть якщо загальний CPU не «100%».
Рішення: Якщо навантаження високе, а завантаження GPU низьке, припиніть ганятися за перемикачами SLI. Знизьте налаштування, що нагружають CPU (відстань видимості, густота NPC), або прийміть, що ви CPU‑звʼязані.
Завдання 8: Інспектувати використання по ядрах, щоб виявити «зашитий» рендер‑потік
cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0 (server) 01/13/2026 _x86_64_ (16 CPU)
10:22:18 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
10:22:19 AM all 42.0 0.0 8.0 0.2 0.0 0.5 0.0 0.0 0.0 49.3
10:22:19 AM 3 98.5 0.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.5
Що це означає: Одне ядро (CPU3) завантажене на максимум. Це ваш вузький потік рендеру/гри. Дві GPU не допоможуть, якщо кадр не може бути поданий.
Рішення: Знизьте налаштування, що навантажують CPU, або перейдіть на платформу з кращою одноядерною продуктивністю. Мульти‑GPU не вирішить вузький ап‑пайп.
Завдання 9: Перевірити тиск памʼяті (пагінг може маскуватися як «затримки GPU»)
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 32Gi 30Gi 500Mi 1.2Gi 1.5Gi 1.0Gi
Swap: 16Gi 10Gi 6.0Gi
Що це означає: Ви активно свопите. Це знищить фреймтайми незалежно від кількості GPU, які ви накопичуєте.
Рішення: Виправте тиск памʼяті спочатку: закрийте фонові додатки, знизьте налаштування текстур, додайте RAM і повторіть тест. Вважайте використання swap червоним прапором для кадрування.
Завдання 10: Підтвердити частоту CPU і стан тротлінгу
cr0x@server:~$ lscpu | egrep -i 'model name|cpu mhz'
Model name: AMD Ryzen 9 5950X 16-Core Processor
CPU MHz: 3599.998
Що це означає: Показана поточна частота, але не те, чи відбувається тротлінг під тривалим навантаженням.
Рішення: Якщо частоти падають під ігровим навантаженням, виправте охолодження або ліміти живлення. Мульти‑GPU підвищує температуру корпусу, що може тихо знижувати буст CPU.
Завдання 11: Перевірити прапори обмеження потужності / тротлінга на NVIDIA
cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | egrep -i 'Power Limit|Clocks Throttle Reasons' -A3
Power Limit : 250.00 W
Clocks Throttle Reasons
Idle : Not Active
Applications Clocks Setting : Not Active
SW Power Cap : Active
Що це означає: GPU досягає програмного ліміту потужності. У мульти‑GPU системах блок живлення і VRM теплові умови можуть навʼязувати консервативні ліміти.
Рішення: Якщо активний power cap і продуктивність нестабільна, розгляньте зниження цільового FPS, покращення повітряного потоку або запуск однієї GPU з вищими сталими тактовими частотами.
Завдання 12: Перевірити підказки про шаринг PCIe з NVLink/статус мосту (коли доступно)
cr0x@server:~$ nvidia-smi topo -m
GPU0 GPU1 CPU Affinity
GPU0 X PHB 0-7
GPU1 PHB X 8-15
Що це означає: PHB вказує, що комунікація йде через PCIe host bridge; це не тісний peer‑to‑peer шлях. Це може зашкодити навантаженням, які потребують інтенсивного обміну між GPU.
Рішення: Якщо топологія погана, не очікуйте, що між‑GPU співпраця буде дешевою. Віддавайте перевагу рендерингу на одній GPU або явному розподілу навантаження, який уникатиме спільного обміну даними.
Завдання 13: Підтвердити видимість пристроїв Vulkan (для експериментів з явним мульти‑GPU)
cr0x@server:~$ vulkaninfo --summary | egrep -i 'GPU id|deviceName' -A1
GPU id : 0 (GeForce GTX 1080 Ti)
deviceName = GeForce GTX 1080 Ti
GPU id : 1 (GeForce GTX 1080 Ti)
deviceName = GeForce GTX 1080 Ti
Що це означає: Vulkan бачить обидва пристрої. Це передумова для явних мульти‑GPU додатків, але не гарантія, що гра це підтримуватиме.
Рішення: Якщо показує лише один пристрій — виправте інсталяцію драйвера/рантайму. Якщо обидва видні, переходьте до перевірки можливостей на рівні додатка.
Завдання 14: Перевірити затримку сховища (так, це може виглядати як «затримки GPU»)
cr0x@server:~$ iostat -xz 1 3
avg-cpu: %user %nice %system %iowait %steal %idle
38.12 0.00 6.21 8.93 0.00 46.74
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s w_await aqu-sz %util
nvme0n1 210.0 38400.0 0.0 0.00 3.10 182.86 75.0 10240.0 9.80 2.10 78.00
Що це означає: Високий iowait і підвищений await можуть спричинити підвисання стримінгу. Мульти‑GPU не виправить затримки компіляції шейдерів чи латентності стрімінгу ресурсів.
Рішення: Якщо сховище насичене, зменшіть фонові IO, перемістіть гру на швидше сховище і налаштуйте поведінку кешу шейдерів. Виправте реальний вузький ресурс.
Поширені помилки (симптом → корінь → виправлення)
1) «Друга GPU показує 0–10% завантаження»
Симптоми: Одна GPU гаряча, інша простає; FPS незмінний порівняно з однією GPU.
Корінь: Ігровий/API‑шлях не підтримує драйвер‑кероване мульти‑GPU, або профіль драйвера відсутній/вимкнений.
Виправлення: Перевірте підтримку тайтлу для вашого покоління GPU і режим API. Якщо гра на DX12/Vulkan і не реалізує явне мульти‑GPU, прийміть однокарткову конфігурацію.
2) «Вищий середній FPS, але відчуття гірше»
Симптоми: Бенчмарк каже швидше; геймплей відчувається сіпучим; VRR це підкреслює.
Корінь: Варіація фреймтаймів від AFR (мікростаттер), черги або непостійне навантаження на кадр.
Виправлення: Виміряйте фреймтайми і обмежте FPS для стабілізації кадрування, або вимкніть мульти‑GPU. Пріоритезуйте 1% low / 99‑й перцентиль фреймтаймів замість середніх значень.
3) «Текстури зʼявляються пізніше, потім фризи стають жахливими на 4K»
Симптоми: Різкі піки, особливо при різкому повороті камери або вході в нові області.
Корінь: Ліміт VRAM на GPU; дзеркалення означає, що ви не отримали додаткової ємності. Відбувається пагінг активів і зупинки.
Виправлення: Знизьте роздільність текстур, зменште налаштування RT, або перейдіть на одну GPU з більшим VRAM.
4) «Випадкові чорні екрани / GPU зникла»
Симптоми: Ресети драйвера, одна GPU випадає з шини, переривчасті проблеми зі стабільністю.
Корінь: Нестабільне живлення, термічний стрес, маргінальна цілісність сигналу PCIe або розгін, який здавався «стабільним» на одній карті.
Виправлення: Поверніть стоки частот, зменшіть ліміт потужності, покращіть охолодження, перевірте кабелі, уникайте райзерів, оновіть BIOS і протестуйте кожну GPU окремо.
5) «Працює в одній версії драйвера, ламається в наступній»
Симптоми: Масштабування зникає або зʼявляються артефакти після оновлення драйвера.
Корінь: Зміни профілів, зміни планувальника або регресія в кодових шляхах мульти‑GPU (які тепер мають низький пріоритет).
Виправлення: Зафіксуйте версії драйверів для вашого випадку використання, документуйте робочі комбінації і не вважайте «новіший драйвер» автоматично кращим для мульти‑GPU.
6) «Дві GPU, але використання CPU виглядає низьким — все одно CPU‑звʼязано»
Симптоми: Завантаження GPU низьке, FPS зафіксований, загальний CPU < 50%.
Корінь: Один або два гарячі потоки (рендер, ігровий потік). Загальний CPU приховує насичення по ядрах.
Виправлення: Спостерігайте використання по ядрах. Знизьте CPU‑важкі налаштування; орієнтуйтеся на стабільні фреймтайми; подумайте про апгрейд платформи замість додавання GPU.
7) «PCIe x8/x4 несподівано, погане масштабування»
Симптоми: Гірше‑ніж‑очікувалось масштабування; сильний стуттер під час стрімінгу; топо показує PHB‑шляхи.
Корінь: Шерінг ліній з M.2/іншими пристроями, неправильний вибір слота або обмеження чипсету.
Виправлення: Користуйтеся правильними слотами, зменшіть споживачів ліній або обирайте платформу з більшою кількістю CPU‑ліній, якщо наполягаєте на багатьох пристроях.
Три корпоративні міні‑історії з поля бою
Міні‑історія 1: Інцидент, спричинений неправильним припущенням
Невелика студія мала «лабораторію продуктивності» з кількома висококласними тестовими стендами. Хтось побудував монстр‑машину: дві топові GPU, купа RGB і таблиця бенчмарків,
що тішила менеджмент. Студія використовувала її для погодження бюджетів продуктивності для нового контент‑навантаженого рівня.
Неправильне припущення було тонким: вони вважали, що масштабування репрезентативне. Їхній підписувальний стенд працював в AFR з профілем драйвера, який випадково добре
підходив для тієї конкретної збірки. Він давав чудовий середній FPS у лабораторії. На більшості клієнтських машин він не давав хороших фреймтаймів і точно не репрезентував
одиночну GPU‑базу, якою володіла більшість.
Настав релізний тиждень. Соцмережі заповнилися скаргами на «фризи на новому рівні». Всередині студії стенд виглядав «ок». Інженери почали шукати фантомні баги в анімації і фізиці,
бо графіки GPU не здавалися зашитими.
Справжнім винуватцем був стрімінг активів плюс новий тимчасовий ефект. На лабораторній машині AFR маскував частину часу GPU, накладаючи операції, але погіршував кадрування
так, що студія не вимірювала. На одиночних GPU у користувачів те саме приводило до перевищення VRAM і пагінгу та трешингу кешу шейдерів. Студія оптимізувала під неправильну реальність.
Виправлення не було магічним мульти‑GPU трюком. Вони перебудували свої пороги продуктивності: тестування на одній GPU, на основі фреймтаймів, з порогами тиску памʼяті.
Двокарткова машина залишилася в лабораторії, але перестала бути джерелом істини. Інцидент закінчився, коли вони перестали довіряти бенчмарку, який не відповідав популяції користувачів.
Міні‑історія 2: Оптимізація, що обернулася проти
Команда візуалізації підприємства (подумайте: великі сцени CAD, рендеринги в реальному часі) спробувала «витиснути безкоштовну продуктивність», увімкнувши AFR у контрольованому середовищі.
Їхні сцени були важкими на тимчасове накопичення: анти‑аліасинг, денойзинг і купа логіки «використовувати попередній кадр». Хтось стверджував, що оскільки GPU ідентичні, результати мають бути погодженими.
Вони отримали вищу середню пропускну здатність зі статичною камерою. Чудове демо. Потім вони випустили бета‑версію внутрішнім стейкхолдерам. Як тільки камера рухнулася — стабільність зображення
погіршилася: привиди, мерехтіння і непостійні тимчасові фільтри. Гірше, інтерактивна затримка відчувалася гірше через збільшення глибини черг під AFR.
Бекфайр був архітектурним: тимчасовий пайплайн рендерера припускав когерентну історію кадрів. AFR розділив цю історію між пристроями. Команда додала точки синхронізації і передачі між GPU,
щоб «пофіксити», що знищило виграш у продуктивності і додало нові паузи. Тепер у них була складність і відсутність прискорення.
Вони врешті‑решт вимкнули AFR і інвестували в нудні покращення: culling на боці CPU, спрощення шейдерів і правила LOD для контенту. Кінцева система була швидшою на одній GPU,
ніж AFR‑збірка була на двох. Оптимізація провалилася, бо намагалася паралелізувати те, що було фундаментально серійним у часовій залежності.
Міні‑історія 3: Нудна, але правильна практика, що врятувала ситуацію
Група валідації апаратного забезпечення в середній компанії підтримувала флот GPU‑тестових вузлів. Вони не гралися на них; запускали регресії рендерингу і обчислень і час від часу відтворювали баги клієнтів.
Ноди включали мульти‑GPU бокси, бо клієнти використовували їх для обчислень, а не для розваг.
Їхньою секретною зброєю не був хитрий планувальник. Це був changelog. Кожен нод мав закріплену версію драйвера, базову прошивку і просту матрицю «known‑good».
Оновлення виконувалися поетапно: спочатку канарка‑нод, потім невелика партія, потім решта. Без винятків. Нікому це не подобалося. Це здавалося повільним.
Одного тижня новий драйвер ввів інтермітуючі кориговані помилки PCIe на конкретній ревізії материнської плати при навантаженні обох GPU змішаного типу.
На робочій станції розробника це виглядало як випадкові краші додатків. У флоті канарочний нод почав виділяти AER‑логи протягом кількох годин.
Через нудну дисципліну вони корелювали таймлайн, відкотили канарку і заблокували розгортання. Ніякої флот‑широкої нестабільності, ніякого масового перевстановлення, ніякого панічного порятунку.
Вони подали тикет вендору з відтворюваними логами і чіткою рецептурою відтворення.
«Порятунок» не був героїчною відладкою. Це була операційна практика поетапних розгортань і фіксації версій. Мульти‑GPU системи підсилюють маргінальні проблеми; єдино розумна відповідь —
ставитися до змін як до виробничих, а не як до вихідних експериментів.
Контрольні списки / покроковий план
Покроково: вирішіть, чи варто взагалі зачіпати мульти‑GPU
- Визначте мету. Це вищий середній FPS, кращі 1% лови, чи конкретне обчислювальне/рендерне навантаження?
- Ідентифікуйте тип навантаження. Режим реального часу з тимчасовими ефектами? Припустіть «ні». Офлайн‑рендер/обчислення? Можливо «так».
- Перевірте реальність підтримки. Якщо додаток не реалізує явне мульти‑GPU і вендор більше не підтримує профілі драйверів — зупиніться тут.
- Заміряйте базу. Одна GPU, стабільний драйвер, фреймтайми, використання VRAM, по‑ядрове завантаження CPU.
- Додайте другу GPU. Підтвердьте ширину PCIe, живлення, теплові умови і топологію.
- Повторно виміряйте. Шукайте покращення в 99‑му перцентилі фреймтаймів і пропускній здатності, а не лише в середньому FPS.
- Прийміть рішення. Якщо виграш невеликий або кадрування стало гіршим — приберіть другу карту. Податок на складність реальний.
Покроково: стабілізувати мульти‑GPU бокс (коли потрібно його запускати)
- Спочатку працюйте на стокових частотах. Розгони, «стабільні» на одній GPU, можуть впасти в двокарткових теплових умовах.
- Підтвердьте бюджет потужності. Переконайтеся в запасі по PSU; уникайте ланцюгового зʼєднання кабелів PCIe для високого споживання.
- Зафіксуйте версії. Закріпіть драйвер/прошивку; виконуйте оновлення поетапно, як у продакшені.
- Інструментуйте. Логуйте dmesg, AER‑події, причини тротлінгу GPU, температури і завантаження.
- Встановіть очікування. Для ігор ви оптимізуєте для стабільності і кадрування, а не для скріншотів бенчмарків.
Питання та відповіді
1) Чи працювали SLI/CrossFire колись по-справжньому?
Так — іноді. У добре профільованих DX11‑титрах з AFR‑дружніми пайплайнами і мінімальними тимчасовими залежностями масштабування могло бути сильним. Проблема в тому, що «іноді»
не є продуктовою стратегією.
2) Чому VRAM не сумувався між GPU для ігор?
Тому що кожному GPU потрібен локальний доступ до текстур і геометрії на повній швидкості, і споживче мульти‑GPU зазвичай дзеркалить ресурси на кожну карту.
Без уніфікованої моделі памʼяті ви не можете трактувати два пулі VRAM як один без великих витрат на синхронізацію і передачі.
3) Що таке мікростаттер, з операційної точки зору?
Це варіація латентності. Ви доставляєте кадри в непостійних інтервалах — сплески й паузи — через що рух виглядає нерівним. Саме тому «середній FPS» — небезпечна і неповна метрика.
4) Чому DX12/Vulkan зробили мульти‑GPU рідшим замість більш поширеним?
Вони зробили його явним. Це архітектурно чесно, але перекладає роботу на команду рушія: управління ресурсами, синхронізація, тестування по комбінаціях GPU і QA‑покриття.
Більшість студій не захотіли це фінансувати для малої бази користувачів.
5) Чи можуть дві різні GPU працювати разом для ігор зараз?
Не так, як раніше «драйвер сам за вас». Явний multi‑adapter теоретично може використати різнорідні GPU, але реальна підтримка рідкісна і зазвичай спеціалізована. Для типових ігор —
припускайте «ні».
6) А NVLink — чи виправляє це?
NVLink допомагає у певних сценаріях peer‑to‑peer пропускної здатності і цінний у обчисленнях. Він не вирішує автоматично проблеми кадрування, тимчасові залежності чи економіку розробки.
Інтерконекти не виправляють архітектуру.
7) Якщо я вже володію двома GPU, що мені робити?
Для ігор: використовуйте одну GPU і продайте другу, або перейдіть її на обчислення/кодування. Для обчислень: використовуйте фреймворки, що явно підтримують мульти‑GPU,
і заміряйте масштабування з реалістичними розмірами батчів і накладними витратами синхронізації.
8) Яким метрикам варто довіряти при тестуванні мульти‑GPU?
Перцентилі фреймтаймів (наприклад, 99‑й), відчуття затримки вводу (важко виміряти, легко помітити), завантаження по GPU, запас VRAM і логи стабільності.
Середній FPS у цьому контексті — метрика для показухи.
9) Чи мульти‑GPU повністю вмерло?
Не повністю — просто в споживчих реальних іграх як стандартний шлях прискорення. Мульти‑GPU живе там, де навантаження можна чисто розділити: офлайн‑рендеринг, наукові обчислення,
ML і деякі професійні візуалізаційні пайплайни.
Наступні кроки, які ви справді можете зробити
Якщо ви думаєте про мульти‑GPU для ігор у 2026 році, ось відверта порада: не робіть цього. Купіть найкращу одну GPU, яку можете собі дозволити, а потім оптимізуйте
фреймтайми, запас VRAM і стабільність стеку драйверів. Ви отримаєте систему, яка поводиться передбачувано — а це те, чого ви хочете, коли вам доводиться її налагоджувати.
Якщо ви мусите запускати мульти‑GPU — бо ваше навантаження обчислювальне, офлайн‑рендер або спеціалізована візуалізація — поводьтеся з ним як з інфраструктурою продакшену:
фіксуйте версії, поетапно розгортайте, інструментуйте все і припускайте, що друга GPU збільшує площу поверхні відмов більше, ніж продуктивність.
Практичні наступні кроки:
- Змініть мислення тестування з «середній FPS» на перцентилі фреймтаймів і відтворювані прогони.
- Підтвердьте ширину PCIe, топологію і стабільність живлення перед налаштуванням драйверів.
- Вирішіть уперед, чи ваш додаток використовує явне мульти‑GPU; якщо ні — припиніть витрачати час.
- Тримайте одну відому‑добру базову версію драйвера і ставтесь до оновлень як до контрольованого розгортання.