Бінування: як один кристал стає п’ятьма ціновими рівнями

December 10, 2025 • February 3, 2026 • Читання: 4 хв • Views: 0

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

Ви купуєте два «ідентичні» CPU для двох «ідентичних» серверів. Та ж модель. Такий самий BIOS. Ідентичне охолодження. Один працює спокійно під навантаженням;
інший нагрівається сильніше, менше розганяється і починає видавати виправлені machine‑check помилки, ніби намагається привернути увагу.
У продукції це не дрібниця. Це звіт про інцидент, що ось‑ось станеться.

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

Бінування в одному абзаці

Бінування — це практика тестування виготовленого кремнію (CPU/GPU/SoC/DRAM/NAND) і сортування його на категорії
(«біни») залежно від того, що він надійно може робити: частота при заданій напрузі, витік/енерговитрати, теплова поведінка, включені функції
та рівні помилок. Ці біни стають різними SKU та ціновими рівнями. Той самий дизайн кристалу може постачатися як преміум‑частина, як середній
варіант з нижчими тактовими частотами або як бюджетний варіант з відключеними ядрами/блоками кешу. Мета — вихід продукції: продати якомога більше
пластини, не відвантажуючи деталі, що відмовлятимуть, тротлити або порушуватимуть енергетичні рамки.

Від пласти до п’яти рівнів: конвеєр

Бінування починається задовго до того, як ваш закупівельний список побачить номер партії. Воно починається на пластині, де в кремнії
витравлено сотні (або тисячі) копій одного дизайну. У ідеальному світі кожен кристал поводився б однаково. У світі, де ми живемо,
варіації виробництва неминучі, а дефекти — неминучі.

1) Виготовлення пластин і варіації

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

2) Сортування на пластині (probe test)

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

3) Різання, пакування і їхні сюрпризи

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

4) Фінальний тест, burn‑in (іноді) і присвоєння SKU

Фінальний тест — це момент, де писалася історія SKU. Постачальник запускає тест‑патерни, перевіряє блоки функцій, контролює запаси запобіжників
(fuses) і верифікує, що частина відповідає специфікації: цільові частоти, енергетичні цілі і функціональні вимоги. Потім їй присвоюють мітку:
преміум‑бін, середній бін, «рекламний» бін або списання.

Це версія виробничої лінії. Бізнес‑версія гранично проста: виробник хоче максимізувати дохід з пласти, тримаючи рівень відмов і гарантійні витрати під контролем.
Бінування — це спосіб пройти по цій голці.

Чому кристали не ідентичні (і чому це має значення)

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

Виробнича варіативність перетворюється на різницю в енергії, теплі й розгоні

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

Маржі торгуються між напругою, частотою і помилками

Те виконання, яке ви бачите, — це результат переговорів між фізикою і прошивкою. Постачальники встановлюють криві напруга/частота, енергетичні ліміти і алгоритми розгону
на базі характеристик. Якщо кристал маргінальний на високих частотах, його або привласнять до нижчого біна, або відправлять з консервативними лімітами.
Якщо він відмінний — його можуть продавати дорожче або позначити для вимогливих TDP/clock SKU. Іноді це той самий кремній з різною конфігурацією fuse‑ів і прошивкою.

Чому це важливо в операціях

У полі бінування проявляється як:

Різні тривалі всіядні (all‑core) частоти на «однакових» вузлах.
Термальне тротлінгування на частині хостів з тим самим дизайном охолодження.
Різні сигнатури помилок: виправлені ECC, виправлені machine check, або перетренування лінків.
Різні співвідношення «потужність → продуктивність», що псують планування ємності.

Мета постачальника — відвантажити частини, що відповідають специфікації. Ваша мета — керувати передбачуваним флотом. Ці цілі перетинаються, але не тотожні.

Патерн із п’яти рівнів: як один кристал стає п’ятьма SKU

«Один кристал стає п’ятьма ціновими рівнями» — це не універсальний закон; це повторний патерн. Точна кількість варіюється, але п’ять часто зустрічається,
оскільки добре мапується на: флагман, високий, середній, низький, salvage. Ось як це зазвичай відбувається.

