企业官网建设流程全解析

1. 算力核心的认知重构：从图形渲染到智能计算的范式转移

1.1 为什么GPU成了AI时代的“天选之子”

很多人第一次接触AI芯片这个概念，脑子里蹦出来的第一个词就是GPU。这很正常，毕竟过去十年里，深度学习这波浪潮几乎就是踩着GPU的肩膀爬上来的。但如果你把时间拨回2006年，那时候的GPU还在老老实实给《魔兽世界》渲染多边形，跟“智能”两个字八竿子打不着。转折点出现在英伟达推出CUDA架构，把原本只能做图形流水线计算的显卡，改造成了通用并行计算平台。这个决策在当时看来有点不务正业，但正是这个“不务正业”，让GPU在十年后成了AI训练的唯一选择。

要理解GPU为什么适合AI计算，得先看AI计算到底在算什么。神经网络的本质是大规模矩阵乘法和卷积运算，这些运算有个共同特点：数据量大、计算模式统一、各计算单元之间没有复杂的依赖关系。说白了就是“人多力量大”的活，不需要每个工人都很聪明，但需要同时有几千个工人一起搬砖。CPU的设计哲学恰恰相反，它追求的是单核性能极致，核心数通常只有几十个，但每个核心都能处理复杂的逻辑分支和乱序执行。你让CPU去算矩阵乘法，就像让一个博士生去搬砖，他确实能搬，但效率远不如一队训练有素的搬运工。

GPU的流处理器架构就是为这种“搬砖”场景量身定做的。以一张典型的AI训练卡为例，它内部有数千个CUDA核心，每个核心虽然只能做简单的浮点运算，但胜在数量多、调度统一。当深度学习框架把矩阵运算拆解成成千上万个并行线程后，GPU可以在一个时钟周期内同时处理大量数据。这种架构带来的吞吐量提升是数量级的，不是百分之几十，而是几十倍甚至上百倍。

1.2 NPU的登场：专才与通才的分工逻辑

GPU虽然强大，但它有个天生的“包袱”：它得兼顾图形渲染。这意味着GPU的芯片面积里，有相当一部分电路是给纹理单元、光栅化单元、显示输出这些图形功能预留的。对于纯AI推理任务来说，这些电路就是纯粹的浪费。更关键的是，GPU的功耗大头都花在了数据搬运上，计算单元和显存之间的数据来回倒腾，能耗比并不理想。

NPU的设计思路就完全不同了。它把图形相关的电路全部砍掉，把省下来的芯片面积和功耗预算全部砸在矩阵乘法单元和卷积加速器上。典型的NPU内部会集成大量的MAC阵列，专门做乘加运算，同时配备大容量的片上缓存来减少数据搬运。这种设计让NPU在做AI推理时，能效比可以做到GPU的几倍甚至十几倍。你可以在手机、摄像头、智能音箱这些功耗敏感的设备里看到NPU的身影，它们不需要跑《赛博朋克2077》，只需要安安静静地做图像识别、语音唤醒、人脸检测这些专用任务。

这里有个常见的误解需要澄清：NPU并不是要取代GPU。在AI工作流里，训练阶段几乎清一色用GPU，因为训练需要高精度浮点运算和灵活的可编程性，GPU的通用性在这里是优势。而推理阶段，尤其是边缘侧推理，NPU的专用性优势就体现出来了。你可以把GPU理解成全能型选手，什么都能干但单项不是最快；NPU是专项运动员，只练一个项目但能破世界纪录。两者在算力生态里是互补关系，不是替代关系。

1.3 算力单位的迷思：TOPS、TFLOPS与真实性能的鸿沟

打开任何一款AI芯片的规格书，你都会看到TOPS或者TFLOPS这两个单位。TOPS是每秒万亿次整数运算，TFLOPS是每秒万亿次浮点运算。数字越大看起来越厉害，但这里面的水很深。首先，整数运算和浮点运算的精度不同，INT8的TOPS和FP16的TFLOPS不能直接比较。其次，厂商标称的峰值算力是在理想条件下测出来的，实际跑模型时，受限于内存带宽、数据搬运效率、算子优化程度，能发挥出峰值算力的百分之五六十就算不错了。

