The generated web: real speed, and no ground truth to be wrong against

On 14 August 2026, a developer who posts as Alok benchmarked Qwen3.8-27B — the dense 27B model in Alibaba's Qwen3.8 line — on his own RTX 4090, and got 65 tokens/second decode with native multi-token prediction. A few weeks later, once Cerebras added the same checkpoint to its Shared Tier, he tried it there instead, and posted this:

you can just hallucinate the entire internet with Qwen 3.8 27b running at 2,000 tokens/second? part 2 of turning @cerebras + @Alibaba_Qwen 3.8 27B into an OS: built an offline browser with zero network calls and mounted it directly the JIT ubuntu desktop. no wifi. no scraping. zero packets sent to external CDNs.

The follow-up framing, which is the one worth taking seriously: at this speed, browsing isn't retrieving files from a server, it's querying an alternate reality. Full operating systems, virtual worlds, complex simulation engines — existing purely as model weights. Zero gigabytes stored on disk, just pure interactive reality streamed on demand.

expand

The demo is real, the number is real (with some caveats below), and the underlying observation — that a latency threshold changes what an interface can be, not just how fast it loads — is genuinely worth working through. So: is 2,000 tokens/second real, why does Cerebras get it and nobody else does, what does the arithmetic on an actual web page say about where that speed matters, and where does the whole idea stop working.

The number, and which number

Cerebras's own published figure for Qwen3.8-27B on the Shared Tier is about 1,850 output tokens/second, at $0.99 / $1.49 per million input/output tokens, on a model that is genuinely dense — 27B parameters, no MoE routing to hide behind. That figure is real in the sense that matters most: it is Cerebras's own number for this exact checkpoint, not a projection — their model page for qwen-3.8-27b lists it as ~1850 tokens/sec — and it shows up consistently across their inference docs and third-party coverage from the same week.

One spec worth keeping straight, because it gets restated wrongly: Qwen ships the checkpoint with a 262,144-token native context, but Cerebras does not serve all of it. The same model page lists 64k on the free trial and 128k on paid tiers. For a demo that regenerates a whole page from scratch per click, that ceiling never comes up. For anything that wants to carry a session forward, it is the first wall you hit.

It is also not quite the number in the tweet. Looking closely at Alok's own recording, there are three different tok/s readings on screen simultaneously: an ambient "CEREBRAS AI 1,520 tok/s" status in the desktop's top bar, a fixed "1,950 tok/s" badge in the browser's own titlebar, and a genuinely live per-request counter on the synthesis progress line that I watched read 758, 1,830, 722, 843, and 1,042 tok/s across five different page loads in the same clip. None of these three are wrong, exactly — they're measuring different things (a smoothed background figure, a configured ceiling, and the instantaneous rate of whatever request is actually in flight) — but it's a good demonstration that "tokens per second" is never one number even inside a single continuous demo. The tweet's round 2,000 is the most generous read available from any of them, including Cerebras's own 1,850. Call it what it is: optimistic rounding of a real, fast, but noisy figure — not a fabricated one.

If you want the number rather than a badge, the API hands it to you. Every Cerebras chat completion comes back with a time_info object next to usage, carrying queue_time, prompt_time, completion_time and total_time, all documented in Cerebras's chat-completions reference. That makes the measurement two divisions, and it is the only tok/s figure in this whole story that nobody had to read off a screen:

import os
from cerebras.cloud.sdk import Cerebras
 
client = Cerebras(api_key=os.environ.get("CEREBRAS_API_KEY"))
 
r = client.chat.completions.create(
    model="qwen-3.8-27b",
    reasoning_effort="none",
    messages=[{"role": "user", "content": "Emit the full HTML for youtube.com as it looked in 1999."}],
)
 
print(r.usage.completion_tokens / r.time_info.completion_time)  # decode-only rate
print(r.usage.completion_tokens / r.time_info.total_time)       # what a UI badge sees

Those two lines print different numbers, and the distance between them is the entire ambiguity. In the example response Cerebras prints in those same docs, completion_time is 0.01440533 against a total_time of 0.022999626968 — decode is about 63% of the wall clock, with queueing and prompt processing eating the rest. Divide by total_time instead of completion_time and a genuine 1,850 tok/s decode rate reports as roughly 1,160. That is, to within the noise, exactly the band the demo's live counter sits in. I can't prove that's what the demo's counter does — its source isn't public — but a counter measuring round-trip wall clock is a much simpler explanation for "advertised 1,850, observed 722–1,830" than the hardware underdelivering.

expand

Why Cerebras, specifically

