Intel проти AMD для реальної роботи: компіляція, рендеринг, віртуальні машини та ШІ

October 7, 2025 • February 3, 2026 • Читання: 5 хв • Views: 0

Було корисно?

Ваш CI-пайплайн повільний, хост для віртуальних машин підкидає джиттер, рендери в Blender розтікаються до завтра, а «AI box» дивно упирається в вузьке місце, яке не GPU.
Вибір CPU, який ви зробили два квартали тому, тепер фігурує в ваших інцидент-репортах.

Intel проти AMD — це не фанатський конфлікт. Це набір компромісів, які виявляються у хвилинах на збірку, коефіцієнтах консолідації віртуальних машин, бурях cache-miss, обмеженнях енергоспоживання і «чому цей потік опинився на E‑core?»
Приймаймо рішення як дорослі, яких будили опівночі.

Що насправді означає «реальна робота»

«Реальна робота» — це не один бенчмарк. Це купа вузьких місць, що змінюються залежно від часу:
лінкер перетворює CPU на генератор cache-miss; рендер — на теплову машину;
віртуалізація — у проблему планування; ШІ — у годівницю пам’яті.

Тому питання не «хто швидший?», а:
який CPU робить ваше навантаження стабільним, передбачуваним і економічно ефективним під тривалим навантаженням — і який з них породжує режими відмов, через які ви проведете вихідні.

На що слід оптимізувати

Час до результату: час збірки, час рендеру, пропускна здатність навчання або затримка запиту.
Хвостова затримка під конкуренцією: найповільніший 1% ламає деплої та SLO.
Детермінованість: стабільні частоти й поведінка планувальника важать більше за піковий буст у лабораторії.
Підсистема пам’яті: пропускна здатність, латентність, кількість каналів і топологія NUMA часто вирішують, хто переміг.
I/O і PCIe: GPUs, NVMe, NIC-и і passthrough — це рішення платформи, не просто кількості ядер.
Реальність енергоспоживання та охолодження: ваш стій не цікавиться маркетинговим PDF.

Коротко: хто в чому перемагає

Ви можете сперечатися про винятки вічно. У продакшні більшість рішень зводиться до «нам потрібні багато ліній пам’яті і стабільний потік?» проти «нам потрібна найкраща затримка на потік?» проти «нам потрібна найпростіша поведінка платформи?»

Компіляція великих кодових баз (ядро Linux, Chromium, LLVM, ігрові рушії)

AMD часто перемагає за пропускною здатністю за долар, коли ви можете забезпечити ядра достатньою пам’яттю і I/O.
Intel часто виграє по затримці на потік і іноді має переваги в конкретних тулчейнах або бібліотеках, але гібридні ядра ускладнюють CI-ранери.
Правило рішення: якщо збірки добре паралеляться і дружні до кешу — ядра допомагають; якщо домінує лінк або латентність пам’яті — вирішують частоти й поведінка кешу.

Рендеринг (Blender, Arnold, V-Ray, офлайн пайплайни)

Обидва вищі варіанти перемагають, якщо можуть тримати частоти під навантаженням. Перемагає CPU, який тримає частоти при 100% навантаженні у вашому шасі, а не той, що має найвищий «до» показник.
Висока кількість ядер у AMD може бути жорсткою перевагою у ферм для CPU-рендеру; Intel конкурує при сильній поведінці на всіх ядрах і в певних AVX-сценаріях.
Правило рішення: купуйте за стійку частоту при всіх ядрах у межах вашого теплового пакета і бюджету на живлення.

Хости VM (KVM/Proxmox/VMware, змішані навантаження)

AMD EPYC часто практичний вибір для щільності: багато ядер, багато каналів пам’яті, багато PCIe-ліній, хороше співвідношення perf/W.
Intel Xeon може вирізнятися зрілістю платформи, певними екосистемними акселераторами і іноді кращою одноядерною продуктивністю для «шумних» контрольних задач.
Правило рішення: віддавайте пріоритет ємності/пропускній здатності пам’яті й бюджетові PCIe-ліній більше, ніж піковому турбо-ядру.

ШІ (тренування і інференс, з GPU, але CPU не другорядний)

CPU годує GPU: препроцесинг даних, токенізація, вхідний пайплайн, компресія/декомпресія, мережа і файлові операції — усе на CPU.
AMD часто виграє у серверах за рахунок каналів пам’яті і ліній, що допомагає тримати GPU зайнятими; Intel іноді випереджає у певних векторних інструкціях і тонко налаштованих бібліотеках.
Правило рішення: якщо ваші GPU чекають, купуйте CPU/пам’ять/I/O-платформу, яка припинить їх чекати.

