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 EthernetRoCE或InfiniBand。这些变化的意义在于它们让单位面积的算力密度大幅提升。一个采用液冷和高密度机柜的智算中心在同样的建筑面积和供电条件下能承载的算力可能是传统数据中心的数倍。外界如果只数卡、不看机房自然会低估。我在参观某智算中心时注意到一个细节他们的机柜布局和供电走线是专门为高功率密度设计的每列机柜的供电和液冷管路都是独立回路。这种设计前期投入大但后期扩容和运维的弹性很好。这类工程细节才是算力真实产能的一部分。2.2 集群网络为什么是算力的一部分大模型训练不是单卡任务而是成千上万张卡协同。卡与卡之间的通信量极大网络一旦成为瓶颈再多的卡也白搭。这就是为什么集群网络必须被算进“算力”里。常见的集群网络方案有两类InfiniBand和RoCE。InfiniBand延迟低、带宽高但成本高、生态相对封闭RoCE基于以太网成本低、兼容性好但对网络配置和拥塞控制要求高。国内很多智算中心选择RoCE路线通过精细的PFCPriority Flow Control和ECNExplicit Congestion Notification配置来保证无损传输。这里有个容易被忽略的点网络拓扑。常见的拓扑有Fat-Tree、Spine-Leaf、Torus等。不同拓扑对通信模式的支持不同。比如All-Reduce这种集合通信在Fat-Tree上表现稳定但在Torus上可能需要更复杂的路由策略。选错拓扑集群效率会打折扣。2.3 路由与策略配置的实操细节在大型数据中心里BGPBorder Gateway Protocol常被用来做路由。但AI集群的网络需求和传统数据中心不同它更看重低延迟、无损、可预测。所以很多团队会在BGP之上叠加Segment Routing over IPv6SRv6策略来实现流量工程和路径控制。举个具体场景一个集群里有多个计算分区每个分区有独立的Spine-Leaf结构。跨分区的All-Reduce通信需要走特定路径避免拥塞。这时可以配置SRv6 Policy为不同的通信流指定不同的Segment ListSLIST。初始可以配置两条SLIST一条走低延迟路径一条走高带宽路径根据任务类型动态选择。配置时要注意单CPCandidate 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 常见问题速查表问题现象可能原因排查手段解决方向多卡训练扩展性差网络带宽不足或拓扑不合理检查网卡速率、NCCL配置、卡间拓扑优化网络配置调整拓扑显存溢出批量或序列过大、碎片化、KV Cache增长查看显存占用曲线检查批量配置降低批量用梯度检查点限制序列长度异构卡任务失败算子不支持、精度不匹配、版本冲突查看错误日志检查算子支持列表换算子调度到匹配卡统一版本推理延迟高批处理策略差、KV Cache未优化检查批处理配置查看KV Cache占用用连续批处理PagedAttention微调不收敛学习率不当、批量太小、数据问题检查学习率、批量、数据分布调整学习率用梯度累积清洗数据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 最后分享一个小技巧如果你也在做推理优化可以试试动态批处理加优先级队列。把请求按优先级分队列高优先级队列优先处理低优先级队列在空闲时处理。同时用连续批处理让新请求随时加入。这样既能保证关键请求的延迟又能提升整体吞吐。我在几个项目里用这个组合效果不错卡利用率提升了延迟也没恶化。