企业官网建设流程全解析

前阵子给一台户外巡检车配算力板卡，本来觉得手到擒来，结果接二连三的踩坑：标称100 TOPS 的主控在30℃室外跑满负载直接烫到降频，跑模型时内存带宽卡脖子，最后换了两版散热、重排了电源纹波才勉强稳住。这篇文章就是我这次端侧AI算力选型的完整记录，会把这个领域里面“参数之外”的经验尽量讲透。

所谓端侧AI算力，简单说就是让AI推理不依赖云端服务器，直接在机器人、车、飞机这类移动设备上完成。具身智能（能感知、能决策、能行动的智能体）更是离不开这个能力——机械臂要实时识别抓取物、巡检车要随时避障、无人机要在线定位，所有计算都必须在毫秒级内完成。选错芯片，轻则模型跑不起来，重则设备死机返厂。这篇指南不只是罗列芯片型号，而是把算力评估方法、散热功耗实测、接口集成细节、常见故障排查全部串起来，适合正在做机器人、自动驾驶、边缘计算产品选型的工程师，也适合刚入门想少走弯路的学生和爱好者。

1. 项目概述与需求拆解

1.1 这个项目到底在解决什么问题

我们这个项目的本体是一台四轮巡检车，上面挂了一套六轴机械臂，外加双目视觉、一枚激光雷达和若干超声波传感器。它的工作场景是工业园区和半结构化道路，任务包括自主巡线、障碍物识别与避让、目标抓取。整套系统对算力的要求非常典型：视觉感知要实时出检测框和深度信息，机械臂规划要快速解算逆运动学，导航模块要维护局部地图，全部跑在端侧，不允许有高延迟。

一开始我的思路很简单：买一块算力最高的板卡，全堆上去。后来发现完全不是这么回事。算力只是第一步，还要考虑整机的功耗预算（电池容量有限）、散热能力（机箱密闭还是开放）、外设接口（相机是MIPI还是USB，雷达是网口还是串口）、以及工具链是否支持手里的模型格式。如果这些问题不在选型阶段想清楚，后面每一步都在还债。

1.2 车载与机载环境的硬约束

车载和机载跟桌面端最大的区别在于环境约束。第一个是供电。车辆电源系统在启动、制动时电压波动很大，电机的启停会产生明显的纹波，算力板卡对电源质量非常敏感，稍不注意就会触发欠压保护或者随机重启。第二个是温度。设备舱如果不开空调，夏日暴晒后内部温度可以轻松到50℃以上，散热设计必须按照这个极端值去校核，而不是用实验室25℃的数据自欺欺人。第三个是振动。机械臂运动和车辆颠簸带来的持续振动，会让松动的接口、没固定的SSD、甚至散热器产生接触不良，这些问题在静止测试时完全不会暴露。第四个是长时间运行的稳定性，工业场景通常要求7x24小时，不是跑几分钟demo就完事。

这些约束会把选型范围大幅收窄。很多做桌面开发时好用的板卡，一上车就原形毕露。

1.3 选型前的三条铁律

我把自己这次踩坑的教训总结成三条铁律，放在最前面。

第一条，先做算力需求评估，再去看芯片参数。把要跑的模型、分辨率、帧率全部列出来，用后面第2章的方法算出一个大概的TOPS区间，再去看芯片，而不是反过来。

第二条，算力数字必须问清楚是什么精度、什么模式算出来的。同样一颗芯片，FP16和INT8的TOPS可能差一倍以上，稀疏化和剪枝后的理论峰值跟实际能跑到的数字更是两回事。厂商标的TOPS绝大多数是INT8稠密峰值，实际部署效率要打折扣。

第三条，盯紧散热和功耗的闭环。端侧设备能散出去的热是有限的，哪怕芯片规格上写了可以跑到25W，如果你的散热器只能压住15W，那它的实际有效算力就按15W去估。这个道理谁都懂，但真做起来特别容易忽略。

2. 算力评估：从“算力焦虑”到数学题

2.1 TOPS 到底是什么口径

TOPS是Tera Operations Per Second的缩写，代表每秒万亿次操作。但这个“操作”在不同语境下差别很大。对AI芯片来说，最常说的TOPS一般指INT8精度的乘加运算次数，而且是一次乘加算作两次操作（Multiply-Accumulate，MAC），所以一颗芯片标称100 TOPS，意味着它每秒能做50万亿次乘加。如果换成FP16精度，同样的硬件单元算力通常会减半；再往上FP32还要再砍一半。