Факти та історія, що досі важливі

x86-64 походить від AMD (AMD64). Intel прийняв його пізніше, а індустрія пішла цим шляхом, бо це було найменш болісне міграційне рішення.
Ера «tick-tock» Intel навчила покупців очікувати передбачуваних зменшень технологічного вузла; коли цей ритм зламався, стабільність платформи стала важливішою за пікову частоту.
Чіплет-дизайни пішли в маси з AMD, що дозволило високі кількості ядер і гнучкий I/O; це змінило криву «більше ядер дорожче».
NUMA не зникла. Багаточіпові дизайни зробили локальність пам’яті першокласною характеристикою, а не академічною деталлю.
AVX-512 стала сумнівною сумішшю сумісності: сильна на деяких Intel‑чіпах, відсутня або відрізняється на інших, і загалом її слід ставити як «приємно, якщо є», а не як план.
Ера Spectre/Meltdown навчила, що мікроархітектурні фічі можуть стати вектором безпеки з наслідками для продуктивності.
Гібридні ядра Intel принесли складність планування з ноутбуків на десктопи/сервери; це може бути чудово, але також новий клас «чому це повільно?» тикетів.
Бюджет PCIe-ліній був тихим фактором у робочих станціях/сервах; він вирішує, чи можна запускати кілька GPU, швидкі NVMe і NIC-и без компромісів.

Компіляція: пропускна здатність, затримки та кеш

Компіляція — жорстоке навантаження, бо виглядає як CPU-bound, поки ви не проінструментуєте систему.
Потім виявляється, що ваш дорогий CPU чекає на дрібні читання, page cache misses, вирішення символів або на однопоточну фазу в лінкері.

Що насправді робить збірки швидкими

Швидке сховище для коду й артефактів збірки (NVMe, достатньо IOPS, не загальна мережна файловa система, яка «має сьогодні поганий день»).
Достатньо RAM, щоб тримати заголовки, об’єктні файли і робочі множини компілятора гарячими.
Сильна продуктивність на потік для серіальних фаз (configure, лінкери, вузькі місця codegen).
Багато ядер для паралельної компіляції, але тільки якщо ви можете їх годувати без I/O-трещання.
Кеш і латентність пам’яті, бо фронтенд компілятора багато працює з вказівниками.

Intel vs AMD: патерни при компіляції

На практиці «більше ядер за гроші» у AMD часто перемагає для великих збірок, коли ваша система збірки добре паралелізується.
Intel часто відчувається більш чутливим для інтерактивної розробки і певних однопоточних фаз, особливо якщо частоти тримаються високими під навантаженням.

Пастка: купити багато ядер, а потім компілювати на раннері з маленьким RAM‑диском, повільним SSD або перевантаженою загальною файловою системою.
Так ви отримаєте 64 ядра й збірку, яка працює так, ніби її тягнуть хом’яки.

Жарт №1: Сервер збірки без достатньої RAM — як кавоварка без води: технічно вражає, практично місце злочину.

Гібридні ядра та CI-раннери

Гібридні дизайни Intel можуть бути відмінними, але CI-системи і тулзи не завжди ввічливі щодо того, на які ядра потоки потрапляють.
Якщо важкі компіляційні потоки перескакують на енергоефективні ядра, статися зростання часу виконання і варіації.
Виправлення рідко означає «купити інший CPU», частіше — «закріпити, ізолювати і виміряти».

Рендеринг: ядра, частоти та стійка потужність

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

Що важить для CPU-рендерингу

Стійка частота на всіх ядрах при безпечних температурах, а не піковий буст для одного ядра.
Кількість ядер для embarrassingly parallel навантажень рендеру.
Пропускна здатність пам’яті для складності сцени і текстурної навантаженості (залежить від рендерера).
Стабільність під AVX/векторними навантаженнями. Деякі шляхи коду сильно знижують частоти під важкими векторними інструкціями.

Intel vs AMD: реальність рендерингу

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

Рендеринг також робить «ефективність» рядком бюджету. Менше ваттів на кадр — більше вузлів на стій і менше гнівних листів від інфраструктури.

Віртуальні машини та контейнери: NUMA, IOMMU і «шумні сусіди»

Віртуалізація — це момент, коли CPU перестає бути просто «чіпом» і стає системою. Ви купуєте топологію: канали пам’яті, PCIe-лінії, маршрутизацію переривань, поведінку IOMMU і дружність планувальника.

Чому AMD часто виглядає добре для хостів VM

