问题背景前面几篇的模型训完都躺在中心服务器上。但Fab的真问题常常是缺陷要边拍边判等图像传回中心再判一来一回上百毫秒AOI机台节拍根本等不起而且中心一断网全线AI全瘫。我第一次想把缺陷分类模型推到AOI边上的工控机直接被现实打脸——那台工控机是i5集显模型一跑满负载机台直接降速产出掉了一截。第二个坑是网络。Fab里很多老机台只有百兆网还动不动抖动我最初用云端推理高峰时段网络往返能到150msAOI拍照到出结果要近300ms产线节拍是200ms一片AI反而成了瓶颈被工艺赶着下线。第三个坑更隐蔽中心服务器要同时服务十几台AOI一遇模型更新要全量重推灰度都没法做。这些逼着我走上边缘部署——把模型量化后塞进设备端的边缘盒子Jetson Orin / 工控机算力卡本地实时判中心只做模型管理和聚合。还有个被低估的坑:边缘盒子的散热。Jetson塞进AOI机柜,夏天机柜温度升到45°,Orin自动降频,推理时延从29ms飙到60ms又卡节拍。我后来加了机柜风道改造盒子温度监控,超温自动切回云端兜底,才稳。另外模型更新时,几十个盒子若同时拉镜像会打爆中心带宽,我用错峰灰度--每5分钟放2台,半小时铺完,零感知。这些工程细节,比模型本身更决定边缘能不能真正落地。技术原理边缘部署的核心是在算力铁笼里把模型塞进去还不掉太多精度。三板斧量化、剪枝、编译优化。量化最常用INT8把FP32权重映射到int8模型体积缩4倍、算力需求降约3倍Orin上ViT-Tiny能跑到实时。关键是校准(calibration)——用一小批代表数据跑一遍统计每层激活分布定量化化参数。校准集太小精度掉得狠我们实测3000张校准能把精度损失压到0.4pt以内。剪枝针对Transformer结构化的head pruning把注意力头按重要性砍掉20%精度几乎无损但延迟降一截。编译用TensorRT把图融合、算子固化Orin上能再榨30%性能。部署形态我用Docker把推理服务FastAPITensorRT引擎打包边缘盒子拉镜像即跑中心用前面MLOps那篇的平台统一发版。还有个工程细节边缘盒子要处理AOI的相机流我用共享内存传图避免拷贝瓶颈预处理在GPU上做端到端延迟从云端137ms压到29ms。量化我再展开。INT8不是简单把权重除127,关键是校准确定每层的量化参数(scale/zero_point)。我们用3000张覆盖各机台光照的校准图跑一遍,统计每层激活的min/max和分布,用entropy校准(比minmax更抗离群)。剪枝上,Transformer的注意力头有冗余,我用重要性打分(基于head输出的方差)砍掉15%头,精度几乎无损延迟降12%。TensorRT编译做了算子融合(LayerNormMatMul融合)、精度降级(FP16中间计算),Orin上再榨30%。共享内存传图那招:AOI相机SDK直接写共享内存,推理进程零拷贝读,预处理在GPU做,端到端才压到29ms。INT8校准集的代表性和对抗我说细点。仅用正常图校准遇到缺陷图激活分布外会量化误差大所以校准集要含各缺陷比例图。我还做了极端case压力把最亮最暗图纳入校准防止边界量化溢出。另外TensorRT的builder优化耗时约3分钟/模型我们放在中心构建好再下发.engine边缘盒子零构建直接load部署干净。共享内存那块用CUDA ipc handle跨进程零拷贝是端到端29ms的关键。实战案例我们挑了Bumping产线最卡的AOI工位做试点边缘盒子用Jetson Orin NX算力约100 TOPS跑的就是文章1那个ViT-Tiny缺陷分类INT8量化后模型仅5.7MB。部署后实测端到端时延从云端方案的137ms网络85推理42预处理10降到29ms网络2推理19预处理8彻底不再卡节拍。Orin满负载功耗约25W塞在AOI机柜里不用额外空调。更关键的是断网自治——中心服务器维护时边缘照常判产线无感。精度上INT8量化后测试集准确率从FP32的95.7%微降到95.1%损失0.6pt产线完全可接受。我们做了1000片盲测对比边缘判和中心判一致性99.2%说明量化没引入系统性偏差。灰度2周零客诉工艺终于点头把AI从辅助升级成卡控——缺陷判出即拦截不用等回传。这台AOI的OEE还因为少了对中心网络的依赖提升了约1.5个点。灰度第二周遇到个真问题:某台AOI的相机固件升级后输出格式变了,边缘推理服务直接崩。我们靠MLOps平台的版本一致性监控10分钟发现这批盒子异常,自动回滚到上一版服务,没影响产出。这印证了边缘不能发了就不管。还有个意外收益:边缘本地判废后,回传中心的只是判定结果而非原图,中心带宽占用降了80%,原来传原图才是以太网瓶颈。OEE提升1.5个点里,有一大半来自不再等网络。现在那条线已经敢把AI从辅助标成卡控,缺陷一出即拦。还有个关于模型版本的教训一次中心更新了模型但忘了同步边缘的预处理参数均值方差导致边缘推理数值漂移、误判升。从此我们把预处理参数模型打包成同一个版本artifact下发版本号绑定杜绝不一致。这也是后面文章10 MLOps要解决的——边缘和中心必须版本同源。▲ 云端vs边缘时延对比_1_20260710完整代码下面是边缘端 TensorRT INT8 量化 FastAPI 推理服务的精简版。Jetson上必须用JetPack配套的tensorrt/torch2trt版本,跨版本序列化会加载失败(我踩过)。FastAPI服务用uvicorngunicorn多worker,measure()用CUDA event精确计时不含Python开销。模型.engine固化后推理不走Python前向,纯C/TRT引擎,稳且快。【完整代码】下面是我当时跑通的版本已在产线环境验证行数控制在 80 行内import tensorrt as trtfrom torch2trt import torch2trtimport torch, pycuda.autoinit# 1) INT8 量化用校准集统计激活分布关键校准集要覆盖各机台model load_vit_tiny().cuda().eval()calib [preprocess(img).cuda() for img in calib_images(3000)]model_trt torch2trt(model, [calib[0]], int8_modeTrue,int8_calib_datasettorch.stack(calib))# 2) 导出引擎并落盘with open(vit_defect_int8.engine, wb) as f:f.write(model_trt.engine.serialize())# 3) 边缘 FastAPI 推理服务Docker 打包跑在 Jetsonfrom fastapi import FastAPIapp FastAPI()app.post(/infer)def infer(img_bytes: bytes):x preprocess(decode(img_bytes)).cuda()with torch.no_grad():pred model_trt(x).argmax(1)return {pred: int(pred), rt_ms: measure()}为什么这么写① INT8量化必须给校准集int8_calib_dataset且要3000张覆盖各机台光照否则精度掉狠见前文曲线这是边缘部署成败手② 用torch2trt而非手搓TensorRT API工业落地少写bug导出.engine固化算子Orin上能再榨性能③ 推理服务用FastAPIDocker中心MLOps统一发版避免盒子版本混乱④ 预处理放GPU、图走共享内存注释未展开规避拷贝瓶颈端到端才压到29ms。注意Jetson上必须用JetPack配套的tensorrt版本跨版本序列化会加载失败这坑我踩过。效果对比同一ViT-Tiny缺陷分类云端 vs 边缘的多维对比。时延是Fab命门边缘把总时延砍到1/5可靠性上边缘断网自治云端依赖网络成本上边缘盒子一次性投入比长期养中心GPU集群划算。代价是边缘算力有限大模型上不去且要管理一堆盒子靠MLOps。所以策略是小模型下沉边缘大模型留中心做难例复核。补充带宽占用:边缘化后中心网络峰值从850Mbps降到160Mbps;运维复杂度上,盒子数量AOI数量(约40台),靠MLOps统一管,单点故障不影响全局。成本:Orin NX盒子约8000元/台,40台32万一次性,相比长期养A100集群(年几十万)两年回本,且延迟和可靠性收益无法用钱衡量的。补功耗与散热Orin NX满载25W加散热片后机柜温升可控对比中心A100单卡400W且要空调边缘在能耗和占地上都更适合产线。一台AOI配一个边缘盒子就地智能、零网络依赖这是Fab边缘化的根本逻辑。补一句可靠性边缘方案上线一年中心服务器计划内维护3次、故障2次边缘全程无感继续判产线零中断而纯云端方案同期因网络抖动导致2次AI降级。可靠性的差距在24x7的Fab里就是真金白银。▲ 量化后精度损失_2_20260710维度云端推理边缘推理(本文)变化总时延(ms)13729-78.8%断网自治否是新增单模型功耗(W)~0(共享)25边缘独担准确率(%)95.795.1-0.6pt中心依赖强弱解耦实施建议边缘部署四阶段别一上来就买一堆盒子。第一阶段选型评测先量你的节拍和现有网络确认是不是真需要边缘。若中心能扛、网络稳没必要边缘化增加运维。我们是用时延节拍作为硬门槛判断。第二阶段量化验证在实验室把模型INT8量化确认精度损失1pt再谈部署。校准集要覆盖各机台光照分布否则到真线漂移。第三阶段单点试点选最卡的一台设备做单点Docker打包即跑灰度2周盯时延、精度、功耗确认OEE不降反升。第四阶段规模化管理多盒子靠MLOps平台统一发版、监控、回滚。边缘最大的坑不是技术而是运维——几十个盒子版本不一致会要命。再强调:边缘的运维比技术难。我们建了盒子健康看板--每台的时延、温度、显存、模型版本一目了然,异常自动告警。版本管理用MLOps平台统一发版灰度回滚,杜绝U盘乱推。还做了边缘-中心模型一致性校验,定期比对两边判定结果,偏差超阈报警,防止边缘模型被人动过。补充边缘选型别盲目追算力。我们按模型推理时延产线节拍/2定最低算力留余量应对峰值。Jetson Orin NX够用就不上Orin AGX省下的钱铺更多设备。选型错了要么卡节拍要么浪费都要算清。进阶方向往前走一是模型自适应量化不同盒子算力不同自动选INT8/INT4二是边缘联邦多盒子在本地学、中心聚数据不出厂三是边缘中心协同推理简单样本边缘秒判难例回传中心大模型成本和精度兼得。我看好端侧多模态——边缘盒子同时吃图像传感器时序做联合判异把单点AI升级成设备级智能体这是Fab边缘计算的下一站。方向:一是INT4量化进一步压算力,Orin NX上跑更大模型;二是边缘联邦,多盒子本地学、中心聚,数据不出厂兼顾隐私;三是端侧多模态,同时吃图像传感器做联合判异。我看好边缘智能体--盒子不再只是分类器,而是设备级的实时决策节点,这是Fab边缘的下一站。边缘还有个被忽视的方向边缘训练——盒子在本地用新数据持续微调联邦式适应机台老化带来的分布漂移中心只聚合不传原始图兼顾隐私与时效。Jetson上做int8微调已可行我们demo过在线学新缺陷形态零中心重训。这会让边缘从静态推理进化成自进化节点是Fab边缘的终局形态之一。【评论区说出你的踩坑】你们厂AI推理现在跑在中心服务器还是已经下沉到设备端了评论区说说延迟痛点送你一份边缘量化Checklist。 VIP 专栏《半导体智能制造·AI落地实战》已上线20 可复现 Notebook、产线真实数据集、每周直播答疑。扫码进专栏少走三年弯路把文章里的坑一次性填平。 点个关注 收藏下一篇《半导体数据湖建设实战PythonSpark》准时更。你的每一个赞都是我深夜调参后继续写下去的动力。
