cascade-fastmix-v1

A throughput-first challenger to the reigning king valor/aurora-mix.

This is a derived work. generator.py descends from the on-chain valor/aurora-mix; tempo_gen/ vendors an Apache-2.0 subset of TempoPFN. See NOTICE for attribution and the full change list, and Provenance below for a licence caveat you should read before deploying.

The thesis: the token budget is unclaimed

cascade trains in stream_cpu mode. The generator subprocess pipes into a synchronous training loop — no prefetch thread, no worker pool — and toto2_trainer stops on tokens >= token_budget or time.time() > deadline, because "waits for data DURING training do count — that is the anti-trickler bound". So the corpus generation rate is a hard ceiling on how much compute a submission actually spends.

Measured on an AMD EPYC 7B13, against the 185k tokens/s reference in chain.toml:

Both kings starve the trainer and time-truncate. At the heat's 1800s cap and 333M-token budget, the king trains on roughly half its intended compute. This generator keeps the king's prior breadth and feeds above the reference rate, so it spends the full budget — ~2x the tokens at the same wall clock.

Crucially, the speed comes from fixing an implementation defect, not from a cheaper prior. ForecastPFN — the king's largest family, and 100% of the ares-v3 prior that held the throne four rounds — spent 74% of its runtime in pandas Index arithmetic inside _get_freq_component: ~40 pandas ops per component per series to evaluate a plain Fourier sum. Vectorising it preserves the sampled prior to ~1e-12 (the RNG draw order is untouched); only the overhead goes.

What changed vs. the king

1. Vectorised ForecastPFN evaluation — same prior, same RNG stream.
2. Enabled web_traffic and seasonal_level. Both were fully implemented upstream but named in neither _DEFAULT_WEIGHTS nor config.json, so the weight filter in __init__ dropped them and they could never be drawn. web_traffic is the interesting one: upstream's own comment sizes the private eval pool at ~65% count/web (npm + wikimedia ~53%), and no other family emits that log-multiplicative, period-7, adoption-curve composition.
3. Fixed web_traffic rather than merely enabling it. Its level is drawn in log space over many decades; _postprocess then applied the generic positive rescale (up to another 100x) and the terminal clip pinned the result flat — after the degeneracy guards had already run. Enabling it as-inherited emits 52/200 series at std<1e-6. Fixed: 0/200.
4. Rescale instead of clip for over-range series, preserving shape.
5. Fixed a latent contract bug: generate(1) and generate(2) raise ValueError on the king (an upstream TempoPFN mixup bug). They work here.
6. Rebalanced weights against the stream rate: ForecastPFN 0.40 → 0.28, with freed mass to fast high-signal families.

Verification

cascade verify ./challenger            # PASS — deterministic, accepted by trainer
python -m pytest challenger/tests -q   # 14 passed

• Determinism: byte-identical corpora in-process and cross-process under differing PYTHONHASHSEED.
• Corpus health: 500 series — 0 flat, all finite, all 1-D, lengths 66–2048.

What is NOT verified

No GPU was available, so this has never been scored. cascade verify proves it would be accepted; it says nothing about whether it wins. Before spending a hotkey, run the real A/B:

cascade score ./challenger --pool-dir <your real held-out series> --device cuda
cascade score ./valor      --pool-dir <same pool> --device cuda

You need to clear the 0.02 win margin ([scoring] win_margin_start).

The throughput edge has a ceiling. It exists only while the king is below the reference rate. If a heat pod is >2.2x this box's single-thread speed, the king saturates too and the edge collapses to ~1.0x — leaving only the web_traffic/seasonal_level coverage as the differentiator. A 2.2x single-thread gain over an EPYC Milan core is not realistic, so the edge probably holds, but it is an inference, not a measurement.

The weights are reasoned, not tuned. 0.28/0.14/0.12/… reflects the evidence above (ForecastPFN's throne record, the count/web pool estimate, per-family throughput), not a sweep. The ~65% count/web figure is upstream's claim, taken on faith. Sweep the web_traffic and forecast_pfn shares once you have GPU scoring.

Provenance

cascade publishes every committed generator as public, content-addressed code specifically so competitors can study and improve on the king — cascade fetch plus "you win by improving on the visible best" is the documented workflow, and a byte-identical copy is dropped before it trains. This derivation follows that intent.

That said: the upstream valor/aurora-mix repo carries no LICENSE or NOTICE file, so no explicit licence grant accompanies the code this file is derived from. The attribution in NOTICE records provenance; it is not a substitute for a licence. Satisfy yourself that you are comfortable deploying a derivative of another miner's unlicensed code under your own hotkey. If you are not, the two genuinely independent contributions here — the vectorised ForecastPFN evaluation and the web_traffic scale fix — port cleanly onto a generator of your own authorship.