Щільність ядер допомагає консолідації, коли у вас багато середніх VM.
Канали пам’яті важливі для сумарної пропускної здатності і щоб уникати штрафів за віддалений доступ NUMA.
PCIe-лінії важливі для NVMe-пулів, NIC-ів і passthrough GPU без компромісів.

Чому Intel іноді безпечніший вибір для підприємств

Послідовність платформи між поколіннями в деяких інфраструктурах, що зменшує операційну варіативність.
Відповідність екосистемі з певними вендорами, інструментами прошивки і драйверами.
Сильне одноядерне для control-plane сервісів і затримкочутливих змішаних навантажень.

NUMA: невидимий податок

NUMA-проблеми виглядають як «моя VM іноді повільна». На хості видно багато CPU. Диск нормальний. Мережа — нудна.
Потім ви розумієте, що половина звернень до пам’яті — віддалені.

Багатосокетні Intel та AMD, навіть деякі односокетні чіплет-дизайни, можуть кусатися тут. Виправлення передбачуване:
вирівняйте vCPU і розміщення пам’яті, уникайте крос-ноду алокацій і перестаньте робити вигляд, що «один великий CPU» — реальна річ.

PCI passthrough і особливості IOMMU

Для GPU passthrough або швидкісного NIC passthrough групування IOMMU і налаштування прошивки важать більше, ніж бренд.
Ви хочете материнську плату/BIOS, що поводиться як інструмент, а не як головоломка.

Навантаження ШІ: CPU важить більше, ніж вам хочеться

Якщо ви запускаєте тренування на GPU і думаєте «процесор неважливий», ви, мабуть, ніколи не бачили, як GPU вартістю $10k простоює, бо потік dataloader заблокований на декомпресії.

Де CPU стає вузьким місцем у ШІ-системах

Вхідний пайплайн: декодинг зображень, парсинг записів, токенізація, аугментації.
Сховище і файлові системи: дрібні читання, операції з метаданими, поведінка кешу.
Мережа: переміщення даних для розподіленого тренування або шарів сервінгу.
CPU-сторінкова математика: препроцесинг ембедингів, інженерія ознак, постпроцесинг.
Оверхед оркестрації: Python runtime, contention потоків, контейнерний оверхед, переривання.

Intel vs AMD для AI-серверів

Якщо ви будуєте GPU‑сервери, історія про лінії та пам’ять AMD може бути чистою перемогою: більше місця для GPU і NVMe без PCIe-шеллгеймів.
Intel може бути відмінним, коли ваш стек налаштований під певні бібліотеки, коли потрібна сильна одноядерна продуктивність для високого QPS інференсу, або коли ваш постачальник передбачає це.

Найкраща практична метрика — не «CPU‑бенчмарк», а зайнятість GPU у часі і end-to-end пропускна здатність.
Якщо GPU стоять, можливо, причина — у CPU/платформі.

Платформні компроміси: пам’ять, PCIe, енергоспоживання та те, про що ви шкодуєте пізніше

Канали пам’яті та ємність

Для VM і ШІ ємність і пропускна здатність пам’яті часто визначають реальну межу.
CPU з «менше, швидших ядер» може програти CPU з «більше каналів пам’яті і достатньо ядер», коли навантаження годується з пам’яті.

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

PCIe-лінії та топологія

Multi‑GPU, NVMe RAID/ZFS пулі й 100GbE NIC-и хапають лінії.
Якщо ви купите платформу, що не може їх коректно провести, годинами будете дебажити, чому карта застрягла на x4 або чому два пристрої ділять пропускну здатність.

Енергетичні ліміти: різниця між «бенчмарком» і «вівторком»

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

Надійність — це фіча, а не настрій

Ось ваша цитата, бо це суть:
«Надія — не стратегія.» — генерал Гордон Р. Салліван

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

Практичні завдання: команди, виводи і рішення

Ви не обираєте Intel або AMD за відчуттями. Ви обираєте, виходячи з того, що ваші системи показують під навантаженням.
Нижче конкретні завдання, які можна виконати на Linux-хостах для діагностики і прийняття рішення.

Завдання 1: Ідентифікуйте топологію CPU (ядра, потоки, NUMA)

cr0x@server:~$ lscpu
Architecture:                         x86_64
CPU(s):                               64
Thread(s) per core:                   2
Core(s) per socket:                   32
Socket(s):                            1
NUMA node(s):                         2
NUMA node0 CPU(s):                    0-31
NUMA node1 CPU(s):                    32-63

Що це означає: один сокет, але два NUMA‑вузли (звично для чіплетів). Крос‑ноду доступи до пам’яті можуть коштувати дорого.
Рішення: для pinning VM або рендер-джобів тримайте CPU і алокації пам’яті в межах NUMA-вузла, якщо можливо (або принаймні протестуйте обидва варіанти).

