by Chris DePuy / September 19, 2026
On September 17, the community project pd-bridge published the result its earlier one-way design had been pointed at: a working closed loop in which two NVIDIA DGX Sparks prefill a 284-billion-parameter DeepSeek model, two Apple Mac Studios receive and serve the resulting attention state, and a multi-turn conversation runs turn after turn across all four machines. The project first drew attention on September 8, when it showed a Mac Studio decoding an NVIDIA-prefilled prompt at up to 3.7x the speed of the Mac alone. What makes the September 17 round more consequential than the first is that the return leg now rides RDMA in both directions, over a driver no chip vendor ships. I think the useful way to read the week is as a demonstration that the prefill/decode split has left the single-vendor data center and arrived, working and measured, at desk scale.
The Bridge Design: the Prefill Box Writes the Decoder’s Cache for It
The hard problem in splitting a request across CUDA and Metal is that the two engines do not agree on what a key-value cache is. The project’s write-up declines to translate between formats altogether: the prefill side recomputes, on its own GPUs, the finished cache blocks the Metal-side engine would have produced for itself, using the decoder’s projection and pooling weights, and deposits them directly into the decoder’s own prefix-cache store through that engine’s standard block writer. The Metal engine sees an ordinary cache hit and never learns a second machine was involved.
The published evidence for that claim is unusually concrete for a basement project. The repository’s validation table reports 313 of 313 cache arrays rebuilt bit-exact against a full native forward pass, 11 of 11 bridge-written blocks identical to the ones the decoder writes itself, and 52 of 52 in-container self-tests. The payload runs to roughly 10 kilobytes of unified memory per token, the README’s own worked example putting an 81K-token prompt at 0.80 GB transferred in 1.08 seconds. The served window has meanwhile grown from 262,144 to 2,097,152 tokens, and the cold-load ladder reports a 700,630-token prompt completing “in 11 minutes 26 seconds” at 1,117 tok/s of prefill.
| Cold prompt | Mac Studio alone | Sparks prefill, Mac decode | Ratio | Source |
| ~25K tokens | 42.6 s | 28.2 s | 1.5x | pd-bridge README |
| ~82K tokens | 205.8 s | 72.9 s | 2.8x | pd-bridge README |
| ~105K tokens | 245.6 s | 75.5 s | 3.3x | pd-bridge README |
| ~241K tokens | 732.3 s | 200.3 s | 3.7x | pd-bridge README |
The ratio in the same table grows with the prompt because the Mac’s cost is dominated by re-reading the conversation history on every turn, and the only way to stop paying for it is to have somebody else compute it once.
The Transport: a macOS RDMA Driver Apple Does Not Ship
None of the September 17 numbers exist without MCDMA, the native macOS RoCE driver Ash Hart built, described in his September 14 write-up. macOS will enumerate the Mellanox adapter as an Ethernet device but offers it no verbs path at all; Hart’s driver and userspace provider post byte-verified READ and WRITE operations in both directions, with all 24 GPU-buffer transfer tests passing when a Metal kernel fills the source and a CUDA kernel checks the destination words. Latency medians, taken over registered host buffers with one operation outstanding at a time, run 7.625 microseconds for a Mac-initiated WRITE and 3.680 microseconds for a Spark-initiated WRITE, with the caveat Hart states himself: the headline table was pooled on driver 0.1.17 with a keepalive workload holding the Studio’s GPU active, and the current 0.1.18 development release carries no matched performance comparison against it. The 0.1.18 validation report adds sustained rates of about 50.6 Gbit/s inbound to the Studio and 29.4 Gbit/s outbound, and the driver’s own readout attributes the ceiling to the Thunderbolt 5 PCIe tunnel at Gen4 x4, not to the 100 GbE link that was validated September 15. The baseline the driver has been improving from is on the record: the August 18 launch post reported 939 MB/s on a single link and 1.80 GB/s with the Mac writing to both Sparks concurrently, at a 24 µs round-trip and 41k messages per second on small messages, every byte delivery verified.
The Loop: Four Machines, Two Fabrics, One Conversation
The September 17 configuration, documented in the project’s fabric layer, assigns each machine the one job its silicon is good at. The Spark pair runs prefill on Blackwell tensor cores at about 1,100 tok/s against roughly 400 on a Mac Studio. A gateway Studio, the only one with a ConnectX-4 card in a Thunderbolt enclosure, terminates the Sparks’ RoCE traffic on the MikroTik switch and maps the arriving blocks into the Metal engine’s cache format. A second, 512 GB Studio holds the whole conversation’s cache, takes each increment from the gateway over Apple’s own RDMA transport, and turns the reply without re-reading history — its cached-token count stepping 30,720, 47,104, then 61,440 as the conversation grew. The maintainer’s report measured 0.7 seconds per reply at a 31K-token history against a flat 31 seconds for the same Studio re-prefilling alone, rising to 7.4 seconds at 47K and 10.5 at 63K — up to a 4.2x gain, growing with context. Over four turns, the cache-loaded library machine answered in 7 to 10 seconds against 30 on one Studio and 18 on the Sparks alone, and the project’s notes put the transport itself at 0.3 to 0.5 seconds Spark to gateway and about 0.05 seconds gateway to library — comfortably under a tenth of the reply time.
Boundary Conditions the Repositories Make Explicit
The documentation is candid about its own edges, and they are worth taking seriously. The bridge serves one model, DeepSeek-V4-Flash, because the pooling mathematics it reproduces are specific to that architecture’s hybrid attention; the stack is pinned to oMLX 0.6.4 and vLLM 0.21.1rc1 and reaches into both engines’ internals through monkey patches that the status section says should break when either project moves. The maintainers note plainly that no Mac-alone control was run beyond the 241K table, so the longer ladder rows report what the bridge does rather than a claimed speedup. The capture consumes about 11.8 kilobytes per token on the head node until the request completes, and past roughly 772,000 tokens it crosses a 5 GB free-memory floor and seals a valid contiguous prefix instead of the whole prompt — a 1,006,172-token run completed only 70 percent bridged, the decoder filling the remainder natively. And the judged quality evaluation behind the claim that bridged output matches native is five questions against a single document; the two legs do not even share precision, prefilling in FP8 and decoding in MXFP4, so faithfulness was checked, not proven.
What It Means
The hardware logic behind all of it is a bandwidth asymmetry: Hart’s write-up cites NVIDIA’s own 273 GB/s figure for the Spark against Apple’s stated 800 GB/s-plus for the M3 Ultra, and roughly £800 of networking hardware is what stands between those pools. Prefill/decode separation itself is not new — NVIDIA Dynamo has run the split inside the data center since its 2025 release — but it has been sold as a rack-scale feature of one vendor’s fabric. What this week adds is a measured, open, cross-vendor instance at desk scale — one whose own Credits section positions it against the EXO Labs Spark-to-Studio prefill/decode result as its reference point, and whose maintainers describe the build as “a basement, not a lab” with nothing being sold — with the transferable idea stated plainly in the repository: “when two engines cannot share a cache format, compute the consumer’s finished cache on the producer.” For operators, the near-term read is that the sizing unit for desk-side AI is no longer the box but the phase — a fleet that pairs compute-dense nodes for ingestion with bandwidth-dense nodes for generation, joined by RDMA at sub-tens-of-microsecond latency, captures both ends of the curve without either vendor’s permission. The number that decides whether such a split pays is the per-token capture cost on the prefill side; at 11.8 KB/token, the floor arrives long before the window does. As firms such as 650 Group have been tracking in their AI infrastructure research, the constraint on this class of deployment has moved from model fit to fabric economics, and the community is now instrumenting that frontier faster than the vendors are productizing it.
A separate batch of .md notes is pending a dedicated post: GLM-5.3-Flash’s EXL3 4-bit two-Spark recipe with near-lossless 4 bpw, carrying a measured 1,554 tok/s prefill and 67.9 tok/s structured decode; the GLM-5.3-Flash full-743B-on-four-Sparks cluster alongside the agent shared-memory and second-brain notes and the Hermes agent-platform and tooling-speed updates; the JSPARK3 “Tempo” three-Spark vLLM-versus-EXL3 comparison against the same DeepSeek model and its September 13 write-up recording a 146.12 tok/s six-stream aggregate and an 82.0 tok/s three-agent repeat round; the second round of single-Spark Qwen3.8-27B recipe speedups with its top-ranked community agentic-quant benchmark, and the newest single-Spark Qwen3.8-Flash-Next builds including a 66.17 tok/s single-stream profile; the two-Spark GLM-5.3-Flash EXL3 kit’s v1.5.0 and six-fix maintenance rounds, its owner note that concurrent streams now run “much better”, its September 17 two-Spark report of 81 tok/s across two concurrent streams, and its eight-change sibling round whose opt-in scheduler cuts peak prompt wait from about 120 seconds to 15; the heterogeneous prefill-and-decode split’s second instalment with its doubled two-million-token window and published cold-load ladder; the September 14 three-to-four-Spark vLLM speed-run update reporting about 190 tok/s across six streams with a 1M-context proof; the two-Spark DeepSeek-V4.1-Flash EXL3 2.9 bpw build whose September 16 update records 42 tok/s single-stream prose against the prior 32 and 63.7 tok/s across two concurrent streams against 42.5, with the September 15 README documenting the ~1,029 tok/s prefill table and the ~2.1 GiB long-prefill floor, alongside the operators reporting frontier-class local service at a subscription-substitution price point; the two-Spark GLM-5.3-Flash EXL3 maturation round whose September 16 field note reports a 0.986 prefix-cache hit rate at 262K and warm time-to-first-token of 3 s against 192 s cold alongside an 88/100 independent tool-calling score; the September 16 single-Spark 2-bit GLM decode round recording 15.96 to 28.95 tok/s, a 1.81x gain with math at +114% and structured at +97%; the Mac-side serving pair covering the September 15 MLX-Serve 26.9.3 release and the September 16 MLX.fast and CUDA.fast correction reporting 80.6 and 43.5 tok/s after a display bug; the September 18 two-Spark GLM-5.3-Flash NVFP4 overnight speed run reporting cold prefill +26–36%, repeat-prompt time-to-first-token 21 s to 6 s, a KV pool +33% at 714K tokens and a 41-to-16-minute boot fix; the September 17 twelve-PR maintenance round on the two-Spark DeepSeek-V4-Flash recipe covering tool-call truncation crashes and status checks that report failures; and the September 17 and 18 Jev decision-model cluster spanning the launch explainer, the twenty-tip usage guide and the five-experiments DGX Spark fleet plan.