Рівень 1: Флагманський бін (слайд у маркетингу)

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

Рівень 2: Високий бін (все ще відмінно, але без заголовків)

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

Рівень 3: Мейнстрім‑бін (де живе обсяг)

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

Рівень 4: Низький бін (понижені частоти, налаштований під меншу напругу або з вимкненими функціями)

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

Рівень 5: Salvage‑бін («ще придатна» купа)

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

Ось чому «той самий кристал» не означає «той самий чіп». Дизайн кристалу — це один креслення; відвантажений продукт — це креслення плюс результати тестів плюс конфігурація fuse‑ів плюс політика прошивки.

Жарт №1: Якщо ви коли‑небудь почуватиметеся непотрібним, згадайте, що хтось одного разу верифікував перемикач «режим для ігор», який просто змінював колір RGB і криву вентилятора.

Що вимірюють під час бінування

Тести відрізняються залежно від постачальника й продукту, але вимірювані виміри послідовні. Якщо вам коли‑небудь було цікаво, чому ваш «TDP» не відповідає вимірюваній
потужності зі стіни або чому розгін непередбачуваний, то це тому, що одночасно жонглюють кількома обмеженнями.

Функціональна коректність

По‑перше: чи працює він? Постачальники запускають логічні тести, scan‑ланцюги та вбудовані самотести. Якщо блок відмовляє — його або списують, або відключають
(якщо продукт підтримує salvage). В GPU відключення кількох обчислювальних блоків — класичний шлях salvaging. У CPU часто це ядра або сегменти кешу, залежно від архітектури.

Частота при напрузі (V/F криві)

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

Витік і потужність

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

Теплова поведінка і чутливість до гарячих точок

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

Запаси інтерфейсу пам’яті

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

Якість інтерконектів і I/O ліній

PCIe і високошвидкісні лінки мають запаси цілісності сигналу. Постачальники можуть сертифікувати певні швидкості лінків на підставі виміряних eye‑діаграм або рівнів помилок.
Деякі частини бінуються під нижчі швидкості лінків або з меншою кількістю валідованих ліній.

Поведінка помилок під стресом

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

Цікаві факти та історичний контекст

Управління виходом продукції випереджає сучасні CPU. Ранні виробники швидко зрозуміли, що продавати лише ідеальні кристали економічно неможливо.
Градування швидкості стало помітним для споживачів у 1990‑х. Ідея, що один і той самий дизайн може постачатися на різних тактових частотах, стала масовою з PC‑CPU.
«Харвестинг» функціональних блоків — старий трюк. Чіпи пам’яті й CPU давно використовують резервування чи запобіжники для спасіння частково дефектного кремнію.
Лазерні запобіжники і eFuses спростили сегментацію. Сучасні чіпи можуть постійно конфігуруватися після виготовлення, що дає різновиди SKU з одного набору масок.
Кристали на краю пластини часто поводяться інакше. Варіації по пласти можуть створювати просторові закономірності; дані тестів регулярно мапують для виявлення системних проблем.
Пакування може змінити бін. Кристал, що проходив probe на пластині, може провалитися на фінальному тесті після пакування через напруження, теплові або СІ‑зміни.
DRAM і NAND теж сильно бінуються. Вендори пам’яті бінують за швидкістю, затримками і рівнями помилок; SSD‑вендори бінують NAND за витривалістю і продуктивністю.
Серверні SKU часто віддають перевагу енергоефективності над піковими тактовими частотами. Дата‑центри платять за ватти і охолодження; «повільніший» бін може бути кращим для експлуатації.
Turbo/boost — по суті динамічне бінування під час роботи. Сучасні CPU постійно вирішують, наскільки близько до межі можна працювати з урахуванням температури, енергії і навантаження.

Три корпоративні міні‑історії з практики

Міні‑історія 1: Інцидент через неправильне припущення (SKU = поведінка)

