# Backburner: splitting a 27B model across a Mac and an iPhone over USB-C

> Backburner is a Python and llama.cpp fork that lets an iPhone act as a second accelerator for a Mac running Qwen3.8-27B locally, splitting the transformer layers between the two devices and sizing the context from the phone's free memory. This looks at the numbers the project publishes, the hardware it needs, and how far the idea generalises.

**StayLameBro/backburner** — Your iPhone helps your Mac run a 27B model: faster prompt reading and more context over a USB-C cable

- Repository: https://github.com/StayLameBro/backburner
- Stars: 1,168 · Forks: 114
- Language: Python
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/staylamebro-backburner

## Two GPUs, one model, split by layer

The premise is simple to state and unusual in practice. Plug an iPhone into a MacBook with a 10 Gb/s USB-C cable, and the phone helps run Qwen3.8-27B locally.

The mechanism is a layer split. For every batch of prompt tokens, the Mac runs layers 1 to 40 and the iPhone runs layers 41 to 64 on its GPU, pipelined. So the two devices are not doing the same job twice, they are doing different parts of the same forward pass, and the pipeline is what hides the latency of shipping activations over the cable.

The project calls the number of layers the Mac keeps L, and the table of measured splits is presented as starting points rather than tuned optima. The two directions of the split are worth separating, because they are different claims. Below 64k of context the phone runs the upper layers during prefill and the benefit is throughput. Past 64k the phone changes jobs: it computes attention over the older keys it holds, while the Mac runs all 64 layers, so the phone is holding the KV cache rather than doing layer work, and it contributes its GPU during prefill and its GPU plus Neural Engine while writing.

The third claim is the one that matters most for anyone considering this for production, and it is the strictest of the three: the same answers. Greedy output is token-identical with and without the phone, 256 out of 256 tokens at 8k and 32k context, and 32 out of 32 at 140k. The phone is supposed to be a compute accelerator, not a different machine with different answers, and the project treats that as a property it has to prove.

## The prefill numbers, and where the speed comes from

The readme publishes the measurements, and it is careful about whose hardware they are. They were measured on 2026-10-01 with Qwen3.8-27B in IQ4_XS on an M4 Pro with 24 GB and an iPhone 17 Pro Max over USB-C, and the raw rows are in `bench/results/*.jsonl` with the scripts that produced them in `bench/`.

The reading benchmark is the interesting one, because it models an agent session rather than a synthetic prompt. A 2,000-token file or tool result is read into a saved agent session, two reads per depth:

| Context already in the session | Mac alone | Mac + iPhone |
|---|---|---|
| 16k | 109 tok/s (18.8 s) | 157 tok/s (13.1 s) |
| 32k | 101 tok/s (20.3 s) | 130 tok/s (15.8 s) |
| 48k | 87 tok/s (23.5 s) | 113 tok/s (18.1 s) |

That is 29 to 44 percent faster prefill, and the readme states it as 29-44% faster prefill at 16k-48k, with the agent waiting less each time it reads a file or a tool result of more than about 512 tokens.

A cold session tells a different story. With the system prompt, project notes and twelve tools, 26,849 tokens read cold, the first answer takes 245 s on stock llama.cpp, 228 s on this fork with the Mac alone, and 168 s with the phone. After the first time, the SSD prompt cache in `scripts/proxy.py` restores that 27k-token start in 0.3 to 5 s, which is the number that matters for an agent loop.

Past 64k the Mac-alone configuration switches the context to 4-bit, and the phone keeps it at 8-bit, where prefill runs at 67 to 73 tok/s with the iPhone against 59 to 68 tok/s for the Mac alone at 4-bit.

## The fork speeds up the Mac on its own

A reader could easily come away with the wrong conclusion, that the phone is doing all the work. It is not, and the readme says so directly: the engine is a llama.cpp fork with its own Mac kernels, SME2, Metal fusions and DFlash2 speculative decoding, and those speed things up on the Mac alone too, with the numbers kept apart.

The decode table makes the split obvious. At 27-33k context, stock llama.cpp from Homebrew on the Mac gives 11.3 tok/s, this fork with the Mac alone gives 25.0, and this fork with the iPhone gives 25.1. The phone changes nothing about writing speed below 64k. The improvement there is the fork's kernels and its draft model.

Past 64k the phone's GPU and Neural Engine do compute attention over the old keys for every generated token, and the fork with the phone holds 12.6 tok/s at 128k in a greedy 256 token run. The readme is also honest about a missing comparison: Mac-alone writing speed at 128k at 4-bit was not measured on the same day, so there is no head-to-head number for it.

The practical reading is that the phone buys prefill throughput and context headroom, and the fork buys most of the raw speed. A user who only wants speed can take the fork without the phone.

## Context capacity is sized from the phone's free memory

The second headline capability is more context, and the mechanism is a memory calculation rather than a compute one.

A 24 GB Mac fits 64k tokens of 8-bit context next to the model, and the readme says the server sizes the total from the phone's free memory at startup, giving 196k to 229k tokens at 8-bit on an iPhone 17 Pro Max. It has been tested end to end to 128k at 8-bit and 140k at 4-bit. At 128k with the iPhone, 3 of 3 planted facts were recalled at positions 1.5k, 40k and 100k, with the phone thermal state nominal.

