Wasmtime, WasmEdge и Wasmer: выбор runtime для VDS

WebAssembly на сервере используют не как полную замену виртуальным машинам или контейнерам, а как компактный формат для изолированного выполнения кода. На VDS он подходит для плагинов, пользовательских функций, обработчиков событий, расширений backend-сервисов и задач, которым требуется контролируемый доступ к файловой системе, сети и ресурсам хоста.

Среди универсальных серверных runtime для таких задач рассматривают Wasmtime, WasmEdge и Wasmer. Все три запускаются на Linux x86_64 и ARM64, поддерживают встраивание в приложения и способны исполнять WASI-модули. Их архитектурные приоритеты различаются: Wasmtime теснее связан с развитием WASI и компонентной модели, WasmEdge делает акцент на расширениях и разных режимах выполнения, а Wasmer предлагает несколько компиляторов и экосистему WASIX.

Ниже рассматривается запуск WebAssembly непосредственно на VDS. Браузерный WebAssembly и Kubernetes-оркестрация не входят в рамки обзора. Для размещения runtime и backend-сервисов потребуется VPS-сервер с доступом к настройкам окружения.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Краткий вывод

• Wasmtime — основной кандидат для новых backend-проектов, которым нужны WASI, WIT, компонентная модель и строгое управление возможностями гостевого кода. Особенно удобен для хостов на Rust и C.
• WasmEdge — практичный вариант, если важны интерпретатор, JIT и AOT в одном runtime, готовые расширения, сетевые сценарии или SDK для нескольких языков. Компонентная модель пока не является его наиболее зрелой частью.
• Wasmer — гибкий runtime с выбором между Singlepass, Cranelift и LLVM, развитым WASIX и удобным запуском более сложных приложений. Его стоит выбирать, когда эти возможности важнее тесной интеграции с актуальной компонентной моделью WASI.

Универсального победителя по скорости нет. Итог зависит от соотношения холодных и прогретых запусков, сложности модуля, выбранного компилятора, числа экземпляров, частоты вызовов host-функций и архитектуры процессора. Выбор по чужому микробенчмарку без проверки на конкретной VDS ненадёжен.

Что делает серверный WebAssembly runtime

Файл .wasm содержит переносимый байткод, но сам по себе не умеет открывать файлы, создавать сокеты или читать переменные окружения. Runtime проверяет модуль, компилирует или интерпретирует его, выделяет память, связывает импорты с функциями хоста и контролирует выполнение.

Для backend-приложения важны несколько уровней:

• WebAssembly Core определяет инструкции, линейную память, таблицы, функции и базовые типы.
• WASI предоставляет стандартизированные интерфейсы к ресурсам операционной системы без полного доступа к POSIX API.
• Компонентная модель описывает высокоуровневые интерфейсы между гостем и хостом либо между несколькими компонентами.
• SDK runtime позволяет загружать модули, регистрировать host-функции, задавать лимиты и вызывать экспортированные функции из основного приложения.

Изоляция WebAssembly не отменяет необходимость обычной защиты VDS. Уязвимость в runtime, чрезмерно широкая host-функция или ошибочно открытый каталог могут дать гостевому коду больше возможностей, чем предполагалось. WebAssembly следует считать дополнительной границей внутри процесса, а не полной заменой отдельному системному пользователю, cgroups, seccomp или виртуальной машине.

WASI: Preview 1, WASI 0.2 и WASI 0.3

Термин «поддержка WASI» недостаточно точен. На практике он может означать старый интерфейс wasi_snapshot_preview1, компонентные интерфейсы WASI 0.2 либо новый асинхронный стек WASI 0.3.

WASI Preview 1

Preview 1 по-прежнему важен из-за большого количества существующих модулей и языковых toolchain. Он ориентирован на core-модули и системные вызовы в стиле файловых дескрипторов. Для консольных утилит и простых вычислительных задач этого часто достаточно.

Недостаток Preview 1 — слабая типизация границы между хостом и гостем: строки, записи и другие сложные значения передаются через линейную память и соглашения ABI. Кроме того, он не решает композицию сервисов так же последовательно, как компонентная модель.

WASI 0.2 и компонентная модель

