企业官网建设流程全解析

1. 算力数字的信任危机：为什么TOPS开始不够用了

如果你最近一年跟做AI芯片或推理部署的人聊过，大概率会听到一个共同的抱怨：标称算力越来越漂亮，实际跑起来却越来越让人心里没底。一颗芯片写着几百TOPS的INT8算力，纸面参数能把上一代产品甩开好几条街，但真把业务模型搬上去，吞吐量可能只比老产品高个百分之二三十，延迟甚至偶尔还会倒退。这种落差不是个例，而是整个行业正在经历的一次评判标准迁移。

TOPS，全称是每秒万亿次操作，本质上是一个理论峰值指标。它的计算方式很朴素：芯片里有多少个乘加单元，每个单元每个时钟周期能做多少次乘加，再乘以主频，最后除以一万亿。这个公式本身没问题，问题在于它描述的是一个理想状态——所有计算单元永远满载、数据永远及时到位、没有任何等待和空转。可真实的AI负载根本不是这样运转的。

我拿一个具体的场景来说明。假设你部署的是一个目标检测模型，输入分辨率是1080p，模型里有大量的卷积层、少量的全连接层，还有几个需要做非极大值抑制的后处理步骤。在纸面上，卷积部分确实能吃满算力，但卷积和卷积之间需要把特征图写回内存再读出来，后处理阶段更是几乎用不到矩阵计算单元。这些环节里，芯片的乘加阵列要么在等数据，要么干脆闲着。标称的几百TOPS，在这种负载下能发挥出三成就算不错了。

更麻烦的是，不同厂商对TOPS的统计口径并不统一。有的按稀疏化之后的等效算力标，有的按INT8标但实际业务跑的是INT4或者FP16，还有的把不同精度下的算力混在一起宣传。这就导致一个很尴尬的局面：你拿着两张标称算力相近的卡去做选型，实测下来差距可能大到让你怀疑是不是自己测错了。我见过一个团队，选型时按TOPS排了个序，结果实测发现排第一的那颗芯片在自家模型上跑不过排第三的，原因就是排第一的那颗芯片内存带宽成了瓶颈，算力根本喂不饱。

所以现在业内越来越多人开始说一句话：TOPS是给投资人看的，真实负载才是给工程师看的。这句话虽然有点绝对，但它点出了核心矛盾——算力峰值和实际有效算力之间，隔着一整套系统级的工程问题。这些问题包括内存带宽够不够、片上缓存怎么调度、算子库对模型结构的适配程度、多卡互联的通信开销，甚至包括驱动和编译器的成熟度。任何一个环节掉链子，标称算力都只是墙上的奖状。

那为什么这个标准迁移偏偏发生在现在？因为前几年AI芯片还处在“有没有”的阶段，大家先解决算力从无到有的问题，标称指标粗糙一点也能忍。但现在行业进入了“好不好用”的阶段，业务方开始算投入产出比，开始关心每瓦性能、每美元吞吐、部署周期和运维成本。这时候再拿一个理想状态下的峰值数字去说服人，已经不好使了。评判标准从峰值算力转向真实负载表现，本质上是从实验室思维转向产品思维。

2. 真实负载到底在考验芯片的哪些能力

2.1 内存带宽与计算单元的比例关系

真实负载第一个要过的关就是内存墙。你可以把计算单元想象成一个超级能吃的胃，内存带宽就是食道。胃再大，食道太细，进食速度就上不去。AI负载里大量的操作是访存密集型的，比如逐元素加法、归一化、激活函数，这些操作的计算量很小，但需要把数据从内存搬进搬出。如果芯片的算力/带宽比失衡，这些操作就会成为整个流水线的堵点。

一个粗略的经验法则是，对于主流的视觉类模型，每1TOPS算力大致需要配比4到8GB/s的内存带宽才能让计算单元保持较高利用率。对于Transformer类的大模型，这个比例还要更高，因为注意力机制里的键值缓存会带来大量随机访存。你在选型时如果只盯着TOPS看，很容易忽略这个比例，结果就是买回来一颗算力很强但带宽不足的芯片，跑什么模型都差一口气。

2.2 算子库对模型结构的覆盖度

第二个考验是算子库。芯片厂商提供的算子库不可能覆盖所有模型里用到的所有算子，总有一些冷门操作需要自己写或者等厂商更新。问题在于，一个模型里哪怕只有一个算子没有被高效实现，整个模型的性能就可能被拖垮。我遇到过最极端的情况是，一个模型里有个自定义的池化操作，厂商库里没有对应实现，编译器只能回退到CPU上跑，结果这一个算子占了整个推理时间的四成。

