Two boxes, one model

Summary

Each finding is scoped to the runs that produced it; the dates are in section 03.

1. For DeepSeek V4 Flash, one machine now beats two on long prompts. Same 3-bit file, same build, same 262,144-token window and identical prompts, 21 September: the desktop alone at -b/-ub 4096 read 690.9 tokens a second at 48,024 tokens and 632.1 at 150,103; the pair at its kept -b 2048 -ub 512 read 102.5 and 51.4. Whole requests took 75.2 seconds against 474.2 at 48,024 tokens (416.4 on the pair at -b/-ub 2048), and 244.8 seconds against 2,933.8 at 150,103, of which reading took 237.5 seconds and 2,922.9, or 48.7 minutes (section 04).
2. The pair's speaking edge is a short-prompt edge. On the same day and prompts the pair spoke at 14.76 tokens a second against 12.65 at 2,998 tokens, 12.04 against 12.16 at 48,024 and 7.66 against 11.79 at 150,103, and its reading fell from 226.8 to 30.7 tokens a second across one long prompt.
3. The pair always adds memory; it did not add reading speed. A 400.71-billion-parameter model and a 1.03-trillion-parameter model ran on the pair, and the larger file, 283.03 GiB, is bigger than either machine's memory. Against the desktop at its tuned setting, the pair read slower in every comparison re-run after the batch change. MiniMax M2.7, which our records had as faster on the pair, was compared with a desktop run at -ub 128; at the default the desktop read faster, on a shorter prompt (section 05). GLM-4.7 Full and the control were not re-run.
4. A dense model is the pair's best case for speaking. Mistral Medium 3.5, which does not fit the card, spoke at 5.54 tokens a second on the pair on a 441-token prose reply, against 1.97 on its desktop record, a different file from August; it read about ten times slower (section 05).
5. A large micro-batch can break the pair. At -ub 4096 the laptop's side failed 40,960 tokens into a 48,024-token read and the request died. -ub 2048 finished it, reading 14 percent faster, in 416.4 seconds against 474.2; the pair is kept at 512 as a precaution after the 4,096 failure (sections 04 and 08).
6. The path works, and it is not free. A 29.94-billion-parameter control model split half and half spoke at 63.8 to 68.0 tokens a second on answers of 54, 10 and 8 tokens, against 223.65 alone on replies of about 200 tokens; its reading figures are on different prompt lengths and windows, so neither pair measures what the cable costs (section 05). Two traps cost more time than any tuning (section 08).

What it is

llama.cpp has an RPC backend. One machine runs llama-server and holds the model; another machine runs ggml-rpc-server, and the first machine treats it as a device, in the same list as its graphics card and its processor. Layers are assigned to devices at load time. Nothing is pipelined across requests and nothing is sharded inside a layer: when a token needs a layer that lives on the second machine, the work and its data cross the cable and come back.

That makes three places a layer can live on this bench, and the launcher expresses them as three numbers: whole layers on the graphics card, layers whose attention stays on the card while their experts sit in the desktop's system memory, and whole layers on the second machine. Every run on the pair is written as those three numbers in that order, for example 8 / 10 / 25. A whole layer on the laptop includes its attention: the load logs put the attention cache for those layers on the laptop, so the laptop does that part of the attention work.

Every model placed with that middle number is a mixture-of-experts model: most of its weight sits in expert tensors that only some tokens use. That is why the knob exists at all, and it is why the placement question has an answer worth measuring.

What we ran, exactly

The builds

Both ends of the pair were built from one llama.cpp source commit, d3146f2b5 (build 10919, GNU 13.3.0, Linux x86_64), with the RPC backend on, as the server's own first log line records on 13 September: a CUDA build on the desktop, a Vulkan build of the worker, ggml-rpc-server, on the laptop. The later pair runs and the 21 September runs of the 3-bit DeepSeek file alone used a desktop build of the same commit, read from the build's own source directory because their logs do not print it. Other desktop-alone runs used each model's own serving build: 5f55650a7 for the 8-bit DeepSeek runs of 15 and 20 September and the 13 September MiniMax run, c8e03ce81 for the 21 September Qwen runs.

The link, measured

On 2026-09-15, with no model server running: 0.667 ms average round trip over 30 pings, and one TCP stream carrying 2,092 to 2,120 MB/s from desktop to laptop and 1,107 to 1,111 MB/s back. That is a plain socket test, a lower bound rather than a tuned benchmark; the table, the method and its scripts are in the data package. measured

