ARC6N0 T5X边缘AI平台：异构推理架构与实战部署解析-嵌云网-嵌入式AI开发资源站

ARC6N0 T5X边缘AI平台：异构推理架构与实战部署解析

边缘AI模型推理NPU

|难度：普通|阅读约 34 分钟

1. 从"云上跑模型"到"边缘出结果"：这个平台要解决的真实痛点

这几年做AI落地，最深的感受就是：模型训练早就不是瓶颈了，真正卡脖子的是推理那一步到底放在哪儿跑。云端推理延迟高、带宽贵、数据还得出域，工业现场、门店、园区这些环境根本等不起。我见过太多项目，算法在测试机上跑得飞快，一上现场就翻车，不是因为模型不行，而是部署链路太重，一个小破盒子根本带不动。

ARC6N0 T5X边缘AI平台，就是冲着这个痛点来的。它的定位很直接：一个把推理能力真正下沉到设备端的边缘AI平台，集成异构计算单元、轻量推理引擎和一套完整的分发运维机制。你可以把它理解成一张"算力百宝箱"——里面既有面向神经网络加速的NPU算力单元，也有负责传统视觉处理的DSP，还有一块可编程的GPU核心，三者在同一个运行时调度器下协同干活。

这套平台适合谁来用？如果你是做工业视觉检测的集成商、做园区安防巡检的工程团队、做智慧零售运营的甲方技术部门，或者纯粹是研究边缘计算的学生、独立开发者，都可以拿它当参考。它不是那种PPT上的"边缘计算概念框架"，而是能从镜像烧录一路讲到服务上线的完整实操方案。我写这篇文章，就是把我们团队从选型、架构设计、烧录部署到真机跑模型的整个过程，尽量原原本本地还原出来。

你可能要问：市面上那么多边缘计算方案，为什么还要自己做一套？答案很简单：通用方案要么太贵、要么太封闭。买现成的边缘盒子，算力规格固定死了，想加一个传感器通道都得求厂家改固件；用开源框架吧，OpenCL、TensorRT、ONNX Runtime、ncnn这些各有各的脾气，融合到一起需要大量适配工作。ARC6N0 T5X从一开始就没打算做一个"通用AI框架"，而是瞄准"特定场景的确定性交付"——把最常用的模型结构、算子库、数据管线提前固化好，让集成商拿到手就能干活。

举个具体的例子。我们接过一个模拟项目X，需求是给车间传送带做零件缺陷检测，要求在200毫秒内返回结果，同时现场不能连外网。如果用云端方案，一张图传上去往返就超过300毫秒，项目直接黄了。上了T5X之后，整个推理链路压缩到设备本地，平均延迟降到80毫秒左右，还省掉了每年几万块的带宽和云主机费用。这个数字对比，就是边缘AI存在的全部理由。

所以这篇文章的核心内容很简单：ARC6N0 T5X是什么、内部怎么协作、实测数据如何、怎么部署落地、适合哪些场景、有哪些坑千万别踩。我会尽量把关键参数和踩坑过程写清楚，你可以直接拿去对照自己的项目做评估。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 从硬件单元到软件调度：ARC6N0 T5X的架构设计逻辑

2.1 异构计算单元怎么协作：NPU、DSP、GPU的分工逻辑

做边缘AI平台，第一件事不是选芯片，而是先想清楚算力怎么分配。ARC6N0 T5X采用了一个"三引擎联动"的异构架构。主推理引擎是NPU，专门跑卷积神经网络这类结构化算子；DSP负责信号预处理，比如图像降噪、色彩空间转换、FFT（快速傅里叶变换）；GPU则兜底，处理那些NPU暂时不支持的算子，比如某些自定义ROI池化或者动态形状的模型分支。

为什么会这样拆？因为"单一引擎跑所有任务"这种思路在边缘设备上根本不现实。NPU擅长矩阵乘法和卷积，但遇到条件分支、动态shape就很吃力——网络结构一旦变化，NPU编译得重新来一套；DSP则是固定管线逻辑，延迟极低但不灵活；GPU通用性好，但功耗高，长时间满载跑容易触发降频保护。三者配合，才能在不同负载下都保持稳定的表现。

