I reran the performance claims in DBR-2026-05 and DBR-2025-01 on a fifth machine. I also measured something neither paper does: how the browser feels while the model runs. When a local 7B model reads a 4,000-token page at llama.cpp's default batch size, a GPU-heavy page drops most of its frames for the whole 11 seconds. A 64-token batch fixes that for about 10% more time to first token. That fix doesn't carry over to 14B, and the data suggests it won't carry over to smaller Macs either.
The page below repaints only when the benchmark's real frames did. Each replay is one measured trial: 2 seconds idle, then the prefill of a 4,000-token page, then the start of decode. Gaps in the motion are real dropped frames from the run.
Every page idles at 0% dropped with no model loaded. At the default batch, 7B prefill drops 83% of frames on WebGL Aquarium, 64% on the shader page and 30% on MotionMark Arcs. It drops 0% on BBC News and on a light page. Decode drops nothing on any GPU-heavy page.
CPU-only prefill keeps the shader page smooth (0.1%) but takes 104 s instead of 11.5 s. Pausing 16 or 50 ms between 128-token chunks still drops 34–38%. 64-token chunks are smooth with no pause at all. What matters is how long each GPU kernel holds the GPU, not whether the queue has gaps.
On the shader page batch 64 takes 3B from 69% to 0% and 7B from 64% to 1.3%. 14B still drops 31% at 64. A fixed value safe for 14B (32 or less) costs 7B about 17% TTFT on every page, including pages that never needed it.
Safari drops 14.5% during 7B prefill on the shader page (p95 32 ms against a 17 ms budget). Decode drops 0%, and batch 64 brings it to 0% for 6% more TTFT. At 60 Hz each frame has twice the time budget, so the same GPU stalls miss fewer deadlines.
On MotionMark Multiply, a CPU-bound page, GPU inference drops 6–10%. CPU inference drops 22% in prefill and 30% in decode, and four threads still drops 18%. Anything that runs on CPU cores needs its own budget, which matches DBT-2026-09's 12%-of-a-core cap on background embedding.
7B at 4k tokens takes 11.4 s cold and 79 ms when the page is already in the KV cache, so the 640 ms figure only fits a cached prefix. No model gets a cold 4k prefill under 900 ms here. Decode and memory pass easily. 24 GB shows no swap cliff, and Q8 prefills faster than Q2_K.
A frame is dropped when its interval is more than 1.5× the page's own idle median (8.3 ms at 120 Hz, 17 ms in Safari at 60 Hz). Each bar is the median over 5 trials of a full prefill. The numbers are requestAnimationFrame intervals, which track the page's own rendering rather than the compositor.
“A model that starves the compositor produces a janky browser, which testers blamed on the browser rather than the model.”DBR-2026-05
Dart's own paper names the failure. Its research agenda asks for local inference “without the browser becoming unusable while they do”. This is that failure measured, narrowed down to one phase, and given a cheap first fix.
The fix isn't the whole answer. It holds for 3B and 7B on this machine, and the 14B run suggests a base M1 or M2 behaves like this machine running a bigger model. Stage 2 starts with the fix and builds only as much scheduler as the slower machines need.
Inference. Qwen 2.5 Instruct GGUF (bartowski quants) on llama-server, all layers on the Metal GPU unless noted. Every E4 trial prefills a fresh 4,000-token page with the prompt cache off, then decodes 256 tokens.
Frames. Brave opens its own profile and a calibrated page, which idles at 120 fps with no model loaded. A recorder injected over DevTools logs every requestAnimationFrame interval and every long animation frame. The harness marks idle, prefill, decode and gap phases on the same clock.
Dropped frame. A frame whose interval is more than 1.5× the page's own idle median. Each condition gets 5 measured trials after a warm-up. Conditions run in an interleaved order, and the machine stays on AC with nobody touching it.
Pages: a light page (WebGL + scroll), the shader page (raymarch + scroll), WebGL Aquarium with 20,000 fish, MotionMark CanvasArcs (complexity 10,000) and Multiply (2,000), BBC News scrolling, and Safari on the light and shader pages.
Prefill and decode columns are the share of frames dropped in that phase. p95 is the 95th-percentile frame interval during prefill. TTFT is the median time to first token.
ubatch is fixed when llama-server loads the model. "paced cN gM" sends the prompt as separate N-token requests that reuse the cached prefix, waiting M ms between them. That version works without touching the runtime, but it costs about twice the TTFT of setting ubatch.
These are cold prompts with Brave open. The limits come from DBR-2026-05: 900 ms TTFT, 18 tok/s decode and 60% of RAM. Every model passes decode and memory. None passes TTFT at 2k tokens or more.
The paper's 640 ms at 4k only fits a prefix that's already cached.
Prompt (pp) and generation (tg) tokens per second. Q8_0 prefills faster than Q2_K, so on this GPU low-bit quants save memory, not speed.
With 24 GB, 18 GB of other memory slows 7B decode by 6%. Swapping starts between 8 and 14 GB of ballast, and the 2.3× cliff the paper describes never appears.
The rule I fixed before E4 read only the light page, and on that page it said “build the capability gate” (). After the shader page showed 64% drops, I changed it so the worst page decides. Both verdicts are printed in the report.
The raw database, the harness and the generated report are in the repository: github.com/18Abhinav07/DiggingOnDart (bench/results/m4pro-24gb.db.gz, SQLite, and bench/reports/report.md). Running ./reproduce.sh reruns the core result on any Apple Silicon Mac. Live copy of this site: prefill-and-the-frame.pages.dev.
Stage 1 found a cheap fix that works on this machine. It also found evidence that the fix stops working as the GPU gets slower relative to the model. The plan below is in that order: ship the fix, test the small-Mac prediction, and add machinery only when a measurement says the simpler step failed.
Set n_ubatch = 64 for 3B and 7B. On the M4 Pro this takes every GPU-heavy page to about 0% dropped. It costs 9–11% TTFT on heavy pages and about 5% on pages that were already smooth. 14B needs 32 or less.
Decode is left alone. It never dropped frames on a GPU-heavy page at any setting.
Batch 64 works on the M4 Pro because each GPU kernel finishes quickly enough for the page to get the GPU back in time. A 7B batch-64 step there takes about 200 ms in total (4,000 tokens in 12.8 s at 64 per step), and the page still stays smooth. So the total length of a step isn't what matters. The length of each kernel inside it is, and that scales with tokens per batch times model width, divided by GPU speed.
14B prefills 2.07× slower than 7B on this machine (23.7 s vs 11.4 s cold at 4k). That is the same ratio as the M4 Pro to a base M2 with 10 GPU cores in llama.cpp's own Apple Silicon numbers. So 14B on the M4 Pro is a stand-in for 7B on a base M2 or M3, and at batch 64 it still drops 31%.
7B Q4_0 prompt processing (pp512), from the llama.cpp Apple Silicon benchmark thread (ggml-org/llama.cpp discussion #4167). The prediction is what I'd expect for 7B Q4_K_M from the proxy ratio. It hasn't been measured.
./reproduce.sh settles it on a real Air in 15 minutes.
Small fixed values cost a lot more on slow machines. Batch 32 already costs 7B 17% TTFT on the M4 Pro. A cold 4k prefill on an M1 takes 35–40 s before any penalty, so a constant small enough for the slowest machine taxes every other machine all the time.
llama_decode k tokens per call, so k can change every step with no reload. llama-server can't do this, because ubatch is fixed at load. My HTTP version (one request per chunk) costs +23% at 64 tokens, against +11% for ubatch 64. The first measurement is whether in-process chunking closes that gap.If a table entry still drops frames on real pages, add feedback: read missed deadlines for the frontmost tab in 250 ms windows, halve k when drops rise above the page's idle rate, and grow it back additively while frames stay clean. The table gives the floor and ceiling.
Stop rule: if the table alone is safe on a base M1 for less than 10% extra TTFT, ship the table and don't build the controller.
dartsched, a small C++ layer over llama.cpp: chunked prefill through llama_decode, the mode switch, a pluggable frame signal, and the controller only if step 4 is triggered.“We hire slowly and deliberately, and every person here shapes both the product and the culture. If none of these fit but you think you belong here, write to careers@dartbrowser.com and tell us why.”dartbrowser.com/careers
I saw an SDE 1 opening on LinkedIn and started researching the browser. The more I read, the clearer it got: Dart wants to run real models on the user's own machine, inside a browser that still has to feel fast. That's the problem I want to work on.
My background sits on both sides of it. I've worked with privacy cryptography in blockchain systems, and I've built AI evaluation, inference, data pipelines and verification systems. Keeping data on the user's side and making inference actually work are the two things I've spent my time on, and a browser that runs AI locally is where they meet.
Rather than only write to you, I wanted to show you how I work. I spent a couple of days with your papers and picked one sentence from DBR-2026-05: a model that starves the compositor makes a janky browser, and testers blame the browser. Then I set out to measure it. This site is what came out of it: where the jank comes from, a fix that works today, and where that fix will break next.
I won't claim I'm a browser builder. What I love is engaging with a problem, digging into it, finding the creative angle, and keeping at it until the solution works for the people it's meant for, from many surfaces, not just tech.
Give me a chance and I'll deliver the results, even if that means breaking Chromium down to its bits and studying it from scratch. I'm confident I can do that.
The papers measure tokens per second. I measured the frames a person actually sees, because that is what gets blamed on the browser.
The decision rule was written before the frame runs. When the data forced an amendment, both verdicts stayed in the report, and every prediction here is labelled as one.
From cryptography to inference pipelines to the frame loop of a browser, I follow the failure down to wherever it lives and learn that layer.
It's the same habit I used in my SDP work, which this walkthrough shows.
Here it was the jank DBR-2026-05 describes. I reproduced it on third-party pages and pinned it to one phase: prefill, not decode.
A harness that records every frame next to every inference phase on one clock, with 717 trials and 0 errors, all stored in SQLite.
64% → 1.3% dropped for +11% TTFT, plus the cases where that fix stops working, written down before building anything bigger.
Run ./reproduce.sh on an M1 or M2 to confirm or refute the small-Mac prediction, then take Metal GPU traces to check the kernel-length explanation directly.
Feed llama_decode k tokens per call and find out whether it closes the gap between the +23% of my HTTP version and the +11% of ubatch 64.
Build the per-device, per-model table and switch batch size on page weight, then check it against the success criteria on both machines.
Follow the stop rule. Then point the same signal at speculative decoding, background embedding and CPU thread budgets.