Train across Macs and CUDA devices.

Research. Peer transport is published. Weight-sharing and quorum-gated synchronization paths are implemented; end-to-end training across Mac and CUDA members remains under development.

• Memory-weighted scheduling — the Apple-silicon scheduler accounts for each node’s unified-memory capacity. Extending placement across Mac and CUDA backends is part of the mixed-hardware scope.
• Content-addressed weight sharing — model weights move peer-to-peer over LAN, Apple AWDL, and a global iroh mesh, verified against Hugging Face SHA-256 digests rather than trusting any peer.
• iroh transport — QUIC links and signed gossip via mlx-go-iroh. LAN and gossip by default; pkarr/relay global discovery is opt-in.
• Quorum-gated sync — DiLoCo-style updates apply only when a quorum of distinct peers publishes the same signed digest. Fail-closed: the live datapath stays off unless explicitly enabled.

Research. mlx-go-iroh is published and tagged; weight sharing and a quorum-gated DiLoCo sync loop run on top of it. The next validation gates are a complete multi-node training run, cross-device latency measurement, and heterogeneous-compute consistency.

mlx-go runs the local computation; mlx-mesh coordinates the machines and moves model state between them. The intended use includes models that exceed one machine’s capacity and training runs that combine local development with CUDA compute under the operator’s control. cove can isolate individual workloads when they need a disposable Mac.

Macs provide local development, evaluation, and supported training workloads. CUDA hosts provide additional compute and memory for larger jobs. A cohort can contain either backend or both; the scope includes distributing work across them.

• Workload placement. Assign supported work according to backend, available memory, and the run’s partition or update rule.
• Model-state transfer. Move weights, adapters, and training state with explicit identity, format, and integrity checks.
• Cross-device synchronization. Declare precision and numerical tolerances, then compare updates and model quality across the participating backends.
• Recovery. Define how a run checkpoints, resumes, and handles a member leaving. Retained state and membership changes belong to the run record.

These are the mixed-hardware integration goals. Existing peer and runtime components are described separately from the complete training workflow.

mlx-go provides the array runtime, including selected Linux CUDA workflows. lib/nvidia provides direct CUDA APIs and profiling tools. Your Mac, borrowing the cluster describes the local-to-CUDA workflow.

The unit of work is a cohort of machines. Each member contributes local computation and exchanges model state through the peer transport. The design accounts for different memory capacities, verifies transferred weights, and gates synchronization on agreement among distinct peers.

mlx-go-iroh supplies discovery, signed gossip, and content-addressed transfers. Quorum-gated DiLoCo synchronization and peer-to-peer weight sharing use that transport. The architecture extends beyond a fixed pair of hosts.

A complete run needs a declared cohort size, checkpoint, topology, and update rule, with records of round latency, bytes transferred per peer, and model quality. A mixed Mac/CUDA run also needs cross-backend output and update comparisons, declared precision tolerances, and explicit checks for a member leaving mid-round. These are the next system-level validation gates.

The initial adapter-exchange experiment remains a component record: it checks transfer and deterministic merge in a two-node configuration. The measurement ledger records the scope of each result.