「token粉碎機」提出五大挑戰，AI Infra如何接得住OpenClaw

表面上人們在「養龍蝦」，水面之下，一場硬戰正圍繞底層AI Infra打響。

「龍蝦（OpenClaw）」正在成為當下最火的現象級關鍵詞。短短一個多月內，微信指數從1月29日的0飆升至3月10日的1.656億，熱度幾乎呈爆發式增長。截至3月20日，OpenClaw在GitHub上已收穫32.5萬顆星，登頂平臺第一。與此同時，奇安信報告顯示，全球每日新增部署實例從5000躍升至9萬，增長高達18倍；其中，美國和中國成為最主要的兩大陣地，合計佔比超過65%。

從技術圈到大眾生活，「養龍蝦」正迅速出圈——上至七旬老人，下至孩童，都在加入這場全民熱潮。

數據來源：奇安信報告

各大廠紛紛「下水斗法」，推出各種Claw，甚至不止一個。雲端部署、本地部署、在線託管…...各種版本層出不窮。政務單位、科研院所也隨即推出自家Claw——深圳福田區政務Claw、北京移動運維Claw、清華大學教學Claw，應用類型極廣。

各大企業也迅速將自家明星技能封裝為skills，接入開放生態，例如百度搜索skill、宇樹科技人形機器人行走Skill、麥當勞點餐skill......截止3月中旬，GitHub上已有超過2.5萬個skills；在OpenClaw官方技能平臺ClawHub上，skills數量也接近2.8萬個，其中不乏中國企業的貢獻，如百度搜索在「搜索引擎類skill」中下載量已位居全球第一。

然而，在這樣的火熱之下，卻隱藏着看不見的硝煙。OpenClaw爆紅背后，一場硬戰正圍繞底層AI Infra打響。

一隻「龍蝦」，攪動全球Agent生態

伴隨OpenClaw進入千行百業，更多人意識到，OpenClaw不止是一款走紅的產品，或許是一個時代的拐點，將對Agent的落地產生全方位影響。

其實，在過去兩三年間，Agent落地並不太順利，企業接受它的框架和邏輯需要一個過程。但OpenClaw的出現，提供了一個開源、不限制模型、不限制渠道、全面開放skills（技能）的Agent模式，讓所有行業迅速達成共識。

人們已經通過OpenClaw解決複雜甚至無人問津的長尾問題。「未來軟件可能變得很碎片化，但解決問題的軟件方案卻變得高度統一，就是通過OpenClaw框架把skills整合起來。」百度集團執行副總裁、百度智能雲事業羣總裁沈抖觀察説，「誰懂業務、誰能把解決問題的方案變成skills，誰就能在整個生態中取得最大收益。」

在這樣的發展態勢下，曾經移動互聯網時代各大平臺的「流量孤島」，有望被OpenClaw連成一片大陸。畢竟，所有應用廠商都不敢忽略這個未來的超級入口。

除了軟件，OpenClaw也快速跑入人們使用的各類硬件。小度音箱、宇樹機器人、華為手機、樹莓派、聯想PC.....這是一個更宏大的視角。OpenClaw有望打破原來硬件間的壁壘，形成更大一統的智能生態。

也因此，英偉達創始人黃仁勛在本周舉辦的GTC大會上明確表態「OpenClaw是適用於個人AI的操作系統」，並提出每家公司的CEO都必須思考：「你的OpenClaw戰略是什麼？」

顯然，以OpenClaw為代表的Agent已帶我們進入了新時代。

「token粉碎機」，源自龍蝦獨特模式

然而，就在這場全民「養蝦」熱快速蔓延的同時，一個現實問題也隨之浮現，OpenClaw是名副其實的「Token粉碎機」。

過去近一個月，全球Token調用佔比暴增至17%，業內形容OpenClaw「鯨吞了全球超六分之一的算力」。

為什麼OpenClaw會這樣「費token」？這源自它的三大獨特模式：流量全民化、交互智能體化，以及社區化生態。

首先是流量全民化，OpenClaw這類智能體的用户規模與請求量呈現潮汐式爆發特點，無固定峰值規律。