以我们跑的一个YOLOv8s目标检测模型为例，整个推理过程在T5X上被拆成了三段：输入图像先经过DSP做720p到640p的缩放和降噪，耗时约3毫秒；然后640x640的RGB数据通过DMA直接灌进NPU，跑完整个卷积主干，平均耗时约47毫秒；最后置信度筛选和NMS（非极大值抑制）这类后处理逻辑交给GPU上的CUDA核，约12毫秒。三段加起来约62毫秒，如果都在NPU上硬跑，后处理那部分至少要多出40毫秒。

这个"各干各的活、数据零拷贝流转"的设计，是整个平台延迟指标能打的核心。你可能会想，数据在不同引擎之间搬来搬去，难道没有开销吗？这就是ARC6N0 T5X在设计上比较聪明的地方：NPU、DSP、GPU共享同一片物理内存，通过硬件同步原语做数据流转的握手，不需要经过CPU去拷贝，传输开销几乎可以忽略。

2.2 推理引擎与模型适配层：ONNX进来、平台化算子出去的转换机制

硬件有了，接下来就是软件怎么把模型"喂"进去。ARC6N0 T5X对外的模型入口是ONNX，这套平台内置了一个模型适配层，做三件事：算子映射、权重重排、子图替换。

算子映射解决的是"模型里有NPU不支持的算子怎么办"的问题。适配层会先对ONNX图做一次静态扫描，把所有算子分成三类：原生NPU算子、DSP加速算子和GPU兼容算子。比如Conv、Relu、MaxPool这些常见算子，经过权重重排（把NCHW转成NHWC并把8bit量化参数预计算好）后直接映射到NPU；而像ScatterND、NonMaxSuppression这类动态算子，就拆解到GPU上单独处理。

权重重排这一步很关键，很多人第一次上手会忽略。ONNX模型里权重默认是按Caffe风格排列的，但NPU的卷积加速器要求权重按分块方式排布，否则访存效率低到吓人。T5X的适配层会在编译阶段自动完成重排，不需要你去手动改模型结构。

子图替换则是针对"复合算子"的优化。比如说LayerNorm，它本身在ONNX里被拆成了好几个小算子，但NPU往往有对应的融合指令。适配层识别出这个子图模式后，会直接替换成NPU的原生融合算子，这样既省了中间张量的内存读写，还在延迟上收益明显。我们在测MobileNetV3时，单靠子图替换这一项，端到端延迟就降了约18%。

这套转换机制做完之后，模型会被编译成一个中间表示文件（我们用IR后缀），里面同时包含了算子序列、资源分配表和数据流图。运行时直接加载IR文件执行，不会再动态解析ONNX，这也是为什么相同模型跑在T5X上比跑在通用推理框架里启动更快、更省内存。实测下来，一个80MB的YOLOv8s模型，从加载到首次推理的冷启动时间在1.2秒左右，隔一段时间热启动则只需约180毫秒。

2.3 运行时调度器：实时任务、周期任务与优先级抢占怎么处理

硬件协作到位了，还得有一个"指挥官"来调度任务，这就是平台内置的实时运行时调度器。工业场景里最怕的一件事是：两个推理任务同时来，结果互相抢占资源，导致谁都没跑完。T5X的调度器把任务分成三种类型：实时任务、周期任务和尽力而为任务。

实时任务优先级最高，通常是门禁识别、急停检测这类必须在几十毫秒内响应的动作；周期任务包括帧率固定的视频流分析，比如每200毫秒对摄像头画面做一次看护检测；尽力而为任务则指模型上报、日志写入、算子自检这类不赶时间的操作。

调度器用的是"固定优先级+时间片配额"的混合策略。每个引擎在自己的时间片内只处理授权给它的任务，超时就会被挂起，让出计算资源。这样设计的好处是，即使某个周期任务因为模型异常运行超时，也不会把实时任务的执行窗口挤掉。我们在实验里人为向NPU灌入一个跑不完的坏算子，实测实时任务的中断响应时间仍然稳定在约9毫秒以内。

内存管理上，T5X也做得很细。NPU、DSP、GPU共享物理内存，但调度器会给关键任务预留常驻内存块，防止碎片化导致的大延迟。比如人脸识别模型的特征提取权重就常驻在NPU显存中，不会被换出，保证每次识别都是"即刻可用"的状态。

3. 实测数据与基准表现：延迟、功耗、精度三方面怎么看

