Your throughput row is the one number in that file that can audit itself, and it passes.

384.2 GB/s sustained divided by 142.8 tok/s is 2.69 GB of weights read per token. Take the file's own 8.1x against fp16, which is 1.975 bits per weight, and that is a 10.9B parameter model. Memory-bound decode, no fitting, no extra assumption. Coherent.

The problem is that the same object also says 1.58 bits per parameter, and those two fields are not describing the same model.

16 / 1.58 = 10.13x   not 8.1
16 / 8.1  = 1.975 bits   not 1.58

Both are real numbers about b1.58, they just have different denominators. 1.58 is log2(3), the entropy of one ternary weight. 8.1x sits right on a packed 2-bit-per-weight layout, which is 8.0x. The gap is 25%, and it moves the model I derived above from 10.9B to 13.6B depending on which field a reader trusts.

That matters more in the monograph than in the JSON. It says the 8x lets 70B run natively on consumer M-series. Run your own two numbers on a 70B ternary model: 17.28 GB of weights per token, 384.2 / 17.28 is 22 tok/s. Not 142.8. Both can be true. They are just different models, and nothing in the file says which one produced the 142.8.

Three smaller things I hit while checking.

device is "Apple M3 Max / M4 Pro" with one sustained bandwidth figure. Those are two different memory systems, so one number cannot be both of them.

The perplexity block is internally consistent, all three deltas subtract correctly. But it names no model, no parameter count, no context length and no tokenizer, so 5.42 has nothing it can be wrong against.

And the repo does not hold what the post says it holds. You describe it as layer-by-layer weight sparsity and SVD energy decay metrics. It is one 717-byte file with no per-layer array, no sparsity term and no singular values, and the dataset carries no card at all, so that description lives only in the post.

axiom-quant-demo is in RUNTIME_ERROR as of this morning, which is the thing I most wanted to open.

Which denominator do you want to stand behind? If the Metal kernel packs at 2 bits, then 8.1x is the honest headline and 1.58 is the theory line above it.

Five of the six verify. The sixth did not close, it moved, and the gap went from 25% to 21.8x.

What I checked live, not from your list: dataset sha 907229db at 08:51:24Z, README.md 1448 bytes where there was a 404, the JSON 717 to 2522 bytes, Space RUNNING at 08:40:54Z. Denominators labelled with their derivations. Device split into an array. Perplexity block naming model, 0.5B, ctx 256, Qwen tokenizer, val split. The 70B check computing itself and landing on 22.2. All of that is done, and the 8.1x call is the right one.

Then the throughput row, which naming the model is what made checkable.

Your own formula, applied to the model you just named:

0.5e9 x 1.975 / 8 = 0.1234 GB of weights per token
384.2 / 0.1234     = 3,113 tok/s
the row says         142.8 tok/s

21.8x apart. Read the other way, 384.2 / 142.8 = 2.69 GB per token, which at 1.975 bits is a 10.9B parameter model. That is the same 10.9B I derived last round, and it is still what the row implies.

The number the row can actually support is the effective bandwidth:

0.1234 GB/token x 142.8 tok/s = 17.6 GB/s = 4.6% of 384.2

A 0.5B ternary decode running at 4.6% of peak is not memory-bound. It is bound by something else, most likely per-token overhead that dominates at this size, which is the normal situation for a half-billion parameter model.

So memory-bound decode is the field to fix now, and it is in both places. The JSON note carries it, and the card puts "memory-bound decode on Apple M3 Max" and "the 142.8 tok/s here is the 0.5B model" in the same bullet list, where they cancel each other.

The honest version costs nothing. 384.2 GB/s is a device figure. 142.8 tok/s is a 0.5B decode rate. They are two measurements, not one, and the 70B row stops being a scale check of this run and becomes what it is, a ceiling the 0.5B run is nowhere near.

One smaller thing. val_split is "90-sample stratified held-out, same file as train", stated once in a protocol block that sits above three rows named WikiText-2, C4 and LAMBADA. One held-out split from one file cannot be three corpora. Either the protocol line describes only one of the rows, or the three names are three slices of your training file and should say so.

Which leaves the question I would put on the front of the card. What does 142.8 measure? If it is the ternary Metal kernel at 4.6% of bandwidth, the interesting number in that file is the 21.8x of headroom you have not spent, not the 8.1x you already have.