alt.hn

3/4/2026 at 5:56:04 PM

NanoGPT Slowrun: Language Modeling with Limited Data, Infinite Compute

 https://qlabs.sh/slowrun

by sdpmas

3/5/2026 at 8:56:02 PM

This is very much in line with what I found fascinating about optimizing microgpt for speed (0). Or rather, what I was able to do with it after doing so. It's so small and so fast to train, you can really dig deep into the optimization landscape. I've spent all my free time this past week digging into it.

0: https://entrpi.github.io/eemicrogpt/ (The writeup is from a few days ago, and I'm still running experiments before I do a big rewrite. Slowrun is good food for thought.)

by easygenes

3/4/2026 at 10:23:10 PM

There was this very interesting paper out of Stanford this last September about pretraining under the unlimited compute but limited data paradigm[0]. Pretty much exactly the same thing but with ~200M training tokens instead.

[0] https://www.alphaxiv.org/abs/2509.14786

by linolevan

3/4/2026 at 10:33:51 PM

yeah, we do incorporate some of the findings from the paper in our repo! like aggressive regularization and ensembling.

by sdpmas

3/5/2026 at 12:33:30 AM

I see you already mention diffusion - iirc there was a result not too long ago that diffusion models keep improving with more epochs for longer than AR models do.

by _0ffh

3/5/2026 at 12:37:09 AM

diffusion is promising, but still an open question how much data efficient they are compared to AR. in practice, you can also train AR forever with high enough regularization, so let's see.

by sdpmas

3/4/2026 at 11:55:14 PM

> Directions we think are wide open

> Second-order optimizers and natural gradient methods

Do second order optimizers help improve data efficiency? I assumed they’d help you get to the same minimum faster (but this is way outside my wheelhouse).

by bee_rider

3/5/2026 at 12:35:53 AM

yes! typically the optimizer that trains faster also get better data efficiency. it maybe not be absolutely true, but that has been my observation so far. also see https://arxiv.org/pdf/2510.09378 for second-order methods.

by sdpmas

3/5/2026 at 2:33:19 AM

That still looks like a “converge faster” paper.

https://arxiv.org/abs/2006.10732

The above provides a nuanced theoretical view. GD inductive bias is probably better unless your model is misspecified

by vladf

3/5/2026 at 1:21:46 AM

Fundamentally I don't believe second-order methods get better data efficiency by itself, but changes to the optimizer can because the convergence behavior changes. ML theory lags behind the results in practice.

by alyxya

3/5/2026 at 8:48:23 AM

Very interesting benchmark, excited to see what comes out of this. Considering humans are enourmously more sample efficient compared to today's models, it seems clear there's a lot of room to close that gap. The fact that they hit 5.5x in the first week with relatively straightforward changes suggests we're nowhere near the ceiling for data efficiency

by jbergqvist

3/5/2026 at 8:50:17 AM

absolutely!

by sdpmas

3/5/2026 at 7:51:00 AM

I think there will be good headway in using the part-trained model to generate itself more training data in the form of making itself tasks, completing those tasks with many different approaches, evaluating which solution is best (using the same LLM as judge), and then differentially training on the best solutions vs the worst ones.

The challenge is that such an approach almost certainly requires a model with RLHF post-training, but this needs to be done in the pre training phase. But with infinity compute, this isn't an issue - you simply do the post-training many times.

by londons_explore

3/4/2026 at 7:52:39 PM

I like the idea of flipping the constraint. Most ML benchmarks assume unlimited data and limited compute, so people optimize for speed.

If high-quality training data becomes the real bottleneck, then the interesting question is how much signal you can extract from the same dataset when compute is cheap.

by lzaborowski

3/4/2026 at 9:08:02 PM

Curious about the baseline choice. modded-nanogpt was optimized for wall-clock speed, not data efficiency, so it seems like an unusual reference point for this kind of benchmark. Why not vanilla NanoGPT?

by kseniamorph

3/4/2026 at 10:09:43 PM

Modded-nanogpt is also much more data efficient than vanilla napogpt, even if some of the individual optimizations trade off higher throughput for worse data efficiency.

by timshel1

3/4/2026 at 10:32:46 PM

yes, agreed, modded-nanogpt is already a data-efficient variant of original nanogpt. just that the kinds of algorithms it allows are somewhat constrained because it optimizes for wall clock time.

by sdpmas

3/4/2026 at 7:23:44 PM

Very cool idea. Interested to see how this progresses. One question: how worried are you about over-training on this particular dataset? i.e. instead of generalizing you lean more toward memorization? Obviously you leave out a validation set but since you're meta-optimizing the model itself by its performance on the validation dataset you're still at risk of over-fitting.

