本文來自微信公眾號： 海豚研究 ，作者：海豚君，原文標題：《拿 DSec 來套？Muse 如何真正撬動 CPU 需求》

對于Muse對CPU的帶動，前兩天海豚君已經做了討論（點此回顧）。我們注意到X上有人提到了不一樣的觀點，先來看看不一樣的聲音：

“基準情形下服務1億DAU需要1GW電力，其中只有約0.1GW來自CPU/VM層。取決于每個Muse DAU每天產生多少次推理等效模型調用，3到4GW完全說得通?！?/p>

下面海豚君再來討論下具體差異：

1.計算方式對比

首先我們來對比下計算方式：

Freda：“CPU核數(shù)=DAU×(活躍時長/24)×峰均比×冗余系數(shù)×每live VM物理核數(shù)”；

海豚君：“CPU核數(shù)=(A頭節(jié)點)GPU出貨量×每GPU頭節(jié)點核數(shù)+(B固定層)總注冊用戶x日活率x（活躍時間/24）×每用戶2vCPUx峰均比÷超售比÷2(單核兩線程)+（C彈性層）活躍用戶×任務并發(fā)率×每任務沙箱核數(shù)”。

可以看出對方的測算中，并沒有測算A頭節(jié)點（GPU側）的CPU核數(shù)。當然這也能理解，這個也不能算Agent CPU帶來的增量部分。

關鍵在于Agent CPU主要帶來的部分，就是用戶側和Agent側兩部分，海豚君將其拆分成B固定層和C彈性層兩塊，而Freda的測算并沒有進行拆分，而是直接用一個live VM物理核數(shù)來給設定。

2.概念的混淆性

Freda的測算中，關鍵在于live VM物理核數(shù)的選定，她直接參照了DSec。

原本提到“DSec also demonstrates stable operation at around：800 microVMs per node.”她測算的是，188物理核/節(jié)點÷800microVMs/節(jié)點=0.23物理核心per live VM。

值得注意的是，DSec當時的設計目標是：當Agent需要執(zhí)行代碼、操作shell、讀寫文件等工具時，按需創(chuàng)建microVM沙箱來隔離執(zhí)行。因而這里的microVM，實際上并不是用戶數(shù)，而是沙箱數(shù)。之后再把這個數(shù)去乘以用戶數(shù)，來測算整個規(guī)模明顯是不對的。

另一方面，F(xiàn)reda選用的800個microVM只是演示上限，按生產實測峰值表現(xiàn)為524個micro VM，拿188物理核/節(jié)點÷524microVMs/節(jié)點=0.36物理核心per live VM，而不是給出的0.23。

這兩者只有在“一個用戶在峰值時恰好只持有一個沙箱”時才相等。而Muse顯然不是這樣的，用戶VM本機沒有瀏覽器，broker要去租另一臺跑瀏覽器鏡像的VM。光這一條，一個正在瀏覽的Muse用戶就至少占兩個沙箱。

這么看來，F(xiàn)reda只是測算了C（彈性層）的部分，并未測算A頭節(jié)點（GPU側）和B固定層（用戶側）的CPU核需求。

3.不合適的參照對象

當然，C（彈性層）本身也是Agentic AI需求的主要增長來源，姑且來看這部分：

DSec和Muse本身就是不同的，拿著DSec來參照也不太合適。DSec是DeepSeek用來跑代碼執(zhí)行的沙箱：跑一段代碼、返回結果、銷毀；而Muse的沙箱是常駐的個人計算機：帶瀏覽器、帶持久記憶、帶Chromium多進程調度、關掉App還在跑。

Freda的整條邏輯建立在“90%的沙箱平均只用不超過申請CPU的5%"這個實測上。但這個5%是在DSec的負載構成下測的，是被大量“跑腳本、編譯、跑測試”稀釋出來的均值，不是瀏覽器負載的占空比。

Muse是完全不一樣的。一次跨平臺比價可能觸發(fā)多達146次頁面加載，而每次頁面加載都是完整的HTML解析+JavaScript執(zhí)行+DOM構建+渲染。Chromium的JS主線程是單線程且CPU-bound的，一個現(xiàn)代商旅頁面的渲染要占滿一個核好幾秒。

本身單個客戶不一定只有1個任務，因而海豚君在C（彈性層）中引入了并發(fā)率的概念（情景假設），即對應單個活躍客戶的平均任務數(shù)（1個任務對應1個并發(fā)沙箱），這部分要關注后續(xù)Muse等Agent的使用情況。

對于C（彈性層）的測算，在1億Muse用戶（日活30%）、每天活躍3小時、峰均比2的情況下，假定每個任務沙箱需要的CPU核數(shù)為1.5個（此前的4個是參照NemoClaw的配額上限），以并發(fā)率來做情景假設：其中峰值活躍達到750萬（=1億x30%x3/24x2）

中性情況對應著并發(fā)率=150%（從此前的100%上調），即單個活躍客戶平均有1.5個任務。如果單個CPU機架和GPU機架均為200kW，CPU機架的占比下調至在15%的情況下（此前假定占比25%），對應著1GW的配套工廠。

在這情況下，單GW對應的CPU核需求量=A（GPU側）1836萬個（=30.6*60）+B（固定層）188萬個（=1億x30%x3/24x2x2/4/2）+C（彈性層）1688萬個=3712萬個，大約是原來純GPU機架方案的2倍左右（相比于1836萬個）。

在調低單個任務沙箱需要的CPU核數(shù)的情況下，也相應的調低了CPU配比情況，對應著CPU需求倍數(shù)從3倍調整至2倍，仍遠高于Freda的預測?？紤]到英偉達存儲機架（DPU）等部分的額外需求，海豚君預估Agentic CPU有望帶動CPU核數(shù)需求仍會達到2倍以上。

整體來看，這份Freda的測算中混淆了microVM（任務沙箱）和用戶的概念，他僅僅算了C彈性層的一部分，并且在計算過程中參照的DSec和Muse的方式本身就有很大的不同，這樣的參考是明顯不合適的。