The reason a dense 27B model can run this fast for one user, with nobody else to share the request with, is architectural, and Cerebras is unusually direct about it. Their WSE-3 wafer — 4 trillion transistors, 900,000 cores, fabbed on TSMC's 5nm process across almost an entire 300mm wafer — puts 44GB of SRAM directly next to the compute logic, reachable at 21 petabytes/second. From Cerebras's own explanation of why that matters for inference:

That is the actual mechanism behind decode being memory-bandwidth-bound, made concrete: an H100 has to stream every weight matrix out of HBM for every single token, over and over, and HBM bandwidth is the ceiling. Cerebras's SRAM bandwidth is high enough that the round trip essentially disappears. Crucially, this advantage doesn't depend on batching multiple users together — a GPU reaches high aggregate throughput by serving many concurrent requests off the same weights-in-flight; Cerebras is close to its peak rate even at a single request, because there was never a slow trip to external memory to amortize in the first place. That is exactly the shape this demo needs: one browser, one request at a time, nobody to batch with.

I looked for a rigorous, same-model batch-1 number for Qwen3.8-27B on an H100 to make that comparison directly, and could not find one — every H100-vs-Cerebras table I found (including Cerebras's own comparison materials) uses Llama-3.1-70B, not this model, to illustrate the pattern: H100 batch-1 throughput around 550 tok/s scaling up to roughly 12,000 tok/s at batch 64, against Cerebras holding a flat ~2,100 tok/s regardless of batch size. That's a different, larger dense model, so I'm not going to present it as Qwen3.8-27B's number — it illustrates the shape of the tradeoff correctly (Tim Dettmers, on an unrelated 405B/8×H100 comparison: "Cerebras is fast for batch size 1 but slow for batch size n. GPUs are slow for batch size 1 but fast for batch size n") without me inventing a figure for the model this article is actually about.

What I do have, for this exact checkpoint, is consumer hardware — which is the more honest comparison anyway, since it's what a person actually runs at home:

Notice the 3090 outrunning the nominally faster 4090 — that's not a typo, it's two different people optimizing to two different depths (speculative-decode tuning versus a stock recipe), and it's worth remembering every time a benchmark claims one number for "a 4090": the software stack is doing as much work as the silicon. Depending which row you pick as the honest baseline, Cerebras is somewhere between 15× and 130× faster than the same model on hardware a person can own outright.

The arithmetic that actually matters

None of that throughput matters until you attach it to an actual page. A real webpage is a lot of DOM: the 2024 Web Almanac puts the median page at 594 DOM elements and a compressed HTML transfer size of 33KB — uncompressed runs up to 147KB at the 90th percentile. Converting bytes to tokens at the usual rough rate (about 4 bytes per token, a slight underestimate for tag-dense markup), raw real-world HTML typically runs 10,000 to 60,000 tokens; one measurement of a genuinely heavy page (a Reddit thread, full of comment chrome) came in at 52,899 tokens of HTML rendering 477 tokens of visible text — a 111× ratio between what ships and what a reader actually sees.

A model asked to write a page rather than scrape one produces something leaner — no analytics tags, no thirty class names per div, no embedded JSON state — so I'll work across a range instead of pretending to know the one true number: a short result page around 800 tokens, a full article page around 3,000, a media grid like a YouTube homepage around 8,000, up to a heavy, real-world-style page around 20,000. That range is the whole argument, once you know where it lands against how long a human is willing to wait.

Human-factors research has used the same three thresholds since long before LLMs existed. Jakob Nielsen laid them out for the Nielsen Norman Group in 1993, based on decades-older human-factors work, and has revisited them periodically to note they haven't moved: 0.1 second feels instantaneous — caused by you, not the computer; 1 second keeps your flow of thought unbroken, though you notice the delay; 10 seconds is the point past which people give up and go do something else, and the interface needs to show progress or lose them.

Drag that slider to a media-grid-sized page (8,000 tokens) and the crossing is stark. At Cerebras's ~1,850 tok/s, the entire page finishes in about 4.3 seconds — inside the band where a spinner is fine, not outside it. At the tuned RTX 3090, the same page takes about a minute; on a default-configuration Mac, close to ten minutes. First paint tells the sharper story: assuming the browser only needs the first ~8% of the document (header, nav, the first visible row) before it can paint anything — which is a conservative assumption, browsers have painted HTML progressively as it streams in since long before this demo existed — Cerebras delivers that in under 350 milliseconds, comfortably inside "feels instant." The default Mac doesn't reach first paint until roughly 34 seconds have passed, well past the point most people have already clicked away.

That compounding is the real, underrated point in the demo's favor: HTML has always been a streaming format on the browser side, and here the model is streaming on the server side too, so the two streams compose directly. There's no backend doing an opaque computation before anything ships — the "network," in this fake internet, is exactly as fast as the model's own decode rate, and nothing else in the chain adds a serial wait. That's a real architectural point, not just a fast number.

The call, and the one parameter that decides the latency

None of this needs exotic plumbing. Cerebras's documented streaming example for this exact model is four lines of setup and a loop — and it ships with one argument that matters more than everything else on the page:

from cerebras.cloud.sdk import Cerebras
import os
 
client = Cerebras(api_key=os.environ.get("CEREBRAS_API_KEY"))
 
stream = client.chat.completions.create(
    model="qwen-3.8-27b",
    reasoning_effort="none",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Hello!"},
    ],
    stream=True,
)
 
