关于Muse对CPU需求的拉动作用，海豚君在前两天的文章中已有所探讨（可点击回顾）。我们注意到，X平台上有人提出了不同看法，先来看看这些观点：
“在基准情境下，服务1亿日活跃用户需要1GW电力，其中仅约0.1GW来自CPU/VM层。这取决于每个Muse日活跃用户每天产生的推理等效模型调用次数，3到4GW的电力需求是合理的。”
接下来，海豚君再来分析具体差异：
首先，我们对比一下计算方法：
Freda： “CPU核心数=日活跃用户数× (活跃时长/24)×峰均比×冗余系数×每live VM物理核心数”；
海豚君： “CPU核心数=(A头节点) GPU出货量×每GPU头节点核心数+ (B固定层) 总注册用户×日活率×（活跃时间/24）×每用户2vCPU×峰均比÷超售比÷ 2(单核两线程)+ （C弹性层） 活跃用户×任务并发率×每任务沙箱核心数”。
可以看出，Freda的计算中未包含A头节点（GPU侧）的CPU核心数。这可以理解，因为这并不算Agent CPU带来的增量部分。
关键在于，Agent CPU主要带来的增量来自用户侧和Agent侧两部分，海豚君将其拆分为B固定层和C弹性层，而Freda的计算没有进行拆分，而是直接用live VM物理核心数来设定。
Freda的计算中，关键在于live VM物理核心数的选择，她直接参考了DSec。
原文提到“DSec also demonstrates stable operation at around：800 microVMs per node.”她据此计算：188物理核心/节点÷800 microVMs/节点=0.23物理核心 per live VM。
值得注意的是，DSec的设计目标是：当Agent需要执行代码、操作shell、读写文件等工具时，按需创建microVM沙箱来隔离执行。因此，这里的microVM实际上不是用户数，而是沙箱数。之后再用这个数去乘以用户数来测算整体规模，显然是不对的。
另一方面，Freda选用的800个microVM只是演示上限，生产实测峰值表现为524个micro VM，因此应为188物理核心/节点÷524 microVMs/节点=0.36物理核心 per live VM，而不是0.23。
这两者只有在“一个用户在峰值时恰好只持有一个沙箱”时才相等。而Muse显然不是这样，用户VM本机没有浏览器，broker需要租用另一台运行浏览器镜像的VM。仅此一点，一个正在浏览的Muse用户就至少占用两个沙箱。
由此可见，Freda只计算了C（弹性层）的部分，并未涉及A头节点（GPU侧）和B固定层（用户侧）的CPU核心需求。
当然，C（弹性层）本身也是Agentic AI需求的主要增长来源，我们暂且来看这部分：
DSec和Muse本质不同，用DSec作为参照并不合适。DSec是DeepSeek用于运行代码执行的沙箱：运行一段代码、返回结果、销毁；而Muse的沙箱是常驻的个人计算机： 带浏览器、带持久记忆、带Chromium多进程调度、关闭App仍在运行。
Freda的整个逻辑建立在“90%的沙箱平均只用不超过申请CPU的5%”这一实测数据上。但这个5%是在DSec的负载构成下测得的，是被大量“跑脚本、编译、跑测试”稀释后的均值，并非浏览器负载的占空比。
Muse的情况完全不同。一次跨平台比价可能触发多达146次页面加载，而每次页面加载都包含完整的HTML解析、JavaScript执行、DOM构建和渲染。 Chromium的JS主线程是单线程且CPU密集型的，一个现代商旅页面的渲染会占满一个核心好几秒。
单个客户不一定只有1个任务，因此海豚君在C（弹性层）中引入了并发率的概念（情景假设），即对应单个活跃客户的平均任务数（1个任务对应1个并发沙箱），这部分需要关注后续Muse等Agent的使用情况。
对于C（弹性层）的计算，在1亿Muse用户（日活30%）、每天活跃3小时、峰均比2的情况下，假定每个任务沙箱需要的CPU核心数为1.5个（此前的4个是参照NemoClaw的配额上限），以并发率进行情景假设：其中峰值活跃达到750万（=1亿×30%×3/24×2）
中性情况对应并发率=150%（从此前的100%上调），即单个活跃客户平均有1.5个任务。如果单个CPU机架和GPU机架均为200kW，CPU机架的占比下调至15%（此前假定占比25%），对应着1GW的配套工厂。
在此情况下，单GW对应的CPU核心需求量=A（GPU侧）1836万个（=30.6×60）+B（固定层）188万个（=1亿×30%×3/24×2×2/4/2）+C（弹性层）1688万个=3712万个，大约是原来纯GPU机架方案的2倍左右（相比1836万个）。
在调低单个任务沙箱所需CPU核心数的情况下，也相应调低了CPU配比，对应CPU需求倍数从3倍调整至2倍，仍远高于Freda的预测。考虑到英伟达存储机架（DPU）等部分的额外需求，海豚君预估Agentic CPU有望带动CPU核心数需求达到2倍以上。
整体来看，Freda的计算混淆了microVM（任务沙箱）和用户的概念，她仅计算了C弹性层的一部分，并且在计算过程中参照的DSec和Muse方式本身就有很大差异，这样的参考明显不合适。
本文来自微信公众号 “海豚投研”（ID：haituntouyan），作者：海豚君，36氪经授权发布。
