Mesh LLM: распределённый инференс поверх iroh

Mesh LLM объединяет GPU и память на любых имеющихся машинах и отдаёт всё это как единый OpenAI-совместимый endpoint по адресу localhost:9337/v1. Вы запускаете один узел, добавляете другие по желанию, а mesh-сеть сама решает, где выполнять каждый запрос. Проект находится в той же плоскости, что и titit-local-ai и lucumr-local-models - в пользу запуска моделей на собственном железе вместо аренды API с поминутной тарификацией, - но решает другую половину задачи. Те материалы посвящены локальному инференсу на одной машине; Mesh LLM заставляет несколько машин работать как единое целое, позволяя запускать модели, которые не поместились бы ни на одном отдельном компьютере.

Запрос обрабатывается одним из трёх способов: выполняется локально на GPU текущей машины, перенаправляется пиру, у которого модель уже загружена в память, либо слишком большая модель делится между несколькими машинами в виде пайплайна. Клиент не видит, какой путь был выбран, и просто обращается к localhost.

Разделение модели между узлами

Режим разделения называется Skippy. Модель разбивается по диапазонам слоёв на стадии - слои 0-15 на одном узле, 16-31 на следующем и так далее, - а активации передаются по пайплайну от стадии к стадии. Несколько скромных машин запускают модель, которая не влезла бы ни на одну из них по отдельности. Skippy представляет собой набор патчей поверх llama.cpp, залезающий во внутренности движка, чтобы извлекать активации и фильтровать тензоры во время загрузки. Заранее рассчитанные разбиения для популярных моделей публикуются в организации на HuggingFace: отдельная задача нарезает модели по слоям и выкладывает части.

Вся схема работает благодаря тому, что именно передаётся по сети. Между стадиями перемещаются только небольшие векторы активаций - несколько килобайтов на токен, а не гигабайты весов. Сами веса постоянно находятся в VRAM каждого узла. Из-за этого схема упирается в задержку (latency-bound), а не в пропускную способность (throughput-bound), и способна работать быстрее потокового чтения весов из локальной RAM или с диска, где приходится заново считывать гигабайты на каждый токен из медленного хранилища. Плата за это - один сетевой round-trip на каждую стадию пайплайна для каждого токена: при разбиении на N узлов вы платите (N-1) сетевыми задержками за каждый сгенерированный токен. В быстрой локальной сети с субмиллисекундными задержками потолок производительности высок; в открытом интернете он падает, поэтому генерация токенов рассчитана на локальные или корпоративные сети. С prefill ситуация иная: задержка на токен там не накапливается, поэтому распределённый prefill выигрывает даже на медленных каналах.

Заявленные цифры скромные, но реальные. Для Qwen 235B-A22B указано 16 tok/s на двух узлах; один из контрибьюторов получил ~10 tok/s на GLM 5.2 на двух Mac Studio через обычный 1GbE с собственной Q2-квантизацией. Если один узел отваливается прямо во время инференса, топология пересчитывается, и запрос повторяется на новом разбиении.

Почему iroh

Каждый узел - как сервер, так и клиент - поднимает endpoint iroh, который служит его идентификатором (открытым ключом) и единственной сетевой поверхностью. Центрального сервера нет. iroh выполняет hole-punching, пробивает NAT и при необходимости переключается на relay, открывая прямое аутентифицированное QUIC-соединение между любыми двумя узлами независимо от их расположения. В качестве резервного пути Mesh LLM держит два relay-сервера iroh в разных регионах. Поскольку узлы адресуются по открытому ключу, а не по IP, "отправить запрос пиру" и "передать активации на следующую стадию" превращаются в тот же примитив, что и "обратиться к localhost", просто с другим ID endpoint'а. Это та же независимая от местоположения адресация по ключам, что лежит в основе yggdrasil-network, и то же свойство "транспортное имя, а не сервер", которое в stateful-agent-routing названо недостающим звеном для адресации конкретного долгоживущего процесса.

В протоколе используются три ALPN для QUIC: mesh-llm/1 для основной mesh-сети (gossip, маршрутизация, HTTP-туннели, каналы плагинов), mesh-llm-control/1 для плоскости управления владельца и skippy-stage/2 для чувствительной к задержкам передачи активаций. Внутри основного соединения всё передаётся в виде двунаправленных потоков с одним лидирующим байтом: gossip (0x01), HTTP-туннели (0x04), запросы маршрутов (0x05), события отключения и выхода пиров, RPC плагинов, прямые запросы - всё демультиплексируется по этому первому байту. iroh предоставляет защищённый транспорт, а Mesh LLM строит поверх собственный gossip-слой, чтобы контролировать допуск участников, совместимость версий и доверие к пирам. Сам рантайм построен на плагинах: плагины декларируют возможности в манифесте и предоставляют их через MCP, HTTP, инференс и mesh-события.

Нерешённые вопросы

Шифрование работает только при передаче (in-transit). Подключение по ключам в iroh обеспечивает аутентифицированный и зашифрованный QUIC между endpoint'ами, поэтому перехватить трафик нельзя, но это не сквозное (end-to-end) и не внутрипроцессное шифрование: тот, кто исполняет инференс, видит исходный промпт и ответ открытым текстом. В сети, разделяемой с друзьями или семьёй, это неудобно для личных задач (например, медицинских вопросов к общей модели), и авторы честно признают, что защита приватности от узлов-участников и защита от отравленных активаций пока не решены. Текущее решение - собирать приватную сеть только из доверенных пиров. Механизмов справедливого распределения ресурсов (fairness) и стимулирования участников для публичной сети тоже пока нет: команда считает их избыточными, пока основной сценарий - собственные приватные сети. Такая позиция в отношении распределённых систем отличается от подхода log-distributed-llms, где многоагентная координация рассматривается как задача византийского консенсуса: Mesh LLM уходит от проблемы византийского доверия за счёт предположения, что сеть находится под вашим полным контролем.

Среди аналогов и предшественников в обсуждениях упоминаются: exo (в документации Mesh LLM есть страница со сравнением), cocompute (ещё один проект на базе iroh) и Colibri. Размер клиента составляет около 18 MB; планируется мобильное приложение на Swift SDK для iroh, а также поддержка ACP для подключения сторонних агентных клиентов.

См. также

• iroh - p2p QUIC-транспорт, на котором всё построено
• titit-local-ai и lucumr-local-models - сценарий локальных моделей, который Mesh LLM масштабирует на несколько машин
• yggdrasil-network - ещё одна сеть с адресацией по открытым ключам и независимостью от топологии
• stateful-agent-routing - примитив "маршрутизируемое имя вместо сервера", роль которого выполняют ID endpoint'ов iroh
• log-distributed-llms - распределённые LLM через призму византийского консенсуса, подход к доверию, которого Mesh LLM избегает