在项目里跑出确定性数据，比什么宣传都有说服力。ARC6N0 T5X有几个官方基准值，但我们实测下来的表现更贴近真实场景，这里列三组数据给大家参考。

第一组是目标检测。用测试集自带的600张混合场景图像（包含弱光、强逆光、运动模糊三种情况），部署YOLOv8s（输入640x640，FP16精度）：

平均端到端推理延迟：62毫秒（包含图像前处理和后处理）
P95延迟：79毫秒，P99延迟：110毫秒
GPU后处理部分在弱光场景下会增加约3毫秒，因为需要做额外的自适应直方图均衡化
硬件功耗：整板平均约8.2W，峰值11.5W

第二组是语义分割。用SegFormer-B0（输入512x512，INT8量化）跑一组园区道路画面的分割任务：

平均推理延迟：27毫秒
显存占用：约420MB（包含模型权重和激活值）
与FP16模型相比，mIoU（平均交并比）从0.812下降到0.797，降幅约1.5个百分点，但延迟缩短了约38%

第三组是音频事件检测。用一个轻量级波形分类模型（输入16kHz单声道音频，每段2秒）做异常声检测：

平均推理延迟：41毫秒
支持32路音频流并行处理
整机功耗在音频任务下仅4.6W，因为DSP承担了大部分梅尔频谱计算

说实话，精度那条值得单独提一下。很多边缘平台对INT8量化后精度下降是讳莫如深的，但ARC6N0 T5X支持一种"混合量化"策略：敏感层保持FP16，非敏感层用INT8。比如刚才那个SegFormer-B0，适配层自动把最后一层的归一回传和跳层连接保留成FP16，其他卷积层量化成INT8。最终精度降幅被压缩到0.6个百分点，但延迟收益几乎和全量化一致。这点在做医疗影像或缺陷检测这类高精度场景时，非常实用。

3.1 对比一段"裸跑ONNX Runtime"和"T5X平台化推理"的差异

为了让数据更有参考价值，我把同一个YOLOv8s模型分别丢在裸装的ONNX Runtime（CPU模式）和ARC6N0 T5X平台上跑了一遍，相同输入下得出以下对比：

指标	ONNX Runtime (仅CPU)	ARC6N0 T5X
端到端平均延迟	312毫秒	62毫秒
冷启动加载模型	3.8秒	1.2秒
运行功耗	6.1W	8.2W
内存占用	380MB	530MB
峰值吞吐	2.8 FPS	13.1 FPS

这个对比说明几个问题。短期内，CPU裸跑虽然功耗低一点，但延迟太高，只能做离线分析，根本扛不住实时场景；T5X内存占用多了一截，换来的是三引擎并行的能力，在需要连续跑视频流时，哪怕同时开三个模型，调度器也能稳定分配资源。所以这个平台的目标用户，是对确定性有要求的集成商，而不是跑个Demo就收手的爱好者。

另一个值得关注的点是"多模型并发"稳定性的实测。我们把一个人脸识别模型和一个车辆检测模型同时部署到平台上，各跑各的视频流，运行24小时。结果人脸模型平均延迟66毫秒，车辆模型平均延迟71毫秒，相互之间的抖动不超过5%，而且没有出现一次内存访问冲突。调度器对两个模型的输入输出做了内存隔离，NPU通过时间片交替执行，整体表现非常稳。

3.2 长时间跑稳定性：56小时压力测试与降频拐点

数据好看还不够，边缘设备最怕"越跑越慢"。ARC6N0 T5X在满载场景下跑了一个56小时的连续压力测试，负载是四路720P视频轮询做检测识别。前12小时，平均延迟稳定在63毫秒左右；第20小时开始，由于设备外壳温度升到约67℃，GPU核心出现轻微降频，延迟缓慢上浮到73毫秒；但在第28小时温度稳定后，延迟又回到了66毫秒，之后30小时基本没有继续恶化。

为什么会有这个"降频拐点"？因为T5X的散热设计是分区域的，NPU和DSP功耗相对低，不容易触发降频；GPU一旦长时间满载，温度上升更快，节流保护就会介入。所以项目上如果主要靠GPU跑后处理，建议在部署上保留对GPU负载的监控，并且在机箱加装主动散热。我们在另一个项目里用了带风扇的工业机箱，GPU温度始终没超过58℃，延迟全程没超过70毫秒。