傳統大模型對話「即用即走」，總流量相對平穩。而未來人人都可能擁有一個24小時專屬AI助理，當數以千萬計的用户同時「養蝦」，原本可預測的流量模型將徹底失效。流量壓力不僅來自更多人，更來自永不休息的機器，像運維Claw，24小時代替人們不間斷地監控、排查、調度任務。這些形成的無規律、全天候、高密度的流量變化相對以往是一種質變。

其次是交互智能體化，單次用户操作會觸發多輪思考、工具調用、邏輯校驗，形成請求放大效應。

我們以OpenClaw完成一次任務為例，來了解它背后具體的推理調用鏈路與算力消耗結構。

當用户向OpenClaw發出「幫我規劃這周六帶6歲孩子去上海迪士尼的行程，預算2000元，要避開人流高峰，晚上8點前回到市區」這一指令時，OpenClaw立即構建了一個龐大的初始輸入——它不僅包含用户的簡短指令，還加載了Agent預設角色文檔，瀏覽器、命令行、文件讀寫等工具的使用説明，以及過往對話記憶。一次請求中，消耗幾十、上百k的token很正常。

在這個例子中，初始輸入約1.5萬token，驅動大模型完成首輪規劃推理，將任務拆解為查門票價格、看實時排隊、算交通時間、找餐廳推薦等子目標。

接下來OpenClaw進入ReAct循環。所謂ReAct是「邊想、邊做、邊反思，不對就改，直到認為達到可交付的水平」，並不是一次調用。

第一輪行動中，模型調用瀏覽器工具抓取迪士尼官網當日排隊數據，等網絡返回后，系統將網頁內容注入上下文，觸發第二輪推理：「飛躍地平線項目」排隊120分鍾，建議購買尊享卡或調整遊玩順序，隨后再調用計算工具覈算是否超支。每一輪「決策-執行-反思」都要讓大模型完整算一遍，上下文也隨之不斷膨脹，從初始的1.5萬token迅速增長至3.5萬token以上。

整個任務累計執行了8~12次大模型推理，最終輸出數千token的行程單，總token消耗約30萬。相比之下，傳統大模型只需一次調用、幾百token就能給出「幾個迪士尼攻略」。簡言之，以前大模型是「按次調用「，現在的OpenClaw是「按流程調用」，其「動手能力」讓Token消耗放大至少幾十到上百倍。

實際上黃仁勛曾透露，以OpenClaw為代表的Agent，執行復雜任務的Token消耗，比傳統生成式大模型激增約1000倍；持續監測類Agent可達百萬倍。行業人士告訴數智前線，OpenClaw重度用户日均消耗Token高達3000萬至1億，按國際頂尖模型計算單日成本為90~1000美元，中端模型則需42~140美元。

最后，社區化生態是OpenClaw的第三個獨特模式。智能體之間自主發起對話、協同作業、鏈式響應，形成無人工干預的自激式交互閉環。

有用户腦洞大開，把不同廠商的「小龍蝦」統統接入飛書，拉進同一個羣聊，設定各自分工后，徹底放手。此后，這羣「小龍蝦」開始自主發起對話、分工協作：一隻負責抓取市場資訊，一隻分析投資決策，一隻專門檢查工作質量，形成「AI團隊」。

這種模式讓流量從「人機對話」轉向「機器自循環」，智能體間的交互頻次呈指數級增長，進一步加劇了算力需求的潮汐式爆發。

總體而言，OpenClaw這類Agent如果普及，三股力量將疊加共振，讓「1」裂變成難以計數的「N」——N個併發任務、N條鏈式調用、N個AI團隊。而每一個N都在挑戰着AI Infra的吞吐上限、調度效率、成本邊界。更殘酷的現實是：推理的迭代速度，可能遠遠跟不上Agent生態爆炸的速度，AI Infra正面臨巨大挑戰。

AI Infra推理系統面對五大挑戰

OpenClaw的這一跨越，迫使底層AI Infra推理迎來五道此前未出現過的挑戰：

挑戰一：撐住洪峰，從「單次短鏈路」到自激爆發的極限重構

