6.1.10 · D3Scaling & Efficient Architectures

Worked examples — Long-context architectures

3,303 words15 min readBack to topic

This page is the "drill ground" for Long-context architectures. The parent note gave us four families of tricks — sparse attention, linear attention, state-space models (SSMs), and memory-augmented lookup. Here we hit every case with numbers you can check by hand.

Before we start, one promise: every symbol below is either defined here or built in the parent note. If you see and feel unsure, read it as "the cost grows in proportion to , the number of tokens." Nothing more magical than that.


The scenario matrix

Every cell below is covered by at least one worked example. The Ex # column tells you where.

Cell class Specific case What it stresses Ex #
Sparse — normal window , few global tokens linear saving Ex 1
Sparse — degenerate window (window = whole sequence) collapses back to Ex 2
Sparse — limiting (each token sees only itself) information loss extreme Ex 2
Linear — normal precompute , one query associativity payoff Ex 3
Linear — zero input a query whose feature map hits a zero denominator division-by-zero guard Ex 4
SSM — decay sign eigenvalue vs vs stable / blow-up / neutral Ex 5
SSM — limiting (tiny step) recurrence identity Ex 6
Memory — normal local + top- retrieval additive cost Ex 7
Word problem pick an architecture for a real budget design decision Ex 8
Exam twist crossover length where two costs tie solve for Ex 9

Ex 1 — Sparse attention, the normal case

Forecast: guess now — will the total be closer to , or closer to ? Write down your guess.

  1. Regular tokens. There are regular tokens, each doing comparisons. Why this step? Each regular token only looks inside its sliding window — that is the whole point of "local."

  2. Global tokens. Each of the global tokens compares against all tokens. Why this step? Global tokens are the escape hatch that preserves document-level information the local windows would miss.

  3. Total. Why this step? Total sparse cost is — here .

  4. Full attention baseline.

Verify: , a reduction. Sanity check the formula ? No — careful: the parent formula double-counts if we let global tokens also be regular. We removed them ( regular), so is the honest count. Units: comparisons. ✓

Figure — Long-context architectures

Figure s01 — reading the sparse mask. The grid is the full attention matrix: row is a query, column is a key, and a coloured cell means "query actually looks at key ." The burnt-orange diagonal band is the local window — notice it hugs the diagonal, exactly cells wide, because each token only reaches two neighbours on each side. The deep-teal cross (top two rows and left two columns) is the two global tokens: full rows and full columns because they see everyone and everyone sees them. The cream cells are the comparisons we skip — and that skipped area, roughly cells, is precisely the compute we saved. This is the picture behind the vs count above.


Ex 2 — Sparse attention, the two degenerate corners

Forecast: which of these two extremes gives you back plain Transformer attention?

  1. Case (a): . Cost . Why this step? When the window equals the whole sequence, "local" attention is full attention — we bought nothing. Complexity is back to .

  2. Case (b): . Cost . Why this step? Each token sees only itself. This is the cheapest possible — but it is also the most information-starved: no token can mix with any neighbour. Useless as attention, but it exposes the lower bound.

Verify: Case (a) equals the full-attention count from Ex 1 exactly ✓. Case (b) equals , the theoretical floor (you must at least look at yourself). Monotonic in : as goes , cost goes . ✓


Ex 3 — Linear attention, the normal payoff

This reworks the parent example so you can trust the machinery, then we extend it.

Forecast: the raw value list is ; will the answer land inside that range or outside?

  1. Feature-map the keys. . Why this step? The whole linear-attention idea is to replace with so we can reorder the sum.

  2. Precompute (a 3-vector since ). Why this step? is the key–value summary, built once for all queries — this is where the comes from.

  3. Precompute . Why this step? is the normalizer — it plays the role the softmax denominator played.

  4. Numerator and denominator for , with :

  5. Output. .

Verify: lies inside ✓ (a weighted average of values must). If we skipped normalization we'd report , obviously outside the value range — the division by is what keeps it honest. ✓


Ex 4 — Linear attention, the zero-denominator corner

Forecast: guess what happens to .

  1. Denominator. . Why this step? A zero denominator means "this query has no measurable similarity to anything" — division is undefined.

  2. Numerator. . So we face . Why this step? Both collapse together; the ratio is genuinely undefined, not infinite.

  3. The engineering fix. Real implementations add a small (e.g. ) to the denominator: Why this step? A cleaner fix is to choose a feature map whose components are always strictly positive, so the denominator can never truly hit zero. A common choice is .

Verify: with , output , finite ✓. The parent note's starts with a constant , so its denominator for real inputs — the constant-1 feature is itself a guard. ✓


Ex 5 — SSM, the sign of the eigenvalue (negative, positive, and zero)

First, a quick definition so nothing here is a mystery symbol.

Forecast: which sign gives a state that decays (safe), which explodes, and what happens exactly at zero?

  1. Where even comes from. The equation has one exact solution: over any interval of length , the state multiplies by , i.e. . Why this step? We are not approximating here — is the classic "growth proportional to current amount" equation whose solution is an exponential. Advancing one token = advancing time by , so the exact per-token update is "multiply by ." That is where is born; every number below just plugs into it.

  2. Case (a) : . Why this step? Negative real part old information fades — this is the stable, useful regime for long context.

  3. Case (b) : . Why this step? Positive real part state blows up. This is why S4 constrains eigenvalues to have negative real part.

  4. Case (c) (the boundary): . Why this step? This is the razor's edge — neutral stability. The state neither fades nor grows; it holds its value forever (a perfect infinite memory). In principle attractive, but fragile: any tiny numerical or learned nudge of off zero tips you into decay () or blow-up (). Real S4 keeps eigenvalues strictly in the left half-plane precisely to stay on the safe side of this edge.