所以现在有经验的团队在做芯片评估时，会先把自己要部署的模型拆成算子列表，然后逐个去查厂商的算子库支持情况，重点看那些非标准算子、融合算子和动态形状算子。这个工作很琐碎，但能帮你避开很多坑。有些厂商会提供算子覆盖度报告，但你要注意看报告里的“支持”是什么含义——是原生高效支持，还是通过组合算子拼出来的，还是回退到通用计算单元。这三种情况的性能差距可能是数量级的。

2.3 批处理与并发场景下的调度效率

第三个考验是调度。真实业务很少一次只处理一条数据，通常要做批处理来提高吞吐，或者要同时处理多个请求来降低延迟。这时候芯片的调度能力就很重要了。有些芯片在单批单请求下表现很好，但一批量上去，性能不升反降，因为片上缓存不够用，批与批之间互相抢资源。还有些芯片在多模型并发时调度混乱，导致延迟抖动很大，这对在线服务来说是致命的。

评估调度效率的一个实用方法是做阶梯式压测：从batch size等于1开始，逐步增加到2、4、8、16，观察吞吐量和延迟的变化曲线。理想的曲线是吞吐量随batch size近似线性增长，延迟增长平缓。如果吞吐量很快到顶甚至下降，或者延迟急剧上升，说明调度或缓存存在瓶颈。这个测试不需要很复杂的工具，用厂商提供的推理框架加上一个简单的压测脚本就能做。

2.4 精度与量化策略的实际表现

第四个考验是精度。现在几乎所有的推理部署都会用量化来降低计算量和内存占用，常见的是INT8量化，更激进的会用到INT4。但量化不是免费的午餐，它可能带来精度损失，而且不同芯片对量化的支持程度差异很大。有的芯片对INT8的支持很成熟，量化后的精度损失可以控制在可接受范围内；有的芯片INT8算子实现粗糙，量化后精度掉得厉害，你不得不回退到FP16，算力优势就没了。

评估量化表现不能只看厂商给的精度报告，因为那些报告通常是在标准数据集上测的，跟你的业务数据分布可能差很远。正确的做法是拿你自己的校准数据集去做量化，然后在你的验证集上看精度变化。同时要关注量化后的性能提升是否达到预期——有些芯片量化后算力翻倍，但实际推理速度只快了百分之十几，因为瓶颈在访存而不是计算。

3. 从纸面参数到实测数据：一套可复用的评估方法

3.1 先明确业务场景的硬约束

在开始任何测试之前，先要把业务场景的硬约束列清楚。这些约束包括：延迟上限是多少毫秒，吞吐量最低要求是多少，精度底线在哪里，功耗和散热预算是多少，部署环境是数据中心还是边缘设备。这些约束决定了你评估芯片时的侧重点。比如在线推荐场景对延迟极其敏感，那你就不能只看吞吐量；边缘设备对功耗敏感，那每瓦性能就是核心指标。

我习惯把这些约束写成一个表格，每项指标标注是“硬性门槛”还是“优化目标”。硬性门槛是必须满足的，不满足直接淘汰；优化目标是在满足门槛的前提下尽量做好的。这样在后续测试中就不会被某个单项的漂亮数字带偏，始终围绕业务需求做判断。

3.2 构建贴近真实的测试负载

测试负载的构建是评估中最关键也最容易被敷衍的环节。很多团队直接拿厂商提供的基准测试脚本跑一遍就完事了，但那些脚本通常是为了展示芯片优势而设计的，跟你的真实业务负载可能相差甚远。正确的做法是从你的业务里抽取一个有代表性的模型，最好就是准备上线的那一个，然后用真实的数据分布去做推理测试。

如果业务里有多个模型，那就选一个主力模型加一两个典型辅助模型，组成一个测试集。测试数据不要用随机生成的，要用真实业务数据或者至少是分布接近的模拟数据。输入形状也要覆盖实际可能出现的各种情况，包括最小尺寸、最大尺寸和典型尺寸。这些准备工作看起来繁琐，但能让你拿到的数据真正有参考价值。

3.3 关键指标的测量与记录方式

测量环节有几个细节容易出错。第一是预热，芯片在冷启动和热稳定状态下的性能可能有明显差异，测试前要让芯片跑一段时间达到热稳定。第二是多次测量取统计值，不要只跑一次就下结论，至少跑十次取中位数和百分位值。第三是记录完整的延迟分布，不要只看平均延迟，P99延迟往往更能反映用户体验。