防雷、防浪涌这些工业现场特性，T5X也考虑了。它设计了宽压输入范围（9V到36V DC），并带反接保护和过流恢复，这对车载或户外供电不稳定的场景非常重要。不过要提醒一句：宽压输入并不等于可以乱接电源，必须使用合格的工业电源适配器，否则电源纹波大，很容易让板载的LDO（低压差线性稳压器）过载，烧掉供电线路，我们实验室就烧过一块测试板，教训很深刻。

4. 完整部署实操：从镜像烧录到边缘服务上线的全过程

讲了这么多架构和数据，终端可能更关心：拿到手怎么把平台跑起来？下面我把一次完整的部署过程逐步写清楚，尽量按我们实际操作时的顺序来。

4.1 准备阶段：烧录系统镜像与基础网络配置

ARC6N0 T5X出厂不带系统，需要自己烧录。它支持从eMMC烧录，也支持从SD卡启动。官方推荐用一张32GB以上的高速SD卡做启动介质，烧录工具用的是balenaEtcher。先到平台官网下载对应硬件版本的镜像包，解压后得到一个img文件。

烧录命令很简单（Linux环境）：

bash复制# 解压镜像
tar -xzf ARC6N0_T5X_v2.1.img.tar.gz
# 查看SD卡设备号，注意千万不要选错盘
lsblk
# 写入镜像，/dev/sdX需要替换成实际设备
sudo dd if=ARC6N0_T5X_v2.1.img of=/dev/sdX bs=4M status=progress conv=fsync

烧完之后把SD卡插到板子上，接好串口线（默认波特率115200），上电。第一次启动会进入系统初始化向导，设置root密码、网络参数和时区。平台默认关闭SSH密码登录，需要先通过串口创建好SSH密钥，再用密钥登录，否则连接会被拒绝。

这里有个小坑必须提一下：镜像烧录完第一次启动时间比较长，大约3到5分钟，因为系统会自动扩展文件系统并初始化NPU固件。很多人以为板子卡死了，直接断电，结果文件系统损坏，只能重新烧录。正确的做法是耐心等，"系统初始化完成，请重新登录"这个提示出来之后再操作。

网络配置建议使用静态IP，而非DHCP。边缘场景里设备IP经常要配合防火墙白名单，如果DHCP租约到期换IP，后面所有依赖IP的配置全得改。用nmtui工具设置静态IP：

bash复制nmtui
# 选择Edit a connection，修改IPv4配置为Manual
# 填好IP、掩码、网关和DNS

如果是跨网段访问边缘设备，还需要配好路由。我们园区网络的网段是192.168.10.0/24，设备在192.168.20.0/24，加一条静态路由就能互通：

bash复制ip route add 192.168.10.0/24 via 192.168.20.254 dev eth0

4.2 部署模型：把ONNX模型转换并编译进平台

网络搞定，接下来把训练好的模型部署上去。以YOLOv8s为例，先把PyTorch模型导出成ONNX：

python复制import torch
from ultralytics import YOLO

model = YOLO('yolov8s.pt')
# 导出ONNX，固定输入尺寸640x640，opset版本建议不低于17
model.export(format='onnx', imgsz=640, opset=17)

然后在T5X平台上执行模型转换：

bash复制arc-t5x-convert --input ./yolov8s.onnx \
  --output ./yolov8s.ir \
  --precision mixed \
  --input-shape 1x3x640x640 \
  --quantize-calibrate ./calib_dataset/

这里--quantize-calibrate参数指定一个校准数据集目录，里面最好放200张左右有代表性的图片，覆盖不同光照和背景。转换过程会先跑一遍校准，统计每层激活值的分布，然后据此决定哪些层量化到INT8、哪些保持FP16。校准集如果不够代表性，量化后的精度掉得比较明显，我经验是至少放150到300张。

转换完成后会看到一个.ir文件和一份.report报告。报告里会列出每个算子的执行引擎、延迟预估和显存占用。我建议仔细看一眼报告，如果某个算子的预估延迟特别高，多半是模型里有NPU不支持的结构，适配层把它扔到GPU上了。这时候可以回模型侧做优化，比如把动态shape改成静态、把三通道输入提前分路，往往能显著降延迟。

4.3 编写推理服务：Python SDK与C++ API两种方式对比

