Операційні вимоги для «Оптимальний CPU для валідатора Solana» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.
Процесор є головним вузлом, що визначає, чи зможе валідатор Solana обробити свій лідерський слот у відведений час. Вибір CPU безпосередньо впливає на skip rate — частку пропущених слотів, яка є ключовою метрикою здоров'я вузла. Цей довідник дає конкретні критерії вибору процесора для production-середовища без зайвих узагальнень.
Роль процесора у валідації
Solana використовує модель виконання, де банківський етап (banking stage) обробки транзакцій є переважно однопотоковим. Це архітектурне рішення runtime, написаного на Rust, і воно не змінюється від версії до версії. Саме в цьому потоці відбувається виконання транзакцій, перевірка підписів, оновлення стану акаунтів та генерація Proof of History (PoH).
Інші завдання працюють паралельно на окремих ядрах:
- Gossip-протокол — обмін інформацією з сусідніми вузлами
- Turbine — розповсюдження блоків
- Accounts Background Service — фонове стиснення та обслуговування бази акаунтів
- RPC-сервер (якщо запущено на тому ж вузлі)
- Підтримка persistent accounts_db та shred-зберігання
Відповідно, процесор для валідатора має забезпечувати два things: максимальну однопотокову продуктивність для банківського етапу та достатню кількість ядер для паралельних завдань без конкуренції за ресурси.
Клієнт: agave-validator (githash перевіряйте у своєму розгортання). Кластер: mainnet-beta. ОС: Ubuntu 24.04 LTS. Дата перевірки актуальності архітектурних припущень: верифікуйте у репозиторії agave перед закупівлею.
Ключові характеристики CPU
Кількість ядер та потоків
Мінімально працездатний вузол потребує не менше 12 фізичних ядер. Рекомендований діапазон для production — від 16 до 32 фізичних ядер. Звертайте увагу саме на фізичні ядра, а не на потоки (hyperthreading/SMT). У контексті Solana SMT дає другий потік з приблизно 30–40% продуктивності першого, що корисно для фонових завдань, але не компенсує брак фізичних ядер.
Розподіл приблизно такий: 1 ядро — банківський етап (критичний потік), 1 ядро — PoH, 2–4 ядра — Turbine та Gossip, 2–4 ядра — Accounts Background Service, 4–8 ядер — RPC (якщо на тому ж вузлі), решта — операційна система та мережевий стек.
Частота базова та турбо
Базова частота має бути не нижчою за 2.8 GHz. Турбо-частота на одному активному ядрі — від 3.5 GHz і вище. Саме турбо-частота визначає продуктивність банківського етапу, оскільки цей потік може використовувати максимальний турбо-буст, поки інші ядра не навантажені критично.
Важливо: у серверних платформах турбо-частота залежить від кількості активних ядер та теплового бюджету. Перевіряйте специфікацію саме для режиму «1 core active», а не рекламну максимальну частоту без контексту.
Архітектура: Zen 3/4, Ice Lake та інші
Архітектура визначає IPC (інструкцій за такт) — другий множник продуктивності після частоти. Для Solana-валідатора на сьогодні релевантні:
- AMD Zen 3 (Milan) — добра продуктивність на ядро, перевірена в production на mainnet
- AMD Zen 4 (Genoa) — покращений IPC, підтримка AVX-512 (використовується в криптографічних операціях)
- Intel Ice Lake-SP — стабільна серверна платформа, достатній IPC
- Intel Sapphire Rapids — покращений IPC порівняно з Ice Lake, але перевірте тепловий бюджет у вашому дата-центрі
Архітектури старші за Zen 2 (Rome) або Cascade Lake не рекомендуються для нових deploymentів через нижчий IPC, що безпосередньо дає вищий skip rate при рівній частоті.
Кеш L2/L3
Об'єм L3-кешу має значення для банківського етапу, оскільки робочий набір даних включає стан активних акаунтів, які часто звертаються послідовно. Рекомендовано від 32 MB L3 на кожні 8 ядер. Процесори з великим загальним L3 (256 MB і більше, як у топових EPYC) дають перевагу при високому навантаженні на accounts-db.
L2-кеш у сучасних серверних CPU достатній (по 32 MB на CCD у Zen 4, по 1.25–2 MB на ядро у Intel), і його об'єм зазвичай не є вирішальним фактором при виборі між моделями одного покоління.
Рекомендовані моделі процесорів
Нижче наведено моделі, які підтверджено працюють у production на mainnet-beta. Конкретну модель обирайте з урахуванням доступності у вашому хостинг-провайдері та теплового бюджету серверної платформи.
| Модель | Архітектура | Ядра / Потоки | Базова частота | Турбо (1 ядро) | L3-кеш |
|---|---|---|---|---|---|
| AMD EPYC 9654 | Zen 4 (Genoa) | 96 / 192 | 2.4 GHz | 3.7 GHz | 384 MB |
| AMD EPYC 9554 | Zen 4 (Genoa) | 64 / 128 | 2.5 GHz | 3.8 GHz | 256 MB |
| AMD EPYC 7763 | Zen 3 (Milan) | 64 / 128 | 2.45 GHz | 3.5 GHz | 256 MB |
| AMD EPYC 7543 | Zen 3 (Milan) | 32 / 64 | 2.8 GHz | 3.7 GHz | 128 MB |
| Intel Xeon 8480+ | Sapphire Rapids | 56 / 112 | 2.0 GHz | 3.8 GHz | 105 MB |
| Intel Xeon 8380 | Ice Lake-SP | 40 / 80 | 2.3 GHz | 3.4 GHz | 60 MB |
Частоти вказані за офіційною специфікацією виробника. Реальна турбо-частота залежить від материнської плати, охолодження та політик дата-центра. Перевіряйте фактичну частоту у production командою lscpu або через turbostat.
Для вузла без RPC-сервісу достатньо 16–24 ядер (наприклад, EPYC 7543). Якщо на тому ж сервері працює RPC-ендпоінт з високим трафіком — орієнтуйтесь на 32+ ядер.
Бенчмарки: як CPU впливає на skip rate
Skip rate — це відсоток лідерських слотів, які ваш вузол не зміг обробити вчасно. Пропущений слот означає втрачену комісію та негативний сигнал для делегаторів. Зв'язок між CPU і skip rate прямий, але не лінійний.
Механіка проста: кожен лідерський слот триває приблизно 400 ms. За цей час банківський етап має виконати всі транзакції з пула, згенерувати PoH-записи та сформувати блок. Якщо CPU не встигає — слот пропускається.
Щоб виміряти вплив саме CPU (а не диска чи мережі), виконайте ізольований тест на вже працюючому вузлі:
- Переконайтеся, що NVMe-накопичувач не є вузьким місцем (перевірте
iostat -x 1— %util має бути значно нижчим за 100% під час лідерського слота). - Увімкніть моніторинг частоти банківського потоку:
watch -n 0.5 "ps -T -p $(pgrep agave-validator) -o pid,tid,pcpu,comm | head -20" - Спостерігайте за skip rate у журналі:
journalctl -u agave-validator -f | grep -i "skip" - Зафіксуйте skip rate за кілька епох (мінімум 3–4 епохи для статистичної значущості).
Якщо під час ваших лідерських слотів частота CPU не досягає турбо-режиму, а skip rate ненульовий — проблема, ймовірно, не в процесорі. Якщо частота стабільно на турбо, але skip rate все одно присутній — перевірте, чи не конкурують за ресурси інші процеси на цьому сервері.
Не порівнюйте свій skip rate із чужими публічними даними без контексту: географічне розташування, мережева затримка до сусідів та конфігурація інших компонентів роблять пряме порівняння некоректним.
Помилки вибору: чого уникати
Десктопні процесори замість серверних. AMD Ryzen або Intel Core можуть показати вищий однопотоковий бенчмарк за нижчу ціну, але вони не мають ECC-пам'яті, не підтримують hot-plug RAM, мають обмежену кількість PCIe-ліній та не розраховані на 24/7 навантаження у дата-центрі. Корупція пам'яті без ECC на accounts-db може призвести до непомітного пошкодження стану.
Орієнтація лише на кількість ядер. 128 ядер з низькою частотою та старою архітектурою дають гірший результат для Solana, ніж 24 ядра з високою турбо-частотою та сучасним IPC. Банківський етап використовує одне ядро — і саме воно має бути найшвидшим.
Ігнорування теплового бюджету. Процесор із високою специфікацією, встановлений у корпус із недостатнім охолодженням, не досягне заявленої турбо-частоти. Перевірте TDP процесора та можливості охолодження вашої серверної платформи до закупівлі.
Змішування різних поколінь у одному вузлі. Деякі платформи дозволяють встановити процесори різних моделей у різні сокети. Це створює асиметрію NUMA, яка ускладнює планування потоків ОС і може призвести до непередбачуваної продуктивності банківського етапу.
Нехтування AVX-512. Solana-клієнт використовує AVX-512 інструкції для певних криптографічних операцій (зокрема, перевірки підписів Ed25519). Процесори без AVX-512 (більшість десктопних AMD, деякі старі серверні Intel) виконують ці операції повільніше, що додатково навантажує банківський потік.
Наступний логічний крок після визначення процесора — вибір NVMe-накопичувача, оскільки навіть найшвидший CPU не компенсує повільний диск при завантаженні snapshot або обробці великих банків. Деталі — у розділі NVMe-накопичувачі для валідатора: вибір та налаштування.