团队要跑一个训练或推理任务，采购单上同时出现「算力平台」和「分布式计算平台」两个词，看着都像在卖卡，报价口径却完全不一样，选错了要么多花钱，要么活干不完。这篇不评比谁强，只帮你分清两者各自解决哪一段问题、什么情况下要两个一起上、什么情况下其中一个可以直接跳过。
采购单上同时冒出「算力平台」和「分布式计算平台」两个词，是很常见的事。两者的报价口径通常完全不一样，一个按资源时长算，一个按调度能力和工程配套算。选错方向的代价也很直接：要么卡买多了闲置，要么活根本跑不完。这篇不评比谁更强，只帮你分清它们各自管哪一段。
判断起点其实很简单：前者回答「算力从哪来」，后者回答「活怎么摊开」。把这两个问题拆开看，采购单上的两个词就不再打架了。下面按任务形态逐项对号入座。
先分清两件事：一个是卖资源，一个是管干活
算力平台交付的是资源，形态是机器、容器或接口，你买到的是可以跑东西的地方。分布式计算平台交付的是作业能力，形态是调度器、运行时和一套作业描述，你买到的是把一件事拆到多台机器上跑完的本事。两者解决的问题不在同一层。
- 算力平台
- 把 GPU、存储、网络打包成可按量或按合同买到的资源，关心的是有没有卡、什么时候能开机
- 分布式计算平台
- 把一次任务切成多份分到多台机器上跑再合并结果，关心的是任务能不能切、切完怎么同步、挂了怎么续跑
- 叠放关系
- 同一套物理集群上可以只跑算力平台交付，也可以在上面再叠一层分布式调度，两者不是替代关系
| 你所在的阶段 | 该找谁 | 判断依据 |
|---|---|---|
| 手上没机器，先要能跑起来 | 算力平台 | 有没有卡、开机快慢、按什么口径计费 |
| 机器有了，任务一台装不下 | 分布式计算平台 | 切分方式、跨机通信、断点续跑 |
| 机器和调度都有，就是跑得慢 | 两边都要看 | 先量网络开销，再决定是加卡还是改切分 |
| 任务跑一次就扔，没人维护集群 | 算力平台优先 | 调度器的运维成本可能高于算力本身 |
按任务形态对号入座，别一上来就上分布式
最常见的浪费，是把单机任务硬塞进分布式调度里。多出来的通信、调试和运维成本，往往比省下的时间多。先看任务属于哪一类，再决定要不要叠分布式这一层。
- 单机装得下的任务：单卡或单机多卡能跑完的推理、微调、数据处理，只需要算力平台，上分布式只会多出通信和调试成本
- 装不下但能切分的任务：数据并行、张量并行、流水线并行这类训练或大批量批处理，才需要分布式计算平台，前提是框架本身支持你要用的切分方式
- 跑一次就扔的临时任务：优先按量租算力平台，别顺手自建分布式调度，调度器本身的维护成本常常比算力费更贵
- 长期固定节奏的任务：把分布式平台当成内部标准件，作业模板固化下来，重复利用率才划得来
- 介于两者之间的任务：先按单机跑一遍拿基线，有了真实耗时再判断跨机的收益是否为正
这里有个容易被忽略的前提：分布式能不能提速，取决于通信占比。切分不当、网络带宽不够时，多机反而比单机慢。所以「任务能不能切」只是必要条件，「切完划不划算」才是决定条件。
选型核对清单：六个问题问完再签字
- 任务规模先算单次任务的显存和数据量，看能不能塞进一台机器。到 /models/deploy 按模型和量化档位过一遍，再决定要不要分布式
- 切分方式确认框架支持哪些并行策略，跨机通信走什么网络。带宽不够时多机更慢，这一条要在签字前问清楚
- 容错要求任务跑十几个小时要不要断点续跑，节点挂了是整单重跑还是局部重试。答案决定了你是否真的需要分布式平台
- 计费口径算力按卡时、按整机还是按合同包段，调度开销算不算在账单里。两边口径对齐之后再比价，具体数字到 /price-watch 核对
- 迁移成本现有代码要不要改启动方式、改依赖版本、改数据读写路径。改造成本经常被低估，要单独列一行
- 退出路径这个平台不用了，权重、数据和作业配置能不能原样搬走。搬不走的方案，议价空间会被锁死
这六个问题里，只要有两个以上答不上来，就说明选型还没到签字的时候。先把答案写出来，再回到报价单上做比较。
几个常见的误判，以及什么情况下结论不成立
下面三个误判在技术选型会上出现频率最高。它们不是知识点错误，而是把两层东西混在一层里比较造成的。
- 误判一：把分布式平台当成更高级的算力平台，以为买了调度就等于有卡。实际它本身不产出算力，你还是得有地方跑
- 误判二：认为多机一定比单机快。通信占比高的任务在多机上会更慢，切分不当的时候尤其明显
- 误判三：只比单价不比总账。调度开销、数据搬运、失败重跑带来的损耗，都要算进总成本里
- 误判四：把「团队会用」当成「团队能维护」。会提交作业和会排障是两件事，排障能力才是长期成本
什么情况下这套分析不成立：如果你的任务始终在单机范围内，或者团队没有能维护调度器的工程能力，那么分布式这条路当下就不该走。这时候先老实按量租卡，把任务跑通、把基线量出来，比提前上架构更划算。反过来说，如果你已经在为排队和多机同步反复加班，那问题多半不在算力平台，而在缺一层调度。
动手验证：用小任务先量一遍再决定
选型会上争论半天，不如拿一个真实但有代表性的小任务跑两遍。一遍单机，一遍多机，记录端到端耗时而不是只看计算部分。数据搬运和启动等待往往才是差异的来源。
- 跑基线挑一个代表性的小任务，单机版先跑一遍，记录端到端耗时、峰值显存和失败重跑次数
- 量网络到 /tools/speed-test 量出你这边的网络与接口延迟基线，跨机通信的开销心里先有个数
- 对口径到 /compute/platforms 和 /compute/providers 对齐各家交付形态与计费口径，再回到 /compute/sizing 按自己的模型算卡数，当时的数字以页面为准
- 写对照表把结果整理成一张表：任务、配置、耗时、成本、失败重跑次数，下次选型直接复用这张表
| 验证项 | 怎么量 | 量完看什么 |
|---|---|---|
| 端到端耗时 | 单机与多机各跑一次真实小任务 | 跨机收益是否为正，而不是只看计算段 |
| 网络开销 | 用站内测速工具拿本地基线 | 通信占比高时，多机可能是负收益 |
| 失败重跑 | 记录节点异常后的恢复方式与次数 | 重跑一次就吃掉多少收益，值不值得 |
| 迁移成本 | 试改一个真实作业的启动方式和依赖 | 改造工时是否已经超过预期收益 |
量完以后大概率会得到两种结论：要么单机确实够用，省下的是调度这一层的人力；要么跨机收益明确，那就把作业模板和容错策略一起固化下来。两种结论都比拍脑袋决定要稳。
下一步把你手上的任务按上面的清单过一遍，然后到站内算力平台与选型页面核对当时的交付形态和计费口径，再决定要不要叠分布式这一层。→常见问题
算力平台和分布式计算平台是同一个东西吗？
不是。算力平台提供的是可购买、可调度的计算资源，交付的是机器、容器或接口；分布式计算平台提供的是把一次任务拆到多台机器上执行并合并结果的能力，本身不产生算力。你可以只用算力平台，也可以在上面再叠一层分布式调度，两者是叠加关系不是替代关系。
什么情况下我不需要分布式计算平台？
任务能在单机范围内跑完、跑一次就结束、或者团队没有维护调度器的工程能力时，都不需要。这时候按量租算力平台，把代码跑起来就行。判断标准看 /models/deploy 里按模型和量化档位算出的显存需求，一台机器装得下就别上分布式。
两个都上是不是更保险？
不一定。叠加会同时带来算力成本和调度运维成本，任务如果对跨机通信敏感，多机反而更慢。更稳的做法是先单机跑通一遍、记录端到端耗时，确认瓶颈确实在单机容量上，再决定要不要引入分布式调度，而不是一开始就按最复杂的方案铺开。
