\subsection{Two-node reuse and locality (E2/E6)}
\label{sec:network}
Figure~\ref{fig:breakeven} and Table~\ref{tab:network} report genuine two-node measurements: the sender node (M3U96a) prefills a
test document with Qwen2.5-3B, serializes the cache with its manifest, optionally quantizes or compresses it, and sends it over the
LAN to a receiver worker (M3U96b) that checks the manifest, installs the cache, prefills only the fresh question and decodes the
answer; the alternative sends the token ids and lets the worker prefill the whole document. Each point is the median of 18 runs
(6 test documents $\times$ 3 repeats, after one warm-up on both ends); the effective transport rate was
\EsixBONoneEZZZGbps{}~Gb/s on a link that iperf3 measured at 0.94~Gb/s.

\begin{figure}[t]\centering
\includegraphics[width=\textwidth]{fig6_breakeven.pdf}
\caption{Reuse/network break-even. Left: measured round trip to a remote answer (medians, p25--p75 bars) for moving the native bf16 cache
(B1), the zstd-compressed cache, the 8-bit and 4-bit packed caches (B2), versus sending the text and prefilling remotely; the grey line is
the sender's own local prefill for scale. Right: analytic transfer time from the measured bandwidth (solid) and a hypothetical 10~Gb/s link
(dashed) against the measured remote prefill slope. Qwen2.5-3B; synthetic test documents; M3U96a $\to$ M3U96b.}\label{fig:breakeven}
\end{figure}

\begin{table}[t]\centering\scriptsize
\caption{Two-node transfer (medians of 18 runs; ms unless stated). ``Send'' is the sender-side socket time; ``load'' is manifest check plus
deserialization at the worker; the round trip includes the worker's fresh-query prefill and 32 decoded tokens. 4-bit rows transfer a cache
that yields quality~0 for Qwen2.5 (Section~\ref{sec:results-frontier}) and are shown only for byte and time accounting.}\label{tab:network}
\begin{tabular}{@{}llrrrrr@{}}\toprule
Context class & Representation & payload (MB) & send & load & remote prefill & round trip \\\midrule
2k  & text $\to$ remote prefill & 0.01 & -- & -- & \EsixTextRemotePrefillNoneWZZZPrefill & \EsixTextRemotePrefillNoneWZZZRt \\
2k  & B1 bf16 cache & \EsixBONoneWZZZBytes & \EsixBONoneWZZZSend & \EsixBONoneWZZZLoad & 0 & \EsixBONoneWZZZRt \\
2k  & B2 8-bit cache & \EsixBWENoneWZZZBytes & \EsixBWENoneWZZZSend & \EsixBWENoneWZZZLoad & 0 & \EsixBWENoneWZZZRt \\
8k  & text $\to$ remote prefill & 0.03 & -- & -- & \EsixTextRemotePrefillNoneEZZZPrefill & \EsixTextRemotePrefillNoneEZZZRt \\
8k  & B1 bf16 cache & \EsixBONoneEZZZBytes & \EsixBONoneEZZZSend & \EsixBONoneEZZZLoad & 0 & \EsixBONoneEZZZRt \\
8k  & B2 8-bit cache & \EsixBWENoneEZZZBytes & \EsixBWENoneEZZZSend & \EsixBWENoneEZZZLoad & 0 & \EsixBWENoneEZZZRt \\
16k (${\approx}$11k tokens) & text $\to$ remote prefill & 0.06 & -- & -- & \EsixTextRemotePrefillNoneOXZZZPrefill & \EsixTextRemotePrefillNoneOXZZZRt \\
16k & B1 bf16 cache & \EsixBONoneOXZZZBytes & \EsixBONoneOXZZZSend & \EsixBONoneOXZZZLoad & 0 & \EsixBONoneOXZZZRt \\
16k & B2 8-bit cache & \EsixBWENoneOXZZZBytes & \EsixBWENoneOXZZZSend & \EsixBWENoneOXZZZLoad & 0 & \EsixBWENoneOXZZZRt \\\bottomrule
\end{tabular}
\end{table}

Three observations follow. First, the serialized bf16 cache is three to four orders of magnitude larger than the text it replaces
(\EsixBONoneEZZZBytes{}~MB versus 29~kB at 8k tokens), and zstd recovers only ${\approx}20$\,\% of it (high-entropy payload; H8), while packed
8-bit quantization halves it. Second, on this link and with this receiver, moving the cache is nevertheless \emph{faster} than re-reading
the text at every context length we measured: at 8k tokens the bf16 transfer answers in \EsixBONoneEZZZRt{}~ms against
\EsixTextRemotePrefillNoneEZZZRt{}~ms for remote prefill, and the 8-bit cache in \EsixBWENoneEZZZRt{}~ms, because the M3~Ultra receiver prefills
Qwen2.5-3B at ${\approx}0.44$~ms per token (\EsixTextRemotePrefillNoneEZZZPrefill{}~ms for 8k) whereas 1~GbE moves the per-token cache
(${\approx}26$~kB bf16, ${\approx}14$~kB at 8 bits) in ${\approx}0.23$ and ${\approx}0.12$~ms. The break-even therefore depends on the ratio
of receiver prefill time to link time per token, which the right panel makes explicit: a faster receiver (the laptop prefills 8k tokens in
${\approx}1$~s) or a slower link would move the crossing to longer contexts, and a 10~Gb/s link would make transfer dominant everywhere. Third,
the cost of building the cache is paid by the sender and is counted once per document: when the cache is reused for $N$ queries at the
receiver, the per-query cost is the fresh-query prefill plus decoding (${\approx}$\EsixBONoneEZZZLoad{}~ms load and ${\approx}190$~ms to the
first token at 8k), while the text alternative pays the full prefill on each cold query unless the receiver keeps its own cache---at which
point the two strategies converge and the question becomes where to schedule the work. Equation~\eqref{eq:amortized} with the measured
components gives the break-even reuse count for any bandwidth; these are measured points on one link, not a universal bound.