1. 大会现场透露的算力需求信号第三届AI算力产业大会暨展览会的现场我最大的感受是AI基础设施已经不是要不要建的问题而是怎么建才不浪费的问题。走进展馆和两年前完全两个光景。早几年大家围在GPU服务器展台前问你这卡多少TFLOPS今年几乎所有人都在问你这套集群跑大模型训练端到端可用算力能到多少。这个词很关键端到端可用算力而不是纸面算力。一家做智算中心建设的朋友跟我说他们现在投标甲方直接要求标定真实训练效率要测到MFU模型算力利用率达到某个值才愿意验收。放在过去这根本没人关心。奇点算力这次受邀参会展台位置不算大但围的人一直不少。我过去转了一圈他们团队正在演示一套面向智算场景的资源调度系统核心逻辑是把分散在几十台服务器上的GPU算力按任务优先级动态编排中间还插了一段故障自愈的模拟。说实话这种演示在展馆里不算花哨但围观人群里问得最细的反而是运维工程师一个接一个问断点续训怎么做的多租户隔离的粒度到哪一层。这种务实的技术追问恰恰说明行业已经过了讲概念的阶段。大会主论坛的主题围绕AI基础设施升级展开几个嘉宾的分享串起来看可以梳理出一条很清晰的脉络算力需求的增长曲线已经远超摩尔定律的线性外推而供给侧的硬件迭代、机房配套、网络架构、软件栈适配每一个环节都出现了新的瓶颈。过去我们觉得GPU是算力的一切但现在的共识是GPU只是算力链条里最显眼的一环电力、散热、互联、存储、调度软件任何一环掉链子整个基础设施的效率都会被拉低。这也是今年很多参展商不约而同强调全栈的原因。单纯卖卡的路子越来越窄大家开始讲整体解决方案。奇点算力在展台上放的那张架构图从底层基础设施到中间调度平台到上层应用适配链路铺得很长。我问他们的技术负责人这么做会不会摊子太大他的回答很有意思不是我们想做全栈是客户在倒逼。他们不想自己把每个环节拼起来拼一次亏一次亏怕了。这句话基本概括了这次大会的基调AI基础设施升级账要算总账。2. 基础设施升级绕不开的三个核心难题2.1 电力与散热算力暴涨后的物理天花板大会期间我参加了一场小型闭门研讨主题是智算中心建设运维。几乎所有人提到的第一个问题都不是芯片是电。一个非常具体的数字单机柜功率密度早期通用数据中心一般在4-8千瓦AI训练集群动辄要上到30-60千瓦液冷方案甚至做到单机柜100千瓦以上。这不是把服务器塞进机柜就完事而是整个供电架构、散热架构都要重新设计。有位做数据中心改造的嘉宾说得很直白我们算了一笔账老机房改造成支持高密度AI算力改造费用比新建还贵很多业主听完直接放弃了。风冷方案在单机柜功率超过20千瓦后能效比会急剧恶化风扇转速拉满噪声巨大散热效果仍然有限。液冷从可选变成必选已经不是趋势而是现实。我特意留意了展馆里的液冷展商数量比去年翻了不止一倍冷板式、浸没式、喷淋式各种路线都有。奇点算力展台也放了一套液冷整机柜方案他们给的数据是PUE可以做到1.15以下这在几年前是不可想象的。但液冷真正落地的难点不在技术本身而在运维习惯。传统风冷机房IT工程师个个会修服务器但液冷系统的漏液检测、冷却液更换、管路维护需要一套全新的运维能力。展台上我问了下奇点算力负责交付的工程师他说他们现在每个液冷项目都会给客户做至少两轮运维培训还专门做了一个液冷故障模拟的沙盘让客户运维人员在交付前先踩一遍坑。2.2 互联与调度GPU再多连不起来也是白搭另一个被反复提及的问题是互联。大模型训练是典型的分布式计算场景成百上千张GPU需要频繁交换梯度数据网络性能直接决定集群的实际效率。这里有一个经常被低估的点GPU之间的通信带宽很多时候比GPU算力本身更值钱。通讯时间是死的数学题卡越多通信占比越大集群规模到一定量级后再堆卡效率也不涨甚至可能下降。这就是为什么现在训练集群普遍用高速无损网络而不是传统的TCP/IP以太网。行业中常说的Scale-up单节点内扩展和Scale-out跨节点扩展两种路径前者靠NVLink这类高速总线后者靠IB或RoCE网络。大会展区不少网络设备厂商都在推800G交换方案参数上确实比上一代翻了一倍但真正考验的是大规模集群下的稳定性和拥塞控制能力。软件层的问题更麻烦。硬件互联只是通路怎么把任务合理分配到每张卡上、怎么减少通信开销、怎么在部分节点故障时不至于整个训练任务崩溃这些都要靠调度系统和框架层面的优化。奇点算力这次重点展示的调度平台我深度看了演示有两点印象很深一是它能把GPU资源池化和任务调度的粒度做到比较细同一个集群可以同时跑训练、微调、推理资源分配实时调整二是它的故障感知不是简单的节点宕机就重启而是会做故障预判提前把任务迁走。后者对训练任务的价值极大因为大模型训练中断一次恢复的时间成本按天算。2.3 数据与存储喂不饱的I/O墙算力、网络之外存储是那个容易被忽略、但实际运行中非常致命的瓶颈。一个很形象的比喻GPU是台吃数据的猛兽存储系统就是喂饭的人。训练任务跑起来数据要先从存储里读出来经过预处理、增强、切分再送到GPU显存里。如果存储系统响应慢GPU就一直饿着肚子等利用率唰唰往下掉。很多团队买了上千张卡结果实际利用率只有四五十查来查去问题出在数据加载上。这次大会专门设置了一个存力相关的展区这是我比较意外的说明存储的瓶颈已经得到行业普遍重视。有几家厂商展示了NVMe-oFNVMe over Fabric方案把闪存阵列通过高速网络直连服务器延迟可以压到几十微秒级别。奇点算力的方案里也整合了类似的技术路径他们在宣讲时给了一个数据通过存储与计算协同优化数据加载耗时可以缩短60%以上。这个数字我没法验证但从工程角度来看存储链路确实是目前投入产出比最高的优化点之一。我自己踩过类似的坑之前在跑一个千亿参数模型的训练任务数据增强环节用Python在CPU上做结果GPU利用率长期只有三成。后来把数据流水线全部改成GPU上的DALI方案又做了样本预加载和多级缓存利用率才慢慢拉上来。这种问题不是个案而是普遍现象。3. 奇点算力这类厂商的角色为什么越来越关键3.1 从卖硬件到交付可用算力的转变参展商名录翻一遍会发现一个很有意思的变化过去那种只卖服务器、只卖网络设备的纯硬件厂商越来越少更多厂商把自己的定位改成了算力服务商智算解决方案提供商。奇点算力是其中走得比较早、喊得也比较清楚的一家。所谓可用算力我理解包含三层含义指标可用标称的算力规格在实际业务中能跑出应有的性能稳定可用集群长时间运行不掉链子故障能快速恢复易用好用有配套的平台工具算法工程师不用每天跟底层细节较劲。这三层说起来简单做起来难度逐级递增。指标可用本质上只是硬件选型和网络调优的问题稳定可用就需要调度系统的支撑而易用好用则牵扯到一整套开发者工具链。大部分传统硬件厂商卡在第一层就止步了能把后面两层做扎实的在整个行业里都是稀缺品。在展台上和奇点算力的技术团队成员聊了聊他们的核心团队里有不少是之前做超算集群、互联网大数据平台出身的人这决定了他们的思路完全不同——不是按硬件规格书卖产品而是按业务负载需求反推架构设计。一台机器该配多大内存、什么规格的SSD、几个网口不是拍脑袋定的是先分析用户要跑的训练任务特性再回头配硬件。3.2 智算中心建设中最容易被忽视的软硬协同问题这次大会上我听到频率最高的一个词不是大模型不是GPU而是软硬协同。过去IT基础设施的建设逻辑是分层的底层硬件、中间操作系统、上层应用各管各的接口标准定好大家各自做好自己的事情就行。但智算时代的AI基础设施这个清晰的边界被打破了。GPU的利用率、通信的效率、存储的吞吐这些指标强烈依赖软件调度与硬件特性的深度配合。举个最简单的例子同一个训练任务在同样的GPU集群上跑用不同的通信库、不同的梯度压缩策略性能差距可以到30%以上。这里就体现了集成商/方案商的真正价值。奇点算力在宣讲里反复强调全栈调优他们做的事情本质上是用一套软件平台把底层异构硬件不同厂商的GPU、网络设备、存储统一封装向上提供给用户的是一套标准化的算力接口。这样用户不需要关心底层用的是谁的卡、怎么连的网络只需要提交作业、拿结果。这个思路很朴素但在工程实现上非常难因为每个硬件厂商都有自己的配置细节把这些细节都处理好需要大量的工程积累。我在现场问了一个很尖锐的问题如果用户坚持指定某一家的GPU你们有适配能力吗他们的回答很坦诚主流厂商的卡我们都适配过但适配深度有差别。用我们推荐的组合我们能承诺性能用户强行指定某些冷门型号我们只能保证能跑但调优需要额外时间。这种坦诚在行业内不多见也侧面说明软硬协同这件事的复杂度。3.3 为什么被邀请参会本身是一个行业信号奇点算力不是那种常年活跃在聚光灯下的明星企业在AI算力圈内却是越来越多项目中被提到的角色。这次受邀在大会上做专题分享本身就说明一个问题行业开始正视算力基础设施集成与调优这个环节的价值。之前行业中有一个普遍心态买最好的卡、堆最多的卡算力自然就上来了。但过去一两年大量项目用惨痛的教训证明了这个逻辑不成立。花了几千万采购的GPU集群实际产出效率只有三分之一。这时候行业才回过神来需要有一套方法论把硬件资源真正转化成业务价值。奇点算力这类厂商做的正是这个转化层。这个角色有点像交响乐团的指挥——乐手硬件都很优秀但没有人指挥各自演奏出来的不是音乐是噪音。指挥的作用不是自己演奏而是让所有人的演奏形成合力。AI基础设施里的软件平台和调度系统就是这个指挥的角色。4. 从展区到论坛几个值得深究的技术细节4.1 异构算力的管理与统一编排我在大会第二天参加了一场关于异构算力的分论坛其中奇点算力的分享主题是混合算力场景下的资源统一调度。现在很多企业手头有不止一种算力资源可能有几卡GPU自建集群可能租了一部分公有云算力可能通过算力平台调度了一部分第三方算力。这种情况下每个资源池的管理方式、计费方式、网络环境都不同算法团队用起来非常痛苦。异构算力统一编排的思路是通过一个中控平台把这些资源池抽象成统一的算力空间用户可以像使用本地资源一样使用全部算力。这里的技术难点可以列出很多层面资源池之间的网络打通与隔离任务调度策略在跨域场景下的自动选择不同算力平台之间的数据流转与安全管控故障域扩大的情况下如何保证任务可靠性。奇点算力分享的是一个大型智算项目案例他们通过统一调度平台把客户分布在不同地域的三个算力节点两小一大整合成一个逻辑集群最大训练任务的规模提升了两倍资源利用率从52%提升到78%。这个数据在行业内是相当可观的提升但背后的工作量也非常惊人仅网络打通和调优就花了一个半月。4.2 模型推理场景的低延迟优化大会展区里和训练相比推理侧的热度上升得很快。原因很直接大模型应用开始落地了凡是做To B业务的厂商都在考虑怎么把模型部署到生产环境。推理和训练是两种不同的技术挑战。训练是大力出奇迹堆算力跑久一点总能出结果推理则是精打细算过日子要在给定的延迟和成本约束下服务的并发请求数最大化。我在和一个做企业知识库产品的创业者聊他说他们用开源的模型部署在几块消费级GPU上白天最高峰要同时服务200多个用户的问答请求延迟还要求3秒内返回。这种场景对推理引擎的优化要求非常高。具体优化手段包括模型量化和蒸馏压缩、KV Cache优化、动态批处理、前缀缓存等。有一家厂商展示了他们的推理加速方案用同样的硬件单卡并发数提升接近3倍。原理说起来并不玄妙主要是把显存的管理和计算核心的调度做了深度优化减少了计算闲等的时间。但原理不玄妙和能落地做出来之间隔着大量工程细节。奇点算力在推理场景上同样有布局他们的调度平台也包含推理实例的弹性伸缩能力。按他们的说法训练和推理混合部署可以让GPU的闲置算力在训练间隙被推理任务利用起来最大化硬件利用率。这个思路实践起来有不少坑比如训练任务对显存的占用是波动的推理任务又是延迟敏感的调度不当可能导致两边都受影响。但他们通过资源隔离和优先级策略把两类任务做了比较稳妥的共存。4.3 边缘算力与中心算力的协同这次大会还专门有一条AI基础设施走向边缘的分会场讨论的是算力如何从中心节点向边缘延伸。我带着好奇进去听了半场发现这类讨论的落地性比去年强了很多不再只是讲概念而是讲实际部署经验。比如在工厂车间里做质检视频流产生的数据量非常庞大全部传回中心机房既费带宽又增加延迟更合理的做法是在边缘侧部署小规模算力先做前端的检测和过滤只把疑似异常的样本传回中心做二次确认。这种边缘加中心的协同架构落地中最大的障碍不在技术在管理。边缘节点分布在不同的地理位置、不同的网络环境下远程运维对平台的可靠性要求很高。帮奇点算力做展台运维的一名工程师告诉我他们有个部署在客户工厂里的边缘节点因为厂区网络波动导致节点离线远端自动重启了三次才恢复。听起来是小问题但每个边缘节点的管理成本如果按照传统IT运维的方式算根本算不过来。5. 落地AI基础设施时的避坑经验5.1 别把算力规划当成服务器采购数量计算大会期间和多位从业者交流下来我发现一个非常普遍的误区很多人把算力规划简单理解为我要多少张卡然后把需求书甩给采购部门最后大概率踩坑。算力规划应该是从业务目标反推的过程。你的模型多大参数量、训练数据多少T、目标多长时间迭代一轮、同时支撑多少并发推理、未来三个月业务增长预期是多少这些共同决定了需要什么规格的算力、多少算力、以什么形式配置。我在现场听到一个很典型的反面案例。一家企业为了做行业大模型一次性采购了上百张高端GPU结果因为数据准备和清洗的环节跟不上大部分GPU一个月里有大半个月是闲置的。如果当初把一部分采购预算用来建设数据平台和开发测试环境同样的钱能发挥更大的作用。算力采购也不一定非要一步到位。结合业务发展阶段可以采用核心自有弹性外租的组合策略。稳定长期运行的核心训练负载用自建集群突发性需求和节假日高峰用云端算力弹性补充。奇点算力在交流中也表达了类似观点他们服务的大客户越来越多采用混合策略自有算力保证数据安全性和核心业务稳定外租算力解决峰值瓶颈。5.2 故障恢复能力是被低估的ROI重点智算集群的规模越大故障越不是会不会发生的问题而是多久发生一次的问题。千卡集群运行一个月出现节点故障、网络抖动、存储异常几乎是必然事件。关键区别在于故障的影响范围和处理效率。很多自建集群的团队出了故障靠人工排查一个节点宕机可能要几个小时才能发现和修复期间整个训练任务可能已经中断。而成熟的调度系统能做到自动感知故障、自动迁移任务、自动断点续训把故障影响控制在几分钟以内。这里有一个容易被忽略的成本账大模型训练中断恢复的代价不只是重新跑一遍。有的框架支持定期保存检查点可以从中断处恢复但检查点的保存频率设置得是否合理直接影响恢复时的损失程度。检查点保存太频繁存储和IO开销大保存太少中断后可能丢失几十个小时的训练进度。这个参数需要结合训练任务的特点和底层存储性能来仔细权衡。奇点算力在他们分享中强调的故障预判机制就是在节点真正宕机之前通过监控日志和传感器数据判断出异常趋势提前把任务迁移走。这个能力对训练型业务的价值比多买几块GPU实在得多。5.3 算力平台的易用性是规模化的前提最后想聊聊算力平台的易用性这个话题在大会上被反复提起却最容易在前期建设中被忽视。一个典型的场景企业花大力气建设了智算平台但算法团队还是习惯各自用各自的服务器平台使用率极低。原因是平台的学习成本太高创建任务要配置一大堆参数文件上传下载流程繁琐出了问题又不容易排查。最后的结果是投入巨资建设的平台沦为摆设。真正好用的算力平台应该让算法工程师几乎感觉不到平台的存在。提交任务像发一封邮件一样简单资源和文件管理像网盘一样直观监控信息一眼就能看懂。这背后是复杂的底层逻辑但对用户必须是简单的前台体验。奇点算力在展台演示时有个细节我印象很深他们的任务提交界面做得非常简洁选择镜像、配置资源、填启动命令三个步骤就能提交任务。这种把复杂留给自己把简单给用户的设计思路说明他们是真的在用户的真实使用场景里打磨过产品。5.4 数据安全与多租户的边界防范智算平台一旦开放给多个团队使用数据安全和租户隔离就成了必须正视的问题。不同业务团队的数据可能有不同的保密等级平台需要在底层做好逻辑隔离。技术上多租户隔离涉及多个层面文件系统的权限隔离、运行环境的容器隔离、网络层面的安全策略、以及GPU显存和内存的资源隔离。任何一个层面的疏漏都可能带来数据泄露的风险。这个问题在大规模商用智算中心尤为突出。现场一位做智算中心运营的朋友告诉我他们服务的客户里有几个金融机构对数据隔离的要求极为严格甚至要求同一条训练任务的不同阶段运行在不同物理节点上。这种极端需求虽然在实际中不占主流但平台的隔离能力是否足够灵活往往决定了能否拿下这类高价值客户。6. 写在最后几个值得长期关注的判断大会结束之后我整理了几天的笔记有三个判断想分享给正在规划AI基础设施的朋友。第一个判断AI基础设施的软件红利期正在到来。硬件层面各家GPU的代际差距在缩小单纯拼硬件参数的赛道越来越拥挤而软件层面调度、优化、易用性的提升空间还非常大。未来一两年谁能把硬件资源转成业务价值的效率做得更高谁就能占据竞争优势。第二个判断算力评估的真实基准会越来越重要。随着行业对算力认知的加深那种只讲峰值算力的时代会逐渐过去。更多的客户会用具体的业务负载来评估算力平台的好坏算力供给方需要拿出真实场景下的性能数据来证明自己。第三个判断生态协同能力将成为算力厂商的核心竞争力。没有任何一家公司能独立提供AI基础设施的全部能力。芯片厂商、服务器厂商、网络厂商、软件平台、云服务商、数据中心运营商每个环节都有各自的专业壁垒能把这些环节高效协同起来的厂商才是客户真正的合作伙伴。最后再分享一个小经验不管你是准备自建算力集群还是打算采购算力服务都建议先花两周时间梳理清楚自己的真实负载画像。把业务任务分成训练型、推理型、数据处理型三种类型统计各自的时间分布和资源消耗特征。有了这份画像再去看各种算力方案脑子里就有一杆秤被任何厂商带着节奏走的概率都会小很多。