企业官网建设流程全解析

1. 算力认知偏差的由来与核心判断

1.1 一个被反复提起的误判

过去两年，围绕中国AI算力的讨论里，有一种声音始终存在：高端芯片获取受限，算力总量必然被拉开差距，大模型训练和推理会被卡住脖子。这个判断在海外媒体和部分行业分析里被反复引用，甚至成了一种默认前提。但如果真正深入到国内数据中心、智算中心和一线AI工程团队里去看，会发现这个前提本身就站不住脚——它把“算力”简单等同于“某一种高端加速卡的绝对数量”，忽略了算力是一个由硬件、网络、调度、软件栈、能源和工程能力共同构成的系统。

我在过去一年多的时间里，接触过不少做智算中心规划、大模型微调和推理服务部署的团队。一个很直观的感受是：外界对中国AI算力的低估，不是低估了某一款芯片，而是低估了整个体系在约束条件下把算力“用出来”的能力。这个能力体现在很多细节里，比如集群网络怎么设计、异构卡怎么统一调度、推理怎么压成本、微调怎么在有限资源下跑出效果。这些东西不上头条，但它们决定了算力的真实可用量。

1.2 算力不等于加速卡数量

先把一个基础概念说清楚。算力（Computing Power）在AI语境下，通常指单位时间内可完成的浮点运算次数，常见单位是TFLOPS、PFLOPS。但一块卡标称的算力，和它在真实任务里能贡献的算力，中间隔着好几层损耗。

第一层是利用率。一块卡在跑矩阵乘法时能接近峰值，但在跑注意力机制、数据搬运、通信等待时，实际利用率可能只有标称值的30%到60%。第二层是集群效率。单卡再强，如果网络带宽不够、通信拓扑不合理，多卡扩展的线性度会迅速下降。第三层是任务匹配度。训练和推理对算力的需求完全不同，推理更看重显存带宽和延迟，训练更看重互联和吞吐。

所以，当有人拿“某类卡的数量”来推算中国AI算力总量时，结论天然是偏低的。真正该看的是：这些卡有没有被组织成高效集群，有没有配套的调度和软件栈，有没有足够的电力和散热支撑它们持续跑满。

1.3 被低估的三个维度

我把这种低估归纳为三个维度。

第一个维度是异构算力的整合能力。国内很多智算中心并不是清一色的同款卡，而是多种加速卡混布。这在外界看来是“无奈之举”，但实际工程中，通过统一的资源抽象层和调度器，异构集群可以承担相当规模的训练和推理任务。关键在于调度层能不能把任务拆解、分发、回收做好。

第二个维度是推理侧的优化空间。大模型落地的大头在推理，而推理算力的弹性非常大。量化、蒸馏、KV Cache优化、连续批处理（continuous batching）、投机解码，这些手段能把同样的硬件吞吐提升数倍。很多团队在推理优化上投入的精力，远比单纯堆卡更划算。

第三个维度是能源与数据中心的配套。算力最终要落到电上。国内在数据中心建设、绿电配套、液冷散热上的推进速度，实际上为算力持续扩张提供了底座。这一点经常被忽略，但它决定了算力能不能“持续在线”。

2. 数据中心与集群网络：算力被低估的物理底座

2.1 智算中心的真实形态

很多人想象中的AI数据中心，是一排排整齐的同款服务器。实际去现场看，尤其是国内近两年新建的智算中心，形态要复杂得多。机柜功率密度从传统的6到8千瓦，提升到20千瓦甚至更高；散热从风冷转向冷板式液冷或浸没式液冷；网络从普通以太网转向RDMA over Converged Ethernet（RoCE）或InfiniBand。

这些变化的意义在于：它们让单位面积的算力密度大幅提升。一个采用液冷和高密度机柜的智算中心，在同样的建筑面积和供电条件下，能承载的算力可能是传统数据中心的数倍。外界如果只数卡、不看机房，自然会低估。

我在参观某智算中心时注意到一个细节：他们的机柜布局和供电走线是专门为高功率密度设计的，每列机柜的供电和液冷管路都是独立回路。这种设计前期投入大，但后期扩容和运维的弹性很好。这类工程细节，才是算力真实产能的一部分。

