企业官网建设流程全解析

做算力租赁这行的，最近见面聊得最多的一句话就是：国产GPU到底能不能顶上来，我敢不敢把机柜里的H100换掉一部分？这话听着像技术问题，其实是道商业题。我自己前后跑过三轮测试，从单卡跑通模型，到8卡整机压72小时，再到拿真实业务流量做灰度，中间踩的坑足够写一本小册子。这篇文章就把这套流程完整摊开讲：国产GPU在哪些场景下已经可以交付给客户，在哪些场景下换过去就是给自己埋雷，算力租赁这门生意的账该怎么算，迁移工作量到底有多少人力。不管你是刚入行准备采购第一台机器的租赁商，还是手里已经有一批卡、正在纠结要不要混搭的技术负责人，都能从里面找到可以直接抄的测试方法和判断标准。我不会给你一个"能"或者"不能"的结论，因为这个问题本来就不该有统一答案，我只把决策需要的数据和坑点摆出来。

1. 换卡之前，先把这门生意的账本搞清楚

很多人讨论国产卡能不能替代，一上来就比纸面算力，这个思路从第一步就跑偏了。算力租赁卖的不是TFLOPS，卖的是"客户的任务能在约定时间内以约定成本跑完"这个承诺。同样一张卡，放在科研单位做小规模实验，和放在租赁机房里给几十个客户共享，评价标准完全是两回事。所以在动手测之前，我习惯先把账本拆成三层，每一层都会直接影响你最后换不换、换多少的判断。

1.1 算力租赁真正要算的三笔账

第一笔是采购账。整机含税价只是冰山一角，后面还跟着备件比例、保修年限、返修期间的算力损失。我见过有人只盯着单卡报价便宜三成，结果故障率高了以后，备件库里常年躺着三台机器在等维修，实际可用算力反而更少。第二笔是运营账，包含功耗、PUE、机位租金、运维人力分摊。这一笔在风冷机房里特别关键，因为功耗差异会被PUE放大，而且会直接吃掉你的电力配额——很多机房不是没钱买卡，是没电装卡。第三笔是交付账，也就是客户真正掏钱买的那个单位：每百万token多少钱，或者每张图多少钱，或者每个训练epoch多少小时。这三笔账任何一笔没算清楚，换卡的决策都是拍脑袋。

我自己的习惯是做一个单卡月度成本模型，把所有摊销项都塞进去，最后得出一个"每卡每月保本价"。这个数字才是你和客户谈判的底线，也是衡量换卡是否划算的唯一标尺。

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组网。两台机器都接在同一台交换机下，避免网络路径差异影响结果。软件层面，国产平台用的是厂商提供的容器镜像加适配过的推理框架分支，对照组用的是同版本的上游框架，尽量让软件变量可控。

关键参数先摆出来，方便你对照自己的候选清单：

这些数字是官方标称，我给的是区间，因为不同批次和不同固件版本实测差异不小。记住一点：标称值只用来判断"能不能上"，真正决定报价的是实测值。

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_s=72*3600, interval=30): 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, shell=True).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：

这组数字需要读得细一点。单卡低并发下，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卡的线性度。

这组数据说明两件事。第一，单机内部互联是硬差距，这个短期内靠软件优化很难弥补，因为它是物理链路决定的。第二，跨机场景下网络成了瓶颈，两台机器的表现非常接近，这意味着如果你的业务是跨机多副本推理（比如每个模型副本单机跑，副本之间只做负载均衡），国产卡和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生态迁到国产栈的迁移路径

迁移路径通常有三种，成本从低到高。第一种是框架层面已经支持，客户只需要换镜像、换个权重格式，业务代码一行不改。这种情况现在越来越常见，主流推理框架都有国产平台的适配分支，模型池里常见的开源模型基本都能直接跑。第二种是有一部分自定义算子或者特殊结构，需要重写算子或者换一个等价实现，工作量按算子数量算。第三种是深度耦合的，比如自研的训练框架、自定义的通信策略、特殊的内存管理，这种情况迁移成本可能超过收益，我会直接建议客户保留原平台。