WASI 0.2 строится вокруг компонентов и WIT — языка описания интерфейсов. Вместо ручной передачи указателей разработчик может определить функции, записи, варианты, списки, строки и ресурсы. Генераторы bindings создают код для гостя и хоста, а Canonical ABI преобразует значения.

Это полезно в системах плагинов: контракт можно описать независимо от языка реализации. Например, основной сервис написан на Rust, один компонент — на Go, другой — на языке, toolchain которого выпускает совместимые компоненты. Реальная переносимость зависит не только от runtime, но и от зрелости bindings для каждого языка.

Многие компиляторы всё ещё создают Preview 1-модули. Для перехода применяют адаптер, оборачивающий core-модуль в компонент. Это рабочий путь миграции, но он добавляет слой совместимости и не превращает старое приложение в нативный компонент автоматически.

WASI 0.3

WASI 0.3 переносит асинхронные операции на примитивы компонентной модели. Интерфейсы используют futures и streams вместо части схем с отдельными ресурсами, подписками и ручным опросом. Для HTTP, потокового ввода-вывода и цепочек компонентов это делает модель естественнее.

Ратификация спецификации не означает одновременную и одинаково полную поддержку во всех runtime, SDK и языковых toolchain. Если проекту нужен именно WASI 0.3, проверяйте не общую отметку «WASI supported», а конкретные интерфейсы, синхронный или асинхронный режим вызова и используемую версию bindings.

Wasmtime: ставка на стандарты и контролируемое встраивание

Wasmtime развивается в экосистеме Bytecode Alliance и тесно связан с Cranelift, WIT, WASI и инструментами компонентной модели. Для нового backend-проекта это обычно наиболее прямой путь к WebAssembly Components без привязки к нестандартному системному API.

Компиляция и производительность

Основной оптимизирующий компилятор Wasmtime — Cranelift. Runtime также развивает Winch как baseline-компилятор с приоритетом на меньшую задержку компиляции. Такое разделение полезно на VDS: для короткоживущих экземпляров важна скорость подготовки кода, а для постоянно работающих компонентов — качество машинного кода.

Wasmtime позволяет сериализовать предварительно скомпилированный модуль или компонент и загружать его без повторения полного этапа компиляции. Это часто называют AOT, хотя результат не следует воспринимать как универсальный ELF-бинарник. Артефакт зависит от версии runtime, настроек, целевой архитектуры и набора возможностей CPU.

Предварительную компиляцию нужно выполнять для того же семейства процессоров и совместимого набора инструкций, которые доступны на рабочей VDS. Артефакт, подготовленный для x86_64, нельзя перенести на ARM64. Даже между двумя x86_64-серверами агрессивная привязка к CPU может стать причиной несовместимости.

Компонентная модель и sandboxing

Из трёх рассматриваемых runtime Wasmtime предлагает наиболее цельный путь для компонентов: загрузку компонента, WIT-bindings, связывание импортов, WASI 0.2 и инструменты адаптации Preview 1. Развитие асинхронных компонентных вызовов продолжается и затрагивает в том числе C API.

Wasmtime позволяет формировать WASI-контекст отдельно для каждого экземпляра. Хост явно решает, какие каталоги открыть, какие переменные окружения передать, куда направить стандартные потоки и какие сетевые операции разрешить. Дополнительно можно ограничивать память, число вычислительных шагов через fuel и время исполнения через epoch interruption.

Fuel полезен для детерминированного ограничения CPU, но его подсчёт создаёт накладные расходы. Epoch interruption дешевле для длительных задач, однако требует от хоста периодически увеличивать epoch и правильно назначать deadline экземплярам. Ни один механизм не заменяет лимиты процесса на уровне Linux, если runtime или host-код потребляет ресурсы вне WebAssembly.

SDK и сценарии выбора

Наиболее сильная сторона Wasmtime — Rust API. C API подходит для C и C++ и служит основой для bindings других языков. Существуют интеграции с Python, .NET, Go и Ruby, но необходимо различать API самого проекта, проекты Bytecode Alliance и сторонние обёртки.

• Выбирайте Wasmtime для нового сервиса вокруг WIT и компонентной модели.
• Он подходит для недоверенных плагинов с минимальным набором capabilities.
• Это логичный вариант, когда основное приложение написано на Rust или C/C++.
• Он предпочтителен, если важна стандартизированная композиция компонентов, а не расширенный POSIX-слой.

