Can a 12B model show the same "global workspace" structure Anthropic found in frontier models?

[soenning-ai]

TL;DR: Yes. Measured with Anthropic's open-source Jacobian-Lens on a single 12 GB consumer GPU, Gemma 4 12B shows the "global workspace" signature reported for frontier models — participation ratio ≈ 6–7 directions (of 3840) in layers 33–40, with the top 25 directions carrying ~86 % of transport energy. Setup, numbers, and caveats below; all scripts run locally against public HF weights and are available on request.

The question

About two weeks ago Anthropic released the Jacobian-Lens paper (anthropics/jacobian-lens, Apache-2.0). Core finding: in frontier models, the information transported from deep layers to the output flows through a tiny bottleneck of roughly 10–25 directions out of thousands available — a "global workspace" signature. The paper leaves open whether this is an emergent property of scale. So: does a 12B that fits on a living-room gaming PC have it too?

Setup: bf16 gradients through 24 GB of weights on a 12 GB card

The lens needs backward passes through the frozen weights. Gemma 4 12B in bf16 is ~24 GB; the card is an RX 6700 XT with 12 GB (not even officially ROCm-supported). Naive CPU fallback: 17 min per backward pass, at 480 passes per prompt — a non-starter.

The workaround is a device split that keeps autograd off the CPU entirely:

• The upper half of the model lives permanently in VRAM.
• The autograd graph is rooted at the first GPU layer, so backward never crosses the device boundary.
• The lower half runs its forward once per prompt on CPU; its output activations are the (detached) graph root.

	naive CPU	device split
time per backward pass	~17 min	~1.2 s (~800×)
full 100-prompt fit (480 passes/prompt)	—	~24 h

Since the lens targets transport from deep layers to the read-out, rooting the graph mid-stack costs the lower half of the depth range but nothing else (see caveats).

The honest ops chart: 24 h, 100 prompts, five process kills, zero data loss — per-prompt checkpointing.

Results

The signature is there — and tighter than the frontier corridor. Participation ratio of the average-Jacobian spectrum: ~6–7 directions in layers 33–40 (of 3840 possible). Top-25 directions carry ~86 % of transport energy. That is at or below the 10–25 range reported for frontier models.

The robustness check that convinced us: a 5-prompt pilot gave PR ≈ 8–9. Averaging over 100 prompts sharpened this to ≈ 6–7. If each prompt used its own private directions, averaging would widen the bottleneck — instead it concentrated. The directions are genuinely shared across prompts.

One coherent channel across depth: top-25 subspace overlap between all layer pairs stays far above the random baseline (≈ 0.007) throughout L33–44 — the same subspace, not layer-local bottlenecks.

Cross-lingual side finding: on a German prompt ("Die Hauptstadt des Landes, das für Käse und Windmühlen bekannt ist…"), the lens shows the concept locking in English first, mid-stack — "Netherlands" wins layers before "Niederlande" appears. The shared cross-lingual space, directly visible in the residual stream.

Left: English name wins mid-stack on a German prompt. Right: a concept relay — continent → peninsula → Italy → boot.

Caveats

• These are spectra of the average Jacobian; per-prompt concept counting is next.
• Upper half of the model only (the device split roots the graph mid-stack).
• n = 1 — a data point, not a law. (Controls against a from-scratch model and a pretrained-only base model are in the follow-up comment below.)

Reproducibility

Nothing hosted, no accounts touched — the scripts only download public HF weights and run locally. The charts above are not hand-made either: each card is generated by a matplotlib script that computes its numbers (participation ratios, energy concentration, subspace overlaps) directly from the saved lens tensors — so anyone re-running the fit regenerates the exact same figures from their own data. Happy to share everything (fit runner, device-split trick for gradients on ROCm, chart generators) with anyone who wants to point the Jacobian-Lens at their own consumer card.

Transparency: the cost math, the device-split idea, every script — and this post — were pair-built with Claude (Fable 5) in Claude Code over one weekend.

[soenning-ai]

Follow-up: we found where the bottleneck comes from — and it's your pretraining.

Since the original post we ran two controls and a series of state probes. Posting the results here because they may be genuinely useful for understanding the Gemma family — and, if our reading is right, its teacher.

1) The bottleneck is set in pretraining

The open question was: emergent property of any sufficiently trained transformer, or something about how Gemma is made? Two controls, same corpus, same lens:

model	training	PR @ 14–15 layers below read-out	top-25 energy
Gemma 4 12B (IT)	family recipe + post-training	6.1	86 %
Gemma 3 4B (PT, base)	family recipe only	18.8	41 %
Pythia-2.8b	from scratch (The Pile)	459	14 %

The from-scratch control has clean mid-stack semantics (France→Paris, triangle→vertices) but no workspace geometry — its transport stays diffuse (PR up to ~2,000) and averaging more prompts into the lens widens its spectrum (902→999 in the matched window). The pretrained-only Gemma 3 base model, at Pythia's size class, is already twenty times tighter and averaging sharpens it (42→38; Gemma 4: 9.9→7.7) — the directions are genuinely shared across prompts, in a model that has never seen an instruction.

