CubeSandbox vs E2B для продакшн-агентов
Сравнение CubeSandbox и E2B для выполнения агентов: изоляция, скорость запуска, совместимость и когда самостоятельный хостинг оправдывает компромиссы.
Меня зовут Дора. Недавно у нас был агент, выполняющий вызовы инструментов в продакшне. Оркестратор работал нормально. LLM работала нормально. Узким местом был слой песочницы — каждый раз, когда агенту нужно было выполнить фрагмент сгенерированного кода, мы платили 200 мс холодного старта, иногда больше, иногда очередь вела себя непредсказуемо. При ~40 вызовах инструментов за сессию это складывается в ощутимую долю общего времени.
Поэтому я начала изучать альтернативы. Сравнение, которое сейчас делают все, — это CubeSandbox vs E2B. Эта статья — результат двух недель, в течение которых я читала оба проекта, развернула один из них и не смогла развернуть другой (об этом позже).
Небольшая оговорка: у меня нет коммерческих отношений ни с одним из проектов. Оба с открытым исходным кодом. Картина ниже — это компромисс между размещением у провайдера и самостоятельным хостингом, а не история о «хорошем» и «плохом».
CubeSandbox vs E2B: Обзор

Оба проекта решают одну и ту же проблему примерно одним и тем же способом: запускают микровиртуальную машину, выполняют ненадёжный код, завершают работу. Оба публикуют показатели производительности примерно одного порядка. Реальное различие — в форме продукта.
CubeSandbox — это стек с открытым исходным кодом «песочница как сервис» от Tencent Cloud, выпущенный в апреле 2026 года под лицензией Apache 2.0. Построен на RustVMM и KVM. Заявленные показатели из их репозитория: холодный старт менее 60 мс, ~5 МБ памяти на песочницу, нативная совместимость с E2B SDK (замените одну переменную окружения с URL). Распространяется как полный самостоятельно размещаемый стек, а не просто библиотека.
E2B тоже с открытым исходным кодом (также Apache 2.0), построен на микровиртуальных машинах Firecracker. Основан в 2023 году. Инициализация песочницы занимает около 150–200 мс при использовании пулов предварительно прогретых снимков. Самостоятельный хостинг существует через скрипты Terraform, но основное распространение — управляемое облако: Hobby (бесплатно, кредиты на $100), Pro ($150/мес + использование), Enterprise (BYOC, on-prem). Пользователи с самостоятельным хостингом — меньшинство, размещение у провайдера — основная история.
Таким образом, реальная ось не «какая песочница лучше». Она такова:
| Функция | CubeSandbox | E2B |
|---|---|---|
| Лицензия | Apache 2.0 | Apache 2.0 |
| Основной режим | Самостоятельный хостинг | Размещённый SaaS (самостоятельный хостинг возможен) |
| Базовый VMM | RustVMM + KVM | Firecracker (KVM) |
| Заявленный холодный старт | <60ms | ~150–200 мс |
| Память на песочницу | ~5 МБ | ~5 МБ |
| Совместимость с SDK | Прямая замена E2B SDK | Нативный E2B SDK |
| Поддержка GPU | Требует Linux x86_64 с поддержкой KVM; нет нативного проброса в upstream | Те же ограничения Firecracker для GPU |
| Операционная нагрузка | Вы управляете кластером | E2B управляет кластером (управляемый) |
Числа выше взяты из собственных репозиториев и примечаний к выпускам каждого проекта, а не из бенчмарка, который я запускала. Воспринимайте их как данные от поставщика — полезные в качестве ориентира, но не замена вашим собственным тестам.
Компромиссы между размещением у провайдера и самостоятельным хостингом
Это и есть настоящее решение, и оно по большей части не техническое.
Выбор размещения у E2B означает, что вы перестаёте думать о ядрах микровиртуальных машин, пулах снимков, хостах KVM и отказоустойчивости оркестратора. Вы также перестаёте думать об оптимизации затрат, потому что ценообразование уже задано за вас. Команда, в которой я работала, пробовала E2B Pro в течение двух недель — интеграция занимает около часа, SDK чистый, и сэкономленные инженерные часы реальны.
Выбор самостоятельного хостинга с CubeSandbox означает, что вы владеете машиной. Стоимость становится «сколько стоит базовый сервер», а не «сколько стоит наша кривая использования». Соответствие требованиям упрощается, потому что данные не покидают ваш периметр. Но вы также берёте на себя дежурство, обновления ядра, настройку политик eBPF. CubeSandbox поставляется с одноклик-развёртыванием для одноузловых и кластерных установок, что помогает, но «одноклик-развёртывание» и «готовый к продакшну кластер» — это разные вещи.
Я сделала паузу на несколько дней, потому что ответ действительно зависит от состава команды. Стартап из четырёх человек, выпускающий агентов в следующем квартале, вероятно, не должен управлять собственным флотом микровиртуальных машин. Команда с инфраструктурными инженерами и требованиями к соответствию — вероятно, должна.
Вопросы совместимости и миграции