Ограничения Wasmtime связаны прежде всего с быстрым развитием API и спецификаций. Сериализованные артефакты и интеграции нужно обновлять контролируемо, а поддержка компонентов и WASI может появляться в Rust API раньше, чем в отдельных языковых bindings. Для приложений, ожидающих почти полный POSIX, потребуется адаптация либо другой runtime.

WasmEdge: режимы выполнения и расширения

WasmEdge ориентирован на cloud-native и edge-сценарии, но может использоваться как библиотека или CLI-runtime на VDS. Он поддерживает Linux x86_64 и AArch64 и предлагает C API, а также SDK для Rust, Go, Node.js и других языков.

Interpreter, JIT и AOT

В WasmEdge доступны интерпретатор, JIT и AOT. Интерпретатор уменьшает требования к этапу подготовки и удобен для диагностики или редко вызываемых модулей. JIT компилирует код во время работы, а AOT переносит компиляцию до запуска и подходит для стабильных production-нагрузок.

AOT-компилятор может создавать нативную разделяемую библиотеку или WebAssembly-файл с машинным кодом в custom sections. Второй формат удобнее для распространения вместе с исходным байткодом, но AOT-часть всё равно зависит от целевой архитектуры. API позволяет явно выбрать режим, а не полагаться только на автоматическое поведение runtime.

На VDS это полезно, когда одна система запускает разные классы задач. Небольшие одноразовые функции можно исполнять без долгой оптимизации, а постоянно вызываемые вычислительные модули — предварительно компилировать. Недостаток — больше конфигурационных вариантов, которые нужно одинаково воспроизводить в тестовой и рабочей среде.

WASI, расширения и компоненты

WasmEdge поддерживает WASI и дополняет его собственными расширениями и плагинами, включая сетевые и специализированные вычислительные возможности. Это сокращает путь к практическому серверному приложению, но создаёт зависимость от конкретного runtime.

Если гостевой код напрямую использует WasmEdge-specific socket API, плагин базы данных или вычислительное расширение, перенести тот же файл в Wasmtime или Wasmer без изменений может не получиться. Поэтому нестандартные импорты лучше изолировать за собственным WIT-контрактом либо тонким адаптером.

Поддержка компонентной модели остаётся развивающимся направлением. Если компоненты являются обязательным production-форматом, WasmEdge следует проверять на конкретном наборе функций, а не выбирать по общему заявлению о поддержке WebAssembly. Для core-модулей и Preview 1-приложений это ограничение может быть несущественным, но становится критичным при зависимости от WIT-ресурсов, композиции компонентов или асинхронных интерфейсов WASI.

Когда выбирать WasmEdge

• Нужен явный выбор между интерпретатором, JIT и AOT.
• Проект использует проверенные WasmEdge-плагины или расширения.
• Хост написан на Go, Rust, C/C++ или Node.js, а подходящий SDK проверен командой.
• Основная нагрузка состоит из core-модулей или WASI Preview 1.
• Важна возможность поставлять AOT-код внутри WebAssembly-файла.

При развёртывании определите, будет ли runtime поставляться системным пакетом, локальным архивом приложения или собираться вместе с backend. Системная установка упрощает обновление одной копии библиотеки, но может усложнить параллельную эксплуатацию сервисов с разными требованиями к ABI. Также нужно контролировать совместимость C-библиотеки, плагинов и языковых SDK.

Wasmer: компиляторы и расширенная среда WASIX

Wasmer сочетает standalone runtime, встраиваемую Rust-библиотеку, языковые SDK, систему пакетов и WASIX. WASIX расширяет WASI возможностями, которые нужны приложениям с более привычными POSIX-паттернами, включая процессы, потоки и сетевое взаимодействие.

Singlepass, Cranelift и LLVM

Главное архитектурное отличие Wasmer — несколько компиляторных backend:

• Singlepass минимизирует время компиляции и подходит для частых холодных запусков, когда максимальная скорость длительного вычисления не является главной целью.
• Cranelift предлагает баланс между временем компиляции и качеством машинного кода.
• LLVM тратит больше времени на оптимизацию, но может быть выгоден для долгоживущих и вычислительно тяжёлых модулей.

Wasmer умеет кешировать скомпилированные модули, применять metering и формировать данные для профилирования.

