谷歌AI基建主管谈Agent重塑基建、光网络突破、终极物理瓶颈和未来10年的算力形态前几天刷到某头部云厂商AI基建负责人的分享标题起得挺唬人但听他讲完两个小时我反而觉得这可能是今年最有信息量的一份基建路线判断。因为这哥们儿不是画饼他聊的全是正在发生的事Agent开始把数据中心的流量模型搅成一锅粥、光网络从能跑就行变成了跑不动就完蛋、供电和散热开始卡脖子、以及他对未来十年算力形态几个比较反直觉的预测。我自己这几年一直在做AI训练和推理平台的架构接触过不少小规模集群和大规模集群的调度优化所以对这个话题特别敏感。今天把这边的笔记和思考整理一下重点聊聊他提到的几个核心判断也加一些我自己的实操认知给关心AI基础设施、算力演进、以及Agent落地后底层到底会发生什么变化的朋友做个参考。1. Agent不是新应用是算力需求的通胀机器大家现在聊Agent多半关注的是它能干多少活、能不能帮我写代码、能不能自动跑流程。但负责基建的人看Agent看的角度完全不一样他们会先问这玩意儿跑起来之后对GPU显存、网络吞吐、存储IO的要求变了多少答案是有点吓人的。1.1 从一次问答到一口气吃掉几十万token传统的大模型推理一个用户请求进来几千个token模型前向一次返回答案结束。整个请求的生命周期通常只有几秒特征非常清晰非常适合用传统的调度策略去预测和分配资源。但Agent不一样。一个Agent任务从开始到结束可能要经历理解任务、拆解子目标、多次调用工具、读取文档、反馈修正、再尝试……这个过程中模型可能要反复推理几十次甚至上百次累计消耗的token少则几万多则上百万。这种请求的特征已经不是短连接而是长会话。那位基建负责人打了个比方说传统推理请求像是到便利店买瓶水Agent请求则是直接把超市的仓储物流全跑了一遍。这对基建最直接的影响是KV Cache的占用会疯狂上升。一个长Agent会话的KV Cache可能占掉显存的80%以上真正留给模型参数和计算的空间少得可怜。我以为这个判断特别关键。因为这意味着你光看并发用户数已经没有意义了真正决定一个推理集群能同时扛多少Agent的是会话总KV存量和显存总量的比值而不是传统的拦截和排队策略。1.2 基建调度逻辑从排队执行到按需抢占传统推理集群的调度很成熟——请求进来选一个空闲的GPU推理完释放。最多再加个排队机制用优先级把高价值的请求往前插。但Agent任务的执行路径是完全不可预测的。你不知道它下一步会调用哪个工具、会读多长的上下文、会迭代多少轮所以预估执行时间和预估资源消耗这两件事基本失效了。那位负责人的原话是在Agent时代基建调度系统需要具备抢占迁移弹性伸缩的能力也就是说当一个Agent任务中途突然发现需要更多显存时调度系统得有办法把别的任务压缩、迁移腾出资源给这个任务继续跑。这和我们做K8s调度时遇到的情况很像只是复杂度和时间粒度都更严苛了。传统Pod迁移可以接受秒级甚至分钟级的重建但一个正在执行的Agent推理请求中断和迁移可能导致会话上下文全部丢失用户直接看到重试报错。所以基建层面必须想办法做推理态的迁移而不只是容器级别的迁移——这是非常难但绕不开的工程问题。我在自己的测试平台上跑过几个走ReAct循环的Agent印象最深的不是它最终能不能答对题而是它的资源消耗曲线和心电图差不多——忽高忽低最高峰和最低谷差出几个数量级完全没法按传统方式做预算。这也是为什么我认为Agent时代的推理集群必须做极致的弹性和资源池化而不是简单靠堆机器。谁先把这块搞明白谁就能在Agent应用爆发的阶段抢到最重要的成本优势。1.3 显存才是Agent时代最稀缺的资源很多人以为算力就是多少张卡、多少P FLOPS但在Agent场景里最卡脖子的其实是显存容量和显存带宽。原因刚才提到了Agent需要处理非常长的上下文而长上下文的KV Cache会吃掉海量显存。我也观察到一个现象单张H系列的GPU计算侧其实还有富余但一跑长上下文显存先被打爆。为了省显存工程上常用的办法是KV Cache量化、PagedAttention、以及把Memory Offload到CPU内存或远端存储。但这些方案都会增加额外的延迟和带宽开销。那位基建负责人提了一个数据我印象很深——在某些Agent场景里显存成本已经和计算成本对半开甚至反超计算。所以未来十年的算力形态核心不一定是更快的GPU反而是更大的显存、更宽显存带宽、更高效的显存复用机制。这也是为什么业界都在往HBM的方向堆料甚至开始考虑存算一体架构——因为Agent这种应用本质上是吃记忆密集型的算力而不是计算密集型的算力。2. 光网络为什么突然变成主角光网络这个事以前在数据中心里存在感很低。大家关心的是GPU算力多强、CPU够不够用网络只要不丢包就行。但那位基建负责人非常强调一点Agent和大规模模型训练的集群扩张会把光网络的瓶颈无限放大光网络已从配菜变成了主菜。2.1 电互连的物理极限铜缆在1.6T时代扛不住先说一个直观的物理事实电信号通过铜缆传输时距离越远、频率越高信号衰减越严重。在目前主流的400G和800G时代铜缆在某些较短距离内还能用。但一旦网卡速率到1.6T即便在机柜内部信号衰减和功耗也会大到让人头疼——电互连只能在非常短的物理距离内保持性能超出范围就必须换成光。那位负责人给了一个非常明确的判断未来高速互联的边界线会不断收缩。以前机柜内走铜线没问题未来可能连同一块背板上的芯片之间都在考虑用光来互联。这台设备已经不只是网络设备而是整个算力集群能不能有效扩展的骨架。2.2 从可插拔光模块到共封装光学光的优势是功耗低、抗衰减小、带宽极限高但以往光模块也有自己的问题作为可插拔器件插在交换芯片附近走线距离长功耗也不小而且随着速率提高光模块的功耗和散热压力越来越大。说得直白一点传统的交换芯片可插拔光模块模式在1.6T时代会走到尽头。新方向是共封装光学CPO——把光引擎直接封在交换芯片的同一块基板上用光在芯片附近做互连。好处是两个一是功耗显著下降二是解决了高速信号长距离走线的难题。但这玩意儿做起来真实性很难。光引擎和硅基芯片的工艺完全不一样热膨胀系数不一样良率管理难度也不一样大规模量产之前还有很多工程问题。那位基建负责人提了一个观点我觉得很中肯CPO不是想不想做的问题而是不做就没法继续往上走的问题——物理规律决定了的只是时间早晚。2.3 光网络部署中的真实痛点光网络听起来高大上但真要在机房维护起来痛点特别多。我自己当过甲方也当过乙方搞过一段时间的网络调优和运维。光模块有一个很大的坑故障率。大规模集群里光模块是最容易挂掉的硬件之一而且挂的方式千奇百怪——脏了、温度高了、激光器老化了、链路误码率变高了但没完全断。一个万卡集群如果全用光互连每天都会有几个光模块冒出来捣乱排查起来极度费人费力。那位基建负责人也提到了这个问题说他们的方案是搞智能运维系统用光模块的遥测数据预判故障、在用户无感知的情况下提前切换链路。这种思路说实话很考验团队的系统工程能力因为光模块遥测数据量大、种类多、故障模式也很隐蔽不是简单设个阈值就能搞定的。所以如果你问我Agent和光网络有什么关系我的回答是Agent大规模商用之后推理请求会从数据中心内部频繁跳转甚至跨数据中心协作光的带宽和延迟直接决定了Agent能指挥多少东西、能跑多远。光网络升级本质上是在为Agent时代做路网的准备。3. 三道物理高墙功耗、散热和光速聊完网络聊聊那位负责人说的一个更底层的问题——终极物理瓶颈。他列举了三个他认为是未来十年的硬约束功耗、散热、光速。我觉得这三个词简直是把算力形态的走向说透了。3.1 功耗墙AI集群逼近电网极限过去造数据中心大家最关心的是IT设备的计算密度。现在造AI数据中心最先确认的反而是供电方案——因为需求太大了。训练一个超大模型的集群动辄上万张卡整机柜功率密度甚至能达到100kW以上而传统机房一个机柜的供电能力只有10kW左右。这意味着今天的大部分存量机房根本没办法直接承载下一代AI算力必须改造供电和制冷系统。那位基建负责人用了逼近电网极限这种说法。因为一个超大数据中心的容量可能相当于一个小城市的电力负荷。这在电网调度、可再生能源配套、以及备用电源层面都是巨大的挑战不是多买几台UPS就解决的。所以未来算力选址一定更倾向于靠近电厂、靠近水电或绿电资源而不是靠近用户。3.2 散热墙风冷退场液冷成为标配功耗一上来发热量也水涨船高。传统的风冷散热在机柜功率密度超过一定数值之后效率会大幅下降风扇转速拉到极限噪音和能耗也完全不可接受。液冷是唯一能在高功率密度下稳定带走热量的方案。目前已经有不少大型AI集群在采用冷板式液冷或者浸没式液冷把散热从吹风变成泡澡。那位基建负责人的说法是未来所有高性能计算场景液冷不是选项而是标配。这听起来很绝对但物理规律就是这样。你不可能让空气带走超过一定密度的热量也不可能靠加大风扇无限提升散热能力——空气流速上去之后噪音、震动、功耗一堆问题都会冒出来。相比之下液体的比热容和传热系数优势太明显了。我在冷板和浸没间也犹豫过。冷板式实施门槛低改造小维护方便但对服务器内部的风道设计有要求浸没式散热效率更高整体更安静但液体本身、密封方案、介质成本都是新考验。如果是新建数据中心我建议直接按液冷标准去设计因为后改装会痛不欲生。3.3 光速墙分布式计算的理论天花板最后一个物理瓶颈是光速。很多人不太把它当回事因为光速每秒三十万公里在地球尺度上听起来绰绰有余。但放到超大规模AI集群的分布式训练和推理协同里光速就是实实在在的延迟上限。做一个简单的计算两地之间相距1000公里光在光纤里的实际传播速度约为200,000公里/秒单程延迟5毫秒。如果训练任务需要频繁同步梯度哪怕每个迭代只因为跨地域多出10毫秒的延迟累积起来就是天文数字。这也是为什么几乎所有大规模训练集群都必须集中式部署、尽量同机房、同园区而不是像消费互联网一样到处分散。那位基建负责人说得很直白未来不太可能出现一个全球分布式的大模型训练集群因为光速锁死了同步效率。算力形态的演进会优先考虑把最核心的训练和推理任务集中放在一个或多个超级园区里园区之间只做低敏感度、低同步频率的协作。我理解他的思路是未来算力协同一定是分层的。最底层是同一机柜内的超低延迟互连然后是同数据中心内的高速网络再往上的跨数据中心、跨地域就只能做异步或准同步了——绝对不能指望全世界的算力组成一台超级计算机。4. 未来十年算力形态的三个确定性走向那位基建负责人最后聊的是未来十年的算力形态。他没讲太多花哨的概念而是用三个维度把方向说清楚了。可能听起来不够科幻但作为真正搞基建的人我知道这才是最务实的东西。4.1 从卖芯片到卖系统单位算力功耗成为核心指标过去大家选算力主要看GPU的浮点算力多少、显存多大。但那位负责人说未来衡量算力强不强不能光看FLOPS要看单位功耗下的有效算力和单位显存下的有效会话数。为什么因为功耗和显存是真正的物理约束。Agent场景下用户对快不快的感知很多时候不是算得快不快而是显存够不够、带宽够不够。芯片厂商必须从系统角度去设计把计算、存储、互连、散热打包成整体来优化。谁能在同样的功耗和物理空间下服务更多Agent并发谁就是下一代的赢家。我也看到现在不少厂商开始推大内存GPU高带宽内存的路线这完全就是冲着Agent赛道的需求去的。可以预见未来一段时间的大模型推理性能评测除了传统的吞吐和延迟指标一定会加入长上下文处理能力KV Cache利用率单位瓦特处理token数这类更贴近实际应用的指标。4.2 推理算力将反超训练Agent是最大推手前几年的大模型焦点是训练——训出一个基座模型很贵所以大家都研究怎么多快好省地训。但现在头部模型的训练需求逐步稳定推理需求开始爆发尤其是Agent带来的推理需求更是以几何级数增长。一个Agent跑一天消耗的token量可能等于几千个普通用户的日常使用量。这个比例一旦上去推理侧需要的算力会远超训练侧。那位基建负责人预测未来五年推理算力占整个AI算力集群的比重会持续攀升甚至成为绝对主力。这个预判对我的冲击还挺大的因为我以前做推理优化总觉得是被动配合训练但现在明显感觉到推理正在变成核心业务。推理侧的优化空间还很大比如算子融合、连续批处理、显存管理、前缀缓存每一个方向都值得花精力深耕。Agent这个浪潮把推理优化的价值放大了无数倍。4.3 存储、网络、算力的木桶效应会越来越明显最后一个走向是所有层面要平衡发展。过去大家总默认算力是核心网络和存储能跑就行。但Agent同时是计算密集内存密集IO密集的应用——它不仅仅是算得快就行还要能快速读取知识库、长会话中间结果、工具调用记录这全都压在存储和网络的肩上。那位基建负责人讲了一个很直接的场景Agent翻企业知识库的时候请求到文件存储的IO可能比到大模型的请求还多如果存储带宽不够Agent的思考速度会被拖垮。训练集群还可以靠大文件、高吞吐来设计但Agent的读写模式碎片化、突发化、低延迟要求高对存储系统的挑战甚至比训练还难。所以未来十年光有GPU是不够的必须同时配套高吞吐的存储系统和低延迟的网络系统。三者像木桶一样最短的那块板决定了整个算力集群的实际输出能力。谁先意识到这个问题谁就能避免在Agent应用爆发时被基建拖后腿。我自己在实际操作中的体会是如果你想给Agent做一个稳定的生产级服务不要只盯着GPU型号先用量化工具把KV Cache摸一遍再把存储延迟测一遍最后再去谈并发和吞吐。基建这东西说起来都是纸上谈兵真到落地的时候每一个瓶颈都会变成一个个具体的告警电话。那位负责人的分享其实就是把这些坑提前标了出来剩下的还得靠我们这些人一个一个去填。