История совместимости CubeSandbox с E2B — самое интересное техническое утверждение в выпуске CubeSandbox. По их документации, существующий агент на базе E2B может заменить одну переменную окружения и направить трафик на самостоятельно размещённый кластер CubeSandbox — без изменений кода. Я лично не мигрировала продакшн-нагрузку E2B, поэтому принимаю это утверждение на веру, но его можно проверить, прочитав вызовы SDK, которые принимает каждая сторона. Площадь невелика. Обе поддерживают одинаковый жизненный цикл Sandbox: create, run command, run code, terminate.
Здесь становится полезным: это означает, что CubeSandbox — по сути бэкенд с собственной инфраструктурой для E2B SDK. Вы можете разрабатывать на управляемом облаке E2B, а затем перенаправить на собственный кластер, когда объём использования это оправдает. Аргумент о привязке к поставщику становится слабее для обеих сторон — что, я думаю, полезно для категории в целом.
Где побеждает CubeSandbox
Контроль, структура затрат и владение инфраструктурой
Для любой команды агентов, работающей с достаточным объёмом, при котором цены управляемых песочниц начинают появляться в ежемесячном счёте, CubeSandbox — более честный вариант. Вы платите за оборудование, которое уже понимаете. Фильтрация исходящего трафика через eBPF (CubeVS) настраивается на уровне ядра. Если ваши правила резидентности данных говорят «это не может покинуть наш VPC», — это 30-секундный разговор с самостоятельно размещённой песочницей и гораздо более длинный разговор с управляемой.
То, что говорят недостаточно часто: самостоятельно размещённая среда выполнения агентов — это не бесплатный обед. Предельная стоимость каждого выполнения снижается, фиксированная стоимость растёт. Точка безубыточности уникальна для кривой использования каждой команды. Посчитайте, прежде чем решать. Если ответ оказывается «мы сэкономим $300/месяц и добавим два часа еженедельной операционной работы» — это не победа.
Заявления о производительности и плотности, которые команды должны протестировать

CubeSandbox публикует холодный старт менее 60 мс, который в примечаниях к выпуску Tencent Cloud через HPCwire описывается как «треть от среднего по отрасли (150 мс)». Они также заявляют о 2000+ песочницах на одной физической машине. Эти цифры получены из производственных нагрузок внутри Tencent Cloud, а не из синтетического бенчмарка — что лучше синтетического, но это всё равно их нагрузка, а не ваша.
Что я бы протестировала, прежде чем верить заголовку:
- Холодный старт при вашем реальном размере снимка (шаблон 5 ГБ ведёт себя иначе, чем шаблон 200 МБ)
- Поведение параллелизма на p99, а не только среднее — CubeSandbox публикует среднее время отклика 67 мс при 50 параллельных запросах, что обнадёживает, но не то же самое, что p99
- Переживут ли ваши конкретные зависимости урезанное ядро RustVMM без сюрпризов
Здесь мои данные заканчиваются. Я развернула CubeSandbox на одной виртуальной машине с поддержкой KVM и запустила песочницы примерно за полдня. Я не проводила нагрузочное тестирование при заявленных показателях плотности. Любой, кто утверждает, что делал это через три недели после публичного выпуска проекта, вероятно, преувеличивает.
Где E2B всё ещё побеждает
Другая половина картины CubeSandbox vs E2B: если вы не хотите думать об инфраструктуре, побеждает E2B. Это звучит пренебрежительно, но это реальный вывод.
В частности:
- Управляемый SDK E2B более зрелый. Больше примеров, больше интеграций LangChain/LlamaIndex, более длинный послужной список.
- Manus, анализ кода Perplexity, Open R1 от Hugging Face — существуют производственные примеры в масштабе. У CubeSandbox есть производственные примеры внутри Tencent Cloud, что реально, но внешние кейсы ещё пишутся.
- Документация E2B охватывает десктопные песочницы, шаблоны из Dockerfile, сохранение файлов и 24-часовые жизненные циклы сессий из коробки. CubeSandbox более спартанский — README и примеры охватывают основной жизненный цикл, но не длинный хвост.
- Сам Firecracker — известная величина. AWS Lambda работает на нём. Проект Firecracker находится в продакшне с 2018 года. Стек CubeSandbox на базе RustVMM новее в публичном пространстве, даже если он работал внутри Tencent какое-то время.

