拿 DSec 来套？Muse 如何真正撬动 CPU 需求 - 热门赛事

关于Muse对CPU需求的拉动作用，海豚君此前已展开过讨论（详见回顾）。近期，我们在X平台上留意到一种不同看法，现将其呈现如下：

“在基准场景中，支撑1亿日活跃用户需要1GW电力，其中仅约0.1GW来自CPU/VM层。具体取决于每个Muse日活跃用户每天产生的推理等效模型调用次数，3到4GW的规模是合理的。”

接下来，海豚君将分析具体差异：

计算方法对比

首先，对比双方的计算方式：

Freda： “CPU核心数=日活跃用户数×（活跃时长/24）×峰均比×冗余系数×每活跃虚拟机物理核心数”；

海豚君： “CPU核心数=（A头节点）GPU出货量×每GPU头节点核心数+（B固定层） 总注册用户×日活率×（活跃时间/24）×每用户2vCPU×峰均比÷超售比÷2（单核两线程）+（C弹性层） 活跃用户×任务并发率×每任务沙箱核心数”。

可以看出，对方的测算中未包含A头节点（GPU侧）的CPU核心数。这可以理解，这部分并非Agent CPU带来的增量。

关键在于，Agent CPU主要贡献来自用户侧和Agent侧，海豚君将其拆分为B固定层和C弹性层，而Freda的测算未作拆分，直接用一个活跃虚拟机物理核心数来设定。

概念混淆

Freda测算的关键在于活跃虚拟机物理核心数的选定，她直接参照了DSec。

原文提到“DSec also demonstrates stable operation at around：800 microVMs per node.”她的计算方式是：188物理核心/节点÷800微虚拟机/节点=0.23物理核心每活跃虚拟机。

需要指出的是，DSec的设计目标是：当Agent需要执行代码、操作shell、读写文件等工具时，按需创建微虚拟机沙箱来隔离执行。因此，这里的微虚拟机实际上对应的是沙箱数量，而非用户数。用这个数值乘以用户数来推算整体规模，显然是不正确的。

另一方面，Freda选取的800个微虚拟机只是演示上限，根据生产实测峰值表现为524个微虚拟机，用188物理核心/节点÷524微虚拟机/节点=0.36物理核心每活跃虚拟机，而非她给出的0.23。

这两者仅在“一个用户在峰值时恰好只持有一个沙箱”时相等。而Muse显然并非如此：用户虚拟机本身没有浏览器，代理需要租用另一台运行浏览器镜像的虚拟机。仅此一项，一个正在浏览的Muse用户就至少占用两个沙箱。

由此可见，Freda仅测算了C（弹性层）的部分，未涵盖A头节点（GPU侧）和B固定层（用户侧）的CPU核心需求。

不恰当的参照对象

当然，C（弹性层）本身也是Agentic AI需求的主要增长来源，暂且审视这部分：

DSec与Muse本质不同，以DSec作为参照并不合适。DSec是DeepSeek用于执行代码的沙箱：运行一段代码、返回结果、销毁；而Muse的沙箱是常驻的个人计算机： 带有浏览器、持久记忆、Chromium多进程调度，关闭应用后仍在运行。

Freda的整个逻辑建立在“90%的沙箱平均只用不超过申请CPU的5%”这一实测数据上。但这个5%是在DSec的负载构成下测得的，是被大量“运行脚本、编译、测试”稀释后的平均值，并非浏览器负载的占空比。

Muse的情况完全不同。一次跨平台比价可能触发多达146次页面加载，而每次页面加载都涉及完整的HTML解析、JavaScript执行、DOM构建和渲染。 Chromium的JavaScript主线程是单线程且CPU密集型的，一个现代商旅页面的渲染会占满一个核心数秒之久。

单个用户不一定只有一个任务，因此海豚君在C（弹性层）中引入了并发率的概念（情景假设），即对应单个活跃用户的平均任务数（一个任务对应一个并发沙箱）。这需要关注后续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的测算中混淆了微虚拟机（任务沙箱）与用户的概念，她仅计算了C弹性层的一部分，并且在计算过程中参照的DSec与Muse的方式本身存在显著差异，这样的参照显然不恰当。

本文来自微信公众号 “海豚投研”（ID：haituntouyan），作者：海豚君，36氪经授权发布。