Start with what the script actually counts. For each quantized projection it takes the weight bytes, then adds one bf16 scale and one bf16 bias for every group of 64 values along the input dimension [5]. That is MLX affine group quantization as it lands on disk, rather than a parameter count [5]. Group size 64 is a config choice, not a law. Change it, or keep scales in fp32, and every byte in the report moves. That is the first thing that would have to be true for any of these figures to transfer to your machine.
Gate 1 is the strong test, because it leaves no tolerance to hide in. From config.json alone the model predicts the layout Swiftlet publishes in its own on-disk MoE format, and the gate demands integer equality rather than closeness [6]. All four values matched [6]. The full container came in 0.137% low, and the shortfall is named: tokenizer and chat template, which the model does not attempt [7].
Gate 2 is the one that broke, and how it broke is the point. Predicting a stranger's conversion gave 151.8 GB against a published 153.5 GB, 1.1% off a 2% tolerance [8]. The correction dated 2026-08-14 says the script assumed one dense-MLP layer where the published header states two, so it counted 41 mixture-of-experts layers instead of 40 [10]. That extra layer added 3.54 GB, while unmodelled vision and audio encoders, RMS norms, 8-bit router gates and safetensors headers subtracted 5.27 GB [12][9]. Add the magnitudes: the script was off by 8.81 GB in two directions at once, roughly 5.7% of the reference number, while printing 1.1% [1]. Take the layer error out and the whole remaining gap is that unmodelled list, 5.27 GB, or 3.4% of 153.5 GB [2][11]. Two errors landing 1.73 GB apart is the sort of luck you only hear about afterwards.
The structural claim is that total parameter count is nearly irrelevant, and that per-token cost is experts_per_token x layers x expert_size [14]. The corrections show the shape of that dependence. A figure that read 3.482 GB at publication and 3.397 GB after the fix raised the predicted token rate by a factor of 1.025 [16], which is exactly 3.482 divided by 3.397 [3]. It enters as a divisor on read bandwidth. On a device sustaining about 7 GB/s [20], 3.397 GB per token comes out near 2.1 tokens per second [4], on the assumption that this figure is the per-token expert read for the 276B model rather than another row of the same table.
So the bandwidth number carries real weight, and that is where the author's earlier work had been guessing: a previous experiment priced disk reads at a nominal 100 microseconds and admitted in its own limitations that the latency was assumed, not observed [19]. The replacement measurement reported 11 to 24 GB/s on a device that does about 7 [20], which is 1.6x to 3.4x too fast [5]. The cause is a single misread API: fcntl(fd, F_NOCACHE, 1) stops the kernel caching future reads on that descriptor and does nothing to pages already resident [21]. The benchmark was timing RAM.
Residency also reframes a README. Swiftlet describes its decode loop as "dispatch bound, not IO bound" [17]. On a 24 GB machine after warmup, 93.7% of the 35B model's expert set is resident, so it is barely streaming at all [17]. Streaming is what lets it start in a couple of gigabytes, not what it lives in, and the finding was a cliff rather than a gradient: past it, kernel work buys nothing [18][15].