Завдання 2: Перевірте масштабування частот і governor

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

Що це означає: governor встановлено в performance, зазвичай добре для ферм збірки і низької латентності.
Рішення: якщо ви бачите powersave на сервері, що виконує збірки/рендери, очікуйте повільніші і більш спайкові результати; змініть governor або політику BIOS/OS відповідно.

Завдання 3: Спостерігайте реальне троттлінг і терміни

cr0x@server:~$ sudo turbostat --Summary --quiet --interval 5
Avg_MHz   Busy%   Bzy_MHz  TSC_MHz  PkgTmp  PkgWatt
4050      92.10   4395     3600     86      215.3

Що це означає: CPU зайнятий, температура пакета висока і споживання потужності суттєве. Якщо Avg_MHz або Bzy_MHz падають з часом, у вас троттлінг.
Рішення: якщо стійкі MHz падають під час рендерів, виправте охолодження/енергетичні ліміти до купівлі «швидшого» CPU.

Завдання 4: Підтвердьте мікрокод і kernel‑мітігації

cr0x@server:~$ dmesg | egrep -i 'microcode|spectre|meltdown' | tail -n 6
[    0.231] microcode: updated early: 0x2f -> 0x35, date = 2024-02-12
[    0.873] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
[    0.873] Spectre V2 : Mitigation: Retpolines; IBPB: conditional; STIBP: always-on; RSB filling
[    0.873] Meltdown   : Mitigation: PTI

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

Завдання 5: Виміряйте пропускну здатність збірки на відтворюваній збірці

cr0x@server:~$ /usr/bin/time -v make -j$(nproc)
...
Elapsed (wall clock) time (h:mm:ss or m:ss): 6:42.11
User time (seconds): 24012.55
System time (seconds): 1120.33
Percent of CPU this job got: 620%
Maximum resident set size (kbytes): 25100432

Що це означає: CPU utilization не близький до 6400% на машині з 64 потоками; ви лишаєте ядра простою — часто через I/O або пам’ять.
Рішення: якщо CPU% низький, припиніть купувати ядра і почніть виправляти I/O (NVMe, tmpfs для директорії збірки, кращий ccache, більше RAM).

Завдання 6: Виявити I/O wait під час збірок або тренувань

cr0x@server:~$ iostat -xz 2 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          38.22    0.00    7.10   24.55    0.00   30.13

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         120.0   210.0  9800.0 18200.0   8.40   0.32  10.5

Що це означає: %iowait високий; CPU чекає на сховище.
Рішення: якщо iowait домінує, бренд CPU не має значення — виправте локальність сховища, проблеми з чергуванням, файлову систему або перемістіть артефакти збірки з перевантажених томів.

Завдання 7: Перевірте тиск пам’яті і свопінг

cr0x@server:~$ vmstat 2 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
12  0      0 184320  10240 8123456  0    0   120   240 6200 9800 55  8 30  7  0
18  2  524288  20480  11000 620000  0  4096  150  1200 7500 15000 48 12 20 20 0

Що це означає: spikes своп-ауту (so) і зростання wa. Ви пейджите.
Рішення: більше RAM, зменшити паралелізм або виправити процеси, що втекли. Для хостів VM — це також ознака вийшовшого з-під контролю overcommit.

Завдання 8: Підтвердьте локальність пам’яті NUMA для процесу

cr0x@server:~$ numastat -p 12345
Per-node process memory usage (in MBs) for PID 12345 (renderd)
Node 0          18240.12
Node 1           1120.55
Total           19360.67

Що це означає: процес переважно використовує пам’ять Node 0. Добра локальність, якщо його потоки на Node 0.
Рішення: якщо пам’ять розподілена порівну, а потоки ні — закріпіть через numactl або налаштуйте vNUMA у VM; крос‑NUMA трафік може зруйнувати продуктивність рендеру та VM.

Завдання 9: Перевірте розширення віртуалізації і IOMMU

cr0x@server:~$ egrep -m1 -o 'vmx|svm' /proc/cpuinfo
svm

cr0x@server:~$ dmesg | egrep -i 'iommu|dmar|amd-vi' | head
[    0.612] AMD-Vi: IOMMU performance counters supported
[    0.613] AMD-Vi: Interrupt remapping enabled

Що це означає: апаратна віртуалізація присутня (svm для AMD, vmx для Intel) і IOMMU активний.
Рішення: якщо IOMMU вимкнено, PCI passthrough буде болісним або неможливим; виправте BIOS і параметри ядра перед тим, як винуватити вибір CPU.