傳統AI服務遵循「請求—推理—結束」的短鏈路邏輯，但OpenClaw的ReAct模式，要完成「請求—判斷—行動-反思」多輪循環，每一輪都是一次獨立的推理請求。人機交互場景下，單次用户指令可放大為幾次到幾十次推理請求；一旦進入多Agent協作模式，Agent之間以機器速度在多個節點上高頻往返，沒有任何人類節奏的緩衝，每秒處理的請求數量瞬間可放大幾十上百倍，在毫秒級窗口內，形成傳統服務根本無法預見的「自激式流量洪峰」。

這要求基礎設施要具備超高併發、低延迟、抗雪崩的極致吞吐能力，同時兼容高頻短推理與長會話共存的複雜場景，解決隊列擁堵、鏈路打滿、GPU利用率低下的頑疾，支撐指數級放大的請求量。

挑戰二：算力調度，從「誰有空誰上」到全生命周期精準匹配

OpenClaw的任務天然是串行鏈式的，就像接力賽，AgentA負責打開瀏覽器截圖，交給AgentB理解頁面內容，B分析完畢才能觸發AgentC生成最終報告。三步必須依次執行，無法並行。任何一環卡住，整條鏈就停在原地等待，而在等待期間每個Agent仍佔用顯存不釋放。此外請求還呈現輕重混雜、多級跳變的特點，「誰空閒誰調度」的粗放調度模式徹底失效。

在這種情況下，基礎設施必須進化為智能編排系統：針對串行鏈式調用，AgentA輸出完畢，其佔用顯存應即時釋放或降級保留，待AgentB完成上游結果回傳后再重新激活，而非讓整條鏈路的每一環都白白佔着資源「空轉等候」。而且，輕量意圖匹配輕算力，複雜推理匹配高算力，高優先級任務享有資源保障，這讓AI Infra的算力調度，從負載均衡向全鏈路資源生命周期精細管理升級。

挑戰三：內存續命，從「用完即清」到動態交互下記憶牆失控突圍

KV Cache是模型的「短期工作記憶」，把已計算的上下文存下來供下次複用，省時省顯存。這在傳統服務邏輯下較為簡單，一個用户、一段對話、一塊緩存，用完即清。但在OpenClaw的多輪交互、工具調用、多Agent協作場景中，每次產生的碎片化中間結果不斷插入，「工作記憶」指數級上升，傳統緩存複用邏輯根本無從命中。帶來的后果，輕則延迟飆升，重則整條任務鏈路崩潰。

基礎設施需要具備多角色會話隔離、動態KV裁剪、緩存優化複用能力，破解長上下文與智能體動態交互帶來的內存牆難題。

挑戰四：彈性擴容，從"加機器救場"到秒級無縫接續

雙十一零點，數十萬用户同時發出「幫我搶購限量商品」的指令，流量3秒內暴漲。傳統服務的應對方式是「加機器、把請求分流出去」，但OpenClaw的Agent此時記着它打開了哪個頁面、點了哪個按鈕、正在等哪個Agent回傳結果，這些上下文全部活在內存里，綁定在某台具體的服務器上。一旦遷移，上下文瞬間斷裂，任務失敗，並沿着Agent協作鏈路逐級擴散，引發級聯雪崩。

因此，OpenClaw要求基礎設施在秒級完成擴容的同時，還必須將上下文完整遷移、無縫接續，並具備全鏈路熔斷、限流、降級能力。這兩件事單獨做都很難，同時實現，是傳統架構從未考慮過的命題。

挑戰五：模型適配，從「默認先跑英偉達」到國產芯適配無時差

OpenClaw需要前沿模型矩陣協同作業，而模型現在就像軟件版本一樣甚至每天迭代，不同模型差異極大。這是傳統適配從未有過的速度與複雜度組合。

基礎設施必須能隨時兼容下一個「格式又改了」的新模型。而開源社區的規律是現實的，一個新模型發佈，開發者默認先跑英偉達GPU，國產芯需要二次開發，算子要重新適配，精度要對齊，有時候光是把模型"跑起來"就要額外花幾周。這不是國產芯不努力，而是生態欠賬還在還。結果就是，國產芯的模型適配總是慢一步，OpenClaw的能力迭代也隨之被拖住了。這是國產芯需要攻克的難題。

