1. 邊緣算力升級(jí)背后的真實(shí)需求1.1 為什么工控機(jī)突然成了AI落地的香餑餑這兩年跟做工業(yè)自動(dòng)化的朋友聊天話題繞來(lái)繞去最后總會(huì)落到同一個(gè)點(diǎn)上算力到底放在哪。以前大家習(xí)慣了兩種模式要么把所有數(shù)據(jù)傳到云端服務(wù)器處理要么在設(shè)備端用單片機(jī)做點(diǎn)簡(jiǎn)單的邏輯判斷。但這兩種方式在當(dāng)下的項(xiàng)目里越來(lái)越不夠用了。云端方案的問(wèn)題在于延遲和帶寬。一條產(chǎn)線上的視覺(jué)檢測(cè)設(shè)備每分鐘要拍幾百?gòu)埜咔鍒D片全部往上傳網(wǎng)絡(luò)稍微抖動(dòng)一下產(chǎn)線就得停。而且很多工廠的現(xiàn)場(chǎng)環(huán)境根本不允許把生產(chǎn)數(shù)據(jù)往外傳數(shù)據(jù)必須留在本地。單片機(jī)方案的問(wèn)題更直接算力太弱跑個(gè)簡(jiǎn)單的閾值判斷還行一旦涉及到圖像識(shí)別、振動(dòng)分析、預(yù)測(cè)性維護(hù)這些AI任務(wù)根本帶不動(dòng)。工控機(jī)站上AI風(fēng)口本質(zhì)上是因?yàn)樗ㄔ诹艘粋€(gè)非常微妙的位置上。它比單片機(jī)強(qiáng)太多有完整的x86或ARM架構(gòu)能跑完整的操作系統(tǒng)能裝GPU或NPU加速卡同時(shí)它又比云端服務(wù)器更貼近現(xiàn)場(chǎng)可以放在產(chǎn)線旁邊的電控柜里直接接傳感器和執(zhí)行器數(shù)據(jù)不出廠區(qū)就能完成推理。這種“邊緣算力”的定位恰好滿足了當(dāng)前工業(yè)場(chǎng)景對(duì)實(shí)時(shí)性、數(shù)據(jù)隱私和成本控制的綜合需求。我見(jiàn)過(guò)一個(gè)典型的案例某汽車(chē)零部件工廠在質(zhì)檢環(huán)節(jié)部署了基于工控機(jī)的AI視覺(jué)系統(tǒng)。以前用人工目檢一個(gè)班次需要四個(gè)質(zhì)檢員漏檢率在百分之三左右。換成工控機(jī)加工業(yè)相機(jī)加輕量級(jí)深度學(xué)習(xí)模型之后單臺(tái)設(shè)備就能覆蓋整條產(chǎn)線推理延遲控制在五十毫秒以內(nèi)漏檢率降到了千分之五以下。這個(gè)項(xiàng)目里用的工控機(jī)并不是什么高端型號(hào)就是一臺(tái)搭載了AMD嵌入式處理器的無(wú)風(fēng)扇機(jī)型外加一張入門(mén)級(jí)推理卡。整套方案的成本比租用云端GPU實(shí)例三年的費(fèi)用還低。1.2 邊緣算力升級(jí)到底升的是什么很多人一聽(tīng)到“邊緣算力升級(jí)”第一反應(yīng)就是換更好的CPU、加更貴的顯卡。這個(gè)理解不能說(shuō)錯(cuò)但太片面了。邊緣算力的升級(jí)是一個(gè)系統(tǒng)工程至少包含四個(gè)層面。第一層是計(jì)算架構(gòu)的升級(jí)。以前工控機(jī)主要跑PLC邏輯或者簡(jiǎn)單的HMI界面CPU性能過(guò)剩但AI算力為零。現(xiàn)在需要在保持低功耗的前提下集成專門(mén)的矩陣運(yùn)算單元。AMD的7730U這類處理器之所以被頻繁提及就是因?yàn)樗谑逋叩蕉逋叩墓膮^(qū)間里提供了八核十六線程的計(jì)算能力同時(shí)集成的顯卡也具備一定的并行計(jì)算能力可以分擔(dān)輕量級(jí)推理任務(wù)。第二層是接口與擴(kuò)展能力的升級(jí)。邊緣AI設(shè)備需要接的東西太多了工業(yè)相機(jī)走USB3.0或GigE激光雷達(dá)走網(wǎng)口傳感器走RS485或CAN總線執(zhí)行機(jī)構(gòu)走GPIO。工控機(jī)如果接口不夠就得外掛一堆轉(zhuǎn)換器穩(wěn)定性直線下降。所以現(xiàn)在選型的時(shí)候串口數(shù)量、網(wǎng)口數(shù)量、USB口數(shù)量都是硬指標(biāo)。第三層是軟件棧的升級(jí)。以前工控機(jī)上跑個(gè)組態(tài)軟件就完事了現(xiàn)在要裝Docker、要跑Python推理腳本、要支持TensorRT或ONNX Runtime。操作系統(tǒng)從Windows CE換成了Ubuntu或者Windows 10 IoT開(kāi)發(fā)方式從梯形圖變成了Python加C混合編程。第四層是運(yùn)維方式的升級(jí)。邊緣設(shè)備分散在各個(gè)現(xiàn)場(chǎng)不可能每臺(tái)都接顯示器鍵盤(pán)去調(diào)試。遠(yuǎn)程部署、遠(yuǎn)程監(jiān)控、OTA升級(jí)這些能力在邊緣AI項(xiàng)目里是剛需。我見(jiàn)過(guò)太多項(xiàng)目因?yàn)闆](méi)做好遠(yuǎn)程運(yùn)維設(shè)備出問(wèn)題之后工程師要開(kāi)車(chē)幾百公里去現(xiàn)場(chǎng)插U盤(pán)重裝系統(tǒng)。1.3 哪些場(chǎng)景最適合用工控機(jī)做AI推理不是所有AI任務(wù)都適合放在工控機(jī)上跑。根據(jù)我這幾年接觸的項(xiàng)目以下幾類場(chǎng)景的匹配度最高。工業(yè)視覺(jué)檢測(cè)是最大的應(yīng)用場(chǎng)景。包括表面缺陷檢測(cè)、尺寸測(cè)量、字符識(shí)別、裝配驗(yàn)證等。這類任務(wù)的特點(diǎn)是模型相對(duì)固定輸入是圖像輸出是分類或回歸結(jié)果對(duì)延遲要求高但對(duì)模型復(fù)雜度要求不高。用YOLO系列或者M(jìn)obileNet系列的小模型在工控機(jī)上配合入門(mén)級(jí)推理卡就能跑到實(shí)時(shí)。設(shè)備預(yù)測(cè)性維護(hù)是另一個(gè)快速增長(zhǎng)的方向。通過(guò)振動(dòng)傳感器、溫度傳感器、電流傳感器采集設(shè)備運(yùn)行數(shù)據(jù)在工控機(jī)上跑異常檢測(cè)算法提前發(fā)現(xiàn)軸承磨損、電機(jī)失衡等問(wèn)題。這類任務(wù)的數(shù)據(jù)量不大但需要長(zhǎng)期穩(wěn)定運(yùn)行對(duì)工控機(jī)的可靠性和散熱設(shè)計(jì)有要求。邊緣側(cè)的語(yǔ)音交互也開(kāi)始出現(xiàn)在工業(yè)場(chǎng)景里。比如工人戴著降噪耳機(jī)通過(guò)語(yǔ)音指令查詢?cè)O(shè)備狀態(tài)或者錄入質(zhì)檢結(jié)果。這需要在本地完成語(yǔ)音喚醒和命令詞識(shí)別不能依賴云端因?yàn)檐?chē)間里網(wǎng)絡(luò)覆蓋不一定好。AGV和移動(dòng)機(jī)器人的本地決策同樣依賴邊緣算力。AGV上的工控機(jī)需要實(shí)時(shí)處理激光雷達(dá)點(diǎn)云、攝像頭圖像和里程計(jì)數(shù)據(jù)完成SLAM和路徑規(guī)劃。這類場(chǎng)景對(duì)功耗和體積的要求比固定式設(shè)備更苛刻。注意如果你的AI模型參數(shù)量超過(guò)一億或者需要跑大語(yǔ)言模型做復(fù)雜推理工控機(jī)的邊緣算力大概率不夠用。這時(shí)候要么用更強(qiáng)大的邊緣服務(wù)器要么采用云邊協(xié)同的架構(gòu)把重任務(wù)放云端輕任務(wù)放邊緣。2. 工控機(jī)選型與AI部署的核心細(xì)節(jié)2.1 處理器怎么選從AMD 7730U說(shuō)起選工控機(jī)做AI推理處理器是第一個(gè)要過(guò)的關(guān)。市面上主流的方案有Intel的酷睿系列、AMD的銳龍嵌入式系列、還有各種ARM架構(gòu)的芯片。最近被頻繁問(wèn)到的AMD 7730U我專門(mén)拿了一臺(tái)樣機(jī)做了兩周的測(cè)試這里把真實(shí)感受說(shuō)一下。7730U是一顆八核十六線程的移動(dòng)端處理器基礎(chǔ)頻率兩吉赫茲加速頻率能到四點(diǎn)五吉赫茲集成Radeon顯卡TDP默認(rèn)十五瓦可以配置到二十五瓦。放在工控機(jī)里這個(gè)功耗水平意味著可以用無(wú)風(fēng)扇或者小風(fēng)扇的散熱方案整機(jī)體積能控制得很小。實(shí)際測(cè)試中我用它跑了幾個(gè)典型的邊緣AI任務(wù)。圖像分類方面ResNet-50模型在ONNX Runtime下的單張推理時(shí)間大約是四十毫秒換算下來(lái)二十五幀每秒對(duì)于大部分質(zhì)檢場(chǎng)景夠用了。目標(biāo)檢測(cè)方面YOLOv5s模型輸入六百四十乘六百四十推理時(shí)間約六十五毫秒十五幀每秒如果產(chǎn)線速度不快也能接受。如果是更輕量的YOLOv5n能跑到三十幀以上。跟同價(jià)位的Intel方案比7730U的優(yōu)勢(shì)在于多核性能和集成顯卡的并行計(jì)算能力。劣勢(shì)在于某些工業(yè)軟件對(duì)AMD平臺(tái)的兼容性不如Intel比如一些老版本的Halcon或者VisionPro在AMD平臺(tái)上偶爾會(huì)出現(xiàn)指令集不兼容的問(wèn)題。所以如果你的項(xiàng)目要用到特定的商業(yè)視覺(jué)軟件選型前一定要確認(rèn)兼容性。選處理器的核心邏輯是先確定你的AI模型需要多少算力再倒推處理器型號(hào)。不要反過(guò)來(lái)先買(mǎi)機(jī)器再想跑什么模型那樣很容易翻車(chē)。2.2 推理加速卡需不需要需要什么樣的工控機(jī)自帶的集成顯卡能跑一些輕量模型但如果你要跑稍微大一點(diǎn)的網(wǎng)絡(luò)或者對(duì)幀率有更高要求就需要加一張推理加速卡。目前主流的選擇有三類。入門(mén)級(jí)獨(dú)立顯卡比如英偉達(dá)的T400或者A2000。這類卡的優(yōu)勢(shì)是CUDA生態(tài)成熟TensorRT支持好幾乎所有主流深度學(xué)習(xí)框架都能無(wú)縫對(duì)接。T400的功耗只有三十瓦半高半長(zhǎng)能塞進(jìn)大部分工控機(jī)的擴(kuò)展槽里。實(shí)測(cè)跑YOLOv5s能到一百幀以上比集成顯卡快好幾倍。專用推理加速棒比如英特爾的神經(jīng)計(jì)算棒或者谷歌的Coral USB加速器。這類設(shè)備的優(yōu)勢(shì)是即插即用不需要額外的供電和散熱設(shè)計(jì)適合已經(jīng)部署好的工控機(jī)做后期升級(jí)。劣勢(shì)是算力有限而且對(duì)模型格式有要求需要先做轉(zhuǎn)換。國(guó)產(chǎn)NPU模組比如瑞芯微或者寒武紀(jì)的加速卡。這類方案在特定場(chǎng)景下性價(jià)比很高但軟件生態(tài)相對(duì)封閉模型部署的靈活性不如英偉達(dá)方案。如果你的項(xiàng)目對(duì)國(guó)產(chǎn)化有要求可以重點(diǎn)考慮。實(shí)操心得加裝推理卡之前一定要確認(rèn)工控機(jī)的電源功率是否夠用。我遇到過(guò)一臺(tái)工控機(jī)額定電源只有六十瓦加了一張三十瓦的卡之后滿載運(yùn)行時(shí)電源過(guò)熱保護(hù)系統(tǒng)頻繁重啟。后來(lái)?yè)Q了九十瓦的電源才穩(wěn)定下來(lái)。2.3 操作系統(tǒng)與軟件環(huán)境搭建工控機(jī)上跑AI操作系統(tǒng)的選擇直接影響后續(xù)的開(kāi)發(fā)效率和運(yùn)行穩(wěn)定性。目前主流的選擇是Ubuntu和Windows 10 IoT Enterprise。Ubuntu的優(yōu)勢(shì)在于對(duì)深度學(xué)習(xí)框架的支持最友好Docker、CUDA、TensorRT這些工具鏈在Linux下的性能和穩(wěn)定性都更好。而且Ubuntu可以裁剪得很精簡(jiǎn)去掉圖形界面之后系統(tǒng)資源占用極低適合長(zhǎng)期無(wú)人值守運(yùn)行。缺點(diǎn)是現(xiàn)場(chǎng)調(diào)試不如Windows方便很多工控現(xiàn)場(chǎng)的工程師習(xí)慣了Windows環(huán)境。Windows 10 IoT的優(yōu)勢(shì)在于兼容性好大部分工業(yè)軟件和組態(tài)軟件都能直接跑遠(yuǎn)程桌面調(diào)試也方便。缺點(diǎn)是系統(tǒng)更新不可控而且Windows下的推理性能通常比Linux低百分之十到二十。我的建議是如果項(xiàng)目允許優(yōu)先選Ubuntu。如果甲方或者現(xiàn)場(chǎng)運(yùn)維團(tuán)隊(duì)強(qiáng)烈要求Windows那就用Windows但一定要關(guān)閉自動(dòng)更新并且做好系統(tǒng)鏡像備份。軟件環(huán)境搭建的步驟以Ubuntu為例大致是這樣的# 更新系統(tǒng)包 sudo apt update sudo apt upgrade -y # 安裝Docker curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER # 安裝NVIDIA容器工具包如果使用NVIDIA推理卡 sudo apt install nvidia-docker2 sudo systemctl restart docker # 拉取推理鏡像 docker pull nvcr.io/nvidia/pytorch:23.10-py3這套流程我在多臺(tái)工控機(jī)上重復(fù)過(guò)基本不會(huì)出問(wèn)題。唯一需要注意的是如果工控機(jī)沒(méi)有聯(lián)網(wǎng)需要提前把Docker鏡像和依賴包下載好用U盤(pán)拷貝過(guò)去。2.4 模型轉(zhuǎn)換與推理優(yōu)化在工控機(jī)上跑AI模型跟在服務(wù)器上跑是兩碼事。服務(wù)器上你可以直接用PyTorch加載模型推理工控機(jī)上必須做優(yōu)化否則性能差得遠(yuǎn)。第一步是模型量化。把FP32的模型轉(zhuǎn)成FP16或者INT8推理速度能提升兩到四倍精度損失通常在百分之一以內(nèi)。用TensorRT或者ONNX Runtime的量化工具都能做。第二步是算子融合。把卷積、批歸一化、激活函數(shù)這些連續(xù)的操作合并成一個(gè)算子減少內(nèi)存訪問(wèn)次數(shù)。TensorRT會(huì)自動(dòng)做這個(gè)優(yōu)化ONNX Runtime也有類似的圖優(yōu)化。第三步是輸入尺寸調(diào)整。如果你的模型輸入是六百四十乘六百四十但實(shí)際場(chǎng)景中目標(biāo)只占圖像的一小部分可以考慮降低輸入分辨率或者用滑動(dòng)窗口的方式處理大圖。輸入尺寸從六百四十降到四百八十推理速度能提升將近一倍。第四步是批處理策略。如果工控機(jī)需要同時(shí)處理多路視頻流可以把多幀圖像拼成一個(gè)批次一起推理提高GPU利用率。但批處理會(huì)增加延遲需要根據(jù)實(shí)際場(chǎng)景權(quán)衡。# ONNX Runtime推理示例 import onnxruntime as ort import numpy as np # 加載量化后的模型 session ort.InferenceSession(model_int8.onnx) # 準(zhǔn)備輸入 input_name session.get_inputs()[0].name input_data np.random.randn(1, 3, 640, 640).astype(np.float32) # 推理 outputs session.run(None, {input_name: input_data})這段代碼在7730U的工控機(jī)上跑YOLOv5s量化模型能穩(wěn)定在二十幀以上。3. 從零搭建邊緣AI工控機(jī)的完整實(shí)操3.1 硬件組裝與系統(tǒng)安裝拿到工控機(jī)之后第一步是硬件組裝。如果是準(zhǔn)系統(tǒng)需要自己裝內(nèi)存和硬盤(pán)。內(nèi)存建議至少十六吉如果跑多個(gè)模型或者多路視頻三十二吉更穩(wěn)妥。硬盤(pán)建議用NVMe固態(tài)容量根據(jù)項(xiàng)目需求定一般五百吉起步。安裝Ubuntu系統(tǒng)的時(shí)候有幾個(gè)坑要注意。工控機(jī)通常沒(méi)有光驅(qū)需要用U盤(pán)啟動(dòng)。制作啟動(dòng)盤(pán)的時(shí)候用Rufus或者balenaEtcher都行但要注意分區(qū)格式選GPT還是MBR取決于工控機(jī)的BIOS模式。現(xiàn)在大部分工控機(jī)都支持UEFI選GPT就行。系統(tǒng)安裝過(guò)程中建議選擇最小化安裝不要裝桌面環(huán)境。如果確實(shí)需要圖形界面裝完之后再單獨(dú)安裝輕量級(jí)的桌面比如XFCE或者LXDE。Ubuntu Server版本默認(rèn)沒(méi)有圖形界面資源占用最低。安裝完成后第一件事是配置網(wǎng)絡(luò)和遠(yuǎn)程訪問(wèn)。工控機(jī)通常放在電控柜里沒(méi)有顯示器和鍵盤(pán)所以SSH是必須的。# 安裝SSH服務(wù) sudo apt install openssh-server sudo systemctl enable ssh sudo systemctl start ssh # 查看IP地址 ip addr show配置好SSH之后就可以通過(guò)網(wǎng)絡(luò)從開(kāi)發(fā)機(jī)遠(yuǎn)程登錄工控機(jī)了。如果現(xiàn)場(chǎng)網(wǎng)絡(luò)環(huán)境復(fù)雜還可以配置一個(gè)反向隧道或者內(nèi)網(wǎng)穿透工具方便遠(yuǎn)程維護(hù)。但要注意任何遠(yuǎn)程訪問(wèn)方案都要做好安全加固修改默認(rèn)端口、禁用密碼登錄、只允許密鑰認(rèn)證。3.2 串口數(shù)據(jù)采集與AI推理的配合工控機(jī)在工業(yè)現(xiàn)場(chǎng)經(jīng)常需要同時(shí)處理串口數(shù)據(jù)和AI推理。比如一個(gè)場(chǎng)景是工控機(jī)通過(guò)RS485讀取PLC的寄存器數(shù)據(jù)同時(shí)通過(guò)網(wǎng)口接收工業(yè)相機(jī)的圖像把兩者結(jié)合起來(lái)做判斷。Ubuntu下查看和配置串口常用的命令有這些# 查看所有串口設(shè)備 ls /dev/ttyS* ls /dev/ttyUSB* # 查看串口參數(shù) stty -F /dev/ttyUSB0 -a # 配置串口參數(shù) stty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb # 讀取串口數(shù)據(jù) cat /dev/ttyUSB0Python下用pyserial庫(kù)操作串口import serial import time ser serial.Serial( port/dev/ttyUSB0, baudrate115200, bytesizeserial.EIGHTBITS, parityserial.PARITY_NONE, stopbitsserial.STOPBITS_ONE, timeout1 ) while True: if ser.in_waiting 0: data ser.readline() # 處理數(shù)據(jù)送入AI模型 process_data(data) time.sleep(0.01)注意工控機(jī)的串口設(shè)備名可能會(huì)因?yàn)閁SB轉(zhuǎn)串口芯片的不同而變化。建議用udev規(guī)則給串口設(shè)備綁定固定的名稱避免每次重啟后設(shè)備名改變導(dǎo)致程序找不到串口。3.3 時(shí)間同步問(wèn)題的排查與解決沒(méi)有聯(lián)網(wǎng)的工控機(jī)時(shí)間不準(zhǔn)確這個(gè)問(wèn)題在邊緣設(shè)備里非常常見(jiàn)。原因通常有三個(gè)主板電池沒(méi)電了、系統(tǒng)沒(méi)有配置時(shí)間同步源、或者時(shí)區(qū)設(shè)置錯(cuò)誤。主板電池沒(méi)電是最常見(jiàn)的原因。工控機(jī)斷電之后RTC時(shí)鐘靠主板上的紐扣電池維持。電池電壓低于二點(diǎn)七伏之后RTC就會(huì)走不準(zhǔn)甚至停走。解決辦法很簡(jiǎn)單換一顆CR2032電池就行。但要注意有些工控機(jī)的電池是焊死的需要拆機(jī)更換。如果電池沒(méi)問(wèn)題那就是系統(tǒng)層面的配置問(wèn)題。Ubuntu下可以用timedatectl檢查時(shí)間狀態(tài)timedatectl status如果顯示“System clock synchronized: no”說(shuō)明沒(méi)有同步源。在沒(méi)有外網(wǎng)的環(huán)境下可以在局域網(wǎng)內(nèi)搭一個(gè)NTP服務(wù)器讓所有工控機(jī)都從這個(gè)服務(wù)器同步時(shí)間。如果連局域網(wǎng)都沒(méi)有那就只能靠RTC但RTC的精度會(huì)隨時(shí)間漂移需要定期手動(dòng)校準(zhǔn)。還有一個(gè)容易被忽略的點(diǎn)是時(shí)區(qū)。有些工控機(jī)默認(rèn)是UTC時(shí)間但現(xiàn)場(chǎng)操作人員看的是本地時(shí)間差八個(gè)小時(shí)。用下面的命令設(shè)置時(shí)區(qū)sudo timedatectl set-timezone Asia/Shanghai3.4 遠(yuǎn)程部署與OTA升級(jí)方案邊緣設(shè)備部署之后最頭疼的事情就是升級(jí)。如果只有幾臺(tái)設(shè)備手動(dòng)操作還能接受。如果有幾十上百臺(tái)必須有一套自動(dòng)化的部署和升級(jí)方案。我的做法是用Docker Compose管理應(yīng)用用Watchtower或者自己寫(xiě)的腳本做鏡像更新。每臺(tái)工控機(jī)上跑一個(gè)輕量的Agent定期從內(nèi)網(wǎng)的鏡像倉(cāng)庫(kù)拉取新版本鏡像然后重啟容器。# docker-compose.yml version: 3 services: ai-inference: image: registry.local/ai-inference:latest restart: always devices: - /dev/ttyUSB0:/dev/ttyUSB0 volumes: - ./models:/app/models - ./logs:/app/logs environment: - MODEL_PATH/app/models/yolov5s.onnx - CONFIDENCE_THRESHOLD0.5這套方案的好處是升級(jí)回滾都很方便。新版本有問(wèn)題把鏡像標(biāo)簽改回舊版本重啟容器就行。而且Docker隔離了運(yùn)行環(huán)境不會(huì)因?yàn)橄到y(tǒng)庫(kù)的變動(dòng)導(dǎo)致應(yīng)用跑不起來(lái)。OTA升級(jí)的時(shí)候要注意一定要做灰度發(fā)布。先升級(jí)一兩臺(tái)設(shè)備觀察二十四小時(shí)確認(rèn)沒(méi)問(wèn)題再全量推送。我見(jiàn)過(guò)一次全量升級(jí)導(dǎo)致所有設(shè)備同時(shí)重啟產(chǎn)線停了兩個(gè)小時(shí)損失很大。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 推理速度不達(dá)標(biāo)的排查思路模型在開(kāi)發(fā)機(jī)上跑得好好的部署到工控機(jī)上就慢得不行這是最常見(jiàn)的問(wèn)題。排查的時(shí)候按下面的順序來(lái)。先確認(rèn)工控機(jī)是否真的在用推理卡。有時(shí)候程序默認(rèn)用了CPU推理GPU在一邊閑著。用nvidia-smi或者radeontop查看GPU利用率如果一直是零那就是沒(méi)用上。再確認(rèn)模型是否做了優(yōu)化。直接拿PyTorch的FP32模型去推理速度肯定慢。檢查是否轉(zhuǎn)成了ONNX或者TensorRT是否做了量化。然后看輸入預(yù)處理是否成了瓶頸。圖像解碼、縮放、歸一化這些操作如果放在Python里做速度會(huì)很慢。盡量用GPU做預(yù)處理或者用OpenCV的CUDA加速版本。最后看散熱。工控機(jī)如果散熱設(shè)計(jì)不好處理器溫度上去之后會(huì)降頻性能直接砍半。用sensors命令查看溫度如果超過(guò)八十五度就要考慮加強(qiáng)散熱了?，F(xiàn)象可能原因排查方法解決措施GPU利用率零程序用了CPU推理查看代碼中device設(shè)置改為cuda或指定GPU推理速度只有開(kāi)發(fā)機(jī)一半模型未優(yōu)化檢查是否用量化模型轉(zhuǎn)TensorRT或ONNX INT8運(yùn)行幾分鐘后變慢處理器過(guò)熱降頻用sensors查看溫度加強(qiáng)散熱或降低功耗配置幀率波動(dòng)大內(nèi)存不足用free查看內(nèi)存占用增加內(nèi)存或減小批處理大小4.2 工控機(jī)穩(wěn)定性問(wèn)題的獨(dú)家避坑技巧工控機(jī)在實(shí)驗(yàn)室跑得好到了現(xiàn)場(chǎng)就各種問(wèn)題這個(gè)我踩過(guò)的坑太多了。說(shuō)幾個(gè)最典型的。電源問(wèn)題是第一大坑?，F(xiàn)場(chǎng)的電控柜里通常有變頻器、接觸器這些干擾源電源質(zhì)量很差。工控機(jī)如果直接用開(kāi)關(guān)電源供電很容易受到干擾導(dǎo)致重啟或者死機(jī)。解決辦法是加一個(gè)隔離電源模塊或者用帶濾波功能的工業(yè)電源。我現(xiàn)在的項(xiàng)目里一律用明緯的工業(yè)電源雖然貴一點(diǎn)但穩(wěn)定性好太多。接地問(wèn)題是第二大坑。工控機(jī)的金屬外殼一定要可靠接地否則靜電積累到一定程度會(huì)打壞接口芯片。我遇到過(guò)一臺(tái)工控機(jī)運(yùn)行了三個(gè)月之后USB口全部失效拆開(kāi)一看USB保護(hù)芯片被打穿了就是因?yàn)闆](méi)接地?；覊m問(wèn)題在粉塵環(huán)境里特別嚴(yán)重。無(wú)風(fēng)扇工控機(jī)靠外殼散熱灰塵積在散熱鰭片上之后散熱能力急劇下降。建議每半年清理一次用壓縮空氣吹。如果環(huán)境粉塵特別大考慮用帶正壓防塵設(shè)計(jì)的機(jī)箱。振動(dòng)問(wèn)題在移動(dòng)設(shè)備或者沖壓設(shè)備旁邊很常見(jiàn)。工控機(jī)里的內(nèi)存條、硬盤(pán)、擴(kuò)展卡在長(zhǎng)期振動(dòng)下可能松動(dòng)。解決辦法是用帶鎖扣的內(nèi)存插槽硬盤(pán)用M.2接口的擴(kuò)展卡用螺絲固定死。4.3 AI模型部署中的兼容性問(wèn)題工控機(jī)跑AI模型兼容性問(wèn)題主要集中在幾個(gè)地方。CUDA版本與驅(qū)動(dòng)版本不匹配是最常見(jiàn)的。TensorRT對(duì)CUDA版本有嚴(yán)格要求CUDA版本又對(duì)驅(qū)動(dòng)版本有要求。裝之前一定要查兼容性矩陣不要隨便裝最新版。我的經(jīng)驗(yàn)是用NVIDIA官方提供的Docker鏡像里面已經(jīng)把版本都配好了省心。ONNX算子不支持是第二常見(jiàn)的。有些模型用了比較新的算子ONNX Runtime或者TensorRT不支持轉(zhuǎn)換的時(shí)候會(huì)報(bào)錯(cuò)。解決辦法是用ONNX Simplifier做一下圖簡(jiǎn)化或者把不支持的算子替換成等價(jià)的組合。Python版本沖突也很煩人。工控機(jī)上可能已經(jīng)裝了Python 3.8但你的代碼需要Python 3.10。不要直接升級(jí)系統(tǒng)Python會(huì)搞壞系統(tǒng)工具。用conda或者pyenv創(chuàng)建一個(gè)獨(dú)立的環(huán)境。實(shí)操心得部署之前先在開(kāi)發(fā)機(jī)上用跟工控機(jī)相同的Docker鏡像跑一遍確認(rèn)沒(méi)問(wèn)題再往工控機(jī)上推。這樣可以排除百分之九十的環(huán)境問(wèn)題。4.4 邊緣設(shè)備遠(yuǎn)程運(yùn)維的實(shí)用方案最后說(shuō)一下遠(yuǎn)程運(yùn)維。邊緣設(shè)備分散在各個(gè)現(xiàn)場(chǎng)運(yùn)維成本很高。我目前用的方案是組合拳?；A(chǔ)層用SSH加密鑰認(rèn)證所有工控機(jī)統(tǒng)一配置禁用密碼登錄。中間層用Ansible做批量命令執(zhí)行和配置管理幾十臺(tái)設(shè)備同時(shí)操作也沒(méi)問(wèn)題。應(yīng)用層用Docker Compose加Watchtower做自動(dòng)更新。監(jiān)控層用Prometheus加Grafana每臺(tái)工控機(jī)上跑一個(gè)Node Exporter采集CPU、內(nèi)存、溫度、磁盤(pán)這些指標(biāo)在Grafana上統(tǒng)一展示。如果現(xiàn)場(chǎng)網(wǎng)絡(luò)不穩(wěn)定可以在工控機(jī)上跑一個(gè)輕量的MQTT客戶端把關(guān)鍵狀態(tài)數(shù)據(jù)發(fā)到內(nèi)網(wǎng)的MQTT Broker這樣即使SSH連不上也能通過(guò)MQTT了解設(shè)備狀態(tài)。這套方案我在多個(gè)項(xiàng)目里用過(guò)管理幾十臺(tái)邊緣設(shè)備基本不需要去現(xiàn)場(chǎng)。唯一的要求是現(xiàn)場(chǎng)網(wǎng)絡(luò)要通哪怕帶寬很小也行MQTT的消息量很小每秒幾KB就夠了。我個(gè)人在實(shí)際操作中的體會(huì)是邊緣AI工控機(jī)的項(xiàng)目硬件選型只占三成剩下七成都在軟件部署和運(yùn)維上。選一臺(tái)性能夠用的工控機(jī)不難難的是讓它在現(xiàn)場(chǎng)穩(wěn)定跑一年不出問(wèn)題。所以前期在散熱、電源、接地這些基礎(chǔ)工程上多花點(diǎn)心思后期能省下大量的運(yùn)維時(shí)間。另外模型優(yōu)化的工作一定要做不要指望工控機(jī)能直接跑開(kāi)發(fā)機(jī)上的原始模型量化、剪枝、算子融合這些步驟省不得。