LFM2.5-VL-3B -> Core AI: fp16 SigLIP2-NaFlex tower + int8lin/int4lin decoders + text core; fp32 ladder cos 1.000000, suite 7/9 = fp16 baseline

README.md

@@ -50,12 +50,17 @@ greedy decoding turns any near-tie into a different tail, and the fp16 bundle it
 — int8lin and int4lin both reproduce that 7/9. The divergences are wording: *"sleeping
 peacefully on a bright pink couch"* → *"sleeping on a pink couch"*.
 
-**No iPhone numbers are published here because none were measured**, and the reason is
-mechanical: the int8lin bundle's AOT `resources.bin` is **3.13 GiB**, past the iOS runtime's
-2 GiB load wall. int4lin brings that to 2.03 GiB — still ~30 MiB over — so the phone path for
-this size needs either a split graph or a smaller embedding (the 128k × 2048 table is 524 MB
-and stays fp16 because it is tied to the head). The 450M is the phone-sized member of this
-family.
+### iPhone 17 Pro — `ios-h18p/lfm2_5_vl_3b_decode_int4lin` + the fp16 tower
+
+**27.5 prefill / 19.3–22.8 decode tok/s**, nat 16/16 and image oracle 24/24, clean at a
+1024-token generation. int8lin does **not** load on iOS (its AOT `resources.bin` is 3.13 GiB);
+int4lin's is 2.03 GiB and does — which is worth stating because the note this port was written
+against put the load wall at 2 GiB, and 2.03 GiB was written up as expected-to-fail before a
+phone was asked. It loaded. Use int8lin on a Mac and int4lin on a phone; on this model int4
+costs nothing (7/9 on the suite, the same cases as fp16).
+
+On device the description matches fp32's picture and diverges at the same near-tie the Mac
+bundles take ("sleeping peacefully" → "sleeping"), then onto an equally accurate branch.
 
 ## Run it