Modal становится мейнтейнером gVisor

На этой неделе на конференции KubeCon в Солт-Лейк-Сити Google безвозмездно передает gVisor, включая название и товарные знаки, в фонд Cloud Native Computing Foundation (CNCF), после чего проект переходит на модель управления, возглавляемую мейнтейнерами. Modal is one of three companies, alongside Ant Group and Tines, that have committed to join gVisor’s maintainers, а OpenAI, Tencent и NVIDIA продолжают свое участие и вклад в проект.

gVisor был основным средом выполнения контейнеров в Modal с самого начала. Нам требовалась безопасная среда выполнения с поддержкой GPU и более строгими гарантиями, чем у runc (стандартной среды выполнения в отрасли); с тех пор мы стремимся сделать gVisor самой безопасной и высокопроизводительной средой для рабочих нагрузок ИИ на рынке.

Мы запускаем более 40 миллионов контейнеров gVisor ежедневно. Сюда входят инференс на GPU, многоузловое обучение, агенты для написания кода с ИИ, песочницы и многое другое.

Итак, вот почему мы сделали ставку на gVisor, что мы в него внедрили и куда, по нашему мнению, проект должен развиваться дальше.

gVisor в одном абзаце

В Linux обычные контейнеры разделяют ядро хоста. Каждый системный вызов вашего кода попадает в то же ядро, которое запускает код всех остальных, поэтому одна ошибка или уязвимость в ядре может позволить коду выйти за пределы контейнера и скомпрометировать всю машину. gVisor добавляет отдельное ядро приложения, называемое Sentry, написанное на языке Go между контейнером и хостом. Sentry самостоятельно реализует интерфейс системных вызовов Linux и запрашивает у хоста лишь небольшой отфильтрованный набор операций. Ваша программа видит Linux. Хост видит один хорошо себя ведущий процесс.

Безопасность gVisor обеспечивается слоями. Первый слой — это сам Sentry: он обрабатывает каждый системный вызов приложения с помощью собственной реализации, поэтому приложение никогда не общается с ядром хоста. Второй слой предполагает, что первый может дать сбой. Sentry, в свою очередь, защищен теми же примитивами Linux, которые защищают обычные контейнеры. Пространства имен (Namespaces) предоставляют ему изолированное представление процессов, сети и точек монтирования. pivot_root оставляет его с пустой корневой файловой системой. cgroups ограничивают использование процессора и памяти, а также доступ к устройствам. Строгий фильтр seccomp разрешает лишь немногие системные вызовы хоста, необходимые Sentry, и проверяет многие из их аргументов. Чтобы добраться до хоста, злоумышленнику придется взломать Sentry, а затем преодолеть и эту защиту.

gVisor не требует аппаратной виртуализации, что позволяет запускать его на любой машине Linux. Это включает в себя облачные ВМ, где вложенная виртуализация недоступна или работает медленно, а также «голые» (bare-metal) GPU-серверы, составляющие большую часть нашего парка у десятков облачных провайдеров. По сравнению с обычными контейнерами (т. е. runc), это дает нам реальную границу безопасности между арендаторами.

Почему Modal работает на gVisor

Основой Modal является специализированная среда выполнения контейнеров, которая обеспечивает масштабируемость и производительность, ожидаемые нашими клиентами. Как инфраструктурный провайдер, мы запускаем чужой код — много кода от самых разных людей на общих машинах, масштабируя его от нуля до миллиона песочниц за минуту. При этом мы обязаны изолировать весь этот код, что предъявляет довольно жесткие требования:

• Многоарендность (Multi-tenancy) требует реальной границы. Общее ядро хоста не является приемлемой границей, когда код мог быть сгенерирован минуту назад моделью по запросу пользователя.
• GPU должны просто работать. Интерфейс nvproxy в gVisor позволяет изолированному процессу использовать графические процессоры NVIDIA через прокси, который понимает и проверяет интерфейс ioctl драйверов, вместо того чтобы подвергать контейнер воздействию «сырого» драйвера. Память и вычислительные мощности GPU остаются нативным.
• Запуск должен быть быстрым. gVisor может загрузить песочницу примерно за 25 мс с накладными расходами памяти всего в 12 МБ.
• Состояние должно быть переносимым. gVisor может создавать контрольные точки (checkpoint) для всей песочницы (каждый процесс, файл и сокет, а с cuda-checkpoint — и память GPU) и восстанавливать ее на другой машине. Это лежит в основе снимков памяти Modal и снимков памяти GPU.
• Система должна работать везде, где работаем мы. Отсутствие вложенной виртуализации и кастомного ядра хоста означает, что одна и та же песочница запускается в любом облаке и на любом сервере без ОС, который мы приобретаем.

В анонсе Google компания Modal описывается как . Мы считаем, что это скоро изменится, и переход под крыло CNCF играет в этом ключевую роль в значительной степени.

В цифрах