还有个容易混淆的点是“算力”跟“处理器频率”的关系。很多人在评估时直接问“你的GPU多少GHz”，这在AI芯片里不太适用，因为AI芯片的算力主要由MAC阵列规模、时钟频率和利用率共同决定。举个例子，NVIDIA Jetson Orin NX 16G 标称100 TOPS（INT8），它内部有GPU、两个深度学习加速器（DLA）和CPU协同工作，实际达到这个数字需要模型能充分把GPU的Tensor Core和DLA全部用起来，并且数据搬运不成为瓶颈。如果只是用CPU做前处理、再把数据搬进GPU，利用率能到60%已经算非常优秀。

所以在横向对比芯片时，别只看纸面TOPS，要看三样东西：内存带宽、能效比（每瓦能提供多少TOPS）、以及工具链能不能把你的模型吃透。

2.2 视觉任务算力估算：以目标检测为例

评估算力需求最靠谱的方法是从模型的实际计算量出发。以大家都熟悉的目标检测模型YOLOv8s为例，输入分辨率640x640时，它的计算量约28.7 GMACs（亿次乘加），我们平时看到的一些论文里喜欢用FLOPs来表示，注意这里的单位其实是GFLOPs=2×GMACs。如果要跑到25 FPS，那理论上每秒需要的运算量为：

28.7 GMACs × 2 × 25 FPS = 1435 GOPS ≈ 1.4 TOPS

也就是说，单看模型本体，1.4 TOPS的INT8算力好像就够了。但实际部署时还要算上前处理（图像缩放、归一化、颜色空间转换都要消耗CPU），后处理（NMS非极大值抑制、解码框），以及推理框架本身的调度开销。经验上，真实系统效率最多只能达到理论峰值的50%~70%。按50%算，就需要2.9 TOPS。如果再叠加多路相机，假设4路相机同时跑YOLOv8s，单这一项就需要超过10 TOPS的余量。

如果你的场景不只是一维视觉，还有激光雷达点云处理，那算力需求会瞬间拉高好几个量级。比如PointPillars这一类的点云检测网络，对每一帧点云做预处理和pillar特征提取，每帧的计算量轻松超过100 GMACs，10 FPS就需要1 TOPS以上，但加上点云体素化、特征编码和后续的多任务头，实际工程中往往要预留3到5倍的余量。我的建议是：先用profiling工具测出自己模型的实际GMACs，代入“帧率 × 2 × GMACs ÷ 部署效率”这个公式，再乘上1.5到2的安全系数，就是底线算力。

2.3 token算力需求评估：大模型上车的现实问题

现在很多具身智能项目开始尝试在端侧跑大语言模型（LLM）或多模态模型，这就涉及到一个热词：“token算力需求评估”。token是模型输入输出的最小单位，评估端侧能不能跑大模型，光看TOPS是不够的，因为LLM推理有个明显的瓶颈是内存带宽，不是纯算力。

以Llama 3 8B为例，模型权重如果按BF16存储，大约需要16GB。推理时分两步：预填充（prefill，处理输入token）是计算密集型；解码（decode，逐个生成输出token）则是访存密集型，每生成一个token都要把全部权重从内存里过一遍。解码速度的理论上限可以用“内存带宽 ÷ 模型权重大小”来估算。假设板卡的内存带宽是102GB/s，那解码速度的上限大约是102 / 16 ≈ 6.4 token/s。这是一个非常不“AI”的数字——哪怕GPU算力再强，内存带宽不够，生成速度也上不去。

所以如果你打算在端侧跑LLM，真正的评估指标是两点：能不能装下整个模型（内存容量），以及内存带宽能提供多少token/s。对于对话式的任务，5 token/s基本是底线；对于简单的调度指令，2 token/s也可以接受。如果把模型量化到INT4，权重占用降到约4GB，带宽瓶颈就缓解了很多，但你又得衡量量化带来的精度损失。建议先拿量化的ONNX模型在自己的板卡上实际跑一遍，记录真实的token/s，再决定是否上车。

2.4 内存带宽与延迟：算力焦虑的隐形凶手

