大模型部署算力平台有哪些

模型挑好了，卡从哪来这一步最容易卡住：自建、公有云按量、专业租卡平台、聚合平台、托管推理服务，名字都听过，但到底按什么顺序筛，很多人没想清。还有一种情况是卡已经在跑，发现加并发就爆显存、想换平台又怕权重搬不过去。这篇不重复榜单和自建划算不划算的结论，只给选型动作：先定场景，再算显存和并发，然后比计费口径、许可边界和迁移代价，最后给一份可以直接照做的排查清单。

模型挑好了，卡从哪来这一步最容易卡住。自建、公有云按量、专业租卡平台、聚合平台、托管推理服务，名字都听过，但到底按什么顺序筛，很多人没想清；还有一种情况是卡已经在跑，发现加并发就爆显存、想换平台又怕权重搬不过去。

这篇不重复榜单也不下「自建划不划算」的结论，只给一套选型动作：先定场景，再算显存和并发，然后比计费口径、许可边界和迁移代价，最后给一份能照着做的排查顺序。适合手上有一个明确要上线的模型、或者准备把现有服务换地方的团队。下面按顺序讲。

先把平台类型分成五类，别混着比

这五类的真正差异集中在三件事上：谁管卡、谁管模型、谁管扩容。管卡的人决定你要不要关心驱动和集群，管模型的人决定你手里有没有权重文件，管扩容的人决定高峰期你等的是分钟还是几天。先想清楚自己愿意接手哪一摊，选项立刻少一半。

注意同一家厂商可能同时提供两种形态，比如既卖按量实例又卖托管推理。比价之前先确认你点进去的是哪条通道，否则拿托管服务的规格去和裸卡比价，结论一定是错的。想知道各家当前在卖哪些通道，到 中转站与平台目录（/sites） 按类型筛一遍更省事。

先定场景，再挑平台，顺序反了会白花钱

场景这件事不是走流程。微调训练、批量离线推理、在线低延迟服务、内网私有化这四条路，对卡型、互联带宽和网络拓扑的要求几乎没有交集。先定场景再挑平台，能避免拿一张单卡机器的报价去支撑一个需要多卡互联的训练任务。

• 微调训练：先看卡间互联和显存总量，单卡性能排后面，因为瓶颈常在通信上
• 批量离线推理：先看单位算力成本和任务排队策略，延迟可以放宽，机器可以被抢占但要有重试机制
• 在线低延迟服务：先看单请求延迟和并发承载上限，再谈算力单价，顺序反了会买到便宜的慢卡
• 内网私有化：先确认数据能不能出内网，这一步会直接决定公有云按量这条路是否出局

场景确认之后，把不可妥协的约束写成一句话，比如「数据不出内网」「单请求延迟要稳」「任务可以排队但不能丢」。后面挑平台时，凡是不满足这句话的选项直接划掉，不要因为便宜而回头相商。

按模型、量化档位和并发算一遍显存

显存不够是部署里最常见的翻车点。算法其实不复杂：先估权重占用，再留出 KV 缓存，最后加框架自身开销，三项加起来才是你要买的卡。很多人只算了第一项，上线一加并发就爆，然后就怪平台不稳。

1. 第一步 估权重按模型参数量和量化档位估一个量级，档位越低省得越多，但输出质量的取舍必须自己用业务语料验，别信别人说够用。
2. 第二步 留 KV 缓存按峰值并发乘以单请求上下文长度倒推，上下文越长、并发越高，这块涨得越猛，经常反超权重本身。
3. 第三步 加框架开销推理框架自己也要吃显存，留一档余量，不要卡着上限下单。
4. 第四步 验证拿最小配置跑起来，逐步加压力看显存曲线和延迟拐点，拐点就是你真实的并发上限。

具体换算公式和不同量化档位的对照数值，到 工具目录（/tools） 里找部署测算相关的页面按当时口径核一遍。这类数字随框架版本和优化手段在变，拿一年前的表直接下单很容易买小或买大。

计费口径比单价更值得先对齐

两张报价单不能只比单价，因为算法根本不是一套。按时长、按卡天、按 token、按吞吐包干，这四种口径适合的负载完全不同。长跑型任务用按 token 计费可能很亏，短冲型任务用按卡天计费又容易为闲置买单。

计费外的部分同样要问：存储怎么算、外网流量是否另收、快照要不要钱、闲置多久自动关机、冷启动要等多久。这几项加起来经常比算力本身更能拉开总账差距。价格随时在动，到 价格追踪（/price-watch） 看当时的数字，本篇不写死任何价位。

许可证和权重能不能带走，是换平台的前提

开源权重不等于随便商用，这两件事经常被混为一谈。选平台之前先确认两件事：授权范围允许你怎么用，以及平台允不允许你把权重导出来自己部署。第二件事尤其容易被忽略，等你想迁移时才发现搬不走，前面省的钱全还回去。

权重可导出

你手里能拿到模型文件，换平台时重新部署即可，迁移成本主要花在环境和压测上

权重不可导出

托管服务常见形态，迁移等于从平台侧重新拉取或重新训练适配，时间要提前算进计划

授权范围

决定你能不能商用、能不能改、能不能再分发，签合同前逐条核对

涉及数据合规的项目，把平台的数据留存策略和日志策略一起看完再签，不要只盯着算力和价格。什么情况下这部分可以放宽：纯内部试验、数据本身就是公开语料、且服务不会对外提供。只要沾上用户数据，这部分就不能省。

迁移到新平台的排查顺序

决定换了之后，不要原地切换。先搭并行环境，按下面这个顺序验证，每一步都通过再进下一步。顺序颠倒的常见后果是并发还没跑稳就开始对账，账单差异根本看不出是算力贵还是流量贵。

1. 一 跑通最小可用单卡拉起推理服务，用同一组提示词对比新旧两边的输出，确认模型行为没变、依赖没缺东西。
2. 二 压并发找拐点逐步加压力，观察显存占用、延迟曲线和平台的限流阈值，找到性能开始掉的那一点。
3. 三 校验账单构成拉出两边的费用明细，逐项对比，确认差异来自算力、存储还是外网流量。
4. 四 切流量并留回退小比例切流观察一段时间，回退方案先准备好再放大比例。

什么情况下不建议换平台

换平台有很明确的不适用场景，认清这些能省下大量无用功。最典型的是痛点是偶发延迟抖动：这可能是推理框架参数没调好，也可能只是某段时间供给紧张，直接搬家很可能把问题一起带走，因为根因根本不在平台上。

• 当前唯一痛点是偶发抖动，先把框架参数、批处理策略和监控口径排查一遍再决定
• 迁移窗口期内业务不能停、又没有回退方案，先搭并行环境验证，别原地切换
• 用量很小且负载波动大，切换的人力成本很可能超过省下的算力钱
• 只是觉得别家便宜，但没算过存储、流量和运维的账，先去价格追踪页面把总账列出来

反过来说，如果当前平台已经卡死了你的上限，比如并发上不去、权重拿不出来、合规过不了，那迁移就是必须做的，这时候重点不是要不要换，而是怎么按上面的顺序换得稳。