Category: Uncategorized

先说结论：评测要产出的是一张表，不是一个排名

很多团队做算力平台选型时，第一步就错了：打开几家平台的价目页，把同型号卡的小时价抄下来，选最便宜的那家。这个做法的问题不在于草率，而在于它假设了”同一张卡在不同平台上等价”。实际情况是，同样标注 RTX 4090、同样 24G 显存的实例，磁盘 IO 可能差出数倍，实际可用算力可能因为虚拟化损耗而打折扣，故障恢复策略可能完全不同。单价只是整张成本曲线的一个切面，用它做唯一依据，等于用一张照片去判断一个人的健康状况。

更有效的做法是把评测变成一次有结构的记录：固定一组维度，每个维度给出可执行的检查项，把观察结果填进同一张表，最后横向对照。这篇算力平台评测框架要交付的不是”哪家最好”的结论——那个结论会随你的任务类型而变——而是一套可复用的评测方法与一张记录表模板。用同一套表去评三到五家平台，你得到的是自己的选型依据；换一个季度重新填一遍，你得到的是市场变化的一手数据。

一句话版本：把评测拆成价格结构、资源可用性、配套性能、上手体验、售后兜底五个维度，每个维度用具体动作去测而不是用印象去猜，最后用一张统一格式的记录表做出可对比的决策。

为什么单看价格一定会踩坑

价格本身没有错，错的是把它当成了可比量。同型号卡在不同平台上的单价差异，往往对应着完全不同的服务内容，这些差异至少体现在四个方面。

第一是计费粒度。有的平台按秒计费、关机不计费；有的按小时取整，开机不足一小时也按一小时算；有的把存储与快照单独计费，实例关停后仍然按存储容量收费。对于需要频繁创建和销毁实例的开发场景，计费粒度的影响可能超过单价差异本身——一个单价贵 10% 但按秒计费的平台，在实验型负载下可能比单价便宜但按小时取整的平台更省钱。

第二是实际可用算力。同一张卡在虚拟化环境下可能出现算力损失，尤其在高密度切分的实例上。宣传的算力参数是硬件规格，不是你能拿到的算力。这件事只有实测才能发现：跑一次标准的矩阵计算基准，对比参考值，就能看出差异。

第三是配套性能。训练与推理任务的瓶颈经常不在 GPU，而在磁盘 IO、内存带宽或网络。数据集加载慢会让 GPU 长时间空转，模型保存慢会拖长每次实验的迭代周期。这些性能不写在价格表上，却直接决定你的有效算力。

第四是隐性限制。单实例的磁盘容量上限、出网带宽、并发连接数、快照数量、甚至是否允许长时间运行——这些限制不体现在单价里，但会决定你的任务能不能顺利完成。踩过坑的人都知道，一个”价格很便宜但磁盘只有几十 G”的实例，对需要处理大规模数据集的团队毫无价值。

五维评测框架

第一维：价格结构

这一维的目标不是找最低价，而是搞清”你实际会为使用付多少钱”。检查项如下。

• 计费粒度的最小单位是什么？关机、暂停、快照保留状态分别是否计费？
• 存储、快照、镜像、出网流量是否单独计费？单价分别是多少？
• 包月与预留的折扣力度、最低时长要求、是否可退或可转？
• 新用户优惠、时长赠送、推荐返利的实际折算价值是多少？
• 有没有阶梯计价或错峰折扣？触发条件是什么？
• 账单的透明度如何？能否按实例、按项目拆分查看消耗？

把这些问题问完，你会发现所谓”单价”只是一个中间变量。真正的决策变量是”你的典型使用模式下，一个月会产生多少费用”。建议用两个典型模式分别测算：实验型（频繁开关机、短时任务）和稳定型（长期运行、包月）。

第二维：资源可用性

这一维衡量的是”你想用的卡，多久能真正拿到”。检查项如下。

• 目标卡型在工作时段（含晚高峰）的开卡成功率如何？需要排队时，平均等待多久？
• 是否提供预留实例或排队优先级机制？锁定失败时的补偿规则是什么？
• 卡池的地域分布如何？能否指定节点或机房位置？
• 实例被意外回收或中断的频率如何？中断后是否有自动重调度？
• 同一卡型是否存在多个代际或配置混用（如不同带宽的版本）？能否指定？

这一维对训练任务的意义远大于推理任务：一次被中断的长训练可能损失数小时甚至数天的进度。判断标准很直接——如果你要做超过数小时的连续训练，可中断实例只适合配合断点续训使用，长期稳定负载应该考虑预留。

第三维：配套性能

这是最容易被忽略、又最直接影响效率的一维。检查项如下。

• 磁盘的读写吞吐与 IOPS 表现如何？用大文件顺序读写与小文件随机读写分别测一次。
• 数据集加载与模型保存的实际耗时是多少？这是迭代速度的直接决定因素。
• 内存容量与带宽是否与卡型匹配？是否存在”卡很强但内存拖后腿”的情况？
• 出网带宽与延迟如何？需要拉取模型权重或数据集时，这项影响巨大。
• 多卡实例的卡间互联是否达标？做多卡任务时通信开销占总时间的比例是多少？

把这一维测扎实的价值在于：它决定了你的 GPU 有多少时间在真正干活。一块长期等待数据加载的显卡，无论单价多低都是浪费。

第四维：上手体验

这一维衡量的是”从注册到跑通第一个任务需要多久”。检查项如下。

• 可用镜像与社区环境是否丰富？目标框架（PyTorch 等）的版本是否齐全、是否预装常用依赖？
• 从注册、实名、充值到开出第一台实例，全流程耗时多久？有没有卡点？
• 文档质量如何？SSH 连接、端口映射、数据上传下载的说明是否清晰可执行？
• 是否支持常用工作流（Jupyter、VS Code 远程、命令行提交任务）？
• 数据迁移路径是否顺畅？从对象存储或本地批量上传的速度与工具是否可用？

这一维对个人开发者与初创团队权重最高：它直接影响”试错成本”。上手顺畅的平台即使单价高一点，也常常因为迭代速度更快而更划算。

第五维：售后兜底

这一维衡量的是”出问题时有没有人管”。检查项如下。

• 支持渠道有哪些？工单、在线客服、社群、电话，各自的响应时间承诺是多少？
• 服务等级协议（SLA）的具体条款是什么？可用性承诺的数字、计算口径、赔付方式分别怎么写？
• 实例故障、数据丢失、任务中断的责任划分与补偿机制是否明确？
• 是否有数据保留与销毁政策？删除实例后数据何时清理、能否申请延迟删除？
• 发票开具、合同签署、企业认证等商务流程是否支持？

这一维在一切正常时几乎不产生价值，但在出问题的那一刻会成为决定性因素。评估时不要只看”有没有客服”，要看”赔付条款是否可执行”——写了可用性承诺但没有明确计算口径与赔付流程的条款，实际约束力有限。

评测记录表模板

下面的模板是为逐平台填写设计的，建议对每一家候选平台填一行，横向对照。字段刻意保持精简，确保真的会被填完。

字段	记录内容	为什么重要
卡型与配置	型号、显存、CPU、内存、磁盘容量与类型	同型号不同配置不可直接比价
单价与计费粒度	小时价、最小计费单位、关机是否计费	决定实验型负载的真实成本
实测算力	标准基准的实测值或相对参考值的比值	识别虚拟化损耗
磁盘 IO	顺序读写吞吐、随机读写 IOPS	决定 GPU 空转时间
排队时长	工作时段与晚高峰的开卡等待时间	决定任务能否按计划开始
网络与出网	带宽、延迟、出网计费方式	影响数据与权重拉取效率
上手耗时	注册到跑通首个任务的分钟数	衡量试错成本
赔付条款	SLA 数字、计算口径、赔付方式	兜底能力的实质内容
隐性限制	磁盘上限、快照数量、并发限制等	避免任务中途被卡住
结论	适合的任务类型与不适合的场景	把评测转化为可执行决策

填表有两个纪律值得坚持：一是同一张卡型、同一套基准脚本，跨平台测出来的数据才可比；二是记录测试时间点，因为价格与可用性都会变化，三个月后的同一张表会得出不同结论，而时间戳能让差异变得可解释。

常见评测陷阱

• 跑分与真实负载脱节。用统一的算力基准跑分很整齐，但你的真实任务是数据密集还是计算密集、是长上下文还是短请求，瓶颈完全不同。基准分只用来横向对比硬件一致性，不能代替任务级验证。建议至少跑一次自己的真实任务。
• 忽略隐性费用。存储、快照、出网、镜像、闲置实例的保留费用，都可能让账单明显高于按单价推算的预期。评测时应该实际产生一次完整账单周期再判断。
• 在非高峰时段测可用性。凌晨开卡顺畅不代表工作时段顺畅，可用性必须在目标使用时段测。
• 把宣传参数当作实测结果。虚拟化损耗、多卡互联的实际效率、共享存储的波动，都只有实测才看得出来。
• 只测一次就下结论。平台状态是波动的，单次测试的偶然性很高。关键维度建议在不同时段重复测两到三次。
• 评测完不留档。不做统一记录，评测结论就只存在于个人印象里，团队无法复用，也无法在下一轮采购时做纵向对比。

常见问题

小团队没有精力做五维评测怎么办？

按任务关键度做裁剪。如果你的负载是短时实验，重点测价格结构、上手体验和配套性能里的磁盘 IO 三项就够了；如果要做长时训练，优先测资源可用性、配套性能和售后兜底；如果涉及企业合规与客户交付，售后兜底与商务条款的权重最高。无论怎么裁剪，跨平台使用同一套测试脚本这一条纪律不能省，否则数据不可比。

基准测试应该用什么工具？

用你自己任务的最小可运行版本，比用通用基准更有参考价值。做法是挑一个你熟悉的、耗时几分钟到十几分钟的真实任务（比如训练一个小模型若干步、跑一次推理吞吐测试、加载一次真实数据集），在每家平台上跑同样的脚本、记录同样的指标。这样得到的数据直接对应你的使用体验，比抽象的跑分更能指导决策。

价格差异多大才值得换平台？

没有固定阈值，但可以用”迁移成本”做基准。迁移涉及数据搬迁、环境重建、流程调整与团队重新熟悉，这些成本是实打实的。经验做法是：把迁移的一次性成本折算到预期的使用周期里，如果节省的费用在周期内无法覆盖迁移成本，就不值得换。另外要注意，价格差如果来自服务内容差异（比如配套性能更弱、售后响应更慢），那实际上不是价差而是产品差异。

怎么验证赔付条款是真管用的？

看三件事：SLA 的具体数字与计算口径（是月度可用性还是单实例可用性）、赔付的触发方式（自动赔付还是需要申请）、以及赔付的形式（现金、代金券还是时长补偿）。如果条款里只有原则性表述而没有计算口径与流程说明，实际可执行性就存疑。评估时可以直接向客服提一个假设场景，看对方能否给出明确的处理路径，这比读条款更能说明问题。

评测要多久做一次？

建议在两类时点重做：一是价格或产品发生明显变化时（新品发布、大幅调价、平台合并），二是自身负载特征发生明显变化时（从实验转向生产、从单卡转向多卡）。日常不需要频繁重测，但可以保持一项低成本动作：在常用平台上定期跑一次真实任务，记录耗时与花费，作为趋势对比的基线。

避坑清单

• 只用单价做决策。计费粒度、配套性能与隐性限制共同决定真实成本，单价只是其中一个切面。
• 样本量不足。只测一家、只测一次、只测高峰外时段，结论都不牢靠。
• 不做记录。没有统一的记录表，评测结论无法在团队内复用与纵向追踪。
• 忽略自己任务的瓶颈特征。先搞清你的任务是计算密集还是数据密集，再决定测什么。
• 把宣传参数当实测值。算力、带宽、互联效率都要自己验证，尤其在虚拟化环境下。
• 忘记评测的核心目的。评测是为了把任务匹配到合适的平台与卡型，不是给平台排座次；脱离任务谈优劣没有意义。

按画像给建议

• 个人开发者：把评测做轻，聚焦三项——计费粒度、磁盘 IO、开卡速度。用你最熟悉的一个小任务在两家平台上各跑一次，记录耗时与花费，基本就能做出选择。避免为了”找到最优平台”而反复迁移，时间本身就是成本。
• 初创团队：建立一份轻量的平台档案，用统一的记录表模板覆盖两到三家候选，每季度更新一次价格与可用性字段。把评测的责任固定到一个人，并把结论沉淀成团队可读的文档，避免每次采购都从零开始。
• 企业与研究机构：把评测升级为采购流程的前置环节，重点覆盖售后兜底与商务条款两个维度，把 SLA 数字、赔付流程、数据保留政策作为硬性准入条件。评测记录应归档留存，作为后续续约与供应商评估的历史依据；涉及合规场景时，把信创与数据边界要求作为筛选的第一道关卡，再在合格名单内做性能与价格对比。

回到方法本身：评测的价值不在于一次性选出”最佳平台”，而在于把选型这件事从感觉变成可复核的记录。五维框架提供了检查的完整清单，记录表模板保证了横向可比，重复测试的纪律让结论能跨越时间保持有效。市场价格与服务随时在变，但只要你手里这套框架和这张表还在，任何时点都能重新跑一遍流程——这才是评测框架真正的用处。文中提及的价格区间来自公开渠道整理，仅用于建立量级感，请以各平台官方实时价目与服务条款为准。

先说结论：先写需求画像，再谈价格与合同

算力采购最常见的失败模式，不是买贵了，而是买错了。团队接到任务后直接去比价，锁定一家平台签下包月，运行一个月后发现负载特征和当初的假设完全不同——任务从训练转向了推理、并发量比预期低一个数量级、或者数据集规模增长导致磁盘成为瓶颈——于是既付了闲置的钱，又没能满足实际需求。问题的根源在于采购流程的起点位置错了：它应该从需求画像开始，而不是从价目表开始。

一份可用的需求画像回答四个问题：要做什么任务、模型或数据规模有多大、每天或每月需要运行多长时间、未来半年到一年会怎么增长。这四个答案决定的不只是”租什么卡”，还决定了适合哪一类采购路径、该用按需还是包月、以及合同里哪些条款必须写清楚。国内算力市场的供给已经相当丰富——零售向平台、大厂云、国产信创三条路径各有明确的适用边界，价格从 4090 的 1.2-2.5 元/时到 H100 的 9.6-12 元/时不等——供给充足意味着”选错”的成本比”买贵”更高，因为选错要付出的是整个项目的迭代效率。

一句话版本：采购流程应该是”需求画像 → 路径选择 → 条款谈判 → 阶梯放量”四步；先小额试用验证假设，再包月锁定稳定基线，最后才考虑长期预留或自建，每一级都要用前一级的真实数据做依据。

第一步：需求画像评估表

需求画像要落到可记录、可复核的字段上，而不是停留在”我们需要一些 GPU”这种表述。下表给出了四个必须回答的问题及其影响。

画像维度	要回答的问题	对采购决策的影响
任务类型	训练、微调、推理，还是数据处理与实验并行？	决定卡型取向：训练看算力与互联，推理看显存与带宽
规模	模型参数量级、数据集大小、单次运行时长？	决定显存档位、磁盘容量与数量级预算
时长	月均运行小时数、是否连续、是否有明显峰谷？	决定按需、包月还是预留
增长	未来半年到一年负载增长的量级与节奏？	决定是否需要弹性与预留，以及合同期限
约束	数据合规、发票、SLA、地域、信创要求？	决定可选的采购路径范围