The launch shape

One llama-server on the desktop, one worker process on the laptop, one request at a time. The 13 to 14 September runs served a 131,072-token window, except the control, which served 8,192; the 15 and 21 September runs served 262,144 where the rows say so. Every run on the pair from 13 to 21 September left llama.cpp's batch sizes at their defaults, -b 2048 -ub 512, except the 21 September rungs that raised them.

The probes

• 13 to 15 September: a short probe (a 21-to-55-token question, up to 200 tokens of answer), a depth probe (filler padded to about 8,000 tokens with a code word planted in the middle) and, on some runs, a fresh 8,000-token prompt with a different code.
• 15 to 21 September: a synthetic ledger with a sealed code planted halfway, read cold, answered with the code. On 21 September the desktop-alone and pair runs used identical prompts, 2,998, 48,024 and 150,103 tokens long, and on the pair each cold read was followed by the same ledger with its last question changed, then a real follow-up turn.

Speeds are llama.cpp's own timings fields, per request. Speaking figures count every token the model generates, hidden reasoning included: DeepSeek V4 Flash thinks by default, and a short answer can be mostly reasoning. Where a figure comes from a short answer, the table says how long the answer was. A whole-request time is the probe's wall clock from sending the request to the finished answer; a reading time is the server's own prompt-evaluation time inside it.

Dates

The same file on one machine and on two

On 21 September we ran the 3-bit DeepSeek V4 Flash file (UD-IQ3_XXS, 104.2 GB) both ways: the same llama.cpp binary, a 262,144-token window and identical prompts. On the desktop alone the file ran with every layer's attention on the card and the experts of 36 of its 43 layers in system memory. On the pair it ran at 8 / 10 / 25. All figures measured, 2026-09-21, one request at a time, the sealed code quoted back correctly on every read that finished.

Speaking figures are short answers: 59 to 86 tokens generated, most of it hidden reasoning before a one-line code. On the pair, a longer reply of about 400 tokens on the same documents spoke within 3 percent of the short answer at every depth (14.73, 12.05 and 7.85); we did not time a longer reply on the desktop alone. The desktop run at -ub 2048 read a different 150,000-token ledger, 149,898 tokens long. The desktop's 150,103-token run records ubatch=skip: the probe passed no batch setting, and the server was started on the fast preset, whose default is -b/-ub 4096; its card reading at load, 28,570 MiB, matches the explicit 4,096 run (28,490) and not the 2,048 one (27,092). The package README lists this as its contradiction 10.

Reading is the server's own prompt-evaluation time; the whole request adds the answer and the probe's round trip. 2,922.9 seconds of reading is 48.7 minutes, and 237.5 is 4.0. measured

Reading. The desktop alone read faster at every length, each machine at its own setting (-b/-ub 4096 alone, -b 2048 -ub 512 on the pair): 3.3 times the pair's speed at 2,998 tokens, 6.7 times at 48,024 and 12.3 times at 150,103. At the same micro-batch of 2,048, with -b 4096 on the desktop and -b 2048 on the pair, the pair was slightly faster on the short prompt, 224.9 against 208.1, and 3.6 times slower at 48,024 tokens, 117.0 against 426.5. The gap grows with depth, and the server's own progress lines on the 150,103-token read show it directly:

Tokens read per second over each stretch, worked out from the timestamps in each server's progress lines for the same prompt by the script in the package. measured

Speaking. The pair still spoke faster on the short prompt, 14.76 against 12.65, about a sixth. By 48,024 tokens the two were level (12.04 against 12.16), and at 150,103 the desktop alone was faster (11.79 against 7.66). Our reading of the pattern, which no run here instruments: the laptop holds 25 whole layers, attention included, and attention work grows with the prompt, so the laptop's share of every token grows with depth.

The micro-batch on the pair. Raising it from 512 to 2,048 bought 39 percent on the 2,998-token read and 14 percent at 48,024 tokens, where the whole request took 416.4 seconds against 474.2. At 4,096 the 48,024-token read stopped: the server's last progress line was at 40,960 tokens, then it logged that the remote worker had crashed or returned a malformed response, and the request failed. Our notes from the laptop's system log record its graphics driver resetting the device and the worker restarting itself; that log was not kept, so the desktop's log is the only file behind this paragraph. The worker was serving again three minutes later for a 150,103-token read at 512, which completed without a fault. We keep 512 as a precaution after that failure; 2,048 did not fail.