我见过太多人拿着TOPS数字去选芯片，结果发现实际推理速度跟纸面参数对不上。举个例子，某款芯片标称INT8算力是32TOPS，但它的内存带宽只有几十GB/s，跑大模型时数据喂不饱计算单元，实际吞吐量可能还不如一款标称16TOPS但带宽翻倍的芯片。所以在看算力参数时，一定要结合内存带宽、缓存大小、支持的算子类型综合判断。算力是上限，带宽是瓶颈，软件生态是天花板，三者缺一不可。

2. 深入GPU内部：架构细节与实操中的性能陷阱

2.1 从SM到Tensor Core：GPU计算单元的层级结构

要真正理解GPU的算力从哪来，得往下钻到流多处理器这个层级。以英伟达的架构为例，一个完整的GPU由多个SM组成，每个SM内部又包含多个CUDA核心、共享内存、寄存器文件、调度单元。当你在PyTorch里调用一个矩阵乘法时，框架会把运算拆解成线程块，分配到各个SM上执行。每个SM内部的调度器负责把线程束分配给CUDA核心，这个过程是硬件自动完成的，但你的代码写法会直接影响调度效率。

这里有个实操中很容易踩的坑：线程块大小设置不当会导致SM利用率低下。比如你设置线程块为32个线程，但SM的调度粒度是32的倍数，如果块太小，调度开销占比就高；块太大，又可能超出共享内存限制。经验值是在128到512之间调整，具体要看模型和GPU型号。我一般会先用256试，然后用性能分析工具看SM占用率，再微调。

Tensor Core是另一个需要重点理解的概念。从Volta架构开始，英伟达在SM内部集成了专门做矩阵乘加的Tensor Core单元。它可以在一个时钟周期内完成4x4矩阵的乘加运算，比用CUDA核心逐个算快得多。但Tensor Core对数据精度和矩阵维度有要求，比如FP16输入、FP32累加，矩阵维度需要是8的倍数。如果你的模型维度不满足这些条件，Tensor Core就发挥不出来，只能回退到CUDA核心。这也是为什么很多框架在训练前会把维度padding到8的倍数，就是为了喂饱Tensor Core。

2.2 显存带宽：那个比算力更致命的瓶颈

很多人选GPU只看算力，忽略了显存带宽。我可以用一个生活化的类比来解释：算力相当于厨师的切菜速度，显存带宽相当于食材从仓库到案板的传送带速度。如果传送带太慢，厨师切得再快也得等着。在AI计算里，数据搬运的能耗和时间往往超过计算本身。特别是大模型推理，模型参数动辄几十GB，每次前向传播都要把参数从显存读到计算单元，带宽不够的话，计算单元大部分时间都在空转。

实测数据很能说明问题。以某款主流训练卡为例，它的FP16算力是312TFLOPS，显存带宽是900GB/s左右。跑一个BERT-Large推理，理论计算时间远小于数据搬运时间，实际瓶颈在带宽上。如果你把同样的模型放到一款算力减半但带宽相同的卡上，推理延迟可能只增加百分之二三十，而不是翻倍。这就是带宽瓶颈的典型表现。

所以在实际选型时，我一般会先算一个比值：算力除以带宽。这个比值越高，说明计算单元越容易饿着。对于大模型推理场景，这个比值最好不要超过某个阈值，否则就得考虑用模型量化、算子融合、KV缓存这些手段来减少数据搬运。具体阈值因模型而异，但经验上，如果每TFLOPS算力对应的带宽低于3GB/s，就要警惕了。

2.3 多卡互联：NVLink与PCIe的实战选择

当单卡显存装不下模型时，就得考虑多卡。多卡方案有两个选择：走PCIe总线或者走NVLink。PCIe 4.0 x16的带宽是32GB/s，NVLink 3.0的带宽是600GB/s，差了将近20倍。这个差距在模型并行训练时是致命的。如果你用PCIe做张量并行，卡间通信会成为主要瓶颈，GPU利用率可能掉到百分之三四十。用NVLink的话，通信开销可以忽略不计，GPU利用率能维持在百分之八九十。

但NVLink不是没有代价的。它需要专门的桥接器，对主板和机箱有要求，成本也高。而且NVLink的拓扑结构有限制，不是所有卡都能两两直连。我踩过的坑是：买了四张支持NVLink的卡，结果发现只有相邻的两张能组成NVLink对，跨对通信还是得走PCIe。所以在规划多卡方案时，一定要先查清楚NVLink的拓扑图，别想当然地以为插上就能全互联。