2.2 集群网络为什么是算力的一部分

大模型训练不是单卡任务，而是成千上万张卡协同。卡与卡之间的通信量极大，网络一旦成为瓶颈，再多的卡也白搭。这就是为什么集群网络必须被算进“算力”里。

常见的集群网络方案有两类：InfiniBand和RoCE。InfiniBand延迟低、带宽高，但成本高、生态相对封闭；RoCE基于以太网，成本低、兼容性好，但对网络配置和拥塞控制要求高。国内很多智算中心选择RoCE路线，通过精细的PFC（Priority Flow Control）和ECN（Explicit Congestion Notification）配置来保证无损传输。

这里有个容易被忽略的点：网络拓扑。常见的拓扑有Fat-Tree、Spine-Leaf、Torus等。不同拓扑对通信模式的支持不同。比如，All-Reduce这种集合通信，在Fat-Tree上表现稳定，但在Torus上可能需要更复杂的路由策略。选错拓扑，集群效率会打折扣。

2.3 路由与策略配置的实操细节

在大型数据中心里，BGP（Border Gateway Protocol）常被用来做路由。但AI集群的网络需求和传统数据中心不同：它更看重低延迟、无损、可预测。所以，很多团队会在BGP之上叠加Segment Routing over IPv6（SRv6）策略，来实现流量工程和路径控制。

举个具体场景：一个集群里有多个计算分区，每个分区有独立的Spine-Leaf结构。跨分区的All-Reduce通信需要走特定路径，避免拥塞。这时可以配置SRv6 Policy，为不同的通信流指定不同的Segment List（SLIST）。初始可以配置两条SLIST，一条走低延迟路径，一条走高带宽路径，根据任务类型动态选择。

配置时要注意：单CP（Candidate Path）多SLIST的场景下，需要明确优先级和权重。如果两条SLIST的带宽和延迟差异大，权重设置不合理会导致流量倾斜。我见过一个案例，因为权重没调好，一条路径被打满，另一条闲置，整体通信效率反而下降。后来通过调整权重和引入动态探测，才把两条路径的利用率拉平。

提示：SRv6 Policy的配置不是一劳永逸的。集群扩容、任务模式变化后，SLIST的权重和路径需要重新评估。建议定期做通信矩阵分析，根据实际流量调整策略。

3. 异构算力调度：把不同卡用出合力

3.1 异构集群的现实与价值

国内很多智算中心不是单一品牌的卡，而是多种加速卡混布。这在外界看来是“拼凑”，但实际运行中，异构集群有它的价值。不同卡在显存容量、算力精度、互联带宽上各有侧重，适合不同类型的任务。比如，有的卡适合大显存推理，有的卡适合高吞吐训练，有的卡适合低精度量化推理。

关键在于调度层能不能把任务和卡匹配好。这就需要一个统一的资源抽象层，把不同卡的算力、显存、互联能力抽象成统一的资源池，然后由调度器根据任务需求分配。

常见的调度框架有Kubernetes加上设备插件（Device Plugin），再配合Volcano、Slurm等批处理调度器。设备插件负责把卡的资源暴露给Kubernetes，调度器负责把Pod分配到合适的节点。对于异构卡，还需要在设备插件层面做资源标签，比如gpu-type: A、gpu-type: B，调度时通过nodeSelector或affinity来匹配。

3.2 调度策略的取舍

调度策略的设计，核心是在“利用率”和“任务成功率”之间找平衡。如果一味追求高利用率，把任务塞满所有卡，可能会导致某些任务因为资源争抢而失败或超时。如果过于保守，又会让算力闲置。

我比较推荐的做法是分层调度。第一层是资源预留，给关键任务预留一定比例的算力，保证它们随时能跑。第二层是弹性调度，把剩余算力分配给可中断的任务，比如离线推理、数据预处理。第三层是抢占式调度，当高优先级任务到来时，可以抢占低优先级任务的资源，但要做好检查点（checkpoint）保存，避免任务从头开始。

这里有个实操心得：抢占式调度一定要配合任务的可恢复性设计。如果任务不支持断点续跑，抢占就等于重跑，反而浪费算力。所以，在任务提交时，最好要求带上检查点机制，或者至少把任务拆成可独立运行的片段。