Компанія розгорнула нову партію обчислювальних вузлів для сервісу з критичною латентністю. Закупівлі зробили «правильну» річ: той самий постачальник,
той самий номер моделі, той самий stepping (наскільки могли з’ясувати), ті самі налаштування BIOS, та сама розкладка стелажів. Сервіс все одно отримав
дивне хвостове латентне погіршення, яке з’являлося лише під регіональними піками трафіку.

Команда on‑call шукала звичні підозри: паузи GC, «шумні» сусіди, регресії планувальника ядра. Нічого не показало. Метрики показували, що підмножина хостів
працює на кілька градусів гарячіше і підтримує трохи нижчу all‑core частоту під піковим навантаженням. Не достатньо, щоб викликати тривоги. Достатньо, щоб розтягнути p99.

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

Виправлення не було екзотичним. Вони додали етап burn‑in і характеристику для нових вузлів, записуючи підтримувану частоту під стандартизованим навантаженням,
разом з потужністю і температурою. Вузли, що потрапили в кластер «гарячі/повільні», були призначені для пакетних робіт, а не для латентно‑чутливих пулів.
Той самий SKU. Різна доля. Продукція заспокоїлася.

Міні‑історія 2: Оптимізація, що відкотилася (енерготюнінг зустрічає «силу кремнію»)

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

У продакшені зміна поводилася як чемний катастрофічний випадок. Частина вузлів почала показувати виправлені machine‑check помилки під навантаженням.
Потім менша частина перейшла до невиправлених помилок і спонтанних перезавантажень — рідко, але завжди в найгірші години. Вплив на SLA був невеликий, але повторюваний,
що виснажує команди місяцями.

Механізм відкату: undervolt зменшив шумову маржу на маргінальному кремнії. Лабораторні одиниці були кращими бінами; у флоті була дискретна розподілка, яка включала слабші кристали.
Помилки «виправлялися», поки не перестали, а телеметрію спочатку ігнорували, бо «виправлене» звучало як «нормально».

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

Міні‑історія 3: Нудна, але правильна практика, що врятувала день (гігієна флоту перемагає)

Сервіс, що інтенсивно працює з диском, мав змішані навантаження: компактацію, шифрування та стрімінг високої пропускної здатності. Вони стандартизувалися на одному SKU
для простоти. Але вони систематично робили одну нудну річ: логували модель CPU, версію мікрокоду, налаштування BIOS щодо енергії та телеметрію machine‑check у систему інвентаризації,
і ніколи не пропускали burn‑in тести для нових стелажів.

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

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

Ніхто не отримав підвищення за «ми помітили зсув розподілу і підлаштували політики». Але ніхто не пройшов через пейджинг о 3 ранку також. Ось правильна нудна практика.

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

Ви не можете «побачити біни» напряму без даних тестування від постачальника, але можете спостерігати наслідки: поведінку частоти, енергетичні ліміти,
тепловий резерв і рівні помилок. Нижче — практичні завдання, які можна виконати на Linux‑серверах для характеристики і управління варіативністю, пов’язаною з бінуванням.
Кожне включає: команду, приклад виводу, що це означає і яке рішення прийняти.

Завдання 1: Визначити модель CPU, stepping і мікрокод

cr0x@server:~$ lscpu | egrep 'Model name|Stepping|CPU\(s\)|Thread|Socket|Vendor|MHz'
Vendor ID:                           GenuineIntel
Model name:                          Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz
CPU(s):                              64
Thread(s) per core:                  2
Socket(s):                           2
Stepping:                            6
CPU MHz:                             2000.000

Значення виводу: Підтверджує, що ви купили, і чи є у флоті змішані steppings.
Рішення: Якщо ви бачите змішані steppings або несподівані моделі під тим же замовленням, розділіть пули і зробіть базову характеристику окремо.

Завдання 2: Перевірити версію мікрокоду і чи застосовані оновлення

cr0x@server:~$ grep -m1 microcode /proc/cpuinfo
microcode	: 0x2d

Значення виводу: Мікрокод впливає на поведінку розгону і маржі стабільності. Різні версії можуть змінювати продуктивність і рівні помилок.
Рішення: Стандартизувати мікрокод по флоту перед порівнянням «поведінки бінів». Інакше ви порівнюєте яблука з прошивкою.