这张表的意义在于，如果你手里60%的客户是纯推理业务，那迁移成本是可控的；如果一半客户在做全参微调，那你换卡之前得先招人或者把迁移成本摊到报价里。

4.2 框架与算子库适配的实操清单

真的动手的时候，我建议按这个顺序推进，每一步都有明确的验收动作，不要跳步。

第一步是环境确认。把驱动、固件、容器镜像、框架分支、通信库的版本全部固定下来，写成一份清单，后面所有问题都基于这份清单排查。版本混乱是排查困难的头号原因。

# 环境快照，迁移前务必存一份 ./toolchain/smi --query-gpu=index,name,firmware,driver --format=csv > 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元。

单看毛利，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集中在训练和高价值推理。具体分配规则如下：

这张表不是固定的，每个季度我都重新评估一次，因为软件栈的成熟度变化很快。上一年很多跑不通的东西，这一年已经能跑了，所以不要把一次测试的结论当成永久标签。

5.3 客户侧的话术与合同条款

这一块可能比技术更重要。客户对硬件的敏感度其实没有我们想象的高，他在乎的是能不能按约定完成。所以我的做法是：合同里不写具体硬件型号，只写可交付的指标——吞吐下限、延迟上限、可用性、故障恢复时间。这样后续调优、换卡、扩缩容都不需要改合同。

指标怎么定？我的建议是按实测值的80%来承诺。比如实测7B模型32并发下吞吐1850 tok/s，那合同里写1500 tok/s。留这20%的余量不是保守，是给自己留出应对固件升级、负载波动、机房温度变化的空间。我见过太多因为承诺太满，最后靠运维硬扛的团队，扛不了几个月就会出问题。

还有一个细节是灰度期条款。新客户第一次使用国产卡资源时，我会在合同里加一个两到四周的灰度期，期间按实际用量计费、不承诺硬性SLA，双方都有退出的空间。这个条款保护的是双方，客户更愿意尝试，我也避免了被一单不可能完成的任务拖住。

6. 常见问题与排查技巧实录

最后把这一年多踩到的坑集中整理一份，都是我实际遇到过并且解决过的问题，你遇到类似现象可以直接对照。

6.1 典型问题速查表

6.2 验收与交付的实操心得

第一，验收必须用客户的真实数据。我现在的标准流程是：向客户要一份脱敏的真实请求样本（至少一万条），跑完整压测，出一份带长度分布和延迟分位数的报告。这份报告既是验收依据，也是后续出问题时的基线。

第二，延迟指标要看P99，不要看平均值。平均值永远好看，P99才会暴露问题。我有个客户对首token延迟特别敏感，平均值1.2秒完全达标，但P99到了4.5秒，用户体验就是"有时候要点两次"。

第三，压测要覆盖故障场景。主动拔掉一张卡、模拟网卡抖动、把一台机器重启，看业务系统的反应。这比任何纸面可用性数据都有说服力。

第四，把每次测试的完整环境快照存下来。环境不一样的数据没有可比性，一年后你回头看那份报告，没有版本信息就是一堆无用的数字。

实操心得：我在每个机柜里放了一台小机器专门跑监控采集，不和业务机器混部，避免业务满载时监控数据丢失。这个投入很小，但每次出问题复盘的时候，它是唯一可靠的信息源。

我自己在实际推进这件事的过程中，最大的体会是：不要试图一次性把整个机房换掉，也不要因为某一项测试数据不好就全盘否定。正确的做法是把业务按场景切成小块，一块一块地迁，每一块都跑完整流程，跑通了就沉淀成标准操作手册，跑不通就退回去等下一次软件版本更新。这一年多下来，我手里的国产卡从最初的两台实验机，变成了现在推理资源池的主力，而整个过程中没有丢掉一个客户。真正的分界线从来不是硬件参数，而是你愿不愿意花时间把测试和验收这套流程做扎实。