表面上人们在“养龙虾”，水面之下，一场硬战正围绕底层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打响。
伴随OpenClaw进入千行百业，更多人意识到，OpenClaw不止是一款走红的产品，或许是一个时代的拐点，将对Agent的落地产生全方位影响。
其实，在过去两三年间，Agent落地并不太顺利，企业接受它的框架和逻辑需要一个过程。但OpenClaw的出现，提供了一个开源、不限制模型、不限制渠道、全面开放skills（技能）的Agent模式，让所有行业迅速达成共识。
人们已经通过OpenClaw解决复杂甚至无人问津的长尾问题。“未来软件可能变得很碎片化，但解决问题的软件方案却变得高度统一，就是通过OpenClaw框架把skills整合起来。”百度集团执行副总裁、百度智能云事业群总裁沈抖观察说，“谁懂业务、谁能把解决问题的方案变成skills，谁就能在整个生态中取得最大收益。”
在这样的发展态势下，曾经移动互联网时代各大平台的“流量孤岛”，有望被OpenClaw连成一片大陆。毕竟，所有应用厂商都不敢忽略这个未来的超级入口。
除了软件，OpenClaw也快速跑入人们使用的各类硬件。小度音箱、宇树机器人、华为手机、树莓派、联想PC.....这是一个更宏大的视角。OpenClaw有望打破原来硬件间的壁垒，形成更大一统的智能生态。
也因此，英伟达创始人黄仁勋在本周举办的GTC大会上明确表态“OpenClaw是适用于个人AI的操作系统”，并提出每家公司的CEO都必须思考：“你的OpenClaw战略是什么？”
显然，以OpenClaw为代表的Agent已带我们进入了新时代。
然而，就在这场全民“养虾”热快速蔓延的同时，一个现实问题也随之浮现，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正面临巨大挑战。
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的能力迭代也随之被拖住了。这是国产芯需要攻克的难题。
面对智能体浪潮，百度集团执行副总裁、百度智能云事业群总裁沈抖在去年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氪经授权发布。
发布时间：2026-03-20 22:20
立即订购
在线咨询
返回顶部