前两天有个制造业的朋友微信上问我我们想上一个设备预测性维护的AI项目是不是先买几台A100就行我反问他你的设备数据能实时取出来吗维修记录有没有标准化一线工人愿不愿意在系统里点工单他沉默了半分钟回了一句好像还得先把底子打好。这句话其实点破了当前制造企业智能化转型最大的问题。AI不是空中楼阁不是装个开源大模型、跑通一个Demo就叫智能工厂。模型只是上层建筑能不能在产线上稳定干活取决于数据、算力、平台、组织这套底座牢不牢。我参与过多个制造企业的智能化项目评估和建设见过太多“上半场热闹、下半场烂尾”的例子这篇文章就把我自己的一套底座建设方法论完整拆开讲一讲。打算上AI的制造企业CIO、数字化负责人、工艺和IT工程师都能按里面的思路盘一盘自己的家底。1. 上层炫技、下层空心多数制造企业还没到“选模型”的阶段1.1 从Demo到产线之间的四道坎我发现一个规律几乎每个制造企业都有一段“Demo辉煌史”。供应商拿一批历史数据用Jupyter Notebook跑出90%以上的准确率领导看完当场拍板立项。等到真正接产线问题就冒出来了——数据源连不上、点表混乱、采上来的数据缺一大半、现场工人根本不信任系统建议。这不是模型不行而是底层有四个坎没跨过去。第一道坎是数据坎设备PLC没有联网、老设备没有通讯接口、点表命名随意数据根本没法形成资产第二道坎是算力坎企业没有GPU环境连一个能部署推理服务的容器平台都没有模型训练完没地方上线第三道坎是业务系统坎工单还是纸质流转质量报表靠Excel统计AI模型输出的结论没有系统承接第四道坎是组织坎项目挂在信息中心名下业务部门不参与、不买单效果好坏没人负责。很多企业拿着这些问题去问供应商供应商只会说“我们负责算法数据需要你们自己提供”。结果需求方和供应方互相踢皮球项目自然卡死在Demo阶段。1.2 制造业AI场景的五个硬约束为什么互联网公司做AI可以快节奏迭代制造企业不行因为工业现场有很多刚性约束和线上业务完全不一样。第一是误报率的容忍度极低。互联网推荐系统猜错了推荐内容损失很小但设备预测性维护如果一天误报十几次工程师很快就会把系统提示当噪音忽略甚至直接关掉。第二是时延要求高视觉质检在高速产线上必须在几百毫秒内给出判断没法把图片传回云端慢慢算。第三是可用性要求苛刻产线是7×24小时运行的AI服务挂了就得有人马上处理不能等第二天上班。第四是可解释性要求工艺工程师不接受一个“黑盒告诉你停机”他要知道是哪个特征异常、为什么报警。第五是数据安全边界很多工厂的数据不能出园区这决定了云上大模型API这条路在多数场景走不通。这些约束叠加起来就倒逼出一个结论制造企业需要的不是最前沿的模型而是一整套能把AI稳稳兜住的工程化底座。1.3 “底座”不是一套软件而是一套工程能力经常有企业问我买一套工业AI平台是不是就等于建好底座了我的回答是底座不是单纯软件是四个层次工程能力的组合。我习惯把底座拆成四层每一层都有明确要回答的问题底座层次要回答的核心问题典型建设内容数据底座AI吃什么数据能不能稳定、干净、实时地流到模型手里设备联网、数据采集、数据治理、时序存储算力与平台底座AI在哪跑训练和推理的资源够不够、稳不稳GPU集群、边缘推理、容器平台、模型服务模型与应用底座AI怎么用模型如何嵌入生产流程产生业务价值基础模型部署、RAG、Agent、专用模型组织与流程底座AI谁来管效果谁负责一线怎么愿用复合团队、评审机制、KPI、变革管理这四层缺一不可而且顺序不能乱。数据没通算力买了是浪费模型练出来了没有组织承接最后还是PPT。下面四章我按这个顺序把每一层的建设方法讲透。2. 数据底座让设备“说人话”比训练模型更花时间2.1 工业数据采集的“三通一平”做数据底座第一步是盘点现场的数据通路。我管这套动作叫“三通一平”通设备、通系统、通业务最后统一到一个时序数据平台上。通设备指的是把PLC、传感器、DCS、CNC这些底层设备的数据采上来。这里最常踩的坑是通讯协议不统一——老设备走MODBUS RTU新设备支持OPC UA还有一批设备厂商私有协议互相之间根本不通。我的建议是现场加装边缘采集网关用OPC UA作为统一上行协议底层协议由网关负责转换上层系统不需要关心现场是哪种设备。只要设备支持以太网通讯不管什么牌子都能被网关拉进同一个数据平面。通系统指的是把MES、ERP、SCADA、质量系统里的业务数据接进数据平台。设备数据告诉你“这台机床温度升高了”业务数据告诉你“这台机床这个小时正在加工哪个零件、用的哪套工艺参数”。只有把设备数据和业务数据关联起来模型才有条件做归因分析。最后是通业务这一步最容易被忽视。设备数据是点业务数据是线人的行为数据是面。维修工单是不是及时录入、报修原因写得规不规范直接决定后面的预测维修模型能不能训练出有效特征。这一步往往需要行政手段推动光靠技术部门做不了。2.2 数据质量的四维体检与标签体系数据采上来了不代表能用。我刚做工业项目时吃过一次亏用设备历史数据训练故障预测模型训练集准确率很高上线后白天正常、夜班误报率飙升。排查到最后发现夜班和白天加工的产品批次不同工艺参数差异很大而历史数据里的设备负载标签是错的。工业数据质量我建议从四个维度做体检。完整性点位有没有大面积缺失停机和换型时间段是否被标记一致性同一台设备在不同系统里的编码是否一致点表单位是否统一准确性传感器值是否在合理区间内有没有长期不变的“死数据”及时性数据从现场到平台的端到端时延是否满足场景需要体检之后要马上做的一件事是建立标签体系。我习惯把标签分三类设备标签产线、工段、设备型号、所属车间、产品标签产品型号、订单号、批次号、时间标签班次、是否换型、是否停机。标签体系越规范后面做数据切片和分析就越轻松。这里给一个点位定义的参考结构新建采集点建议按这个标准建{ point_id: Line1_A3_Spindle_Temperature, equipment_id: CNC_A3, source: opcua://192.168.1.10/ns2;sSpindleTemp, data_type: float, unit: ℃, sampling_rate_hz: 1, category: process_temperature }2.3 时序数据库与流批一体的选型制造业90%以上的AI场景数据都是时序数据温度、振动、电流、压力全是带时间戳的数值流。这类数据不能丢进传统关系型数据库硬扛要用专门的时序数据库。数据量可以先算一笔账假设一台设备采集1000个点位每秒采样一次每条数据按64字节算时间戳加数值加质量码一天的原始数据量约5.5GB。一条产线50台设备就是275GB一天一个月超过7TB。这还只是低频采样的量振动分析如果做到20kHz采样数据量再翻几个数量级。所以工程上一般不会把所有点位都高频采集加工过程参数用1Hz振动和电流做条件触发式高频采集这个分寸必须现场定。时序数据库选型我踩过不少坑给一个当前比较实用的参考数据库适合场景经验说明TDengine数据量超大、需要高压缩比国产开源MySQL风格接口对国内团队友好InfluxDB中小规模、生态丰富组件齐全但数据量很大时资源开销偏高Apache IoTDB与MES/流程工业集成较深支持文件导入和类SQL适合工厂内部数据管理同时还要搭一套流处理链路用Kafka承接采集网关上报的数据Flink做清洗、对齐、特征计算结果写入时序库和向量库。这个流批一体的架构是后面所有AI应用的“水龙头”。3. 算力底座买GPU之前先算清这四笔账3.1 推理算力估算从产线需求倒推很多企业采购GPU的思路是“买最好的”这恰恰是最大的浪费。算力建设要做的第一件事不是逛显卡市场而是从场景倒推开。我自己常用的方式是先把产线AI场景列出来再估算每个场景的实时并发和单路算力需求。拿工业视觉质检举例一条产线20台相机每台相机节拍2秒出一张图那么每秒需要处理10张图。假设目标模型在单张图上的推理延迟需要控制在300毫秒以内再考虑图像前后处理和算法冗余单张图大概需要2-4 TOPS的算力整条产线的推理算力需求就是20-40 TOPS。这个量级用一台高算力边缘工作站就能覆盖完全不需要上机架式GPU服务器。反过来如果是做设备预测维护处理的是1Hz的振动和温度数据用小规模的CPU加一张消费级GPU训练就够了。真正的算力大头只有两类场景一类是视觉大模型的批量训练另一类是企业级大语言模型私有化部署。我把常见场景的算力配置整理成一个表供参考场景类型实时性要求算力建议产线视觉质检毫秒级边缘推理盒或工作站单机覆盖数路相机设备预测维护秒级告警CPU服务器推理为主训练用单张GPU知识库问答秒级响应单张24GB GPU部署量化后的7B-14B模型企业级Agent应用秒级响应多卡GPU集群按并发用户数扩缩容3.2 集中式集群与边缘推理的分工算力底座第二个核心决策是训练和推理要不要分家中心和边缘怎么分工。我的原则很简单训练集中化推理边缘化。模型训练是长周期、重资源、低频次的任务放在中心机房或云上做用GPU集群跑跑完生成模型产物再下发到边缘。推理是高频、低延迟、有时限要求的任务必须在靠近设备的地方完成。工业场景里边缘推理不是可有可无而是刚需。一条轧钢产线做表面缺陷检测图传回中心机房再返回结果网络抖动几百毫秒产线早就把缺陷件压过去了。边缘网关兼顾两个职责一是协议转换和数据采集二是把AI推理能力像普通软件一样部署进去。中心侧的集群软件现阶段比较成熟的做法是Kubernetes加GPU插件配合模型服务框架提供统一推理接口。训练任务用作业方式提交推理服务用弹性部署方式运行两者的资源池在逻辑上隔离避免互相抢资源。3.3 推理优化与模型服务化很多算法团队把模型训练完丢给运维就完事了这是不对的。模型在实验环境能跑和在生产环境稳定服务中间差了整整一个优化和工程化阶段。推理上线前至少要过三关。第一关是格式转换把PyTorch模型转换成ONNX格式或用TensorRT做引擎优化推理速度通常能提升一倍以上。第二关是量化把FP16压到INT8显存占用和延迟都能大幅下降。但工业场景里量化要慎重尤其视觉质检对精度极敏感我的建议是先用INT8精度不达标再退回FP16不要为了省资源盲目上INT4。第三关是服务化把模型包装成标准接口统一走网关鉴权和限流。大语言模型的推理又不一样现在社区主流方案是vLLM这类推理框架。它在显存管理和连续批处理上做了大量优化同样一张卡能支撑的并发远高于原生方案。下面是一个我在本地环境常用的启动示例python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen2.5-14B-Instruct \ --served-model-name qwen2.5-14b \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --port 8000这一层做扎实之后模型上线就变成一次标准发布而不是每次都靠工程师临时调试。4. 模型与应用底座从通用大模型到工业场景的四级台阶4.1 通用大模型的私有化部署路线数据不出厂这个硬约束注定了制造企业的大语言模型要优先走私有化部署路线。现在开源模型的能力已经追得很紧尤其国内外的开源模型配合量化技术完全能在企业内部服务器上跑出可用的效果。模型选型我的思路是先定参数量再定具体模型。只是做知识库问答和文档摘要7B-14B参数量的模型量化后在单张24GB显卡上就能跑响应速度也好如果要做复杂的多步推理和Agent任务模型逻辑能力要求高就要上32B以上甚至70B级别的模型那通常需要4到8张卡。私有化部署不是装完就胜利后续还有模型更新和效果回归的问题。开源的7B模型半年就会迭代一版每次升级都要维护一套评测集验证新模型在本地业务问题上有没有退化。所以模型底座还要配一个模型仓库和评测流水线把这个过程标准化。很多企业一上来就问要不要微调我的建议是如果目标只是问答、摘要、知识检索先别微调把RAG做好再说。4.2 RAG把知识库变成模型的“外挂记忆”制造业企业最值钱的资产除了设备和工艺就是散落在老师傅脑子里和档案柜里的知识。设备维修手册、工艺规程、FMEA失效分析、历史故障案例这些文档过去根本没法被检索利用RAG技术把这个问题解决了。RAG的原理并不复杂先把文档切片用嵌入模型转成向量存入向量数据库用户提问时把问句转成向量去库里做相似度检索取出最相关的片段最后把片段和问题一起交给大语言模型让它基于这些材料生成回答。这套方案在企业落地的关键在两个方面。一是切片策略制造文档里大量内容是表格和操作步骤切碎了会丢失上下文我的经验是优先按章节、按表格行组合切配合重叠窗口。二是引用溯源生成答案一定要带上原文出处编号让工程师能点开原文核对这一步直接决定了业务人员会不会信任系统。我在实际项目里工程师对带引用的知识问答接受度明显高于不带引用的。4.3 Agent从“能聊天”到“能干活”知识问答只是大模型应用的第一层真正的工业价值在Agent也就是让模型能调用工具、驱动业务流程。我举一个已经落地的场景设备报修工单的智能辅助。设备报警后Agent先根据报警代码和实时数据做初步判断检索该设备历史维修记录和对应解决方案然后把一条带上下文信息的工单草稿推送到维修班组。维修人员只需要确认或修改一键提交维修完成后Agent再把结论自动归档沉淀到故障知识库。这一个流程把原来“老师傅查半天资料再手写工单”的时间压缩到十分之一以内。还有一类Agent需求增长很快是工业控制逻辑的代码生成辅助。比如工艺工程师描述“皮带启动后延时5秒若进料口无料则触发报警”大模型可以生成一份结构化控制逻辑初稿由PLC工程师审查确认后再实施。这里我必须强调涉及安全联锁的控制逻辑无论如何都要经过专业工程师人工审核和仿真验证AI只能当辅助工具。对于以Java技术栈为主的工厂IT团队集成这些Agent能力时可以考虑Spring AI这类框架把模型调用封装成标准服务复用现有开发体系学习成本低不少。4.4 工业专用模型视觉质检、预测维护与工艺优化大模型之外制造业真正解决生产问题的还是大量专用小模型。视觉质检、预测维护、工艺参数优化各自有成熟的技术路线。视觉质检是目前落地最广的场景。它的问题是数据样本不平衡——缺陷样本可能只占千分之一。我的建议是优先找历史留存的不良品图像先尽量凑齐主要缺陷类别合成数据做增强不要一上来就指望零样本解决所有问题。预测维护模型方面大家最容易忽略的是标签工程。故障标签不是简单从维修工单里取而是要把“换轴承”“做保养”这类事件结合停机时间段反推出故障发生前期的“状态窗口”。标签窗口给早了、给晚了模型学出来全是噪声准确率自然上不去。这一点纯算法团队如果没有人点拨很容易在错误标签上浪费几周时间。工艺参数优化类项目则要多目标取舍做在前面。质量、效率、能耗、寿命往往相互权衡做之前就要和业务方达成共识主目标是什么、约束条件是什么否则模型给出来的一组参数一线根本不敢用。5. 组织与流程底座比技术更难的是“谁对效果负责”5.1 复合型团队不是“招几个算法工程师”我一直认为制造业AI项目失败的深层原因通常不是技术而是组织上没有长出能承接技术的团队。很多企业以为AI团队就是算法工程师加IT运维这是很片面的。一个能打硬仗的智能制造团队至少要包含五类角色懂业务的负责人通常由工艺、设备或质量部门的骨干担任负责定义业务问题和验收标准数据工程师负责采集、清洗、建模前的大多数脏活累活算法工程师负责模型训练和优化而且必须愿意下车间看设备MLOps工程师负责把模型变成稳定运行的服务还有一名熟悉设备通讯的自动化工程师解决PLC协议对接这类卡脖子问题。这里面最关键的是“懂工艺的AI工程师”。我在项目里见过一位设备工程师转岗做算法他能把“轴承早期磨损”准确定义成“振动频谱中某一频段的能量增长”这种跨领域翻译能力是团队里最稀缺的。企业选人时与其招一个只会调参的名校应届生不如培养一个愿意学算法的老工艺工程师。5.2 评审机制与KPI别用“AI替代人”来立项组织底座还包括一套科学的立项和评审机制。制造业AI立项最容易犯的错误是把目标定成“替代工人”。这种说法一出来项目在内部就天然遇到抵抗而且很难量化验收。我建议立项时把目标改写成具体的经营指标设备综合效率OEE提升几个点、缺陷漏检率降到多少以下、误报率控制在什么水平、某类能耗降低多少。每条都要对应一个可采集、可对比基线的业务指标。评审节奏建议“双周一次”业务负责人看业务收益技术负责人看模型指标数据团队看数据质量变化。这里尤其要盯住模型误报率因为在线运行时的误报率往往比离线测试高出数倍必须在试点期坚决压下去否则项目会在推广前死掉。5.3 变革管理让一线愿意用、敢反馈再好的模型一线不用就是零。变革管理的核心是把系统的使用成本压到最低把价值反馈做得足够即时。第一不要额外增加一线操作工的数据录入负担。工单字段能自动带出的就别让手填现场备注能用语音转文字的就不用键盘打字。第二让AI建议直接出现在他该出现的地方。设备报警就把处理建议弹到班组长手机上而不是埋在看板系统深处。第三建立反馈闭环。工人反馈一次误报系统要能记录并从知识库中剔除错误建议让他感觉到自己的反馈有回音。做到了这三点一线的配合度会明显提高。6. 12个月落地路线图从家底盘点开始的四个阶段6.1 第1-3个月能力盘点与场景选择如果企业决心启动智能化底座建设我建议以12个月为一个完整周期来规划前3个月不买任何硬件只做摸底和规划。摸底要做三件事。一是数据摸底统计设备联网率、通讯协议分布、关键设备数据采集覆盖率、历史数据可追溯时长。二是场景摸底和工艺、设备、质量部门访谈列出现场痛点清单按“发生频率”“损失成本”“数据基础”“解决难度”四个维度打分。三是组织摸底盘点现有IT团队有哪些人、缺哪些能力明确业务方是否有意愿派骨干参与项目。场景选择是这一步的产成品。选场景的黄金法则是高频、高痛、有数、可控。不要选整个车间作为试点选一条产线、一个产品族、一类设备越小越好便于快速闭环。6.2 第4-9个月最小可行系统和试点验证第4个月开始建设原则是“先数据、后模型、再应用”。第一个月先打通试点产线的数据采集链路建好时序数据库和基础标签体系。这时不要贪多宁可点位少而准也不要接一堆无法保证质量的数据。第5-6个月进入模型开发阶段算法团队基于已采集的数据做特征工程和模型训练。第7-8个月做在线试运行模型和业务系统并行跑业务人员只看预测结果不下达操作重点记录模型在真实工况下的表现。第9个月做试点总结对照最初定下的KPI决定是扩大试点还是调整方向。这个阶段最需要盯住的是数据质量和模型的现场表现差距。如果离线指标和在线指标差距很小说明数据底座扎实如果差距很大大概率是数据分布变了要回到数据采集和特征工程去找原因不要把时间花在调参上。6.3 第10-12个月横向复制与运营固化试点验证通过后项目才真正进入有挑战的阶段——横向复制。很多企业在试点阶段很成功一推广就失控原因是复制条件没有定义清楚。我总结的复制三条件是数据一致、场景相似、流程成熟。数据一致指新产线的点位命名、采集频率、标签体系必须和试点产线统一场景相似指业务痛点和知识结构可复用流程成熟指数据录入、工单流转等业务动作已经标准化。三个条件缺一个复制过去的都不是能力而是麻烦。运营固化方面要明确AI系统的运维责任人建立模型监控看板跟踪推理服务的可用性、时延、数据质量指标设置模型效果定期回测机制。运营不是把系统上线就结束而是一个持续迭代的过程。6.4 预算与人力投入参考关于预算我给一个量级参考具体金额因企业规模差异很大但比例结构是可参考的投入方向预算占比常见误区数据采集与治理30%-40%预算全花在算法和算力上数据工程没钱算力基础设施20%-30%一开始就买大批GPU半年用不满模型与应用开发25%-35%外包开发但内部没人能承接运维组织与培训5%-10%完全忽略一线不会用导致项目失败人力上试点期一个场景配齐数据工程师、算法工程师、业务骨干各一人就足够支撑。我的经验是绝大多数项目花在数据准备上的精力占到70%算力和模型训练加起来不到30%。谁低估了数据工程的成本谁就会在后面付出代价。最后再分享一个我在项目里反复用到的判断标准当一个AI项目推进不下去的时候先别怪模型不够强先去看数据到了没有、业务系统接上了没有、业务负责人有没有真正参与。这三件事没有答案所有算法上的努力都是空中楼阁。底座建设没有捷径但这条路走过一遍之后后面再上任何AI应用都会比别人快上好几倍。