A model card table carries two kinds of number and the risk is lopsided. Competitor columns, the MiniCPM and Freeze-Omni and PersonaPlex rows everybody keeps printing, come from someone else's paper, so you can check them against that paper in ten minutes without downloading a gram of weights. The hero row is the release's own score, and that one stays unverifiable until someone runs something. So the borrowed half is the testable half, and when it matches another lab's table to one decimal place you've proved those baselines were lifted rather than typed, which locates where the citation printed on that page points before you read a single claim.
I swept three releases that way across Nov 8 and Nov 9, then re-checked the first one two days later. Nothing needed a download to decide anything.
The table that cited somebody else's research
The org is adventists-ai, 16 models. Their family page Sophon-Realtime-v1 is a README only (5 files, zero bytes of weights). Weight repos sit next to it: Sophon-Realtime-32B-Tag at 44.61 GB over 68 files created 2026-10-29 with 202 downloads, Sophon-Realtime-32B-Flash at 40.89 GB over 55 files created 2026-11-07 with 10. Their GitHub repo, created 2026-11-04 and pushed 2026-11-08, is Apache-2.0 Python, 176 tree entries, 8,227 lines.
Their VoiceBench row printed MiniCPM-o 4.5 at 76.1, Freeze-Omni 55.2, PersonaPlex 30.6, Moshi 29.5, NemotronLabs at 55.1. The arXiv id tagged on their own model page is 2609.21967, which resolves to NVIDIA's paper, "NemotronLabs VoiceChat: An Open Full-duplex Speech-to-Speech Model with Tool Calling Capabilities", submitted 18 Sep 2026 and last revised 1 Oct 2026. That paper's Table 3 matches those five rows exactly, faithful copies of someone else's baselines.
Sophon's own scores go the other way. VoiceBench 82.8, Big Bench Audio 81.8%, FDB v3 Pass@1 48% and NVV-SuperBench 0.86/0.80 appear in no public table I could open, and the string 82.8 does not occur anywhere inside the cited paper. Their card notes that 82.8 ties GPT-4o-mini-Audio at 82.84, a half-duplex model scored in the same column as a full-duplex one. Zero HF discussions on any of it.
Four read-only checks that made it decidable
Resolve the arXiv id, diff the competitor columns against that paper's table, grep the hero number's digits inside it, then git ls-files looking for an eval harness. Twenty minutes, all read-only, nothing moved onto my disks. The fourth check came back empty, their repo has no eval or bench directory at all, which is what turned "82.8" from a claim into an uncheckable one.
Two days later the popularity tripled and the evidence did not
Stars went 12 to 162, forks 2 to 10, Python lines 8,227 to 12,023, HF downloads 202 to 356 on Tag. New E2E weights published at 79.0 GB over 37 files, and the README grew a methodology footer: "Self-run unless noted", VoiceBench judged by official evaluators behind a gpt-4o-mini judge, Big Bench Audio judged by GPT-4.1 on the transcript, FDB v3 reported as best of several runs.
That footer is better disclosure than the Nov 8 card had, and it's also the sentence shape that makes an unaudited number read like it was audited. git ls-files still shows no eval, bench or harness code anywhere in the repo, only docs/assets/bench/*.png chart images, nothing a stranger could run against those charts, so 82.8 stays self-reported with more prose around it.
The case where the claim was reproducible, and still optimistic
DSpine spec-decode drafters for the dense Qwen3.8-27B plus a llama.cpp fork (Ajay9o9/llama.cpp, branch dspine, HEAD d493f84 pushed 2026-11-08). Delta against upstream is one commit, "dflash : add DSpine draft model support", 8 files, +323 lines. Unlike Sophon, this drafter repo carries four HF discussions with third-party measurements on Intel Arc SYCL, AMD ROCm, DGX Spark GB10 and RDNA3 Vulkan, cross-hardware community checks that make the claim testable at all.
Stock llama-server refused it here (0.9.0-dev b299 6414d5b): done_getting_tensors: wrong number of tensors; expected 73, got 58. Their fork loads it. I built that branch with -DGGML_CUDA=ON in about fifteen minutes and ran it on my RTX 3090 against the quant their card recommends, Qwen3.8-27B-Q4_K_M (1.258 GB drafter), flags -fa on --jinja temp 0, three reps per prompt. No-spec decode measured 42.7 code / 42.7 prose / 41.8 math tok/s; DSpine n-max 15 hit 84.0 / 56.8 / 79.8 and n-max 7 gave 61.5 / 46.2 / 61.2, with draft acceptance 20.5% of drafted tokens at n15 against 35.6% at n7 for code.
Their card claims 94 to 132 tok/s on a stock 3090 with this drafter, I measured 80 to 84 hot on the same class of card, so the direction is real and the top line sits roughly 15 to 40% high. Their no-spec baseline is 28.2 against my 42, different prompt and context settings, which is where their multiplier stops matching mine. Prose gained least across the three arms, and their own chart caveat says why (the llama-bench prompt there is novel prose, "quite unfavorable for drafting").
The third claim broke further back in the chain
A third drop claimed "Qwen3.8-27B 82 to 381 tok/s on one RTX 3090". Tracing the reposts (an Aug 21 post, Reddit r/LocalLLaMA comments/1vtup5s, then GitHub syv-ai/qwen38-27b-rtx3090, which now redirects to syv-ai/HyperQwen, Apache-2.0, created 2026-08-15, pushed 2026-11-09, 2,634 stars) shows the caption naming llama.cpp where the source thread and the repo both run vLLM, so the engine in the headline was wrong before any number got checked. Their README pairs 127 tok/s single-stream at 64k with SPEC=dflash2 plus prefix cache and reaches 381 only in quoting mode at 4 slots/56k with DFLASH_TOKENS=15, a setting that crashed EngineCore (marlin_gemm dispatcher aten::empty allocation failure) on a >20k-token quote request here. The repo now pins vLLM==0.33.0 per issue #440 dated Nov 6 and no issue mentions that signature, which leaves 381 unrun against the current release.
What the checks decided
Sophon stays parked unless an 80 GB card lands on the box, a 4B-thinker variant shows up in that org listing (it doesn't), or they publish a repro harness. DSpine belongs as a per-model option for the dense 27B brain when llama.cpp serves it, since warm decode on my resident coder lane sits at 82-84 tok/s while DSpine lands at 50-72 depending on depth. HyperQwen stayed parked at SPEC=dflash2 plus PREFIX_CACHE=1 with no DFLASH_TOKENS line, since the resident engines hold both cards.
Four read-only checks per release and I never argued with a score. Copied rows decide where a table came from, a missing harness decides whether its own scores mean anything.
Which number on a model card would you need to see before installing weights: the hardware floor, the citation resolving to their own paper, or somebody else's run on your class of GPU?