对于推理场景，如果模型能塞进单卡，就别折腾多卡。多卡推理的通信开销和调度复杂度，往往会让吞吐量不升反降。只有在模型确实太大、单卡装不下的情况下，才考虑多卡推理，而且优先考虑流水线并行而不是张量并行，因为流水线并行的通信量小得多。

3. NPU实战解析：从手机到数据中心的专用算力

3.1 手机端NPU：功耗墙下的算力突围

手机里的NPU和GPU面临完全不同的约束条件。手机SoC的功耗预算通常只有几瓦，散热能力有限，电池容量也捉襟见肘。在这种条件下，GPU跑AI推理的能效比就很尴尬了。以某款旗舰手机为例，用GPU跑图像超分，功耗可能到3瓦，手机背面温度能到45度以上；换成NPU跑同样的任务，功耗不到1瓦，温度 barely 上到35度。这个差距直接决定了用户体验，一个是玩十分钟就烫手，一个是能连续跑半小时不降频。

手机NPU的架构通常是MAC阵列加专用缓存。MAC阵列的规模从几百个到几千个不等，取决于芯片定位。旗舰芯片的NPU算力能到几十TOPS，中端芯片可能只有几TOPS。但这里有个关键点：手机NPU的算力标称值往往是在INT8甚至INT4精度下测的，跑FP16模型时算力会打折扣。而且手机NPU的软件栈碎片化严重，高通、联发科、苹果各有各的API，开发者要针对不同平台做适配，工作量不小。

我在实际开发中的体会是：手机端AI功能优先用厂商提供的推理框架，比如高通的SNPE、联发科的NeuroPilot。这些框架对自家NPU的算子支持最全，性能调优也最到位。如果非要跨平台，可以考虑ONNX Runtime或者TFLite，但要做好性能损失的心理准备。另外，手机NPU对模型结构有偏好，卷积神经网络跑得飞快，但Transformer类模型在部分NPU上支持不好，可能需要回退到GPU或CPU。

3.2 数据中心NPU：推理专用芯片的崛起

数据中心侧的NPU，或者说AI加速卡，走的是另一条路线。它们不需要考虑电池续航，功耗可以放到几百瓦，但要求极高的吞吐量和极低的延迟。这类芯片通常砍掉了图形相关的一切，把面积全部留给矩阵计算单元和高速缓存。典型代表包括各类推理加速卡，它们在大规模推荐系统、视频分析、自然语言处理等场景里表现突出。

这类NPU的一个核心设计理念是“数据流架构”。传统GPU是指令流驱动，每条指令都要经过取指、译码、执行的流程，调度开销不小。数据流架构则是让数据在计算单元之间流动，计算单元在数据到达时自动触发运算，省去了指令调度的开销。这种架构在跑固定模型时效率极高，但灵活性差一些，模型结构变化大了可能就得重新编译。

在实际部署中，数据中心NPU的瓶颈往往不在芯片本身，而在软件栈和生态。GPU有CUDA这个护城河，积累了十几年的算子库和工具链，NPU厂商要追赶这个生态差距，难度非常大。我见过不少项目，芯片纸面参数很漂亮，但实际部署时发现某个关键算子不支持，或者精度对不齐，最后只能回退到GPU。所以选NPU时，一定要先验证你的模型能不能跑通，别只看参数。

3.3 边缘NPU：安防摄像头里的算力经济学

边缘侧的NPU应用，安防摄像头是最典型的场景。一个城市级安防项目可能涉及几万路摄像头，每路都要做人脸检测、车牌识别、行为分析。如果全部把视频流传回数据中心处理，带宽成本是天文数字。所以在摄像头端或者边缘盒子里放一颗NPU，就地完成推理，只把结构化结果传回去，这是更经济的方案。

边缘NPU的算力需求跟数据中心完全不同。它不需要跑大模型，通常就是几兆到几十兆参数的小模型，算力需求在几TOPS到十几TOPS之间。但它的功耗约束很严，很多边缘盒子是PoE供电，总功耗不能超过30瓦，留给NPU的预算可能就几瓦。而且边缘设备的工作环境恶劣，夏天暴晒、冬天严寒，芯片得能在零下40度到零上85度的范围里稳定工作。

我在边缘项目里踩过的坑是：低估了模型量化的难度。边缘NPU通常只支持INT8推理，但训练好的模型是FP32的，量化过程中精度损失如果控制不好，召回率能掉十几个百分点。后来我们摸索出一套流程：先用PTQ做训练后量化，如果精度不达标，再用QAT做量化感知训练，在训练时模拟量化误差，让模型提前适应。这套流程走下来，精度损失能控制在两个百分点以内。