Modal участвует в разработке gVisor с 2023 года и с тех пор значительно увеличил объемы вклада в основной репозиторий (upstream). В этом году мы сформировали вокруг проекта специализированную команду для более качественной поддержки потребностей наших клиентов.

Что мы создали и передали в upstream

Наши клиенты дают нам множество задач для работы над gVisor. Поддержка нового GPU, запуск профилировщика, выжимание еще нескольких ГБ/с из общей памяти. Мы выполняем эту работу и отправляем изменения в upstream. Modal публикует подавляющее большинство своих патчей с открытым исходным кодом и направляет больше инженерных ресурсов на проект по мере присоединения к его мейнтейнерам.

GPU: поддерживаем nvproxy на шаг впереди с NVIDIA

nvproxy — это компонент gVisor, который обеспечивает работу GPU. Он должен понимать каждый вызов ioctl, который драйвер NVIDIA в пользовательском пространстве отправляет драйверу ядра, а NVIDIA меняет этот интерфейс с каждым выпуском драйверов. Мы внесли в upstream следующие изменения:

• Новые GPU и драйверы. Поддержка новых версий драйверов NVIDIA по мере их выхода, а также недостающие компоненты для более новых GPU, таких как Blackwell и RTX PRO 6000.
• Многопроцессорные рабочие нагрузки с GPU. Графические процессоры на одном сервере могут напрямую общаться друг с другом через NVLink, включая функции NVLink, которые использует NCCL на крупных серверах с H100 и H200. Процессы могут совместно использовать память GPU, на что опирается NCCL для передачи данных между GPU на одной машине. Благодаря CUDA MPS несколько процессов могут эффективно делить один GPU.
• Графика, симуляция и видео. Рендеринг Vulkan и бездисплейный (headless) OpenGL, а также аппаратные видеокодеры и декодеры NVIDIA. Сюда входят симуляторы робототехники, такие как MuJoCo и NVIDIA Omniverse, а также видеопайплайны GPU в FFmpeg.
• Мониторинг. Инструменты мониторинга nvidia-smi и DCGM от NVIDIA работают внутри песочницы, включая отслеживание использования GPU для каждого процесса.
• Профилирование и отладка. NVIDIA Nsight Systems и Nsight Compute, аппаратное трассирование на GPU Blackwell, а также дампы памяти ядер GPU для отладки падающих ядер.
• GPUDirect RDMA. Память GPU может передаваться напрямую сетевой карте, благодаря чему данные перемещаются между GPU на разных машинах в обход CPU. Именно это позволило нам запустить ModelExpress в gVisor (подробнее в разделе RDMA ниже).

В результате в gVisor теперь запускается широкий спектр сложных и нишевых рабочих нагрузок GPU.

RDMA: многоузловое обучение внутри песочницы

Когда мы создавали поддержку нескольких узлов, gVisor не поддерживал RDMA, поэтому мы добавили его и передали изменения в upstream. Многоузловое обучение, при котором GPU на разных машинах обмениваются градиентами через InfiniBand, RoCE или EFA, раньше должно было запускаться вне песочницы. Мы создали rdmaproxy — новый прокси-сервер устройств gVisor для интерфейса RDMA verbs, созданный по образцу nvproxy. Контейнер получает настоящий путь передачи данных сетевой карты (NIC), а gVisor проверяет путь управления.

• Поддержка NVIDIA ConnectX (InfiniBand и RoCE) и AWS EFA.
• Создание топологии RDMA sysfs внутри песочницы, благодаря которой NCCL сопоставляет каждый GPU с правильной сетевой картой.
• Поддержка плоскостей данных на базе UCX, а также NCCL.
• Достижение примерно 99% нативной пропускной способности шины в бенчмарках NCCL all-reduce.

Именно это позволило нам перевести Modal Clusters в стадию общедоступности с многоузловыми заданиями, работающими в gVisor.

Снимки: восстановление состояния GPU за секунды

Снимки памяти Modal используют механизм checkpoint/restore в gVisor для захвата контейнера после загрузки модели, а затем восстанавливают это состояние на новых машинах за считанные секунды. Ежедневно из снимков восстанавливается около 670 тысяч контейнеров gVisor.

Производительность файловой системы и памяти

Производительность ввода-вывода долгое время была проблемой в gVisor. Рабочие нагрузки ИИ часто обращаются к этим путям, поэтому большая часть нашей недавней работы в апстриме была посвящена именно этому. Вот несколько примеров:

• PyTorch DataLoader через общую память: переработка огромных страниц в аллокаторе памяти gVisor позволила увеличить скорость прохождения пакетов в одном из тестов с 2,9 до 22 ГБ/с (примерно в 8 раз), сохранив при этом неизменным объем используемой памяти.
• Файловые системы: мы оптимизировали tmpfs в gVisor, что ускорило работу SQLite в 2,7 раза. Мы также представили ряд оптимизаций для overlayfs, которые сокращают копирование данных файлов при выполнении стандартных операций.

Больше программ «из коробки»