Если вы выпускаете продукт агента v1 в следующем квартале и у вас нет инфраструктурного специалиста, управляемый план E2B — более простой путь. Часы, не потраченные на борьбу с кластером песочниц, — это часы, потраченные на самого агента. Это стоит $150/месяц для многих команд.
Система принятия решений для команд агентов
После двух недель изучения этой темы вот система, которую я бы реально использовала. Это один из наиболее полезных шорткатов для сравнения песочниц для агентов ИИ, которые я нашла:
- Объём ниже ~50 тыс. часов работы песочницы в месяц, нет требований к соответствию, нет инфраструктурной команды → E2B с размещением у провайдера. Дальше не читайте.
- Объём выше этого, или строгая резидентность данных, или вы уже используете Kubernetes/микровиртуальные машины → CubeSandbox с самостоятельным хостингом. Экономика меняется, и у вас есть ресурсы для эксплуатации.
- Где-то посередине → Начните с E2B с размещением у провайдера. Разрабатывайте с SDK. Когда счёт начнёт ощутимо расти или возникнут вопросы соответствия, совместимость SDK означает, что миграция — это изменение одного URL. Эта гибкость — самое недооценённое свойство всего этого сравнения.
- Вам нужен проброс GPU для инференса агентов внутри песочницы → Ни один из вариантов не подходит хорошо. Upstream Firecracker не поддерживает проброс GPU нативно, и CubeSandbox наследует аналогичное ограничение. Для этой нагрузки рассмотрите gVisor или Daytona.
Фрейминг, которому я бы сопротивлялась: «CubeSandbox — лучшая технология, поэтому она побеждает». Выбор песочницы на микровиртуальных машинах — это выбор формы продукта. Технологии примерно равнозначны по опубликованным характеристикам. Ежедневная стоимость — операционная.
FAQ

Это вопросы, которые мне постоянно задавали коллеги по команде во время оценки CubeSandbox vs E2B.
Является ли CubeSandbox полноценной заменой E2B?
Для поверхности E2B SDK — да, по замыслу. Проект позиционирует себя как совместимую с E2B среду выполнения, где вы меняете переменную окружения. Для функций за пределами основного жизненного цикла песочницы (шаблоны из Dockerfile, десктопные песочницы, управляемая наблюдаемость) ответ — «пока нет».
Что самостоятельный хостинг реально добавляет к нагрузке?
Хост с поддержкой KVM (или флот), управление ядром/образами, мониторинг, настройка пула снимков, политика исходящего сетевого трафика и дежурство. Выпуск Tencent Cloud описывает «одноклик-развёртывание» для одноузловых и кластерных установок, но считать это идентичным кластеру производственного уровня — оптимистично. Планируйте 1–2 недели на настройку и регулярную небольшую долю чьего-то внимания.
Какие нагрузки больше всего выигрывают от песочниц на микровиртуальных машинах?
Всё, где вы выполняете сгенерированный моделью код против ненадёжных входных данных в масштабе. Риск общего ядра в обычном Docker — стандартный аргумент против контейнеров для этого — каждая крупная платформа агентов отошла от изоляции с общим ядром по этой причине. Если ваш агент выполняет только изолированный код из фиксированного разрешённого списка доверенных скриптов, микровиртуальные машины могут и не понадобиться.
Что команды должны тестировать в первую очередь?
Три вещи в следующем порядке: холодный старт p99 при вашем реальном размере шаблона; плотность песочниц на доллар оборудования (для самостоятельного хостинга) или на доллар счёта (для размещения у провайдера); режим отказа при пиковой нагрузке. Заголовочные цифры — менее 60 мс против ~150 мс — реальны, но описывают средние значения в благоприятных для поставщика условиях. Ваша нагрузка не совпадёт ни с одним поставщиком — это единственная причина вообще проводить бенчмарк.
Заключение
Дебаты CubeSandbox vs E2B реальны, но слегка неправильно сформулированы. Это не «какая песочница технически превосходит». Обе используют изоляцию на уровне оборудования, обе публикуют достоверные показатели производительности, обе Apache 2.0, обе поддерживают один и тот же SDK. Решение таково: хотите ли вы, чтобы кто-то другой управлял инфраструктурой, или хотите управлять ею сами.
Это продуктовый вопрос, а не инженерный. И честный ответ для большинства команд — «начните с размещения у провайдера, держите миграцию дешёвой». Совместимость SDK между двумя проектами — самое полезное в этом выпуске — это означает, что налог на привязку к поставщику только что стал меньше для всех в инфраструктуре агентов.
Больше информации — как только я протестирую CubeSandbox под реальной нагрузкой. Оба проекта обновляются быстро — это сравнение не состарится так изящно, как базовые технологии.
Предыдущие публикации:




