Community-reported decode throughput for a 70B Q4_K_M served by llama.cpp RPC across three separate machines holding 56GB of VRAM in total

NOT FULLY SPECIFIED - this is a forum report, not a benchmark. What the reporter states: three machines (one with an RTX 4090, two others each with a 4060 Ti), 56GB VRAM total, llama.cpp RPC backend with a worker on each machine, single request, n_ctx_slot 8192, n_prompt_tokens 649 then 793, output 92 then 163 tokens. Two requests reported: 4.38 tok/s decode (228.56 ms/token) then 3.98 tok/s decode (251.13 ms/token). Per-request, not aggregate - one concurrent request. Prefill was 145.97 tok/s then 37.47 tok/s. Topology, CPU, RAM, llama.cpp build, network medium and GPU split across the three workers are ALL UNSTATED, so this cannot be reproduced.

SINGLE REPORT, one user (u/RazzmatazzReal4129) on r/LocalLLaMA, who posted the full llama-server slot timing logs - which is why it is recorded at all. Do NOT read 4-5 tok/s as an RPC ceiling: the reporter describes this as a first attempt ('I haven't found much online as I was trying to set this up'), the inter-machine network medium is not stated, and a 4090 plus two 4060 Ti split across gigabit ethernet would explain the figure entirely without any RPC-specific penalty. The value is useful as an existence proof that a 70B model can be served in full VRAM across three consumer boxes with no P2P and no NVLink, and as an order-of-magnitude anchor for what general-Ethernet RPC costs - not as a performance figure to plan around. FORMAT_ID BACKFILL 2026-10-08 (w10-bench-formatid): format_id was null and is now 'gguf-q4-k-m'. EVIDENCE, quoted from this record's own text: model: "Llama 3.3 70B (Q4_K_M GGUF)". NO NUMBER CHANGED - value, metric and unit are untouched; this adds metadata, it does not re-measure. The value was NOT taken from a model name, from a sibling record, or from outside knowledge. Left null everywhere the record's own unit/methodology does not name a format for this run: 63 of the 150 records in data/benchmarks/ are still null and each one has its reason, because a null with a reason is correct and a guessed value is not. 2026-10-11 ACCELERATOR-ATTRIBUTION CORRECTED (value research). This figure was left in nvidia-rtx-4090's accelerator_ids, which made the value-analysis join treat 4.38 tok/s as a single-card 4090 figure and rank the 4090 as the worst value in the corpus (456621 tok/s per $1000, ~80x below the 5090). It is not a single-card figure: it is a THREE-HOST llama.cpp RPC cluster totalling 56GB (one RTX 4090 plus two RTX 4060 Ti), on a first attempt by the reporter, at n_ctx_slot 8192 and single-request decode. The record's own note already says not to read it as an RPC ceiling. Accelerator clarity matters more than this one record: a per-card tok/s is the denominator of every value calculation in this corpus, so a cluster figure filed under one card's id silently poisons every ranking that joins it. There is no record type for a mixed multi-host RPC configuration, so the list is now empty and the machines are named in the methodology text.