1. 为什么云平台选型会被VC摆上台面
这两年有个很有意思的现象：越来越多的VC开始把“云平台策略”当成投后管理的一个重要模块来抓，而不是像以前那样完全放手让被投企业自己决定。
起因其实很朴素。我接触过不少管理合伙人，他们在看被投企业的季度经营数据时发现，AI 创业公司的成本结构跟前几年的SaaS公司完全不是一回事。SaaS公司最大的成本是销售和市场费用，而AI公司最扎眼的支出常年是“云资源消耗”这一项，有些项目在模型训练高峰期，云账单能占到月度现金消耗的40%以上。一家天使轮或A轮的创业公司，一年在算力上烧掉几百万甚至上千万，这不是个案，而是普遍状态。
更让GP们坐不住的是另一件事：他们发现被投企业之间在算力采购上的代价差异非常大。同样一个千亿参数模型的训练任务，A公司在某个平台上花的钱可能是B公司的1.5倍，原因可能仅仅是B公司早期拿到了更合适的资源包，或者选了一个对训练场景更友好的网络架构。这个差别放在单月看好像是“运营效率问题”，但放到一轮融资的生命周期里看，就是在直接侵蚀估值。
所以现在很多VC内部开始讨论一个问题：如果我们手上有一个portfolio，里面聚集了大量AI创业公司，那我们在云平台选择上到底应该帮他们做点什么？是统一谈一个框架协议？还是针对每个项目单独给建议？或者干脆搭建一个内部共享的算力资源池？
要回答这些问题，第一步是把“云平台选型”从一个技术采购问题上升到一个投资组合管理问题来看待。这不是CTO一个人能定的事，也不是财务拍脑袋能定的，它需要技术判断、商务谈判和投资视角三方面同时在线。
2. AI创业公司对算力平台的真实诉求拆解
既然要帮一堆AI公司选平台，就得先搞清楚这些公司到底在平台上看重什么。我拆过很多AI项目的技术尽调报告，发现一个共性：如果只问“你用的云平台好不好”，十个创业者里有八个会说“还行”——这个回答基本没有信息量。真正有效的方式是按照业务阶段和技术栈拆开问。
2.1 训练场景：卡量、互联带宽与稳定性是三个生死线
做基础模型或垂直大模型训练的公司，对算力平台的诉求跟所谓“上云”完全是两回事。他们要的不是虚拟机和对象存储，而是一个能跑大规模分布式训练的高性能计算环境。
训练场景下，最核心的指标不是单卡性能——今天主流厂商能拿到的卡型其实差不多——而是三件事：
第一是卡量配额。一个百亿参数的模型动辄需要几百张卡，千亿模型直接冲到几千张。很多平台宣传页写得天花乱坠，但真要下单的时候告诉你“库存紧张，需要排队”，这就非常耽误事。对VC来说，“能不能快速拿到卡”往往决定了被投企业的研发进度。
第二是节点间的互联带宽。集群训练最怕的是通信瓶颈。用InfiniBand或NVLink做过集群互联的多机多卡训练，跟普通以太网对比，训练收敛速度差距可以到30%甚至以上。这个参数虽然不写进PPT，但在技术尽调里必须直接问清楚。
第三是任务中断的恢复机制。大规模训练最痛的是跑到第80个epoch时节点挂了，如果平台没有自动checkpoint和快速重启的机制，损失的时间成本是灾难性的。所以现在有经验的算法团队都会问平台“最长连续无故障运行时间”和“故障恢复SLA”，而不是只问“一小时多少钱”。
2.2 推理场景：延迟SLA规格和熟知场景的弹性伸缩
如果你的被投企业做的是AI应用层产品，比如AI客服、Agent工作流、内容生成工具，那它们的核心诉求就不是“集群训练”，而是推理链路的延迟、成本和稳定性。
这里面有个很基础但经常被忽略的问题：很多创业公司以为“反正都是GPU，换个平台没差别”，但推理场景对平台的调度器、冷启动速度、地域节点分布都有隐性要求。比如一个面向国内用户的聊天产品，如果GPU节点都在偏远地区，首token响应时间就可能直接拉胯，用户是不会关心的，他们会直接放弃这个产品。
还有弹性伸缩逻辑。AI应用的流量波峰波谷比传统互联网业务更极端——大促、发版、热点事件都会让调用量瞬间翻几倍。平台能不能在几十秒内自动扩容GPU实例池，直接决定了用户体验，也决定了企业要浪费多少预算去养闲置算力。
2.3 容易被忽视的工具链、合规和迁移成本
除了算力本身，还有一个经常被低估的维度是平台的软件生态。我见过一个创业团队，算法模型已经训练好了，但在某平台上想上线推理服务时要自己从头搭一堆K8s基础设施，白白拖了两周。反观那些自带MLOps工具链的平台，模型注册、版本管理、自动部署、监控告警都是开箱即用的，研发效率差距非常明显。
数据合规也要提前确认。如果被投企业做的是医疗、金融或政务相关场景，训练数据可能要留在特定地域，甚至要做私有化部署。还有一个隐性但重要的问题是迁移成本——很多企业一开始没想清楚，到头来会发现从一家云平台迁到另一家，光是数据出口流量费用、模型架构适配的时间成本，就足够烧掉不少预算了。
关于模型架构适配，简单解释一下：不同的云平台背后集成的分布式训练框架各有差异。你在选型的时候不搞清楚，等模型跑到一半才发现某些算子在目标平台上性能平平，迁移或重写的成本几乎等同于重新训练一遍，这就是为什么很多创业团队“上云容易下云难”的直接原因。
3. 主流云平台的能力拼图
市面上的平台看着多，其实按照对AI创业公司的适配度来分，基本可以归成几个梯队。VC在梳理portfolio的云策略时，脑子里得有这张拼图。
3.1 综合云厂商：生态完善的“主力部队”
这里说的是那些老牌云厂商——阿里云、腾讯云、华为云这一梯队。它们的共同优势是产品线极度丰富，从底层的计算、存储、网络，到上层的模型服务、数据处理、安全合规，几乎你能想到的它都有。对AI创业公司来说，选择这类平台最大的好处是“一站式”，团队不需要在基础设施上花太多心思，可以把精力放在算法和应用层。
但这类平台也有短板：GPU资源在大模型训练高峰期的供给经常偏紧，而且商务政策比较复杂，有些以公有云起家的平台在私有化交付和私有网络互通方面不一定灵活。综合来说，它们最适合做主力生产环境，不太适合做纯训练型的超算环境。
3.2 专业算力平台：性价比和弹性的“突击队”
用AutoDL这类专业算力平台来举例吧。这类平台的典型特征是：专门为深度学习场景设计，租卡流程非常快，按小时计费，价格往往比大厂同类实例低不少，尤其适合短周期任务、算法实验和中小规模的模型微调。很多AI创业公司的早期版本就是在这种平台上跑起来的，因为起步成本低、门槛低、解放了工程师的算力焦虑。
不过这类平台也有自身边界。服务规模较大之后的稳定性不一定能跟老牌云厂商比，且部分专业平台在网络互联、存储高可用方面与大厂有差距，高并发生产环境是否合适需要实测验证。另外，这类平台的长期商务政策、技术支持和容灾能力在不同团队之间的口碑差异很大。但对很多处于早期阶段的创业公司来说，把它当作“算力资源池”来补充弹性和控制成本，是非常理性的选择。
3.3 国际云厂商与开源方案的角色
如果你的portfolio里有出海业务或者研发团队在海外，那国际云厂商的平台（比如AWS的SageMaker、Google Cloud的Vertex AI）也是绕不开的选项。它们在AI工具链、全球化节点覆盖和文档成熟度上确实领先，特别适合做国际化产品和数据合规要求高的场景。但缺点是价格偏高，而且在部分区域的资源访问体验对国内团队并不算友好。
开源方案方面，比如OpenStack这类开源云平台，适合两类企业：一类是数据敏感度极高必须私有化部署的；另一类是体量已经足够大，自建云平台的边际成本比租用公有云更低的。但我的总体评价是，除非团队里就有资深的运维专家，否则在早期阶段我不建议创业公司自建云——省下的那点算力成本，往往会在人力维护上找回来。
为了更直观地展示差异，我给一家典型的A轮AI创业公司做云平台对比时，会习惯性拉一个这样的表：
| 评估维度 | 综合云厂商 | 专业算力平台 | 国际云厂商 |
|---|---|---|---|
| 资源供给弹性 | 较强，但高峰期有排队 | 灵活，短租方便 | 强，区域覆盖广 |
| 训练性能 | 中上（视具体规格） | 高（场景专注） | 高（配套完善） |
| 推理延迟SLA | 好，节点分布广 | 视区域而定 | 好，全球节点丰富 |
| 工具链成熟度 | 高 | 中 | 很高 |
| 数据合规/私有化 | 灵活度中等 | 偏弱 | 灵活度高，但跨境需评估 |
| 成本控制空间 | 中等，商务政策复杂 | 门槛低，性价比高 | 偏高 |
| 快速支持响应 | 标准SLA | 社区/工单为主 | 标准SLA+生态 |
每个项目的情况不同，这张表只能作为初筛思路，不能替代对具体场景的实测结果。我见过有企业在专业算力平台上跑推理，延迟高到无法接受，也见过有企业在大厂云上做训练因为利用率不够导致成本爆炸。选型一定是“场景先行”的，不能只看品牌和名气。
4. 从投资组合视角看云平台决策框架
VC选云平台跟单个企业选云平台，视角有本质不同。单个企业考虑的是“我这个月的任务怎么最省钱地跑完”，VC考虑的是“我整个portfolio怎么在可接受的成本范围内，获得最优的算力保障和技术前瞻性”。
4.1 评估维度与量化打分逻辑
我自己在帮portfolio做云平台评估时，会建立一套标准化的评分维度，权重可以根据基金的投资阶段和技术偏好调整。通常包含以下五个维度：
- 算力供给能力（权重30%）：GPU库存充足度、交付周期、可扩展上限、多卡多机集群的互联能力、断点续训支持。
- 成本结构（权重25%）：单位算力价格、预留实例折扣、闲置资源回收机制、数据流量和存储的隐性收费、账单的透明度。
- 技术生态（权重20%）：MLOps工具链的成熟度、开源框架适配性、模型部署的便利度、API的稳定性。
- 稳定性与SLA（权重15%）：故障率、自动恢复能力、技术支持响应速度、是否有专人服务。
- 合规与数据安全（权重10%）：数据加密、访问控制、敏感信息的隔离方案，以及是否满足行业或地域的合规要求。
每个维度内部再做细分打分。比如“成本结构”不是只看目录价，我会让财务同事帮忙对比“预估实际月账单”和“目录价之差距”，因为很多隐性费用只有在账单里才能看得出来。
4.2 谁适合单云策略，谁适合多云策略
portfolio里不同类型的公司，最优解往往差别很大。早期项目（种子轮-A轮）通常只有一个算法团队，没有专职的运维，这时候我会建议它们“抱紧一家主力平台的大腿”，把所有任务尽量集中在一个生态里。原因很简单：分散只会增加团队的学习成本和运维复杂度，而早期最缺的就是人力和时间。
到了B轮以后，业务量和数据量都上来了，就应该认真考虑多云策略。一种比较典型的做法是：训练任务放在性价比高的专业算力平台，生产环境的推理服务放在综合云厂商，再配置一个备用资源池以防某个平台上资源紧缺或者出现故障。这样做既控制了成本，又增加了供应链韧性。
但多云不是简单地“多接几家”。我见过不少团队在两家平台上各跑一半业务，结果数据和代码的复杂度翻倍，还时不时出现同步问题，团队的精力几乎都耗在“平台差异适配”上，真正的业务推进反而被拖累。没有统一的资源调度层之前，盲目分散风险会更复杂。所以正确的做法是先确立主平台，再逐步扩展，而不是从一开始就平均分配。
4.3 VC与被投企业的关系边界
这里我想多说一句。VC帮被投企业选平台、谈价格，是好事，但也要注意边界。最忌讳的是因为一家基金在某平台拿了较低的折扣或返点，就直接要求被投企业必须用某一家——这既可能损害创业公司的技术自主性，也存在利益冲突风险。
比较健康的做法是，VC把自己的角色定位成“信息中枢”和“谈判杠杆”：跟主流云平台建立整体合作关系，拿到portfolio级别的折扣，然后把资源和价格信息透明地分享给被投企业，让每个项目的技术负责人自己决定用还是不用。VC不越位去替CTO做技术决策，但可以帮CTO省下大量商务谈判的时间。
5. 落地执行：从框架到协议的实操路径
光有决策框架还不够，真正的价值在于落地。下面我从尽调、商务谈判、监控和复盘三个角度分享一下实际操作中值得注意的地方。
5.1 尽调时问云计算相关的关键问题
很多投资团队的尽调问卷里，关于云计算的只有“公司用了哪家云、月均费用多少”这一行，信息量几乎为零。要想真正评估一家AI公司的云资源使用效率，至少应该往上叠几个问题：
- 过去6个月的云资源月度消耗趋势，以及每次训练任务的平均单位成本。
- 当前GPU的利用率是多少，是否有闲置资源，闲置的原因是什么。
- 是否有自动弹性伸缩策略，伸缩的触发条件是什么。
- 如果未来6个月业务翻倍，现在选用的平台是否能在两周内提供足够的算力。
这些问题看起来琐碎，但从回答的内容能很快判断出这家公司的技术团队有没有真正的工程化能力。如果说不出GPU利用率，那就说明他们只是在“用云”，没有在“管云”，这个信号对投资判断很重要。
5.2 商务谈判中的关键筹码
跟云平台谈判时，VC最核心的筹码是“规模采购承诺”。你可以把portfolio里所有AI公司的预计算力消耗汇总成一个大框架，然后用这个总量去换取更低的单价、更快的交付优先级、更灵活的资源包退改政策。
但具体到执行层面，会有一个值得注意的点：很多云平台的折扣是跟你承诺的消耗量挂钩的，如果你今年签了一个很高的量，实际用不掉，明年续约的时候不仅谈不到更好的价格，反而可能要面临惩罚性条款。所以我建议跟平台签阶梯式协议——基础折扣+达成额外消耗目标后的追加返点，这样既保住了价格，又避免了过度承诺。
另一个容易被忽视的是技术服务条款。AI创业公司最需要的不是“标准7x24工单支持”，而是能直接对接到底层工程师的快速通道。尤其是训练高峰期遇到故障，早一个小时恢复可能就意味着省下几十万的算力成本。这个支持等级如果在签框架协议时没谈清楚，后面很难再补。
5.3 用投资组合的视角来监控和复盘
选定平台、签完协议不是结束，而是要建立一个持续的监控和复盘机制。我会建议每家被投企业每个月把以下三项数据同步给投后团队：
- 实际算力消耗与预算的偏差率。
- 不同模型训练任务的平均单位成本（比如每训练一次某模型花多少钱）。
- 平台故障次数和平均恢复时间。
积累两三个季度的数据后，你会发现有一些非常有价值的判断依据：比如某家的算法团队把70%的算力花在了实验性探索上，这可能说明他们在算法方向上的战略还比较模糊；或者某家的推理成本占比逐月上升，这说明产品在增长，但同时意味着需要提前沟通下一轮融资前的成本结构优化方案。
对于VC内部来说，这些数据还有一个更大的作用——当你投了15家AI公司的时候，你可以从数据中看出整个portfolio共同面临的算力瓶颈是什么，然后针对性地去跟平台谈新的合作方案，或者规划是否有必要投一个算力调度中台类的项目来服务整个生态。这才是“portfolio视角”比“单项目视角”高级的地方。
6. 我在实际操作中的几个原则性体会
最后分享几点经验，不谈流程，只谈判断。
第一，别被“算力价格”带节奏，要算综合成本。很多创业公司选平台只盯着每卡每小时的价格，但实际上训练任务总费用里，GPU费用可能只占一半，另一半是存储、网络、数据加载和人工调试的时间成本。一个看起来便宜的卡，如果配套服务的可用性差，最终总成本反而更高。
第二，平台切换要趁早。我自己见过很多项目，在早期非常随意地选了一个平台，半年后模型跑起来了、数据积累起来了，再想换平台，成本已经非常高了。所以VC早期可以“放养”，但至少应该跟被投企业的CTO聊一次云平台策略，哪怕就是把本文讲到的这些维度过一遍，帮他们建立一个判断坐标系，也比完全不管要好得多。
第三，技术团队的真实口碑比任何评测都靠谱。做选型尽调时，与其花时间研究各家官网的文档，不如直接问那些已经在这个平台上跑了半年以上的一线算法工程师。他们的回答往往一句话就点破问题，比如“这个平台在某家厂商的卡上跑某个算子特别慢”“这家平台的故障恢复是半自动的”，这些信息才是选型判断里含金量最高的部分。
第四，AI技术栈更新太快，别把某个平台的绑定当成“终身决策”。今天的好选择，可能半年后就被一个新的专业算力平台或者新的服务模式超越。保持可迁移性才是硬道理——模型代码尽量用标准的PyTorch/DeepSpeed框架，数据存储用兼容S3接口的对象存储，推理服务保持K8s化部署。这些看起来是老生常谈，但在关键时刻，它们是VC手里保护portfolio的“逃生通道”。
算力是AI创业的硬约束，而平台选型是这个硬约束里最值得磨的杠杆。一把好的杠杆，能帮整个portfolio撬动效率与成本的双重优势；一把坏的杠杆，轻则多烧钱，重则把一个好项目拖进技术与资金的双重泥潭。
