上个月和一个在头部机构做投后的朋友聊项目他跟我抱怨Portfolio 里 20 多家 AI 创业公司今年光是处理算力报销和平台选型就占掉三分之一的工作量。这件事确实被很多人低估了——AI 公司的业务可以千差万别但底层都长在同一片土壤上训练要 GPU微调要 GPU推理还是要 GPU。云平台选得对不对直接决定被投企业的烧钱速度、模型迭代节奏以及账面上那点现金还能撑几个月。我一直觉得VC 帮 portfolio 挑云平台本质上不是一次采购而是一次技术尽调加一次成本规划的综合动作。这篇文章就从这个角度切入把“哪些云平台值得进 portfolio 的供应商名单”这件事拆开讲从 AI 技术输出能力怎么识别到算力支持怎么实测再到具体执行流程和避坑清单。不管是投资经理、投后负责人还是被投团队的 CTO都可以按这套框架直接上手用。1. 从投资视角重新理解“云平台”它已经变成 portfolio 的公共底座很多人觉得选云平台是个技术活应该让被投公司自己搞定。我的观点相反当 portfolio 里有十几家、几十家 AI 公司时云平台就不再是某个 CTO 的局部决策而是整个投资组合的公共底座。这个底座选错了后面每一步都会带着系统性的偏差。1.1 先盘点 portfolio 里到底有哪几类算力需求动手选平台之前先别急着看各家宣传页第一步应该先做一次“需求盘点”把被投公司按算力使用模式分成几类。我通常会分三类来看。第一类是模型预训练型特征是单次任务占用卡量大动辄几十上百张卡训练周期以周甚至月计算对卡间互联带宽和多卡扩展性要求非常高最怕的是训练中途节点故障导致断点丢失。第二类是模型微调和对齐型这类公司通常同时跑几十个任务每个任务用四到八张卡对单卡性能没那么敏感但对平台的任务调度效率、排队时间、镜像复用这些能力更敏感。第三类是推理服务型GPU 型号要求不高关键是稳定在线、弹性伸缩、推理延迟可控、单位请求成本低。三类公司放在一起对平台的诉求往往互相冲突。预训练团队希望独享大集群微调团队希望随时有小批量资源推理团队希望成本压到极致。VC 做选型时如果只盯着某一类需求后面一定会有人不舒服。所以我建议把所有需求先列成一张表按“训练任务占比、微调任务占比、推理任务占比”三个数字去粗估 portfolio 的整体画像之后再用这个画像去套平台能力。1.2 VC 不该把算力选型完全丢给 CTO现在回答一个本质问题选型这么专业为什么 VC 要亲自下场我从实操中总结出三个理由。第一是估值保护。AI 公司的估值模型里烧钱速度是最敏感的变量之一。同一个业务方向算力成本控制得好和不好可能差出三到五倍。我见过两家做类似产品的被投一家坚持用按需付费一家通过 portfolio 集采拿到了包年折扣半年下来光算力成本就差了两百多万对估值的影响是实打实的。第二是投后赋能的抓手。大部分 AI 创业公司的采购能力很弱CTO 会看技术但不一定会谈商务。VC 拿着整个 portfolio 的需求去和云平台谈框架协议不管是资源折扣、技术支持等级还是售后 SLA都能拿到比单个创业公司更优的条件。第三是风险筛查。AI 算力市场这两年冒出来很多新平台有的靠补贴拉新烧钱速度比被投公司还猛。一旦平台资金链出问题停服甚至跑路被投公司的数据、模型权重、训练日志全在里面迁移成本极高。VC 提前做准入背调相当于给 portfolio 加了一道风控防线。这三条理由不是一个可选项而是每个 VC 在算力这件事上都必须同时守住的底线。1.3 更稳的姿势主力平台加二供备份顺着上面的风险逻辑走就会发现一件很反直觉的事给 portfolio 选平台不应该追求“选最好的一个”而应该追求“选一个最好的组合”。我的习惯做法是“一个主力 一个备份”。主力平台占 70% 到 80% 的算力用量保证稳定性、技术支持和商务折扣备选平台占 20% 到 30% 的用量承担溢出流量、临时需求也充当容灾通道。这样设计有三个好处一是不会被单一平台锁定谈判时手里有牌二是主力平台出故障时可以快速切换不至于全组停摆三是被投团队对两个平台都保持熟悉真要发生大规模迁移也不会手忙脚乱。千万不要把所有资源压在一家身上。我之前遇到过一件事某个 portfolio 全员用同一家平台结果该平台一个城市节点故障整个团队停摆两天正好错过活动窗口期。这种损失远远大于换平台省下的那点折扣。2. 可输出 AI 技术的平台到底在输出什么标题里有一个关键词是“可输出 AI 技术”。很多投资人第一次看到这个词会困惑云平台不就卖算力吗还能输出 AI 技术其实这正是这几年 AI 云平台和传统云平台最大的区别。能把“AI 技术”作为服务输出的平台和被投公司之间的合作深度是完全不同的。2.1 从“卖机器”到“卖能力”AI 技术栈完整度是关键传统云平台提供的是一台 GPU 服务器操作系统、驱动、深度学习框架、分布式环境全都要自己搭建。对一个 10 人规模的 AI 创业公司来说光是把环境配好、跑通一个分布式训练任务就能耗掉 CTO 一两天的时间。而真正面向 AI 场景设计的平台会把这套东西标准化成预置能力常用的深度学习镜像、模型权重下载加速、深度学习框架环境的一键拉起、微调训练任务的模板化提交。我让团队测过两组数据传统云平台从零搭一个大模型微调环境包括装驱动、配环境、搭分布式通信、做镜像熟练工程师大概需要半天到一天成熟的 AI 云平台用预置镜像和模板基本十分钟之内能把环境拉起来。这个差距对创业公司的研发节奏影响是决定性的。尤其在窗口期很短、竞争激烈的时候早一天跑出结果可能就决定了融资故事能不能讲通。评估技术栈完整度时建议看四个具体模块训练环境是否开箱即用、是否提供模型仓库和数据集管理、是否内置微调工具链、推理部署是否有配套模板。四个模块都齐备的平台才有资格说自己在“输出 AI 技术”。2.2 异构算力调度最值得被 VC 盯紧的技术分水岭判断一家 AI 云平台是不是真技术出身我最看重的一点是异构算力调度能力。所谓异构就是平台手里不只一种卡可能有不同厂商、不同代际、不同显存规格的 GPU这些卡不能简单堆在一起当库存卖得靠一套调度系统把它们统一池化再按任务需求动态分配。调度系统写得好的平台能做到用户提交任务后自动匹配最优资源资源碎片被充分利用高峰时段也能保证重要任务优先启动。调度系统写得烂的平台典型表现就是排队时间不可控、任务频繁被抢占、多机训练时通信瓶颈严重明明单卡性能不差整体效率却很低。VC 尽调时怎么判断调度能力不用自己去读源码但可以问几个具体问题资源池支持哪些 GPU 型号的混合编排GPU 显存是否支持细粒度切分任务队列有没有优先级策略发生节点故障时任务能不能自动恢复如果平台方能拿出真实的任务调度数据和故障恢复记录可信度会高很多如果只给口号和 PPT那就要留个心眼。2.3 模型服务化与推理优化训练之外的另一半战场还有一个容易被 VC 忽略的板块是推理服务化能力。很多 AI 创业公司训练出的模型要变成产品推理才是长期花钱的地方。如果一个平台只能在训练阶段提供算力推理阶段要自己搭服务、自己调推理引擎那它的 AI 技术输出就不算完整。好的平台会提供推理网关、自动扩缩容、模型量化、批处理加速这类服务。比如同样一个模型把它从高精度格式量化到 INT8 或 FP8推理吞吐可能提升一倍以上但量化过程需要平台层的工程能力支持创业团队自己搞往往要踩很多坑。被投的 CTO 们最怕的就是在推理引擎优化上消耗时间平台如果有成熟的服务化方案模型上线周期可以从两周缩短到一两天。这块评估起来很简单直接让平台方提供推理服务的压测报告再把典型业务场景丢进去实测看延迟、吞吐和单位成本。数据不会骗人。2.4 自研程度与开放接口识别“套壳平台”的几个信号尽调时还要搞清楚一个问题平台的这些 AI 能力到底是自研的还是把开源项目缝合到一起的。自研平台通常有完善的 API、CLI、开发者文档和版本管理机制被投公司可以方便地把平台能力集成到自己的研发流程里遇到特殊需求也能提定制化方案。套壳平台则往往只做了浅层封装表面上看什么都有实际用起来处处受限没有公开的 API 文档、无法定制调度策略、私有化部署时核心组件交付不出来一旦上游开源项目变更功能可能直接受影响。怎么快速识别三个信号足够第一看开发者文档是否完整且持续更新第二问平台能不能提供定制化调度策略而不是只有标准模板第三测试私有化部署场景下平台的核心能力能不能完整交付。这三个问题问完平台的成色基本就清楚了。3. 算力支持怎么评估从纸面参数到真实可得性算力评估是整个选型里最容易踩坑的部分。宣传页上的参数通常都很好看但真实跑起来完全是另一回事。这一章我讲讲怎么从“纸面算力”走到“真实可得算力”。3.1 别只盯着“显卡 tops 算力表”很多投资人喜欢拿着单卡算力表来比较平台比如看到某张卡的 FP8 算力指标很高就觉得这个平台很厉害。这个习惯需要改一下。单卡峰值算力只代表理论极限真实训练效率还取决于卡间互联带宽、显存容量、通信拓扑、驱动和框架的适配程度。举个例子某些消费级显卡的 FP8 算力指标并不低但在多卡互联能力和长时间运行稳定性上和数据中心级显卡有明显差距。也就是说纸面算力高不代表实际训练任务就跑得快。我见过一个被投团队两家平台宣传的算力差不多实测同一批微调任务A 平台完成时间比 B 平台多了将近一倍问题就出在多机通信拓扑上。正确的评估姿势是看三组真实数据单任务平均排队时长、多卡扩展效率、长时间训练任务无故障运行的时长。这三组数据只有平台的真实监控报表能给纸面参数给不了。3.2 调度能力决定算力的“到手率”另一个关键问题是平台说自己有多少万张卡跟你实际能不能用上是两回事。算力可分和算力可得之间隔着一层调度系统。我陪一个被投做过压测某平台在宣传材料里把资源池写得很大结果我们提交了一个 16 卡训练任务排队四个小时才启动中途还因为节点故障被强制迁移了一次前面跑的几小时全部作废。换了一个平台后同样的任务策略下十分钟内就能启动运行过程也稳定。两家平台纸面参数差不多真实体验天差地别核心差距就是调度和故障恢复能力。所以评估算力时不要把“总量”当作核心指标要把“到手率”当作核心指标。跟平台对齐时争取把排队容忍度、故障自动恢复、断点续训时间这几个指标写进 SLA这样后面使用才有保障。3.3 算一笔总账计价模型决定真实成本算力成本这块VC 通常比较敏感但容易被细节坑到。不同平台的计价方式差异很大按卡时计费、按整机包月、竞价实例、抢占型实例看起来花样很多但要算清楚真实成本必须用“总拥有成本”的概念。这里说的总拥有成本不只是 GPU 单价还包括存储费、日志和快照费、模型和数据回源流量费、以及任务失败后重跑的成本。我见过一个案例训练费用看起来比同行便宜 20%结果日志存储、模型检查点存储和数据回源的附加费用加起来把便宜的部分全吃了回去账单反而更高。建议让候选平台提供一份详细的计费清单然后把被投公司典型业务场景套进去分别算一遍月度总成本。比价时统一口径别用 A 平台的单项价格跟 B 平台的整机价格硬比。这种事情没有捷径只有把每一笔费用掰开揉碎了算才能看出谁在裸泳。3.4 数据合规与网络链路容易翻车但经常被忽略最后说两个经常被忽略但很容易翻车的点数据合规和网络链路。AI 公司的数据有时涉及行业敏感信息数据不能出域。平台的数据中心部署位置、是否支持私有化或专有云部署、能不能提供专线接入这些都是硬指标。如果平台给不出清晰的合规说明再便宜也不要选。网络链路同样重要。分布式训练需要节点间高带宽低延迟通信如果平台把节点分散在多个机房节点间走公网互联那多机训练的稳定性就很成问题。选型时要重点看平台有没有同地域高可用集群节点间是不是内网互联有没有提供内网传输加速的专项方案。这几点确认清楚了训练过程中的“隐形掉速”才能避免。4. 实操流程为 portfolio 做一次完整的平台尽调理论聊完这一章放一套我反复用过的实操流程照着走就能完成一次 portfolio 级的平台选型。4.1 五步走的整体流程第一步盘点需求把被投公司按训练、微调、推理三类场景分类量化出月均算力需求和峰值需求第二步建评分卡确定各维度权重第三步向候选平台发起技术问卷和商务洽谈先筛掉明显不合格的第四步安排被投 CTO 做 POC 测试把关键指标跑出真实数据第五步综合评分和商务条件做决策签框架协议。这五步看起来简单但每一步都要输出文档需求清单、评分卡、问卷记录、测试报告、商务备忘。文档化很重要不然选型过程容易拍脑袋后面复盘也没凭据。4.2 评分卡模板含权重我常用的评分卡长这样评估维度权重核心问题核心算力可得性25%排队时间、资源充足度、扩展效率AI 技术栈完整度20%预置镜像、微调工具、推理服务、模型仓库成本与计价透明度20%GPU 单价、附加费用、折扣空间稳定性与运维15%故障率、断点续训、工单响应时效安全与合规10%数据合规、私有化能力、审计报告生态与开放性10%API 成熟度、文档质量、合作伙伴生态权重可以根据 portfolio 构成动态调整。如果被投里推理类应用占多数就把“AI 技术栈完整度”里模型服务化相关的细分项权重调高如果预训练任务多就把“核心算力可得性”权重继续拉高。评分卡的核心价值是统一口径避免多个投资人凭感觉给意见。4.3 POC 怎么测四组测试拿真实数据评分卡建好后最花时间也最有价值的是 POC 测试。我建议安排四组测试每一组都记录时间戳和观测指标。第一组模拟真实业务负载跑一个小规模模型微调任务记录从提交到任务启动的时间。第二组跑多卡训练任务从 1 卡逐步扩展到 8 卡、16 卡看加速比有没有接近线性增长这一步最能暴露通信瓶颈。第三组压测推理服务模拟峰值流量观察延迟、吞吐和成本消耗。第四组测试断点续训能力人为触发一次节点故障或强制迁移看任务能不能恢复、恢复后从哪个检查点继续。四组测试都完成之后让被投 CTO 写一份测试报告把每家平台的实际表现横向对比。数据面前谁在裸泳一目了然。4.4 商务条款三个容易被忽略的关键点最后是商务环节。除了单价我建议重点盯三个条款。第一折扣是否按资源使用量阶梯式调整。很多平台的折扣在前几个月很优惠用久了反而变贵一定要把阶梯机制写清楚。第二SLA 的赔付标准和响应时效。不要只看“99.9%”这种数字要看排队时长是否纳入 SLA、故障响应是几分钟级别还是几小时级别。第三退出机制和数据迁移支持。写清楚退订流程、数据导出格式、迁移支持方式这对后续调整供应商至关重要。这三个条款写不进合同后面再谈就很难。我在谈判时通常会加一条“无理由按季度调整配额”以及“提前一个月通知的资源退订无违约金”这两条基本能保证 portfolio 不被平台绑死。5. 常见问题与排查技巧实录最后这部分我把实际操盘中反复踩过的坑整理成一组速查问题。如果你正在帮 portfolio 做选型这些问题大概率会用到。5.1 宣称可用率很高任务却一直排队平台宣传“可用率 99.9%”但实际提交任务要排队好几个小时。原因在于可用率通常只算服务在线时间不计排队等待。解决办法是在 SLA 里明确一条在资源池有空闲的前提下任务从提交到启动的时间不超过某个阈值。如果平台不敢承诺说明调度余量不足要谨慎。5.2 显存明显够用多卡训练速度就是上不去这种情况先别怀疑 GPU先看网络和存储。简单排查方法是先用系统命令看卡和显存占用再用通信库自带的测试工具跑一遍节点间带宽。如果带宽不达标大概率是网络拓扑或者交换机瓶颈需要平台方介入调整。VC 不需要亲自做这类排查但要让被投 CTO 知道往这个方向查避免被平台“踢皮球”。5.3 不同平台报价口径不统一没法直接比A 平台说“8 卡训练一小时 XX 元”B 平台说“整机月付 XX 万”两个报价根本没法直接比。要先把计费口径统一成“有效算力小时成本”也就是实际完成的训练任务量除以总花费再叠加排队、中断、附加费用等因素综合测算。口径统一之后平台之间的真实差距往往比想象中更大。比如按单卡价看A 平台似乎更便宜但把任务中断重跑的成本算进去后可能是 B 平台更划算。这种口径差异只有真正算过一笔账才知道。5.4 纸面算力很高真实吞吐差距很大有些平台的算力指标看着很高实际跑典型任务时吞吐和效率都一般。这种情况很可能是峰值算力与真实可用算力之间的差距被宣传放大了。解决方式是在尽调问卷里加一道题请平台给出典型模型微调任务的实测吞吐数据。横向对比几家之后纸面数据和实测数据的差值就能看得清清楚楚。如果平台连这种实测数据都不愿意给基本可以排除。5.5 被投中期想换平台数据迁移怎么做换平台的触发点可能是成本、稳定性甚至是被投团队与平台协同效率变差。不管原因是什么数据迁移都是绕不开的坎。建议从选型一开始就要求平台支持标准数据格式导出同时准备一个共享文件存储作为中转把模型权重、数据集、镜像全部标准化。真到切换那天一天内可以完成大部分迁移。这个方案我给好几个被投做过执行起来比想象中顺畅。最后分享一点个人体会。在我做过的几次 portfolio 级算力平台选型里影响决策质量最大的往往不是某一个技术指标而是被投 CTO 和平台技术团队之间的沟通效率。一个平台如果文档清晰、工单响应快、愿意陪我们做压测那它大概率是靠谱的。另一个我长期坚持的做法是保留一个占用量 20% 左右的二供平台让被投团队每隔一个季度跑一次小规模任务上去既保持对主平台的议价压力也防止过度绑定。算力这件事最怕的就是把主导权全部交给别人最后只能被动接受账单。希望这套思路能帮你把算力管理变成 portfolio 的主动优势。