\section{Results} \label{sec:results} Every number below has a raw log in \code{benchmarks/raw/}; the path is given with each result. Results marked \textsc{pending} have a protocol but no log yet in this version. \subsection{Correctness} \label{sec:results-correctness} On four prompts (general, code, reasoning, French) \titan{} reproduces mlx-lm's logits with $\max|\Delta| = 0.0$ (float16) at capacities 64, 32, 16 and 8 slots per layer, with identical argmax at every position and identical greedy continuations of 32 tokens at 16 slots (\code{benchmarks/raw/tests/numerical\_*.json}, \code{greedy\_*.json}, \code{pytest\_gateB\_*.txt}, 7 tests passed). The registry's byte ranges read with \code{pread} are byte-equal to \code{mx.load} for sampled experts of both the per-expert layout (OLMoE) and the stacked layout (Qwen3-30B-A3B, on M3U96a). Qwen3-30B-A3B logit parity: \textsc{pending} (test launched on M3U96a; result to be inserted from its log). \subsection{All-resident control and demand loading} \label{sec:results-capacity} Table~\ref{tab:capacity} summarises the laptop capacity sweep (64-token greedy generations, general and code prompts, page-cached checkpoint, \code{benchmarks/raw/gateB/capacity\_sweep\_laptop/sweep.jsonl} and \code{benchmarks/raw/gateC/prefetch\_online\_laptop/smoke\_lazyinstall.jsonl}). \begin{table}[t] \centering\small \caption{OLMoE-1B-7B 4-bit on the M5 Max laptop: decode throughput vs residency (2 repeats after warm-up; ranges over prompts).} \label{tab:capacity} \begin{tabular}{llrrr} \toprule Backend & Residency & decode \tps{} & hit rate & stall / 64 tokens \\ \midrule mlx-lm & all & 491--496 & -- & -- \\ \titan{} & 64 slots, preloaded & 489 & 1.00 & 0 \\ \titan{} & 64 slots, not preloaded (sync path) & 201--203 & 1.00 & 0 \\ \titan{} & 32 slots, LRU, demand (v1 installs) & 56--80 & 0.73--0.81 & 0.7--1.0 s \\ \titan{} & 16 slots, LRU, demand (v1 installs) & 36--45 & 0.48--0.60 & 1.7--2.0 s \\ \titan{} & 16 slots, LRU, demand (lazy installs) & 51--73 & 0.48--0.67 & 0.6--0.9 s \\ \titan{} & 16 slots, LRU + transition prefetch ($d{=}1$, $m{=}8$) & 35--56 & 0.63--0.73 & 0.6--1.1 s \\ \bottomrule \end{tabular} \end{table} Two observations. The all-resident control matches mlx-lm within one percent only when every layer's table is complete; otherwise each layer pays a host synchronisation, which alone costs 2.4$\times$ in throughput on this model and is the floor of any demand-loading design, including colibri's. And the demand-loading rows are the H1 \emph{control}: at 16 slots the model does 53 misses per token (Prop.~\ref{prop:capacity}), i.e.\ about 11~ms of fetch per 2~ms of compute. \subsection{Routing locality} \label{sec:results-locality} From the v1 traces (18 prompts, 3\,686 tokens), per-layer LRU hit rates are 0.57 at 16 slots, 0.80 at 32 and 0.93 at 48 (LFU within 0.01), nearly identical on fit and held-out prompts (\code{benchmarks/processed/gateC/sim\_olmoe\_laptop\_ssd\_v1.json}); a one-layer-ahead transition predictor has recall@8 of 0.50 on held-out prompts; a linear probe on the previous layer's log-probabilities only 0.16 with these few traces. Table~\ref{tab:sim} is generated from the simulation JSON (v2 traces when available, else v1). \input{tables/sim} \begin{figure}[t] \centering \includegraphics[width=\textwidth]{sim_hit_vs_capacity.pdf} \caption{Trace-driven simulation on the v2 held-out prompts: per-layer hit rate (left) and modelled stall per token (right) by slot capacity and predictor. Generated by \code{scripts/make\_figures.py} from \code{benchmarks/processed/gateC/}.} \label{fig:sim} \end{figure} \subsection{Prefetching (H1)} \label{sec:results-prefetch} With the one-layer horizon the online prefetcher raised the hit rate from 0.48 to 0.63 (general) and from 0.67 to 0.73 (code) but reduced throughput from 51 to 35 and from 73 to 56~\tps{} (Table~\ref{tab:capacity}): the lead time $d\,\tau_\ell = 0.13$~ms is shorter than the 0.21~ms fetch, so predicted experts arrive late and are waited for, and the 50\,\% of wrong predictions add traffic. This is exactly the regime excluded by condition~\eqref{eq:condition}. Depth-$d$ and token-horizon prefetching on the cold-NVMe tier are reported in Table~\ref{tab:cold} (generated from \code{benchmarks/raw/gateC/cold\_nvme\_laptop/sweep.jsonl}; rows present only for configurations that have run). \input{tables/cold} \begin{figure}[t] \centering \includegraphics[width=\textwidth]{capacity_sweep.pdf} \caption{Decode throughput of every single-node configuration measured on the laptop (median over repeats, bar = range): mlx-lm, \titan{} all-resident with and without the synchronisation-free path, bounded residency on the page-cache tier, and the cold-NVMe tier with and without prefetch. Source files are named in brackets.} \label{fig:capacity} \end{figure} \subsection{Medium model (Qwen3-30B-A3B)} On M3U96a (M3 Ultra, 96~GB) the stacked-layout registry reads byte-equal slices, logits are bit-identical to mlx-lm at 128, 64, 32 and 16 slots per layer and greedy decoding is token-identical at 32 slots (\code{benchmarks/raw/tests/m3u96a/}). Table~\ref{tab:qwen3} gives the baselines: mlx-lm 121.4~\tps{} and \titan{} all-resident 121.7~\tps{} (medians of 3 repeats), i.e.\ parity on a model whose decode step touches 0.97~GiB of expert weights. \input{tables/qwen3} \subsection{Two-node execution over gigabit Ethernet (H2, H3: first evidence)} \label{sec:results-twonode} With M3U96a as coordinator and M3U96b as worker (OLMoE, 32 slots, page-cached checkpoint on both, held-out general and code prompts, \code{benchmarks/raw/gateE/two\_node\_m3u96a\_m3u96b.jsonl}), executing the odd-numbered experts of every layer on the worker keeps the logits bit-identical to mlx-lm but reduces decode throughput from 70 / 87~\tps{} (local control) to 15 / 15~\tps{} (Figure~\ref{fig:twonode}). The remote wait is 2.5~s per 64 tokens, i.e.\ about 2.5~ms per layer: a 0.5--0.65~ms TCP round trip plus the worker's array creation, kernel dispatch, evaluation and serialisation, paid 16 times per token. This is larger than a cold-NVMe demand miss at 16 slots (about 1.2~ms per layer) and twenty times the local compute per layer. On this topology the remote tier is therefore a capacity mechanism, not a latency one, exactly as Section~\ref{sec:prefetch-condition} anticipates; H2 can only be tested in the regime where a node cannot hold the experts it needs locally. \begin{figure}[t] \centering \includegraphics[width=0.6\textwidth]{two_node.pdf} \caption{Two Mac Studios over 1~GbE: local bounded residency vs remote execution of half the experts (medians).} \label{fig:twonode} \end{figure} \subsection{Metal kernels (H4), energy frontier (H5)} \textsc{pending}: Gates D and the energy study have protocols (Section~\ref{sec:algorithms}, \code{research/protocol.md}) and no logs in this version.