\newcommand{\WPabstract}{%
Sparse mixture-of-experts (MoE) language models touch only a few experts per token, so a model whose weights exceed a
machine's memory can still be served if the right experts are in the right place at the right time. This working paper
reports the design, implementation and measurement of \titan{}, an MLX-native inference runtime for Apple Silicon that
manages expert residency with bounded per-layer slot tables, loads experts on demand from local NVMe, prefetches them with
causal predictors, and (in its distributed mode) executes them on other Macs of a heterogeneous cluster connected by
gigabit Ethernet. Every design choice is validated against mlx-lm on identical weights: with all experts resident the runtime is
bit-identical in logits and within one percent of mlx-lm's decode throughput; with bounded residency the router's choices and
the logits are unchanged by construction. We state five hypotheses (causal prefetch, topology-aware placement, hierarchical
caching, fused Metal kernels, and adaptive orchestration on the latency--throughput--energy frontier) and test each one with a
pre-registered protocol on a live inventory of a 21-node Mac cluster. This version (0.1) is a \emph{preliminary} working paper whose
results are mostly negative and fully attributed: on the small model, the best causal predictor (a per-layer logistic probe,
recall@8 of 0.76, within 0.16 of the oracle hit rate) only ties with demand loading because installing a prefetched expert costs
as much graph time as the read it saves (H1 not supported); kernel fusion is immaterial because decode at batch size one is
launch-bound at 28\,\% of memory bandwidth (H4 not supported); and executing half the experts on a second Mac Studio over the
gigabit Ethernet that actually connects the cluster costs 2.5~ms per layer, more than a cold-NVMe miss, so the remote tier is a
capacity mechanism rather than a latency one (H2/H3 in this regime). The storage layout, by contrast, matters: an
expert-contiguous record file raises cold-NVMe decoding from 8 to 36~tokens/s. Energy measurements and the adaptive scheduler
are pending and labelled as such.%
}