把这张表填完，很多采购决策会自动浮现。比如”月均 40 小时、有明显峰谷、未来增长不确定”的画像，指向的是按需实例加弹性上限；”月均 300 小时以上、连续运行、增长可预期”的画像，指向包月或预留；”数据不可出域、需要信创合规”的画像，会把可选范围直接收窄到特定路径。画像的价值就在于把模糊的需求翻译成可比较的条件。

第二步：三条采购路径的对比

国内可选的采购路径大致分三类，它们之间的差异不只是价格，而是服务模型完全不同。

第一类是零售/开发者向平台，代表有 AutoDL、晨涧云、智星云、恒源云、趋动云、算家云、OpenBayes 等。它们的特点是计费粒度细、开卡快、镜像与社区环境丰富、价格带密集，4090 类卡型约 1.2-2.5 元/时，包月折算可到 0.8-1.5 元/时。适合开发、实验、微调与中小规模推理，采购流程轻——注册充值即可用，几乎没有商务流程。限制在于高端卡高峰期需要排队、售后以工单为主、企业级合规与发票体系相对简单。

第二类是大厂云，代表是阿里云、腾讯云、华为云。优势是 SLA 明确、合规模板完善、网络与存储配套成熟，能够与对象存储、专线、监控、权限体系一起打包，适合对稳定性与合规有硬要求的生产环境。代价是单价更高、可选配置体系复杂、存储与公网带宽单独计费，采购流程涉及商务与合同环节，周期更长。

第三类是国产信创路径，核心是昇腾 910B 生态，提供 64G 显存与 1.6TB/s 带宽。它的价值主要在合规对冲与供应链安全，适用场景受政策约束驱动而非纯性价比驱动。采购时需要考虑三到六个月的迁移适配期，这段周期必须在项目排期中显式留出。

路径	代表	价格特征	采购周期	最适合
零售/开发者向	AutoDL、晨涧云、智星云、恒源云等	4090 约 1.2-2.5 元/时；包月折算 0.8-1.5 元	小时级，注册即用	开发、实验、微调、中小推理
大厂云	阿里云、腾讯云、华为云	单价更高，存储与带宽单独计费	天到周级，含商务与合同	生产环境、合规、发票、SLA
国产信创	昇腾 910B 生态	整机或包月口径为主，企业级报价	周级，含适配期规划	信创合规、供应链对冲

三条路径不是互斥关系。实际中最常见的是组合使用：零售平台做开发与突发，大厂云跑生产与合规交付，国产方案用于信创项目或作为长期备份。采购规划时按”路径 + 用途”分别立项，比试图用一家满足所有需求更现实。

第三步：商务条款清单

价格谈完之后，真正决定风险敞口的是合同条款。下面这份清单按重要性排列，建议逐项确认。

• 服务等级协议（SLA）。可用性承诺的具体数字、计算口径（月度还是单实例）、统计周期，以及未达标的处理方式。只有原则性表述而无计算口径的条款，实际约束力有限。
• 赔付机制。赔付的触发方式是自动还是需申请，赔付形式是现金、代金券还是时长补偿，申请时限与所需材料是什么。这一项要在签约前问清流程，而不是出问题时才研究。
• 数据保留与销毁。实例删除后数据何时清理、是否可申请延迟删除、备份策略如何、是否支持指定地域存储。涉及敏感数据的团队，这一项应与内部数据合规要求逐条对齐。
• 发票与合规资质。发票类型与税率、开具周期、是否支持企业合同与对公付款、是否具备所需行业资质。政府与国企项目对这些条款的要求通常是硬性的。
• 退出机制。包月或预留的提前终止条件、未使用时长的处理方式、数据迁出的支持与时限、是否有迁出费用。退出条款决定了你的锁定风险，往往比折扣率更值得争取。
• 价格保护与调价条款。合同期内的价格是否固定、能否包含续约优先权或价格上限约定。在市场报价波动较大的时期，这一条的价值会明显上升。
• 资源保障条款。包月或预留是否承诺具体的资源保障、是否可在约定卡型与地域间调整、调整的限制条件是什么。

第四步：小额试用 → 包月 → 预留的阶梯策略

采购最忌讳一步到位。推荐按三级阶梯放量，每一级都用上一级的真实数据做决策依据。

第一级是小额试用：按需开通、控制预算，目标不是跑生产任务，而是验证三件事——平台的真实性能是否符合预期、你的任务在目标卡型上能否顺利运行、上手与运维成本是否可接受。这一级的花费通常很小，但它能过滤掉大部分错误选项。试用的动作要具体：跑一次真实任务、记录磁盘 IO、观察高峰时段的开卡等待、体验一次故障或工单响应。

第二级是包月锁定稳定基线：把经过试用验证、负载平稳的部分签成包月。行业经验是月均使用 150 小时以上时，包月通常比按需省 20-30%；低于这个量级则按需更灵活。签订包月前要确认两件事：负载确实稳定（试用期数据可以支撑这一判断）、以及退出条款可接受（包月合同一般不可退）。

第三级是预留或自建：只有在负载规模足够大、时间足够长、且经过前两级验证之后，才考虑预留实例或自建集群。自建的门槛尤其高——行业里常被引用的经验判断是利用率超过 70% 才值得认真评估自购，而且要算完设备折旧、电费与机房、运维人力、机会成本四笔账。在没有充分数据前，把自建作为三级方案而不是起点，能避免大部分沉没成本。

三类团队的采购清单

个人开发者

• 优先选零售向平台，注册充值即用，避免任何长期合约。
• 按需 + 按秒计费是关键，避免为闲置付费。
• 先用量级最小的卡跑通流程，确认任务可行再升级卡型。
• 关注新用户优惠与时长赠送，但不要为了折扣改变自己的用量节奏。

初创团队

• 建立”稳定基线包月 + 突发按需”的组合结构，避免单一卡型绑定。
• 至少保留两家平台的可用账号，作为供给波动与价格变化的对冲。
• 把算力支出按项目归集，便于判断每个业务线的真实成本。
• 为关键任务配置断点续训能力，让可中断实例也能承担部分训练负载。
• 签订任何包月前，先确认退出条款与数据迁出支持。

企业与研究机构

• 以合规、SLA、发票、数据保留作为准入门槛先行筛选，再在合格名单内比价。
• 把商务条款清单作为标准附件，逐项与供应商确认并归档。
• 生产与实验分离：生产负载用有 SLA 保障的资源，实验负载用弹性按需资源。
• 评估信创方案时，把三到六个月的迁移适配期显式写入项目排期与预算。
• 建立用量与成本的周期复盘机制，作为续约谈判与自建评估的数据基础。

常见问题

应该先谈价格还是先做试用？

先试用。价格是明面上的，可以随时从官网获得；而平台的真实性能、可用性与服务响应，只有实际使用过才知道。正确顺序是先用小额预算完成试用、拿到数据，再带着明确的需求画像与用量预估去谈价格——有数据支撑的谈判，比空口询价能拿到的条件好得多。反过来说，如果先谈定价格、再发现平台不适合，退出的成本远高于试用的花费。

包月折扣多少才值得锁定？

不要只看折扣率，要看”锁定后的总支出”与”按需方案的总支出”哪个更低。折扣 30% 但实际只能用到一半时长，实际成本反而更高。经验上月均使用超过 150 小时是包月开始划算的分界；此外要确认合同是否可退、能否转让、是否有资源保障条款。如果折扣力度大但退出条款苛刻，本质上是用灵活性换价格，这个交易只有在用量高度确定时才划算。

大厂云比零售平台贵那么多，值吗？

看你的约束条件是否落在大厂云的能力范围内。如果任务需要明确的 SLA、完善的合规与发票体系、与现有云上架构（对象存储、专线、权限、监控）打通，这些能力本身就是价值，贵出来的部分是购买确定性。如果只是训练实验或批量推理，对可用性与合规没有硬要求，零售平台的性价比优势更明显。很多企业的实际做法是混合：生产在大厂云，实验与突发在零售平台。

什么情况下应该考虑自建？

三个条件同时成立时值得认真评估：负载长期稳定且可预测、利用率持续高于阈值（行业经验是 70% 以上）、团队具备机房与运维能力。即使满足，也要把四笔账算完整——设备折旧、电费与机房、运维人力、机会成本。自建的优势是长期单位成本更低与数据完全自主，劣势是固定资产风险与灵活性丧失。在没有充分数据支撑前，租赁始终是风险更低的起点。

采购合同最容易漏掉什么？

退出机制与价格保护。大多数团队会把注意力放在价格与配置上，而忽略”如果半年后不想用了怎么办”和”如果市场调价了合同怎么处理”。这两条在签约时往往可以通过争取获得更有利的条款，但在已经产生争议之后再谈就没有空间了。建议把”数据迁出支持与时限””提前终止条件””价格固定或上限约定”三项作为必谈条款。

避坑清单

• 跳过需求画像直接比价。不知道自己要什么任务、多大规模、多少时长，任何价格都无从判断贵或便宜。
• 一步到位签长约。没有试用验证就签包月或预留，等于用真金白银验证一个未经验证的假设。
• 只看单价不看计费粒度。关机是否计费、存储是否单独收费，会显著改变实验型负载的真实成本。
• 忽略退出机制。包月通常不可退，数据迁出可能受限，这些条款决定了你的锁定风险。
• 只绑定一家供应商。供给波动与价格变化是常态，保留第二家可用账号是低成本的保险。
• 把 SLA 当作营销话术。要看具体数字、计算口径与赔付流程，能执行的条款才是条款。
• 忘记把适配期写进排期。涉及信创方案时，三到六个月的迁移适配是刚性成本，不写进计划就等于隐含地宣告项目延期。

按画像给建议

• 个人开发者：把采购简化成”选一家上手快的零售平台、用按需实例、按秒计费、每月复盘一次花费”。这个阶段采购的目标是降低试错成本而不是压低单价，不要为了省几块钱去做跨平台迁移。像 AutoDL 这类平台提供多种卡型按小时计费，适合快速验证。
• 初创团队：用组合结构与阶梯放量控制风险。先用按需完成试用、再把平稳负载包月、把突发留给按需，同时保持两家平台可用。财务上按项目归集算力成本，让每个业务线都清楚自己的算力开销，这会显著改善后续的采购谈判质量。
• 企业与研究机构：把采购流程制度化：需求画像表、商务条款清单、试用验收记录、周期复盘机制，四份文档构成完整的采购闭环。合规与数据条款作为硬性门槛前置，性能与价格在合格名单内比较。涉及信创的方案单独立项，把适配周期与人力成本纳入预算，并把结论沉淀为组织可复用的知识资产。

把整个流程再压缩一遍：先回答”要做什么、多大规模、多长时间、怎么增长”四个问题，再据此选择零售平台、大厂云或国产信创路径，然后用商务条款清单把风险写进合同，最后按试用、包月、预留三级阶梯放量。这个顺序的价值在于：每一步都在用真实数据缩小不确定性，而不是用折扣率换取一个未经验证的承诺。市场中所有价格与条款请以供应商官方渠道披露为准，本文引用的区间仅用于建立量级感。

先说结论：先算单价，再算区间，最后才算自部署

大模型推理的成本决策，卡住很多团队的地方不是算不出来，而是算错了对象。最常见的错误是拿”API 每百万 token 的价格”直接和”显卡每小时的价格”对比——这两个数字不在同一个维度上，前者是产出单位，后者是投入单位，中间差着吞吐、并发率、利用率和运维成本四层折算。把它们直接相减，得出的结论通常会把团队带偏。

正确的顺序是三步：第一步，搞清楚 API 计价口径，知道自己每个月的 token 消耗对应多少钱；第二步，算清自部署的真实成本结构，把卡时、并发率与运维一起折算成”每百万 token 的等效成本”；第三步，再拿两个数字做区间对比，并叠加数据敏感性、定制需求、波动容忍度这些非价格因素。2026 年的公开报价里，DeepSeek 一类模型的 API 价格量级在每百万 token 输入 0.27 美元、输出 1.1 美元附近，而 GPT-4 级别的模型报价在每百万 token 5 到 15 美元的量级，两者相差一个数量级。这个差距本身不足以决定你要不要自部署，但它决定了你该从哪个方向开始算账。

一句话版本：低量级、需求波动大、不想养运维的团队，API 几乎总是更划算；高量级、数据敏感、有定制需求且负载平稳的团队，自部署才可能算得过账，而且通常要先做完量化与批处理优化才能算平。

API 计价口径：输入和输出不是一个价

读 API 价目表的第一件事，是分清输入 token 和输出 token。几乎所有主流厂商都对这两者分别定价，而且输出价格明显更高——常见倍率是输入的数倍。原因在于计算特性不同：输入阶段可以并行处理，显卡利用率高；输出阶段是自回归逐 token 生成，每一步都依赖上一步，显卡利用率天然偏低。所以输出贵不是定价策略，而是成本结构的直接反映。

第二件事是分清缓存命中与未命中。很多厂商对重复出现的上下文（比如固定的系统提示词、长文档前缀）提供缓存折扣，命中缓存的那部分输入价格可以低一个量级。如果你们的应用有稳定的长前缀——例如固定的角色设定、知识库前言、代码规范——把前缀设计成可缓存的形式，能直接砍掉一大部分输入成本，这是投入产出比最高的一项优化。

第三件事是注意阶梯计价与批量折扣。部分厂商对夜间时段、批量推理任务提供折扣，或者按月消耗量分档降价。这些条款不写在首页最显眼的位置，但对你实际的账单影响很大，尤其是消耗量已经上到一定规模之后。

计费维度	口径说明	对成本的影响
输入 token	按每百万 token 计价，通常较低	长上下文、长提示词会快速放大
输出 token	按每百万 token 计价，通常是输入的数倍	长回复、链式思考会显著放大
缓存命中	重复前缀命中缓存时折扣计价	可缓存前缀是降本首选
批量/错峰	批量任务或非高峰时段折扣	适合离线处理类负载
量级档位	月消耗达到档位后单价下移	需要主动与商务确认

把这几条合起来看，你会得到一个反直觉的结论：API 的”标价”往往是你能拿到的最高价。缓存、批量、错峰、档位四层折扣叠加上去，实际单价可能比标价低不少。所以在做 API 与自部署对比时，请用”你的实际混合单价”，而不是价目表首页那个数字。

自部署的成本结构：卡时只是一半

自部署的成本由三部分构成，很多人只算第一部分。

第一部分是卡时成本。这是最直观的一项：租几张卡、每小时多少钱、跑多少小时。国内 A100 40G 时租约 2.4-2.9 元，H100/H800 约 9.6-12 元，24G 的 4090 约 1.2-2.5 元。如果按推理场景算，多数 7B 到 13B 模型的部署落在 24G 卡上，成本相对可控。

第二部分是并发率与利用率折算。这是最容易被忽略、也最能改变结论的一层。你租了一张卡，但它的实际吞吐取决于模型大小、量化精度、批处理策略和你的请求模式。同样一张卡，做单请求低并发服务时可能每秒只产出几十个 token，开启连续批处理后吞吐可以提升数倍。也就是说，”每百万 token 的等效成本”不是一个固定值，它随着你的优化程度上下浮动几倍。跳过这一层直接拿卡价除以 token 数，结论必然失真。