Завдання 3: Подивитися політику governor для CPU

cr0x@server:~$ cpupower frequency-info | sed -n '1,18p'
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 800 MHz - 3500 MHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 800 MHz and 3500 MHz.
                  The governor "powersave" may decide which speed to use
  current CPU frequency: 1200 MHz (asserted by call to hardware)

Значення виводу: Показує, чи система дозволена підвищувати частоту або зафіксована політикою.
Рішення: Для характеристик використовуйте послідовний governor (часто performance), щоб зменшити шум при порівнянні вузлів.

Завдання 4: Зафіксувати governor на performance для контрольного тесту

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3

Значення виводу: Governor змінено. Машина буде віддавати перевагу вищим частотам.
Рішення: Якщо ваш флот покладається на енергозберігаючі governor‑и, не міняйте виробничі налаштування глобально; використовуйте це лише під час тестування або в виділених пулах.

Завдання 5: Спостерігати пер‑ядрові частоти під навантаженням (швидка перевірка реальності)

cr0x@server:~$ sudo turbostat --quiet --show CPU,Avg_MHz,Busy%,Bzy_MHz,PkgWatt,PkgTmp --interval 2 --num_iterations 3
CPU   Avg_MHz  Busy%  Bzy_MHz  PkgWatt  PkgTmp
-     2860     92.3   3099     182.40   78
-     2795     93.1   3003     179.10   80
-     2712     94.0   2886     176.85   82

Значення виводу: Bzy_MHz падає по мірі підвищення температури; потужність залишається близько до ліміту.
Рішення: Якщо підтримуваний Bzy_MHz суттєво відрізняється між «однаковими» вузлами, розглядайте їх як різні бін‑кохорти при плануванні.

Завдання 6: Перевірити термальне тротлінгування і сенсори температури

cr0x@server:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +82.0°C  (high = +90.0°C, crit = +100.0°C)
Core 0:        +79.0°C  (high = +90.0°C, crit = +100.0°C)
Core 1:        +80.0°C  (high = +90.0°C, crit = +100.0°C)

Значення виводу: Ви близькі до «high» порогів; невеликі відмінності бінів можуть переключити вас у тротлінг.
Рішення: Якщо когорти систематично працюють гарячіше, налаштуйте криві вентиляторів, розміщення в стелажі або розподіл навантаження перш ніж звинувачувати додаток.

Завдання 7: Переглянути логи ядра на предмет machine‑check і виправлених апаратних помилок

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'mce|machine check|edac|hardware error' | tail -n 8
Jan 12 02:14:03 server kernel: mce: [Hardware Error]: CPU 17: Machine Check: 0 Bank 7: b200000000070005
Jan 12 02:14:03 server kernel: mce: [Hardware Error]: TSC 0 ADDR fef1a140 MISC d012000100000000
Jan 12 02:14:03 server kernel: mce: [Hardware Error]: PROCESSOR 0:50656 TIME 1705025643 SOCKET 0 APIC 34 microcode 2d

Значення виводу: Є апаратні помилки. Навіть якщо «виправлені», вони — провісник маргінальних умов напруга/частота/тепло.
Рішення: Карантинізуйте вузли з повторюваними виправленими помилками; перевірте охолодження, мікрокод і будь‑які undervolt/енергетичні налаштування.

Завдання 8: Перевірити лічильники EDAC (ECC пам’ять)

cr0x@server:~$ sudo edac-util -v
mc0: 2 Uncorrected Errors with no DIMM info
mc0: 37 Corrected Errors with no DIMM info

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

Завдання 9: Підтвердити фактичну швидкість пам’яті (і чи її понизили)

cr0x@server:~$ sudo dmidecode -t memory | egrep 'Speed:|Configured Memory Speed:' | head -n 10
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s

Значення виводу: DIMM‑и підтримують 3200, але платформа їх запускає на 2933 (може бути обмеження IMC CPU, правила population або BIOS).
Рішення: Якщо нова партія тихо працює на нижчій швидкості пам’яті, перевірте обмеження CPU stepping/bin та правила population BIOS; відкоригуйте очікування і плани ємності.

