A solo-built Rust autograd stack with custom SIMD dispatch models gacha probabilities at 10k+ sims per second. Here's what the benchmarks reveal about tiny-model performance without PyTorch.
A single static Rust binary, no PyTorch, no ndarray, no tch-rs, running roughly 10,000 gacha simulations per second on a laptop while training four neural nets from scratch in 30-45 seconds. That's the pitch behind Talos-XII, a hand-written autograd project that just landed on r/MachineLearning looking for benchmark help across ARM, AVX-512, and GPU targets.
And honestly, it's one of the more interesting from-scratch ML projects to surface this year. Not because it's trying to compete with the big frameworks (it isn't), but because it's asking a question the field has mostly stopped asking: what does the performance envelope actually look like when you skip the framework tax entirely for small models?
PyTorch and JAX have swallowed the training story for anything above roughly 10 million parameters. That's fine. But there's a specific regime, small RL policies, MLPs under a few hundred thousand params, tabular models, where a Rust autograd from scratch build can genuinely outperform a mainstream framework on cold-start latency, binary size, and per-sample throughput.
Photo by Brecht Corbeel on Unsplash
Talos-XII is a benchmark case for exactly that regime. It's a CLI simulator for the gacha system in Arknights: Endfield, which sounds niche until you realize the underlying question, "what's my probability of getting the rate-up unit as an F2P player," is a stochastic policy-evaluation problem. The kind of thing PyTorch is overkill for and pure Monte Carlo is undertrained for.
So the author built a full stack instead.
The headline claim is four trained models plus a hand-rolled backend. Based on the project description on Reddit, here's the breakdown:
| Component | Purpose | Type |
|---|---|---|
| Env Net | Fits environment noise/bias distribution | Small MLP |
| Luck Optimizer | Optimizes over 32-dim engineered features | Neural optimizer |
| Dueling DQN | Pull-vs-wait decisions | Discrete RL |
| PPO actor-critic | Continuous strategy | MLA transformer |
Underneath sits a custom autograd engine covering matmul, conv2d, pooling, and normalization ops, all with gradient-checked backward passes. The SIMD story is what makes it a benchmark project rather than a toy: runtime dispatch selects scalar, AVX2, AVX2+FMA, or AVX-512 on x86, and NEON on ARM64. Rayon handles parallel simulation. BF16 inference caches sit on top.
And there's a PyO3 bridge (import talos_xii as tx) so you can write training scripts in Python without pulling in NumPy or PyTorch. That's the part that punches above its weight.
The author reports roughly 10,000+ simulations per second on their laptop. That's the number the community is being asked to reproduce. And it's the right number to focus on, because sim throughput is what matters for Monte Carlo policy evaluation. A 100x slower stack means 100x fewer confidence-interval improvements per hour.
A rough context table for what "10k sims/sec" means in this regime:
| Approach | Typical sims/sec on CPU | Cold-start cost |
|---|---|---|
| Pure Python + NumPy | 100-1,000 | Low |
| PyTorch small model | 500-5,000 | High (framework load) |
| Hand-written Rust + SIMD | 5,000-50,000+ | Near zero |
| GPU batched (small model) | 10,000-100,000 | Very high (transfer + kernel launch) |
These ranges are order-of-magnitude estimates from the small-model literature, not measurements of Talos-XII specifically. But they frame why 10k+ on CPU with a single binary is a legitimate number worth verifying, not a stunt.
The interesting benchmark question isn't "does Rust beat PyTorch on a big transformer" (it doesn't, and nobody claimed it does). It's "does the framework tax dominate when your model is tiny." Everything about Talos-XII's design points at yes.
This is where the article has to be honest. There's no independent benchmark data yet. The author is asking Reddit for help precisely because they don't have ARM64 numbers, AVX-512 numbers on Zen 4 or Sapphire Rapids, or a GPU comparison. That's the entire ask in the [P] flair post.
So what can actually be evaluated right now:
That gap is the whole point of the Reddit post. Which brings us to the part that will decide whether this project has legs.
The author calls out a component they're not confident about: Adaptive Cache-aware Hyper-Connections. It blends a dense path with a pruned sparse path via a gradient-sensitive gate, adds a Sinkhorn manifold weight projection, and switches between cached, sparse, and dense execution paths based on measured latency.
Photo by Ilya Pavlov on Unsplash
Not gonna lie, this is the part that raises eyebrows. Loosely inspired by manifold-constrained hyper-connections, aimed at compact RL policies on CPU, sounds cool. Whether the speed-accuracy tradeoff generalizes beyond one laptop is the open question.
And it's the right question to be uncertain about. Cache-aware routing that beats a straightforward dense path on one machine can easily lose on another because L2 sizes, prefetcher behavior, and branch predictor state all shift. The Sinkhorn projection specifically has known numerical stability issues at low precision. If you're testing this on BF16 inference caches, that's worth flagging.
So the community benchmark ask is legitimate. This isn't the author overselling; it's the author naming the exact component where they need external validation.
Rust has been slowly building out a native ML story. Candle from HuggingFace covers most inference use cases. Burn is going after training. But those are frameworks, and framework choice comes with framework overhead.
Talos-XII sits in a different niche: single-purpose stacks where you write autograd because the framework's abstractions would cost more than they save. It's closer in spirit to Karpathy's micrograd than to Candle, and it shares the same skeptical stance we've applied to viral projects in our Rio3.5 vs Qwen3.7 benchmark teardown. Except micrograd is 100 lines of Python and Talos-XII ships production SIMD dispatch.
Benchmark data — the kind you see in projects like our agentic LLM benchmark writeup — shows small-model workloads are increasingly the bottleneck in RL research, where you're running millions of environment steps per training run and the model is often smaller than the environment simulator. In that regime, a hand-written Rust stack could plausibly outperform PyTorch by 5-10x on wall-clock throughput. Plausibly. Nobody has clean numbers yet.
If the 10k+ sims/sec number reproduces cleanly on other hardware, and if the ARM64 and AVX-512 paths land in the same order of magnitude, this becomes a legitimate reference implementation for a specific class of problem:
But all of that's conditional on independent benchmarks. As of this writing, the author has one machine's numbers and is asking the community for more. That's the honest state of things.
And it's kind of refreshing. Every other week there's a from-scratch ML project claiming to beat PyTorch. This one says: here's the code, here are the tests, here's the specific component I'm unsure about, please break it.
That's how benchmarks are supposed to work.
The interesting signals over the coming weeks:
The project is on GitHub, tests pass on three OSes, and it's MIT licensed. Low friction to try. If you have unusual hardware (older ARM cores, AVX-512 without AMX, weird cache hierarchies), this is exactly the kind of project where your benchmark numbers matter.
No. It's designed as a CPU-first single static binary with runtime SIMD dispatch across scalar, AVX2, AVX2+FMA, AVX-512, and NEON. There's no GPU path in the current release, and the author is specifically asking whether one should even exist for this workload.
For models under a few hundred thousand parameters, hand-written Rust can plausibly hit 5-10x wall-clock throughput over PyTorch on CPU because the framework's dispatch and Python overhead dominate. For anything larger, PyTorch's optimized kernels and GPU support win decisively. Talos-XII targets only the small-model regime.
Yes. The project ships an optional PyO3 bridge you can import as `talos_xii as tx` in Python. That gives you the autograd primitives and trained models without pulling in the NumPy or PyTorch dependency tree, which is unusual for a from-scratch stack.
ACHF (Adaptive Cache-aware Hyper-Connections) blends dense and pruned-sparse execution paths via a gradient-sensitive gate with a Sinkhorn manifold projection. The author is uncertain because cache-aware routing that wins on one CPU often loses on another due to different L2 sizes and prefetcher behavior, and Sinkhorn has known numerical issues at BF16.
Potentially. The gacha problem is a stand-in for any stochastic policy evaluation where a static probability table can't answer the question. If the SIMD and autograd numbers hold on other hardware, the same stack applies to small RL research, Monte Carlo policy evaluation, and embedded ML where a single binary matters.