3.3 显存与算力的匹配计算

异构调度里，一个常见的坑是显存和算力不匹配。比如，把一个大模型推理任务调度到显存足够但算力较弱的卡上，结果显存够用但延迟很高；或者调度到算力强但显存小的卡上，模型加载不进去。

所以，调度前需要做资源需求估算。以推理为例，一个70亿参数（7B）的模型，如果用FP16精度，权重大约需要14GB显存；加上KV Cache和中间激活，实际需要20GB以上。如果卡只有16GB显存，就必须做量化或者模型切分。

量化的选择也有讲究。INT8量化能把显存占用降到FP16的一半左右，但精度损失需要评估。INT4量化更激进，显存占用进一步降低，但对某些任务精度影响较大。实际选型时，建议先在目标卡上做小规模测试，看精度和延迟是否满足要求，再决定量化方案。

注意：异构集群里，不同卡对量化的支持程度不同。有的卡对INT8有硬件加速，有的没有。调度时要把量化方案和卡的能力匹配起来，否则可能跑得比FP16还慢。

4. 大模型微调与推理：在约束下把算力用出效果

4.1 微调的算力账怎么算

大模型微调是算力消耗的大头之一。全参数微调（Full Fine-tuning）需要保存优化器状态、梯度、激活值，显存占用通常是模型权重的数倍。以一个7B模型为例，FP16全参数微调可能需要80GB以上的显存，单卡很难放下，必须用数据并行、模型并行或流水线并行。

但实际业务中，很多场景并不需要全参数微调。参数高效微调（PEFT）方法，比如LoRA、QLoRA，能在只训练少量参数的情况下达到接近全参数微调的效果。LoRA通过在权重矩阵旁路添加低秩矩阵，把可训练参数量降到原来的百分之几甚至千分之几。QLoRA进一步把基础模型量化到4-bit，进一步降低显存需求。

我实测过，一个7B模型用QLoRA在单张24GB显存的卡上就能微调，虽然速度比全参数微调慢，但显存门槛大幅降低。对于算力受限的团队，这是很实用的路径。

4.2 微调实战中的资源配置

微调时的资源配置，核心是平衡批量大小（batch size）、序列长度（sequence length）和梯度累积（gradient accumulation）。批量大小影响训练稳定性和吞吐，序列长度影响显存占用，梯度累积可以在小批量下模拟大批量效果。

具体怎么调？我的经验是：先确定显存上限，然后从较小的批量大小和序列长度开始，逐步增加，直到显存接近打满但不出错。如果批量大小上不去，就用梯度累积来补。比如，目标批量大小是64，但单卡只能放8，那就设置梯度累积步数为8。

学习率也要相应调整。批量大小变化后，学习率通常需要按比例缩放。一个常用的经验法则是：批量大小翻倍，学习率也翻倍，但上限要控制，避免训练发散。

4.3 推理优化的几个关键手段

推理是算力消耗的持续大头。一个线上服务，如果推理优化没做好，算力成本会高得离谱。常见的优化手段有几种。

量化是最直接的。把FP16模型量化到INT8，显存占用减半，吞吐通常能提升1.5到2倍。INT4量化更激进，但精度损失需要评估。

**连续批处理（continuous batching）**是提升吞吐的关键。传统批处理要等一个批次的所有请求都完成才能开始下一批，连续批处理则允许新请求随时加入，已完成请求随时退出，大幅提升卡利用率。vLLM、TensorRT-LLM等框架都支持这个特性。

KV Cache优化也很重要。KV Cache占用显存很大，尤其是长序列场景。通过PagedAttention等技术，可以把KV Cache分页管理，减少碎片，提升显存利用率。

**投机解码（speculative decoding）**用一个小模型来预测大模型的输出，然后大模型并行验证，能在不损失精度的情况下提升解码速度。这个手段在延迟敏感的场景下很有价值。

4.4 微调与推理的算力分配

一个实际问题是：微调和推理抢算力。微调任务通常需要长时间占用大量算力，推理任务则需要低延迟、高可用。如果混在一起，推理的延迟会被微调任务拖累。

