过去大半年我一直在跟踪国内AI算力基础设施的市场格局一个比较明显的信号是以GPU算力、大模型训推服务为核心的新云市场正在从传统云厂商的势力范围里生生切出一块新蛋糕。最近看到IDC相关报告和几份行业研究数据商汤大装置在中国新云市场的份额排名已经做到了第一。说实话这个结果放在两年前我不会觉得意外但在今天这个时间点拿到第一背后涉及的远不止是“卖了多少卡”这么简单。这篇文章我想以一个长期接触AI基础设施的从业者视角拆一下新云市场到底在卷什么、商汤大装置靠什么跑在前面以及企业如果要上车这类平台实操层面有哪些值得关注的东西。先说一个基本判断商汤大装置领跑新云市场不是靠单一产品打天下而是把“算力层-平台层-模型层-应用层”串成了一个完整的闭环。对一个规模化训练千亿级参数模型、或者要把AI落到业务场景里的团队来说这个闭环意味着你不用自己拼装一套复杂的AI基础设施可以直接在这个体系里完成从资源申请到模型上线的全过程。这篇文章会把里面的技术逻辑、选型思路、落地细节和踩坑经验都摊开来聊适合正在做AI算力选型的技术负责人也适合想搞清楚新云市场格局的从业者。1. 新云市场到底“新”在哪儿为什么传统云不够用了1.1 从“通用算力”到“智能算力”的需求转移要理解商汤大装置为什么能在新云市场登顶先得把“新云市场”这四个字掰开揉碎了看。过去十几年我们熟悉的云计算本质上解决的是通用算力的供给问题你要跑网站、存数据、搭数据库、做消息队列按需租用CPU资源就行。这种模式的核心指标是稳定性、SLA、性价比厂商拼的是机柜规模、网络延迟和运维能力。但AI大模型时代来了之后“算力”这个词的内涵变了。大模型训练和推理需要的是GPU、NPU这类智能算力而且是成规模的、集群化的智能算力。拿训练一个千亿参数模型举例单卡训练根本跑不动需要数千张GPU组成的高速互联集群同时还要配套高速存储、高性能网络、分布式训练框架、断点续训能力。这些能力和传统云厂商轻车熟路的CPU云主机体系完全是两套技术栈。传统云厂商当然也看到了这个趋势也都在推GPU云服务器。但问题在于很多传统云厂商的GPU实例还是按照“虚拟机”的思路在设计——给你几块卡、配个NVLink就算交付了。而真正训练大模型的团队要的是一整套“AI工厂”数据预处理、模型并行策略、训练调度、监控告警、模型评估、推理优化这些东西如果都要客户自己拿开源组件去拼体验会非常痛苦。新云市场的本质就是围绕“智能算力”重构整个云服务体系。它不再以CPU为核心而是以GPU算力池、分布式训练平台、模型服务为核心。谁能在这一层做到极致谁就能在新云市场拿到话语权。商汤大装置从一开始就是按这个逻辑做的它没有历史包袱不需要兼容老的VM虚拟化体系直接面向大模型训练和推理场景做了深度优化这是它能在新云市场排名第一的重要原因。1.2 新云市场的用户画像是谁新云市场的用户和传统云的用户重叠度其实没那么高。传统云服务的典型客户是互联网公司、中小企业需求是跑应用、存数据。新云市场的核心客户画像是四类第一类是做大模型研发的AI公司。这类团队是典型的重度用户一次训练任务可能就要占用上千张GPU连续跑几十天。他们对算力集群的线性扩展效率、断点续训的可靠性、分布式训练框架的兼容性高度敏感。对他们来说算力平台稳定多训练一轮可能就能节省数百万的成本。第二类是希望用AI改造核心业务的大型企业。比如金融、能源、制造、城市治理这些行业的头部客户他们不一定要自己训练基础大模型但需要基于开源模型或商用API做微调、做RAG检索增强生成、做行业智能体应用。他们要的是一个能在合规前提下快速落地AI能力的平台。第三类是高校和科研机构负责算法研究、发表论文、验证新架构这类用户看重学术生态、框架支持度和成本灵活性。第四类则是传统的软件开发商和系统集成商他们要为下游客户交付AI应用需要稳定、可复用的模型服务能力。这四类用户的共同点是什么他们不关心云主机怎么创建、VPC怎么划分他们关心的是“我能不能快速拿到算力”“训练任务能不能稳定跑完”“模型部署之后推理性价比够不够”。这正是新云市场产品设计的第一原则。2. 商汤大装置的技术底牌一套完整的AI基础设施栈2.1 全栈式架构算力、平台、模型、应用四层闭环业内聊商汤大装置通常会提“AI基础设施”这个概念。但真正拉开差距的是它把基础设施做成了四层结构每一层之间紧密咬合而不是四块拼凑起来的产品。最底层是算力层。大装置目前管理了大规模GPU资源池覆盖训练和推理两种场景。但单纯有卡不算本事难点在于把几千张卡组织成一台“超级计算机”高速互联网络怎么组网、存储带宽怎么保障、任务调度器怎么分配资源、故障域怎么隔离。这些工程细节直接影响大规模训练的效率。如果互联拓扑设计不好几千张卡跑起来通信开销可能吃掉三成以上的算力。商汤在AI训练场景深耕多年这部分的经验积累是纯做云起家的厂商很难短期补齐的。往上第二层是平台层也就是AI开发平台。这里包含数据管理、标注工具、模型训练框架、分布式调优、模型评估、版本管理这一整套工具链。我自己的体会是这个层级的价值经常被低估。很多团队卡住的瓶颈不是没有算力而是数据清洗和实验管理的效率太低。一套真正好用的AI开发平台能把数据科学家从繁琐的环境配置里解放出来让他们把时间花在模型结构设计和调参上。第三层是模型层也是商汤最有差异化优势的部分。商汤自研的“日日新”大模型体系覆盖了语言、多模态、语音等方向同时对外提供MaaS模型即服务能力。这一层意味着大装置不只提供“挖矿的工具”还直接提供“矿藏”——用户可以不从零训练直接基于已经验证过的基座模型进行行业微调开发成本和周期大幅下降。最上面是应用层面向具体行业场景输出解决方案。比如企业私有大模型部署、智能客服、内容生成、数字人等等。这一层离用户最近也最考验对业务场景的理解能力。商汤过去在智慧城市、智能汽车、AI内容生成等领域的积累在这一层转化成了落地优势。2.2 软硬协同为什么“自研模型自有算力”的组合更具竞争力很多人会忽略一个关键问题商汤大装置和商汤自研模型是同一个体系里长出来的。这件事的意义比表面看起来要大得多。训练大模型的过程中算力平台和模型算法从来不是独立运行的。模型的并行策略怎么切分梯度同步怎么做显存如何优化容错如何恢复这些都需要算法团队和平台团队深度配合。如果是用第三方云平台训练自己的模型模型开发者只能在平台给定的框架里做适配跟平台深度调优的权限很有限。而商汤是“自己的模型跑在自己的平台上”日日新系列的训练过程反过来会暴露出平台层的各种瓶颈推动平台不断迭代。这种软硬一体的迭代节奏让大装置的训练效率和稳定性在实战中得到了充分打磨。从客户视角来理解这件事也很直接。如果你选择一个大装置这样的平台你买到的不是一个“黑盒算力包”而是一个已经被千亿模型验证过的整套方法论。平台支持什么并行策略、推荐什么数据格式、怎么设计推理服务这些都不是拍脑袋定的而是有大模型训练实战做背书的。对于缺乏从零搭建AI基础设施经验的企业来说这能少走很多弯路。另外软硬协同还体现在推理效率上。大模型部署到生产环境之后推理成本直接决定商业模式能不能跑通。优化的手段包括量化、蒸馏、批处理调度、KV Cache复用等等。这些优化不是简单的框架配置而是需要结合模型结构和硬件特性做联合设计。商汤的模型团队和平台团队在一个体系内协作模型发布时就已经做了针对性的推理优化用户拿到的往往是“开箱即用”的较高性价比配置。2.3 生态与开放新云市场第一不只是靠自嗨商汤大装置能做到新云市场第一还有一层原因在于它的生态打法。新云市场是一个非常强调“繁荣度”的市场——就算你自己的技术很强如果开发者生态起不来客户也会担心被绑定在孤岛上。在生态建设上大装置主要做了几件事一是兼容主流开源模型生态像主流的开源大模型如Llama系列、Qwen系列等平台上都有成熟的部署方案和优化配置用户迁移成本很低。二是提供业界标准的API接口尽量兼容OpenAI等主流API格式方便开发者平滑迁移。三是围绕行业头部客户做共创在金融、政务、能源、制造等领域沉淀可复制的解决方案。这些动作加在一起形成了一个正向循环生态越开放客户越多客户越多平台沉淀的行业Know-how越深场景经验越丰富平台能力越强。新云市场的竞争到最后拼的往往不是某一项单点技术的领先而是这个循环转得够不够快。商汤大装置这几年的增长很大程度上就是吃到了这个生态复利的红利。3. 从选型到落地企业接入AI算力平台的实操经验3.1 先想清楚你的算力需求到底是什么标题里的“第一”是市场格局层面的判断落到一个具体企业身上首先要面对的实际问题是我到底要不要用这类AI算力平台用的话怎么选这里我结合自己的实操经验给一些参考。第一步是明确需求类型。你需要的算力用途是训练、微调还是推理对应的平台选型差别非常大。如果是从零训练千亿参数的大模型那你要看的是平台的分布式训练能力支持多大规模的集群、并行策略是否灵活、断点续训机制是否完善、故障恢复时间多长。这种场景建议直接选商汤大装置这类以AI为核心的基础设施它的集群设计和容错机制是专门为超大规模训练打磨的。如果只是基于开源模型做行业微调几十亿到百亿参数级别对平台的分布式能力要求低一些但很考验数据和实验管理工具链的完善度。这种情况下重点考察平台的开发环境是否友好、数据标注和清洗工具是否好用、实验追踪是否方便。如果模型已经训练好要部署到生产环境提供线上服务那核心关注点是推理服务的性价比、弹性扩容能力、以及私有化部署的灵活性。推理场景往往对延迟和成本极其敏感一个优秀的推理优化方案能帮你省下大量成本。我自己做过一个测算同一个7B参数模型优化前后的单次推理成本可以相差一个数量级。第二步是评估数据安全和合规要求。新云市场的大部分头部平台都提供公有云服务和私有化部署两种模式。涉及敏感数据的行业客户通常更倾向于私有化交付。选型时需要确认平台是否支持在客户机房或者公有云隔离区里完成整套部署是否提供从数据接入、模型训练到推理服务的全链路安全方案。3.2 算力资源规划与成本控制的正确姿势我见过不少团队在接入AI算力平台时第一个月就烧掉了全年预算的一半。核心原因不是平台太贵而是资源规划没做对。这里有一个基本方法先算总量再拆阶段。第一步根据模型参数量、训练数据量、批次大小估算单次训练任务需要的总算力用GPU卡时数来衡量。第二步根据实验迭代周期预留调优和试错的空间一般是理想用量的1.5到2倍。第三步再拆分到每个月需要多少卡时对应平台的不同计费模式来做成本预估。计费模式上要多留一个心眼不同平台的计费粒度差异很大。有的按卡时计费有的按节点计费有的提供包年包月的专属资源池。对训练任务来说按需使用的费用看起来灵活但如果任务长期运行包周、包月的模式通常会划算得多。另外很多平台对闲时资源有折扣如果训练任务不是实时性要求很高的在线业务把任务安排在闲时执行可以省下一笔可观的费用。成本控制还有一个容易忽略的点任务失败导致的算力浪费。大模型训练经常遇到训练中断、loss爆炸、显存溢出等问题每一次失败都意味着前面的算力投入白费。所以评估平台时要特别关注断点续训的成熟度。好的平台能做到分钟级故障恢复坏的平台可能让你重新开始。这两个平台的差距对成本的影响是几十万甚至百万级的。3.3 团队能力匹配平台再强也得有人会用接入一个强大的AI算力平台并不意味着团队能立刻运转起来。我见过很多传统企业采购了上千卡的算力结果团队里无人能写分布式训练代码最终算力利用率不到三成。这个问题的根源不是平台而是团队能力模型没有跟上。新云市场的平台通常提供了比较完善的可视化开发界面和低代码训练工具这在一定程度上降低了门槛。但如果团队要做真正有竞争力的模型还是需要有能够理解并行训练原理、会用PyTorch等框架做分布式开发的工程师。在规划接入算力平台的同时一定要同步规划团队的能力建设。这里分享一个务实的方案团队里至少要有一个人深度研究平台官方文档和平台的技术支持建立直接联系。AI算力平台的知识壁垒很高很多时候一个配置参数就能让训练速度有数倍的差距。如果企业内部缺少这种技术接口人平台上线的初期大概率会遇到各种不顺利。4. 实战复盘在新云平台上训练与部署模型的五个关键坑4.1 网络和存储分布式训练最容易忽视的瓶颈分布式训练的时候很多团队一开始只盯着GPU型号和数量却忽视了网络和存储这两个隐藏瓶颈。这是我觉得最值得拿出来讲的经验之一。先看网络。几千张GPU并行训练每训练一步所有节点之间都要做梯度同步。比如用一个常见的全数据并行策略模型参数是70B单次梯度同步的数据量就是140B以上。这个数据量要在几秒钟内完成跨节点传输对网络带宽和延迟的要求极高。如果网络配置不当通信时间占训练时间的比例会指数级上升GPU利用率直线下降。实际应用中要优先选择带RDMA远程直接内存访问高速网络的算力集群并且在规划训练任务时通过拓扑感知的调度策略让通信频繁的节点尽量处在相近的网络层级。存储的问题同样隐蔽。大模型训练的样本通常是海量的小文件这些文件的读取速度直接影响数据加载效率。简单算一下如果数据加载速度跟不上GPU计算速度GPU就会空转等待利用率自然上不去。所以平台的数据缓存服务、高性能文件存储能力和GPU配置一样重要。选型时不妨做个压力测试用和真实任务接近的数据集规模模拟一下数据加载耗时。4.2 框架兼容性迁移成本比你想象的高很多平台在宣传时会强调自己“支持主流深度学习框架”但兼容的深度差别很大。我自己测试过一些平台PyTorch跑起来没问题但分布式训练用的先进特性比如混合精度、梯度检查点、自定义通信原语有些平台支持得并不完整。等到模型规模一大运行复杂训练代码的时候各种莫名的报错就会冒出来。所以评估平台时不要看宣传材料上写“支持PyTorch”就下结论要用自己实际训练的模型代码跑一遍。重点测试两个场景一是单机多卡训练验证多卡通信是否正常二是多节点分布式训练验证平台对分布式框架的支持是否足够顺畅。测试时建议先跑小规模任务确认整套流程通畅之后再上大规模。即使平台兼容性不错代码迁移仍然要预留时间。不同平台对镜像、容器、文件系统的管理方式不同数据导入导出的路径设计也不同。我们在实际项目里一般会预留一到两周做代码适配和性能压测。如果上线周期排得太紧这块很容易被压缩最后吃亏的还是自己。4.3 故障恢复训练中断是必然事件不是偶然事件训练千亿参数的大模型动辄需要几十天。这么长的时间里硬件故障几乎是必然发生的。GPU掉卡、机房网络抖动、节点宕机任何一个都可能导致训练任务中断。关键是中断之后平台能不能快速恢复损失了多少计算量。好的平台会有完善的checkpoint机制和自动容错调度。训练进程写checkpoint的频率要合适太频繁写盘占用资源太稀疏故障恢复损失大。平台层面要看它有没有自动检测故障节点并重新调度任务的能力。有些平台能自动把失败节点上的任务迁移到健康节点并从最近的checkpoint继续训练整个过程对用户基本透明。这种能力听起来基础实际能做到的平台不多。我们团队的经验是正式的大规模训练前一定要做一次故障演练。主动杀掉一个训练节点看平台的反应时间、恢复逻辑和checkpoint回退机制。这个问题如果等到真实训练时才发现代价会非常昂贵。4.4 推理阶段的显存与吞吐调优思路模型训练完成只是第一步上线推理才是持续花钱的地方。很多团队训练阶段做得不错一部署推理就发现成本高得离谱。这里涉及一个基础概念推理阶段的吞吐量和延迟是矛盾的。提高吞吐量通常靠加大batch size但这会增加单次请求的排队时间提高延迟降低延迟需要小的batch size但会降低GPU利用率。平衡的办法有几个。一个是做推理优化把模型量化到INT8甚至更低精度推理速度能提升数倍显存占用大幅下降。另一个是使用平台提供的推理框架成熟的框架通常内置了continuous batching连续批处理、PagedAttention等优化能动态地把不同请求拼装到同一批次里处理显著提升显卡吞吐。还有一个思路上的调整不是所有场景都需要调用最大最强的模型。很多业务用7B、13B的模型就完全够用推理成本远低于几百B的大模型。在平台选型的时候可以看看是否有灵活的模型路由或者模型编排能力帮助你在效果和成本之间找到最佳平衡点。4.5 数据安全与多租户隔离的合规实践企业使用AI算力平台时数据安全是绝对不能妥协的底线。特别是金融、医疗、能源等强监管行业训练数据往往包含高度敏感的私有信息。我见过一些企业因为图方便把数据明文放在平台上结果在审计时遇到很大的麻烦。比较稳妥的做法是分层管理核心敏感数据走私有化部署或者专有云隔离区脱敏数据走公有云算力。很多平台提供了VPC隔离、安全沙箱、加密存储等能力选型时要逐一确认。另外从数据导入开始就要建立完整的审计链数据什么时候上传、什么时候被哪个训练任务读取、训练产物保存在哪里都要有记录可查。如果你打算用平台上的MaaS模型服务直接调用API要注意提示词和输入数据里避免夹带隐私信息。调用第三方模型服务时数据传输链路要经过加密并且仔细阅读服务协议中有关数据使用的条款。这些细节看起来琐碎但在合规审查时每一环都很关键。5. 未来判断新云市场第一之后竞争才真正开始5.1 算力层会从“拼规模”走向“拼效率”商汤大装置虽然在中国新云市场拿到了第一但整个市场还在快速增长阶段远没到格局固化的程度。接下来几年我判断新云市场的竞争重心会从“拼规模”转向“拼效率”。规模层面的竞争相对简单你有多少卡、能建多大的智算中心这是资本和资源就能解决的问题。“效率”层面的竞争更难也更见真功夫。同样的算力怎么让训练速度更快、资源利用率更高、单位推理成本更低、模型效果更好这些才是长期壁垒。商汤大装置在这个方向上的布局已经比较清晰在算力层做精细化调度在平台层做全流程自动化在模型层做高效训练和推理优化在应用层沉淀行业Know-how。这套打法如果持续跑下去第一的位置会坐得越来越稳。5.2 大模型云平台的终局是“场景为王”另一个我的判断是新云市场的竞争终局不会停留在“算力买卖”上而是会走向“场景为王”。单纯卖GPU资源的天花板是很低的真正高价值的是帮客户解决业务问题。举个例子一个银行客户需要的不是“1000张GPU”而是“一个合规、稳定、低成本的智能客服系统”。前者是资源导向后者是场景导向。能够把算力、模型、应用三件事打包成一个场景化解决方案的平台才有最深的客户粘性。在这一点上商汤的基因有一些天然优势。商汤本身就是一个AI应用公司在智慧城市、智能汽车、内容生成等领域积累了大量的场景经验和行业客户。大装置作为底层基础设施天然可以和这些场景形成协同。其他厂商如果只是从云计算的角度来做AI基础设施缺少应用层的场景积累越往后会越吃力。5.3 企业现在应该做什么对于正在关注新云市场的企业我的建议其实很简单不要只盯着“谁是第一”看热闹要回到自己的业务需求做判断。如果你正在做大规模模型训练选择一个经过大型模型验证过的全栈平台远远好过自己拼装开源组件如果你只是在做模型微调和部署多关注推理成本优化和生态开放性如果你的数据合规要求极高就优先看私有化部署方案的成熟度而不只是看公有云上的跑分数据。我自己的经验是新云平台选型最好让团队里真正写代码的人深度参与。技术负责人看PPT工程师去读文档、跑测试、压性能两边信息对齐之后再做决策远比只看市场排名靠谱得多。市场第一是一个重要的参考维度但最终还是要选那个真正适配你团队情况和业务场景的平台。踩过几次坑之后你会发现没有最好的平台只有最合适的平台。