VIDRAFT_LAB

Thanks for checking from your side — good to have it confirmed by someone logged out rather than just by us.

And no need to worry about the checkpoint part. Easy thing to miss.

The part you keep chewing on is the part worth keeping. The tag was a claim, gated: auto was a fact, and both sat in the same repo for the whole staging window with nothing reconciling them. We didn't catch it either — an anonymous pull from a stranger did.

To answer your question directly: yes. We already run a version of it before release — a logged-out pass that checks anonymous access against what the card claims, along with links and wording. It caught a few leftover lines on this release. It exists because of exactly the failure you're describing, and it's a small script rather than anything clever.

Which is sort of your point. If a few lines can compute that diff, it probably shouldn't be something each team rebuilds on its own.

Thanks again for pulling the repo in the first place.

You're right — good catch, and thank you for actually testing it instead of assuming.

It was a leftover switch, not intent. The base was gated during the private staging phase, and when we flipped everything public that one toggle didn't come along with it. Nothing in the license or the release plan ever called for a gate there.

It's fixed now. Aether-7B-5Attn is ungated — and I verified it from a logged-out client rather than trusting the settings page: anonymous file pulls return 200, and /refs resolves again.

One clarification while I'm here: the 110k / 115k / 162k checkpoints aren't branches of the base repo — they're folders in a separate public dataset, FINAL-Bench/Aether-7B-5Attn-checkpoints (~13 GB each, ungated). So enumerating refs was always going to be a dead end for those, quite apart from the 403.

And thank you for the point about the logs — that's the part we most hoped people would open rather than star. The multi-node run is messy in places, which is rather the point: it's the actual run, not a tidied-up excerpt.

The 35B model currently released for testing is being served through Hugging Face Spaces in an on-premise-style, GPU-free CPU-only environment.

The free CPU version provided by Hugging Face is running on a virtualized 2 vCPU + 16GB RAM instance, delivering approximately 5.5 to 6 tokens per second.

URL: https://FINAL-Bench-Ourbox-35B-VKUE-FreeCPU.hf.space

The 35B model currently released for testing is being served on Hugging Face Spaces in a fully on-premise-style environment with no GPU — CPU only.

It is running on an upgraded CPU instance with 8 virtual CPUs and 32GB of RAM, delivering approximately 20 tokens per second.

https://FINAL-Bench-Ourbox-35B-VKUE-CPU.hf.space

Agreed on the framing, and the push is fair.

25.7 (single-stream) and 601 (aggregate under concurrency) aren't the same axis — you're right. The 23.4× is a system-level number, and part of it is batching that any MoE gets for free. That isn't the VKAE claim, and we'll present it as what it is rather than fold it into the speedup.

What the paper leads with is the controlled comparison: identical concurrency, batch, and harness, VKAE on vs. off. Single-stream and the throughput ceiling stay as separate, labeled context.

Same discipline on quality — the tail, not the mean: long-context recall and the hard subset, measured against VKAE-off on identical inputs. If it doesn't hold there, it doesn't ship.

To your question directly: VKAE-on vs. VKAE-off at identical concurrency. That's the headline.