AI 모델 및 플랫폼
E2B, 고밀도 에이전트 샌드박스 팜을 위한 NVIDIA Vera 테스트
Unite.AI를 Google의 선호 소스에 추가
E2B는 2026년 11월 9일 양산 전 테스트 결과를 발표했다. 결과에 따르면 이중 소켓 NVIDIA Vera 서버 한 대에서 튜닝을 거친 4회의 테스트를 통해 부하가 걸린 샌드박스 1,400~1,550개를 유지했으며, 별도로 실시한 마이크로벤치마크에서는 AMD EPYC 9B45 기준 시스템보다 높은 프로세서 및 메모리 처리량을 측정했다.
이번 평가는 실제 운영 환경에 배포한 테스트가 아니다. E2B는 SDK를 통해 격리된 마이크로VM을 제공하므로 에이전트가 명령을 실행하고 파일을 다루며, 보존된 실행 상태로 돌아갈 수 있다. 각 샌드박스는 필요에 따라 메모리를 불러오는 스냅샷에서 재개된다. 모델이 다른 곳에서 실행되더라도 세션 작업의 상당 부분은 CPU에서 이뤄지므로, E2B는 개별 작업과 대규모 동시 실행 환경을 모두 테스트했다.
프로세서 및 메모리 마이크로벤치마크
Vera 테스트는 2026년 10월 9~13일, 물리 코어 176개와 RAM 1,479GiB를 갖춘 양산 전 이중 소켓 서버 한 대에서 진행됐다. AMD 기준 측정은 2026년 8월에 이뤄졌다. 운영체제가 구동되는 호스트에서 단일 스레드 연산 테스트를 실시한 결과, E2B는 Vera에서 초당 7,759건, AMD EPYC 9B45에서 초당 5,131건을 측정했다고 밝혔다. 이는 기준 시스템 처리량의 1.51배에 해당하며, 최소 3회 실행한 결과의 중앙값을 사용했다. 연산 테스트에는 Vera의 64K 페이지 커널을 사용했다.
메모리 테스트에서는 4K 커널과 2MiB 대형 페이지를 사용해 2GiB 영역을 메모리에 채웠다. 이때 사용한 대형 페이지 기반 메모리는 E2B 샌드박스에도 적용된다. E2B는 Vera에서 62.8GB/s, AMD에서 17.4GB/s를 측정했다고 밝혔으며, 이는 처리량이 3.61배라는 뜻이다. 이 측정은 전체 샌드박스 시작이 아니라 메모리를 채우는 작업을 대상으로 한다. 스냅샷 기반 환경을 반복해서 복원하는 런타임에서 이는 중요한 작업이다.
이 비교에는 명확한 한계가 있다. 차트는 특정 마이크로벤치마크에서 이름이 명시된 시스템을 다룰 뿐, 에이전트의 종단 간 속도가 같은 비율로 향상되거나 AMD보다 팜 용량이 커진다는 점을 입증하지 않는다. E2B 역시 개별 도구와 애플리케이션의 성능 향상 폭은 달라질 수 있다고 밝혔다.
전체 스택 용량 및 호스트 튜닝
전체 스택 테스트에서 E2B는 E2B Embed를 사용했다. 이는 오픈 소스 E2B Runtime과 대시보드를 단일 머신용으로 패키징한 것으로, 스택은 호스트에서 직접 실행됐다. Embed는 Firecracker 마이크로VM 격리와 Python 및 JavaScript SDK를 지원한다. 평가 항목에는 생성, 명령 실행, 스냅샷 복원, 용량, 반복적인 생성과 종료가 포함됐다.
E2B는 부하가 낮을 때 웜 상태에서 순차적으로 시작한 샌드박스의 시작 시간이 50ms, 명령 왕복 시간이 3.8ms였다고 밝혔다. 두 수치는 모두 팜 전체 부하 측정이 아니라 Vera 베어메탈 테스트에서 각각 측정한 값이다. 별도의 반복 생성·종료 테스트에서는 오류 없이 생성 및 삭제를 22,145회 완료했다.
혼합 용량 부하 테스트에서 각 샌드박스는 CPU 부하 작업을 수행하고 10MiB의 디스크 쓰기를 한 뒤 일시 정지하는 과정을 반복했으며, 10개 중 1개는 계속 실행됐다. 용량 범위의 상단에서 E2B는 명령 왕복 시간의 95백분위수가 255ms였다고 밝혔다.
각 용량 테스트에서는 샌드박스당 512MiB를 예약했다. 테스트 목표에 따라 95백분위수 지연 시간은 각 실행의 웜 상태 버스트 기준치의 5배 이내로 유지해야 했으며, 각 단계의 오류율은 1%로 제한됐다. 따라서 이 결과는 절대적인 최대 부하 한도가 아니라, 명시된 응답성 및 안정성 목표 아래에서의 용량을 보여준다.
호스트 구성은 주요 제약 요인이었다. 기본 설정에서는 샌드박스 320개를 지원했으며, 네트워크 이웃 설정을 튜닝하자 1,024개 장치 한도는 그대로인 상태에서 지원 수가 1,000개로 늘었다. 주요 용량 테스트 결과를 얻으려면 전체 튜닝이 필요했다. E2B는 이 증가를 Vera와 x86의 속도 비교가 아니라 동일 서버에서 구성을 비교한 결과라고 설명한다.
평가의 한계와 예정된 테스트
양산 전 단계라는 점 때문에 아직 해결되지 않은 문제가 몇 가지 있다. E2B는 x86 기준 시스템이 일부 복원 작업을 여전히 더 빠르게 완료했으며, 중첩 가상화에는 추가 작업이 필요하다는 점을 확인했다. 비용이나 전력 측정은 이뤄지지 않아 운영 경제성은 이번 평가에 포함되지 않았다.
E2B가 밝힌 다음 단계는 다중 노드 Vera 클러스터, 객체 스토리지 기반 콜드 재개, 그리고 동일한 E2B 패키징과 호스트 튜닝을 적용한 x86 비교 테스트다. 이제 더 폭넓은 배포 가능성을 판단하려면 후속 테스트가 필요하다. 즉, 전체 스택 결과가 패키징과 튜닝을 비슷하게 적용한 x86 시스템에서도 유지되는지, 단일 서버의 용량 결과가 클러스터에서도 재현되는지를 확인해야 한다.