第三部分是运维与人力。自部署意味着你要有人管服务健康、处理 OOM、升级推理框架、做灰度发布、应对流量高峰、处理故障。这部分成本在小团队里经常以”某个工程师一半的时间”的形式存在，很容易被记成零，但它真实存在。如果这个服务是核心业务，还要额外考虑高可用与多副本带来的冗余成本——为了保证可用性，你往往要付出比理论峰值需求更多的算力。

成本项	计入方式	常见漏算
卡时	卡型单价 × 运行小时	低负载时段的空转成本
并发折算	实际吞吐决定等效每百万 token 成本	用理论峰值而非实测吞吐
运维人力	服务维护、升级、故障处理的工时	常被记为 0
高可用冗余	为可用性多部署的副本	按峰值需求而非冗余需求算
存储与网络	模型存储、日志、出网带宽	大模型权重存储与拉取开销

优化四件套：原理比数字重要

自部署能不能算得过账，很大程度上取决于你做到了哪一层优化。下面四项是推理优化的核心手段，理解原理比记住任何具体数字都重要，因为具体收益高度依赖你的模型与负载特征。

一、量化：用精度换显存与速度

量化把模型权重从 FP16 压到 INT8 或 4-bit，权重体积相应减少到大约二分之一或四分之一。收益是双重的：一方面显存占用下降，同样的卡能装下更大的模型或更大的批；另一方面显存带宽的压力减轻，而推理常常受限于带宽而非算力，所以吞吐往往同步提升。代价是精度损失，通常量化在通用任务上损失可控，但在需要精确数值推理或长链推理的任务上更容易被察觉。评估量化必须用自己的任务集跑对比，不能只看论文数字。

二、KV cache 管理：长上下文的隐形开关

自回归生成时，每个已生成的 token 都要缓存注意力键值对，上下文越长、并发越高，KV cache 越大，长上下文场景下它甚至超过权重成为显存第一大户。对应的优化有几种：把 KV cache 量化到更低精度，几乎不损失质量就把上下文容量翻倍；使用分页式的显存管理减少碎片、提高复用；对超出必要范围的上下文做截断或摘要，从根本上减少需要缓存的长度。对以长文档问答为主的应用，这一项的收益往往超过其他所有优化。

三、批处理：把显卡喂饱

单请求推理的显卡利用率往往很低，因为每生成一个 token 都要把权重读一遍，而算力大部分时间在等带宽。批处理把多个请求合并成一批一起算，权重的读取开销被多个请求分摊，吞吐可以成倍提升。更进一步的连续批处理（continuous batching）允许请求在生成过程中动态加入和退出批次，避免了整批等待最慢那条的问题，是当前高吞吐推理服务的事实标准。这项优化不改模型、不改精度，纯粹靠调度提升效率，是性价比最高的一招。

四、投机解码：用小模型加速大模型

投机解码的思路是让一个小而快的模型先草拟若干个 token，再由大模型一次性并行验证。如果草稿被接受，就等于用一次大模型前向传播产出了多个 token；被拒绝的部分则回退重算。它的收益取决于草稿模型的命中率，在文本连贯、可预测性强的场景下加速明显，在高度随机或专业化的输出上收益有限。实现复杂度高于前三项，适合已经做完量化和批处理、还想继续压延迟的场景。

API 还是自部署：分流决策表

判断维度	倾向 API	倾向自部署
调用量级	低到中等，月消耗有限	高量级且持续稳定
负载波动	波动大、有明显峰值	平稳可预测
数据敏感性	可接受数据出域	数据不可出域或合规要求严格
定制需求	通用能力足够	需要微调专属模型或私有知识注入
运维能力	没有专职人力的团队	有工程团队能承担服务维护
延迟要求	可接受公网往返与排队	需要极致延迟控制或本地部署
模型更新频率	希望自动跟上最新模型	模型版本需要自己锁定

这张表的使用方式是数数：如果大多数维度落在”倾向 API”一侧，就先踏实把 API 用好，把缓存和批量折扣吃满；只有当”高量级 + 平稳 + 数据敏感 + 有运维人力”这几条同时成立时，自部署的账才基本算得平。中间状态最常见的解法是混合架构：核心敏感链路自部署小模型，长尾与突发请求走 API，用同一个网关做路由。这样既保住了数据边界，也不用为峰值流量准备冗余算力。

常见问题

为什么输出 token 比输入 token 贵这么多？

因为两者的计算模式不同。输入阶段所有 token 可以并行处理，显卡能跑满；输出阶段是自回归逐 token 生成，每一步都依赖上一步的结果，显卡大部分时间在等显存带宽而不是算力，利用率天然偏低。成本结构差异直接反映在定价上，这不是厂商的定价策略问题。理解这一点，也能解释为什么”让模型少说废话”是真的能省钱的优化。

自部署一定比 API 便宜吗？

不一定，而且在小量级场景下通常更贵。自部署的固定成本——卡时、运维、冗余——不管你用不用都要付，只有把调用量堆到足够高，这些固定成本才能被摊薄到低于 API 单价。经验上，只有当负载持续稳定、量级足够大、并且你已经做完量化和批处理优化之后，自部署才可能算得过账。反过来，如果你的负载有明显波峰波谷，API 的按量付费反而是更优的财务结构。

缓存命中能省多少？

取决于你的提示词里有多少是重复的。如果应用有固定的长系统提示词、固定的知识库前言或固定的输出格式说明，这部分重复前缀命中缓存后，输入价格可以低一个量级。做这件事的方法很直接：把提示词中固定不变的部分放在最前面，把变化的部分放在后面，让缓存机制能够命中。这是改造成本最低、见效最快的一项优化。

量化会不会影响业务效果？

会有影响，但通常可控，关键是要验证。通用对话、检索问答、摘要类任务对量化的容忍度较高；精确数值计算、复杂代码生成、多步推理类任务更敏感。建议的做法是先在自己的真实任务集上对比量化前后的关键指标，如果差距在可接受范围内再上线，同时保留一个高精度版本的降级开关。

混合架构会不会很复杂？

复杂度主要在于路由与一致性。你需要一个统一网关把请求分发给自部署集群或 API，还要保证两条链路的输出风格、格式与错误处理保持一致。好处是灵活性极高：既保住了敏感数据不出域，又不用为峰值流量准备冗余算力，而且可以在 API 与自部署之间持续对比成本与效果，动态调整分流比例。对大多数有工程能力的团队，这是长期最优的结构。

避坑清单

• 拿卡价直接除以 token 数。缺少并发率与利用率折算是自部署成本误判的头号原因，实测吞吐才是分母。
• 忽略运维人力。服务健康、框架升级、故障处理都是真实成本，不记入就会高估自部署的收益。
• 用理论峰值吞吐做规划。生产环境的实际吞吐远低于压测峰值，按峰值规划会导致长期空转浪费。
• 不做缓存与批量优化就用 API。标价不是你的实际价，四层折扣不主动吃满等于白付钱。
• 为峰值流量自建全部容量。波峰波谷明显的负载应该用混合架构或弹性租用，而不是把冗余成本长期背在身上。
• 只比价格不比效果。推理成本的分母是有效产出，质量下降带来的返工与重试会悄悄推高真实成本。

按画像给建议

• 个人开发者与小团队：直接用 API，把精力放在提示词缓存设计和输出长度控制上。这两项优化不需要任何基础设施投入，见效却最直接。只有当某个模型的调用量稳定到成为固定大额支出时，才值得评估租卡自部署。
• 有工程能力的初创团队：按负载特征分流。把稳定的核心链路放到自部署集群（优先用 24G 卡的 7B 到 13B 模型，单卡成本可控），把长尾与突发请求交给 API，用统一网关管理。同步建设量化与批处理能力，这两项的收益最快兑现。
• 企业与受合规约束的团队：数据边界先行，能用自部署解决的场景尽量自部署，优先评估国产算力方案以满足信创要求。在做经济性评估时，把所有成本项——卡时、并发折算、运维、冗余、存储与网络——完整列出再对比，避免被”看起来更便宜”的单价误导。

回到方法论：推理成本这道题的分母永远是”有效产出”，而不是”服务器数量”或”卡时数”。无论你选择 API 还是自部署，把输入输出口径、缓存与批量折扣、量化与批处理优化这几件事做实，成本曲线自然就会向下走。所有价格请以厂商官方渠道披露的实时价目为准，本文引用的区间仅用于建立量级感；涉及 GPU 平台与云服务的选型，可参考 阿里云 等官方文档中关于实例规格与计费的说明。

先说结论：它是第二条路，不是替代品

讨论国产算力时，最容易走偏的两种态度是”完全对标、直接替换”和”生态不行、不值一提”。前一种低估了软件迁移的真实成本，后一种高估了短期差异、低估了长期供应链价值。更接近现实的定位是：昇腾 910B 提供了一条 CUDA 之外可用的第二条路，它在特定场景下已经能够承担生产任务，但把它当作即插即用的替代品会付出意想不到的时间代价。

从规格上看，910B 提供 64G 显存、1.6TB/s 显存带宽、FP16 算力约 280 TFLOPS 量级。这组参数最有意思的地方不是单项高低，而是它的组合逻辑：显存容量与带宽给得比较充分，算力则相对克制。这与国产 H20″保显存带宽、砍算力”的设计取向非常接近，说明两者瞄准的是同一类负载——推理、长上下文、显存容量敏感的场景，而不是追求极限算力的密集训练。理解了这一点，你就能明白 910B 的适用范围在哪里。

一句话版本：有信创合规要求、需要推理降本、或者希望为供应链风险做长期对冲的团队，值得认真评估 910B；而追求最短迁移路径、生态工具链高度依赖 CUDA 专有库的团队，短期内仍应留在原生态，把国产方案作为备份路线而非主线。

规格与对位：910B 站在哪个位置

做好国产算力的选型，第一步是建立规格对照。下表中的数值来自公开资料整理，用于说明量级关系，实际性能随框架版本、算子实现与模型结构波动，请以官方发布为准。

项目	昇腾 910B	H20（对位参考）	H100 / H800（参照）
显存容量	64G	大容量取向	80G
显存带宽	1.6TB/s	高带宽取向	显著更高
FP16 算力	约 280 TFLOPS	算力被明显削减	高端算力档
软件栈	CANN / MindIE	CUDA 生态	CUDA 生态
合规属性	国产信创可选	合规供给版本	H800 为合规版本
典型场景	信创合规、推理降本	推理与显存容量敏感场景	大规模训练与高端推理

这张表要读出的第一层信息是：910B 的对位对象是 H20 一类推理优化型产品，而不是 H100。它用 64G 显存和 1.6TB/s 带宽去承接长上下文推理、大模型部署这类显存敏感负载，用相对克制的算力去控制成本与功耗。第二层信息是，H800 作为合规版本把 NVLink 带宽从 900GB/s 调整到 600GB/s，说明”合规版本”并不是国产独有的话题，全球供应链都在做类似的产品分层；A800 的互联带宽约 400GB/s 也是同一逻辑的产物。理解了合规分层的普遍性，看待国产算力时就不容易陷入非此即彼的框架。

生态分层：CANN 与 MindIE 各自管什么

提到昇腾生态，最常见的困惑是搞不清 CANN、MindIE 这些名词各自负责哪一层。用一句话概括：CANN 是靠近硬件的底层软件栈，MindIE 是面向模型部署的上层推理工具链。分清楚层次，你就能判断自己的迁移工作量落在哪一段。

CANN 是昇腾的计算架构层，功能上类比 CUDA 加 cuDNN 的组合：它负责算子库、编译器、运行时和通信库，是上层框架能够驱动昇腾硬件的基础。深度学习框架（如 PyTorch）通过适配层把计算图交给 CANN 执行。绝大多数性能调优与算子适配的工作都在这一层发生，这也是迁移工作量的主要来源。

MindIE 是面向推理部署的工具链，提供模型转换、量化、服务化与调度能力，功能上类似于把推理引擎与模型服务框架打包在一起。对于标准的、结构主流的模型，MindIE 能提供相对顺畅的部署路径；模型结构越特殊、自定义算子越多，需要手工介入的地方就越多。

再往上一层是框架与社区适配。PyTorch 等主流框架已有昇腾后端适配，常规的模型代码改动量有限，但一旦涉及 CUDA 专有扩展、自定义算子、或者深度依赖特定生态库（如某些加速库、分布式训练库），改造成本会显著上升。这一层的现实是：常用路径已经铺好，长尾路径仍需自己修路。

层次	代表组件	类比	迁移工作集中度
硬件层	昇腾 910B 加速卡	GPU 硬件	无（采购决策）
计算架构层	CANN	CUDA + cuDNN	高，算子与性能调优主战场
部署工具链	MindIE	推理引擎 + 服务框架	中，标准模型较顺畅
框架适配层	PyTorch 等后端适配	框架后端	中到高，取决于自定义算子
应用层	业务代码与推理服务	应用代码	低，接口基本不变

迁移的现实成本：三到六个月的适配期

关于迁移成本，行业内被反复引用的一条经验判断是：从 CUDA 生态迁移到 CANN 生态，通常需要三到六个月的适配期。这个区间不是随口给的，它对应的是一套完整流程：先做可行性验证（模型能否跑通、精度是否对齐），再做性能调优（把算子效率、显存占用、通信效率调到可用水平），然后做稳定性验证与灰度上线。任何一步压缩得太狠，都会在后续以故障的形式补回来。

在这条路径上，公开披露的实践反馈值得参考。科大讯飞在业绩说明场合曾披露过国产算力使用中遇到的显存与带宽方面的挑战——这类来自真实业务方的反馈比任何宣传材料都更有信息量，因为它揭示的是”跑通”与”跑好”之间的距离。跑通一个模型不等于能撑住生产流量；生产环境考验的是长稳运行、异常恢复、版本升级这些工程细节。

还有一个容易被低估的因素是人才与知识。CUDA 生态积累了十几年的教程、问答、调优经验，遇到问题几乎总能搜到答案；CANN 生态的社区规模仍在成长中，遇到冷门问题时，能依赖的更多是官方文档与技术支持渠道。这会让同样的排障工作耗时更长，这部分成本很难量化，但真实存在。

谁在用：从万卡集群到信创项目

判断一条技术路线是否成熟，看谁在用、用多大规模，比看参数更有说服力。从公开信息看，昇腾的主要落地场景集中在三类。

第一类是运营商与大型央企的算力基础设施建设。这些场景的特点是资金充足、有明确的信创要求、负载以推理与通用计算为主，且对大模型训练的需求相对集中在少数团队。万卡级集群的建设口径在这类主体中反复出现，说明国产算力已经进入了大规模部署阶段，而不再是实验性采购。

第二类是互联网与科技公司的推理业务。推理场景对生态兼容性的要求低于训练——推理用的是已经训练好的模型，算子覆盖面相对集中，部署路径更标准化。这使得推理成为国产算力最容易切入的业务环节，也是”推理降本”这个诉求在国产方案上最容易被满足的原因。

第三类是高校、科研机构与政府项目的信创改造。这类场景往往有明确的政策约束，910B 在部分项目中是唯一可选项，选择空间有限，评估重点也因此从”是否比 CUDA 方案更好”转向”如何把迁移风险控制在可接受范围内”。