我通常会记录这样一组指标：不同batch size下的吞吐量、平均延迟、P50延迟、P99延迟、功耗、芯片利用率、内存带宽利用率。这些指标要同步记录，因为单独看任何一个都可能产生误判。比如吞吐量很高但P99延迟也很高，说明调度不够稳定；芯片利用率很低但吞吐量达标，说明还有优化空间。

3.4 横向对比时的公平性原则

如果你要对比多颗芯片，公平性是个大问题。首先软件栈要尽量对齐，用各自厂商推荐的推理框架和最优配置，不要一颗芯片用精心调优的配置，另一颗用默认配置。其次测试环境要一致，包括散热条件、电源质量、宿主机的其他负载。第三是测试脚本要相同，输入数据要相同，测量方法要相同。

还有一点容易被忽略：要给每颗芯片足够的调优时间。有些芯片上手快，默认配置就能跑出不错的结果；有些芯片需要仔细调优才能发挥实力。如果你给每颗芯片的时间不一样，对比结果就不可信。我的做法是给每颗芯片设定一个固定的调优预算，比如两天时间，在这两天里尽量把它调到最好状态，然后在这个状态下做对比。

4. 那些标称参数不会告诉你的坑

4.1 峰值算力的“含水量”从哪里来

标称算力的含水量主要来自三个地方。第一个是稀疏化，很多芯片会标一个稀疏算力，通常是稠密算力的两倍，但稀疏化需要模型本身有足够的稀疏性才能利用，而大多数业务模型并没有那么稀疏。第二个是精度混标，比如用INT4的算力去对标竞品INT8的算力，数字上好看很多，但INT4在实际业务中的可用性还有限。第三个是理想频率，标称算力是按最高睿频算的，但实际持续运行时芯片会降频，真实算力可能只有标称的七八成。

你在看厂商资料时，要特别留意算力数字后面跟着的小字注释。如果写着“稀疏”“峰值”“理论”这些词，就要在心里打个折扣。更靠谱的做法是直接问厂商要稠密算力、持续算力和实际业务场景下的实测数据。如果厂商支支吾吾拿不出来，那这个数字的水分可能不小。

4.2 编译器成熟度对开发效率的隐性影响

编译器成熟度是个隐性但极其重要的因素。一个成熟的编译器能把你的模型高效地映射到芯片上，自动做算子融合、内存复用、流水线调度。一个不成熟的编译器则可能生成一堆低效代码，让你不得不手工优化，开发周期成倍增加。我见过一个团队，选了一颗纸面参数很漂亮的芯片，结果编译器对动态形状支持很差，模型里所有动态维度都得改成静态的，改完精度还掉了，最后项目延期了好几个月。

评估编译器成熟度的一个方法是看它对主流框架的支持程度和更新频率。如果厂商能及时跟进主流框架的新版本，说明编译器团队在持续投入。另一个方法是拿一个结构稍微复杂一点的模型去编译，看编译时间、生成的代码质量和是否报错。如果编译一个标准模型都磕磕绊绊，那后续的开发体验可想而知。

4.3 多卡扩展时的通信开销陷阱

多卡扩展是另一个容易踩坑的地方。单卡性能好不代表多卡扩展效率高，卡间通信的开销可能吃掉大部分算力增益。有些芯片的互联带宽不足，多卡跑起来后通信成了瓶颈，加卡带来的吞吐提升远低于预期。还有些芯片的多卡编程模型不成熟，需要开发者手动管理通信和同步，开发难度大且容易出错。

评估多卡扩展效率的方法是做扩展性测试：从单卡开始，逐步增加到2卡、4卡、8卡，观察吞吐量的增长曲线。理想的曲线是接近线性的，如果增长很快放缓甚至下降，说明通信或调度存在瓶颈。这个测试要在真实的模型和batch size下做，因为不同模型对通信的需求差异很大。

4.4 长期运行下的稳定性与降频问题

长期运行稳定性是业务部署的底线，但恰恰是很多评估容易忽略的。实验室里跑几分钟的性能数据，跟数据中心里跑几个月的表现可能完全不同。芯片在持续高负载下会不会降频，驱动会不会偶发崩溃，内存会不会泄漏，这些都需要在评估阶段就纳入考察。

我的做法是在评估后期安排一个长稳测试，让芯片在典型负载下连续跑至少24小时，期间记录性能曲线、功耗曲线和错误日志。如果性能随时间明显下降，或者出现任何非预期错误，都要搞清楚原因。这个测试能帮你提前发现很多在短时间测试中暴露不出来的问题。

5. 评判标准迁移之后，选型思路该怎么调整

5.1 从“算力优先”转向“场景匹配优先”