Больше вариантов не всегда означает лучший результат. Если сервис запускает небольшой модуль один раз для обработки короткого запроса, выигрыш LLVM во время выполнения может не окупить компиляцию. Если один экземпляр обслуживает миллионы вызовов, ситуация может быть обратной. На production измеряйте полное время запроса, а не только цикл внутри экспортированной функции.

WASI, WASIX и интеграция

Стандартный WASI подходит для приложений, специально спроектированных под capability-based интерфейсы. WASIX стремится запускать более широкий класс программ, ожидающих сокеты, многопоточность, порождение процессов и другие системные возможности.

Для переноса существующей серверной утилиты это может быть важным преимуществом. Для небольшого недоверенного плагина расширенная системная поверхность, наоборот, не всегда нужна. Чем больше возможностей предоставляет среда, тем внимательнее хост должен задавать разрешения и проверять, какие каталоги, переменные, сеть и дочерние процессы доступны экземпляру.

В документации Wasmer заметное место занимают собственная пакетная модель, WASIX и более ранний стек WAI. Официальные материалы не представляют актуальную WebAssembly Component Model как основной production-путь в той же степени, что документация Wasmtime. Поэтому для WIT-компонентов, WASI 0.2 и WASI 0.3 необходим отдельный proof of concept. Нельзя автоматически приравнивать WAI к современной компонентной модели: они решают похожую задачу интерфейсов, но различаются форматом, инструментами и совместимостью.

• Выбирайте Wasmer, если нужен выбор между быстрой компиляцией Singlepass, сбалансированным Cranelift и LLVM.
• Он уместен, когда приложению требуются возможности WASIX.
• Рассматривайте его при важности собственной системы пакетов и запуска готовых Wasmer-приложений.
• Не выбирайте его без проверки, если компонентная модель является центральным требованием проекта.

Сравнение по ключевым критериям

WASI и переносимость

Wasmtime лучше подходит для стратегии, основанной на стандартных WASI и WIT. WasmEdge удобен для Preview 1 и собственных расширений. Wasmer выделяется WASIX, который облегчает перенос сложных приложений, но создаёт отдельную платформенную зависимость.

Если один гостевой модуль должен работать во всех трёх runtime, безопасным общим знаменателем остаются WebAssembly Core и проверенное подмножество WASI Preview 1. Sockets, threads, HTTP-интерфейсы и компоненты необходимо тестировать отдельно.

Компонентная модель

Для component-first архитектуры наиболее обоснованным выбором является Wasmtime. WasmEdge развивает поддержку, но её полноту следует подтверждать прототипом. В Wasmer нельзя опираться на старые WAI-материалы как на доказательство совместимости с актуальными компонентами.

Холодный запуск и производительность

Холодный запуск включает чтение файла, валидацию, компиляцию, связывание импортов, создание экземпляра и инициализацию гостя. На него влияют размер модуля, число функций, выбранный backend, кеш ОС и объём стартового кода приложения.

Для снижения задержки применяют baseline-компиляцию, AOT, кеширование и повторное использование подготовленного модуля. Интерпретатор может быстрее начать выполнение простого кода, но проиграть после достаточного числа вызовов. В длительных вычислениях LLVM, Cranelift и AOT-режимы могут показать разные результаты в зависимости от кода.

Частые переходы через границу host–guest способны нивелировать разницу между компиляторами. Выгоднее передавать крупную операцию одним вызовом, чем вызывать host-функцию для обработки каждого элемента.

Память и управление ресурсами

На VDS важна не только память одного экземпляра, но и её рост при десятках или сотнях одновременных sandbox. Измеряйте код runtime, кеш компиляции, таблицы, линейную память гостя, стеки, состояние WASI и память host-приложения. Маленький размер файла .wasm не гарантирует столь же маленький RSS процесса.

Для недоверенного кода runtime должен обеспечивать как минимум ограничение памяти и завершение бесконечного вычисления. Дополнительно нужны лимиты числа экземпляров, размера входных данных, объёма вывода и количества одновременно открытых ресурсов.

Эти ограничения удобнее задавать в host-приложении и дублировать средствами Linux: системным пользователем, systemd, cgroups и файловыми правами. Даже если WebAssembly-экземпляр изолирован, ошибка в host-функции выполняется с правами процесса runtime.