for chunk in stream:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="")

That is verbatim from the chat-completions reference, and reasoning_effort="none" is in it for a reason. Cerebras's model page states that for qwen-3.8-27b reasoning is enabled by default at high — so a naive call spends an unbounded thinking trace before it emits the first < of your document. At 1,850 tok/s a 2,000-token think is a full second of dead air ahead of first paint, which is the entire latency budget the previous section just spent. Every millisecond of the "feels instant" argument above assumes reasoning is off. For markup synthesis you want the model typing immediately, and that one string is how.

The client half is even less code, because there is no client-side render loop to write. Here is the Node version of the same stream, verbatim from the streaming docs:

const stream = await client.chat.completions.create({
  messages: [{ role: 'user', content: 'Why is fast inference important?' }],
  model: 'qwen-3.8-27b',
  stream: true,
});
for await (const chunk of stream) {
  process.stdout.write(chunk.choices[0]?.delta?.content || '');
}

Swap process.stdout.write for a write into the HTTP response body and you're done — the browser's HTML parser is the render loop. It has consumed partial markup and painted incrementally since the 1990s, so tokens arriving from a model and bytes arriving off a socket are the same event as far as the parser is concerned. Nothing buffers the document to completion, nothing diffs a virtual DOM per token, and there's no frame budget to blow. That's why the first-paint arithmetic above holds in practice and not just on paper: the fast path is the one you get by doing nothing clever.

What's actually being demonstrated

Here's the part worth being precise about. The pages this demo produces are plausible, not correct. There is no ground truth for "YouTube in 1999" to check against, for a very specific reason: YouTube didn't exist in 1999. It was registered in February 2005 by Chad Hurley, Steve Chen, and Jawed Karim, and opened to the public that May — six years after the year the demo is asked to render it in.

expand

That's not a gotcha — it's the reason the demo works, and it's worth stating plainly rather than either hyping it or sneering at it. When there's no real page to be wrong against, the model only has to be plausible: a 56k-modem upload limit, a webring badge, "Made with Notepad & HTML," all stylistically dead-on for 1999, none of it checked against anything, because there's nothing to check it against. That's why "YouTube in 1999" and "YouTube in 2045" are the two best possible demo prompts — they're maximally forgiving. It's also, precisely, the easiest case a generative interface can be given.

expand

The moment a page has to reflect something real — your actual balance, today's actual price, whether a seat is actually still available, what's actually in an unread email — hallucination stops being a feature and becomes the entire problem, and the fact that tokens arrive at 1,850/second buys you nothing at all, because the bottleneck was never rendering speed. It's whether the number is right. At that point you're doing retrieval, full stop, no matter how fast the chip generating the surrounding markup can go. That is the boundary: generation is for surfaces where there is no ground truth to violate; retrieval is for surfaces where being wrong is the failure mode, not a charming period detail.

The serious version of this idea

Stripped of the "hallucinate the internet" framing, "generate the interface, fast, per request" is an active and legitimate research direction — it's most of what people mean by generative UI. Vercel shipped exactly this idea as a product feature: AI SDK's streamUI let a model stream literal React Server Components straight out of its own tool calls, so a chatbot could hand back a rendered chart or a booking widget instead of a wall of markdown:

const result = await streamUI({
  model: openai('gpt-4o'),
  prompt: 'Get the weather for San Francisco',
  text: ({ content }) => <div>{content}</div>,
  tools: {
    getWeather: {
      description: 'Get the weather for a location',
      inputSchema: z.object({ location: z.string() }),
      generate: async function* ({ location }) {
        yield <LoadingComponent />;
        const weather = await getWeather(location);
        return <WeatherComponent weather={weather} location={location} />;
      },
    },
  },
});

That's straight out of Vercel's own RSC docs, and the shape repays a close read, because it is not the demo's shape. text handles the model's prose. The interesting branch is generate: the model picks the tool and fills its arguments, then hand-written code calls getWeather and hands the answer to a hand-written WeatherComponent. The model never emits markup. It chooses a shape and supplies a lookup key; the numbers come from a real function. Even in the most model-driven UI API anyone shipped, the part that has to be right was never generated.