Завдання 10: Перевірте хост KVM/QEMU на steal time і contention

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.6.0 (server)  01/10/2026  _x86_64_  (64 CPU)

12:00:01 AM  CPU  %usr %nice %sys %iowait %irq %soft %steal %idle
12:00:02 AM  all  62.0  0.0  7.5   1.0     0.0  0.5    0.0   29.0

Що це означає: низький iowait і немає steal на хості; добре. У гостях steal time — канарка для overcommit.
Рішення: якщо гості показують високий steal, зменшіть overcommit, зарезервуйте ядра для «шумних» сервісів або розділіть затримкочутливі VM.

Завдання 11: Перевірте ширину і швидкість PCIe (GPU/NVMe‑вузькі місця)

cr0x@server:~$ sudo lspci -s 65:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s, Width x16

Що це означає: GPU працює на повній ширині і швидкості лінії.
Рішення: якщо ви несподівано бачите x8 або нижче, перевірте проводку слота, біфуркацію або спільне використання ліній. Це вже «вибір платформи», а не голий CPU.

Завдання 12: Перевірте huge pages і бекінг пам’яті для VM

cr0x@server:~$ grep -i huge /proc/meminfo | head
AnonHugePages:    12582912 kB
HugePages_Total:      2048
HugePages_Free:       1024
Hugepagesize:         2048 kB

Що це означає: huge pages сконфігуровані і частково вільні.
Рішення: для високопропускних VM (БД, NFV) huge pages знижують тиск на TLB. Якщо хости фрагментують і huge pages недоступні, плануйте алокацію під час завантаження і вікна обслуговування.

Завдання 13: Виявити дивну поведінку планувальника на гібридних ядрах (Intel)

cr0x@server:~$ ps -eo pid,comm,psr,pri,ni,cls --sort=-pri | head
  PID COMMAND         PSR PRI  NI CLS
 9421 clang++          11 139  -   TS
 9418 clang            37 139  -   TS
 9416 ld               2  139  -   TS

Що це означає: процеси працюють на конкретних CPU ID (PSR).
Рішення: якщо критичні потоки постійно опиняються на повільніших ядрах (часто видно як певні діапазони CPU), встановіть CPU‑affinity для агентів збірки або використайте cpuset/cgroup‑розділення.

Завдання 14: Визначити, чи GPU голодний (AI training)

cr0x@server:~$ nvidia-smi dmon -s pucm -d 2 -c 3
# gpu   pwr  sm   mem  enc  dec  mclk  pclk
# Idx     W   %    %    %    %   MHz   MHz
    0    95  42   18    0    0  8101  1410
    0    96  39   17    0    0  8101  1410
    0    92  44   19    0    0  8101  1410

Що це означає: SM‑util близько ~40%. Якщо ваша модель мала б наситити GPU, ймовірно, є обмеження вхідного пайплайну або CPU‑бік.
Рішення: профіліруйте використання CPU dataloader‑ів, пропускну здатність сховища і мережу; розгляньте більше CPU‑ядер, швидше сховище або кращий паралелізм препроцесингу перш ніж купувати ще GPU.

Швидкий план діагностики

Коли продуктивність погана, не починайте зі «Intel vs AMD». Почніть з вузького місця. Ось порядок триажу, що рятує час і гідність.

Перше: підтвердьте, що система не бреше вам

Перевірте тротлінг (терміни/потужність): чи колапсує частота під тривалим навантаженням?
Перевірте governor/політику енергоспоживання: чи не застрягли ви в powersave або агресивному eco‑режимі?
Перевірте мікрокод/BIOS‑регресії: чи не змінила недавня прошивка поведінку?

Друге: класифікуйте вузьке місце за 60 секунд

CPU‑bound: високе user CPU, низький iowait, стабільні частоти.
I/O‑bound: високий iowait, зростання latency/await на сховищі, низький CPU% для таски.
Memory‑bound: високі cache misses (якщо вимірюєте), часті page faults або віддалений NUMA‑доступ.
Scheduler‑bound: черги runnable великі, контекстних переключень багато, потоки мігрують, хвостові затримки стрибають.

Третє: зіставте це з правильною «категорією виправлення»

Якщо CPU‑bound: більше ядер (пропускна здатність) або швидші ядра (латентність); розгляньте ISA/оптимізації бібліотек.
Якщо memory‑bound: більше каналів, вища швидкість пам’яті, кращий NUMA‑placement; зменшити крос‑ноду трафік.
Якщо I/O‑bound: локальний NVMe scratch, тюнінг файлової системи, кешування, уникайте віддалених FS для «гарячих» артефактів.
Якщо scheduler‑bound: ізолюйте ядра, закріпіть завдання, налаштуйте cgroups, зменшіть вплив «шумних» сусідів.