Завдання 10: Виміряти пакетні енергетичні ліміти (поширена причина «чому не розганяється»)

cr0x@server:~$ sudo rdmsr -a 0x610 | head -n 4
00000000f8c800f8
00000000f8c800f8
00000000f8c800f8
00000000f8c800f8

Значення виводу: Сира MSR‑цінність, що кодує енергетичні ліміти (PL1/PL2) на деяких Intel‑платформах.
Рішення: Якщо різні когорти показують різні налаштування PL, стандартизуйте політику BIOS або розділіть пули; не порівнюйте продуктивність, поки ліміти не збігаються.

Завдання 11: Підтвердити обмеження частоти CPU, видимі ОС

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
3500000

Значення виводу: Максимальна частота в кГц. Якщо вона нижча за очікувану, вас можуть обмежувати BIOS, політика енергії або тепловий режим.
Рішення: Якщо це відрізняється між вузлами одного SKU, розглядайте це як інцидент конфігураційного дрейфу.

Завдання 12: Стрес‑тест для стійкої поведінки (не лише миттєвий turbo)

cr0x@server:~$ stress-ng --cpu 0 --cpu-method matrixprod --timeout 60s --metrics-brief
stress-ng: info:  [22118] setting to a 60 second run per stressor
stress-ng: metrc: [22118] stressor       bogo ops real time  usr time  sys time   bogo ops/s
stress-ng: metrc: [22118] cpu               6823    60.02    59.81     0.11       113.7

Значення виводу: Швидкий проксі‑черезпродуктивності. Використовуйте разом з turbostat, щоб бачити енергетичне/теплове тротлінгування.
Рішення: Якщо пропуск суттєво розходиться між вузлами з однаковими налаштуваннями, створюйте карту когорт і плануйте відповідно.

Завдання 13: Перевірити стан PCIe‑лінків (маржа I/O може виглядати як «повільне сховище»)

cr0x@server:~$ sudo lspci -vv -s 3b:00.0 | egrep 'LnkCap:|LnkSta:'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 8GT/s (downgraded), Width x16 (ok)

Значення виводу: Лінк натренувався на 8GT/s. Це може бути цілісність сигналу, BIOS або маргінальна лінія.
Рішення: Якщо когорти систематично downtrain‑яться, не «оптимізуйте» софт. Виправте кабелі, слот, прошивку або RMA‑йте хост, якщо проблема постійна.

Завдання 14: Підтвердити топологію NUMA і локальність пам’яті (бінування зустрічається з топологією)

cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
node 0 size: 257642 MB
node 0 free: 192110 MB
node 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 1 size: 257919 MB
node 1 free: 198844 MB

Значення виводу: Два NUMA‑вузли. Неправильне розміщення може імітувати «погану бін‑поведінку».
Рішення: Якщо лише деякі хости виглядають повільними, перевірте NUMA‑pinning і локальність пам’яті перед тим, як звинувачувати кремній.

Завдання 15: Перевірити CPU‑тротлінг cgroup (не звинувачуйте чіп за свої обмеження)

cr0x@server:~$ cat /sys/fs/cgroup/cpu.stat
usage_usec 912345678
user_usec  900000000
system_usec 12345678
nr_periods  56012
nr_throttled 8421
throttled_usec 98765432

Значення виводу: Навантаження обмежується квотами cgroup.
Рішення: Якщо ви бачите тротлінг, спочатку виправте обмеження ресурсів або планування; інакше ви помилково приписуватимете варіативність бінуванню.

Завдання 16: Виявити на рівні флоту «бін‑кластери» через просте порівняння

cr0x@server:~$ awk -F: '/model name/ {m=$2} /microcode/ {u=$2} END {gsub(/^[ \t]+/,"",m); gsub(/^[ \t]+/,"",u); print m " | microcode " u}' /proc/cpuinfo
Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz | microcode 0x2d

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

Жарт №2: Ваша модель ємності «детермінована», поки ви не зустрінете той єдиний сервер, що розганяється так, ніби платить оренду по ват‑у.

Короткий план діагностики