如何先手佈局智能體，重構AI Infra

面對智能體浪潮，百度集團執行副總裁、百度智能雲事業羣總裁沈抖在去年8月的公開演講中就明確了行業根本性需求轉變，判斷底層技術將迎來大迭代。

他提及大模型正「從聊天陪伴走向解決各類場景需求的應用」，AI正從Copilot向具備自主決策能力的AI Agent躍遷。這一轉變直接改變了基礎設施的負載特徵：「未來AI應用的推理需求將超過訓練」，且模型需處理更復雜任務與更長上下文。這與OpenClaw等智能體多輪推理的算力消耗結構高度呼應，也對AI基礎設施提出「推理需求主導、長上下文、極致性價比」的新挑戰。

而針對AI Infra的五大挑戰，百度智能雲也給出了應對舉措：

舉措一：流量洪峰下，班車調度與貪心算法巧妙改變算力調度效率

OpenClaw爆火，帶來的史詩級流量洪峰讓響應變慢，甚至整個服務鏈條卡死。問題的根源之一出在算力調度邏輯上：傳統系統採用「先進先出」模式，即請求一到達，就立即分發給下一個可用的推理實例。看似公平，實則在高併發下會讓大量請求堆積在推理引擎內部排隊。

對此，百度百舸推出了班車調度（Staggered Batch Scheduling）機制，像公交車一樣，先在極短時間窗口內把一批請求「攢」在一起，再預判哪臺推理實例即將空閒，掐準時機整批發出。這種班車模式，從根本上消除了請求在引擎內部的無效等待時間，實現了 TTFT 的顯著降低。

然而，光解決排隊問題還不夠。OpenClaw不同推理任務計算量差異懸殊，當它們被分散到多個並行計算單元上時，極易出現「旱澇不均」，所有單元必須等最慢的那個跑完，才能進入下一輪。百度百舸利用批處理（batching）的時間窗口，獲取這批請求的全局信息，用貪心算法將這批任務在各個計算單元之間做拼配，讓每個單元的工作量儘量齊平。兩套創新協同發力，從而實現GPU利用率大幅躍升。

舉措二：深入底層挖潛，定製融合算子，實現吞吐躍升

針對大量OpenClaw等智能體應用併發，ReAct多輪循環帶來的「自激式流量洪峰」，系統吞吐量成爲了關乎生死的核心指標——一旦吞吐跟不上，任務鏈路就可能出現整體擁堵甚至徹底崩潰。

要提升吞吐上限，首先要從推理框架的底層「榨乾」硬件性能。針對大量智能體併發帶來的極高計算壓力，百度百舸聯合崑崙芯，基於 vLLM 社區標準推出了面向崑崙芯 XPU 的高性能插件vLLM-Kunlun Plugin。

這一方案的核心思路非常直接：通過面向不同模型定製高性能的「融合算子」，將原本零散的計算步驟打包處理，重點緩解 Attention（注意力機制）與 MoE（混合專家）等核心模塊的計算瓶頸，從而在框架層面實現系統性提速。實測數據顯示，在 DeepSeek、Qwen、Llama、GLM等主流模型上，這套底層優化顯著提升了崑崙芯 P800 的吞吐和時延表現。同時，配合百度百舸 AIAK 訓推加速技術，系統吞吐更是實現了2到9倍的驚人躍升。

舉措三：分佈式KV Cache和輕量級CP，實現長上下文推理加速

在 PD（Prefill-Decode） 分離式推理正成為新一代計算範式核心的當下，上下文緩存（KV Cache）的流轉效率，直接決定了系統面對高併發請求時的響應和生成速度。

面對OpenClaw等智能體超長上下文帶來的嚴峻挑戰，百度百舸採用分佈式 KV Cache 實現全局緩存智能調度。更關鍵的是Prefill和Decode兩階段之間的高效銜接，二者常分佈在不同計算節點，緩存數據如果傳遞不及時，后一階段就只能乾等。百舸通過高速傳輸通道加快節點間的數據流轉，並引入異步調度，讓兩階段錯開、互不阻塞，冗余計算消失，顯著提升長上下文推理速度。