Три корпоративні міні-історії з передової

Міні-історія 1: Інцидент через хибне припущення (NUMA «не має значення»)

Середня SaaS‑компанія мігрувала свій основний кластер віртуалізації. Старі хости були скромні: менше ядер, поведінка як одно‑NUMA‑вузол і «достатньо добре».
Нові хости на папері були монстрами — більше ядер, швидша пам’ять, загалом краще.

Через тиждень канал інцидентів наповнився. Деякі бази даних у VM почали спонтанно стрибати по латентності під час рутинних бекграунд‑джобів.
Не завжди, не передбачувано. Графіки CPU були нормальні. Латентність диска — нормальна. Мережа — нудна.
На чергуванні з’явилась забобонна приказка: «не деплоїмо після обіду».

Хибне припущення було простим: «один сокет = однорідна пам’ять». Нова платформа виявила два NUMA‑вузли, і гіпервізор щасливо розміщував vCPU на одному вузлі, тоді як алокації пам’яті дрейфували на інший під навантаженням.
Віддалений доступ до пам’яті перетворився на «випадковий джиттер», а джиттер — у хвостову латентність.

Виправлення не було екзотичним. Налаштували vNUMA у VM, закріпили найчутливіші VM на наборі CPU, що вирівняні з вузлом, і припинили overcommit RAM на тих хостах.
Продуктивність стабілізувалась негайно. Ніяких героїчних дій, тільки уважність до топології.

Урок: Intel або AMD не спричинили той інцидент. Причини — віра в те, що топологія опціональна.

Міні-історія 2: Оптимізація, що відбилася бумерангом (агресивне енерготюнінг)

Креативна студія запускала CPU‑рендерні вузли вночі і хотіла знизити витрати на електрику. Хтось амбітно застосував агресивні енергетичні обмеження в BIOS по всьому флоту.
«Короткий тест» пройшов, тож зміна була розгорнута.

Через місяць дедлайни почали просідати. Нічні рендери не встигали. Черга накопичувалась.
Студія звинувачувала нову версію рендерера, потім сторедж, потім «оновлення Windows», бо це традиція.

Справжня проблема: стійкі навантаження по всіх ядрах під новими обмеженнями змусили CPU сидіти на значно нижчих частотах, ніж раніше.
Короткий тест не виявив цього, бо жив у вікні turbo; продакшн‑рендери жили в стійкій тепловій реальності.

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

Урок: можна оптимізувати ватти, але потрібно вимірювати на стійких навантаженнях. Turbo — ввічлива брехуха.

Міні-історія 3: Нудна, але правильна практика, що врятувала день (базова + канаркові хости)

Фінансова компанія виконувала змішані навантаження: CI‑збірки, внутрішні VM і деякі сервіси інференсу. Вони захотіли протестувати нове покоління CPU.
Вони зробили рідкісну річ: побудували два канаркові хости з ідентичними RAM, сховищем, BIOS‑налаштуваннями і версіями ядра, і запускали їх паралельно з продакшном тижнями.

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

Оскільки у них був базовий експеримент і канарка, вони відстежили це рано, скорелювали з вікном оновлення і відклали ту версію ядра у продакшні.
Ніяких інцидентів. Жодної війни у кімнаті. Просто тихе «не сьогодні» рішення.

Урок: найефективніший інструмент продуктивності — контрольований експеримент. Це також найменш гламурна річ у кімнаті, тому її забувають.

Поширені помилки: симптом → корінь → виправлення

1) Збірки повільніші після «апгрейду» на більше ядер

Симптоми: час збірки ледь покращився; CPU‑використання низьке; зростає iowait.

Корінь: сховище і page cache не встигають годувати паралельну компіляцію; сканування заголовків і записи об’єктів насичують IOPS.

Виправлення: розташуйте директорію збірки на локальному NVMe, збільшіть RAM, ввімкніть/настройте ccache, зменшіть -j до значення, що не тротлить, і уникайте загальних ФС для гарячих артефактів.

2) Джиттер латентності VM, що здається «випадковим»

Симптоми: періодичні спайки латентності в гості; хост‑CPU виглядає недовантаженим; очевидних I/O проблем немає.

Корінь: NUMA‑місмейч або ballooning пам’яті, що викликає віддалений пам’ятний доступ; overcommit, що дає steal time.

Виправлення: налаштуйте vNUMA, закріпіть vCPU, зв’яжіть пам’ять, зменшіть overcommit для чутливих VM і валідуйте з numastat і метриками steal у гостях.