Коли підмножина вузлів повільніша/гарячіша/нестабільніша і ви підозрюєте ефекти «бінування», потрібно швидко знайти реальний вузький горлечко. Ось мій план.

Перш за все: виключіть дрейф конфігурацій і штучні обмеження

Governor/політика: підтвердіть, що cpupower frequency-info узгоджений.
Енергетичні ліміти: перевірте налаштування BIOS (і, якщо є, телеметрію лімітів потужності).
Теплова політика: переконайтеся, що криві вентиляторів і повітряний потік однакові; перевірте пил і заблоковані заглушки.
cgroup‑тротлінг: перевірте, що ви не обмежуєте «повільні» вузли по‑іншому.

По‑друге: перевірте тепло і енергію під стійким навантаженням

Запустіть контрольоване навантаження на 5–10 хвилин (наприклад, stress-ng).
Захопіть turbostat для Bzy_MHz, PkgWatt та PkgTmp.
Порівняйте когорти. Якщо потужність досягає стелі, а частота падає — обмеження енергії. Якщо температура досягає «high» — термальне обмеження.

По‑третє: шукайте виправлені помилки та downtraining I/O

Виправлені MCE/EDAC: повторювані виправлені помилки — не «нормально», це «передвідмова».
Швидкість PCIe: downtraining може вдвічі зменшити пропуск I/O і виглядати як регресія сховища/мережі.
Швидкість пам’яті: підтвердіть, що налаштована швидкість пам’яті не впала у новій партії.

По‑четверте: прийміть рішення швидко

Якщо це конфігурація: виправте дрейф і пере‑базуйте.
Якщо це тепло: підправте повітряний потік, розміщення або понижуйте характеристики тієї когорти.
Якщо це маргінальна стабільність: виведіть з чутливих пулів і залучіть підтримку постачальника/RMA.
Якщо це нормальна варіативність бінів: плануйте розумно; перестаньте прикидатися, що флот однорідний.

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

1) Симптом: «Той самий SKU, але деякі вузли на 5–10% повільніші під навантаженням»

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

2) Симптом: «Після undervolting з’явилися виправлені помилки, потім випадкові перезавантаження»

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

3) Симптом: «Нова партія працює гарячіше, вентилятори гучніші, а продуктивність така сама або гірша»

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

4) Симптом: «Пропуск сховища впав; CPU виглядає простим»

Корінь проблеми: PCIe‑лінк downtrain‑ився (маржа сигналу), або прошивка змінила політику лінка.
Виправлення: перевірте за lspci -vv; пере‑вставте карти, перевірте riser‑и/кабелі, оновіть прошивку і ізолюйте когорту; RMA‑йте хост, якщо проблема персистентна.

5) Симптом: «Бенчмарки вистрілюють чудово, а продукція на стійкому навантаженні — погано»

Корінь проблеми: поведінка turbo маскує стійке тротлінгування через енергетичні/теплові ліміти.
Виправлення: тестуйте стійко (хвилини, а не секунди), логуючи turbostat і температури; налаштовуйте під стійку поведінку, а не під маркетингові цифри розгону.

6) Симптом: «Лише підмножина вузлів показує ECC виправлені помилки»

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

7) Симптом: «Графіки продуктивності нагадують гребінку: деякі вузли постійно на верху, деякі — внизу»

Корінь проблеми: у вас кілька ефективних бінів в одному пулі.
Виправлення: припиніть балансування навантаження всліпу; додайте оцінку вузлів на підставі стійкої perf/watt і телеметрії помилок; розділіть пули за когорти.

Контрольні списки

Покроковий план: перетворення бінування з хаосу у факти інвентаря

