Genesi Mesh

Genesi Mesh lets several machines contribute their GPUs to a single inference run. A model that fits on none of them individually still runs accelerated, because the layers are spread across all of them.

Your old PC becomes extra VRAM.

Two ways to share, and they are not interchangeable

Mesh can lend a machine's GPU in two different ways. Picking the wrong one is the most expensive mistake available here, so decide this first.

Serving is also the path that needs no configuration on the client: the mesh advertises which peers are serving Turbo, so a machine with no usable GPU picks one up automatically instead of quietly building a CPU server next to an idle remote GPU. genesi-mesh peers tags such a peer [turbo: <model>], naming the model it is actually serving.

How it works

llama.cpp can treat a remote GPU as an extra device through its RPC backend. One machine holds the model and serves the API; the others simply lend their GPUs:

machine A (client)                      machine B (worker)
llama-server --rpc B:50052   ───────►   rpc-server -H 0.0.0.0 -p 50052
  holds the model, serves :11435          contributes its GPU

What llama.cpp does not do is find the machines, prove they are yours, keep the worker alive, or decide whether pooling is even a good idea. That is what Genesi Mesh adds. The daemon is never in the data path, so restarting it cannot interrupt a running generation.

Read this before you start

Practical expectations:

MoE models suit pooling best (qwen3:30b-a3b, gpt-oss:20b): only a few experts fire per token, so far less data crosses the wire than for a dense model of the same size.

Integrated graphics

An integrated GPU has no memory of its own — what it calls VRAM is a slice of system RAM, backed by bandwidth shared with the CPU (~50–90 GB/s) rather than a discrete card's 200+ GB/s. And llama.cpp splits layers by reported capacity, not by speed, so an integrated peer takes a full share of the work and then makes every token wait for it.

So Mesh does not pool integrated GPUs by default. They appear in genesi-mesh peers tagged [integrated] and are skipped, with plan naming them. Override with pool_integrated = on in mesh.conf if you want to measure it yourself.

Requirements

Every machine needs a llama.cpp built with the RPC backend:

sudo pacman -Syu genesi-llama-cpp

sudo pacman -Syu genesi-llama-cpp-cuda

Check everything at once — this tells you exactly what is missing and how to fix it, so run it first whenever something is not working:

genesi-mesh doctor

The machines do not need the same backend. Pick per machine: CUDA on an NVIDIA worker (faster, and that machine does the compute), Vulkan everywhere else. The RPC protocol is backend-agnostic — each worker executes on whatever backend its own rpc-server was built with.

Verifying with one machine

You do not need a second computer to verify the mesh works. selftest starts a real rpc-server, connects a real client to it over loopback, and reports what llama.cpp itself sees. No mocks.

sudo systemctl enable --now genesi-meshd
genesi-mesh selftest

A pass means this machine can serve its GPU to a mesh. The only thing a second machine adds is the network hop.

Pooling across two or more machines

This is what Mesh is built for.

sudo systemctl enable --now genesi-meshd

sudo genesi-mesh init

sudo genesi-mesh join <secret>

sudo genesi-mesh worker on

genesi-mesh peers

Peers (1)
  old-pc             192.168.1.7     Vulkan    6871 free of 8192 MiB   worker [turbo: llama3.2:3b]

genesi-ai-turbo serve

[mesh] 11.0 GB model does not fit locally (6.8 GB) but fits across 1 machine(s) (13.6 GB pooled)
[mesh] pooling across: 192.168.1.7:50052

Will a given model pool?

Ask before downloading anything. Accepts a .gguf path or a plain size in GB:

genesi-mesh plan qwen3-30b-a3b-Q4_K_M.gguf
genesi-mesh plan 17

Model 17.0 GB
  local VRAM budget:  6.8 GB
  pooled across mesh: 13.6 GB

  → run locally
    too big even pooled (17.0 GB needed, 13.6 GB across the mesh)

Over the internet

The correct approach is a private network overlay, which makes the remote machine behave as if it were on your LAN.

sudo pacman -S tailscale
sudo systemctl enable --now tailscaled
sudo tailscale up

sudo genesi-mesh peer 100.x.y.z

Do not do this for the common case

If what you actually want is "use my powerful desktop from my laptop", do not pool. Pooling sends activations across the link on every token, which over a home connection is far slower than running on the laptop's own CPU.

Instead, run Genesi Turbo on the desktop and point the laptop at its OpenAI-compatible endpoint over Tailscale:

# on the laptop — only the text crosses the network, so it stays fast
curl http://100.x.y.z:11435/v1/models

Genesi Code and any other OpenAI-compatible client can use that URL directly. Remote pooling is only worth it for a model that genuinely cannot run at all on either machine alone.

Security

rpc-server performs no authentication and no validation of what it receives. Genesi Mesh is built around that fact:

• Worker mode is off by default. A machine never offers its GPU on its own.
• rpc_bind defaults to 127.0.0.1. genesi-mesh worker on moves it to 0.0.0.0 and warns while doing it; the daemon repeats the warning at every start.
• Discovery beacons are HMAC-SHA256 signed with your mesh secret, and carry a timestamp checked against a ±180 s window, so only your machines see each other and a captured beacon cannot resurrect a machine that is gone.

That authenticates discovery, not the RPC port itself. It is not a substitute for running this on a network you control.

Choosing where the AI runs

serve and use are mirrors of each other:

genesi-mesh use              # what is selected, and what is actually in effect
sudo genesi-mesh use auto    # pick the best available Turbo (default)
sudo genesi-mesh use local   # always run here, even if a peer is serving
sudo genesi-mesh use old-pc  # pin one particular machine

Automatic is the right default, not the right only behaviour. Wanting the chat on the machine in front of you, or pinned to one specific box, is a legitimate preference rather than a misconfiguration — and silently routing someone elsewhere is the kind of helpfulness they cannot see well enough to argue with.

A pinned peer that stops serving falls back to this machine, not to some other peer: you picked that one on purpose. It switches back on its own when the peer returns. genesi-mesh use with no argument shows both the selection and what is currently in effect, because those differ exactly when it matters.

Command reference

Configuration

/etc/genesi-mesh/mesh.conf. Apply changes with sudo systemctl reload genesi-meshd — the CLI does this for you.

Turbo environment overrides

Troubleshooting

Peers do not appear. Check genesi-mesh doctor on both machines. The usual causes are a missing or mismatched secret, a firewall blocking UDP 47100, the daemon not running, or the two machines being on different subnets (in which case register it with genesi-mesh peer <addr>).

rpc-server is missing. Your llama.cpp was built without the RPC backend. Install genesi-llama-cpp r0-4+ or genesi-llama-cpp-cuda r0-2+.

Turbo never mentions the mesh. That is usually correct behaviour — the model fits locally. Confirm with genesi-mesh plan <model>.

It is slower than running locally. Then the model probably fits locally and something forced the mesh (a GENESI_MESH_ENDPOINTS override). Unset it and let Turbo decide.