今年跑了好几个工厂的质检项目最大的感受是工位上那块屏幕变了。以前AOI检测终端上显示的是红红绿绿的坐标框和缺陷代码操作工要翻手册才能知道这串代码到底什么意思。现在屏幕上是一段自然语言“左幅第12米处疑似断经形态特征为纵向连续缺口建议检查经纱张力。”操作工不仅能看懂还能直接回复一句“收到已通知前道”。屏幕上的这句话背后是整个系统的悄悄重写。这也是我一直在跟朋友强调的观点AI大模型给智能制造带来的不是“换了个更强的算法”而是一场真真切切的系统重构。数据怎么流、算力放在哪、工艺知识怎么存、人跟机器怎么说话全都在变。这篇文章把我在这轮重构里踩过的坑、验证过的方法以及大家问得最多的几个问题——本地部署配置怎么做、32G内存能不能跑、工业检测到底用多大模型才够——一次说清楚。1. 大模型进场先重写的是数据流转方式1.1 传统AOI的“判完就完”大模型时代走不通了传统工业视觉检测的数据流做了十年的人也都很熟悉相机拍照图像采集卡把数据送给检测算法算法算出缺陷坐标和类型结果写进PLC或者MES数据库坏品打个标记然后这张图基本就“死了”。有些工厂连原始图像都不存最多存个缩略图或者抽样图存三天就清掉。为什么因为没地方放更没什么用。但大模型落地之后这个链路第一次要求图像“活着”。我现在带的项目里数据流变成了这样相机拍照后图像先进入边缘推理盒子完成第一轮检测同时图像原始文件归档到集中存储多模态大模型对检出的缺陷区域生成自然语言描述和推理过程结果分两路走——一路转成结构化字段进MES做工单流转另一路连同图像、复判结论、工艺参数、温湿度环境数据一起写入训练数据集。这两路数据的跨度完全不同。过去MES只需要一个“OK/NG”标签现在要保留的是一整条证据链图像、模型输出、人工复判结论、处置结果、产品批次、机台号、工艺配方版本。为什么因为模型要持续迭代没有回流数据就没有优化基础质量追溯也需要在客户投诉后快速还原“当时模型看到了什么、为什么这么判”。这个重构的痛点在时间戳对齐上。相机时间、算法时间、PLC写入时间、MES记录时间往往是四套时钟偏差个几十毫秒平时无所谓但要做多模态训练数据对齐时差几秒就可能把图像和工艺参数错配。我们最后是统一在图像采集端打时间戳所有下游系统都以这个戳为准而不是各自取系统时间。1.2 从“画框”到“写句子”数据标注的粒度完全不同传统检测的数据标注是什么画框。标出缺陷位置选一个类型代码没了。一个熟练标注员一天可以标几十上百张图。但大模型的训练数据不可能这么粗糙。举服装检测的例子。以前电脑裁床前那道质检漏检率靠人工兜底算法只负责圈出“这里有问题”至于问题是跳针、断线还是油污那是一等品判定逻辑里的代码分支。现在要让大模型生成“左袖拼缝处线迹跳针长度约3cm疑似机针磨损导致”这种描述数据标注就得同时给出缺陷类别跳针形态描述连续跳针线迹不连贯长度约3cm位置语义左袖拼缝处距离袖口约8cm可能诱因机针磨损、缝线张力异常、布料硬挺度不够这些描述句的来源不能全靠算法工程师编必须让懂工艺的质检员参与。我见过不少项目在标注环节省人工结果是模型训练出来生成的描述句像“有个缺陷在某个位置”完全没法用。数据标注团队的构成应该是“算法人员定格式质检员定内容工艺员定结论口径”三拨人配合缺一不可。这也是系统重构很容易被忽略的部分车间里新增了一个“数据标注工艺员”岗位这批人既要会看缺陷又要能写出让模型学得懂的句子还要理解哪些描述会影响下游工单的处置逻辑。1.3 接口层重构MES、SCADA要能跟模型“对话”系统重构体感最强的地方在接口。以前MES跟视觉系统之间用的是标准字段判定结果就是一个枚举值质量报表直接拉数据就行。现在大模型输出的是自由文本加结构化JSONMES既要解释JSON还要把自由文本存下来给质量追溯用。我们在项目里给MES加了一个“语义通道”模型输出JSON字段走原有接口描述文本走新增的消息队列两部分用同一缺陷ID关联。这样做的原因是你不能指望MES那边立刻重构完老系统的稳定性还是要保住的。还有提示词跟工艺参数的绑定问题。同一台检测设备布料换了、机型换了提示词里的工艺参数模板就得跟着变。我们做过一次惨痛教训提示词版本没跟上产品切换模型还在用旧模板解释新工艺下的缺陷输出的原因分析全是错的。后来我们强制提示词模板必须带物料编码和工艺版本号切换产品时程序自动加载对应模板不匹配就拒绝推理。2. 云端、单机、边缘工业AI检测的算力选择题2.1 为什么多数工厂最后选了“训练集中、推理就地”“用的是云联网还是单机”这是很多第一次接触工业AI检测的人必问的问题。我的回答是没有一个标准答案但绝大多数工厂最后都会走到“训练集中推理就地”的混合架构上。背后的考量就三个变量。第一个变量是时延。产线节拍摆在那里一个检测工位300ms没出结果后面料就堆起来了。传统视觉检测要求单张图200毫秒内返回大模型推理哪怕量化加速本地跑也要算通信时间。这一条基本排除了“把图传到云端、等结果回来”的路径。第二个变量是数据边界。工厂里的工艺参数、新开发的产品图、原始缺陷图像都属于不能随便出园区的资产。很多客户要求模型推理解释必须在厂内完成训练数据脱敏后才能送到集中算力中心。不是技术做不到是商务和合规谈不拢。第三个变量是成本模型。云端按token计费的模式放在工业实时检测上算下来一年费用可能比买两台服务器还贵。所以最终的架构基本长这样训练在集中算力中心不管是自有机房还是私有云微调和评测也发生在那里推理放在产线边缘盒子或厂内服务器上模型更新通过夜间低峰批量下发。2.2 “什么大模型才够用”——不是越大越好被问到第二多的问题是“得用什么大模型才够”这个问题的标准答案是先看任务复杂度再看参数量不要一上来就上70B的大家伙。工业质检里最常见的是视觉缺陷识别加解释属于“看懂画面说人话”的任务。这种任务用一个7B到13B级别的多模态模型量化版就够了。我在服装检测项目里用的就是7B参数的视觉语言模型能完成缺陷类别判断、形态描述、位置指认三件事推理速度在24G显存上能做到单图两三秒。注意这跟“传统视觉200毫秒”不是一个定位——大模型在这里不是替代传统检测的超高速分类器而是做二次判定和语义解释的工位。什么样的场景需要上更大参数的模型我的判断是模型要融合大量规则做根因推理比如把缺陷图像、机台参数、工序流转信息、历史处置案例放一起回答“这批布连续出现横向疵点问题可能出在哪个工序”。这种复杂推理7B模型经常逻辑断裂13B到32B才压得住。量产前先拿小模型把流程跑通再评估要不要上大参数。不建议一上来就花几十万买双卡服务器跑大模型很多场景7B真的够了剩下的问题靠数据质量解决不靠模型尺寸。2.3 32G内存到底能不能装AI大模型这个话题在社区里反复出现我的回答是能装但你要分清楚内存和显存干的不是同一件事。32G内存的机器纯靠CPU推理跑7B量化模型能跑但慢得让你怀疑人生。一张工业检测图从预处理到推理完成可能要一分钟丢在产线上就是灾难。要是加上一张24G显存的消费级显卡32G内存作为系统内存就很宽裕了7B量化模型用起来舒服13B模型也能勉强推理但并发一高就捉襟见肘。具体到检测工位的配置我给一个经过验证的组合一张24G显存的GPU卡加32G内存跑7B多模态量化模型batch size设为1支持2到3个工位共用。这个配置能做什么缺陷描述生成、质量问答、单品检测解释都没问题。要是想做微调LoRA微调7B模型24G显存也能扛住。但想跑32B模型还要有富余的并发能力就得双卡或上40G以上显存的卡。这里有个容易被忽略的点模型加载后占用的显存不等于模型文件大小还有KV Cache和中间激活值。上下文长度设到4096还是8192显存占用差很多。工业场景根本用不到8192那么长的上下文设4096甚至2048就够了省下来的显存可以多放一路检测任务。3. 本地化部署实操配置、调优与“去限制”的真正含义3.1 一套可复用的检测类模型部署配置本地部署这事儿网上教程很多但大部分是聊天场景的部署教程一搬到工业现场就水土不服。工业场景的部署要求是模型要稳定输出JSON要能限定检测结论的类型和格式要能长期运行不崩。我现在的标准做法是用vLLM做推理服务因为工业现场需要高吞吐和可控的并发。一个简化版的部署参考# 以7B视觉语言模型为例生产环境建议走Docker docker run --gpus all -p 8000:8000 \ vllm/vllm-openai:latest \ --model Qwen/Qwen2.5-VL-7B-Instruct \ --gpu-memory-utilization 0.92 \ --max-model-len 4096 \ --dtype float16 \ --served-model-name industrial-vl启动后就是标准OpenAI接口调用端不用写复杂代码。from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:8000/v1, api_keylocal-key-insecure ) resp client.chat.completions.create( modelindustrial-vl, messages[{ role: user, content: [ {type: image, image_url: {url: file:///data/images/cut_001.jpg}}, {type: text, text: 请检测图中是否存在织物瑕疵。若有返回JSON{\defect\: true, \type\: \类型\, \desc\: \描述\}。若无返回{\defect\: false}} ] }], temperature0.1, max_tokens512 )参数上有几个坑需要提醒temperature一定要压低工业判定要求稳定0.1是上限值再高就会出现同一样品两次检测描述不一致的情况。max_model_len别贪大4096在质检解释场景足够省显存、提并发。gpu-memory-utilization设0.9左右比较稳设太高容易在并发峰值时OOM。3.2 “去限制”到底去的是什么哪些限制反而要加“AI本地大模型去掉限制”这个话题在搜索里的热度一直很高。我把话说清楚在本地部署语境下大家说的“去限制”通常指的是三件事——输出长度被默认截断、并发数太少、模型自带的回答约束模板太保守。这三件事都可以通过部署参数调整。输出长度把max_tokens从默认的几百调到1024或2048长文本输出就不会被腰斩。并发限制vLLM这类服务框架自己管并发把--max-num-seqs调上去就行。回答约束模板修改system prompt去掉过多的“作为AI助手我不能…”这类话术让模型专注于产线业务。但我要特别强调一点工业场景里有些“限制”不但不能去还要主动加上。最典型的是输出格式约束。模型要是输出一段自由文本而不是严格JSON下游MES解析直接报错工单就卡住了。所以我们不光不“去限制”反而在提示词里强制要求“只输出JSON不要解释不要客套”甚至在代码层做schema校验检测结果不在枚举列表内就自动触发行人复核。另一个要加的限制是模型行为边界。对“这个缺陷是怎么造成的”这类问题模型可以去推理但要限定在工艺参数范围内不允许给出“换设备”“找供应商理论”这种建议。这些边界写死在提示词模板里交给不同的角色用。3.3 部署里最容易被低估的工程问题版本、灰度、回滚模型文件动辄7GB到几十GB部署上线绝不是“拷过去跑起来”那么简单。工业现场讲究7x24小时稳定模型升级必须能做到灰度验证和快速回滚。我吃过一次大亏。那次做模型升级把量化等级从Q4换成了Q8准确率指标看着涨了结果同一批布的判级结果比旧版本偏移了2%——这2%在高速产线上意味着可能有几十米布被误判。好在当时做了灰度先拿一个工位跑了一下午发现偏移后直接回滚没造成批量质量事故。从那以后我定了三条规矩模型每个版本必须带配置清单模型文件、量化等级、提示词模板、评测结果、上线时间升级时先在隔离工位灰度跑至少一个班次回滚操作要在部署脚本里一键完成不能靠人肉改路径。另外多模型并存时按产线做显存隔离不要让一个模型的并发峰值把其他产线的推理挤垮。4. 重构的另一半工艺知识从老师傅脑里搬到系统里4.1 从“判级”到“解释”质检报告第一次不用翻译传统质检报告是给工程师看的一串缺陷代码几个坐标值。一线操作工拿到手根本看不懂得老师傅来翻译“这个代码是说纬向有横档大概率是停机档你去看下纬纱张力。”大模型改变的不只是识别准确率而是报告本身。现在模型输出的是“该区域存在横档形态呈纬向宽幅色差覆盖约15cm常见诱因包括停机后开车产生的纬纱堆积”这句话从质量工程师到操作工到仓库管理员都能读懂。质量例会也从“对着代码表念数据”变成了“讨论原因和对策”沟通成本肉眼可见地降了。这也改变了工单流转方式。以前复判员看到NG要么机械地填报废要么等工程师来看。现在模型能给出初步原因定位和处置建议复判员可以直接选择“按建议执行”或“提交人工复核”判断速度提了一大截。4.2 老师的经验怎么变成可检索的知识资产这块是我认为本轮重构里最有价值的部分。大模型在工厂里最深的落地不是替代任何人而是把老师傅脑子里的经验结构化。纺织厂的老班长能从布面上的一个疵点判断是“清花工序的给棉罗拉间隙大了”还是“梳棉机的针布钝了”你问他为什么他说“看多了就知道了”。这种经验最难传承。我们的做法是组织工艺员把过去三年质量事故的处理记录整理成结构化问答对每个条目包含缺陷形态、出现工序、可能成因、处置动作、验证结果存进向量数据库。之后模型在检测中遇到相似缺陷会先检索这批知识库里的历史案例再结合当前图像生成原因分析和处置建议。新人操作工面对瑕疵不再只能干等老师傅而是先看系统的初步判断再拿不准时找师傅确认。老班长的经验第一次以“可检索、可复制”的形式留在系统里。这个过程中最大的坑是知识库里“正确答案”打架。不同师傅对同一类缺陷的处置习惯不一样整理时如果不统一口径RAG检索出来就是自相矛盾的答案。我们花了两周时间做知识条目评审每条都要写清适用前提、处置优先级、效果边界。4.3 大模型应用开发的门槛到底在哪很多朋友问我“AI大模型应用开发怎么学有没有推荐的教程PDF”我的建议是别一上来就啃模型训练的论文那些内容离工业落地太远。真正的门槛在三个地方提示词工程、检索增强RAG、输出约束设计。提示词工程不是“写一段漂亮的prompt”而是把工艺规则翻译成模型能执行的指令包括字段口径、限定词、输出格式。RAG解决的是模型“不知道你们厂这个具体情况”的问题需要用历史案例和工艺手册搭知识底座。输出约束则直接用代码保障模型不会乱说检测结果必须落在规定枚举值里描述部分才允许自由发挥。我给一个最小落地路径供参考选一个场景——频率高、经验明确、人工复核成本大的工序最好。整理一百条历史案例做知识库选一个7B多模态模型跑通“图像加检索加问答”链路先让模型输出建议人工复核再决定采不采纳。跑一个月统计采纳率和误判率再决定要不要扩场景。这条路走完你比啃十本教程都管用。5. 算清这笔账成本、人员与边界5.1 成本大头不在显卡在数据治理很多团队上大模型第一反应是买卡、买服务器。实际跑完一个项目你会发现硬件成本可能只占三分之一。我做过一个粗略统计一个中等规模的质检场景上大模型人力投入分布大致是这样数据采集、清洗、标注、格式转换占50%部署、接口改造、系统集成占25%模型训练、调优、评测占15%上线后的运营迭代占10%。数据治理为什么这么贵因为产线上的图像、判级结果、工艺参数、复判记录分散在五六套系统里格式五花八门有Excel、有CSV、有老数据库导出光是拉齐、去重、对齐时间戳就够项目组忙两个月。这不是算法能解决的问题是脏活累活。很多项目死在半路上不是模型不行是数据始终凑不齐。想上大模型的团队要有心理准备最大的投入不是算法团队是数据工程团队。5.2 人员结构变了岗位职责开始重新分工系统重构必然带来人员结构的调整。算法工程师的角色从“写检测逻辑”变成“做模型评测、设计数据流水线、调部署参数”新增了提示词工程师、知识库工程师车间里出现了数据标注工艺员。一线工人也在变。以前操作工是“看屏幕记代码翻手册”现在要能看懂模型的自然语言描述还要能判断模型的建议靠不靠谱。我们给操作工做培训时发现老师傅上手很快因为模型说的就是他们平时说的话反而是年轻人习惯“机器给什么就信什么”反而要多教一层判断意识。这套重构不是把人的经验去掉而是把人的经验变成模型的基础再由人来把关模型的输出。我自己的判断是未来真正稳定的工厂是人和模型互相校准的地方。5.3 效果评估先分清楚检出、解释、处置是三件事评估项目效果最容易犯的错误是只看算法准确率。工业上的准确率根本不是单点指标至少拆三层看。检出层模型能不能发现缺陷这里用传统检测指标检出率、误报率。解释层给出的原因分析和处置建议准不准这里看人工复核时“建议可直接采纳”的比例。处置层采纳建议后良率、返工率、处置时长有没有变化这是业务上真正关心的结果指标。这三个指标任何一层没跟上都说明系统链路有短板。我见过一个项目模型检测准确率99%但解释层采纳率不到50%因为知识库没整理好模型给出的原因分析驴唇不对马嘴。单看准确率的话这个项目差点被当成成功案例推广。5.4 边界感什么场景适合先上什么场景先别碰大模型不是万能的工业场景尤其要有边界感。适合先上大模型的场景有几个共通点判断标准依赖经验而不只是尺寸测量多品种小批量导致传统算法规则写不完需要给下游工序解释“为什么判废”人工复核成本高、老师傅经验难以复制。比如纺织品外观检测、服装缝制质量复核、设备报警信息语义化、跨工序质量追溯问答。不适合的场景也很明确高速运动目标的位置精确计算别用大模型做传统机器视觉又快又准毫秒级实时闭环控制让PLC去做如果现场连稳定网络和基础数据积累都没有先不要谈大模型。比较好的切入姿势是“人机协同”大模型辅助判断和解释不直接替代最终裁定权等跑顺几个场景了再逐步扩大自动化的比例。我在实际项目里最深的体会是这场所谓系统重构改的不只是技术栈更是车间里日常的协作方式。以前质量问题是“开单、报废、扯皮”现在是“AI给建议老师傅拍板新手跟着学”。有一位老班长在项目收尾时跟我说了一句话“这个模型把我三十年的经验装进去了但还差一点熟的工位我自己还是能看出来。”这话我特别认同。技术重构的终点不是机器取代人而是让每一个普通的判断都有据可依让每一个老师傅的经验都不至于随着退休带走。最后给想上车的团队一个小建议别急着买卡别急着选大模型先挑一条产线、一个工序把一个老师傅的经验整理成一百条问答。你整理完这三百个条目自然就知道这场重构该从哪开始了。