值得注意的是，这三类场景有一个共同特征：负载可预测、模型版本相对稳定、有专门团队负责适配。这恰好是国产算力能够扬长避短的条件，也提示了什么样的团队不适合把 910B 作为主力——模型迭代极快、依赖大量前沿开源库、没有专职适配人力的团队。

常见问题

910B 能替代 H100 吗？

在单卡性能上不能直接对标，产品定位也不同。910B 的 64G 显存与 1.6TB/s 带宽瞄准的是推理与显存容量敏感场景，对位的是 H20 这类推理优化型产品，而不是追求极限算力的大规模训练场景。如果你的任务是高密度训练，CUDA 生态的高端卡仍是更直接的选择；如果任务是长上下文推理、私有化部署或信创合规，910B 是值得评估的选项。

迁移到底要多久？

行业经验区间是三到六个月，差异主要来自三件事：模型是否主流、代码里有多少 CUDA 专有依赖、团队是否有人专门投入。标准结构的模型、少量自定义算子、有专职适配人力的项目，可能落在区间下沿；结构特殊、深度绑定专有库、兼职推进的项目，可能超出上沿。规划时建议按区间上沿做预算，把节省出来的时间当作收益而不是预期。

推理场景是不是迁移更容易？

相对训练更容易，因为推理的算子覆盖面更集中、不需要分布式训练的通信优化、也不涉及梯度相关的算子。但”更容易”不等于”没有成本”：模型转换、精度对齐、吞吐调优、长稳验证这些环节一样都不能少。把推理迁移当成一次完整的工程立项，而不是一次简单的环境切换，是最务实的预期管理。

现在就该上国产算力吗？

取决于你的约束条件。有信创硬要求、或者供应链安全是董事会级别议题的团队，现在就该启动小规模验证，把适配周期纳入规划；没有这类约束、且团队正处在快速迭代期的团队，可以保持关注但不急于切换。一个折中的做法是保留一条小规模验证链路，用最小成本维持对国产生态的技术认知，等需要时能够快速放量，而不是从零开始。

国产算力的性价比怎么评估？

不要只看单卡价格或单卡算力，要算”完成任务的总成本”，其中包括硬件成本、迁移适配的人力成本、性能调优的时间成本、以及后续维护成本。在合规要求下，前一项可能不是决策变量；但在自由选择场景里，只有把所有成本项完整列出，才能得出真实结论。很多项目在纸面上省了硬件钱，却在适配期付出了更多的人力。

避坑清单

• 把规格对标当作能力对标。参数接近不代表实际吞吐接近，真实表现取决于算子库成熟度与框架适配质量，必须实测。
• 低估适配期。三到六个月是行业经验区间，按上沿做预算、按下沿做宣传，才是稳妥的项目管理方式。
• 用一次性验证代替长稳测试。跑通一个 demo 与扛住生产流量之间隔着异常恢复、版本升级、性能波动三道坎。
• 忽略人才与知识成本。CANN 生态的社区积累仍在成长，冷门问题的排障时间成本要提前计入。
• 只算硬件账不算人力账。适配与调优的人力投入往往超过硬件差价，不做完整核算就会误判性价比。
• 把国产方案当成”备胎”却不做技术储备。如果确定要做长期对冲，即使暂不切换，也应保留小规模验证链路。

按画像给建议

• 个人开发者：短期不必切换，CUDA 生态的工具与教程密度仍是学习效率最高的选择。如果所在单位有信创项目，可以主动参与适配工作，CANN 相关的工程经验在当前市场上有明确价值。
• 初创团队：保持单主线、低复杂度。除非客户明确提出信创要求，否则不建议在产品早期同时维护两套算力栈带来的复杂度。可以预留抽象层，把推理服务的硬件依赖隔离出来，为将来切换留出接口。
• 企业与研究机构：如果存在合规约束或供应链对冲需求，建议现在启动小规模验证项目，目标定在”跑通一条真实业务链路并完成长稳测试”，而不是追求极限性能。评估时把硬件、迁移、调优、维护四类成本完整列出，并把结论沉淀成可复用的内部文档——国产算力选型的知识资产，本身就是长期价值的一部分。

把 910B 放在正确的位置上看：它不是 CUDA 的取代者，而是在合规、供应链与成本三重约束下的一条现实可行路径。规格上它用 64G 显存与 1.6TB/s 带宽承接显存敏感的推理负载，生态上它通过 CANN 与 MindIE 覆盖从算子到部署的主要环节，代价是三到六个月的适配期与尚在成长中的社区积累。是否现在投入，取决于你的约束条件而不取决于谁的性能参数更高——想清楚约束，答案通常就清晰了。本文规格与价格信息来自公开资料整理，请以华为官方渠道发布为准，可参考 华为官网 的技术文档。

先说结论：跌价不等于变便宜，而是要重新分配预算

2026 年最值得注意的算力市场信号，是 H100 类高端卡租赁价格的深度回落。公开市场报价显示，海外 H100 时租已回落到 2.0-3.5 美元的区间，相比 2024 年峰值约 8 美元的报价，跌幅接近 64%；国内同类卡的时租在 9.6-12 元人民币区间。这个变化容易被简单读成”算力变便宜了，可以多买一点”，但更准确的理解是：价格结构发生了变化，不同档位的走势并不同步，因此真正需要调整的是预算的分配方式，而不是总量。

为什么说”跌价不等于普遍变便宜”？因为这次回落高度集中在高端卡上。高端卡从极度稀缺回到相对充足，价格自然回归；而中端卡的价格一直处在供需相对平衡的区间，跌价空间有限；入门卡本身利润薄、供给稳定，只有轻微松动。三类卡走出三种曲线，意味着同样一笔预算，今年能买到的算力组合和去年完全不同——去年你可能买不起高端卡，只能全押中端；今年高端卡的门槛降低，部分原本必须用中端卡硬扛的任务，可以迁到高端卡上。

一句话版本：这轮跌价的核心含义是”高端不再稀缺”，它把选择权从供给方交回租户手中；但对预算制定者来说，正确的动作是重新评估任务与卡型的匹配关系，而不是简单地按比例增加采购量。

跌 64% 是怎么发生的：需求侧与供给侧

价格从约 8 美元跌到 2.0-3.5 美元，跌幅接近三分之二，这个幅度不是单一因素能解释的。供需两侧同时转向，才形成了这样的斜率。

需求侧的变化是主线，可以概括为”训练转推理”。2024 年前后的算力紧缺，核心驱动是大模型训练对高端卡的集中需求：训练任务对算力密度与卡间互联的要求最高，几乎只能用最高端的卡，而且训练集群一旦建成就是长期占用。这种需求结构下，高端卡既是必需品也是身份象征，价格自然坚挺。2026 年的情况不同：训练需求仍然存在，但增量正在向推理侧迁移。推理对单卡算力的要求相对宽松，对显存容量与带宽更敏感，可选择的卡型大大增多——A100、L20、H20、910B 都能承接一部分推理负载。需求从”必须最高端”变成”够用即可”，高端卡的价格支撑随之松动。

供给侧的放量同样关键。高端卡的产能经过几年爬坡后明显改善，云厂商与第三方算力平台的存量卡池扩大，前两年囤卡的库存也开始释放到租赁市场。当供给从”需要排队”变成”有现货”，租金的稀缺溢价就被挤掉了。这里有一个值得记住的规律：算力租赁价格里包含了”可获得性溢价”，当卡的获取难度下降时，即使算力本身没变，价格也会下移。所以观察租金走势时，供给端的现货情况与需求端的总量同样重要。

阶段	需求特征	供给特征	价格表现
紧缺期	训练为主，集中采购高端卡	产能有限，排队交付	高端卡报价高企，含稀缺溢价
转折期	推理需求起量，需求结构分散	产能爬坡，卡池扩大	高端卡价格开始松动
当前阶段	训练稳定、推理成为增量主力	现货充足，库存释放	高端回落到 2.0-3.5 美元区间

价格结构分化：三条不同的曲线

把价格按档位拆开看，2026 年的市场呈现出明显的分化格局。

高端档位（H100/H800 类）是跌幅最大的部分，从 8 美元量级回落到 2.0-3.5 美元，国内时租约 9.6-12 元。回落的驱动是供给放量与需求结构迁移的双重作用，这也意味着这一档位的价格已经包含了明显改善的可获得性——现在租 H100，等待时间远短于两年前。

中端档位（A100 类）价格相对稳定，国内 40G 版本时租约 2.4-2.9 元。中端卡没有高端卡那样的稀缺溢价，也没有入门卡那样的价格竞争，供需一直处在相对平衡的位置。它们的价值在于承接”显存需求上不去、但又需要企业级稳定性”的场景，价格弹性因此较小。

消费级与入门档位则是缓慢下移的曲线。RTX 4090 在 1.2-2.5 元区间，4090D 约 1.14 元起，3090 约 1 元起，P40 低至 0.3-0.4 元，入门卡（如 3080Ti 一类）约 0.88-0.98 元，新一代的 5090 报价在 2.68-3.28 元。这一档位的特点是卡池基数大、竞争充分、同质化程度高，价格主要由消费级显卡的二级市场行情和新品节奏决定，而不是由大模型训练需求决定。所以当高端卡大跌时，这一档位往往纹丝不动——它们的价格逻辑和高端卡根本不在同一套供需体系里。

档位	代表卡型	2026 报价区间	走势特征	主要驱动
高端	H100 / H800	国内 9.6-12 元/时；海外 $2.0-3.5	深度回落，较峰值约 -64%	供给放量 + 训练转推理
中端	A100 40G/80G	约 2.4-2.9 元/时	相对稳定	供需平衡，企业级刚需
消费级旗舰	RTX 4090 / 5090	4090 约 1.2-2.5 元；5090 约 2.68-3.28 元	缓降，新品支撑价格	显卡二级市场 + 新品节奏
入门	3090 / 4090D / 入门卡	约 1 元起 / 约 1.14 元起 / 0.88-0.98 元	轻微下移	卡池竞争充分

对三方的含义：租户、持有者与平台

价格变化对不同角色的含义完全不同，这也是同一份行情数据会被读出相反结论的原因。

对租户而言，这是议价窗口。高端卡的可获得性改善意味着两件事：一是原来因为排队而放弃的高端卡任务，现在可以重新纳入方案；二是包月与预留的价格弹性变大，续约时有了更多谈判空间。一个务实的动作是重新审视任务与卡型的匹配关系——过去为了显存必须租高端卡的任务，现在是否有更划算的中端替代？过去因为高端卡太贵而用中端卡硬扛的任务，现在是否值得迁到高端卡上去缩短周期？这个双向调整往往能挤出比单纯砍价更多的价值。

对自购持有者而言，这是一个需要正视账面变化的时期。如果自购的决策前提是”租不到、只能用买”，那么供给改善后这个前提已经不成立；如果前提是”长期高强度使用、自购更便宜”，那么价格回落的影响相对有限，但持有成本（折旧、电费、机房、运维）相对租金上升，会导致自购的盈亏平衡点向后移动。理性的做法是重新计算利用率门槛，而不是固守当初的结论。

对算力平台而言，高端卡从稀缺品变成标准品，意味着竞争焦点从”有没有卡”转向”服务好不好”。当价格无法拉开差距时，能决定用户去留的是开卡速度、镜像生态、存储性能、故障响应速度、计费透明度这些运营细节。这也解释了为什么 2026 年各家平台的动作更多集中在工具体验与社区建设上，而不是单纯的价格战——价格战的空间已经被供给放量压缩了。

值得持续跟踪的观察指标

价格走势不是一次性的新闻，而是一条需要持续跟踪的曲线。下面几项指标可以当作自己的监控清单。

• 高端卡现货指数与排队时长。比起报价，现货可得性与排队时长更能反映真实的供需松紧。排队时长缩短通常先于报价下移，是更早的信号。
• 新款卡的发布与放量节奏。新一代产品发布会在两到三个季度后冲击上一代卡型的租金，这个滞后关系在消费级与专业级卡上都成立。
• 推理在总算力需求中的占比。推理占比上升意味着需求结构继续向”够用即可”迁移，这会让高端卡的稀缺溢价进一步被压缩。
• 中端卡的价格弹性。中端卡是市场的稳定器，如果连它也开始明显松动，说明供给过剩已经蔓延到整个谱系。
• 合规成本与政策变量。合规版本卡型（如 H800、A800 这类调整过互联带宽的版本）的供给节奏，会独立于全球供需影响国内实际可租到的卡型与价格。
• 二手与库存释放节奏。前几年囤积的卡进入租赁市场的速度，是短期价格的重要扰动项，尤其在高端档位。

常见问题

价格跌了，现在是不是该多囤一些算力？

不建议按”囤”的思路操作。租赁市场的价格是随时间连续变化的，长期锁定的前提是你能确定自己会持续满载使用；如果实际利用率低于预期，锁定带来的不是省钱而是固定支出。更稳妥的做法是按任务周期签订长度匹配的合约：稳定基线用包月锁定，波动部分保持按需弹性。真正值得现在做的事，是重新评估任务与卡型的匹配关系，把过去因价格或排队而妥协的配置调整到位。

为什么国内价格和海外差这么多？

两个市场并非完全连通，存在合规、供应链与政策层面的区隔。同一型号的卡，在两地的可获得性、合规版本配置与流通渠道都不同，因此形成了价格分层。国内时租 9.6-12 元与海外 2.0-3.5 美元的差距中，包含了合规成本、渠道成本与市场结构的差异，不能简单理解为某一个市场定价不合理。做预算时应以你自己能实际租到的渠道价格为准。

高端卡还会继续跌吗？

没有人能准确预测，但可以观察驱动因素是否延续。如果供给继续放量、推理需求占比继续上升、新品继续按节奏迭代，那么高端卡的价格压力会持续存在；反之，如果出现新的训练范式突破或供给端意外收缩，价格也可能重新走强。与其预测方向，不如建立监控清单并设定触发条件——例如排队时长或报价变化超过某个幅度时，重新评估采购方案。

中端卡会不会被高端卡拖下水？

短期看可能性不大。中端卡和高端卡服务的是不同的需求：高端卡解决”算力与互联密度”的问题，中端卡解决”显存够用、成本可控”的问题。当高端卡降价时，部分原本用中端卡的负载可能上移，这反而会消耗中端卡的供给、支撑其价格。真正会让中端卡松动的是整体需求萎缩或供给大幅增加，而不是高端卡的降价本身。

自购显卡的账还成立吗？

成立的条件下需要重新核算。价格回落改变了自购与租用的相对关系：租金下移意味着自购的回本周期变长，盈亏平衡所需的最低利用率被抬高。行业里常被引用的经验门槛是利用率超过 70% 才值得认真评估自购，在这轮价格变化后，这个门槛的方向只会更高而不会更低。建议把当前的实际利用率、租金行情与持有成本代入重算，而不是沿用旧结论。

避坑清单

• 把跌幅当成普跌。这轮回落集中在高端档位，中端基本持平、入门轻微下移，按统一比例调整预算会算错。
• 只看报价不看可获得性。报价下降但排队依旧的场景并不罕见，真实成本要算上等待时间。
• 用历史价格锚定当前决策。以 2024 年的价格为参照系会高估当前价格，以最低点为目标又会错过实际窗口。
• 忽略合规与渠道差异。同样是 H100 类产品，不同合规版本与渠道的实际可租价格与性能表现差别明显。
• 长期锁定却没有稳定负载。锁定合约的前提是高利用率，否则省下的单价会被闲置成本吃掉。
• 忘记重算自购门槛。租金下移会抬高自购的盈亏平衡利用率，沿用旧结论容易做出错误决策。

