On CPU uplift from Muse, some voices on X take a different view. Let's look at that contrarian take.

'In a base case, serving 100 mn DAU needs 1 GW of power, with only about 0.1 GW from the CPU/VM layer. Depending on how many inference-equivalent model calls each Muse DAU generates per day, 3–4 GW is entirely plausible.'

1. Methodology versus methodology

First, let's compare the setups. Here is how each side frames the calculation.

Freda: 'CPU cores = DAU × (active time/24) × peak-to-avg. × redundancy × per-live VM physical cores.' The key driver is the per-live VM physical cores.

Dolphin Research: 'CPU cores = (A head-node) GPU shipments × CPU cores per GPU head-node + (B fixed layer) total registered users × DAU rate × (active time/24) × 2 vCPU per user × peak-to-avg. ÷ oversubscription ÷ 2 (2 threads per core) + (C elastic layer) active users × task concurrency × CPU cores per sandboxed task.' This explicitly separates GPU-side, user fixed, and elastic layers.

It is clear the other estimate omits CPU cores tied to A head-node (GPU-side). That omission is understandable, since that is not the incremental CPU from agents.

The crux is that agent-driven CPU load mainly comes from the user-side and agent-side. Dolphin Research splits these into B fixed layer and C elastic layer, whereas Freda does not split and instead uses a single per-live VM physical-core assumption.

2. Conceptual conflation

In Freda's math, the pivotal choice is the per-live VM physical cores. She directly references DSec.

The original note states 'DSec also demonstrates stable operation at around: 800 microVMs per node.' She computes 188 physical cores/node ÷ 800 microVMs/node = 0.23 physical cores per live VM.

Note that DSec was designed to create microVM sandboxes on demand when the agent executes code, operates a shell, or reads/writes files. So those microVMs are sandboxes, not user counts. Multiplying sandbox counts by users to size the whole system is plainly incorrect.

Moreover, the 800 microVMs were a demo ceiling. Production peak measured 524 microVMs, implying 188 physical cores/node ÷ 524 microVMs/node = 0.36 physical cores per live VM, not 0.23.

These only match when each user holds exactly one sandbox at peak. Muse clearly does not fit that: user VMs lack a native browser and the broker leases another VM to run a browser image. That alone means a browsing Muse user consumes at least two sandboxes.

Viewed this way, Freda effectively only measured C (elastic layer), omitting CPU core needs for A head-node (GPU-side) and B fixed layer (user-side).

3. Misfit benchmarks

Granted, C (elastic layer) is the main growth engine for Agentic AI demand. Let's focus there. DSec and Muse are different by design, so benchmarking Muse against DSec is not quite appropriate.

DSec is DeepSeek's code-execution sandbox: run a snippet, return, then tear down. Muse's sandbox acts like a persistent personal computer: it carries a browser, persistent memory, Chromium multi-process scheduling, and keeps running after you close the app. The usage profiles and duty cycles diverge materially.

Freda's logic rests on an observed average that 90% of sandboxes consume no more than 5% of requested CPU. But that 5% was measured under DSec's workload mix, diluted by lots of scripting, compiling, and testing; it is not the duty cycle of browser workloads. The assumption does not transfer.

Muse is different. A cross-platform price comparison can trigger up to 146 page loads, each requiring full HTML parsing, JavaScript execution, DOM construction, and rendering. Chromium's JS main thread is single-threaded and CPU-bound, and a modern travel-commerce page can saturate one core for several seconds.

A single customer may run more than one task, hence Dolphin Research introduces a concurrency ratio in C (elastic layer) as a scenario input. It represents the avg. number of tasks per active user, with one task mapping to one concurrent sandbox. This warrants ongoing monitoring as Muse and similar agents scale.

For C (elastic layer), under 100 mn Muse users (30% DAU), 3 hours of daily activity, and a 2x peak-to-avg., assume 1.5 CPU cores per task sandbox (vs. the prior 4 cores, which referenced NemoClaw's quota cap). Using a concurrency ratio as the scenario lever yields a peak of 7.5 mn active users (= 100 mn × 30% × 3/24 × 2).

In the base case, concurrency = 150% (raised from 100%), i.e., an avg. 1.5 tasks per active user. If both CPU and GPU racks are 200 kW each and the CPU-rack share is reduced to 15% (from 25%), this maps to a 1 GW plant footprint.

Under this setup, CPU core demand per GW equals A (GPU-side) 18.36 mn (= 30.6 × 60) + B (fixed layer) 1.88 mn (= 100 mn × 30% × 3/24 × 2 × 2/4 ÷ 2) + C (elastic layer) 16.88 mn = 37.12 mn. That is roughly 2x the original pure GPU-rack plan (vs. 18.36 mn).

With fewer cores assumed per task sandbox, the CPU mix is also lowered, taking the multiplier from 3x to 2x, still well above Freda's estimate. Including extra needs such as Nvidia storage racks (DPUs), Dolphin Research expects Agentic CPUs to drive CPU-core demand to well above 2x.

Overall, Freda's estimate conflates microVMs (task sandboxes) with users, counts only a portion of C elastic layer, and relies on DSec benchmarks that differ materially from Muse. Such references are not suitable.

<End>

2026/09/29 CPU Hot Take 'Muse goes viral: is this CPU's ChatGPT moment?'

Risk disclosure and statements: Dolphin Research Disclaimer and General Disclosure