做算力租赁这行的最近见面聊得最多的一句话就是国产GPU到底能不能顶上来我敢不敢把机柜里的H100换掉一部分这话听着像技术问题其实是道商业题。我自己前后跑过三轮测试从单卡跑通模型到8卡整机压72小时再到拿真实业务流量做灰度中间踩的坑足够写一本小册子。这篇文章就把这套流程完整摊开讲国产GPU在哪些场景下已经可以交付给客户在哪些场景下换过去就是给自己埋雷算力租赁这门生意的账该怎么算迁移工作量到底有多少人力。不管你是刚入行准备采购第一台机器的租赁商还是手里已经有一批卡、正在纠结要不要混搭的技术负责人都能从里面找到可以直接抄的测试方法和判断标准。我不会给你一个能或者不能的结论因为这个问题本来就不该有统一答案我只把决策需要的数据和坑点摆出来。1. 换卡之前先把这门生意的账本搞清楚很多人讨论国产卡能不能替代一上来就比纸面算力这个思路从第一步就跑偏了。算力租赁卖的不是TFLOPS卖的是客户的任务能在约定时间内以约定成本跑完这个承诺。同样一张卡放在科研单位做小规模实验和放在租赁机房里给几十个客户共享评价标准完全是两回事。所以在动手测之前我习惯先把账本拆成三层每一层都会直接影响你最后换不换、换多少的判断。1.1 算力租赁真正要算的三笔账第一笔是采购账。整机含税价只是冰山一角后面还跟着备件比例、保修年限、返修期间的算力损失。我见过有人只盯着单卡报价便宜三成结果故障率高了以后备件库里常年躺着三台机器在等维修实际可用算力反而更少。第二笔是运营账包含功耗、PUE、机位租金、运维人力分摊。这一笔在风冷机房里特别关键因为功耗差异会被PUE放大而且会直接吃掉你的电力配额——很多机房不是没钱买卡是没电装卡。第三笔是交付账也就是客户真正掏钱买的那个单位每百万token多少钱或者每张图多少钱或者每个训练epoch多少小时。这三笔账任何一笔没算清楚换卡的决策都是拍脑袋。账本具体项为什么它比单卡算力更重要采购账整机价、备件率、保修年限、返修周期决定资产折旧基数返修周期长会直接拉低上架率运营账实测功耗、机房PUE、机位费、运维分摊功耗差200W在PUE 1.3下一年电费差约1500元/卡交付账每百万token成本、客户代码改动量客户只认这个前两笔账最终都要折算到这里我自己的习惯是做一个单卡月度成本模型把所有摊销项都塞进去最后得出一个每卡每月保本价。这个数字才是你和客户谈判的底线也是衡量换卡是否划算的唯一标尺。1.2 能跑通和敢卖出去中间隔着一条河这是我最想强调的一点。测试环境里把模型跑起来、输出几句话这叫能跑通。敢不敢把这台机器写进合同、承诺SLA、卖给客户中间隔着一条很宽的河。河这边是实验室河那边是生产环境客户会拿变长序列来打你会用没见过的batch size来打你会在凌晨三点提交一个需要跑40小时的任务还会在你承诺的时间点前五分钟问你要结果。我在第一轮测试的时候就吃过这个亏。单卡跑7B模型吞吐数据很漂亮我兴冲冲地跟一个做在线客服的客户说可以换结果真实流量一上来长prompt占比高首token延迟直接翻了三倍客户那边的体验指标当场崩掉。后来复盘才发现我的测试用例里prompt长度全是固定的512而客户的真实输入平均1500、P99到4000。这件事让我彻底改变了测试思路所有用例必须从真实流量里采样而不是自己造。提醒任何一份没有标注prompt长度分布和输出长度分布的吞吐数据都是不可信的。看到只有XX tokens/s的测试报告直接问对方要长度分布。还有一层河是运维层面的。客户不会关心你的卡是什么架构他只关心两件事任务能不能按时完成出问题多久能恢复。国产卡的故障形态和排查工具链跟原来的CUDA体系不一样你的运维团队需要重新学一套东西。这个学习成本在换卡决策里经常被低估但它往往是压垮项目的最后一根稻草——机器换过去了人没跟上上架率一掉客户就跑了。2. 实测环境与测试方法怎么测才算数测试方法不对后面的数据全是废纸。我把三轮测试的环境、工具和用例设计完整写出来你可以直接照着搭。需要说明的是下面涉及的国产卡我用A、B两个代号指代一个是偏训练和通用推理的型号一个是偏推理性价比的型号不点名是为了避免变成某家的宣传材料你按参数对应到自己的候选清单就行。2.1 硬件与组网环境说明测试平台是一台8卡整机风冷卡间通过厂商自己的高速互联总线连接对外是两张400G网卡走RoCE组网。对照组是一台8卡H100 SXM整机同样风冷、同样400G组网。两台机器都接在同一台交换机下避免网络路径差异影响结果。软件层面国产平台用的是厂商提供的容器镜像加适配过的推理框架分支对照组用的是同版本的上游框架尽量让软件变量可控。关键参数先摆出来方便你对照自己的候选清单指标A型号B型号H100 SXM显存容量64GB HBM32GB80GB HBM3显存带宽约1.6TB/s约0.8TB/s3.35TB/sBF16稠密算力约350-400 TFLOPS约180 TFLOPS约990 TFLOPS卡间互联厂商私有高速总线厂商私有高速总线900GB/s整卡功耗约350-400W约250W约700W这些数字是官方标称我给的是区间因为不同批次和不同固件版本实测差异不小。记住一点标称值只用来判断能不能上真正决定报价的是实测值。2.2 测试用例设计从单卡峰值到多卡线性度我的用例分了五层从下往上依次是算子级、单卡模型级、多卡模型级、集群通信级、长时稳定性。为什么要分层因为任何一层出问题你都能定位到具体是硬件、驱动、框架还是业务代码的锅。直接上整机跑大模型出问题你根本不知道从哪查起。第一层算子级跑不同shape的矩阵乘和归一化、激活函数看实际算力能达到标称的百分之多少。这一层最枯燥但最有用很多跑得慢的问题其实在这一层就暴露了。# 算子与通信基础测试容器内执行 # 1) 算力基准不同shape的GEMM观察实际TFLOPS ./bench_gemm --dtype bf16 --m 4096 --n 4096 --k 4096 --iters 200 # 2) 单机8卡allreduce看总线带宽 ./bench_allreduce -b 8 -e 8G -f 2 -d bf16 # 3) 跨机allreduce验证RoCE链路 ./bench_allreduce -b 16 -e 8G -f 2 -d bf16 -H host1,host2第二层单卡模型级用7B模型跑prefill和decode重点看显存带宽利用率。这一层我会用固定的并发梯度1、4、16、32、64每个梯度跑满三分钟取稳定值。第三层多卡模型级用70B模型做张量并行看线性度。第四层集群通信级跑allreduce和alltoall这是训练场景的命门。第五层长时稳定性72小时连续压测每小时记录一次温度、功耗、显存占用和吞吐看有没有降频和抖动。测试脚本我用Python做了一层封装把关键指标都落到日志里方便横向对比# 压测记录器每30秒采样一次落成csv便于画图 import time, csv, subprocess def sample(metrics_cmd, out_path, duration_s72*3600, interval30): with open(out_path, w, newline) as f: w csv.writer(f) w.writerow([ts, temp_c, power_w, mem_used_gb, tokens_per_s]) end time.time() duration_s while time.time() end: row subprocess.check_output(metrics_cmd, shellTrue).decode().strip().split(,) w.writerow([int(time.time())] row) f.flush() time.sleep(interval) # 实际调用示例 sample(cat /run/metrics/current.csv, stress_72h.csv)实操心得压测日志一定要按小时切片看趋势不要只看平均值。我遇到过一台机器平均吞吐完全正常但每小时的前五分钟吞吐掉30%原因是固件里有个周期性做显存整理的动作。这种问题只看平均值永远发现不了。3. 核心指标逐项拆解到底差在哪、好在哪数据跑出来之后最关键的是会不会读。我把五项核心指标逐条拆开告诉你哪些差距是可以通过调优抹平的哪些是硬件层面的硬差距以及在租赁场景里各自意味着什么。3.1 算力与显存带宽纸面参数与实际吞吐的偏差先给结论在推理场景下国产卡的实测表现和标称的差距比H100更大一些但差距主要集中在显存带宽这一项上而不是算力。原因很简单大模型推理的decode阶段是典型的访存密集型任务每个token都要把模型权重完整读一遍所以decode吞吐基本等于显存带宽除以权重大小再乘一个75%左右的效率系数。A型号1.6TB/s的带宽理论上限就是H100 3.35TB/s的一半左右实测下来这个比例基本吻合。下面是我这轮测试的实测数据7B模型FP16精度输入512、输出256模型与配置并发输出吞吐(tok/s)首token延迟(ms)单token延迟(ms)7B / A型号单卡19521010.57B / A型号单卡32185048017.37B / H100单卡12051304.97B / H100单卡3239002608.270B / A型号8卡TP3252014006170B / H100 8卡TP32140078023这组数字需要读得细一点。单卡低并发下A型号大概是H100的46%到32并发时比例上升到47%基本同步。也就是说在中小模型、高并发批处理的场景里两台机器的吞吐比例是稳定的你可以很放心地用两台换一台这种粗算法来做容量规划。但首token延迟的比例是1.6倍到1.8倍这对在线交互类业务是硬伤——如果客户合同里写了首token延迟的具体指标这个差距是绕不过去的。70B这一行的差距更明显吞吐只有37%延迟比接近2.6倍。这说明规模上去之后卡间互联的带宽劣势会被放大。训练场景里这个放大效应更夸张我后面单独讲。3.2 精度与算子支持那些跑不通、跑得慢的坑这一节是纯实操经验也是我认为最值得花时间做的部分。纸面算力再高算子跑不起来一样是废铁。我整理了四类必须逐个验证的东西。第一类是数据类型支持。BF16基本都没问题但FP8的支持情况差异很大。如果你的客户在做大模型预训练或者需要FP8量化的推理这一点必须在选型前置确认不能等到迁移的时候才发现要退回BF16那样吞吐直接腰斩。第二类是注意力实现。Flash Attention这类融合算子在国产平台上有时候是厂商自己实现的版本行为和精度跟上游不一定完全一致。我遇到过一件事某个长上下文场景长序列下的输出质量在国产卡上出现了肉眼可见的退化最后定位到是注意力实现在处理极长序列时的分块策略和上游不同。这种问题在短序列测试里完全看不出来。第三类是非标准算子。客户自己写的自定义算子、特殊的位置编码、变体的MoE路由这类东西基本都要重写或者找厂商支持。我的经验是提前把客户的模型结构过一遍把非标准算子列成一张表逐个确认有没有替代实现。第四类是动态shape和变长序列。这一项特别容易翻车。国产平台的图编译模式对动态shape的支持程度不一有些情况下会触发反复重编译表现为跑着跑着突然卡住几秒。测试的时候一定要用真实长度分布去跑不要用固定shape。注意测试精度时不要只看最终输出对不对要做逐层对齐。把中间层的激活值导出来跟参考实现对一遍能提前发现很多隐蔽的精度问题。我自己吃过这个亏最后一层输出看着正常中间层已经偏了结果在长尾样本上全军覆没。3.3 多卡互联与集群线性度租赁商做训练业务通信就是命。单卡再强8卡扩不起来一样接不了活。我重点测了两个指标单机8卡allreduce总线带宽和跨机allreduce带宽以及从1卡到8卡的线性度。测试项A型号平台H100平台说明单机8卡allreduce总线带宽约180GB/s约420GB/s差距约2.3倍跨机allreduce双机约38GB/s约42GB/s接近网络是瓶颈1→8卡推理吞吐线性度0.820.94张量并行的效率损失1→8卡训练线性度0.720.89通信占比越高差距越大这组数据说明两件事。第一单机内部互联是硬差距这个短期内靠软件优化很难弥补因为它是物理链路决定的。第二跨机场景下网络成了瓶颈两台机器的表现非常接近这意味着如果你的业务是跨机多副本推理比如每个模型副本单机跑副本之间只做负载均衡国产卡和H100的集群级表现差距会小得多。这个发现直接影响了我的部署策略后面第5节会详细说。训练线性度0.72这个数字对租赁商来说意味着你买8张卡实际只能当5.8张用。这个损失必须算进报价里不能按8卡报出去不然做一单亏一单。我的做法是在调度系统里按有效算力而不是物理卡数来做资源分配避免超卖。3.4 稳定性与长时压测72小时能暴露什么稳定性是租赁商和自用用户最大的区别所在。自用的人可以容忍一周重启一次租赁商不行客户的任务跑在你这半夜掉一次卡可能就是一个价值几万的训练任务报废。我做了三轮72小时压测发现了几个值得记录的现象。第一个是温度墙和功耗墙。A型号整机在满载72小时后卡温稳定在72到78度之间没有触发降频这一点比预期好。但有一台机器在第三天上午出现了间歇性降频查下来是机房局部热区导致的进风温度高了4度。所以压测必须在真实机位上做不能在凉快的测试间做不然数据没有参考价值。第二个是显存碎片和长时任务的抖动。连续跑48小时后同一配置的吞吐比第一天下降了约6%重启容器后恢复。这个现象在H100上看不到。对于长时训练任务这意味着你要在容错设计上多留余量。第三个是固件和驱动版本的批次差异。同一型号、不同批次的机器在同一个模型上的吞吐差异能到8%到12%。这个数字听起来不大但对批量采购的租赁商来说意味着你不能用一台机器的实测值去推算整个机房的容量必须逐台抽测。提醒抽测比例建议不低于10%而且要覆盖不同批次。验收报告里标注每台机器的实测吞吐作为后续调度权重和排查基线。我见过因为没做这件事后面调优时连变慢了这个结论都证不出来的情况。4. 软件栈迁移真正的成本大头硬件买回来只是开始把客户现有的业务迁过去才是硬仗。我把迁移工作按场景拆成三类每一类的改动量、人力估算和风险等级都不一样你可以对照自己的客户结构来评估总工作量。4.1 从CUDA生态迁到国产栈的迁移路径迁移路径通常有三种成本从低到高。第一种是框架层面已经支持客户只需要换镜像、换个权重格式业务代码一行不改。这种情况现在越来越常见主流推理框架都有国产平台的适配分支模型池里常见的开源模型基本都能直接跑。第二种是有一部分自定义算子或者特殊结构需要重写算子或者换一个等价实现工作量按算子数量算。第三种是深度耦合的比如自研的训练框架、自定义的通信策略、特殊的内存管理这种情况迁移成本可能超过收益我会直接建议客户保留原平台。迁移场景主要改动内容人力估算风险等级纯推理主流框架已适配换镜像、转权重格式、压测验证1-2人日/模型低含自定义算子的推理算子重写或等价替换、精度对齐1-3人周中LoRA微调训练框架适配、精度对齐、checkpoint迁移3-5人日中全参微调通信库、优化器、断点续训、精度对齐2-4人周高预训练全栈适配含数据集与并行策略不建议在首轮切换中尝试极高这张表的意义在于如果你手里60%的客户是纯推理业务那迁移成本是可控的如果一半客户在做全参微调那你换卡之前得先招人或者把迁移成本摊到报价里。4.2 框架与算子库适配的实操清单真的动手的时候我建议按这个顺序推进每一步都有明确的验收动作不要跳步。第一步是环境确认。把驱动、固件、容器镜像、框架分支、通信库的版本全部固定下来写成一份清单后面所有问题都基于这份清单排查。版本混乱是排查困难的头号原因。# 环境快照迁移前务必存一份 ./toolchain/smi --query-gpuindex,name,firmware,driver --formatcsv env_gpu.csv python -c import torch; print(torch.__version__) env_sw.txt pip freeze | grep -iE vllm|transformers|deepspeed|xformers env_sw.txt第二步是算子覆盖度扫描。把客户模型跑一遍打开算子日志统计有多少算子落在了厂商优化库里有多少落到了通用实现。落到通用实现的比例超过15%就要重点关注性能了这些算子往往是性能瓶颈。第三步是精度对齐。用一组固定的输入做逐层对比误差阈值按客户的业务要求定。讲实话这一步最耗时间但绝对不能省。第四步是性能调优。这一步才开始做量化、批处理策略、KV Cache优化这些事情。顺序不要颠倒先保证对再保证快。第五步是灰度上线。先接5%的流量观察一周再逐步放大。灰度的价值不仅在于发现性能问题更在于发现那些低频但致命的稳定性问题。4.3 迁移过程中的两个隐性成本第一个隐性成本是两套并行。迁移期间同一份业务要在两个平台上各跑一遍做对拍这段时间的算力是双份的人力也是双份的。这个成本在很多预算表里是缺失的但它真实存在。我的做法是给每个迁移项目留出两周的重叠期预算明确写进项目计划。第二个隐性成本是人才。熟悉国产平台工具链的工程师在市场上比熟悉CUDA的少得多招人周期长薪资预期也不低。我的建议是不要指望招到现成的人而是在内部培养一两个骨干让厂商的技术支持带着做两三个项目之后就能独立处理了。这条路更慢但更稳而且培养出来的知识是留在团队里的。5. 商业决策什么时候该换、换多少、换哪部分前面全是技术和工程最后落到决策。租赁商不是技术爱好者我们换卡的唯一理由是这笔生意更赚钱或者至少能在某个细分市场里建立优势。我把我的决策框架完整写出来。5.1 单卡成本模型与报价区间先把账算清楚。我用一个简化的模型假设三年折旧、PUE 1.3、电价0.7元每度、机位和运维每月每卡摊500元。项目A型号8卡整机H100 8卡整机整机采购价假设约100万约260万单卡购置成本约12.5万约32.5万单卡月折旧36个月约3470元约9030元单卡月电费PUE 1.3满载约260元约460元机位与运维分摊约500元约500元单卡月度总成本约4230元约9990元市场月租区间约8000-10000元约20000-24000元单卡月毛利约3800-5800元约10000-14000元单看毛利H100每卡赚得多这是事实。但换一个角度看同样100万的采购预算买A型号能拿到8张卡买H100只能拿到3张卡还差一点。在客户需求是我要便宜的中小模型推理这个细分市场里8张A型号能同时服务8个客户3张H100只能服务3个而且报价还得压。这时候你要算的是每万元投资的月毛利计算示例A型号每万元投资月毛利约3800到5800除以12.5即304到464元H100约10000到14000除以32.5即308到431元。两者在每万元投资回报上基本打平但A型号的客户基数更大、单客户流失带来的损失更小。这个结论很有意思在中小模型推理这个细分市场两者的投资回报率是接近的选哪个取决于你的客户结构和风险偏好。如果你面对的是训练客户、大模型客户、对延迟敏感的高端客户H100的不可替代性很强如果你面对的是大量中小推理需求国产卡的现金流模型反而更健康。5.2 混合部署什么业务放国产卡什么业务留在原平台我最后落地的方案是混合部署比例大概是国产卡占推理资源池的六成H100集中在训练和高价值推理。具体分配规则如下业务类型建议载体理由中小模型在线推理7B-13B国产卡吞吐比例稳定成本优势明显离线批处理、数据清洗国产卡对延迟不敏感可以充分吃满吞吐内部业务、测试环境国产卡容错高可以用来积累经验长上下文、多模态推理谨慎先小规模验证算子覆盖度和延迟是风险点大模型高并发推理混合按客户合同分配延迟指标是分界线LoRA微调国产卡可承接改动量可控精度对齐后稳定全参微调、预训练保留在原平台通信线性度差距会直接反映到账单上这张表不是固定的每个季度我都重新评估一次因为软件栈的成熟度变化很快。上一年很多跑不通的东西这一年已经能跑了所以不要把一次测试的结论当成永久标签。5.3 客户侧的话术与合同条款这一块可能比技术更重要。客户对硬件的敏感度其实没有我们想象的高他在乎的是能不能按约定完成。所以我的做法是合同里不写具体硬件型号只写可交付的指标——吞吐下限、延迟上限、可用性、故障恢复时间。这样后续调优、换卡、扩缩容都不需要改合同。指标怎么定我的建议是按实测值的80%来承诺。比如实测7B模型32并发下吞吐1850 tok/s那合同里写1500 tok/s。留这20%的余量不是保守是给自己留出应对固件升级、负载波动、机房温度变化的空间。我见过太多因为承诺太满最后靠运维硬扛的团队扛不了几个月就会出问题。还有一个细节是灰度期条款。新客户第一次使用国产卡资源时我会在合同里加一个两到四周的灰度期期间按实际用量计费、不承诺硬性SLA双方都有退出的空间。这个条款保护的是双方客户更愿意尝试我也避免了被一单不可能完成的任务拖住。6. 常见问题与排查技巧实录最后把这一年多踩到的坑集中整理一份都是我实际遇到过并且解决过的问题你遇到类似现象可以直接对照。6.1 典型问题速查表现象可能原因排查与处理吞吐比预期低30%以上算子落到通用实现打开算子日志统计覆盖度重点看归一化和激活长序列输出质量下降注意力实现分块策略差异逐层对齐激活值确认长序列分支实现跑一段后突然卡顿数秒动态shape触发重复编译固定输入长度分桶减少shape变化连续运行48小时后吞吐下降显存碎片累积定期重启worker或调整显存分配策略同一型号不同机器性能差异大批次或固件差异逐台抽测把实测值写入调度权重跨机任务性能不达标RoCE链路配置或拥塞先测裸链路带宽再排查拥塞控制参数多卡训练扩展效率低通信占比过高调整并行策略优先用流水并行替代纯张量并行温度高触发降频机房局部热区检查进风温度调整机柜布局重新压测6.2 验收与交付的实操心得第一验收必须用客户的真实数据。我现在的标准流程是向客户要一份脱敏的真实请求样本至少一万条跑完整压测出一份带长度分布和延迟分位数的报告。这份报告既是验收依据也是后续出问题时的基线。第二延迟指标要看P99不要看平均值。平均值永远好看P99才会暴露问题。我有个客户对首token延迟特别敏感平均值1.2秒完全达标但P99到了4.5秒用户体验就是有时候要点两次。第三压测要覆盖故障场景。主动拔掉一张卡、模拟网卡抖动、把一台机器重启看业务系统的反应。这比任何纸面可用性数据都有说服力。第四把每次测试的完整环境快照存下来。环境不一样的数据没有可比性一年后你回头看那份报告没有版本信息就是一堆无用的数字。实操心得我在每个机柜里放了一台小机器专门跑监控采集不和业务机器混部避免业务满载时监控数据丢失。这个投入很小但每次出问题复盘的时候它是唯一可靠的信息源。我自己在实际推进这件事的过程中最大的体会是不要试图一次性把整个机房换掉也不要因为某一项测试数据不好就全盘否定。正确的做法是把业务按场景切成小块一块一块地迁每一块都跑完整流程跑通了就沉淀成标准操作手册跑不通就退回去等下一次软件版本更新。这一年多下来我手里的国产卡从最初的两台实验机变成了现在推理资源池的主力而整个过程中没有丢掉一个客户。真正的分界线从来不是硬件参数而是你愿不愿意花时间把测试和验收这套流程做扎实。