按画像给建议

• 个人开发者：这轮跌价对你的直接影响有限，因为你大概率用的还是消费级卡。值得关注的是中端卡与高端卡的替代关系：如果你的任务在 24G 卡上已经吃紧，现在 A100 档位的性价比窗口比一年前更值得认真考虑。
• 初创团队：把这次价格变化当作一次重新设计算力结构的机会。用中端卡承接稳定负载、用高端卡缩短关键任务周期、用按需实例吸收波动，三层结构比单一卡型更能对冲价格波动。同时把报价监控做成常规动作，而不是等年度预算时再看。
• 企业与研究机构：关注的重点应从单价转向总拥有成本与供给侧风险。价格回落期间适合重新谈续约条款、争取更长的价格保护期；同时评估合规版本卡型的供给计划，把政策变量纳入中长期规划。对于自建集群的团队，重新计算盈亏平衡利用率，并考虑”基线自建 + 突发租用”的混合结构以降低闲置风险。

把这篇分析压缩成一句话：这轮跌价的本质是高端算力从稀缺走向充足，它改变的不是算力的绝对成本，而是不同档位之间的相对关系。对使用者来说，最有价值的动作不是等更低的价格，而是趁选择权回到自己手上的时候，把任务与卡型的匹配关系重新梳理一遍。市场价格随时在变，本文引用的区间来自公开渠道整理，请以各平台实时报价为准，可参考 阿里云 等官方渠道公布的实例计费说明。

先说结论：显存是选卡的第一硬指标

在选 GPU 这件事上，算力（TFLOPS）决定”跑得多快”，显存（VRAM）决定”跑不跑得起来”。两者优先级完全不同：算力不够，你把批次调小、训练时间拉长，任务最终还能完成；显存不够，模型在加载权重的那一刻就直接报 out of memory。所以在预算允许的范围内，选卡的正确顺序是”先看显存够不够，再看算力划不划算，最后看价格和平台”。

2026 年国内市场上，24G 的 RTX 4090 时租约 1.2-2.5 元，40G 的 A100 约 2.4-2.9 元，80G 的 H100/H800 国内约 9.6-12 元，国产昇腾 910B 提供 64G 显存。价格随容量阶跃式上升，但并非所有任务都要爬到阶梯顶端。这篇文章要解决的，就是帮你判断自己的模型落在哪一个档位，以及显存不够时除了加钱换卡还有哪些补救手段。

一句话版本：7B 级模型做推理，24G 通常够用；13B 到 30B 级模型微调，40G 或 48G 是舒适区；70B 级模型不量化就很难在单卡上跑，80G 只是起点而不是终点。

显存到底被什么占用

很多人以为显存只用来放模型权重，这是最常见的误解。实际上一张卡上的显存被至少四部分同时占用，任何一部分失控都会导致 OOM。

第一部分是模型权重。参数量乘以每个参数的字节数就是权重体积：FP16 精度下每个参数占 2 字节，所以 7B 模型约 14GB，13B 约 26GB，70B 约 140GB。这是最容易被估算的一部分，也是唯一可以靠量化显著压缩的一部分。

第二部分是激活值与梯度。训练时前向传播的中间结果必须保留到反向传播使用，批大小（batch size）和序列长度（sequence length）直接决定这部分的开销。同样一个模型，批大小从 1 调到 8，激活值可能翻好几倍。这也是为什么”这个模型我用 24G 能推理但训练就爆显存”——推理只需要权重加 KV cache，训练还要额外装下梯度和优化器状态。

第三部分是优化器状态。以 Adam 系列优化器为例，它要为每个参数额外保存一阶和二阶动量，全量微调下这部分开销往往是权重本身的数倍。这就是 LoRA 这类参数高效微调方法存在的根本原因：它只训练极少量新增参数，把优化器状态的开销压到几乎可以忽略，从而让 24G 卡也能微调 7B 级模型。

第四部分是推理场景下的 KV cache。自回归生成时每个已生成的 token 都要缓存注意力键值对，上下文越长、并发越高，这部分占用越大，长上下文场景下甚至可能超过权重本身。明白这四部分，你就知道显存需求不是”模型有多大”一个变量，而是”模型规模 × 精度 × 批次 × 上下文长度”的乘积。

占用来源	大致与什么成正比	训练时	推理时	主要压缩手段
模型权重	参数量 × 每参数字节	必须	必须	INT8 / 4-bit 量化
激活值	批大小 × 序列长度 × 层宽	必须	很小	梯度检查点、减小批次
优化器状态	参数量 × 倍数	全量微调必须	不需要	LoRA / 冻结底座
KV cache	层数 × 头数 × 上下文 × 并发	需要	对话类负载显著	量化 KV、限制上下文

量级表：不同规模模型要多少显存

下面这张表给出的是”量级区间”，用来说明档位关系，不是精确值。实际占用会随框架实现、精度、批次与序列长度浮动，参考时请按自己的配置留出余量。

模型规模	FP16 权重	4-bit 量化权重	推理起步显存	全量微调显存	LoRA 微调显存
7B 级	约 14GB	约 4-5GB	16-24G 档	需要 80G 档或多卡	24G 档可尝试
13B 级	约 26GB	约 7-9GB	24-40G 档	需要 80G 档起步	40G 档较舒适
30B 级	约 60GB	约 16-20GB	40-80G 档	需要多卡	40-80G 档
70B 级	约 140GB	约 35-40GB	需量化后 80G 档	需要多卡集群	80G 档起步

读这张表的正确方式是看”档位跳变”而不是记具体数字。7B 级模型是 24G 卡的上限区间，量化之后 24G 可以宽松地跑推理；13B 级模型量化后能在 24G 上跑，但会比较紧，40G 会明显从容；30B 级以上开始进入 40G 到 80G 的讨论范围；70B 级模型即使 4-bit 量化后权重也需要 35-40GB，单张 80G 能装下权重，但留给 KV cache 和激活值的空间并不宽裕，这直接决定了它的并发能力和上下文长度都受限。这就是”80G 只是起点”的含义。

分水岭一：24G 能干什么、不能干什么

24G 是当前国内供给最充足、价格最亲民的显存档位，RTX 4090、4090D、3090 都是 24G。它的能力边界相当清晰。

能做的：7B 到 13B 级模型的推理服务；7B 级模型的 LoRA 微调；AIGC 出图（Stable Diffusion 系列）与视频生成的轻量场景；中小规模的传统视觉模型训练；嵌入模型、重排序模型的批量推理。

勉强的：13B 级模型的 LoRA 微调，需要把批大小压到很小并开启梯度检查点，训练速度会明显变慢；长上下文推理（比如 32K 以上），KV cache 会迅速吃掉剩余显存，需要限制并发或使用 KV 量化。

做不了的：任何 30B 级以上模型的全量微调；70B 级模型的常规推理（除非激进量化并接受质量损失）；大批次高分辨率扩散模型训练。

值得强调的是，24G 卡的性价比优势非常大：小时价只有高端卡的十分之一到五分之一，而大多数个人开发者和中小团队的实际任务——跑通流程、微调小模型、批量推理——都落在它的能力范围内。把任务硬塞进 24G 并优化批次，往往比直接租 80G 更省钱。

分水岭二：40G 与 48G 的中间地带

40G 档位主要由 A100 40G 与部分专业卡构成，48G 档位则是部分新卡的配置。这个档位的价值在于它刚好覆盖了 24G 到 80G 之间的空白：13B 级模型的全量微调、30B 级模型的量化推理与 LoRA 微调、以及需要较大批次的视觉任务，都在这个区间里找到合适的位置。

从价格上看，A100 40G 的时租约 2.4-2.9 元，相比 4090 的 1.2-2.5 元贵不了太多，但显存多出近一倍，还带来更好的企业级稳定性与互联能力。对于”24G 不够、80G 太贵”的任务，40G 档位经常是最优解。

需要区分同一型号内的容量差异：A100 有 40G 和 80G 两个版本，除了容量，显存带宽也不同，80G 版本带宽更高，对带宽敏感的大模型推理与训练影响明显。所以预算允许时，同一型号优先选大显存版本，带宽通常同步提升。

分水岭三：什么时候必须上 80G 及以上

80G 档位是 H100、H800 的主场，国内时租约 9.6-12 元。触发这个档位的场景有三类。

第一类是模型规模硬性超出。70B 级模型即使 4-bit 量化后仍需要 35-40GB 权重空间，加上 KV cache 和框架开销，40G 卡会非常紧张甚至不可用，80G 是能稳定运行的最低门槛。如果要做 70B 的全量微调，单卡无论多大都不够，必须进入多卡并行的领域。

第二类是对显存带宽敏感的场景。大模型推理的瓶颈经常不在算力而在带宽——每生成一个 token 都要把权重从显存读一遍，带宽直接决定吞吐。H100 的显存带宽远高于消费级卡，这就是它在推理场景下比同算力消费卡更快的原因。”保显存带宽”这个思路在国产 H20 的设计上体现得更极端：保留了高显存带宽，但大幅削减了算力，专为推理与显存容量敏感场景设计。

第三类是多卡训练。当模型要切分到多张卡上时，卡间互联（NVLink）的带宽成为关键。多卡训练不是简单地把卡堆在一起，互联带宽不足会让通信时间吃掉算力收益。这也是 H100 与 H800 的核心差异所在：H800 作为合规版本把 NVLink 带宽从 900GB/s 调整到 600GB/s，单卡算力相近，但大规模多卡训练的扩展效率会受影响。

显存不够时的补救清单

在掏钱升级显卡之前，先按下面的顺序排查，很多 OOM 并不需要换卡就能解决。

• 降低批大小并开启梯度累积。把批大小从 8 降到 2，显存占用大幅下降，再用梯度累积把等效批大小补回来。代价是训练变慢，但结果基本等价。
• 开启梯度检查点。用重算换显存，前向传播的中间结果不再全部保留，显存占用可显著降低，代价是训练速度下降一到三成。
• 改用 LoRA 或其他参数高效微调。如果任务是微调而非从头训练，LoRA 能让 24G 卡完成原本需要 80G 卡的工作，这是性价比最高的一招。
• 量化权重。INT8 大约把权重减半，4-bit 大约减到四分之一，推理场景下这是最直接的手段。代价是精度损失，需要用自己的评测集验证。
• 量化 KV cache。长上下文场景下 KV cache 是隐形杀手，把它量化能在几乎不影响质量的前提下把上下文长度翻倍。
• 使用 CPU 卸载或分层加载。把暂时不用的层放在内存里，需要时再换入，能跑起来但速度损失明显，适合验证与调试而非生产。

按场景选卡对照表

你的任务	建议显存	可选卡型	备注
7B-13B 模型推理服务	24G	4090 / 4090D / 3090	量化后并发能力更强，成本最低
7B 模型 LoRA 微调	24G	4090 / 3090	配合梯度检查点，性价比最优
AIGC 出图与短视频生成	24G	4090 / 5090	5090 显存与带宽更高，单价 2.68-3.28 元
13B 模型全量微调	40-48G	A100 40G	时租约 2.4-2.9 元，性价比档位
30B 模型推理与 LoRA	40-80G	A100 80G / 昇腾 910B 64G	910B 提供 64G 显存，适合信创场景
70B 模型推理	80G	H100 / H800 / H20	需量化，注意上下文与并发预算
70B 级多卡训练	多卡 80G	H100 / H800 集群	关注 NVLink 带宽与扩展效率

常见问题

显存和算力，预算有限时先保哪个？

先保显存。算力不足只影响速度，显存不足直接导致任务无法运行。在同一个价格区间里，如果一张卡算力高但显存小，另一张算力略低但显存大一档，优先选显存大的那张——尤其是涉及模型规模、批次或长上下文的任务。只有在任务显存需求已经明确满足后，才轮到用算力去换时间。

为什么我的模型在 24G 上能推理，一训练就爆显存？

因为训练要比推理多存三样东西：激活值、梯度和优化器状态。推理只需要权重加 KV cache，训练还要为反向传播保留中间结果，Adam 类优化器还会为每个参数额外保存动量。三者叠加，训练显存需求经常是推理的数倍。解决办法是改用 LoRA 只训练少量新增参数，或者开启梯度检查点、减小批大小。

量化的精度损失能接受吗？

大多数场景下可以，前提是你用自己的评测集验证过。经验上 4-bit 量化在通用对话与检索类任务上的质量损失通常可控，但在需要精确数值推理、代码生成或长链推理的任务上，损失会更容易被察觉。建议的做法是：先在量化模型上跑一遍你的真实任务集，对比几个关键指标，再决定是否上线。

多卡能解决显存不够的问题吗？

能，但代价比想象中大。多卡方案需要模型并行或张量并行，卡间通信开销会拉低扩展效率，而且对互联带宽有要求。在小规模场景下，租一张大显存卡通常比租多张小显存卡更省心也更省钱；只有当单卡显存上限（目前 80G 级）确实装不下模型时，多卡才是必选项。

昇腾 910B 的 64G 显存在哪个档位？

介于 40G 与 80G 之间，接近 80G 档位的能力下限。910B 提供 64G 显存与 1.6TB/s 带宽，FP16 算力约 280 TFLOPS，对位的是 H20 一类的推理优化型卡。它适合有信创合规要求、或希望为供应链风险做对冲的团队；代价是需要经历 CUDA 到 CANN 生态的迁移适配期。

避坑清单

• 只看参数量估显存。权重只是四部分之一，遗漏激活值、优化器状态与 KV cache 是 OOM 的头号原因。
• 忽略批次与上下文的影响。同一个模型批大小和序列长度一变，显存需求可能差出几倍，评估必须按真实配置来。
• 把 24G 当成万能卡。它性价比很高但有明确边界，30B 以上的全量微调不要指望它。
• 跳过 40G 直接上 80G。很多任务在 40G 档位就能舒适运行，跳过中间档等于白付溢价。
• 不做量化验证就上线。量化确实省显存，但精度损失要在自己的任务上验证，不能只看论文数字。

按画像给建议

• 个人开发者：从 24G 起步，用 4090 或 4090D 把 7B 到 13B 的推理和 LoRA 微调跑通。只有当明确撞上显存墙时，才考虑升到 40G 档。像 AutoDL 这类零售向平台提供了丰富的 24G 卡型，适合按小时试错。
• 中小团队：把 24G 作为开发与推理的主力，40G 档作为微调与中等模型的补充，80G 留给真正的刚需场景。建议按任务类型给不同卡型设定默认值，避免所有人都默认申请最贵的卡。
• 企业与研究机构：先按模型的显存需求曲线做容量规划，再叠加合规与稳定性要求。涉及 70B 级模型或多卡训练时，把互联带宽与扩展效率纳入评估；有信创要求时，可同步评估 64G 显存的国产方案。

回到最初那句话：显存决定跑不跑得起来，算力决定跑得多快。把这句话当作选卡的第一原则，配合上面的档位表与补救清单，你就能用最小的成本把任务放进合适的卡里，而不是在 OOM 与账单之间反复摇摆。所有价格与规格请以平台官网实时披露为准，本指南提供的区间仅用于建立量级感。