4. 算力选型与部署的实战方法论

4.1 算力需求评估：从模型规模反推硬件配置

选芯片之前，先得算清楚自己的算力需求。这个账不能拍脑袋，得从模型规模、推理延迟要求、吞吐量目标三个维度反推。以一个大语言模型为例，假设模型有70亿参数，用FP16存储需要14GB显存。推理时，每个token的生成需要把全部参数读一遍，所以显存带宽决定了token生成速度的上限。如果带宽是900GB/s，理论最大速度是900除以14，约64 tokens每秒。这是单请求的延迟下限，实际还会受计算单元利用率影响。

如果要支持并发请求，就得考虑批处理。批处理能提高计算单元利用率，但会增加延迟。这里有个权衡：批大小越大，吞吐量越高，但单个请求的响应时间越长。对于在线服务，通常要在吞吐量和延迟之间找平衡点。我的经验是先用小批量测出延迟曲线，然后根据SLA要求确定最大批大小，再算需要的卡数。

对于训练场景，算力需求评估更复杂。除了前向传播，还有反向传播和参数更新，计算量大约是前向的三倍。而且训练通常需要FP32或BF16精度，对显存和带宽的要求更高。一个粗略的估算方法是：模型参数量乘以20，就是训练所需的显存字节数。比如10亿参数的模型，训练时大约需要20GB显存。这个估算包含了参数、梯度、优化器状态和中间激活值，实际可能因框架和优化策略有出入。

4.2 软件栈适配：CUDA、ROCm与厂商SDK的取舍

硬件选型定了之后，软件栈的适配就是下一个关卡。CUDA生态目前是绝对主流，PyTorch、TensorFlow这些框架对CUDA的支持最完善，算子库最全，社区资源也最丰富。如果你选英伟达的卡，软件栈这块基本不用太操心，装好驱动和CUDA Toolkit，框架就能跑。

但如果选其他厂商的芯片，就得做好折腾的准备。AMD的ROCm生态这几年进步很快，但跟CUDA比还是有差距，部分算子可能缺失或者性能不佳。国产NPU厂商通常提供自己的SDK和模型转换工具，你需要把训练好的模型转成厂商专用的格式，这个过程可能遇到算子不支持、精度对不齐、动态shape不支持等各种问题。

我的一般建议是：如果团队规模小、时间紧，优先选CUDA生态的卡，省下来的适配时间比省下的硬件成本更值钱。如果项目有国产化要求或者成本压力大，选NPU之前一定要做POC验证，把核心模型跑一遍，确认精度和性能达标再批量采购。POC阶段别怕麻烦，多测几个模型，把边界情况都覆盖到。

4.3 性能调优实战：从算子融合到显存复用

硬件和软件都就位后，性能调优是最后一道关卡。同样的模型和硬件，调优前后性能差两三倍是常有的事。最有效的优化手段是算子融合。深度学习框架默认是逐算子执行的，每个算子都要读写一次显存。如果把多个算子融合成一个，中间结果留在寄存器或共享内存里，就能省下大量显存带宽。TensorRT和TVM这类推理优化框架的核心价值就在于此。

另一个重要手段是显存复用。训练时，中间激活值占用的显存往往比参数还大。通过分析计算图，找出生命周期不重叠的张量，让它们复用同一块显存，能显著降低显存占用。PyTorch的显存分配器已经做了不少优化，但在大模型场景下，手动管理显存还是很有必要的。比如用梯度检查点技术，用计算换显存，把激活值占用的显存降下来。

还有一个容易被忽略的点是数据加载。如果数据加载速度跟不上计算速度，GPU就会饿着。我见过不少项目，GPU利用率只有百分之三四十，排查半天发现是数据加载的瓶颈。解决办法包括：用更快的存储、增加数据加载的进程数、做数据预处理缓存、用DALI这类GPU加速的数据加载库。这些手段组合起来，能把GPU利用率拉到百分之八九十。

5. 常见问题排查与避坑指南

5.1 驱动与环境配置的典型故障

