边缘算力这个词火了也有两三年但真正让工控机站到AI风口上的是最近这一波本地大模型和小模型推理需求的暴涨。以前提到工控机大家脑子里还是PLC、数据采集、运动控制这些老场景而现在越来越多的项目开始问能不能让工控机在产线边上直接跑一个视觉质检模型能不能在无人值守的站点里本地部署一个对话机器人能不能把原来要丢到服务器上的AI推理任务下沉到机柜里的那台不起眼的主机上答案是能而且现在正是动手的最佳窗口。硬件端有AMD 7730U这样的新平台把性能拉高到入门服务器的水平软件端有Ollama、ONNX Runtime、OpenVINO这些工具把模型部署的门槛一路打到底。这篇内容我会用一份完整实战笔记的方式把这几年在边缘算力项目里踩过的坑、验证过的方案、拿到的实测数据全部整理出来。适合准备上工控机AI方案的技术负责人、正在做边缘计算选型的工程师以及想搞懂国产工控机到底能跑多大模型的硬件玩家。1. 内容整体设计与思路拆解工控机是怎么一步步被推到AI前线的1.1 AI落地的拦路虎恰好是工控机的看家本领先理清楚一个逻辑AI模型的训练可以在云端机房完成但推理环节放在哪里直接决定了项目能不能落地。核心矛盾有三层。第一层是延迟。产线上的瑕疵检测如果要把图片传到云端等服务器返回结果网络抖动一下可能就超过500毫秒产线早就把有问题的工件放过去了。很多工厂的网络环境并不是IDC那种低延迟专线而是混合了无线、4G、老旧交换机的复杂链路延迟完全不可控。第二层是带宽与成本。一台工业相机一分钟能拍几百张图单张按2MB算一天产生的数据量就是几十GB。全量回传云端运营费用根本不是中小项目能承受的。很多客户最后会发现流量费比设备本身还贵。第三层是数据合规。设备参数、产品缺陷照片、工艺配方这些都是制造型企业最核心的资产。让这些数据日日经过第三方云服务在法务和商业上都是雷区。私有化部署成了很多行业的硬指标。而工控机在这些方面有天然优势它就在设备旁边延时可以做到毫秒级它只要在本地跑推理带宽需求几乎为零数据不出厂区合规问题直接消解。这就是我判断工控机会站上AI风口的核心依据——AI推理这个任务的物理属性和工控机的部署位置高度重合。1.2 从老配角到新主角工控机经历了什么在AI这波浪潮之前工控机在自动化体系里是个典型的配角。最常见的角色是充当数据采集网关把传感器的Modbus数据读上来转成MQTT上报给MES系统或者当个轻量级的HMI主机跑个组态软件显示工况。它的CPU性能要求不高双核四线程都算奢侈稳定性才是第一优先级。但AI推理任务彻底改变了这个格局。一个7B参数的对话大模型即使做了INT4量化内存占用也要4到6GBCPU和核显都要满负荷工作。这让工控机的硬件设计面临一次底层重构从追求低功耗稳定转向在稳定前提下提供尽可能高的算力。这个转变在芯片层面最明显。老一代平台还在用J4125、N5105这种赛扬级别的四核处理器核显性能只够解码视频而新一代平台已经走到AMD Zen3、Intel 12代酷睿这个级别集成的GPU单元开始具备实际可用的AI推理能力。再加上OPU、NPU这些异构加速单元正在被集成进边缘设备工控机的算力天花板正被快速抬升。所以你现在买一台工控机已经不是在买一台耐用的电脑而是在买一个能跑AI的边缘算力底座。选型逻辑全部要换内存大小、核显规格、PCIe扩展能力每一项都和AI任务强相关。1.3 模型变小了技术路径走通了风口才真正成立过去工控机跑不了AI还有一个现实原因模型太大。早几年一个像样的视觉模型动辄几百MB到几个GB精度还一般推理速度也慢。但这两年小模型和量化技术的进步让边缘部署这件事突然变得非常顺手。一是参数规模合理的开源模型大量出现。Qwen系列、Llama系列、Gemma系列都有专用的小尺寸版本从0.5B到7B不等。配合GPTQ、AWQ、GGUF这些量化格式一个大模型可以被压缩到原来四分之一的大小精度损失控制在可接受的范围内。二是推理框架针对CPU做了大量优化。ONNX Runtime带OpenVINO执行器、Intel的OpenVINO Toolkit、AMD的ROCm虽然不是所有核显都支持还有Ollama这种开箱即用的部署工具都让在无独立显卡的机器上跑AI成为日常操作。实测下来7730U的Vega核显在OpenVINO的加速下跑视觉分类模型的吞吐量已经接近入门级独立显卡。风口从来不是一个单点突破而是硬件、模型、工具链三条线同时成熟的结果。2024年下半年之后三条线都到位了工控机站上AI风口这件事终于从噱头变成了工程现实。2. 核心硬件与技术选型AMD 7730U工控机到底行不行2.1 7730U的核心参数与算力估算先把这个平台的老底翻出来看。AMD 7730U隶属于AMD Ryzen 7 7030U系列代号Barcelo-R本质上是Zen3架构在移动端的一次Refresh。8核心16线程基础频率2.0GHz最大加速频率4.5GHzTDP设计在15W到28W之间可调。集成显卡是Vega 8拥有8个计算单元频率最高2.0GHz。这套配置放在工控机这个品类里是什么水平首先CPU部分Zen3的单核性能把同价位的Intel赛扬或者Atom吊起来打多核性能甚至能对标上一代标压笔记本处理器处理数据采集、协议解析、模型推理这些计算密集任务绰绰有余。其次核显部分Vega 8虽然架构老但胜在单元多8CU在配合OpenVINO做推理时能分担CPU的相当一部分矩阵运算负载。算力层面的粗略估算INT8峰值大约在2到3 TOPS之间FP32大约在1 TOPS左右。这和专用的NPU或者独显比当然不算高但用来跑量化后的视觉模型和7B以下的大语言模型吞吐量已经够用。具体能跑多快我放在后面实测章节这里先给一个判断标准不要拿它去和3090比但也不要小看它它能在产线旁边稳定提供可用级别的AI算力。2.2 工控机形态与接口的附加分选工控机不能只看芯片整机的形态和接口往往比CPU更重要。AI应用从来不是独立运行的它需要跟相机、传感器、PLC、触摸屏打交道接口的丰富程度直接决定项目能不能接到现有系统里。常见的7730U工控机配置会给到这些接口2到4个Intel千兆网口有的会用i211或i225芯片方便做软路由或者多设备接入6个以上RS232/RS485串口其中至少1到2个支持RS485USB 3.0/USB 3.1接口若干用来接工业相机和外设另外还有HDMI/DP显示输出部分型号提供PCIe x4或x16扩展槽可以插采集卡、运动控制卡或者独立AI加速卡。接口布局上有两个细节值得注意。一是串口是否带隔离和保护电路这决定了在工厂环境下会不会被共模电压击穿二是网口芯片型号有些机型标注千兆但实际用的是入门级Realtek芯片长时间高负载下稳定性会差一些。我自己选型时会优先要求Intel芯片的网口多花一点钱能少很多麻烦。另一个重要因素是散热结构和供电。无风扇设计是工控机的标配通过铝制鳍片或整机外壳散热。这对AI推理是双刃剑好处是没有风扇故障、不怕灰尘适合7x24小时无人值守坏处是持续高强度推理时热量积聚如果散热设计不佳CPU会频繁降频推理速度反而不如跑跑停停的场景。选择时可以关注机型有没有提供风扇扩展位或者额外的散热模块给后面优化留一条后路。2.3 主流工控机平台横向对比为了让你有个坐标系我把市面上常见的几类工控机平台放在一起对比。这里选的是我实际接触过的方案参数以常见配置为准。平台核心/线程核显规格内存支持INT8算力参考适合任务AMD Ryzen 7 7730U8C/16T Zen3Vega 8 8CUDDR4-3200 双通道2-3 TOPS本地大模型、并发视觉推理、多任务网关Intel J64124C/4T TremontUHD 16EUDDR4-3200 单通道0.5-1 TOPS轻量分类模型、数据采集Intel N1004C/4T Alder Lake-NUHD 24EUDDR4/5 单通道0.8-1.2 TOPS轻量视觉、小模型对话Intel i5-1240P12C/16TIris Xe 80EUDDR4/5 双通道3-5 TOPS复杂视觉模型、较大型LLMNVIDIA Jetson Orin NX8C/16T Cortex-A78AEAmpere 1024 CUDALPDDR5 8-16GB100 TOPS(稀疏)GPU强依赖的视觉与多模态模型这个表格看下来7730U在传统工控机阵营里属于性能第一梯队CPU部分完胜J6412和N100核显虽然打不过移动端的Iris Xe也比J6412和N100强不少。和Jetson Orin这类专用AI平台相比通用算力强CPU无敌但AI专用算力弱很多。怎么选我的建议是如果项目以CV视觉、端侧多模态为主且预算允许Jetson Orin系列更省心如果项目除了AI推理还需要跑服务端程序、数据库、协议转换、多路串口通信这类通用计算任务7730U的综合体验更好——因为CPU强意味着你在AI推理之外可以同时干很多活这是Jetson的ARM CPU给不了的。2.4 为什么核显在AI部署中如此关键在工控机这种没有独立显卡的平台上核显就是唯一的硬件加速器。很多人低估它的作用以为AI推理就是CPU硬算实际上现代推理框架早就把算子优化做到异构计算里了。拿OpenVINO举例它会把支持GPU kernel的算子分配到Intel核显上执行常见的卷积、全连接、矩阵乘都可以加速。而如果你的平台是AMD核显别急ONNX Runtime搭配DMLDirectML执行器也能调用Vega显卡进行计算。实测下来7730U跑量化后的YOLOv8CPU加GPU混合推理比纯CPU能快两到三倍。这里顺带说一句很多AMD平台的Linux用户想直接用ROCm但Vega架构在ROCm的官方支持列表里其实是缺席的。所以AMD平台的AI加速路径并不是ROCm而是通过OpenCL、DirectML或者ZLUDA这类兼容层来实现。了解这层知识能帮你少走很多弯路——网上那些教你装ROCm的教程基本是针对RX系列独立显卡的搬到7730U上用不了。3. 实操过程与核心环节实现把AI真正跑在工控机上3.1 部署路径规划先跑通再优化后固化拿到一台7730U工控机第一步不是急着上模型而是把整个部署流程规划清楚。我的习惯是先快速跑通一个最小可用的AI服务再根据性能测试结果决定优化方向最后才考虑做成systemd服务或者Docker容器固化下来。规划时要考虑几个关键点操作系统选择、运行环境、模型格式、推理框架、服务暴露方式。工控机领域Ubuntu 22.04 LTS是我目前最常用的系统稳定性和软件生态都够用Windows也有不少项目在用特别是PLC厂商的软件只有Windows版本时。AI部分只要不是强依赖GPU驱动Ubuntu和Windows的部署复杂度其实差别不大。模型格式方面如果是对话类模型GGUF格式配Ollama是最省事的如果是视觉模型ONNX格式配ONNX Runtime最通用。我自己习惯先把ONNX和Ollama两条路都打通这样后续接不同项目时能快速切换。3.2 Ubuntu环境下查看串口和总线数据的方法工控机项目里最绕不开的操作就是查看串口设备。这里把Ubuntu下的完整流程走一遍这是从热词里看到很多人卡住的地方也确实是在现场最常被问的问题。系统装好后插入USB转串口线或者接上主板的板载串口先看一下设备是否被识别。用dmesg查看内核日志dmesg | grep -i tty正常情况下USB转串口会分配为ttyUSB0、ttyUSB1这样的设备名板载串口则通常是ttyS0、ttyS1、ttyS2等。如果设备名没有出现先检查是不是CH340、CP2102这种常见芯片的驱动没装手动安装对应驱动后再试。确认设备号后可以用stty设置波特率再用cat直接读取数据stty -F /dev/ttyUSB0 115200 raw -echo cat /dev/ttyUSB0这种方式的局限是只能看不能交互。如果要对串口做完整的读写下发用Python的pyserial更方便import serial ser serial.Serial( port/dev/ttyUSB0, baudrate115200, bytesizeserial.EIGHTBITS, parityserial.PARITY_NONE, stopbitsserial.STOPBITS_ONE, timeout1 ) data ser.read(32) if data: print(data.hex( )) ser.close()实际操作中还有两个很容易踩的坑。第一个是权限问题。Ubuntu下普通用户访问串口经常提示Permission denied需要把用户加入dialout组sudo usermod -aG dialout $USER然后重新登录生效。第二个是设备号漂移。一台工控机插了多路USB转串口时重启后ttyUSB0和ttyUSB1的顺序可能互换。解决办法是用udev规则绑定设备ID或者物理端口写一个/etc/udev/rules.d/99-usb-serial.rules文件把固定的symlink映射到实际设备。这也是项目交付时必须做的固化工作否则客户现场一重启程序就可能连错设备。3.3 部署本地大模型Ollama 5分钟上手的完整流程对话类AI是边缘场景最常见的需求之一。在7730U工控机上部署本地大模型我的首选方案是Ollama理由是部署简单、模型管理方便、与OpenAI兼容的API能直接接进现有业务代码。安装Ollama就是一行命令curl -fsSL https://ollama.com/install.sh | sh装完后服务会自动启动监听在11434端口。拉取模型也很直接以Qwen2.5 7B的INT4量化版为例ollama pull qwen2.5:7b模型拉取完成后命令行直接互动一把确认基本对话正常ollama run qwen2.5:7b 请用一句话介绍你自己能出结果就说明最小链路已经通了。但生产环境不能只用命令行需要对外提供API服务。Ollama原生自带HTTP接口不需要额外配置curl http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 写一段工控机的简介, stream: false }需要注意的是Ollama默认只绑定172.0.0.1如果其他设备需要访问要修改环境变量OLLAMA_HOST/0.0.0.0再重启服务。但工控机一般直连内网修改绑定地址前务必确认网络安全策略别把服务裸奔到公网。Python侧调用同样顺手用requests就够import requests import json url http://127.0.0.1:11434/api/chat payload { model: qwen2.5:7b, messages: [ {role: user, content: 什么是边缘计算} ], stream: False } resp requests.post(url, jsonpayload) data resp.json() print(data[message][content])实测下来7B模型在7730U上CPU推理大约能到5到8 token/s核显参与后能再快个20%到30%。这个速度跟云端的流畅感没法比但用于对实时性要求不高的中英文问答、设备运维问答、知识库检索辅助已经是可以接受的水平。如果嫌慢可以换4B或者1.5B的小模型速度翻倍甚至翻三倍。3.4 部署视觉推理模型ONNX Runtime 与 OpenVINO 实战视觉质检是工控机AI项目里占比最大的场景。这里给出一个可复现的完整流程用OpenCV读取工业相机画面送到ONNX Runtime做推理得到检测结果。建议先安装好基础依赖pip install onnxruntime opencv-python numpy如果目标平台是Intel平台把onnxruntime换成onnxruntime-openvino可以激活核显加速AMD平台想用核显加速则用onnxruntime-directmlWindows或者标准版CPU推理。下面以通用CPU推理代码为例因为它的兼容性最好实际部署时再根据硬件调整providerimport cv2 import numpy as np import onnxruntime as ort # 初始化推理会话模型可以是YOLOv8导出后的onnx session ort.InferenceSession( yolov8n.onnx, providers[CPUExecutionProvider] ) # 读取工业相机帧这里用图片模拟 img cv2.imread(part_defect.jpg) input_tensor cv2.resize(img, (640, 640)) input_tensor input_tensor.astype(np.float32) / 255.0 input_tensor np.transpose(input_tensor, (2, 0, 1)) input_tensor np.expand_dims(input_tensor, axis0) # 执行推理 outputs session.run(None, {images: input_tensor}) # 解析输出画框判断是否有缺陷 print(f推理完成输出shape: {outputs[0].shape})这段代码的关键在于输入预处理一定要和模型训练时的流程一致——包括归一化方式、通道顺序、输入尺寸任何一项不一致都会造成推理结果严重劣化甚至形状报错。我在现场见到的推理异常有相当大比例不是模型本身的问题而是预处理不同步导致的。实际项目里建议把这个推理逻辑封装成类便于管理模型、推理参数和结果回调。对于实时视频流场景可以创建一个摄像头采集线程和推理线程用队列解耦避免采集阻塞推理。在7730U上跑YOLOv8n级别的模型CPU推理单帧大约50到80毫秒基本可以满足30帧以下的实时检测需求。3.5 让AI应用开机自启实现无人值守边缘项目交付时的最后一步是把AI服务固化到系统里让工控机开机后自动拉起服务不需要人工登录桌面。这一环节做好做坏直接影响项目的运维成本。Ollama本身自带systemd服务安装完就注册好了可以用systemctl status ollama确认状态。我们的AI业务程序则需要自己写一个systemd服务文件。创建一个/etc/systemd/system/ai-app.service文件[Unit] DescriptionEdge AI Application Afternetwork.target [Service] Typesimple Userindustrial WorkingDirectory/opt/ai-app ExecStart/usr/bin/python3 /opt/ai-app/main.py Restartalways RestartSec5 EnvironmentOLLAMA_HOST127.0.0.1:11434 [Install] WantedBymulti-user.target然后执行sudo systemctl daemon-reload sudo systemctl enable ai-app sudo systemctl start ai-app这个配置里比较重要的是Restartalways和RestartSec5这样程序崩溃后5秒会自动拉起弥补了工控机无人值守的最大风险——服务挂了没人发现。启动后建议定期用journalctl -u ai-app -f查看日志确认程序正常运行。4. 实测调优与资源占用7730U跑AI的真实水平与提速方案4.1 不同任务下的实测数据纸上谈兵没有意义我把同一台7730U工控机放在几个典型任务下实测了一遍数据供参考。任务模型推理框架内存占用响应/吞吐备注中文问答Qwen2.5-7B INT4Ollama CPU约5.8GB5-8 token/s16线程全开轻量问答Qwen2.5-1.5B INT4Ollama CPU约1.2GB20-30 token/s实时感明显目标检测YOLOv8nONNX Runtime CPU约0.8GB12-18 FPS640x640输入目标检测YOLOv8sONNX Runtime CPU约1.5GB5-8 FPS精度更高文本向量化bge-small-zhONNX Runtime CPU约0.5GB1.5ms/条知识库场景这个表说明两个事实。第一7730U完全可以跑当前主流的小参数模型但7B大语言模型会吃掉大部分内存和CPU资源这台机器只适合同时跑一个大模型。第二如果项目里既有视觉任务又有对话需求建议拆成两台工控机或者把对话模型降到1.5B级别勉强也能同机共存。4.2 提速的五个手段按性价比排序实测之后如果觉得速度不达标不要急着换硬件先把下面这些手段按顺序试一遍。第一开启双通道内存。7730U支持DDR4双通道很多工控机出厂只插了一条内存带宽减半。核显和CPU都要共享内存带宽单通道会让性能损失20%到30%。升级成两条内存开启双通道是性价比最高的提速方式。第二关闭节能模式拉高性能限制。工控机的BIOS默认往往偏向低功耗。进BIOS找到AMD CBS或者Performance相关选项把TDP上限调到28W开启PBO这类睿频功能CPU能稳定跑在更高频率上。注意散热要跟得上否则会撞温度墙实际收益有限。第三模型量化等级再压缩。比如从INT8压到INT4速度能再快一倍精度损失要看场景能不能接受。对话任务里INT4基本没问题视觉任务要实测评估检测框偏移一两像素在工业场景里可能就意味着误判。第四用核显参与计算。AMD平台在Windows下可以用DirectML执行器在Linux下可以尝试OpenCL路径。但这条路配置成本较高兼容性问题也多如果CPU推理已经基本达标不一定非要折腾。第五控制上下文长度和并发数。大语言模型的速度受上下文长度影响极大默认的4096长度会拖慢速度实际业务如果不需要那么长改小后性能提升明显。并发请求也会互相抢占CPU能用队列串行化就串行化。4.3 7x24运行的稳定性策略工控机最大的优势就是能长时间稳定运行但这不代表你可以不关注运行策略。AI推理和传统工控软件负载模式完全不同它是持续的CPU高强度计算对散热和电源是全新的考验。散热方面无风扇工控机的整机温度通常会比有风扇的机器高10到20度。我测过一台装7730U的无风扇机型在室温25度的环境下持续跑大模型CPU温度能稳定在75到85度之间摸外壳能明显感觉到烫手。这个温度对芯片来说是安全的但会导致频率比峰值低一些。如果项目需要长时间全速推理建议机房或机柜里给工控机增加一道通风效果立竿见影。存储方面也容易踩坑。AI模型文件动辄几个GB写入频繁时对存储可靠性要求很高建议不要用普通U盘或杂牌SD卡存放模型。正规工控机一般配M.2 NVMe固态哪怕用SATA固态也比闪存卡靠谱得多。另外定期清理Ollama的模型缓存能省出可观的磁盘空间。5. 常见问题与排查技巧实录现场踩坑全记录5.1 串口数据读不出来的排查顺序这是工控机项目里最爱出问题的环节问题往往出在接线、权限和配置三选一。整理一个排查顺序照着走基本能解决九成问题第一步用dmesg确认设备有没有被内核识别到没有识别先解决驱动和硬件连接。第二步用ls -l /dev/ttyUSB0查看设备权限确认当前用户在dialout组里。第三步用stty -F /dev/ttyUSB0设置波特率后尝试读取如果还不通检查杜邦线或DB9线序是否交叉串口线分直连和交叉两种很多现场是线序接反。第四步用万用表量一下设备端的TX/RX有没有电平变化判断是设备没发数据还是工控机没收到数据。如果一个串口要接多种设备接PLC的RS485和接扫码枪的RS232完全不是一个配置逻辑建议每个设备的接口参数都单独写进配置文件不要硬编码在代码里。5.2 推理服务内存溢出或崩溃边跑模型边做其他业务时内存不够导致进程被杀死是常见故障。尤其是同时跑7B模型和视觉模型的场景16GB内存经常吃紧。排查时先用free -h看内存和swap占用再用journalctl -xe查看OOM Killer日志。如果确认是内存不足最有效的方法就是降级模型尺寸1.5B或3B模型占用的资源远小于7B。另外可以调大swap空间作为兜底但要注意swap的I/O会拖慢推理速度只能应急不能长期依赖。此外Ollama默认会保持模型常驻内存如果多个模型来回切换会产生相当高的内存峰值。用ollama stop命令手动释放或者减少同时加载的模型数量能从根上控制内存压力。5.3 推理结果不准或时好时坏模型推理不准确的原因大部分不在模型本身而在预处理流程。比如图片尺寸缩放算法不一致或者色彩通道顺序错误。OpenCV默认是BGR模型训练时用的可能是RGB不做转换就会导致识别结果异常而且这种异常是偶发的极难排查。建议在推理代码里固定做好BGR到RGB的转换并且把预处理步骤做成单元测试。另一个容易被忽略的因素是版型差异。同一个从网上下载的YOLOv8模型如果导出时用了不同版本的工具链输出格式可能不同有的输出是张量有的输出是列表解析代码必须严格对应。把模型输入输出的shape以及语义写在项目文档里是给后面接手的人最大的善意。5.4 网络连接不稳定导致服务中断边缘工控机常部署在车间、户外机柜这类网络环境不太理想的位置有线网络偶尔断开是常态。如果AI服务依赖外部API调用断网就会导致业务中断。两条应对思路一是让模型完全本地推理不依赖外网二是给应用做断网缓存和自动重连机制。A股里有一句话叫“把命运握在自己手里”边缘AI也是一样的逻辑越少依赖外网落地越稳。6. 后续可能的扩展与新玩法这一波把工控机AI底座打好之后可玩的扩展方向非常多几乎每一个都能在现有基础上产生新的商业价值。多模型协同就是一个趋势。一台7730U工控机上同时部署一个视觉模型做质检、一个对话模型做运维问答再挂一个向量化模型做知识库检索配合Agent调度框架一台机器就能撑起一个小型智能工作站。这在过去是不可想象的资源密度。另一个方向是工控机AI Agent化。当大模型能调用工具和API工控机的角色就从“执行固定程序”升级为“能理解和决策的边缘智能体”。举个例子工控机读取到设备振动异常后不再只是上报数据而是让本地大模型分析故障可能的原因主动调取历史维护记录生成处置建议并通知运维人员。这个能力闭环如果跑通运维方式会发生质变。我还看到有人开始把多台工控机组成本地算力集群通过分布式推理框架把大模型切成多段在多台机器上协同运行。虽然目前技术成熟度还不高但方向很有吸引力等于用一台工控机的价格换到了成本更低的私有算力池。最后说一个跟开源社区结合的点。现在的开源模型更新速度非常快几乎每个月都有新模型可以部署。可以把模型仓库做成定时检查更新的机制结合自动评估脚本让边缘设备上的模型能力持续迭代。具备了这种持续进化能力的工控机才算真正站在了AI风口上。