Regarding the impact of Muse on CPU demand, Dolphin Research has already delved into this topic a few days ago (click here for a recap). We observed some contrasting viewpoints expressed by an individual on X. Let's first examine these differing opinions:

"Under standard conditions, serving 100 million Daily Active Users (DAUs) necessitates 1GW of electricity, with merely around 0.1GW stemming from the CPU/VM layer. Depending on the volume of inference-equivalent model calls each Muse DAU generates daily, an estimate of 3 to 4GW seems entirely plausible."

Now, let's delve into the specific discrepancies identified by Dolphin Research:

1. Comparison of Calculation Methods

Firstly, let's contrast the calculation methodologies:

Freda's Approach: "CPU core count = DAU × (active duration/24) × peak-to-average ratio × redundancy factor × physical core count per live VM";

Dolphin Research's Method: "CPU core count = (A Head Node) GPU shipments × core count per GPU head node + (B Fixed Layer) total registered users × daily active rate × (active time/24) × 2vCPUs per user × peak-to-average ratio ÷ oversell ratio ÷ 2 (single core with two threads) + (C Elastic Layer) active users × task concurrency rate × core count per task sandbox".

It's evident that Freda's calculation omits the CPU core count for the A Head Node (GPU side). This omission is understandable, as it's not considered an incremental contribution from Agent CPU.

The crux lies in the portion primarily driven by Agent CPU, which encompasses two facets: the user side and the Agent side. Dolphin Research bifurcates this into the B Fixed Layer and the C Elastic Layer, whereas Freda's calculation does not make this distinction but instead directly employs the physical core count per live VM.

2. Conceptual Misinterpretation

In Freda's calculation, the crux is the selection of the physical core count for live VMs, which she directly borrows from DSec.

Initially stating, "DSec also showcases stable operation at approximately: 800 microVMs per node," she derives 188 physical cores/node ÷ 800 microVMs/node = 0.23 physical cores per live VM.

It's crucial to note that DSec's design objective at the time was to instantiate microVM sandboxes on-demand to isolate execution when Agents needed to execute code, operate shells, read and write files, among other tasks. Thus, the microVMs here represent the number of sandboxes, not users. It's clearly flawed to then multiply this figure by the number of users to gauge the overall scale.

Conversely, the 800 microVMs Freda utilized are merely the demonstration limit. Based on actual production peak performance, it's 524 microVMs. Hence, 188 physical cores/node ÷ 524 microVMs/node = 0.36 physical cores per live VM, not the stated 0.23.

These two figures are only equivalent when "a user occupies precisely one sandbox during peak times." Muse evidently doesn't operate this way; the user's VM lacks a local browser, necessitating the broker to rent another VM running a browser image. This alone implies that a browsing Muse user occupies at least two sandboxes.

Thus, it seems Freda only accounted for the C (Elastic Layer) portion and neglected the CPU core requirements for the A Head Node (GPU side) and the B Fixed Layer (user side).

3. Inappropriate Reference Framework

Certainly, the C (Elastic Layer) itself is also the primary driver of growth for Agentic AI demand. Let's scrutinize this segment:

DSec and Muse are fundamentally distinct, rendering DSec an unsuitable reference. DSec is a sandbox employed by DeepSeek for code execution: run a piece of code, return the result, and terminate; whereas Muse's sandbox is a persistent personal computer: equipped with a browser, persistent memory, Chromium multi-process scheduling, and remains operational even when the App is closed.

Freda's entire rationale is predicated on the observation that "90% of sandboxes utilize, on average, no more than 5% of the requested CPU." However, this 5% was measured under DSec's load composition, diluted by a substantial volume of "script running, compilation, and testing," and doesn't reflect the duty cycle for browser loads.

Muse operates entirely differently. A cross-platform price comparison may trigger up to 146 page loads, with each page load involving complete HTML parsing + JavaScript execution + DOM construction + rendering. Chromium's JS main thread is single-threaded and CPU-intensive, and rendering a modern business travel page can monopolize a core for several seconds.

