Общая видеокарта в команде через P2P и Docker: GPU-Share

Видеокарта у одного, нужна троим

В студии у дизайнера стоит компьютер с RTX, у двух коллег обычные ноутбуки. Генерация картинок, дообучение небольшой модели, ночной рендер просятся на эту единственную карту. Облачные GPU стоят денег, а исходники и клиентские материалы в чужое облако отправлять не хочется. Обычный выход: общий доступ по SSH или VPN. Сразу возникает вопрос, что именно коллега сможет сделать на этой машине.

GPU-Share предлагает другую схему: коллега запускает задачу командой, она выполняется в контейнере на машине с картой, логи возвращаются обратно. Про выбор самой карты я писал в статье про GPU для локального ИИ. Если нужен просто общий адрес языковой модели в офисе, посмотрите разбор NVIDIA PAIR: он раскидывает запросы между компьютерами и контейнеров не запускает.

Что за проект и что я проверил

Проверял 21.10.2026 по GitHub и исходникам. Репозиторий arjun988/GPU-Share создан 24.08.2026, в нём 30 звёзд, 5 форков и 22 коммита, все от одного человека, Arjun Shukla. Последний коммит от 14.09.2026, это 37 дней назад. Релизов и тегов нет, репозиторий не архивирован. В README стоит статус alpha 0.1, флаги и протокол могут измениться.

Названия расходятся. Репозиторий называется GPU-Share, а README, описание и команда называются GPUMesh. В Cargo.toml указан адрес github.com/gpumesh/gpumesh, он отвечает 404, домен установщика install.gpumesh.dev у меня не открылся. Ставить придётся из исходников этого репозитория: нужны Rust и Git, команда cargo install --path crates/gpumesh-cli. Провайдеру нужны видеокарта NVIDIA, Docker и NVIDIA Container Toolkit. Основная платформа Linux, Windows и WSL по README работают для многих сценариев, macOS карты NVIDIA не отдаёт. CI гоняет сборку и тесты только на Ubuntu.

Доверие и сеть: как машины находят друг друга

Команда init создаёт на машине ключи Ed25519. Команда share печатает код сопряжения: подписанный набор из открытого ключа, имени и адресов, он действует час. Сопряжение взаимное: консьюмер вводит код провайдера, а провайдер вводит код консьюмера. Введённый код сразу вносит машину в список разрешённых, остальным вход закрыт, deny отзывает доступ.

Транспорт QUIC, по умолчанию UDP 47000. В коде я заметил деталь: клиент принимает любой TLS-сертификат, а подлинность держится на подписанном приветствии со сроком жизни пять минут. Привязки подписи к конкретному соединению я не нашёл. Это моё чтение кода, подтверждённой уязвимостью оно не является, но в сетях, где путь вы не контролируете, я бы дождался аудита.

Пробивания NAT в проекте нет: ни STUN, ни hole punching в коде не нашлось. Код сопряжения несёт локальный адрес машины, так что простой случай это одна сеть. Для разных сетей два варианта: пробросить UDP 47000 или поднять gpumesh-relay на сервере с открытым UDP 4799 и задать переменную GPUMESH_RELAY. Ретранслятор принимает и пересылает сообщения протокола, а сквозного шифрования поверх него я не увидел, поэтому ретранслятор должен быть только вашим. Сеть между филиалами с настоящим обходом NAT разобрана в статье про EasyTier.

Что может чужой контейнер на вашей машине

По коду провайдера задача запускается как docker run --rm --gpus device=0 с папкой задачи внутри. Всегда берётся первая карта. По умолчанию включены: сброс всех capabilities, no-new-privileges, файловая система только для чтения, /tmp в памяти без права запуска файлов. Лимиты по умолчанию: одна задача одновременно, час работы, 4 ядра, 8 ГБ памяти. Разрешены образы с префиксами nvidia/cuda, python, pytorch, tensorflow, nvcr.io. Оболочку хоста удалённый пользователь не получает, exec открывает оболочку внутри контейнера.

Теперь о том, чего нет. Сеть контейнера bridge, поэтому выход в интернет открыт: задача может отправить данные наружу или скачать что угодно, например майнер. Лимит диска max_disk_mb есть в настройках, но в команде запуска я его не нашёл. Лимит видеопамяти работает как проверка перед стартом, ограничения во время работы нет. Закрытый ключ узла лежит в identity.json открытым текстом, права 600 выставляются только на Unix. Отдельного журнала «кто что запускал» в README нет. Каталог логов в ~/.gpumesh существует, что в нём пишется, я не проверял.

Что важно учесть

Один автор, два месяца, alpha, нет релизов, тесты в просмотренных мной файлах встречаются единицами, README и интерфейс на английском. Независимого аудита безопасности я не нашёл.

Панель управления (сервис gpumesh-control) по умолчанию слушает 0.0.0.0:8080, а токен GPUMESH_API_TOKEN необязателен. Без токена маршруты сопряжения и запуска открыты всем в сети, а сопряжение добавляет машину в список разрешённых. Это вывод из кода, на практике я не проверял. Запускайте панель с токеном и адресом 127.0.0.1.

Контейнер с GPU работает через драйвер хоста. У NVIDIA Container Toolkit была критическая уязвимость CVE-2025-23266 (затронуты версии до 1.17.7 включительно, исправление в 1.17.8 по сообщениям CERT, это вторичный источник). Обновляйте набор и драйвер.

Проект рассчитан только на людей, которым вы доверяете. Публичный реестр с поиском в проекте есть, но открывать свою карту посторонним через него не стоит.

Что можно сделать уже сейчас

Сначала решите, нужен ли вам запуск произвольных задач. Если коллегам нужна одна языковая модель, проще общий сервер, как в статье про vLLM и Ollama.

Возьмите две свободные машины без рабочих данных и пройдите путь из README: init, share, взаимный pair, run --peer с nvidia-smi.

Для выделенного хоста продумайте правила: отдельная машина без личных данных, закрытый исходящий трафик Docker-сети, образы только из вашего списка, токен для панели, актуальный Toolkit. Уходит сотрудник, вы выполняете deny в тот же день.

Если нужно, я разверну такой общий GPU-хост и пропишу эти правила в рамках работы с ИТ-инфраструктурой.

Частые вопросы

Можно ли подключить чужую видеокарту как локальную в PyTorch?

README прямо говорит, что нет: процесс выполняется на машине провайдера. Режим CUDA-remoting помечен как эксперимент для локальной сети и не заменяет драйвер для PyTorch.

Нужен ли облачный сервис?

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

Подойдёт ли это для данных клиентов?

Я бы не стал без закрытого исходящего трафика, отдельного хоста и своего ретранслятора. Проект пока не проходил независимую проверку.

Коротко о главном

GPU-Share под Apache 2.0 даёт сопряжённым машинам запускать Docker-задачи на чужой видеокарте по QUIC, без SSH и облака. Список разрешённых закрыт по умолчанию, контейнер урезан по правам. Выход в сеть из контейнера открыт, проект молодой, аудита нет.

Если хотите попробовать общий GPU-хост в команде и посмотреть, где он подойдёт, напишите мне в Telegram кодовое слово «МОЩНОСТЬ».