Linux x86_64 и ARM64

Все три runtime подходят для обеих основных серверных архитектур. Однако переносимым является исходный WebAssembly-байткод, а не нативный AOT-артефакт. Для смешанного парка VDS необходимы как минимум две сборки. Если включены CPU-specific оптимизации, могут потребоваться отдельные варианты даже внутри одной архитектуры.

ARM64 часто выбирают из-за соотношения цены и доступных ресурсов, но результат конкретной нагрузки зависит от процессора провайдера. Не переносите выводы с локального ноутбука ARM64 на сервер без проверки. Также убедитесь, что языковой SDK публикует готовую нативную библиотеку именно для Linux ARM64, а не только для macOS ARM64.

Как корректно сравнить runtime на VDS

Для proof of concept подготовьте один и тот же модуль и несколько профилей нагрузки:

1. Короткую функцию без WASI для оценки компиляции и базового вызова.
2. CPU-bound задачу, работающую достаточно долго для сравнения машинного кода.
3. Обработку строк или структур через реальный host-интерфейс.
4. Чтение разрешённого файла или потоковый ввод-вывод.
5. Создание множества независимых экземпляров для измерения RSS и времени инициализации.

Холодные тесты запускайте отдельно от прогретых. Фиксируйте архитектуру CPU, версию runtime, compiler backend, параметры оптимизации, размер модуля и состояние кеша. Для каждой конфигурации оценивайте медиану и высокие перцентили, а не один лучший результат.

На Linux можно измерять общее время процесса и максимальный RSS штатной утилитой /usr/bin/time, а аппаратные события — через perf stat, если это разрешено настройками VDS. Встроенный runtime лучше профилировать внутри реального backend-процесса, поскольку отдельный CLI не учитывает стоимость SDK, пула экземпляров и сериализации запросов.

Обязательно проверьте отказные сценарии: бесконечный цикл, превышение памяти, запрещённый путь, слишком большой вывод, panic или trap гостя, отмену асинхронной операции и одновременное завершение нескольких экземпляров. Runtime должен вернуть контролируемую ошибку, не нарушив работу основного сервиса.

Практическая матрица выбора

• Система недоверенных плагинов для Rust-backend: в первую очередь Wasmtime.
• Новые сервисные компоненты с WIT-контрактами: Wasmtime, особенно если требуется WASI 0.2 и дальнейший переход на 0.3.
• Core-модули с выбором interpreter, JIT и AOT: WasmEdge.
• Проект, завязанный на расширения WasmEdge: WasmEdge при осознанном принятии vendor lock-in.
• Частые холодные запуски: протестируйте Wasmer Singlepass и Wasmtime Winch на своей нагрузке.
• Долгоживущие вычислительные модули: сравните Wasmer LLVM, Cranelift, AOT-режим WasmEdge и Wasmtime как базовый вариант.
• Перенос приложения, которому тесно в стандартном WASI: рассмотрите Wasmer с WASIX.
• Хост на Go или Node.js: сравните зрелость конкретных SDK WasmEdge и Wasmer; Wasmtime выбирайте после проверки нужных bindings.
• Обязательная переносимость между runtime: ограничьтесь согласованным подмножеством WebAssembly Core и WASI, избегая vendor-specific импортов.

Итог

Wasmtime, WasmEdge и Wasmer решают разные варианты одной задачи. Wasmtime логично выбирать для стандартизированных серверных компонентов, строго ограниченных плагинов и глубокой интеграции с Rust или C. WasmEdge удобен как многофункциональный runtime с интерпретатором, JIT, AOT и прикладными расширениями. Wasmer привлекателен выбором компиляторов и WASIX, особенно когда гостевому приложению требуется более широкая системная среда.

Для нового component-first проекта отправной точкой будет Wasmtime. Для существующего Preview 1-модуля выбор менее однозначен: WasmEdge может оказаться удобнее по SDK и расширениям, а Wasmer — по модели компиляции или совместимости через WASIX.

Финальное решение принимайте после теста на той же архитектуре и классе VDS, где будет работать production. Измеряйте не абстрактную скорость WebAssembly, а полный жизненный цикл: загрузку, компиляцию, создание экземпляра, host-вызовы, память, ограничение ресурсов, обработку ошибок и обновление runtime.