vizmaya desk · 2 November 2026

Phone flash is 1,333 times too slow to be memory

A phone's flash answers in 40,000 ns. A phone's memory answers in 30 ns.

A new design says it can close the gap. So far, only in simulation.

Memory (DRAM): 30 ns
Flash (UFS): 40,000 ns

Drawn to scale. The top bar is under one pixel wide, so it shows as a tick.

Source: paper Table 1, p.1. The 1,333x is computed: 40,000 ns / 30 ns.

Why does a phone need flash to be fast at all?

1 · The old world

A big AI does not fit in a phone's fast memory.

The paper gives an AI 8 GiB of the phone's fast memory, called DRAM.

The biggest model it tests is 155 GiB. That is about 19 times the room.

Source: Table 2 (p.9); 8 GiB budget (p.3). The 19x is computed: 155.02 / 8 = 19.4.

So where does the rest of the model sit?

2 · The old world

Flash answers 1,333 times slower than DRAM.

The rest of the model sits in flash. Ask flash for data and the first answer takes 40 µs. DRAM takes 30 ns.

That wait caps an AI at 1.3 to 7.2 tokens a second. At DRAM speed it could reach 18 to 102. A token is a small piece of a word.

Source: Table 1 (p.1); token caps p.4. Computed: 40,000 / 30 = 1,333; 10.8 GB/s over 1.5 to 8.5 GB per token.

And what about the notes an AI keeps while it works?

3 · The crack

The AI's notes outgrow the fast memory too.

An AI writes a note for every token it reads. These notes are the KV cache, and they grow with every word.

One 27B model adds 34 KiB per token. A 223,000-token chat fills 7.2 GiB and the longest fills 31 GiB. Fast memory holds 8 GiB.

Source: p.4 and Table 2 (p.9). Computed check: 34 KiB x 223,000 tokens, and x 962,000 tokens.

Is there a memory that is big, fast and writable?

4 · The crack

Memory is a promise about time.

The wire between a phone's processor and its memory has rules. A chip on it must give a first answer in 25 to 35 ns. Then it must send a small chunk every 1.67 ns.

Flash breaks the first rule by more than 100 times.

Source: p.4 (rules in Eq. 1 and 2); Table 1 (p.1).

Could anyone build flash that keeps the deal?

5 · The turn

The authors built flash that senses in under 7.5 ns.

They call it 3D FeNOR. Memory cells are stacked in layers above the chip's own circuits. Some hold 3 bits for the model, and others hold 1 bit and rewrite fast.

With the support circuits, a full read takes 25 to 35 ns. That fits the deal.

Reported by the authors. Their device papers were not checked here.

Source: p.5 and p.6. Sensing under 7.5 ns comes from cited papers [1] and [9]. The 25 to 35 ns total is partly modeled.

One bank is still 3 times too slow. How do they fix that?

6 · The turn

One bank is too slow. Four taking turns are enough.

One bank hands over 96 bytes every 15 ns. That is 6.4 GB/s. The wire needs 19.2 GB/s.

Start four banks 5 ns apart. Together they give 25.6 GB/s.

Source: p.5 (6.4 GB/s); p.7 to 8 and Fig. 5a. Computed: 4 x 6.4 = 25.6.

Cells hold 3 bits. AI weights use 4. What now?

7 · The turn

Wiring fixes the 3-bit versus 4-bit mismatch for free.

AI weights are stored in 4 bits. The flash cells hold 3. Giving each weight two cells wastes 33% of the space.

The authors wire 3 weights across 4 cells. Nothing is wasted and no time is added. Capacity is 1.5 times higher than padding.

Source: p.8 and Fig. 5b. The 33% and 1.5x are the paper's figures.

That settles reading. What about writing?

8 · The turn

Slow writes finish in the background.

Writing a 1-bit cell takes 100 ns. The phone expects a write to be done in about 15 ns.

A small buffer takes the write at once, so the phone moves on. The flash catches up later. If the AI reads that data first, the buffer answers.

Source: p.6, p.8 and Fig. 5c. The start of the 100 ns bar is read from the figure.

Now, where should each kind of data live?

9 · The turn

Put each thing where its lifetime fits.

A boss AI plans. Helper AIs do small jobs and leave. In the paper's tests, one boss runs four helpers.

Models never change, so they go in 3-bit flash. The boss's notes last all session, so they go in 1-bit flash. A helper's notes die with its job, so they stay in DRAM.

Source: p.7 and Fig. 4; four helpers in the tests: p.9.

So how fast does the whole team run?

10 · The result

In simulation, the AI team runs 21.4 times faster.

On phone flash (UFS 5.0) the team makes 1.6 tokens a second. With NORmal it makes 33.6.

Across 7 workloads NORmal is 8.9 to 28.0 times faster than UFS. On six single-model tests it ends 0.12% to 0.31% below a phone with unlimited DRAM.

Simulated. No phone was built.

Sources: p.9 (Fig. 7a), p.10, p.11 (Fig. 11). The 21.4x is the paper's own figure. Chart labels are rounded.

Does it survive being written to all day?

11 · The result

Writing all day wears flash out. NORmal's 1-bit cells barely notice.

Flash survives a limited number of rewrites. HBF, a rival stacked flash, is rated for 100,000. One heavy chat uses 110 to 632 of them.

At one heavy chat a day that is as little as 5.2 months. NORmal's cells are rated for over 100 billion and use 0.8 to 7.2 per chat. A phone should last 5 years.

Simulated and computed. The HBF case is the authors' upper bound.

Source: Fig. 12 (p.11); p.12. Computed: 100,000 / 632 / 365 = 0.43 years.

So what do you do with all this?

12 · The payoff

Ask where the model lives and how fast that place answers.

How big is the model?

The paper's models run from 4.43 to 155.02 GiB. The AI's room in fast memory is 8 GiB.

How fast does its home answer?

Phone flash takes 40 µs. Memory takes 30 ns. That gap decides how quick the AI feels.

Our reading, not a result from the paper.

Source: Table 1 (p.1), Table 2 (p.9). Interpretation by vizmaya desk.

Does NORmal beat every rival?

13 · The limits

A rival wins on light work. NORmal wins on long chats.

HBF has its own 200 GB/s link. On 6 of 7 workloads it is 1.10 to 1.73 times faster than NORmal.

NORmal shares the phone's 153.6 GB/s wire. But on chats past 256K tokens, HBF takes 2.78 to 6.33 times longer.

Simulated by the authors.

Source: p.1 and p.10 (HBF faster on 6 of 7); Fig. 9b (p.10) and p.11 (long chats).

What else has the paper not shown?

14 · The limits

The proof is a simulation. Here is what is missing.

  • No phone built. All speed results are simulated.
  • Energy, total delay and layer count are modeled or projected.
  • No cost, no data-retention time, no error rates.
  • Test traces come from coding agents, not phone use.
  • The rival is simulated by the authors' own group.
  • A preprint. Not peer reviewed. Not replicated.
  • Contested: the paper's "167 GB planner" (p.2) does not match its default planner, 94.3 GB (Table 2, p.9).

Source: p.2, p.6, p.9, ref. [34], and the vizmaya research file of 2 November 2026.

Who did the work?

vizmaya desk · 2 November 2026

Sources and method

Research by Zhuoran Li and Chen Gu (equal contribution), with Zhuohang Bian, Haochen Yu, Yibo Zhao, Xuxiao Yang, Zhaori Cong, Jinshan Yue, Qing Luo, Di Geng, Ling Li and Youwei Zhuo. Peking University, the Institute of Microelectronics of the Chinese Academy of Sciences, and HKUST (Guangzhou), China.