企业官网建设流程全解析

上个月和一个在头部机构做投后的朋友聊项目，他跟我抱怨：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 评分卡模板（含权重）

我常用的评分卡长这样：

权重可以根据 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 的主动优势。