cd /news/large-language-models/how-i-fixed-my-gpt-2-reproducibility… · home topics large-language-models article
[ARTICLE · art-80928] src=promptcube3.com ↗ pub= topic=large-language-models verified=true sentiment=· neutral

How I Fixed My GPT‑2 Reproducibility Nightmare (Part 2)

A developer fixed a GPT-2 reproducibility bug caused by missing std=0.02 in nn.init.normal_ for embedding and linear projection layers, which inflated initial weight variance and caused validation perplexity to stall above 35. After the fix, the model matched the reported perplexity at 40k steps and the validation loss aligned with the GPT-2 blog post curve. The author advises verifying weight initialization against the original codebase, not just the paper, to avoid weeks of debugging.

read2 min views1 publishedJul 30, 2026
How I Fixed My GPT‑2 Reproducibility Nightmare (Part 2)
Image: Promptcube3 (auto-discovered)

The symptom – loss curves looked healthy for the first few thousand steps, then plateaued 0.2 nats above the OpenAI baseline while the validation perplexity refused to cross the 35‑point mark. I blamed the dataset mix, batch size, even the tokeniser caching. Each check came up clean.

The culprit – in model.py

the normal_

call for embedding layers had a missing std

argument, falling back to a default of 1.0 instead of the 0.02

used in the original papers. That blew out the variance in every embedding table, forcing the transformer to spend precious capacity correcting the initial noise rather than learning meaningful representations.

nn.init.normal_(self.wte.weight)

nn.init.normal_(self.wte.weight, mean=0.0, std=0.02)

I also found the same regression in the linear projection layers after the attention block. Without a consistent std=0.02

the residual stream accumulated variance at every layer, making the final hidden states twice as scattered as they should have been.

Diagnosis path – I dumped the norms of each weight matrix at step 0 and compared them against a reference run from the original gpt-2

repo. The embedding layer was already 8× larger in Frobenius norm. From there a git bisect

on my config changes pointed straight to an overlooked line in the init function.

Re‑run results – after the fix the model hit the reported perplexity at 40k steps, and the validation loss matched the curve published in the GPT‑2 blog post. The training time didn’t change noticeably, so the fix is purely about fidelity, not efficiency.

For anyone trying to reproduce old transformers from scratch: always verify weight initialisation against the original codebase, not just the paper. The papers often omit the exact std

values, and the reference implementations can get damaged by refactoring. A two‑minute sanity check on initial norms can save you two weeks of head‑scratching.

If you want the full diff of all the other small corrections I found along the way, drop a reply. I’ll put together a clean patch set if there’s interest.

Next GPT-5.6 Revenue Surge: How July Beat Q2 →

── more in #large-language-models 4 stories · sorted by recency
── more on @gpt-2 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/how-i-fixed-my-gpt-2…] indexed:0 read:2min 2026-07-30 ·