ARC6N0 T5X提供两套推理接口：Python SDK和C++ API。Python SDK适合快速原型验证和逻辑复杂的业务编排；C++ API适合追求极限性能和低延迟的生产环境。下面分别给个最小示例。

Python SDK的推理代码：

python复制import arc_t5x as t5x

# 初始化运行时
runtime = t5x.Runtime()
# 加载IR模型
detector = runtime.load_model('/opt/arc/models/yolov8s.ir')

# 从摄像头读取一帧
frame = capture.read()
# 执行推理，返回检测结果列表
results = detector.infer(frame, conf_threshold=0.45, iou_threshold=0.5)
for r in results:
    print(r.bbox, r.score, r.class_id)

这段代码跑通很简单，但生产环境里你需要把模型加载和推理做成常驻服务。C++那边写法类似，但需要手动管理内存池和缓冲队列，上手成本高一些，不过性能收益很明显。我们用C++重写了检测服务的核心循环，在相同硬件和模型下，端到端延迟又降了约10毫秒，主要省在Python解释器的调用开销和数据转换上。

4.4 配置开机自启与看门狗：服务上线后防止"跑着跑着挂了"

边缘设备不可能天天有人盯着，服务必须做到开机自启、异常自愈。T5X平台内置一个轻量级服务管理器，可以注册托管服务。我们以systemd服务单元为例：

ini复制[Unit]
Description=ARC T5X Detection Service
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/python3 /opt/arc/apps/detect_server.py
WorkingDirectory=/opt/arc/apps
Restart=always
RestartSec=5
User=arcuser

[Install]
WantedBy=multi-user.target

还要配合硬件看门狗。在/etc/systemd/system.conf里设置RuntimeWatchdogSec=14，这样一旦系统内核卡死，看门狗会自动硬重启。我们刚上线时没开看门狗，有次现场意外断电导致文件系统异常，服务起不来，只能安排人跑一趟重新刷镜像。后来把看门狗和systemd的自愈机制都配齐了，类似问题基本没再发生过。

对于关键服务，最好再加一层心跳上报机制，每30秒往MQTT broker上报一次状态。如果连续三次没收到心跳，再触发告警。这样现场出问题才能第一时间知道，而不是等用户投诉了再排查。

5. 落地场景盘点：这套平台真正改变的项目类型

5.1 工业质检：传送带缺陷检测项目里的确定性交付

我们落地过一条家电外壳喷涂质检线，原来靠人工目检，漏检率大概在3%到5%，而且速度慢，跟不上产线节拍。客户要求用视觉方案做到漏检率低于1%，同时单件检测时间不能超过300毫秒。部署在ARC6N0 T5X上的外观缺陷检测模型，配合高亮工业相机和一组位置传感器，实现了多角度抓拍快速检测。最终实测单件平均检测耗时约190毫秒，漏检率降到0.7%左右，而且产线节拍完全没被拖慢。

这套方案里比较关键的是一个"时间同步"问题。相机抓拍是由光电传感器触发，但PLC（可编程逻辑控制器）需要在检测完成后立刻决定是否放行，两个环节之间的握手延迟必须极低。T5X提供GPIO硬触发接口，可以直接把传感器信号接到板子上，省去网络中转的几毫秒。我们一开始用网口触发，延迟波动在15到30毫秒之间，虽然也能干活，但产线提速后就略吃力；换成硬触发后，把延迟压缩到5毫秒以内，稳定很多。

5.2 安防巡检：园区多路视频流实时看护的部署要点

另一个常见场景是园区安防。一个中大型园区通常有几十路摄像头，传统方案全部拉到监控中心做集中分析，网络开销和存储压力都很大。ARC6N0 T5X放在园区边缘机房，本地拉流分析，只上传告警片段和结构化数据，带宽占用直接下降了约80%。

我们部署时的配置参考：单台T5X同时处理八路1080p视频流，每路跑一个轻量级的人形检测模型，再加上全帧率保存事件缩略图。实测八路并发时，设备总功耗约17.6W，平均单路处理延迟约120毫秒，CPU占用率不到30%，NPU基本满载。后续如果还要叠加车牌识别模型，建议单独用一台设备承载，避免多模型抢占NPU资源导致单路延迟超标。