What a follow-up turn costs on the pair. A real next turn, with the model's reply sent back and a short new question added, re-read only the new messages at either setting. A changed last message, here the same document with its last question swapped, went back one micro-batch, so a larger micro-batch costs more there; we measured the swapped question only.

At 150,103 tokens deep and -ub 512 the same two cases re-read 239 tokens in 9.7 seconds and 533 tokens in 20.7 seconds. measured

How the picture changed

• 13 September, the comparison our records first made. The 3-bit file on the pair, at a 131,072-token window and default batch sizes, spoke at 15.9 to 17.1 tokens a second and read 184.6 to 187.9 on prompts of about 8,000 tokens. It was set against the 8-bit file alone in a 12 September framework check: speaking 9.2 to 9.7, and reading of about 75.5 and 73.8, the framework's own estimates, on counted prompts of 52,931 and 102,481 tokens. Different files, depths, days and methods. measured
• 17 September, the first desktop run of the same 3-bit file. It spoke at 13.5, the mean of three 400-token replies to a short prompt, at 262,144 with the experts of 36 layers in system memory. That comes from the day's own results table; its raw logs were not kept. measured
• 21 September, the reversal: the tables above. The 15 September reads at a full window are on what a full window costs, and the 8-bit file's batch runs of 20 September on the DeepSeek V4 Flash card.

The laptop by itself. Run alone, with the same 3-bit file at a 131,072-token window and -ub 512, the laptop read the 48,024-token prompt at 56.7 tokens a second, slower than the pair. Six models on the laptop alone have their own page.

The other models

One row per model, on the pair at llama.cpp's default batch sizes, one request at a time. Where a model has a desktop-alone figure, the run that produced it is named, because it was always a different night and often a different setting. All speeds measured; parameter counts and sizes are read from each file's own header. The full cells, with every probe, are in the data package.

Ten models loaded on the pair, including the control. Against the same file alone, DeepSeek V4 Flash's speaking edge holds only on short prompts (section 04); Mistral Medium 3.5 spoke faster than its desktop record, on a different file; four models read more slowly on the pair and spoke at about the same pace or slower; MiniMax M3 loaded only at a small micro-batch; two are capacity demonstrations; the control is a proof of path.

The placement rule, revised

The mechanism we believe is simple, and worth stating as belief rather than measurement. Every token drags some bytes through some memory: bytes on the card are fastest, bytes in the desktop's system memory are slower, and bytes on the other end of a cable that carries about two gigabytes a second (section 03) are slower again. Moving expert weight off the desktop helps when the freed card space fills with layers the card can serve at full speed. But a whole layer on the laptop brings its attention with it, and attention work grows with the prompt, so the laptop's slower share of every token grows too. That fits DeepSeek's speaking going from 17 percent ahead at 2,998 tokens to 35 percent behind at 150,103, and the pair's reading falling from 226.8 to 30.7 tokens a second across one long prompt. The dense Mistral Medium 3.5 fits it from the other side. We did not instrument any of it: no byte counter, link utilisation or per-layer timing.

Reading has a plainer cause too. For models whose experts sit in system memory, a larger micro-batch makes the desktop's reading several times faster (the batch-size study explains why); on the pair it bought 14 percent before the laptop's side failed. The 13 September comparisons ran the desktop at the default setting or below it.

The draft model, the installed preset and the checks

DeepSeek's draft model, on the card, 2026-09-13, raised speaking at 8,000 tokens of depth by 12 percent on the 3-bit file (16.15 to 18.12) and 51 percent on the 4-bit file (12.78 to 19.25), and cost reading on both (184.6 to 148.8; 145.4 to 121.9); placement moved as well. It was not re-measured at 262,144 or with a larger micro-batch. The 4-bit file with the draft, as a preset of the installed service on 2026-09-15 at 131,072, spoke 19.55 and 19.59 and read 125.1 on 7,841 tokens; its check covered the short legs only. measured

A separate check through an agent framework, 2026-09-14, planted three codes in 48,000 and 96,000 tokens of history and required a tool call at depth. On the 3-bit pair the long legs passed, 3 of 3 codes and a tool call at 52,928 and 102,478 tokens with the first word after 543.65 and 1,537.75 seconds, only inside an attempt that failed on an unrelated leg; a later attempt passed and covers the short legs only. The tables, the attempts and the load figures are in the data package, and the DeepSeek V4 Flash card carries the model-level record.

Two traps behind the advice

Each is an interaction between a reasonable default and a two-machine setup the default did not anticipate, and each is cheap to avoid once seen. The figures are from the campaign's logs.