by archermarks

3/4/2026 at 7:31:13 PM

yes, good point. right now, it's somewhat hard to overfit because the meta-optimization extracts tiny bits of information. but over time, we will switch the validation set to some other random subset of the FineWeb or even entirely OOD datasets!

by sdpmas

3/5/2026 at 6:53:05 PM

The question is not if but when. I hope the project authors acknowledge the problem directly: it is not merely a risk; it is a statistical certainty given enough time. So, what's the plan?

At the very least, track it. How will the project maintainers instrument this?

by xpe

3/5/2026 at 7:48:57 AM

This feels like optimizing for local minima, but more verbosely. Even the epoch shuffling doesn’t seem like it would get them out of that pitfall.

by rcarmo

3/4/2026 at 7:59:11 PM

Amazing job!

by navvyeanand

3/4/2026 at 6:43:19 PM

Reminds me a fair bit of the BabyLM challenge. It would be good to give them a shout-out and see how this challenge differs.

by suddenlybananas

3/4/2026 at 6:59:50 PM

hey, it's Samip (behind the Slowrun repo). yeah that's a fair point, we will mention them in the blog. but there are a couple of major differences: 1. our emphasis is on using more compute to get better data efficiency. this is important because there are lots of hacky chances that will get lower loss, but when compared to general methods that leverage a lot of compute, they don't do so well. and you can already see how this emphasis on compute leads to different methods to BabyLM! 2. our reasoning behind the repo is not anything to do with how much data a child sees. and our dataset is not tailored towards that either. it's simple pretraining on random subset of the internet. we know there are better training algorithms that get lower loss on that data, and we are finding those.

by sdpmas

3/5/2026 at 2:54:06 PM

I feel like you really need to mention BabyLM. For example you have:

> Directions we think are wide open ... Curriculum learning

BabyLM and offshoot published a pretty convincing body of work on exactly that (which suggests it's not particularly relevant to LM training).

As I read your page, I really felt like the brevity-thoroughness tradeoff went the wrong way.

by Mumps

3/4/2026 at 7:04:20 PM

also, BabyLM is more of a conference track / workshop than an open-repo competition which creates a different vibe

by soraki_soladead

3/4/2026 at 11:31:00 PM

This looks awesome!!! I’m curious on the ensemble: does it mean “train 8 different models and pick the best one”? That’s what my mind jumps to, but that also seems wrong, because I assume we could just keep increasing the number of different models you train to get a win.

by refulgentis

3/5/2026 at 12:33:38 AM

no ensembling means train 8 models and during inference avg logits of all 8 models to make a prediction.

by sdpmas

3/5/2026 at 3:08:09 PM

Maybe some newer references are better, but my mind went to the Model Soups paper[1]:

The conventional recipe for maximizing model accuracy is to (1) train multiple models with various hyperparameters and (2) pick the individual model which performs best on a held-out validation set, discarding the remainder. In this paper, we revisit the second step of this procedure in the context of fine-tuning large pre-trained models, where fine-tuned models often appear to lie in a single low error basin. We show that averaging the weights of multiple models fine-tuned with different hyperparameter configurations often improves accuracy and robustness. Unlike a conventional ensemble, we may average many models without incurring any additional inference or memory costs -- we call the results "model soups."

[1]: https://arxiv.org/abs/2203.05482

by magicalhippo

3/5/2026 at 7:58:20 AM

That doesn't seem all that different to a MoE architecture.

by jiggawatts

3/5/2026 at 8:47:30 AM

It's the opposite of a MoE architecture in many ways. MoE splits every individual feed-forward layer into many tiny subnetworks, only a small number of which contribute to the layer output, and they get trained together to complement each other.

Ensembling makes multiple copies of the entire model, trains them independently on the same task, and then has every copy contribute to the output.

Reducing computation vs. increasing it; operating at per-layer granularity vs. whole model; specialization vs. redundancy.

by yorwba

3/5/2026 at 12:33:13 AM

[dead]

by aplomb1026

3/4/2026 at 8:34:55 PM

[flagged]

by riajain2525

3/5/2026 at 2:08:38 AM

[flagged]

by shubhamintech

3/4/2026 at 11:35:06 PM

[flagged]

by STARGA

3/4/2026 at 11:39:03 PM

really no shame in comments like these?

by whimsicalism

3/4/2026 at 11:53:20 PM

It seems like best etiquette would be to have a username with "bot" in it and include something in the post explicitly indicating it's a bot (e.g. a signature).

This isn't even a new problem where a good cultural solution hasn't been figured out yet. Reddit has had bot etiquette for years.

by devinplatt