我的建议是物理隔离或逻辑隔离。物理隔离是把微调和推理放在不同的卡或不同的节点上。逻辑隔离是通过调度器的优先级和资源配额来隔离。比如，给推理任务设置高优先级和资源下限，给微调任务设置低优先级和资源上限。这样，推理任务随时能拿到资源，微调任务在空闲时跑。

如果资源实在紧张，可以考虑错峰。微调任务安排在业务低峰期跑，推理任务在高峰期优先。这需要调度器支持时间窗口配置。

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

5.1 集群通信效率低怎么排查

集群通信效率低，表现是训练速度上不去，多卡扩展线性度差。排查思路可以分几步。

先看网络带宽。用ibstat或ethtool查看网卡速率和状态，确认是否跑在预期速率上。如果速率不对，检查线缆、光模块、交换机端口配置。

再看通信库配置。NCCL是常用的通信库，它的配置对性能影响很大。检查NCCL_IB_HCA、NCCL_SOCKET_IFNAME等环境变量是否正确。如果用了RoCE，还要检查NCCL_IB_GID_INDEX是否匹配。

然后看拓扑。用nvidia-smi topo -m查看卡间互联拓扑，确认是否走了NVLink或PCIe。如果卡间通信走了PCIe而不是NVLink，带宽会差很多。

最后看拥塞。如果网络有拥塞，PFC和ECN的配置就很重要。检查交换机的PFC配置是否和网卡一致，ECN的阈值是否合理。ECN阈值设得太低会导致过度降速，设得太高又起不到拥塞控制作用。

5.2 显存溢出（OOM）的常见原因

显存溢出是微调和推理中最常见的问题。原因通常有几类。

批量大小或序列长度太大。这是最直接的。降低批量大小或序列长度，或者用梯度累积来模拟大批量。

碎片化。长时间运行后，显存碎片会导致明明有足够空闲显存却分配失败。解决办法是定期重启任务，或者用支持显存池化的框架。

KV Cache增长。推理时，KV Cache随序列长度增长。如果并发请求多、序列长，KV Cache会迅速吃满显存。解决办法是限制最大序列长度，或者用PagedAttention管理KV Cache。

中间激活值。训练时，中间激活值占用显存很大。可以用梯度检查点（gradient checkpointing）来用计算换显存，把激活值重新计算而不是全部保存。

5.3 异构卡任务失败的排查

异构卡任务失败，常见原因是算子不支持或精度不匹配。不同卡对算子的支持程度不同，有的卡不支持某些自定义算子，有的卡对某些精度的支持有限。

排查时，先看错误日志。如果是算子不支持，日志里通常会有“not implemented”或“unsupported”字样。这时需要换算子实现，或者把任务调度到支持该算子的卡上。

如果是精度问题，表现是结果不对或训练不收敛。这时要检查卡的精度支持，比如是否支持TF32、BF16。如果不支持，就要降级到FP16或FP32。

还有一个坑是驱动和框架版本不匹配。异构卡往往需要不同版本的驱动和框架，如果版本混用，可能出现各种奇怪问题。建议在调度层做版本标签，把任务调度到版本匹配的节点上。

5.4 常见问题速查表

5.5 几个踩过的坑

第一个坑是过度追求高利用率。有段时间，我们把集群利用率拉到90%以上，结果任务排队时间变长，关键任务经常超时。后来把利用率控制在75%到80%，留出缓冲，整体任务成功率反而提升。

第二个坑是忽略数据加载瓶颈。训练时，如果数据加载跟不上，卡会空转。用nvidia-smi看利用率，如果忽高忽低，很可能是数据加载问题。解决办法是用更快的存储、预取数据、增加数据加载进程。

第三个坑是量化后没做精度回归。有一次把推理模型量化到INT8，吞吐上去了，但某些长尾case的精度下降明显。后来加了精度回归测试，确保量化后关键指标不下降。

6. 算力约束下的工程取舍

6.1 训练与推理的资源分配策略

在算力有限的情况下，训练和推理怎么分配资源，是个需要仔细权衡的问题。我的经验是：推理优先保底，训练弹性扩展。