前面已经提到了内存带宽的重要性，这里展开说。很多工程师选型时盯TOPS盯得很紧，结果板卡拿回来跑大模型或者高分辨率视觉模型，发现卡成PPT，第一反应是算力不够，其实是内存带宽瓶颈。

举个例子，Jetson Orin NX 16G的LPDDR5带宽是102.4GB/s，看起来不小，但如果你跑一个输入分辨率1920x1080的检测模型，单帧图像数据量就约6MB（RGB8位），100 FPS意味着每秒需要搬运600MB。再加上模型权重、中间特征图和前后处理的拷贝，带宽很容易被吃满。计算单元等待数据的时候，TOPS再高也白搭。

更隐蔽的还有内存延迟。端侧设备不像服务器那样有超大容量高带宽内存，CPU和GPU共享同一片LPDDR，如果模型里频繁操作小张量、大量小算子，延迟会明显拖慢整体速度。实际开发中，我建议优先做三件事：第一，把模型输入尺寸降到满足任务的最低分辨率；第二，尽量用TensorRT这类会把算子融合的推理引擎，减少Kernel启动和数据往返；第三，避免在Python层做逐帧的numpy数据转换，能放在预处理管线里的就放进去。

3. 主流端侧算力芯片横向对比与实测成绩

3.1 芯片家族梳理：不只有NVIDIA

提到端侧AI芯片，很多人第一反应就是NVIDIA Jetson系列，毕竟生态成熟、文档全、社区大。但实际项目里，芯片选型远不止这一家。按照我的分类，端侧芯片大概可以参考这几个方向。

第一梯队是NVIDIA Jetson家族，比如Orin Nano、Orin NX、AGX Orin，适合对开发效率和生态要求高的场景。Ampere架构的GPU加上DLA，TensorRT优化后性能很能打，CUDA生态更是无解。第二梯队是以地平线征程系列、黑芝麻华山系列为代表的国产车规芯片。征程6系列标称最高560 TOPS，黑芝麻A2000标称256 TOPS，这类芯片的优势是原生面向车载场景，有完整的工具链和功能安全认证，适合量产前装项目。第三梯队是TI TDA4VM、瑞萨R-Car这类传统汽车电子芯片，算力不算高（TDA4VM标称8 TOPS左右），但胜在功耗低、稳定性和车规可靠性好，适合做传感器融合、行车记录、底盘控制这类实时性要求高但AI负载不算重的任务。第四梯队是安谋、瑞芯微、地瓜等边缘AI芯片，比如RK3588的NPU有6 TOPS，地瓜旭日5的NPU算力更强一些，适合轻量级视觉项目和成本敏感产品。

选择哪家，不只看算力，还要考虑供货稳定性、车规认证级别、工具链成熟度、以及团队熟悉程度。我个人的建议是：如果做原型验证和快速迭代，Jetson系列最稳妥；如果做出量产产品，国产车规芯片已经很值得考虑了，就是学习曲线会让你多花一些时间。

3.2 实测对比：算力、功耗与能效

下面这张表是我过去一段时间在不同板卡上实测和公开数据交叉验证的结果，可以作为选型参考。注意功耗数据是在80%负载、散热良好条件下测得，实际数值会受环境温度和散热方案影响。

这里面能效比是选型的重要指标，因为端侧设备电池有限，散热有限，能效比直接决定了一件设备能在野外坚持多少小时。Orin NX 16G之所以是很多机器人项目的甜点，不只是算力够用，更因为它25W就能提供100 TOPS的INT8算力，综合生态和性能最均衡。AGX Orin性能虽然猛，但60W的功耗对巡检车来说有点奢侈，要么电池要大，要么就得接受更短的续航。

3.3 功耗与散热的实测记录

纸面功耗是一回事，实际跑起来完全是另一回事。我在Jetson Orin NX 16G上做过一轮比较严苛的散热测试，这里把数据记录下来。

测试条件是室温26℃，机箱半密闭铝合金外壳，只靠被动散热片和底部开孔自然对流，没有加风扇。先跑GPU压力测试（nvstress）加上一个实时目标检测模型，功耗稳定在20W左右，持续运行20分钟后核心温度曲线爬升到84℃，随后功率被温度墙限制，逐步回落到14W，检测帧率也从29 FPS掉到22 FPS。后面我换了带热管的风冷散热模组，同样条件下温度稳定在62℃左右，功耗能持续跑满22W，帧率恢复到28 FPS。