3) Рендер‑вузли добре бенчмаркують, але гірше в продакшні

Симптоми: короткі тести швидкі; довгі рендери повільніють; температури високі; частоти падають.

Корінь: енергетичне/термальне троттлінг, нереалістичні очікування boost або AVX‑важкі шляхи, що знижують частоти.

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

4) Низька зайнятість GPU при тренуванні/інференсі

Симптоми: GPU простоюють; CPU‑ядра завантажені; з’являється disk iowait або мережева затримка.

Корінь: вхідний пайплайн CPU‑bound або сховище‑bound; замало dataloader‑виконавців; повільна декомпресія; затримка віддаленої ФС.

Виправлення: обережно збільшіть паралелізм dataloader‑ів, перемістіть датасети на локальний NVMe, попередньо декодуйте/упакуйте дані і моніторьте end‑to‑end пропускну здатність, а не тільки час моделі.

5) «Однакова модель сервера, різна продуктивність»

Симптоми: ідентичні SKU поводяться по‑різному; один повільніший або більш спайковий.

Корінь: різні BIOS‑дефолти (потужність, memory interleaving, SMT), різні версії microcode, або один хост має гірше охолодження.

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

6) Сервіси з багатьма потоками регресують на гібридних ядрах

Симптоми: вища хвостова латентність; непередбачувані часи відповіді; CPU виглядає «не дуже зайнятим».

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

Виправлення: ізолювати performance‑ядра для критичних сервісів, використовувати cgroups/cpuset і валідувати по‑ядерні метрики; не покладайтеся на дефолти.

Жарт №2: Якщо ваш план продуктивності — «ми просто автоскейлимось», вітаю — ви винайшли дуже дорогий спосіб вибачитись.

Чек‑листи / покроковий план

Покроково: вибір Intel vs AMD для нової робочої станції (компіляція + рендер + випадкові VM)

Запишіть домінуюче навантаження в годинах/тиждень: компіляція, рендер, VM, препроцесинг ШІ.
Визначте клас вузького місця: чутливість до латентності (одноядерна), пропускна здатність (всі ядра), пропускна здатність пам’яті або I/O‑важке.
Встановіть ціль RAM: 64–128GB для серйозних мультипроєктних збірок/рендерів; більше, якщо запускаєте кілька VM.
Плануйте сховище: один NVMe для ОС, один для scratch/build/cache, опційно окремий для датасетів/проєктів.
Вирішіть стратегію ядер:
- Якщо щодня компілюєте величезні кодові бази: віддавайте перевагу ядрам + кешу + достатній RAM і швидкому scratch.
- Якщо рендеринг домінує: пріоритет — стійка продуктивність на всіх ядрах і охолодження.
Перевірте лінії платформи: потреби GPUs + NVMe + NIC. Не купуйте платформу, що змушує вас робити відомі компроміси.
Запустіть канарковий бенчмарк на репрезентативному репозиторії/сцені перед купівлею 20 машин.

Покроково: вибір CPU для хоста віртуалізації (версія «не отримувати пейджі вночі»)

Інвентаризуйте профілі VM: CPU на VM, RAM на VM, IOPS на VM і чи потрібен passthrough.
Вирішіть політику overcommit заздалегідь: CPU‑overcommit може бути; memory‑overcommit лише з планом і моніторингом.
Розмір пам’яті і канали перед кількістю ядер. Голі ядра без пам’яті — декоративні.
Моделюйте NUMA: плануйте node‑aligned розміщення для великих VM; уникайте spanning, якщо можна.
Підтвердіть запас PCIe‑ліній: NIC‑и, NVMe, HBAs, GPU. Брак ліній — постійна шкода.
Стандартизуйте BIOS і microcode: розглядайте це як конфігурацію флоту; зберігайте known‑good профіль.
Плануйте спостережуваність: перехоплення perf‑сounterів на хості, steal time у гостях і latency сховища.

Покроково: вибір CPU/платформи для AI‑сервера (GPU‑центрист, але не ігнорувати CPU)

Почніть з GPU: кількість, генерація PCIe, живлення і охолодження.
Вирахуйте потреби CPU: чи можете ви годувати ці GPU? Розгляньте dataloader CPU, компресію і мережу.
Пріоритет — пропускна здатність пам’яті: достатньо каналів і швидкості для препроцесингу і робіт на боці хоста.
Пріоритет — I/O: локальний NVMe для датасетів, достатньо ліній і реальний NIC для розподіленого навчання.
Раннє вимірювання зайнятості GPU на реалістичному пайплайні; не погоджуйтеся на «воно тренується» як на критерій проходження.