推理是线上服务，延迟和可用性直接影响用户体验和业务收入，所以必须保底。给推理分配固定的资源池，保证高峰期也能扛住。训练是长期投入，可以弹性使用剩余资源，在业务低峰期多跑，高峰期少跑或暂停。

具体操作上，可以用Kubernetes的资源配额（ResourceQuota）和优先级（PriorityClass）来实现。推理任务用高优先级，训练任务用低优先级。当资源紧张时，调度器优先满足推理，训练任务排队或抢占。

6.2 模型选择与算力匹配

不是所有场景都需要最大的模型。模型选择和算力匹配，是控制成本的关键。

对于简单任务，比如文本分类、意图识别，小模型（1B以下）就够用，推理成本低，延迟也低。对于复杂任务，比如长文本生成、多轮对话，可能需要7B到13B的模型。对于最复杂的任务，比如复杂推理、代码生成，才需要更大的模型。

选择模型时，先明确任务需求，再评估算力预算。如果算力有限，优先考虑小模型加微调，而不是直接上大模型。小模型微调后，在很多垂直场景下能达到接近大模型的效果，但成本低得多。

6.3 算力租赁与自建的取舍

算力来源有两种：自建和租赁。自建前期投入大，但长期成本低，可控性强。租赁灵活，前期投入小，但长期成本高，且受供应商影响。

我的建议是：核心业务自建，弹性需求租赁。核心业务的算力需求稳定，自建能保证可控性和成本优势。弹性需求，比如临时的大规模训练、突发的推理高峰，用租赁来补，避免自建资源闲置。

租赁时要注意几点：一是网络带宽和延迟，尤其是跨节点通信；二是数据安全，敏感数据要评估是否适合放在租赁环境；三是供应商的稳定性，避免服务中断。

6.4 软件栈的优化空间

软件栈的优化，往往能带来意想不到的算力提升。同样的硬件，软件栈优化后，吞吐可能提升30%以上。

几个方向：算子融合，把多个小算子合并成一个大算子，减少内核启动开销和显存访问。内存池化，预分配显存池，减少分配释放开销。图优化，把计算图做常量折叠、死代码消除、布局优化。编译优化，用TVM、TensorRT等编译器把模型编译成针对特定硬件优化的代码。

这些优化需要一定的工程投入，但回报通常很高。尤其是推理场景，软件栈优化能直接降低单位请求的算力成本。

7. 个人实操体会

7.1 算力不是唯一变量

做了这么多项目，我越来越觉得，算力只是AI能力的一个变量，而且不是唯一变量。数据质量、算法设计、工程能力、场景理解，这些都能显著影响最终效果。有时候，一个精心设计的小模型，加上高质量的数据和针对性的微调，效果能超过一个粗糙的大模型。

所以，与其纠结算力总量，不如把精力放在怎么把现有算力用出效果上。优化推理、做好微调、调好调度，这些工作的回报，往往比单纯堆卡更直接。

7.2 工程细节决定成败

AI落地到最后，拼的是工程细节。网络配置、显存管理、调度策略、量化精度，这些看起来琐碎的东西，决定了算力能不能真正转化为业务价值。

我见过太多团队，卡买了不少，但因为网络没调好、调度没做好、推理没优化，实际算力利用率很低。也见过一些团队，卡不多，但每个环节都抠得很细，整体效果反而更好。

7.3 持续迭代比一次性规划更重要

算力规划不是一次性的。业务在变，模型在变，硬件在变，规划也要跟着变。建议定期做算力审计，看利用率、看瓶颈、看成本，然后针对性优化。

不要指望一次规划就能管很久。小步快跑，持续迭代，比一次性大规划更靠谱。每次优化一点，积累下来就是很大的提升。

7.4 最后分享一个小技巧

如果你也在做推理优化，可以试试动态批处理加优先级队列。把请求按优先级分队列，高优先级队列优先处理，低优先级队列在空闲时处理。同时用连续批处理，让新请求随时加入。这样既能保证关键请求的延迟，又能提升整体吞吐。我在几个项目里用这个组合，效果不错，卡利用率提升了，延迟也没恶化。