评判标准变了，选型思路也要跟着变。以前大家习惯先按算力排序，再从高到低挑。现在更合理的做法是先明确场景需求，再去找最匹配的芯片。场景匹配包括算力够用、带宽匹配、算子覆盖、精度达标、功耗合适、软件栈成熟这几个维度。算力只是其中一个维度，而且往往不是最关键的维度。

举个例子，如果你部署的是一个小模型但要求极低延迟，那算力可能不是瓶颈，瓶颈在启动开销和调度延迟，你需要的是一颗调度轻快、小算力但低延迟的芯片。反过来，如果你做的是离线批量推理，对延迟不敏感但对吞吐量要求高，那就要优先看带宽和批处理效率。场景不同，最优解完全不同。

5.2 把软件栈成熟度纳入核心权重

软件栈成熟度应该被赋予更高的权重。一颗软件栈成熟的芯片，可能纸面算力不是最高的，但实际部署效率高、开发周期短、运维省心。一颗软件栈不成熟的芯片，纸面算力再高，也可能因为各种工程问题而无法发挥。在评估时，可以把软件栈成熟度拆成几个子项：框架支持度、算子覆盖度、编译器质量、文档完善度、社区活跃度、厂商支持响应速度。每个子项打分，最后加权。

我个人的经验是，对于需要快速上线的项目，软件栈成熟度的权重可以占到四成以上。对于研究性质的项目，可以适当降低这个权重，因为研究项目有更多时间做底层优化。但即便是研究项目，软件栈太差也会严重影响迭代速度。

5.3 小规模试点比大规模采购更划算

在正式大规模采购之前，先做小规模试点。试点规模不用大，几颗芯片加上一台服务器就够。试点的目的是在真实业务环境下验证芯片的表现，包括性能、精度、稳定性、开发效率。试点阶段要尽量模拟真实部署条件，包括数据流、并发模式、运维流程。试点跑通了，再考虑扩大规模。

试点的成本看起来是额外的，但它能帮你避免大规模采购后才发现不合适的巨大损失。我见过太多团队因为跳过试点直接大批量采购，结果发现芯片跟业务不匹配，要么硬着头皮用，要么折价处理，损失远超试点成本。试点还有一个好处是能帮你积累第一手的调优经验，这些经验在大规模部署时非常宝贵。

5.4 建立自己的内部基准测试集

长远来看，每个做AI部署的团队都应该建立自己的内部基准测试集。这个测试集包含你业务里最典型的几个模型、最真实的数据分布、最常用的batch size和并发模式。每次评估新芯片或者新版本软件栈，都用这个测试集跑一遍，记录结果。时间长了，你就有了一套自己的数据，选型时不再依赖厂商的宣传材料，而是靠自己的实测数据做判断。

这个测试集的维护需要一些投入，包括定期更新模型和数据、维护测试脚本、管理测试环境。但它的回报是长期的，能让你在芯片选型这件事上越来越有底气。而且这套测试集还能用于日常的性能监控和回归测试，一举多得。

6. 一个简化版的真实负载评估清单

如果你正准备做芯片评估，又不想搞得太复杂，可以参考下面这个简化清单。它不能覆盖所有情况，但能帮你抓住重点，避免在明显不合适的芯片上浪费太多时间。

这个清单里的每一项都需要实际测试来验证，不能只看厂商资料。测试的顺序建议从算力匹配和内存带宽开始，这两项如果不满足，后面的就不用测了。算子覆盖和量化支持可以并行做，软件栈和多卡扩展在初步筛选通过后再深入。稳定性和功耗散热放在最后，作为最终决策的参考。

7. 写在最后的一些个人体会

做了这么多年的推理部署和芯片评估，我最大的体会是：没有最好的芯片，只有最合适的芯片。同一颗芯片，在A团队手里是神器，在B团队手里可能是鸡肋，差别往往不在芯片本身，而在于团队对场景的理解和对软件栈的掌握程度。所以评估芯片这件事，本质上是在评估芯片和团队、和业务的匹配度。

另一个体会是，评估这件事没有捷径。你可以看很多评测报告，可以听很多厂商宣讲，但最终做决策的依据应该是你自己跑出来的数据。别人的数据可以参考，但不能替代你自己的测试。因为你的模型、你的数据、你的部署环境、你的团队能力，都是独一无二的变量，只有你自己的测试才能把这些变量都考虑进去。

最后一个建议是，把评估当成一个持续的过程，而不是一次性的任务。芯片在迭代，软件栈在更新，你的业务也在变化。今天合适的芯片，半年后可能就不合适了。保持对新技术和新方案的关注，定期用你的基准测试集去跑一跑，这样在需要做选型决策时，你手里始终有最新的数据。这件事做起来不难，难的是坚持。但坚持下来，回报是实实在在的。