gVisor сам реализует интерфейс Linux, поэтому каждое приложение, работающее в Modal, также является проверкой полноты этой реализации. Наши клиенты используют огромное разнообразие программного обеспечения. Когда они приносят что-то новое, мы проверяем, хорошо ли оно работает в gVisor, и отправляем изменения в апстрим. Вот некоторые недавние дополнения:

• Базы данных: ClickHouse работает в «песочницах» gVisor, включая атомарную замену файлов, которую он использует для управления своими таблицами.
• JavaScript: приложения на Bun, такие как агент для написания кода OpenCode, работают со снимками памяти Modal.
• Настольные приложения: приложения, созданные на Qt 5.15, работают в gVisor.
• Облачное хранилище: Mountpoint for Amazon S3 может монтировать бакет S3 как папку внутри «песочницы» и записывать в него данные большими быстрыми блоками.
• Повседневные инструменты: top и htop показывают реальное использование CPU внутри «песочницы».
• CPU-инференс: математические библиотеки, такие как oneDNN, которые PyTorch использует на CPU, могут задействовать быстрые инструкции процессора bfloat16 и int8.
• Большие кодовые базы: «песочницы» остаются легковесными, даже когда инструменты сканируют миллионы файлов, что постоянно делают агенты для написания кода.

Наше видение gVisor

Мы считаем, что gVisor должен стать стандартным способом запуска недоверенного кода в Linux и, в особенности, стандартным уровнем изоляции для вычислений в области ИИ. Вот что для этого нужно:

• Безопасность по умолчанию и достаточная скорость, чтобы о ней забыть. Изоляция не должна быть налогом, который вы противопоставляете производительности. Это означает ввод-вывод, близкий к нативному, и перенос работы по повышению производительности, которую провайдеры вроде нас выполняли в собственных форках, в апстрим.
• Каждый ускоритель — с первого дня. Новые драйверы NVIDIA и GPU должны работать в gVisor в день их выпуска. Мы хотим такой же первоклассной поддержки для TPU и GPU AMD.
• Плотность «песочниц». Используйте эффективность ресурсов gVisor для создания очень экономичных «песочниц», способных справляться с широким спектром агентных задач.
• Переносимое состояние. Делайте снимки чего угодно (CPU, один GPU, много GPU) и восстанавливайте их где угодно.
• Открытость и мультиплатформенность. Нейтральное управление делает безопасным инвестирование для многих компаний, и именно эти инвестиции позволяют реализовать остальную часть этого списка.

Что дальше

Мы хотим, чтобы gVisor стал самым безопасным способом запуска программ Linux, а также решением многих проблем производительности, затрагивающих индустрию ИИ сегодня. Вот некоторые проекты, над которыми мы работаем:

• Снимки памяти для нескольких GPU. Сегодня Modal может делать снимки программ, работающих на одном GPU. Мы расширяем эту возможность на модели, охватывающие несколько GPU. В ранних тестах большие модели восстанавливаются в несколько раз быстрее, чем при обычном «холодном» запуске. Скоро это появится в Modal как экспериментальная функция.
• GPUDirect Storage. GPU могут считывать данные напрямую из быстрого хранилища в свою собственную память, минуя обычный обход через CPU. Это самый быстрый способ загрузить веса большой модели в GPU, и мы внедряем это в gVisor.
• Инференс-серверы, которые запускаются за секунды. Большая часть времени запуска инференс-сервера уходит на загрузку весов модели и прогрев. Мы хотим прогреть сервер один раз, отложить его веса и сделать небольшой снимок всего остального для нескольких GPU, включая скомпилированные ядра, графы CUDA и память KV-кэша. Новый реплика восстанавливает этот снимок и передает веса напрямую в память GPU из хранилища через GPUDirect Storage или с других GPU через RDMA, поэтому даже очень большие модели могут начать обслуживать запросы менее чем за минуту.
• Облачный гейминг и удаленные рабочие столы. Мы хотим, чтобы «песочница» с GPU могла запускать полноценный рабочий стол: сервер отображения на драйвере NVIDIA, игры и 3D-приложения, рисующие на нем, а также захват экрана на GPU и трансляцию игроку по сети. Это включает в себя игры для Windows, работающие через Proton от Steam.
• Более мелкие сегменты GPU. Поддержка MIG и vGPU в nvproxy.
• Поддержка GPU AMD и Grace Blackwell.
• Оптимизации для gVisor на основе модулей ядра.

Попробуйте сами!

• Попробуйте: Modal Functions и Modal Sandbox (с runtime="gvisor") работают на gVisor.
• Внесите вклад: github.com/google/gvisor
• Присоединяйтесь к нам: мы нанимаем инженеров, которые хотят работать над ядрами, средами выполнения и GPU.

Благодарности

Спасибо команде gVisor в Google за создание продукта, достойного передачи в open source, и за тяжелую работу по его качественной передаче. Особая благодарность Этьену Перо, Цзин Чену, Стиву Силве, Джаго Маклеоду и Дрю Брэдстоку за продвижение передачи проекта в CNCF.