结论先行：557.6 万美元是什么口径的钱

DeepSeek-V3 常被引用的训练成本是约 557.6 万美元，这个数字的来源很具体：训练消耗约 278.8 万 GPU 小时，按每小时 2 美元的口径折算得出。作为对比，Llama 3 405B 的训练消耗约 3080 万 GPU 小时，量级差了一个数量级。把这两个数字放在一起，能得出本文最重要的一个结论：衡量训练成本的标准单位不是”多少钱”，而是”多少 GPU 小时 × 单价”。

但这并不意味着训练一个大模型只要 557.6 万美元。这个数字对应的是”最后一次成功的正式训练”的算力账，不含数据构建、人力投入、失败实验的试错成本，也不含上线之后的推理支出。这篇文章要做的，就是把这个数字拆开，看清它包含什么、不包含什么，然后给中小团队一个可用的成本量级感，以及四条务实的降本路径。

GPU 小时计价法：唯一可比的成本口径

为什么用 GPU 小时而不是美元？因为美元金额受卡型、单价、租用方式影响，跨团队不可比；而 GPU 小时是任务本身的物理消耗，换一个单价就能换算成钱。它的计算方式很直接：

训练总成本 ≈ GPU 卡数 × 训练天数 × 24 小时 × 单卡小时单价。以 DeepSeek-V3 为例，278.8 万 GPU 小时 × 2 美元/小时 ≈ 557.6 万美元。这里的 2 美元口径对应的正是 H800 一类高端卡的海外带价水平——注意，同一份算力放在国内按 9.6-12 元/小时（约 1.3-1.7 美元）的时租口径下，金额会不同，这正是”先算 GPU 小时、再套单价”的意义。

这套算法还能解释为什么 Llama 3 405B 的 3080 万 GPU 小时会被反复提及：它代表了”用传统稠密模型路线训练一个更大参数模型”所需的算力量级。把 278.8 万与 3080 万放在一起，差距主要来自模型架构与训练效率的路线选择，而不只是硬件规模。

对比项	DeepSeek-V3 口径	Llama 3 405B 口径
训练算力消耗	约 278.8 万 GPU 小时	约 3080 万 GPU 小时
折算成本（按 2 美元/时）	约 557.6 万美元	按同一单价折算约 6160 万美元量级
成本口径	最后一次成功训练的算力账	同类口径的算力账

557.6 万美元不含什么

这是最容易被误读的一点。训练一个模型的真实投入，远不止那次成功训练烧掉的卡时。把完整成本拆成四块，结构会清楚得多。

一、数据成本

数据的采集、清洗、去重、配比与质量筛选，是长周期的人力与工程投入。高质量语料的获取本身可能涉及采购，而清洗流水线的开发与迭代需要持续投入工程师时间。这部分成本通常不体现在 GPU 小时里，但往往是决定模型效果上限的关键。

这笔成本还有一个特点：它随着模型规模的增长而放大。模型越大，对数据量与数据质量的要求越高，清洗与筛选的规则也越复杂。很多团队在算力上做了充足预算，却在数据环节投入不足，最终得到的结果是”卡时烧掉了，效果没出来”——从成本角度看，这比算力超支更浪费。

二、人力成本

一个完整的大模型训练团队包含算法、工程、数据、算力调度与评测多个角色，人员规模与周期决定了这部分支出的量级。以数月到一年以上的训练周期计算，人力成本在总投入中的占比经常不低于算力成本。

三、试错成本

“最后一次成功训练”这个表述本身就说明问题：在此之前会有多次失败的、被中途放弃的、超参不理想的实验运行。这些实验同样消耗卡时，也需要同样的集群规模，只是不体现在最终公布的那一个数字里。把试错倍数算进去，实际算力支出通常是公布数字的数倍量级。

试错成本对中小团队的意义尤其现实：如果一次实验要烧掉数天的多卡集群时间，团队就会本能地减少实验次数，而实验次数恰恰是模型效果的关键变量之一。这也是为什么”用便宜的中端卡多做几轮实验”经常比”用昂贵的高端卡做一轮完美实验”更有效——前者的总成本可能更低，得到的结论却更多。

四、推理与迭代成本

模型训练完成只是起点。上线后的推理服务是持续性支出，规模取决于用户量、上下文长度与并发；后续的版本迭代（继续预训练、微调、对齐）又是一轮算力投入。把训练成本当成一次性投入来做预算，是最常见的错误。

中小团队的量级感

对绝大多数团队来说，从零训练一个千亿级模型并不现实，真正需要算的是微调与中等规模训练的量级。这里给出的是基于公开经验的量级估算，具体数值会随模型规模、序列长度、批次与并行效率大幅波动，请当作判断量级的参考而非精确预算。

任务类型	典型卡型	算力量级（参考）	成本量级（按公开时租区间）
7B 模型 LoRA 微调	单张 4090（24G）	数小时到数十小时	数十元级
7B 模型全参微调	多张 A100 / 4090	数十到数百 GPU 小时	数百到数千元级
13B 模型 LoRA 微调	A100 40G 或 5090 级	数十 GPU 小时	数百元级
13B 模型全参微调	多张 A100 80G	数百到上千 GPU 小时	数千到万元级
70B 级继续预训练	H100/H800 多机集群	万级 GPU 小时以上	十万元级以上

在动手算之前，先把”需要多少 GPU 小时”这个问题拆成三个输入：模型规模（决定单步计算量与显存占用）、数据规模（决定训练步数）、以及硬件效率（决定实际吞吐与理论峰值的差距）。三者相乘才能得到量级。其中最容易出偏差的是第三项——理论峰值与实际吞吐之间通常存在明显差距，受制于显存带宽、通信开销、算子效率与集群调度。把效率系数设得乐观，预算就会被严重低估；务实的做法是按公开实践中较为克制的效率水平来估，再留出余量。

读这张表要注意两点。第一，卡型选择由显存决定：7B 级 LoRA 单张 24G 卡就能做，13B 级全参微调就必须用 40G 以上的卡。第二，成本随 GPU 小时线性放大，规模每上一个台阶，支出是数量级变化，而不是百分比变化。这也是为什么对中小团队来说，”要不要自己训练”这个问题，答案通常是”先用微调和开源模型验证需求”。

训练之后：推理才是长期账单

把训练成本算清楚之后，还有一个更容易被低估的部分：推理支出是持续性支出，而训练通常是一次性或阶段性的。一次 557.6 万美元量级的训练可能对应数年服务期，但如果推理的量级大，累计支出超过训练成本并不罕见。

推理成本的结构与训练不同：它由单次请求的计算量（受模型规模、上下文长度影响）、并发水平（决定卡是否被有效利用）、以及单位卡时价格三部分决定。因此推理降本的方向也与训练不同——训练关注吞吐与扩展效率，推理更关注”每单位请求的成本”，手段包括量化、缓存复用、批处理与更高效的解码策略。同一个模型，经过推理侧优化之后，单位成本可能下降数倍，这部分收益往往比砍训练卡时更容易拿到。

对做预算的团队来说，这意味着在立项阶段就应该把推理成本单独列一行，并估算预期的请求量级。只算训练账、把推理当成”上线后再说”，会让整个项目的投入产出判断失真。

降本四招

1. 混合精度：FP8 与 BF16 的取舍

降低数值精度是训练加速最直接的手段之一。以 FP8 混合精度为例，它通过降低激活与部分运算的数值位宽来减少显存占用与计算量，从而在同等硬件上获得更高的吞吐。代价是需要处理数值稳定性问题，对算子与框架支持有要求。实际收益取决于模型结构与实现质量，方向明确但幅度因项目而异——建议在小规模上先验证收敛性，再推到全量训练。

2. 架构选择：MoE 的稀疏性红利

DeepSeek-V3 与 Llama 3 405B 的 GPU 小时差异，很大程度上来自架构路线。混合专家（MoE）结构通过每次激活部分参数，让总参数量与激活计算量解耦，从而在推理与训练中摊薄单位效果的计算成本。代价是训练稳定性与通信复杂度更高，工程门槛也更高。对中小团队而言，更现实的用法是直接采用已经开源、以 MoE 为卖点的模型做后训练，而不是自己从头实现。

3. 租用弹性：把固定成本换成可变成本

自建集群意味着为峰值需求买单，而训练任务往往有明显的阶段性：数据准备期算力闲置、集中训练期算力紧张。用弹性租用替代自购，可以把固定成本转化为随任务伸缩的可变成本。这里的关键经验是月均使用 150 小时以上的稳定负载才考虑包月，否则按需更划算；高端卡高峰期要排队，把可中断的训练安排在凌晨与周末能显著降低成本与等待。

4. 开源模型：站在已有的 GPU 小时上

最彻底的降本方式是少烧卡时——直接使用开源基座模型做微调或后训练，而不是从零预训练。以公开数据看，一个 70B 级继续预训练就要万级 GPU 小时以上，而 7B-13B 的微调只需数十到上千 GPU 小时，两者相差两到三个数量级。对绝大多数业务场景来说，微调开源模型已经能覆盖绝大部分需求。

四招之间不是孤立的，组合使用效果更明显：用开源模型做基座（省掉预训练）、用混合精度与高效微调方法压缩算力需求（省掉单次训练成本）、用弹性租用匹配波动的算力需求（省掉闲置成本）。三条路径合起来，中小团队完全可以用可承受的预算完成一个可用的领域模型——这与”训练一个大模型要几百万美元”的印象并不矛盾，因为后者的口径本身就是从零预训练一个超大模型。

常见问题

557.6 万美元能训练出一个 GPT-4 级模型吗？

不能这样理解。557.6 万美元是特定模型在特定口径下最后一次成功训练的算力账，对应的技术路线、数据积累与工程能力是前提条件。把它当作”训练同类模型的普遍预算”，忽略了数据、人力与试错投入，会严重低估实际门槛。

为什么用 GPU 小时而不是直接用美元？

因为 GPU 小时是任务的物理消耗，与卡价无关；美元金额会随卡型与租用方式变化。用 GPU 小时做单位，可以跨团队、跨时期比较训练效率；需要换算金额时，再乘以你实际能拿到的单卡小时单价即可。

中小团队最主要的成本误区是什么？

三个：把训练当一次性投入（忽略推理与迭代）；用峰值需求配置固定资源（忽略租用的弹性）；高估自己从零训练的必要性（忽略了微调开源模型的可行性）。避免这三点，预算通常会合理得多。

自建集群和租用，哪个训练更划算？

取决于利用率。行业经验是利用率超过 70% 才值得评估自购，因为低于这个水平时，闲置的设备折旧、电费与运维成本会超过租用溢价。训练任务波动大，通常更适合”基线自购 + 峰值租用”的混合策略。

MoE 一定比稠密模型省吗？

在”单位效果的计算成本”这个维度上，MoE 的稀疏性通常带来优势；但它引入了训练稳定性、通信开销与工程复杂度，不是无条件的优化。是否采用，取决于团队是否有相应的工程能力与调优经验。

总结

从 557.6 万美元说起，最重要的收获不是一个价格标签，而是一套算法：训练成本 = GPU 小时 × 单价，而这个 GPU 小时只覆盖最后一次成功训练。完整的投入还要摊上数据、人力、试错与推理。对中小团队来说，务实的路径是先算清自己任务的 GPU 小时量级，再决定用哪一档卡、按需还是包月，最后优先考虑微调开源模型而不是从零训练。把这三个决定做对，成本控制的大头就已经完成了。文中所有成本与规模均为公开信息的量级整理，实际以各平台与厂商官方渠道的价格与规格为准。

结论先行：不要比价格，比利用率

算力租用还是显卡自购，这个问题用价格永远算不清，因为两者的成本结构完全不同：租用是可变成本，用多少付多少；自购是固定成本，先付一笔钱，然后慢慢摊。把这两种成本放在一起比较，唯一的公平方式是把它们换算成”每小时的实际成本”，而这又完全取决于一个变量——利用率。

行业里比较通行的经验是：利用率超过 70%，才值得认真评估自购；低于这个水平，闲置带来的折旧、电费与运维成本会迅速吃掉自购的价格优势。所以本文不打算先给结论，而是先把四笔账摆开：设备折旧、电费与机房、运维人力、机会成本。算完之后，再用 H100 的公开价格做一个盈亏平衡的估算，最后给出混合策略与决策表。

第一笔账：设备折旧

自购的第一笔支出是硬件本身。以高端训练卡为例，单卡购置价格在 2.5-3 万美元的量级，整机还要加上 CPU、内存、主板、电源、机箱与高速互联部件，实际整机价格往往是单卡价格的若干倍。这笔钱一旦付出，就进入折旧周期。

折旧的关键认知是：算力硬件的价值衰减速度较快。新一代产品发布后，旧卡的租赁市场价会明显下移（H100 租赁价较 2024 年峰值跌约 64% 就是例子），因此自购设备的会计折旧年限与经济折旧年限经常不一致。如果按三年直线折旧来分摊，一台 3 万美元量级的设备每天的成本就接近 30 美元——注意，这是”每天”，无论你用不用。

第二笔账：电费与机房

这是最容易被低估的一笔。高端卡的功耗本身可观，而整机功耗还要加上 CPU、电源转换损耗与散热。真正的成本大头在散热：把卡产生的热量排出去，需要机房级的空调或液冷系统，其耗电经常与计算设备本身处于同一量级。折算下来，电费加上散热，会让”每小时运行成本”在硬件折旧之外再增加一个可观的份额。

如果不在自有场地，还要加上机柜租金、带宽与机房的运维服务费。这几项通常按月计费，同样与利用率无关。对个人开发者来说，在办公室或家里跑一张高端卡并不现实——噪音、供电、散热都是硬约束，这意味着自购基本等同于”租一个机房位置”，只是设备所有权不同。

还要考虑供电余量。高端卡的瞬时功耗较高，多卡整机对配电容量、线路规格与不间断电源都有要求；一旦需要改造电力环境，这笔支出会进一步抬高自建门槛。相比之下，租用平台的这部分成本被摊薄在所有用户上，这也是租用溢价的一部分来源。

第三笔账：运维人力

设备买回来只是开始：驱动与框架的版本管理、集群调度软件的部署、故障排查与硬件维修、备件与替换、安全补丁与网络配置，都需要人来做。大集群还需要专职的运维或平台工程角色。

自建集群还需要考虑冗余与备件：硬件总有故障率，一块卡坏了可能让整个多卡任务中断，因此需要准备备用卡、备用电源与替换流程。这些冗余设备平时不产生收益，却必须购置与维护；而租用平台上，故障替换由平台承担，用户只需要重新调度任务。把冗余成本计入之后，自购的真实单位成本会进一步上升。

这笔账难算的地方在于它是隐性成本：当团队规模小的时候，这些工作会摊到算法工程师身上，表面上看不出额外支出，但会真实地消耗研发时间。衡量方式可以简单地用”每月占用多少工程师工时”来估算，再按人力成本折算。很多团队在算完这笔账之后，会发现租用的溢价其实是”买了一支运维团队”。

第四笔账：机会成本

最容易被忽略的一笔。自购意味着把一笔现金锁定在会持续贬值的硬件上，这笔钱本可以投入到数据、人才或产品上；也意味着弹性丧失——当业务量突增时无法快速扩容，当模型方向调整时无法快速换型。反过来，自购也有好处：长期稳定的负载、对数据物理隔离有硬要求、或需要极致性能调优的场景下，独占硬件能带来确定性与可控性。