1. Build both ends from one commit, or get confident gibberish

The first split run of the campaign loaded cleanly, was ready to serve after 414 seconds, and returned HTTP 500 on the first request: the laptop's worker had been built from a different commit than the desktop's server. The second time was quieter. With a server built from a llama.cpp pull-request branch and a worker built from mainline, a different model loaded, stayed up, and produced fluent nonsense: the same word repeated. The branch adds one ggml operation, shifting every operation identifier after it (GGML_OP_COUNT 101 to 102, RPC protocol 0 to 1), and the host never asks the worker what it can do. Build both ends from the same source commit and record it. If split output is fluent and wrong, suspect the build before the model.

2. A micro-batch the laptop cannot carry

At -b/-ub 4096 the pair read a 2,998-token prompt normally, then failed 40,960 tokens into a 48,024-token read (section 04). The short read gave no warning. On a pair, test any larger micro-batch at your longest real prompt, not a short one.

Two more traps from the first nights, a watchdog that stopped a healthy server by probing a busy worker's port and a worker that started before the laptop's graphics driver and served from its processor for hours, are written up in the data package with their dates.

What we got wrong

This site publishes corrections of its own records as a genre. Where our records and the logs disagree, the log's number is printed.

Our internal ledger of the first runs also rounded several numbers or quoted the best probe without saying so; the nine rows where it and the logs disagree are in the data package. The pattern is worth more than any single row: the numbers that drifted all drifted in the flattering direction, for the pair. A band became its top end, three attempts became one pass, and a comparison across two files and two default settings became a speed-up.

What this does not show

• One same-file comparison, one model. Section 04 compares one DeepSeek file on one machine and on two, on one day, each machine at its own tuned or kept setting. The other models' rows cross nights, builds, windows and prompt lengths, and each row says which.
• Nothing here measures quality. The only correctness checks are planted codes quoted back and tool calls that returned.
• Windows up to 262,144 tokens. The longest prompt on the pair was 230,835 tokens, the longest on the desktop alone in these records 150,475. We have no data past that.
• One failure at -ub 4096, not retried; the laptop's side of it rests on notes, not a kept log.
• DeepSeek's speaking is measured on short answers, which 400-token replies matched within 3 percent on the pair; on the desktop alone we did not time a long reply.
• Three files on this page are no longer here. Llama 4 Maverick was deleted on 2026-09-14, Kimi K2.7-Code's weights on 2026-09-17 and the MiniMax M3 file used on the pair by 2026-09-21. Their rows record that the files loaded, not a recommendation.
• One cable, one pair of machines, runs from 13 to 21 September. A different second machine, link or llama.cpp build could move all of it.

Sources and artifacts

The evidence ships as a data package: the files the runs actually produced, not a summary. If a number on this page disagrees with a file in the package, the file is right and the page is wrong; tell us and we will fix the page. data/README.md maps every file, states its provenance and the redactions, and opens with the places where the package looks like it argues with itself; data/NUMBERS.md maps every figure on this page to its file and field; data/moved-from-the-page-2026-09-26.md holds the tables and write-ups that left this page on 26 September, each with its sources.

• 15 to 21 September: server logs, result files and memory samples for the pair and the 3-bit file alone, the long reads at a 262,144-token window, the 8-bit file's micro-batch runs, the MiniMax and Qwen desktop runs, and the probe scripts.
• 13 to 15 September: the link measurement with its scripts, one log per model on the pair, the loader's header lines, the tool-and-recall records, the installed service's run record, the placement comment block and the maker's model card at a pinned revision.

Machine names, network addresses, ports, absolute paths, service names, our internal keys and the agent framework's tool names are replaced with marked placeholders or public names, file by file, as the package README lists; nothing that carries a measurement is altered. Withheld: the internal ledger that section 09 quotes, the session notes, and the desktop-only records of 12 September, which carry private labels.

Every claim on this page is dated. llama.cpp's RPC backend is under active development; if today is much later than 21 September 2026, treat everything here as unverified since then.

Related pages on this site

The DeepSeek V4 Flash field card is the model-level record for the model in sections 04 and 07. The batch-size study is the desktop-alone half of this story across the whole roster. What a full window costs has the long reads of 15 September. The laptop-alone study runs six models on the second machine by itself. The September roster lists what else this desktop serves. The wrong flag is the same editorial habit applied to an earlier record: a default nobody had checked, measured and corrected.