值得注意的是，视频流拉取的协议兼容性是个容易被忽略的坑。现场几十路摄像头品牌五花八门，RTSP流地址格式各异，有些老设备甚至只支持私有SDK。我们的做法是先统一到公司内部自研的视频网关做协议适配，输出标准化RTSP流，再给ARC6N0 T5X用。这样设备端只对接标准流，稳定性和复用性好很多。如果直接把各种摄像头的私有SDK接到平台上，代码维护量会非常惊人，而且注定会有兼容性纠纷。

5.3 智慧零售：在门店边缘做客流统计与商品识别的取舍

零售场景更看重低成本和高隐私。门店不希望把顾客的影像上传到云端，又需要实时了解客流、关注区域热力分布。T5X这套设备的门店落地版，在收银台附近部署行人检测和商品识别两个模型，只在本地输出统计结果和人流热力图，视频原片直接在设备上滚动覆盖。这样既满足了运营分析需求，也从物理层面规避了隐私争议。

客流统计的准确率在设计合理时能达到95%左右，商品识别的top-1准确率约88%。这两个数字看起来不高，但在零售场景里，真正的需求是"相对趋势"而非绝对精准。门店经理更关心的是"这周比上周多了多少人""哪个货架前停留时间长"，而不是精确到个位数。想清楚这一点，你就知道为什么边缘端给出80%多准确率的结果，就已经具有商业价值——因为它是实时的、稳定的，而云端方案即使做到99%，往返延迟一拉长，实际体验反而更差。

6. 从部署现场带回来的经验清单：哪些坑值得提前避开

最后整理一下我们在这个项目上踩过的坑和沉淀下来的经验，不一定每条都适用于你的场景，但多少能帮你少走弯路。

第一，模型量化必须用校准集，不能直接拍脑袋转INT8。我们早期图省事，直接用一个公开的COCO子集做校准，结果在某个特定光照的车间场景里，检测框重叠率掉了接近8个百分点。后来换成现场环境实拍图做校准，精度才恢复到可接受的水平。校准集的代表性，决定了量化后模型在真实场景里的表现上限。

第二，NPU不是万能的，别把所有算子都往NPU上丢。你在PC上用PyTorch写的模型，可能包含很多PyTorch特有的动态控制流，这些算子转成ONNX后落到边缘平台经常变成尴尬的"GPU兜底算子"。所以在模型设计阶段就要想好计算图优化方向，尽量用标准卷积、ReLU、Concat这些基础算子，少用自定义的复杂结构。我们后来在模型里加入了一个"算子友好度"检查流程，转完看一下报告，有异常高延迟的算子就回头调整模型结构。

第三，部署环境的散热和供电，直接决定长期稳定性。T5X在正常工况下功耗不高，但长时间跑满NPU后，整机温度依然会慢慢上升。我们在一个无通风的弱电箱里做过测试，两小时后设备就因为过热降频，推理延迟涨了约25%。后来加装了一个小型轴流风扇，温度压住了，延迟也回到正常水平。如果你负责的现场是密闭空间，买设备前就规划好散热位置，别等上线了再改。

第四，网络规划要在部署前想清楚。边缘设备经常部署在内网，但你需要远程访问它做维护。我们踩过最狠的一个坑是，有一台设备部署在某客户现场的封闭网段，没有外网权限，结果算法升级的时候没法远程传输，只能现场派人用U盘拷贝模型文件，来回折腾了两天。建议在部署协议里明确，至少留一条带外管理通道（比如4G模块或独立维护网口），哪怕平时不用，关键时刻能救命。

第五，多模型并发时，一定要确认调度策略是否满足你的业务。ARC6N0 T5X的调度器默认是"公平轮转"模式，但如果你有一个任务比另一个任务重要得多，可以在服务启动参数里手动设置优先级权重。比如我们在这个平台上同时跑了人脸识别（重要）和客流统计（次要），就把人脸识别任务的权重调高，保证识别不卡顿，客流统计多等几十毫秒完全无感。

ARC6N0 T5X这套平台目前已在我们这边多个模拟项目里落地，整体交付质量算是稳定。如果你手头正好有边缘AI相关的项目，也可以拿这份实测数据做个参考，对照自己的模型和算力要求，看看能做到什么程度。不同场景踩的坑可能不一样，但架构上的逻辑是相通的。先想清楚边界条件，再谈技术选型，永远比先选设备再适配场景要靠谱得多。