Given that a single customer may have multiple tasks, Dolphin Research introduces the concept of concurrency rate in the C (Elastic Layer) (scenario assumption), corresponding to the average number of tasks per active customer (one task equates to one concurrent sandbox). This aspect warrants attention for subsequent Agent usage like Muse.

For the C (Elastic Layer) measurement, with 100 million Muse users (30% daily active), 3 hours of daily activity, and a peak-to-average ratio of 2, assuming each task sandbox requires 1.5 CPU cores (the previous 4 was referencing NemoClaw's quota limit), utilizing concurrency rate for scenario assumption: where peak activity reaches 7.5 million (=100 million x 30% x 3/24 x 2)

The neutral scenario corresponds to a concurrency rate of 150% (an increase from the previous 100%), implying that a single active customer has, on average, 1.5 tasks. If a single CPU rack and GPU rack are both 200kW, and the proportion of CPU racks is adjusted down to 15% (previously assumed to be 25%), this aligns with a 1GW supporting factory.

In this scenario, the CPU core requirement per GW = A (GPU side) 18.36 million (=30.6*60) + B (Fixed Layer) 1.88 million (=100 million x 30% x 3/24 x 2 x 2/4/2) + C (Elastic Layer) 16.88 million = 37.12 million, roughly double the original GPU-only rack solution (compared to 18.36 million).

By diminishing the number of CPU cores required per task sandbox, the CPU ratio is adjusted accordingly, with the CPU demand multiplier revised from 3x to 2x, still significantly surpassing Freda's prediction. Considering additional demand for NVIDIA storage racks (DPUs) and other components, Dolphin Research estimates that Agentic CPU could still propel demand for CPU cores to more than double.

Overall, in Freda's calculation, the concepts of microVMs (task sandboxes) and users are conflated. She only calculated a portion of the C Elastic Layer and referenced DSec and Muse, which are fundamentally dissimilar, making such a reference clearly inappropriate.

- END -

// Reprint Authorization

This article is an original piece by Dolphin Research. Authorization is required for reprinting.

// Disclaimer and General Disclosure

This report is intended solely for general comprehensive data purposes, meant for general viewing and data reference by users of Dolphin Research and its affiliated institutions. It does not take into account the specific investment objectives, investment product preferences, risk tolerance, financial situation, or unique needs of any individual receiving this report. Investors must consult with independent professional advisors before making investment decisions based on this report. Any individual making investment decisions based on the content or information referenced in this report must bear their own risks. Dolphin Research shall not be held liable for any direct or indirect responsibilities or losses that may arise from the utilization of the data contained in this report. The information and data presented in this report are based on publicly available materials and are for reference purposes only. Dolphin Research strives to ensure but does not guarantee the reliability, accuracy, and completeness of the relevant information and data.

The information or opinions expressed in this report shall not, under any jurisdiction, be regarded or construed as an offer to sell securities or an invitation to buy or sell securities, nor shall it constitute advice, inquiries, or recommendations regarding relevant securities or related financial instruments. The information, tools, and data contained in this report are not intended for or proposed for distribution to jurisdictions where distribution, publication, provision, or use of such information, tools, and data would contravene applicable laws or regulations or result in Dolphin Research and/or its subsidiaries or affiliated companies being subject to any registration or licensing requirements in those jurisdictions, or to citizens or residents of those jurisdictions.

This report solely reflects the personal views, insights, and analytical methods of the relevant creators and does not represent the stance of Dolphin Research and/or its affiliated institutions.

This report is produced by Dolphin Research, and the copyright is exclusively owned by Dolphin Research. No institution or individual may, without the prior written consent of Dolphin Research, (i) make, copy, reproduce, duplicate, forward, or distribute in any form any copies or reproductions, and/or (ii) directly or indirectly redistribute or transfer to other unauthorized persons. Dolphin Research reserves all relevant rights.