Разработчики smolvm выпустили версии 1.7.0 и 1.7.1 с интервалом менее суток — 27 и 28 июля 2026 года. Крупный релиз развивает CUDA-remoting, клонирование запущенных виртуальных машин, работу с Docker и containerd, упаковку окружений в .smolmachine и диагностику ошибок при запуске.
smolvm 1.7.0 объединил 96 изменений вокруг CUDA, форков и жизненного цикла VM
smolvm 1.7.0 вышел 27 июля и получился заметно крупнее обычного точечного обновления. В официальном changelog перечислены 96 изменений: от поддержки CUDA 13 внутри гостевой системы до проверок портов, переменных окружения, сетевых диапазонов и операций с дисками.
Уже 28 июля появился smolvm 1.7.1. Этот выпуск закрепляет переход на ветку 1.7, обновляет встроенные библиотеки libkrun для macOS, Linux и Windows, исправляет имя программы в справке CLI и убирает лишнее предупреждение установщика о недостающих упакованных ресурсах. Ещё одно изменение добавляет узловой endpoint для предварительной загрузки .smolmachine в локальный кэш объектов.
smolvm — открытый движок и CLI для запуска Linux-окружений в компактных виртуальных машинах. Каждая машина получает собственное ядро гостевой системы и отделяется от хоста границей гипервизора. Проект умеет запускать OCI-образы, сохранять состояние, создавать временные песочницы и упаковывать подготовленную VM в переносимый файл .smolmachine.
Такой формат подходит для ИИ-агентов, CI-задач, выполнения непроверенного кода и воспроизводимых сред разработки. Сеть у новых машин отключена по умолчанию, а доступ к каталогам, портам, сокетам и учётным данным включается явно.
CUDA-форки сохраняют прогретую модель и разделяют веса между клонами
Самая насыщенная часть smolvm 1.7.0 связана с CUDA-remoting. В этой схеме CUDA-вызовы из гостевой Linux-системы передаются хостовому процессу через vsock. Физическая видеокарта и драйвер остаются на хосте, а приложение внутри VM видит доступное CUDA-устройство через совместимые гостевые библиотеки.
Релиз развивает форки виртуальных машин — создание новых экземпляров из уже запущенной «базовой» VM. Подготовленное окружение может заранее загрузить модель и зависимости, после чего клоны наследуют состояние процессов и файловой системы. Для сервиса инференса это сокращает повторную загрузку одних и тех же данных перед запуском каждого экземпляра.
В 1.7.0 разработчики добавили и исправили несколько механизмов, от которых зависит такой сценарий:
- отдельные процессы обслуживания CUDA для клонов с изоляцией copy-on-fork;
- восстановление CUDA-графов в клонированных рабочих процессах;
- повторное подключение клона после сбоя его worker-процесса;
- сохранение адресов памяти при форке;
- общий импорт весов модели для нескольких клонов;
- отображение разделяемых блоков весов в режиме read-only;
- освобождение VRAM после удаления базовой машины;
- закрепление клона за выбранной GPU в конфигурациях с несколькими видеокартами;
- поддержка гостевой поверхности CUDA 13 и совместимости со сборками для архитектуры sm90.
Защита общих блоков весов от записи закрывает неприятный класс ошибок: случайная модификация памяти одним экземпляром могла повредить данные соседних клонов. Теперь разделяемые участки подключаются только для чтения.
Версия 1.7.0 по умолчанию объявляет гостевому приложению поверхность CUDA 12.4. Пакеты CUDA 13 могут включить соответствующий режим через SMOLVM_CUDA_ADVERTISE. Такой выбор снижает риск несовместимости с программами, которые проверяют версию API при старте.
Ошибки запуска VM теперь указывают на реальную причину сбоя
В предыдущих сборках часть проблем могла завершаться общим сообщением о неудачном запуске. smolvm 1.7.0 расширяет диагностику: движок сообщает реальную ошибку доступа к /dev/kvm, распознаёт устаревший CUDA shim внутри гостевой системы и заранее предупреждает, когда CUDA-remoting запрошен на хосте без подходящей видеокарты.
Изменилось и поведение машин на базе OCI-образов. Если загрузка образа завершилась ошибкой, запуск теперь тоже считается неудачным. Движок очищает созданную служебную VM и сообщает о проблеме, включая название отсутствующих учётных данных при отказе приватного реестра. Учётные данные реестра разрешено передавать во время machine start, поэтому остановленная машина может получить закрытый образ без пересоздания.
Разработчики усилили проверки HTTP API:
| Область | Новая проверка | Практический эффект |
| CPU и память | Некорректные значения отклоняются при создании VM | Ошибка появляется до запуска гипервизора |
| Порты | Проверяются опубликованные и закреплённые порты | Конфликты конфигурации выявляются заранее |
| Переменные окружения | API проверяет имена при create, exec и run | Невалидные параметры не доходят до гостевой системы |
| Сетевые правила | Проверяются CIDR и значения allow-host | Ошибочный фильтр не вызывает panic |
| Точки монтирования | Дубликаты гостевых путей отклоняются | Один каталог не перекрывается несколькими источниками |
| Системные каталоги | Монтирование хостового /boot блокируется | Снижается риск опасной конфигурации |
Операции изменения размера, экспорта, остановки и удаления теперь чаще используют блокировку жизненного цикла. Базовую машину нельзя остановить, удалить или изменить её размер, пока от неё зависят активные клоны. Явно остановленная VM сохраняет это состояние даже при настроенной политике автоматического перезапуска.
Для длительных команд появились два полезных исправления. Вывод exec можно передавать клиенту в реальном времени через Server-Sent Events, а фоновый процесс запускается внутри keep-alive-контейнера и продолжает работать после завершения HTTP-запроса. Тайм-ауты exec теперь применяются и к этому пути выполнения.
Docker, containerd и Unix-сокеты получили отдельные механизмы интеграции
smolvm запускает OCI-образы без обязательного Docker daemon на хосте, но некоторые инструменты разработки и ИИ-агенты ожидают доступ к Docker API. В версии 1.7.0 мост к Docker-сокету стал доступен через HTTP API управления машинами.
Документация рекомендует Unix-сокет как основной endpoint Docker. TCP-вариант сохранён для отдельных конфигураций, при его использовании приходится отдельно контролировать сетевой доступ и аутентификацию.
Новые параметры --expose-socket и --mount-socket позволяют пересылать произвольные Unix-сокеты между хостом и гостевой VM. Этот механизм охватывает больше сценариев, чем один Docker API: локальные агенты могут обращаться к специально выданному сервису, не получая доступ ко всей файловой системе хоста.
Для containerd 2.2 исправлена группировка задач под sandbox shim. Обновление устраняет несовместимость, которая мешала корректно управлять контейнерными задачами внутри модели песочницы. В пути crun exec именованный пользователь из config.User теперь преобразуется в числовой UID перед выполнением команды.
Формат .smolmachine стал удобнее для реестров и локального кэша
Файл .smolmachine хранит подготовленную виртуальную машину вместе с её состоянием и зависимостями. Такое окружение можно собрать один раз, перенести на совместимый хост и запустить без повторной установки пакетов.
smolvm 1.7.0 переводит ссылки на такие артефакты через хостовый механизм pack, добавляет в опубликованные манифесты artifactType из OCI 1.1 и стандартные аннотации. Упаковка VM теперь формирует один слой, а экспорт overlay передаётся на диск потоком. Это уменьшает потребность держать весь экспорт в памяти во время создания файла.
Разработчики исправили экспорт уже созданной машины: наружу передаётся sidecar с данными pack, а исполняемая заглушка остаётся служебной частью. Кэш слоёв, которые разделяются по ссылкам, защищён от удаления алгоритмом LRU, пока на данные опираются активные машины или клоны.
В smolvm 1.7.1 появился endpoint предварительной загрузки .smolmachine в локальный blob cache. Оркестратор может заранее доставить артефакт на узел, чтобы последующий запуск не зависел от скорости реестра в момент создания VM.
Обновление особенно заметно в инфраструктуре для ИИ-агентов и локального инференса
Релизы 1.7.0 и 1.7.1 показывают, куда движется smolvm: проект связывает быстрые microVM, OCI-образы, переносимые артефакты и GPU-задачи в одном runtime. Основной практический сценарий связан с запуском множества изолированных задач из заранее подготовленного состояния — например, когда несколько ИИ-агентов получают собственные песочницы или сервис создаёт клоны прогретой модели.
Текущая официальная документация smol machines указывает на ограничения CUDA-remoting. Каждый CUDA-вызов проходит через дополнительный RPC-слой, поэтому программы с большим количеством коротких чувствительных к задержке операций могут терять производительность. GPU разделяется между VM на уровне процессов и общего хостового контекста; аппаратное разделение видеокарты между недоверенными арендаторами этот механизм не обеспечивает.
В changelog нет новых сравнительных тестов запуска, потребления памяти или CUDA-производительности для ветки 1.7. Оценивать выигрыш в конкретном проекте придётся по собственным нагрузкам: длительный инференс, частые CUDA-вызовы, число клонов и объём разделяемых весов дают разный результат.
Для установки актуальной сборки на macOS или Linux проект предлагает официальный скрипт:
curl -sSL https://smolmachines.com/install.sh | bash
smolvm --versionНа Windows используется отдельная сборка windows-x86_64, а в системе должна быть включена Windows Hypervisor Platform. Для Linux требуется доступный KVM; обновлённая диагностика 1.7.0 теперь помогает сразу увидеть проблему с правами на /dev/kvm.