GPU环境配置是新手最容易翻车的地方。最常见的问题是驱动版本和CUDA版本不匹配。比如你装了最新的驱动，但PyTorch编译时用的是旧版CUDA，运行时就会报错。解决办法是查PyTorch官方文档的版本对应表，严格按照推荐组合来装。我一般会用conda创建一个独立环境，把CUDA Toolkit和cuDNN都装在环境里，避免跟系统全局的版本冲突。

另一个高频问题是“GPU被物理移除”的报错。这个报错通常不是硬件真的坏了，而是驱动崩溃或者PCIe链路不稳定。可以先检查dmesg日志，看有没有PCIe错误。如果是驱动问题，重装驱动通常能解决。如果是链路问题，可能需要调整PCIe的速率或者更换插槽。还有个小概率情况是电源供电不足，高负载时GPU掉电，也会报这个错。

对于Windows用户，还有一个坑是WDDM模式下的显存管理。Windows的显卡驱动模型会把显存分页，导致GPU显存看起来比实际大，但实际可用量受限。跑大模型时容易OOM。解决办法是切换到TCC模式，但这需要专业卡支持，消费卡通常不行。所以Windows下跑大模型，显存要留足余量，别卡着上限用。

5.2 模型部署中的精度与性能权衡

模型部署时，精度和性能的权衡是绕不开的。FP32精度最高但速度最慢，FP16速度翻倍但精度略降，INT8速度再翻倍但精度损失更明显。怎么选取决于业务场景。人脸识别、自动驾驶这类对精度敏感的场景，建议用FP16甚至FP32。推荐系统、内容审核这类容错率高的场景，INT8完全够用。

量化过程中最常见的坑是校准集选择不当。PTQ需要一小批数据来统计激活值的分布，如果校准集跟实际数据分布差异大，量化后的精度会崩。我一般会从实际业务数据里随机采样几百到几千条，覆盖各种边界情况。校准集不是越多越好，关键是分布要匹配。另外，量化对某些层特别敏感，比如第一层和最后一层，这些层可以保留FP16精度，只量化中间层，能在精度和性能之间取得更好的平衡。

还有一个坑是动态shape支持。很多NPU和推理框架对动态shape支持不好，模型输入尺寸变化时就得重新编译，耗时很长。如果业务场景输入尺寸不固定，要么把输入padding到固定尺寸，要么选支持动态shape的硬件和框架。padding的方案简单但浪费算力，动态shape的方案高效但适配麻烦，得根据实际情况取舍。

5.3 多卡训练中的通信瓶颈与排查

多卡训练时，卡间通信是最大的性能杀手。NCCL是英伟达的集合通信库，它支持多种通信算法，会根据拓扑自动选择最优路径。但自动选择不一定最优，有时候需要手动调。比如在NVLink全互联的机器上，用Ring算法可能不如Tree算法快。可以通过设置环境变量来指定NCCL使用的算法和协议，实测下来能差百分之十几。

另一个常见问题是负载不均衡。数据并行时，如果各卡拿到的数据量不一样，快的卡要等慢的卡，整体速度被拖慢。解决办法是确保数据均匀切分，或者用动态负载均衡策略。模型并行时，各卡的计算量可能天然不均衡，比如Transformer的某些层计算量大，某些层计算量小。这时候可以用流水线并行，把不同层分配到不同卡上，让各卡的计算量尽量均衡。

排查通信瓶颈的工具主要是NCCL的调试日志和Nsight Systems。打开NCCL调试日志后，能看到每次通信的耗时和算法选择。如果发现某次通信特别慢，可以针对性优化。Nsight Systems能给出时间线视图，直观看到计算和通信的重叠情况。理想情况下，通信应该跟计算重叠起来，如果时间线上通信和计算是串行的，说明重叠没做好，需要调整代码或框架配置。

5.4 算力租用与自建的成本账

最后聊聊算力租用和自建的成本问题。租用GPU云服务的好处是灵活，按需付费，不用一次性投入大笔硬件采购费用。但长期来看，租用成本可能比自建高。我算过一笔账：一张高端训练卡自建成本大约几万块，按三年折旧，每月成本一千多。同款卡在云上租用，每月可能要三五千。如果使用率超过百分之三四十，自建就更划算。

但自建有自建的麻烦：机房、电力、散热、运维都得自己搞。一张三百瓦的卡，加上配套的服务器和散热，整机功耗可能到一千瓦。一个机柜放几台这样的服务器，电力改造和散热改造的费用不低。而且硬件更新换代快，今年买的卡明年可能就落后了，折旧压力大。所以我的建议是：短期项目、实验性项目优先租用；长期稳定的大规模训练，自建更划算。混合方案也可以考虑：核心业务自建，峰值需求租用。

