| 3 |
3 |
document: expH_ssd_feasibility/analysis |
| 4 |
4 |
author: Simon-Pierre Boucher |
| 5 |
5 |
contact: contact@spboucher.ai |
| 6 |
|
−created: 2026-08-11 |
| 7 |
|
−status: draft |
|
6 |
+created: 2026-08-12 |
|
7 |
+status: reviewed |
| 8 |
8 |
--- |
| 9 |
9 |
|
| 10 |
10 |
# Analysis — expH_ssd_feasibility |
| 11 |
11 |
|
| 12 |
|
−*To be written after results exist. Must include the seven-field block and the evidence standard of CLAUDE.md §10.* |
|
12 |
+Run: `results/expH_ssd_feasibility/20260812T034359Z/` · code committed at `b4a652d` |
|
13 |
+Hardware: Apple M5 Max (6P+12E, 40 GPU cores), 48 GB unified memory, APPLE SSD AP2048Z |
|
14 |
+(2 TB, internal APFS), macOS 27.0 (26A5388g), Python 3.14.4, MLX 0.32.0. |
|
15 |
+3 repeats/cell, adaptive budget (~3 s wall/repeat, 256 MiB floor, 8 GiB cap), |
|
16 |
+8 GiB incompressible test file written with `F_NOCACHE`. `iostat -d -w 1` logged |
|
17 |
+alongside as controller-level ground truth. |
|
18 |
+ |
|
19 |
+```text |
|
20 |
+Hypothesis |
|
21 |
+ See hypothesis.md: ≥2 GB/s uncached random reads at ≥1 MiB blocks; sharp |
|
22 |
+ degradation below 64 KiB; modest degradation under concurrent Metal load. |
|
23 |
+ |
|
24 |
+Falsification criterion |
|
25 |
+ <500 MB/s uncached random @1 MiB, or >50% collapse under GPU load. |
|
26 |
+ → NOT triggered. Hypothesis survives, and understates the hardware. |
|
27 |
+ |
|
28 |
+Method / Baseline |
|
29 |
+ As registered in hypothesis.md (internal sequential baseline; no straw men). |
|
30 |
+ |
|
31 |
+Result (mean of 3 repeats; std in results.json, mostly <2%) |
|
32 |
+ Cold random reads (F_NOCACHE file, iostat-validated): |
|
33 |
+ 4 KiB QD1: 67 MB/s (16.6k IOPS) QD8: 480 MB/s (117k IOPS) |
|
34 |
+ 64 KiB QD1: 770 MB/s QD8: 5138 MB/s |
|
35 |
+ 256 KiB QD1: 2302 MB/s QD8: 11590 MB/s |
|
36 |
+ 1 MiB QD1: 4556 MB/s QD4: 13628 MB/s QD8: 13789 MB/s ← at ceiling |
|
37 |
+ iostat peak disk throughput across the whole run: 13112 MB/s → the true |
|
38 |
+ device ceiling is ~13 GB/s. Warm-cache peak (page cache / unified memory): |
|
39 |
+ 136 GB/s — a ~10× RAM:SSD ratio, far better than the ~100–250:1 cliff on |
|
40 |
+ discrete-GPU systems (PCIe + separate VRAM). |
|
41 |
+ Under concurrent MLX fp16 4096² matmul load (10 032 iterations, GPU |
|
42 |
+ saturated): 4 KiB QD8 480→478 MB/s; 1 MiB QD8 13789→13393 MB/s (−2.9%). |
|
43 |
+ |
|
44 |
+ INVALID CELLS (flagged, not used): every cell whose mean exceeds the |
|
45 |
+ iostat ceiling is cache-contaminated — all 4 MiB cells (48–55 GB/s) and |
|
46 |
+ threaded sequential cells at ≥256 KiB (24–34 GB/s). Cause: budget ≈ file |
|
47 |
+ size, so repeats re-read blocks whose F_NOCACHE pages had not yet been |
|
48 |
+ evicted. Sequential single-thread cells ≤14 GB/s are plausible but treated |
|
49 |
+ as upper bounds only. |
|
50 |
+ |
|
51 |
+Interpretation |
|
52 |
+ 1. SSD weight-streaming is VIABLE on this hardware — with the right access |
|
53 |
+ pattern. At ~13 GB/s, a runtime spending 50% of a 100 ms/token budget on |
|
54 |
+ I/O can read ~650 MB/token; even QD1 1 MiB reads supply ~450 MB/token. |
|
55 |
+ 2. The access-pattern contract is strict: ≥256 KiB blocks at QD≥4 (or |
|
56 |
+ ≥1 MiB at any QD) reach ≥60% of ceiling; 4 KiB random is 200× slower |
|
57 |
+ than ceiling. Weight block layout must therefore bundle to ≥256 KiB — |
|
58 |
+ consistent with LLM-in-a-flash's row-column bundling rationale. |
|
59 |
+ 3. Unified-memory contention is a non-issue (<5% under full GPU matmul |
|
60 |
+ load): prefetch threads can run concurrently with Metal compute. |
|
61 |
+ 4. macOS measurement discipline established: F_NOCACHE does not bypass |
|
62 |
+ already-resident pages (first run read 42–115 GB/s from cache); |
|
63 |
+ test data must be written uncached; any figure above the concurrent |
|
64 |
+ iostat ceiling is contamination; 16 KiB pages make sub-16 KiB uncached |
|
65 |
+ I/O impossible in principle. |
|
66 |
+ 5. Bytes/token budget implication for candidates: interactive ≥5 tok/s |
|
67 |
+ leaves ≤~1.3 GB/token of SSD reads in the theoretical limit, ≤~650 |
|
68 |
+ MB/token realistically. A 100 GB-class checkpoint is usable only if |
|
69 |
+ per-token touched bytes stay ~two orders of magnitude below total size |
|
70 |
+ — which is exactly the decoupling this project investigates. |
|
71 |
+ |
|
72 |
+Next experiment |
|
73 |
+ expD/expG (progressive reconstruction + decision stability) become the |
|
74 |
+ binding questions: the storage substrate is not the bottleneck; the open |
|
75 |
+ question is whether ≤650 MB/token of *useful* residual/expert/sparse bytes |
|
76 |
+ suffice to preserve model behavior. Also rerun key cells with a 64 GiB |
|
77 |
+ test file (> RAM) to close the cache-contamination hole for sequential |
|
78 |
+ cells before publishing any sequential numbers. |
|
79 |
+``` |