Verify: (a) ratio between successive terms constant, magnitudes shrinking ✓; (b) ratio constant, magnitudes growing ✓; (c) every , ratio exactly ✓.

Figure — Long-context architectures

Figure s02 — three fates of a state. The horizontal axis is the token step ; the vertical axis is the state's magnitude . The burnt-orange curve () bends down toward the baseline — that curve is memory forgetting gracefully, the regime we want. The plum curve () rockets upward off the top of any fixed axis — numerical death, and the reason we forbid positive eigenvalues. The deep-teal flat line () sits perfectly level at — the neutral boundary from step 4, holding its value forever. Seeing all three at once is the whole stability argument in one glance: the sign of chooses which curve your model rides.


Ex 6 — SSM, the tiny-step limiting case

Forecast: as we sample time more and more finely, does the state change more or less per step?

  1. Evaluate at . . Why this step? Small means each token advances time only a sliver, so sits just under .

  2. One step barely moves : . Why this step? In the limit , , the identity — the state is essentially frozen between steps. Continuous time is recovered.

  3. Contrast : , a big jump per step (from Ex 5).

Verify: for any finite ✓; at , is within of ✓. The step size is the knob converting continuous dynamics to discrete tokens. ✓


Ex 7 — Memory-augmented, the additive-cost case

Forecast: will the attended count be nearer or nearer ?

  1. Local. recent tokens. Why this step? Nearby context (grammar, immediate topic) is best served by a dense local window.

  2. Retrieved. from memory. Why this step? Far-away-but-relevant facts come through selective retrieval, not brute force.

  3. Total attended. . Why this step? Cost is additive: , not multiplicative.

  4. ANN lookup cost per query . Why this step? FAISS-style indices scale like , so even a huge memory bank is cheap to query.

Verify: (a reduction) ✓. ✓ — searching 10k items costs about the work of 13 comparisons, not 10,000. Units: tokens attended, comparisons for search. ✓


Ex 8 — Word problem, the design decision

Forecast: guess the order of magnitude in gigabytes for full attention.

  1. Full-attention score memory. floats. At 2 bytes each: bytes GB. Why this step? This is per layer, per head — clearly impossible on any single device.

  2. SSM memory. A fixed state of dimension plus a kernel of a few thousand entries — call it floats. To compare fairly we must use the same 2 bytes/float assumption we used for full attention: bytes kB. Why this step? The state is a fixed-size summary of all history; it does not grow with . Stating the byte-per-float assumption explicitly is what makes the two numbers directly comparable — mixing float widths would make the ratio meaningless.

  3. Ratio (in floats, so the byte assumption cancels). . Why this step? Since both counts use 2 bytes/float, the bytes cancel and we can compare raw float counts. SSM is about million times lighter on this axis — decisive for a memory-bound device.

  4. The recommendation. Choose an SSM backbone (Ex 5's stable state) as the workhorse, optionally bolted to a small local-attention window (Ex 2's ) for sharp nearby detail. Pure full attention is ruled out by step 1's GB. Reserve memory-augmented retrieval (Ex 7) only if the task needs verbatim recall of far-back facts, since it adds an index to maintain. Why this step? This maps the abstract cost numbers onto a concrete build: fixed memory favour the fixed-size state, accept its lossy compression, and buy back local precision cheaply with a small window.

Decision: SSM (+ small local attention) for a fixed-memory, million-token device; accept that the fixed state may lose some fine detail an attention layer would keep.

Verify: floats B B GB ✓ (since B GB). SSM floats B B kB ✓. Float-count ratio ✓.


Ex 9 — Exam twist, the crossover length

Forecast: guess whether the crossover is around a hundred, five hundred, or a thousand tokens.

  1. Set equal. . Why this step? The crossover is exactly where switching architectures stops helping — the break-even point an exam loves to ask for.

  2. Solve. Divide both sides by (valid for ): . Why this step? Below the window already covers everything, so sparse = full anyway.

  3. Interpret the regions.

    • : since , we get , so full is cheaper (the window is oversized and wasteful).
    • : , so sparse is cheaper — and the gap widens fast.

Verify: at : and , equal ✓. At : , sparse cheaper ✓. At : , full cheaper ✓.

This connects directly to computational complexity: the crossover is where the curve overtakes the line.


Recall Self-test

Ex 1 total comparisons for ::: When window , sparse attention collapses to complexity ::: (identical to full) Linear-attention output for in Ex 3 ::: The guard against a zero denominator in linear attention ::: add small / use strictly-positive feature maps like elu(x)+1 Sign of eigenvalue that keeps the SSM state stable ::: negative (so ) What happens at for an SSM state ::: neutral — , state holds its value forever (fragile boundary) Crossover length where meets with :::

See also the parent's kernel-approximation view via kernel methods, the retrieval angle in RAG, and the compression view in the information bottleneck.