这组数据说明了一个问题：如果你的产品没法主动散热，标称功耗再高也发挥不出来。被动散热下的Orin NX 16G，实际能长期稳定运行的功耗大约是14W，相当于只发挥了70%的水平。所以选型时我会先问一句：设备结构上能不能加风扇，散热路径通不通，如果答案是不能，那就果断选低功耗档位的芯片，别抱着“先超频再说”的想法，下场就是高温降频甚至死机。

3.4 工具链与生态：别忽略的隐性成本

芯片的纸面性能重要，但工具链决定了你落地的效率，这一点在多个平台横向对比后体会尤其深。

NVIDIA走的是“全家桶”路线，JetPack SDK里预装了CUDA、cuDNN、TensorRT，模型从PyTorch导成ONNX再转TensorRT engine，基本无痛。DeepStream则把摄像头解码、批处理、推理、RTSP输出串成一条高效管线，多路视频场景特别方便。国内芯片里，地平线的工具链这几年进步很大，支持PyTorch和ONNX模型的编译，但有些算子需要特定写法才能被加速，比如transformer类的注意力机制需要手动融合成厂商自定义算子，不然效率打折。瑞芯微的RKNN工具链相对简单，支持常见分类、检测模型，但遇到复杂动态shape模型时会让你想砸键盘。

我的建议是，正式选型前一定做一次“三小时冒烟测试”：选一个业务核心模型，在目标芯片上完成从转换到推理的全流程，看它需要的工程量和最终帧率。这一步能帮你筛掉90%的坑。

4. 硬件整机集成实操记录

4.1 外设接口与通信瓶颈

算力板卡选好之后，真正麻烦的是怎么把相机、雷达、底盘控制这些外设接进来。接口选错，后面做整机联调时会非常痛苦。

视觉传感器主流接口有两种：MIPI CSI和USB。MIPI CSI延迟低、带宽足，适合多路高清相机同步采集，但线材短、连接器脆弱，不适合频繁拆装。USB3.0相机方便、即插即用，但多路同时接入时CPU占用率高，而且共享带宽会让帧率抖动。车载场景经常会用GMSL接口传输相机信号，它的特点是传输距离远、抗干扰好，一个GMSL解串器可以接多路相机，但需要注意链路两端必须配对好，不然会出现花屏、丢帧。

激光雷达和底盘控制一般是串口、CAN或者Ethernet接口。CAN总线在车载领域几乎绕不开，但CAN不是即插即用，波特率要配（常用500Kbps）、终端电阻要加（120Ω）、报文协议要双方对齐。我遇到过最头疼的问题是CAN总线上多设备互相干扰，报文错乱，排查半天才发现是终端电阻没加，导致信号反射。

另一个容易忽视的瓶颈是PCIe通道数。如果你同时要插NVMe固态盘、采集卡、加速卡，PCIe通道一紧张就得做带宽分配。Orin NX 16G的PCIe通道数量有限，用了高速SSD之后再挂PCIe采集卡会掉速，所以我在设计时优先保证系统盘的PCIe带宽，次要设备走USB或网口。

4.2 双芯片架构还是会用单芯片

我这次项目最终选择的是双芯片架构：一颗Jetson Orin NX 16G作为主算力芯片，负责视觉感知、路径规划和机械臂控制决策；另一颗低功耗的MCU（STM32H7系列）负责底层电机控制、编码器读取、CAN通信和安全逻辑。这样设计不是叠床架屋，而是出于三个非常实际的考虑。

第一，实时性隔离。机器人控制环路的周期通常是1kHz甚至更高，如果让Linux系统里的进程去管电机，任何一次调度延迟都可能导致抖动甚至失控。MCU跑裸机或者RTOS，中断响应是微秒级，单独掌管电机和急停逻辑，安全得多。第二，算力分工。视觉和规划是重计算，机械臂的逆运动学如果丢给主芯片，会和感知任务抢CPU资源，MCU做低成本重复计算则毫无压力。第三，故障隔离。就算主芯片死机，MCU依然可以让机器人安全停下，不会出现系统崩溃后带着机械臂乱晃的危险状态。

如果预算紧张，也可以单芯片跑所有任务，但起码要把控制命令放在实时核上（比如Jetson的Denver双核或者加一块Xenomai实时补丁），并且给控制逻辑设置独立看门狗。这个方案在下一节会展开聊。