It's a telling footnote that Vercel's own migration guide now marks that approach — AI SDK RSC — as experimental, says flatly that "we do not recommend using it for stable production environments," and directs teams to AI SDK UI instead, where a model drives a fixed set of client components through structured tool-call data rather than generating the component tree itself. In production, in other words, the industry backed away from "let the model generate the whole interface" toward "let the model choose and fill fixed shapes with real data" — which is the same boundary this article keeps landing on, reached independently.

This site has made the opposite-side argument before, in tiny, specialized models in the browser: instead of one enormous model on one enormous remote chip generating everything, a small model runs locally, handles a narrow task, and works with data that's actually on the page. Both bets take the same premise seriously — that crossing a latency threshold changes what a client can be, not just how snappy it feels — and they're not competing, they're complementary: a tiny local model deciding what needs synthesizing and rendering the parts that have real data in hand, calling out to something Cerebras-fast only for the parts that are genuinely being imagined rather than looked up.

None of this is brand new, either, and it's worth saying so. Websim shipped "the whole internet, generated page by page as you click" back in April 2024, built on Claude 3.5 Sonnet; at least one open-source project since (Solipnet, on a local Llama 3 8B) did a version of the same thing. What's new in this demo isn't the concept — it's doing it with zero network calls, mounted as an actual OS-level browser, fast enough that generation time stops being the dominant cost of a page view. The contribution here is latency. Worth saying plainly, because it's the honest version of why this demo matters at all.

Zero gigabytes, non-zero dollars

"Zero gigabytes stored on disk" is literally true — there's no file sitting on a drive for this page, because the page didn't exist a second ago. It is not the same thing as free. You've traded a storage cost that already rounded to nothing for an inference cost that doesn't.

At a medium page (4,000 output tokens) and Cerebras's published rate, one page costs about $0.006 — six-tenths of a cent. Serving the equivalent ~16KB of static HTML from a mainstream CDN costs on the order of $0.0000014. That's roughly 4,600× more expensive, per page, to generate than to serve — and that's the favorable comparison; against the cheapest CDN tiers available, the multiple runs into the tens of thousands. Scale it up and the shape holds: 100,000 page loads this way costs on the order of $600 in tokens, against roughly 14 cents to move the same bytes off a CDN. That is the actual price of "the whole internet, hallucinated on demand" — not zero, just moved from a balance sheet you can see (disk) to one that's easy not to look at (a token meter).

There's a practical ceiling built into this too, and it is not where you'd guess. Cerebras's published rate limits for qwen-3.8-27b are 5 requests/minute, 30K uncached tokens/minute and 1M tokens/day on the free trial, and 300 requests/minute with 150K uncached tokens/minute on the paid Developer tier. Those are rates, not budgets — they refill every minute — so the arithmetic runs the opposite way from how it's usually quoted. One continuous stream at 1,850 tok/s burns 111,000 tokens/minute, which sits under the Developer ceiling: a single tab generating flat out never trips the limit at all. Two tabs do. On the free tier the ceiling is 30K/minute, about 16 seconds of decoding per minute of wall clock, plus a hard 1M tokens/day — roughly nine minutes of total generation, or about 250 medium pages, and then you are finished until tomorrow.

Prompt caching doesn't rescue the bill either, and Cerebras is unusually plain about why. Their caching docs state that "there is no additional fee for using prompt caching. Input tokens, whether served from the cache or processed fresh, are billed at the standard input token rate." Caching buys headroom against the uncached TPM limit, not a discount: cached tokens still count toward total TPM and still cost $0.99/M. So a browsing session that carries its own history forward — to keep "reality" consistent as you click — gets monotonically more expensive the longer it runs. The version of this demo that stays cheap is the one that treats every page as a fresh, stateless request with nothing remembered from the last click, which is also, not coincidentally, the version with the least persistent world to speak of.

Where this leaves it

The number is real, on the generous end of honest. The architecture behind it — a model's full weights sitting in on-wafer SRAM instead of a round trip to HBM — is a genuinely different way to buy speed, and it's the correct explanation for why a dense 27B model, alone, with no one to batch it against, can hit four figures of tokens/second. The arithmetic on an actual page shows exactly why this speed and not last year's crosses from "loading spinner" into "feels instant," and streaming compounds that for free. All of that is the demo working exactly as advertised.

What it demonstrates, though, is generation into a vacuum: pages with no ground truth, priced as if inference were free. Move one step toward a page that has to be right rather than merely plausible, and the speed stops being the interesting number — correctness is, and correctness was never what this architecture was fast at.