The consequence is that capacity is a property of the phone you happen to own, measured at startup and not negotiated with the model. A larger phone is a larger context, which is an unusual and rather charming coupling between hardware and capability.

The repository also supports two phones at once, with the old context shared by both, and the prefill chain still in progress according to the documentation in `docs/TWO-PHONES.md`.

It is worth being clear about which side holds what. Below 64k, the phone runs the upper layers during prefill. Past 64k, the phone holds the oldest keys and computes attention over them, using its GPU during prefill and its GPU plus Neural Engine while writing, and the Mac runs all 64 layers. So the phone is not a spare accelerator for spare capacity, it is the reason the context can be larger than the Mac could hold on its own.

## Tested, reported, and not yet

The compatibility section is the most useful part of the readme for an evaluator, and it makes a distinction worth copying: Tested is the maintainer's own hardware, and Reported links the issue where someone else posted their numbers, which are theirs.

The tested configuration is an M4 Pro Mac with 24 GB and an iPhone 17 Pro Max on the A19 Pro, plus an iPhone 16 Pro Max on the A18 Pro, which gets hot over long prefills, with a note that the vapour-chamber phones, the 17 Pro and 18 Pro, stay cooler. Two iPhones have been tested. Everything else in the table is either reported or not yet.

The reported rows are where the practical limits appear. An 8 GB MacBook Neo with an iPhone Air manages roughly 4 tok/s on short replies and about 2.6 on 512 token replies, dropping further once the Air is at thermal 2, and the Air's USB 2 port costs about 28 ms per token. An M5 iPad Pro with the same Mac gives 8 tok/s decode and about 155 tok/s prefill at 2k. An M1 Max with 64 GB and an M1 iPad Pro shows prefill up 14% with the iPad and 8% with the iPhone, with identical output, plus a few unexplained iPad failures under iPadOS 18. An iPhone 18 Pro Max is reported as faster to 61k than the Mac alone, with 128k runs still being debugged.

The not-yet column is the boundary of the idea. Older or non-Pro iPhones are not supported, because the USB 2 port is too slow for split prefill, and they are planned for roles that need little bandwidth. Another Mac, a Linux PC or a Windows PC as a worker is not yet, with `docs/LINUX.md` for the detail, and Android phones are not yet, with `docs/ANDROID.md`.

The roadmap states the direction plainly: one inference machine out of every device you own, Macs, iPhones, iPads, then Linux and Windows PCs and Android phones, with the goal of running models too big for any one of them, with the same answers a single machine big enough to hold the model would give.

## Conclusion

Backburner fits a Mac owner with an iPhone who wants to run a model larger than the Mac's memory allows, and who cares about prefill latency when an agent reads long files. It does not fit anyone without a Pro iPhone and a 10 Gb/s USB-C cable, and it is the wrong choice if the machine has to run unattended, because the phone becomes a tethered, hot, battery-draining part of the inference stack. Before you build on it, read the compatibility table, because the difference between a tested configuration and a reported one is where the surprises live, and check the release notes, since v0.0.3 was a security fix and v0.0.2 was labelled very early.

## FAQ

### What does Backburner do with an iPhone and a Mac?

It splits the layers of a locally running Qwen3.8-27B between the two devices. Below 64k of context the Mac runs layers 1 to 40 and the iPhone runs 41 to 64 on its GPU, pipelined; past 64k the phone computes attention over the older keys it holds while the Mac runs all 64 layers.

### How much faster is prefill with an iPhone attached?

The project reports 29 to 44 percent faster prefill at 16k to 48k context, measured on 2026-10-01 with a 2,000-token read into a saved agent session, going from 109 to 157 tok/s at 16k and from 87 to 113 tok/s at 48k. The raw rows are in bench/results/*.jsonl.

### Does the iPhone change the speed of generating tokens?

Not below 64k of context, where the readme measures 25.0 tok/s for the fork on the Mac alone and 25.1 with the phone, against 11.3 for stock llama.cpp. Most of the writing speed comes from the fork's own Mac kernels, and the phone only contributes past 64k, where it computes attention over the old keys for every generated token.

### Which hardware does Backburner support?

The tested setups are an M4 Pro Mac with 24 GB and an iPhone 17 Pro Max, plus an iPhone 16 Pro Max and two iPhones. Other configurations are listed as reported, and older or non-Pro iPhones, a Linux or Windows worker, and Android phones are marked not yet.

### What licence is Backburner released under?

MIT, with the licence file at the repository root. The project is early, with version 0.0.2 labelled very early for iPad support, 0.0.3 a security fix that the release title says should be installed, and 0.0.4 published on 2026-10-03.

## Sources

- [Issues](https://github.com/StayLameBro/backburner/issues)
- [License: MIT](https://github.com/StayLameBro/backburner/blob/main/LICENSE)
- [README](https://github.com/StayLameBro/backburner/blob/main/README.md)
- [Releases](https://github.com/StayLameBro/backburner/releases)
- [StayLameBro/backburner on GitHub](https://github.com/StayLameBro/backburner)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/staylamebro-backburner