在長文本推理中，首token延迟（TTFT）一直是用户體驗的「攔路虎」。根源在於128K超長上下文，單張GPU顯存根本裝不下，簡單切分給多張卡易出現負載不均、快慢卡等待的僵局。為此，百度百舸基於萬卡級實戰經驗，推出了輕量級CP（上下文並行）方案，通過邏輯雙倍切分，把任務切成GPU數量兩倍再重新拼配，確保負載均衡，並以單次全局通信降低交互開銷。實測結果，128K超長序列32卡部署下，TTFT控制在2秒內，讓長文本推理邁入秒級時代。

舉措四：三大核心方案，擴容從分鍾級跨入秒級時代

OpenClaw等智能體流量具有顯著潮汐特性，請求量可短時間暴漲數十倍，讓大模型的彈性擴縮容成為一道繞不開的難題。如果臨時拉起新節點，但大模型冷啟動耗時極長，如Qwen3-235B啟動需521 秒，而提前預留資源又會造成嚴重浪費。

為此，百度百舸對啟動流程全面重構，針對模型擴容的三大核心瓶頸——權重加載慢、編譯緩存每次啟動要重複生成、計算圖初始化耗時高，推出三大核心技術：自適應權重傳輸、編譯緩存複用、分階段計算圖捕獲與守護實例機制，實現精準破局。實測將Qwen3-235B啟動時間從521秒壓縮至4.91秒，冷啟動低至34秒，讓擴容從分鍾級跨入秒級時代。

舉措五：通過擁抱開源生態，快速適配新模型

為解決國產芯片部署大模型長期面臨的慢一步和性能瓶頸，百度智能雲的策略是堅定融入vLLM開源生態，不另起爐灶，讓熟悉英偉達GPU的開發者無需重新學習，即可平滑遷移到國產芯片上，從而徹底打通模型迭代快與國產芯片適配慢之間的死結。

百度百舸聯合崑崙芯正式推出的vLLM-Kunlun插件，將崑崙芯的適配工作收斂到底層算子層，大幅降低開發門檻。93%的算子與vLLM社區接口完全對齊，複用社區技術即可完成全量適配。目前vLLM-Kunlun已完成50余款主流大模型的推理適配，配套的XRAY精度抓取工具與牽星AI自動化對比平臺，將精度排查從手工升級為自動精準定位。實測數據顯示：小米MiMO-Flash-V2從零到上線僅需兩天，Qwen3.5適配全程半小時，通過快速定位並修復瓶頸，TTFT降低20%。

面對OpenClaw等智能體浪潮帶來的五大主要挑戰，可以看到百度智能雲通過「前瞻佈局、從底層入手、軟硬協同、邊跑邊建」的策略，不斷推出對應舉措，完成實測驗證。

而這背后，是百度智能雲深耕多年的全棧AI Infra能力支撐：從最底層的崑崙芯自研芯片，到百度天池超節點、再到點亮的P800三萬卡集羣，以及穩定、極速、高效的AI計算平臺百度百舸，形成從硬件到軟件的完整技術閉環。這樣的全棧能力，既支撐OpenClaw生態的高速發展，更是在AI基礎設施格局加速重塑的今天，最關鍵的勝負手。

但這硬仗還遠未到收兵的時候。當前全球日均token消耗量已超過360萬億。IDC預測，未來5年還會再增長3億倍。表面上人們在「養龍蝦」，水面之下，一場關乎Agent普及的AI基礎設施硬戰，正在全面開打。歷史上每一次應用層的範式躍遷，都會在基礎設施層引爆一輪軍備競賽。在OpenClaw生態以肉眼可見的速度向外擴張的當下，AI Infra的戰爭，則速度更快、烈度更高、容錯窗口更窄。

本文來自微信公眾號 「數智前線」（ID：szqx1991），作者：趙艷秋，36氪經授權發佈。