So: not universal (Pythia), not post-training (the base model already has it). What's left standing is the family's pretraining recipe — and the obvious suspect is distillation from a larger teacher. Honest caveats: architecture and data also differ across rungs, n=1 per rung, and these are spectra of the average Jacobian. A puzzle we'd love a hint on: the PT model's lowest layers (L0–9) read ultra-tight (PR 3–7) with very large σ₁ — is that expected from the recipe?

2) The lens reads carried state — including reactions to feedback

Background: we run a Gemma 4 12B autonomously in a home-built agent harness (deterministic kernel, every call ledgered, 100+ wake cycles). That gives us real behavioral episodes to replay through the lens. The measurement trick: two contexts that end in the same byte-identical suffix — at those positions any residual-stream difference is pure carried state, and Gemma's massive-activation outlier dims cancel out of the Δ for free.

Findings, briefly:

• Feedback content is readable as state, word for word. 41 tokens after a critical-vs-praising feedback block ended, the difference-lens reads out inefficient / disorganized / repetitive vs. praised / appreciated — cross-lingually, layer-consistent (L37–40, Δlogit ±30). Criticism also measurably shifts the model from "explore and report" toward "plan first, step one now" (robust across three paraphrase pairs; a thought-channel-suppression effect we initially saw was not robust — noting it because pre-registered negatives should get reported too).
• A real failure cascade carries a state synthetic probes never produced. We replayed a logged episode where the agent failed the same edit twelve times. Its own failed turns, verbatim, produce a mishap/self-correction family (unfortunately / oops / sorry / correcting) at the turn opening. Third-person descriptions of failure don't — only self-authored failure does.
• Pruning the failed turns defuses it. Same context with the failed turns removed: the family is essentially gone, and thought-channel mass at the turn opening goes 0.06 → 0.90. The doomed context crowds reflection out in favor of reactive correction; the cleaned one opens into thinking. "Prune failed turns from context" went from caretaking hunch to a mechanistically supported intervention in our kernel.

Why we're posting this here

If the workspace geometry is inherited through distillation, then Gemma is — in the nicest possible sense — a low-noise window into its teacher's family traits, measurable on a 12 GB consumer card. The state read-outs above (feedback uptake, failure-cascade buildup, context-hygiene effects) would then not just be Gemma quirks but recipe-level properties. That seems worth knowing, and it's cheap to check: we're happy to share all scripts (fit runner, split-device trick for gradients on ROCm, difference-lens probes) — everything runs against public HF weights, nothing hosted.

Two questions for anyone from the team reading: (1) Is pretraining distillation the right suspect for the tight transport, or is there a recipe ingredient we're not thinking of? (2) Is the ultra-tight lower half of the PT model expected?

Method note: Anthropic's Jacobian-Lens (anthropics/jacobian-lens, Apache-2.0), bf16 gradients through frozen weights, single RX 6700 XT. Full caveat list in the attached cards. Drafted in collaboration with Claude, which also pair-built the pipeline.

[soenning-ai]

Qwen run is finished.

Same 4B architecture, same corpus, same 20-prompt J-Lens fit — one rung is
Qwen3-4B-Base, the other is the post-trained Qwen3-4B. The base model already
has a real narrow transport channel. Post-training doesn't conjure it from
nothing; it keeps it much tighter much closer to the output:

layer 15:  Base PR 2.7  |  IT PR 1.7
layer 20:  Base PR 15.3 |  IT PR 4.0
layer 22:  Base PR 99.3 |  IT PR 15.2
layer 30:  Base PR 543  |  IT PR 139

We have a new result card with all of them.

[soenning-ai]

The code and the data behind this post are now public: jlens-small-models

Everything I claimed in this thread is now checkable. The repo has the fit, apply and
spectrum scripts for all four models, the exact 150-prompt wikitext corpus, the raw
spectrum logs, and the figure generators that produced every card I posted here.

Four of the seven figures rebuild from the shipped logs alone — no GPU, no model weights,
no downloads. If you want to check that Gemma 4's participation ratio really is ~6 where
Pythia's is 459, it is one pip install and one script away, and it takes seconds.

What I deliberately did not ship is a fitted lens. The Gemma 4 lens is a 413 MB file
and it would have saved you an afternoon of GPU time — but a lens I hand you is a lens you
have to take my word for, and the entire point of this thread is that you don't have to.
Point the lens at Gemma and run it yourself. The scripts are set up to do exactly that,
checkpointing after every prompt so an interrupted fit costs you one prompt, not a day.

The caveats from the original post travel with the code, and the README states them plainly:
this is averaged transport rather than per-prompt concept counting; scale, architecture,
data and post-training are all confounded across these models; and nothing here is a causal
proof of distillation. The comparison that would isolate it — the same family at the same
scale, before and after — is one only you can run.

The Qwen identity numbers are in there too, framed as narrowly as they deserve: a
post-training-specific self-name binding, with third-person control prompts that move the
other way. It is not evidence about anyone's training data, and I would rather say that
loudly in my own README than have someone else read it into the figures.

The two open questions from my follow-up still stand, and the code is there if it helps you
answer them for yourselves.