Збирайте ідентифікацію апаратури послідовно. Модель, stepping, мікрокод, версія BIOS, конфігурація пам’яті, топологія NIC/PCIe.
Визначте стандартний профіль burn‑in. Стійке CPU‑навантаження, пам’ятєве навантаження і I/O‑саніті‑чек. Тримайте його нудним і відтворюваним.
Фіксуйте три метрики на вузол: стійка all‑core частота, пакетна потужність і пікова температура під час вікна burn‑in.
Записуйте кількість виправлених помилок. MCE і EDAC. Відстежуйте дельти, а не лише абсолютні значення.
Кластеризуйте вузли у когорти. Не за відчуттями — за виміряною поведінкою.
Призначайте навантаження за характеристиками когорти. Латентно‑чутливі — на холодні/ефективні когорти; пакетні — на гарячі/витікені когорти.
Встановіть захисні пороги. Будь‑який вузол, що перевищує поріг виправлених помилок, автоматично виходить з пулу.
Стандартизуйтe прошивку. Налаштування BIOS і мікрокод мають бути консистентними перед порівняннями когорт у часі.
Комунікуйте реалії закупівель. «Той самий SKU» — не гарантія ідентичної стійкої продуктивності. Занотуйте це в плануванні ємності.
Перевіряйте щоквартально. Розподіли кремнію змінюються між виробничими лотами; поведінка вашого флоту буде дрейфувати без постійного вимірювання.

Чого робити / чого уникати (версія для операцій)

Робіть: вимірюйте стійку поведінку під вашою фактичною політикою енергії. Уникайте: довіряти 30‑секундному бенчмарку.
Робіть: трактуйте виправлені апаратні помилки як сигнал. Уникайте: чекати невиправлених помилок, щоби «підтвердити» проблему.
Робіть: розділяйте когорти, коли потрібно. Уникайте: примушувати однорідну модель планування на гетерогенному кремнії.
Робіть: тримайте консервативні налаштування для бінів з багато salvage. Уникайте: застосовувати агресивні undervolt налаштування по всьому флоту.

Питання й відповіді (FAQ)

1) Чи бінування — це просто спосіб більше заряджати за той самий чіп?

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

2) Чи вищі біни завжди надійніші?

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

3) Чому два CPU з тим самим номером моделі по‑різному розганяються?

Бо розгін обмежується енергією, температурою і характеристиками кремнію, як‑от витік. Навіть в межах одного SKU частини можуть мати різні V/F криві.
Додайте відмінності BIOS, мікрокоду і варіативність охолодження — і «той самий» CPU стає розподілом.

4) Чи salvage‑кремній — це «поганий» кремній?

Не обов’язково. Salvage означає «деякі блоки були відключені». Решта блоків можуть бути цілком надійними за правильної валідації.
Але варто очікувати менший запас і бути консервативним щодо undervolt, розгону пам’яті і щільних теплових контуру.

5) Чи можу я як кінцевий користувач визначити свій точний бін?

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

6) Чи «кремнієва лотерея» реальна або це просто інтернет‑фольклор?

Відмінності реальні. Фольклор — у вірі, що можна надійно «виграти» за допомогою споживацьких тактик. У продакшені ви не граєтеся; ви вимірюєте,
групуєте і плануєте. Ставити SLO на карту лотереї — дивне кар’єрне рішення.

7) Як бінування пов’язане з TDP?

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

8) Чи впливає мікрокод на бінування?

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

9) Чому постачальник відвантажує той самий кристал з відключеними функціями замість виготовлення меншого кристалу?

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

10) Яка найкраща оперативна відповідь на варіативність бінування?

Ставтеся до апаратури так само, як до мереж: вимірюйте, моделюйте розподіли і будуйте захисні механізми. Використовуйте burn‑in бази, когорто‑орієнтоване планування і пороги телеметрії помилок.
Не припускайте однорідності лише тому, що закупівля зробила «правильно».

Висновок: наступні кроки, які реально допомагають

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

Практичні наступні кроки:

Почніть збирати stepping CPU, мікрокод і налаштування BIOS в інвентарі.
Додайте короткий відтворюваний burn‑in, що фіксує стійку частоту, потужність і температуру.
Відстежуйте виправлені апаратні помилки і автоматично карантинізуйте повторювачів.
Кластеризуйте вузли в когорти і плануйте навантаження відповідно.
Стандартизуйте прошивку перед тим, як оголошувати «проблему бінування».

Парафраз ідеї від Werner Vogels: «Усе ламається весь час — проектуйте і експлуатуйте, ніби це нормально».