FAQ

1) Для серверів збірки: краще купувати більше ядер чи швидші ядра?

Якщо ваші збірки добре паралеляться і сховище/RAM встигають за ними, більше ядер перемагає. Якщо домінує час лінку або серіальні кроки — виграють швидші ядра.
Виміряйте CPU‑використання під час збірки; низький CPU% свідчить, що ви не завантажені ядрами.

2) Чи робить гібридна архітектура Intel її поганим вибором для реальної роботи?

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

3) Чи менш стабільні AMD‑CPU для віртуалізації?

На зрілих серверних платформах стабільність зазвичай про якість прошивки, виробників плат і дисципліну конфігурації.
AMD EPYC широко використовується для віртуалізації. Розглядайте BIOS/microcode як частину системи, а не як післядумку.

4) Що важливіше для щільності VM: ядра чи RAM?

Для більшості реальних VM‑флотів — RAM. CPU‑overcommit витримується; memory‑overcommit часто породжує інциденти.
Якщо на хості відбувається свопінг, ви вже не керуєте VM‑платформою — ви керуєте платформою розчарувань.

5) Чи потрібен AVX‑512 для ШІ або рендерингу?

Здебільшого ні. Це може допомогти в певних CPU‑bound inference або векторних навантаженнях, але екосистема нестабільна.
Плануйте навколо end‑to‑end пропускної здатності і бібліотек, які ви реально використовуєте, а не навколо набору інструкцій.

6) Чому мій дорогий CPU відстає в Blender?

Стійкий рендер виявляє термальні та енергетичні обмеження. Перевірте реальні стійкі частоти і температури.
Також упевніться, що пам’ять правильно налаштована (канали заповнені) і система не тротлить через VRM або обмеження шасі.

7) Для AI GPU‑сервера: як зрозуміти, чи CPU — вузьке місце?

Слідкуйте за зайнятістю GPU у часі. Якщо SM‑util низький, а CPU завантажений або iowait високий — CPU/сховище обмежують пропускну здатність.
Виправте локальність даних і препроцесинг спочатку; потім розгляньте апгрейд CPU.

8) Чи Intel завжди краще для одноядерної латентності?

Часто конкурентний, іноді провідний, але не «завжди». AMD теж може бути відмінним у продуктивності на потік, залежно від покоління і енергетичних налаштувань.
Реальний ворог — варіативність: троттлінг, фоновий contention і поведінка планувальника.

9) Чи можна «вирішити» продуктивність простим підняттям `-j` у збірках?

Ви також можете погасити кухню, відкривши більше вікон. Це змінює потоки повітря, а не фізику.
Після певної межі більше паралелізму збільшує cache misses і I/O‑контенцію; налаштовуйте -j на основі вимірів CPU‑util і iowait.

10) Яка найбезпечніша рекомендація за замовчуванням, якщо немає часу на бенчмарки?

Для хостів VM і мульти‑GPU серверів: надавайте перевагу платформам з щедрими каналами пам’яті і PCIe‑лініями (часто AMD EPYC у багатьох цінових діапазонах).
Для робочих станцій розробника зі змішаними інтерактивними задачами: віддавайте перевагу сильній продуктивності на потік і стабільному охолодженню, уникайте дивних компромісів платформи.

Наступні кроки, які ви реально зможете виконати

Ось практичний набір кроків. Зробіть це — і рішення Intel vs AMD стане очевидним, а не емоційним.

Виберіть три репрезентативні навантаження: одна збірка, один сценарій VM, один крок рендеру або AI‑пайплайн.
Запустіть наведені вище команди на поточній системі під цими навантаженнями. Класифікуйте вузьке місце (CPU, пам’ять, I/O, планувальник).
Виправте дешеві вузькі місця першими: ємність RAM, NVMe scratch, налаштування BIOS енергоспоживання/терміки, NUMA‑pinning.
Тільки потім обирайте апаратне забезпечення:
- Якщо ви справді CPU‑bound і паралельні: купуйте ядра (часто AMD за ціною, іноді Intel залежить від ціни і платформи).
- Якщо ви серіальний/латентнісний: купуйте продуктивність на потік і уникайте варіативності планувальника.
- Якщо ви пам’ять/I/O‑bound: купуйте канали, ємність і лінії; бренд CPU другорядний.
Стандартизуйте прошивку і політику ОС так само, як стандартизуєте конфіги. Регресії продуктивності люблять «ручно налаштовані» сніжинки.

Схожі статті

Як маркетинг спотворює «покоління»: «новий» CPU, який фактично старий