租用的时候要注意隐藏成本。有些云服务商的标价看起来便宜，但存储、网络、数据传输都要额外收费。跑大规模训练时，数据读取和checkpoint写入的存储费用可能比GPU费用还高。另外，不同云服务商的GPU型号和互联方案不一样，多卡训练的性能差异可能很大。选之前最好先跑个benchmark，别只看价格。

6. 算力生态的未来变量与个人学习路径

6.1 异构计算：CPU、GPU、NPU的协同调度

未来的算力架构一定是异构的，CPU、GPU、NPU各司其职。CPU负责逻辑控制和标量运算，GPU负责大规模并行浮点运算，NPU负责专用推理加速。关键是怎么让它们协同工作，而不是各自为战。目前主流的方案是用统一的内存地址空间，让不同计算单元能直接访问彼此的内存，减少数据拷贝。苹果的M系列芯片在这方面做得比较激进，CPU和GPU共享统一内存，NPU也能直接访问，数据搬运开销很小。

在软件层面，异构调度需要框架的支持。比如OpenCL和SYCL这类跨平台框架，能让同一份代码在不同计算单元上运行。但跨平台框架的性能通常不如厂商原生方案，因为没法针对特定硬件做深度优化。所以实际项目中，往往是混合使用：核心算子用厂商原生库，外围逻辑用跨平台框架。这种混合方案增加了开发复杂度，但能兼顾性能和可移植性。

对于开发者来说，掌握异构编程的思路比掌握某个具体框架更重要。核心思路是：把任务拆解成适合不同计算单元的子任务，然后调度到对应的硬件上执行。比如图像预处理适合用GPU，推理适合用NPU，后处理适合用CPU。这种拆解和调度能力，是未来算力开发者的核心竞争力。

6.2 从入门到进阶：算力开发者的技能树

如果你想往算力开发方向发展，我建议按这个路径来学。第一步是打好并行计算的基础，理解线程、线程块、网格这些概念，知道怎么把串行算法改写成并行算法。CUDA是很好的入门平台，资料多、社区活跃，学好了再迁移到其他平台会容易很多。

第二步是深入理解深度学习框架的底层。PyTorch和TensorFlow的源码值得读一读，看看算子是怎么实现的，计算图是怎么优化的，显存是怎么管理的。这些知识在调优时非常有用。我见过不少开发者只会调API，遇到性能问题就束手无策，就是因为对底层机制不了解。

第三步是学性能分析工具。Nsight Systems、Nsight Compute、PyTorch Profiler这些工具能帮你定位瓶颈。性能调优的本质是找到瓶颈然后消除它，没有工具就是盲人摸象。我建议养成习惯，每写完一个模型就跑一遍profiler，看看时间花在哪了，有没有优化空间。

第四步是跟进硬件动态。AI芯片这个领域变化很快，每年都有新架构、新指令集、新加速器出来。保持学习的心态，看到新东西就想想它解决了什么问题，跟现有方案比有什么优劣。这种技术敏感度，比掌握某个具体工具更重要。

6.3 算力焦虑下的理性选择

最后说点实在的。现在网上到处是“算力焦虑”的贩卖，好像没有几千张卡就做不了AI。但实际情况是，大部分应用场景根本不需要那么大的算力。一个精心调优的小模型，在边缘NPU上跑，效果可能比一个没调优的大模型在数据中心GPU上跑还好。算力是工具，不是目的。关键是找到适合自己场景的算力配置，而不是盲目追求最大最强。

我个人的经验是：先用小算力验证想法，跑通了再考虑扩展。很多想法在小规模验证阶段就能发现问题，根本不需要上大集群。而且小规模验证的成本低、迭代快，试错效率高。等想法验证得差不多了，再根据实际需求配置算力，这样既省钱又省心。

另外，别忽视算法优化带来的算力节省。同样的任务，好的算法可能比差的算法省一个数量级的算力。模型剪枝、知识蒸馏、量化、算子融合，这些技术组合起来，能把算力需求降下来一大截。在算力有限的情况下，算法优化是性价比最高的投入。我见过太多团队一上来就堆硬件，结果模型本身效率很低，堆再多硬件也是浪费。先把算法和工程优化做到位，再考虑加算力，这个顺序不能反。