I mate , add my new model "https://huggingface.co/GODELEV/Rose-Mini" On leaderBoard

Cool stuff right there! Keep it up

Thanks for adding my models!
Really appreciate it. ❤️

The most interesting number here is in a reply, not in a column.

Rose-Mini landing in the same range as BananaMind 2 Medium at roughly 5x fewer training tokens is a stronger result than either raw score. At this scale everyone is compute-bound, so what a reader actually wants is score per training token, and right now the ranking hides it.

A tokens-seen column would surface it for free. You clearly already have the figure for some entries, and it turns a ranking into something someone can read a recipe from.

Would you take self-reported token counts, or is that a number you would only trust when you trained the model yourself?

Self-reported is fine, and for at least one entry you would not have to trust the report at all.

GODELEV/Rose-Mini ships training_meta.json next to the weights, with tokens_seen: 12206861568 and params_M: 49.443. Machine readable, already public. A leaderboard that reads that file gets a verified number for free, and falls back to the form field only when the file is missing. Once the column exists to reward it, one small JSON is a cheap ask of a submitter.

On the comparison, the card argues the other way. Rose X1 is described there as an efficient decoder-only design with GQA, RMSNorm, QK-norm and refresh gates, and the author's own line is that the goal was never to reinvent the Transformer, only to explore it. config.json backs that up: 14 layers, 8 heads, 2 KV heads, RoPE at theta 1e5, and refresh_gate_inject_layers [4, 9]. Two injection points in an otherwise standard decoder stack is exactly what a shared benchmark exists to price.

Pulling it out also costs Rose-Mini its best result. 49.4M parameters at 12.2B tokens landing in BananaMind 2 Medium's range only reads as a finding from inside your table.

Would you rather scrape tokens_seen from the repo, or take it on the submission form?

Scraping is cheaper than it looks, because the key name is already standard.

I checked all 46 entries. Seven publish a machine-readable training token count today, and six of them spell it exactly tokens_seen. Only the filename moves: checkpoint_metadata.json on your four BananaMind 2 repos, training_meta.json on Rose-Mini, training_state.json on Veyra2-Apricot. The seventh is your own BananaMind-1.5-Base, which uses training_summary.json and the key supervised_tokens_seen. So a three-filename glob and one key covers everything already out there, with the form as fallback.

Those seven are enough to show why the column earns its width. Three of them sit within 0.6% of each other on parameters:

• Rose-Mini, 49.4M params, 12.21B tokens, acc 56.0, overall 1037
• BananaMind-2-Medium, 49.6M params, 50.00B tokens, acc 56.0, overall 1034
• Veyra2-Apricot-50M-Base, 49.3M params, 19.99B tokens, acc 51.14, overall 1003

Same size class, 4.1x spread in training tokens, top two tied on accuracy. You called it ~5x earlier in this thread and the files say 4.1x.

That also partly concedes your architecture point, in the other direction. 4.1x at equal score is a property of the whole run, data mix included, so it is not evidence the architecture did it. The column is what lets a reader start separating those.

Raw tokens, or tokens per parameter? The second is the one that stays readable across the 902K to 135M range you cover.