Моделі та платформи ШІ
E2B випробовує NVIDIA Vera для ферм ізольованих середовищ для агентів високої щільності

9 листопада 2026 року E2B опублікувала результати випробувань передсерійного обладнання: у чотирьох прогонах із налаштуваннями на одному двосокетному сервері NVIDIA Vera стабільно працювали від 1 400 до 1 550 навантажених ізольованих середовищ, тоді як окремі мікротести засвідчили вищу пропускну здатність процесора й пам’яті, ніж у системи AMD EPYC 9B45, обраної для порівняння.
Це оцінювання не є розгортанням у виробничому середовищі. E2B надає ізольовані мікровіртуальні машини через SDK, завдяки чому агенти можуть виконувати команди, працювати з файлами та повертатися до збереженого стану виконання. Кожне ізольоване середовище відновлюється зі знімка, завантажуючи пам’ять у міру потреби. Значна частина цієї роботи під час сеансу припадає на процесор, навіть якщо модель працює деінде, тому E2B перевіряла як окремі операції, так і великі масиви середовищ, що працюють одночасно.
Мікротести процесора й пам’яті
Випробування Vera проводилися 9–13 жовтня 2026 року на одному передсерійному двосокетному сервері з 176 фізичними ядрами та 1 479 ГіБ оперативної пам’яті. Контрольні вимірювання для AMD виконали в серпні 2026 року. У тесті обчислень на одному потоці безпосередньо на сервері E2B повідомляє про 7 759 подій за секунду для Vera та 5 131 — для AMD EPYC 9B45, тобто пропускна здатність у 1,51 раза вища за контрольний показник; наведено медіану щонайменше трьох прогонів. Для обчислювальних тестів використовувалося ядро Vera зі сторінками 64K.
Під час тесту пам’яті заповнювали область обсягом 2 ГіБ за допомогою ядер 4K і великих сторінок розміром 2 МіБ — такий самий механізм роботи з великими сторінками використовують ізольовані середовища E2B. За даними E2B, для Vera показник становить 62,8 ГБ/с, а для AMD — 17,4 ГБ/с, тобто пропускна здатність вища у 3,61 раза. Вимірюється заповнення пам’яті, а не повний запуск ізольованого середовища. Це важлива операція для середовища виконання, яке неодноразово відновлює середовища зі знімків.
Це порівняння має чіткі обмеження. Діаграми охоплюють названі системи в межах конкретних мікротестів і не доводять, що агенти працюватимуть швидше на стільки ж у наскрізних сценаріях, а також не свідчать про перевагу над AMD за місткістю ферми. E2B також зазначає, що приріст продуктивності окремих інструментів і застосунків буде різним.
Місткість повного стека й налаштування сервера
Для тестування повного стека E2B використовувала E2B Embed — пакетне рішення для одного комп’ютера, що включає програмне забезпечення з відкритим кодом E2B Runtime і панель керування; стек працював безпосередньо на сервері. Embed забезпечує ізоляцію мікровіртуальних машин Firecracker і підтримку SDK для Python та JavaScript. Оцінювання охоплювало створення середовищ, виконання команд, відновлення зі знімка, місткість, а також багаторазове створення й видалення середовищ.
За даними E2B, прогріті ізольовані середовища запускалися послідовно за 50 мс, а час проходження команди туди й назад за низького навантаження становив 3,8 мс; обидва показники отримано в окремих випробуваннях Vera на фізичному сервері, а не під час вимірювання навантаження на ферму. В окремій серії тестів на багаторазове створення й видалення середовищ виконано 22 145 циклів без жодної помилки.
У змішаному тесті місткості кожне ізольоване середовище неодноразово виконувало коротке інтенсивне завдання на процесорі, записувало 10 МіБ даних на диск і робило паузу; водночас одне з кожних десяти середовищ працювало безперервно. На верхній межі діапазону місткості E2B повідомляє про затримку проходження команди туди й назад на рівні 95-го перцентиля — 255 мс. В окремому тесті, де всі середовища працювали безперервно, стабільно підтримувалася робота 550 середовищ.
У цих тестах місткості для кожного ізольованого середовища резервували 512 МіБ. Задані цілі вимагали, щоб затримка на рівні 95-го перцентиля не перевищувала у 5 разів базовий показник для прогрітого короткочасного навантаження в кожному прогоні; також було встановлено обмеження помилок у 1% на кожному кроці. Отже, результат відображає місткість за визначених цільових показників швидкодії та надійності, а не абсолютну межу навантаження.
Конфігурація сервера була суттєвим обмежувальним чинником. Стандартні налаштування забезпечували роботу 320 ізольованих середовищ; налаштування мережевих сусідів збільшило це число до 1 000, але обмеження у 1 024 пристрої залишилося чинним. Для досягнення основного результату щодо місткості знадобилося повне налаштування. E2B описує цю динаміку як порівняння конфігурацій на тому самому сервері, а не як приріст швидкодії Vera проти x86.
Обмеження оцінювання та заплановані випробування
Передсерійний статус залишає кілька невирішених питань. E2B з’ясувала, що контрольні системи x86 і далі швидше виконували деякі операції відновлення, а для вкладеної віртуалізації потрібна додаткова робота. Вартість і енергоспоживання не вимірювали, тому економічні аспекти експлуатації залишилися поза межами оцінювання.
За словами E2B, наступні кроки — кластер із кількох вузлів Vera, холодне відновлення з використанням об’єктного сховища та порівняння з x86-системою, у якому застосують той самий пакет E2B і ті самі налаштування сервера. Подальше обґрунтування ширшого розгортання залежить від цих додаткових випробувань: чи збережуться результати повного стека під час порівняння з x86-системою, налаштованою та укомплектованою аналогічним чином, і чи вдасться масштабувати результати щодо місткості одного сервера на кластер.