4.3 端侧部署流程实录：从 JetPack 到 TensorRT

这里记录一下我在Jetson Orin NX 16G上部署YOLOv8s的完整流程，这套流程在多数NVIDIA端侧设备上通用。

第一步是烧写系统。下载对应版本的JetPack 5.1.2 SDK Manager，选好板卡型号，把系统刷进SSD。这里特别提醒，JetPack版本直接决定TensorRT和CUDA版本，后面转engine时如果报版本不兼容，十有八九是这个环节的问题。刷完后安装基础依赖：

sudo apt update sudo apt install nvidia-jetpack

这里nvidia-jetpack元包会把CUDA、TensorRT、OpenCV这些组件一次性装好，省得手动折腾。

第二步是导出ONNX模型。在PC上用ultralytics官方导出命令：

yolo export model=yolov8s.pt format=onnx opset=12

注意opset别太高，Jetson上的TensorRT版本太新反而会报一些兼容问题，opset 12是我实测最稳的组合。

第三步是用trtexec把ONNX转成TensorRT engine：

trtexec --onnx=yolov8s.onnx --saveEngine=yolov8s.engine --fp16 --workspace=1024

这里开FP16，性能比FP32快一大截，mAP损失在可接受范围内。workspace设置成1024MB，防止显存不足。

第四步是写推理代码。推荐用Python绑定的TensorRT，或者直接用DeepStream的nvinfer插件省去自己写前处理和后处理。我这里给一个最小化的Python推理骨架，核心是用engine的context和buffer：

import tensorrt as trt import numpy as np logger = trt.Logger(trt.Logger.WARNING) runtime = trt.Runtime(logger) with open("yolov8s.engine", "rb") as f: engine = runtime.deserialize_cuda_engine(f.read()) context = engine.create_execution_context() # 分配输入输出buffer，这里省略了CUDA和图像预处理代码 output = np.empty((84, 8400), dtype=np.float32) ...

第五步是验证帧率。实测Orin NX 16G在FP16、输入640x640、batch=1条件下，YOLOv8s的推理耗时约28-32ms，也就是30 FPS左右，CPU占用率不低但整体OK。如果还嫌慢，可以把输入分辨率降到480，或者切部分帧到DLA跑，DLA对卷积网络很友好，能释放GPU压力。

4.4 多台算力设备的统一管理

做真机项目时，经常有多台设备同时运行，比如一台巡检车上面的主控、一台机载计算单元、再加上几台调试用板卡。每台都单独开SSH操作效率太低，我习惯用一段简单的脚本批量管理：

for ip in 192.168.1.2 192.168.1.3 192.168.1.4; do ssh user@$ip "nvidia-smi; cat /etc/nv_tegra_release" & done

如果设备更多，升级用Ansible或者Docker Compose统一分发容器镜像。把每个算法模块都容器化之后，跨设备部署只需要拉镜像，不用再逐个对齐依赖版本。这算是我在项目后期才发现的高效工作方式，建议一开始就建立容器化习惯，不然设备多了依赖地狱会让人崩溃。

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

5.1 供电不稳导致的死机与重启

车载和机载场景里，死机重启的头号嫌疑是供电质量。我遇到过一种典型现象：板卡在实验室接稳压电源一切正常，装到车上跑几分钟后就重启。用示波器一量，发现车辆电源在电机启动瞬间存在几十毫秒的电压跌落，幅度超过10%。Jetson这类板卡对输入电压有严格要求，跌落到临界值之下就会触发欠压保护。

解决办法有两个方向。一是在电源入口加一级宽压DC-DC模块，输入范围至少9V-36V，输出端加足够容量的电解电容，吸收瞬态尖峰；二是给板卡设置看门狗，即使死机也能自动重启，不会让整台机器瘫在路边。我最终是两者都做了，实测下来电源纹波从±800mV降到±120mV，死机问题彻底消失。此外，线材也是隐患，车载环境最好用带屏蔽层的双绞线，接头点焊加固，别省这几块钱。

5.2 温度降频与性能衰减怎么办

温度降频是最普遍也最容易被忽视的性能杀手。很多板卡默认的策略是到达85℃就限制功率，导致性能断崖式下降。我的排查流程分三步：先用tegrastats观察实际功率、温度、CPU和GPU频率，确定是否撞上温度墙；再测环境温度，看看设备舱内部实际温度比室温高多少；最后检查散热器与芯片的接触压力，以及导热垫/相变材料是否贴合到位。