机会成本还包括技术路线风险。如果未来两年主流卡型或互联标准发生变化，自购的集群可能面临”能用但不再高效”的处境，而租用方可以直接切换。把这一点纳入评估，很多看起来划算的自购方案会变得不那么划算。

还有一个常被忽略的层面是资金的灵活性。把一笔钱用于购置硬件之后，它对业务的响应能力就固定下来了；而在业务早期，方向调整频繁，把钱留在手里或投向数据与人才，往往能产生更高的回报。衡量机会成本并不需要精确的计算，只需要问一个问题：这笔钱如果不买卡，还能用在哪些地方，那些地方的边际收益是否更高？如果答案不确定，租用提供的”随时收手”能力就很有价值。

盈亏平衡：用 H100 算一次

把四笔账简化成一个估算模型。以高端卡为例，取公开口径：单卡购置价格约 2.5-3 万美元量级，海外时租约 2-3 美元/小时。只考虑硬件折旧、暂不计电费与运维，简单的盈亏平衡点计算如下：

年利用率	年运行小时数	按 2.5 万美元购置的硬件摊销（按 3 年）	按 2.5 美元/时租用的年支出	粗略结论
20%	约 1752 小时	约 8333 美元/年	约 4380 美元/年	租用明显更省
50%	约 4380 小时	约 8333 美元/年	约 10950 美元/年	接近平衡，自购略优
70%	约 6132 小时	约 8333 美元/年	约 15330 美元/年	自购占优，但需扣电费与运维
90%	约 7884 小时	约 8333 美元/年	约 19710 美元/年	自购优势明显

这张表说明了两件事。第一，平衡点大致落在 40%-50% 的利用率附近——但这是”只看硬件折旧”的简化模型，把电费、散热、机柜与运维加进去之后，实际平衡点会上移到 70% 左右。第二，利用率越低，自购的劣势越明显，因为固定成本不随使用量下降。这就是”利用率超过 70% 才评估自购”这条经验的由来。

需要提醒的是，上述模型是量级估算，用于说明结构而非给出精确结论；实际数值取决于你拿到的采购价、电价、机房成本与租用折扣，请以实际报价为准。

哪些情况下自购是明确正确的

虽然大多数团队更适合租用，但确实存在几类场景，自购或长期独占是更合理的选择，值得单独说明，避免把”租用更灵活”当成一条无条件的结论。

第一类是数据物理隔离有硬要求的场景。当合规要求决定数据不能离开特定物理边界时，租用公共算力平台在合规层面可能直接不可行，此时自建或专有环境的成本是必须支付的合规成本，而不是可以优化的对象。

第二类是长期、稳定、高负载且可预测的任务。比如常驻的推理服务，如果请求量稳定、卡长期处于高负载，那么自购的单位成本优势会随时间显现。这类任务的特征是”利用率曲线平坦”——没有明显的波峰波谷，固定成本因此可以被充分摊薄。

第三类是需要极致性能调优的场景。独占硬件意味着可以针对具体拓扑做网络与存储调优、可以控制内核版本与调度策略、可以排除邻居干扰。对延迟极度敏感的服务，这种可控性本身就是价值，难以用价格衡量。

反过来，判断是否属于这三类，可以问自己三个问题：数据是否必须留在本地？负载曲线是否平坦且长期高位？性能调优的收益是否已经超过运维投入？三个问题都答”是”，自购才真正成立。

混合策略：基线自购 + 突发租用

对多数团队来说，二元选择本身就是伪命题。更现实的做法是分层：

• 基线负载自购或包月。把稳定、可预测、长期占用的那部分算力（比如常驻的推理服务、固定的训练流水线）配置成自购设备或长期包月，锁定单价。
• 突发负载按需租用。把峰值、实验、临时扩容的部分交给按需实例，避免为峰值购买硬件。
• 特殊卡型不购。只在少数项目用到的卡型（高端训练卡、超大显存卡）一律租用，不为低频需求付出购置成本。
• 保留一键切换能力。容器化与镜像化管理，确保工作负载可以在自建与租用之间迁移，避免被单一环境锁定。

这套组合的核心思想是：让固定成本只覆盖确定的部分，把所有不确定性交给可变成本承担。它同时解决了成本与弹性两个问题。

决策表

你的情况	建议	理由
利用率长期低于 40%	租用	固定成本无法摊薄，闲置成本高于租用溢价
利用率约 50%-70%	租用为主，评估包月	包月可省 20-30%，且保留了弹性
利用率稳定高于 70%，负载可预测	评估自购	固定成本被充分摊薄，长期单位成本可能更低
负载波动大、峰值高	混合：基线自购/包月 + 峰值租用	避免为峰值购置硬件，同时锁定基线成本
数据必须物理隔离	自购或专有环境	合规与安全要求优先于成本考量
个人开发者或小团队	租用	缺少机房、供电与运维条件，隐性成本极高
需要频繁试新卡型	租用	避免技术路线变化带来的资产风险

避坑清单

• 只算硬件钱。电费、散热、机柜、带宽与运维经常被漏掉，这几项能把单位成本抬高一个可观的幅度。
• 用峰值需求决定采购规模。按峰值买设备，等于全年为闲置付费；按基线买、峰值租，才是更合理的结构。
• 忽略经济折旧。新卡发布后旧卡租赁价快速下移，会计折旧年限不等于真实贬值速度。
• 把运维当成”顺手做掉”。驱动、调度、故障、备件都会持续消耗工程师时间，隐性但真实。
• 不做退出规划。自购设备的处置、迁移与兼容性要在采购时就考虑，否则退出成本会很高。

常见问题

利用率怎么算？

用卡的实际占用时长除以可用时长。实际占用包括训练、推理与数据处理，但不包括排队、空闲与调试中断。行业经验是利用率超过 70% 才值得认真评估自购，低于这个水平，租用的弹性优势通常更划算。建议连续统计一个月以上的数据再下结论，避免被短期峰值误导。

自购能省钱吗？

在利用率足够高、负载足够稳定的前提下，长期单位成本可能低于租用。但省下的钱要以占用现金、承担技术路线风险、以及自建运维能力为代价。判断的关键是：你是否有稳定的高利用率，以及是否具备运维团队或愿意投入相应人力。

小团队适合自购吗？

通常不适合。小团队缺少机房、供电、散热与运维条件，这些隐性成本会迅速抵消硬件上的价格优势；同时业务方向可能快速调整，硬件资产的灵活性损失代价更高。更现实的选择是租用，把资本留给数据与人才。

混合策略会不会更复杂？

会增加一定的环境管理成本，但可以通过容器化与统一的镜像管理把复杂度控制在可接受范围内。相比”为峰值买单”或”完全受制于单一平台”，混合策略的复杂度支出通常是值得的。关键是保持工作负载的可迁移性。

多长时间能回本？

取决于利用率、购置价与实际时租。以高端卡 2.5-3 万美元的购置量级与 2-3 美元/小时的时租口径粗略推算，在接近满负荷运行的假设下，回本周期大致在一年多的量级；利用率减半，回本周期就会显著拉长，甚至永远无法回本。这个估算只用于说明量级，实际请以你拿到的报价为准。

总结

算力租用还是显卡自购，答案不在价格表里，而在你的利用率曲线上。四笔账——设备折旧、电费与机房、运维人力、机会成本——共同决定了自购的真实单位成本；把它们全部摊开后，平衡点通常落在 70% 左右的利用率。低于这条线，租用更划算且更灵活；高于这条线且负载稳定，可以认真评估自购；而绝大多数团队的最优解，是”基线自购或包月 + 突发按需租用”的混合结构。所有价格与成本均为公开信息的量级整理，请以实际报价与合同条款为准。

结论先行：四张卡的定位一句话

A100、H100、H800、H20 这四张卡经常被放在一起比较，但它们的定位其实分属三个不同的逻辑：A100 是上一代数据中心主力，显存与生态成熟；H100 是当前高端训练与推理的标杆，卡间互联带宽最高；H800 是 H100 的合规版本，互联带宽做了折损；H20 则是一条完全不同的设计路线——保留显存容量与带宽，主动削减算力。选择的核心不是”谁最快”，而是”你的瓶颈在互联、在显存，还是在算力”。

下面用一张规格速查表把差异摆平，再逐条解释 800 系列的合规背景、H20 的产品逻辑，最后给出三类场景的选型决策和一段国产替代的对位说明。表中的价格是 2026 年公开市场区间的量级整理，以各平台官网实时价格为准。

规格速查表：一张表看懂差异

卡型	显存	显存带宽定位	卡间互联（NVLink）	算力定位	市场价量级
A100	40G / 80G	上一代数据中心级	高带宽互联（A800 版本降至 400GB/s）	上一代通用训练主力	2.4-2.9 元/小时
H100	80G	新一代高带宽	900GB/s	当前高端训练/推理标杆	国内约 9.6-12 元/小时；海外 $2.0-3.5
H800	80G	与 H100 同级	600GB/s（合规版本）	与 H100 同档，互联折损	国内约 9.6-12 元/小时
H20	96G	保留高显存带宽	按整机方案配置	主动削减算力	约 2.1 万元/月/卡 量级

把这张表读成三句话：第一，显存容量从 40G 到 96G 跨越多个档位，直接决定你能装多大的模型；第二，互联带宽是 H100 与 H800 的核心差异（900GB/s 对 600GB/s），也是 A800 与 A100 的差异（600GB/s 对 400GB/s）；第三，H20 走的是另一条曲线，它的显存与带宽不弱，但算力被有意收窄。这三句话基本覆盖了四张卡的全部选型逻辑。

800 系列的合规背景

理解 H800 与 A800 的存在，才能理解这张表。A800 与 H800 是面向特定合规要求的产品版本：在保留显存容量与大部分算力的同时，卡间互联带宽被下调——A800 的互联带宽降到 400GB/s，H800 降到 600GB/s（H100 为 900GB/s）。这不是”性能档次”的下调，而是针对特定参数的限制，目的在于约束大规模集群的并行扩展效率。

这条限制的实际影响，取决于你的并行策略对卡间通信的依赖程度。张量并行（TP）需要频繁同步激活值与梯度，通信量大，带宽折损会直接反映为扩展效率下降；数据并行（DP）的通信量小得多，带宽差异的影响有限；而单卡推理几乎不受影响。所以国内做多卡训练时的常见建议是：如果预算允许且策略以 TP 为主，优先 H100；如果是 DP 为主或推理为主，H800 在价格相近时完全可以承担，不必为纸面带宽多付溢价。

H20 的逻辑：保显存与带宽，砍算力

H20 的设计思路与前三张卡都不一样。它保留了较大的显存容量和高显存带宽，但主动削减了计算能力，量级报价约 2.1 万元/月/卡。这个组合带来一个明确的能力画像：它擅长”数据搬运”而不是”数据计算”。

什么负载符合这个画像？显存与带宽敏感、算力相对宽容的场景——比如以显存容量决定能否装下、以带宽决定吞吐的推理服务，特别是长上下文、大模型权重常驻显存的在线推理。反过来，计算密集型的预训练或大规模微调，在 H20 上会因为算力受限而显著拉长工期，性价比不成立。判断方法很简单：先确认你的任务在瓶颈剖面上属于”带宽受限”还是”算力受限”，前者可以考虑 H20，后者不应考虑。

值得注意的是，H20 通常以整机或包月口径报价（约 2.1 万元/月/卡 量级），与按小时零售的 A100、H100 不在同一个计费维度上。做对比时必须先换成同一口径，否则容易得出错误结论。

显存与互联：两个最容易被误判的参数

选卡时最先被看到的往往是”算力”，但真正决定任务能不能跑、跑得快不快的，通常是显存容量、显存带宽与卡间互联这三个参数。

显存容量是”能不能装下”的问题。模型权重、优化器状态、梯度与激活值都要占用显存，容量不足时任务直接无法启动，只能通过量化、梯度检查点或参数高效微调来压缩需求。这也是 A100 的 40G/80G 与 H100 的 80G、H20 的 96G 之间最直观的差别：它决定了可服务的模型规模上限。

显存带宽是”跑得动多快”的问题。当模型权重需要频繁在显存与计算单元之间搬运时，带宽直接决定吞吐上限。这一点在推理场景尤为明显——H20 的设计正是围绕”保住显存带宽”展开的，它愿意为此牺牲算力，因为对很多推理负载来说，带宽才是真正的瓶颈。

卡间互联是”能不能扩展”的问题。单卡能力再强，多卡训练的效率也取决于卡之间同步数据的快慢。H100 的 900GB/s、H800 的 600GB/s、A800 的 400GB/s 构成了一条清晰的分级，而并行策略对带宽的敏感度依次是：张量并行 > 流水线并行 > 数据并行。换句话说，只有当你的策略真的吃带宽时，高带宽互联的溢价才有意义。

把这三个参数串起来，就得到一条实用的判断顺序：先看显存容量是否够装，再看显存带宽是否满足吞吐目标，最后看卡间互联是否匹配并行策略。算力排在这三项之后，因为算力不足通常可以通过增加卡数或优化实现来弥补，而显存与互联的短板往往无法绕过。

选型决策：按场景对号入座

场景	推荐	理由
单卡推理、模型不超过 80G 显存	A100 或 H100 单卡	不涉及卡间互联，算力与显存满足即可，A100 成本优势明显
长上下文、高并发在线推理	H100 或 H20	显存带宽决定吞吐；算力不是唯一瓶颈
多机多卡大规模训练	H100 优先	TP 并行对互联带宽敏感，900GB/s 优势直接体现为扩展效率
有合规约束的多卡训练	H800（或 A800）	按合规要求选择，接受互联带宽折损，优先用 DP 策略
显存需求超过 24G 但预算有限	A100 40G/80G	单价 2.4-2.9 元/时，是显存升级的最低成本路径
信创合规环境	昇腾 910B	见下一节，属于生态层面的替代而非规格替代

国产替代：昇腾 910B 的对位

谈到国产替代，最常被提及的是昇腾 910B。它的公开规格为 FP16 算力 280 TFLOPS、64G 显存、1.6TB/s 显存带宽，定位上与 A100 量级相近，在显存容量与带宽上具备对位能力。生态层面，910B 走的是 CANN/MindIE 路线，与 CUDA 生态并行而非兼容。

因此国产替代的本质问题不是”规格够不够”，而是”迁移成本有多大”。从公开披露的信息看，CUDA 到 CANN 的适配周期通常在数月量级（业界公开提及过 3-6 个月的适配期），期间需要投入工程资源做算子适配、框架兼容与性能调优。这意味着选型决策要分两步：先确认是否存在信创或供应链安全的硬约束，如果有，就按长远规划预留适配时间；如果没有，则把 910B 作为长期对冲选项做小规模验证，而不是立刻全量替换。

避坑清单

