企业官网建设流程全解析

边缘算力这个词火了也有两三年，但真正让工控机站到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到6GB，CPU和核显都要满负荷工作。这让工控机的硬件设计面临一次底层重构：从追求低功耗稳定，转向在稳定前提下提供尽可能高的算力。

这个转变在芯片层面最明显。老一代平台还在用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.5GHz，TDP设计在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个支持RS485；USB 3.0/USB 3.1接口若干，用来接工业相机和外设；另外还有HDMI/DP显示输出，部分型号提供PCIe x4或x16扩展槽，可以插采集卡、运动控制卡或者独立AI加速卡。

接口布局上有两个细节值得注意。一是串口是否带隔离和保护电路，这决定了在工厂环境下会不会被共模电压击穿；二是网口芯片型号，有些机型标注千兆但实际用的是入门级Realtek芯片，长时间高负载下稳定性会差一些。我自己选型时会优先要求Intel芯片的网口，多花一点钱能少很多麻烦。

另一个重要因素是散热结构和供电。无风扇设计是工控机的标配，通过铝制鳍片或整机外壳散热。这对AI推理是双刃剑：好处是没有风扇故障、不怕灰尘，适合7x24小时无人值守；坏处是持续高强度推理时热量积聚，如果散热设计不佳，CPU会频繁降频，推理速度反而不如跑跑停停的场景。选择时可以关注机型有没有提供风扇扩展位或者额外的散热模块，给后面优化留一条后路。

2.3 主流工控机平台横向对比

为了让你有个坐标系，我把市面上常见的几类工控机平台放在一起对比。这里选的是我实际接触过的方案，参数以常见配置为准。

这个表格看下来，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搭配DML（DirectML）执行器也能调用Vega显卡进行计算。实测下来，7730U跑量化后的YOLOv8，CPU加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', baudrate=115200, bytesize=serial.EIGHTBITS, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, timeout=1 ) 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, json=payload) 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-directml（Windows）或者标准版CPU推理。下面以通用CPU推理代码为例，因为它的兼容性最好，实际部署时再根据硬件调整provider：

import 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, axis=0) # 执行推理 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] Description=Edge AI Application After=network.target [Service] Type=simple User=industrial WorkingDirectory=/opt/ai-app ExecStart=/usr/bin/python3 /opt/ai-app/main.py Restart=always RestartSec=5 Environment=OLLAMA_HOST=127.0.0.1:11434 [Install] WantedBy=multi-user.target

然后执行：

sudo systemctl daemon-reload sudo systemctl enable ai-app sudo systemctl start ai-app

这个配置里比较重要的是Restart=always和RestartSec=5，这样程序崩溃后5秒会自动拉起，弥补了工控机无人值守的最大风险——服务挂了没人发现。启动后建议定期用journalctl -u ai-app -f查看日志，确认程序正常运行。

4. 实测调优与资源占用：7730U跑AI的真实水平与提速方案

4.1 不同任务下的实测数据

纸上谈兵没有意义，我把同一台7730U工控机放在几个典型任务下实测了一遍，数据供参考。

这个表说明两个事实。第一，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风口上。