如果确定是散热不足，优先考虑加主动风扇，因为风冷的效果远好于被动散热，成本也不高。无法加风扇时，可以通过nvpmodel把板卡调到低功耗档，比如把Orin NX从25W降到15W运行，虽然峰值算力降了，但性能更稳定，总吞吐量反而可能更高。散热材料上我踩过坑：用普通硅脂在振动环境中几个月就干了，换成相变材料的导热垫之后，长期可靠性明显改善。

5.3 工具链与版本兼容性问题

端侧AI开发最多的问题是工具链版本不兼容。常见的是这种情况：PC上PyTorch里转好的ONNX模型，到Jetson上用TensorRT转换时报“Unsupported layer”或者“opset version mismatch”。排查思路是先确认TensorRT支持的ONNX算子版本，再调整模型导出参数。有时是模型里的某个运营商用库不识别，那就用onnx-simplifier简化一下图结构，往往会解决。

还有一类容易被忽略的问题：板卡上的Python版本和pip安装的第三方库版本。JetPack自带的Python是3.8，如果你从PC环境复制过来的requirements.txt里有些包版本太新，可能直接无法安装。我的建议是每个项目都用独立的conda环境或者Docker镜像，锁定版本号，避免一边开发一边“升级地狱”。

如果你在Jetson上跑PyTorch遇到类似“illegal instruction (core dumped)”，多半是板卡上的glibc或者CPU指令集不支持新版本PyTorch，最简单的办法是回退到JetPack官方推荐的PyTorch版本，别追新。

5.4 相机同步与传感器时间戳问题

多传感器融合时，时间对齐是绕不开的坑。相机和激光雷达各自采集数据，如果时间戳不一致，融合出来的结果就会出现“看到”的目标位置错位。我的做法是给每个传感器打上统一的硬件时间戳：相机用PTP或者电信号触发，激光雷达用PPS脉冲做同步，所有数据帧到达主控后，以统一的主时钟（PTP或GPS时钟）做时间戳对齐。

如果硬件上的同步方案来不及做，软件层上也需要做缓冲。比如把每路数据按时间戳放到一个短暂的队列里，控制端等到每个周期内的数据都到齐后再统一处理，虽然会增加少量延迟，但能避免严重的数据错位。在端侧算力不足时，我甚至会把视觉帧率降到10 FPS去和雷达的10 Hz对齐，牺牲部分流畅度换取融合准确度。

另外，多相机采集时最常见的问题是曝光时间不一致导致同一场景亮度差异巨大，后期融合效果差。需要把相机配置成手动曝光并锁定参数，或者开启Auto-Exposure同步功能，确保各相机在同一时刻用相同参数曝光。

5.5 调试期的自动化巡检与热修复

最后分享一个调试期的实用经验：在端侧设备上部署一套简单的健康巡检服务，定时上报核心温度、功率、进程状态、磁盘剩余空间到主机端。我写过一段不到50行的Shell脚本，放在crontab里每分钟跑一次，把数据写入日志文件，再通过MQTT推送到调试面板。一旦现场出现性能下降或者异常重启，后端的记录就能帮你迅速定位是温度导致降频，还是进程OOM被杀。

应急时可以用远程SSH执行热修复，比如重启某个崩溃的算法进程、切换低功耗运行模式、清理系统日志。这套机制在大批量现场设备部署时尤其重要，别指望出了问题再抱着笔记本出差去现场排查，先让设备自己把“病历”记录下来。

写在最后的一点个人体会

这个项目做下来，我的核心感受是：端侧AI硬件选型其实是一道系统题，不是单看TOPS能解决的。算力、内存带宽、功耗、散热、接口、工具链，每一环都可能成为短板，而木桶效应在硬件上体现得淋漓尽致。如果在项目一开始就花一周时间做需求评估和散热测试，后续能省下至少一个月的返工时间。

最后再分享一个选型的小技巧：不要只看厂商宣传的性能跑分，一定要拿自己的模型、自己的数据、在自己的目标散热条件下实测。哪怕只跑半天，得到的数据也比任何宣传页都靠谱。硬件这东西，参数可以标得很漂亮，但上了真实负载才知道它到底稳不稳。希望你做选型时，也能少踩几个我踩过的坑。