• 只比算力数字。训练场景下互联带宽经常比峰值算力更能决定实际扩展效率，H100 与 H800 的差异就是例子。
• 混淆报价口径。H20 是整机/包月口径（约 2.1 万元/月/卡 量级），H100 是时租口径（9.6-12 元/小时），直接比较数值没有意义。
• 忽略显存带宽。当模型权重常驻显存时，带宽决定吞吐上限；H20 的设计正是围绕这一点展开的。
• 用单卡跑分推断多卡表现。多卡性能受互联、并行策略、通信开销共同影响，单卡跑分无法预测。
• 把国产替代当成简单换卡。生态迁移需要工程投入与验证周期，必须计入项目排期。
• 升级前不定位瓶颈。如果瓶颈在显存容量或数据读取，换更强的算力并不会带来相应收益；先定位瓶颈，再决定升级方向。
• 忽略整机配套。多卡训练不只取决于卡本身，网络拓扑、存储吞吐与调度软件同样决定实际可用的规模。

最后补充一个容易被忽略的维度：软件生态与框架支持。同一张卡在不同框架、不同版本下的实际表现可能差异明显，尤其是在使用自定义算子、量化或特殊并行策略时。选型阶段如果能用自己的训练或推理脚本做一次真实验证，结论会比参考任何规格表都更可靠——规格表告诉你上限，你的脚本告诉你实际。

此外，采购路径也会影响实际成本。同一张卡，整机采购、按卡租赁与按小时零售是三种不同的商业模式，对应的单价、承诺期与服务水平各不相同。做横向比较时，先把所有报价换算到同一个口径——比如统一折算成”每卡每小时”——再比较，否则很容易把整机月租与零售时租混为一谈，得出与事实相反的结论。

结语：把决策链记下来

规格数据会随产品迭代更新，但判断方法不会变。先看显存容量能不能装下、再看带宽与互联是否匹配负载特征、最后才比较算力与价格——这条顺序能帮你在任何一次硬件更新中快速定位。对于国产替代，把生态适配周期当成一个独立变量放进排期，而不是当成一次简单的换卡操作。这四张卡之间的差异，本质上不是”谁更强”，而是”谁更适合你的瓶颈”。

常见问题

H800 和 H100 到底该选哪个？

看两件事：并行策略与合规要求。TP 为主的大规模训练优先 H100，因为 900GB/s 对 600GB/s 的差距会在扩展效率上放大；DP 为主或推理场景，H800 在价格相近时完全够用。如果存在明确的合规约束，选择范围就已经确定了。

A100 是不是已经过时了？

没有。A100 的 40G/80G 显存与 2.4-2.9 元/小时的单价，构成了”显存升级的最低成本路径”。对于不需要最新互联带宽、也不追求极限算力的训练与推理任务，A100 依然是性价比很高的选择，生态成熟度也是它的优势。

H20 的算力被砍了，为什么还有人用？

因为不是所有负载都被算力限制。长上下文、高并发的推理服务，瓶颈常在显存带宽与容量，H20 保留了这两项，因此在这类场景下仍然可用；而在训练场景下它的性价比确实不成立。用它之前先确认瓶颈在哪一侧。

国产卡什么时候可以完全替代？

这个问题没有统一答案，因为取决于你的软件栈复杂度。生态简单的推理服务迁移成本低，重依赖自定义算子与训练框架的项目迁移成本高。务实做法是分层替代：先从推理侧、从生态依赖少的服务开始验证，再逐步扩展到训练侧。

显存和互联，哪个更重要？

取决于任务阶段。训练阶段，互联更能决定多卡扩展效率；推理阶段，显存容量与带宽更能决定吞吐与可服务的上下文长度。先做瓶颈判断，再决定为哪一项付费。

总结

四张卡的选择可以压缩成一条决策链：先看显存容量是否装得下，再看卡间互联是否匹配你的并行策略，最后看算力与价格是否合理。H100 与 H800 的差异集中在互联（900GB/s 对 600GB/s）与合规定位；H20 走的是保显存带宽、砍算力的路线，适合带宽受限的推理而不适合计算密集的训练；A100 是显存升级的最低成本路径；昇腾 910B 属于生态层面的替代选项，需要预留适配周期。把这条决策链记住，任何新卡型出现时你都能快速定位它的位置。所有价格与规格均为公开信息区间的量级整理，具体以各平台与厂商官方渠道为准。

结论先行：4090 是性价比的锚点

2026 年在国内云上租 GPU，RTX 4090 是最值得作为”锚点”的一张卡：24G 显存、消费级旗舰的算力、供给最充足、价格最透明，市场价约 1.2-2.5 元/小时，包月折算可以低到 0.8-1.5 元/小时。它既不是最便宜的，也不是最强的，但它处在”够用”与”划算”的交点上——绝大多数个人开发者和中小团队的日常任务，用 4090 就能跑完，而成本只有 A100 的一半左右、H100 的七分之一左右。

这篇文章回答一个具体问题：1.2-2.5 元/小时这个价格带里，怎么花钱才值。答案是三件事——选对场景、看清价格口径、避开配套性能的坑。24G 显存能干什么、不能干什么，比卡上标的算力数字重要得多。

价格带：同一张卡，为什么差了近一倍

先把价格拆开看。4090 的价格差异主要来自四个变量：是否包月、卡池新旧与机房地域、计费粒度（按秒还是按小时取整）、以及渠道折扣（新用户券、会员价）。把公开市场报价按口径整理成表，就能看出差异的来源。

口径	价格区间	说明
按需时租（零售平台）	1.2-2.5 元/小时	算家云约 1.24 元、智星云约 1.31 元、AutoDL 约 1.8-2.5 元
包月折算	0.8-1.5 元/小时	月均使用越长越划算，通常是省 20-30% 的量级
老一代同级卡（3090）	约 1 元/小时起	显存同为 24G，算力弱于 4090，适合显存敏感场景
降配版 4090D	约 1.14 元/小时起	价格略低，算力有折损
新一代 5090	2.68-3.28 元/小时	32G 显存，显存与带宽提升，单价约为 4090 的两倍
入门卡（3080Ti/2080Ti 等）	0.88-0.98 元/小时	预算极紧时的试水选择

读这张表的正确方式不是找”最便宜的 1.2″，而是确认三件事：你的任务时长是否达到包月门槛、你的机房是否在数据附近（影响传输与延迟）、以及计费粒度是否对你有利。一个按秒计费、1.6 元/小时的平台，对”每次只跑几十分钟”的任务，往往比按小时取整、1.24 元/小时的平台更省钱。

24G 显存能干什么

4090 的 24G 显存是它的核心资产，也是它的天花板。显存决定了三件事：能装多大的模型、能设多大的批次、能支持多长的上下文。以公开的模型规模经验为参考，7B 级模型在推理时占用约 14-16G（FP16 口径），经过 4-bit 量化后可以压缩到约 5-6G；13B 级模型 FP16 推理约需 26G 以上，必须量化后才能装进 24G；70B 级模型即便量化后也超出单张 24G 的容量，需要多卡或更大显存的卡。这意味着 4090 的能力边界大致落在”7B-13B 模型 + 参数高效微调”这一带。

需要补充的是，显存占用不是只看模型权重的静态值。训练时的优化器状态、梯度、激活值都会占用额外显存，批次越大、序列越长，激活占用越高；推理时的 KV 缓存也会随上下文长度增长。因此同一个模型，在不同批次与序列长度下，能否装进 24G 的答案可能完全不同。这也是为什么”这张卡能不能跑”这个问题，必须用你自己的任务参数去验证，而不是照搬别人给出的结论。

适合 4090 的四类场景

一、AIGC 出图与视频生成

出图类负载对显存敏感、对多卡互联不敏感，24G 显存可以支撑较高分辨率的批量生成，是 4090 最典型的用武之地。这类任务通常短时、突发、可并行，配合按秒计费与包月时段，成本非常可控。注意显存占用会随分辨率与批量线性上升，出图时显存溢出（OOM）多半是批量设得太大，而不是卡不够强。

二、LoRA 与轻量微调

参数高效微调是 4090 的第二主场。7B 级模型做 LoRA 微调，显存占用通常可以压在 24G 以内；13B 级则需要更激进的梯度检查点与量化组合。这里的经验是：微调的成本主要不是卡价，而是”试错次数”——一次超参没调好就要重来，所以计费粒度细、开机快的平台，实际比单价低但开机慢的平台更省。

三、中小模型训练与算法验证

图像分类、检测、分割、语音、时序预测这类中小规模模型的训练，4090 完全够用。多卡场景下要注意，消费级卡之间的互联能力弱于数据中心卡，数据并行（DP）通常比张量并行（TP）更现实：前者通信量小，后者对卡间带宽要求高，在 4090 集群上很难获得线性加速。

四、在线推理与小规模服务

如果用 vLLM 这类推理框架做 7B-13B 的在线服务，单张 4090 可以达到可观的并发。代价是消费级卡在长时间高负载下的稳定性不如数据中心卡，生产环境建议至少保留冗余实例，并明确评估平台是否提供故障赔付条款。

什么时候该从 4090 升级到 A100

4090 的边界非常清楚：显存需求超过 24G 时，它就不再是选项。判断是否需要升级，可以用三个信号来识别。

第一个信号是”反复为了省显存而妥协”。当你不得不降低批次、缩短序列长度、或者改用更激进的量化才能跑起来，而这些妥协已经影响到效果或吞吐时，说明瓶颈是显存而不是成本，升级到 40G/80G 的卡是正确方向。第二个信号是”稳定性成为生产要求”。消费级卡在长时间高负载下的表现不如数据中心卡，如果任务需要 7×24 运行并附带赔付条款，数据中心卡的溢价是买保险。

第三个信号是”多卡并行的扩展效率不达标”。如果业务已经需要多张卡协同，而消费级卡之间缺乏高带宽互联导致扩展效率明显偏低，那么换成有高带宽互联的数据中心卡，可能比继续加卡更省钱——多买两张 4090 的钱，往往已经接近一张 A100 的时租成本。

反过来，如果以上三个信号都没出现，升级就是不划算的。A100 的时租在 2.4-2.9 元区间，是 4090 的两倍左右，仅因为”听起来更强”而升级，等于为用不上的能力付费。

配套性能陷阱：卡之外的三个瓶颈

4090 的算力很少是瓶颈，真正拖慢任务的是卡之外的三件事，这也是评测平台时最容易忽略的部分。

• 磁盘 IO。训练任务启动时要读取数据集，如果磁盘吞吐低，GPU 会大量时间处于等待状态。判断方法是在试用阶段实测读取大文件的速度，而不是只看卡型。
• 网络带宽。拉取镜像、上传数据集、下载模型权重都走网络。出网带宽受限或按流量计费时，”便宜的卡”可能被昂贵的流量费吃掉优势。
• 虚拟化损耗。云上实例通常是虚拟化或容器化的，实测算力可能低于物理卡；不同平台的损耗比例不同，建议用固定基准脚本对比，而不是相信标称参数。

还有一个常被忽略的点是存储计费：数据盘、快照、镜像往往与卡时分开计费，长期保留数据的成本会随时间累积。把任务设计成”用完即清”，比单纯找低价卡更有效。

把这三点连起来，就得到一条实际的决策路径：先用一次真实负载确认显存与吞吐是否满足需求，再确认价格口径（包月还是按需、按秒还是按小时计费），最后确认磁盘性能、网络成本与故障赔付条款。三步都通过，这台 4090 才真正”值”；只要有任何一项不通过，就要重新考虑卡型或平台选择，而不是继续在单价上做文章。

替代关系：4090D、3090、5090 怎么选

卡型	显存	相对 4090 的定位	什么时候选它
RTX 4090D	24G	算力略低的替代版，价格约 1.14 元/时起	预算敏感、且任务对算力不敏感（如轻量推理、出图）
RTX 3090	24G	老一代，算力弱、价格约 1 元/时起	显存敏感但算力需求低，或需要更低的长期成本
RTX 5090	32G	新一代，显存与带宽提升，单价约 2.68-3.28 元/时	13B 级微调、更高分辨率出图、需要更大显存余量
A100	40G/80G	数据中心卡，显存与稳定性更好，约 2.4-2.9 元/时	显存超过 24G 的需求、长时间生产任务

选型逻辑可以归纳成一句话：先看显存够不够，再看算力够不够，最后看稳定性够不够。显存不够就只能换卡，算力不够可以换算法或加卡，稳定性不够则要靠平台兜底。按这个顺序判断，就不会被单价带偏。

还有一个实用的观察角度是”单位任务成本”，而不是”单位小时成本”。同样一项出图任务，在 1.2 元/小时的老卡上跑到深夜，可能比在 2.5 元/小时的新卡上快速跑完更贵；同理，一个因为磁盘 IO 慢而多跑两小时的实例，实际成本远超标称单价所显示的数字。把成本除以任务产出（出一张图、训一轮、处理一条请求），得到的数字才真正可比。

常见问题

4090 和 5090 之间，差价值得吗？

关键看你是否需要多出来的显存余量。如果任务在 24G 内就能跑得舒服，5090 的溢价（单价约两倍）性价比不高；如果经常撞到显存上限（比如 13B 级微调、高分辨率视频生成），32G 带来的”不用反复调参省显存”的体验提升，往往比多付的单价更值钱。判断标准是：过去一个月你有没有因为显存不足而降低批量或改用量化。

包月一定比按需省吗？

不一定。包月省 20-30% 的前提是使用时长足够长、且基本吃满。月均使用量级在 150 小时以上时，包月通常更划算；低于这个量级，按需或按秒计费更灵活。特别是任务间隔较长的开发者，包月意味着为闲置付费。

为什么平台标称的算力我跑不出来？

三个原因：虚拟化损耗、散热降频、以及共享资源争抢。另外，标称参数通常是理论峰值，实际负载受显存带宽、内存与磁盘 IO 制约。正确的做法是用你自己的负载做基准测试，而不是用通用跑分脚本，因为跑分与真实负载之间经常脱节。

多张 4090 能替代一张 A100 吗？

在显存需求不超过 24G 的前提下，某些场景可以，但要注意互联差异。消费级卡之间缺乏高带宽互联，多卡并行的扩展效率通常明显低于数据中心卡，尤其是张量并行。数据并行场景下，多张 4090 是现实可行的方案；张量并行或需要大显存的场景，还是应该选 A100 或更大显存的卡。

怎么判断一个平台的 4090 值不值？

用四个动作验证：跑一次真实负载测吞吐；实测磁盘读取速度；确认计费粒度与关机是否计费；读一遍故障与赔付条款。四项都过关，再考虑价格。只看单价就下单，是最常见的踩坑方式。

总结与画像建议

• 个人开发者：首选按需或按秒计费的 4090，把预算花在试错次数上而不是闲置时长上；出图与 LoRA 微调是它的最佳场景。
• 小型团队：用”4090 包月基线 + 突发按需”的组合，把稳定负载包月锁定成本，把实验负载留给按需；同时保留一张 5090 或 A100 的临时额度应对显存溢出。
• 生产服务：4090 可以做推理，但要评估长时间高负载的稳定性与赔付条款，必要时用多实例冗余替代单卡高负载。OpenBayes 这类平台可以对照其公开的卡型与计费口径做横向比较。

回到最初的问题：1.2-2.5 元/小时怎么花得值。答案是——把 4090 用在它擅长的地方（显存需求落在 24G 以内的任务），把价格口径对齐（包月还是按需、按秒还是按小时），把配套性能测清楚（磁盘、网络、损耗）。做到这三点，你的每一小时都在为结果付费，而不是为等待付费。所有价格均为 2026 年公开市场区间的量级整理，请以各平台官网实时价格为准。