这两年我在制造业圈子里听到最多的一个词就是AI但说着说着就变成了“空中楼阁”。很多企业上了大屏、建了展厅、做了几个演示Demo回头一看真正能在车间里稳定跑起来、能算清投入产出比的场景少得可怜。问题出在哪不是AI不行而是底座没打好。这篇文章我想和你聊的就是制造业智能化转型里那个最不性感、但最要命的部分——底座建设。它不是讲某个算法有多牛也不是帮你选某个大模型而是把算力、数据、模型、平台这几层地基怎么搭、怎么选、怎么避坑讲清楚。我会用这些年在一线踩过的坑、验证过的方法给你一版可以直接参考的落地路径。1. 制造业智能化转型先弄清楚“底座”到底是什么制造业做AI和互联网公司做AI本质上不是一回事。互联网公司从出生那天起就是数字化的数据是自然沉淀的用户行为、点击流、交易记录都在数据库里躺着。制造业不是这样绝大多数企业的现状是核心技术在设备里经验在老师傅脑子里数据散落在PLC、MES、ERP、Excel甚至纸质表单里。这种底子直接上AI等于在沙地上盖楼。1.1 制造业AI落地卡在三个地方先说资金和硬件。一张工业级GPU卡动辄几万到几十万一套像样的训练集群下来大几百万就没了。老板问你要多少预算你不能只给个PPT。他真正想问的是三件事到底要买什么样的硬件买回来多久能回本团队有没有能力把它用起来再说数据。制造业的数据天生就是脏的、乱的、断的。设备采样的时间戳不统一同一个工件在MES里叫“A型壳体”在质检系统里叫“机加工件A”口径对不上。更麻烦的是很多数据根本没有采集——老师傅拿卡尺量了尺寸记在本子上你上哪去做预测性维护最后是组织和流程。IT部门懂技术不懂业务设备部门懂设备不懂数据生产部门只看产量不看算法。三个部门之间没有共同语言项目一启动就进入“互相拉扯”模式。我见过太多项目死在这上面——不是技术不行是没人能对最终结果负责。1.2 底座建设不是买硬件是四层体系我把智能制造AI转型的底座拆成四层这四层缺一不可层级核心内容解决什么问题算力底座GPU/CPU异构集群、存储、网络模型训练和推理跑在哪里数据底座采集、清洗、治理、标注、血缘AI能学到什么、学到的东西准不准模型底座模型选型、微调、推理优化、版本管理用什么模型、怎么让它符合业务平台底座MLOps、应用编排、安全审计模型怎么上线、怎么运维、怎么管这四层之间是层层支撑的关系。数据底座做得不好再强的算力也只是在空转模型底座选型错了平台底座再顺滑也发挥不出效果。很多企业一上来就买卡、训模型结果发现数据出不来、业务对不上最后卡在中间进退两难。所以我的建议永远是动辄谈大模型之前先花三个月把底子摸清楚。2. 算力底座本地部署与云端租用怎么权衡算力底座是花钱最凶的一层也是老板最敏感的一层。做算力规划之前必须想清楚一个前提你的数据能不能出厂制造业的数据涉及产品配方、工艺参数、客户订单很多企业出于商业秘密和合规要求根本不允许数据离开厂区。这一条就把很多企业推向了本地部署。2.1 本地、云端、混合三种模式怎么选我见过三类典型做法各有各的适用场景**纯本地部署。**适合数据敏感度高、有专职运维团队、业务实时性要求高的企业。比如汽车零部件的视觉质检图像数据必须在产线端处理延迟超过几百毫秒就影响节拍这种场景必须本地推理。缺点是前期投入大、扩容周期长而且GPU集群的运维难度比普通服务器高一个档次。**纯云端租用。**适合数据不敏感、业务以离线分析和研发为主、不希望背上资产包袱的企业。比如做工艺参数优化用历史数据在云上训练模型跑完就释放资源按量付费。优点是弹性好缺点是长期跑推理的话费用并不比自建便宜而且每次数据传输都有安全隐患。**本地云端混合。**这是目前制造企业里我比较推荐的方式——核心数据、核心模型推理放本地研发探索、大模型的批量离线任务放云端。用一句话概括训练可以在云上弹性跑推理必须在本地稳定跑。这里有个实际案例。我陪一家电子制造企业做过规划他们的逻辑是产线质检模型必须在本地跑因为一秒都不能断但新工艺的仿真分析、新产品的缺陷模式探索这些计算量波动很大放在云上按需租用省了一大笔买卡钱。最后他们的算力预算比最初的方案省了40%左右而且灵活性更高。2.2 硬件选型的几个实操原则给企业做算力规划时我一般会按使用场景分三档场景GPU配置参考适用业务边缘推理单卡/低功耗卡如RTX系列或工业级推理卡产线质检、设备振动监测单机训练推理1台服务器4~8卡如L20/A40级别私有模型微调、中等规模训练集群训练多台8卡服务器 并行存储大模型预训练、大规模多模态硬件参数的细节不同时期市场的产品差异很大我就不列具体型号了但有几个原则值得说第一显存决定你的天花板。做视觉模型的输入图像分辨率高、批量大显存小了直接爆。做语言模型的上下文长度、模型参数规模都是显存杀手。选卡的时候按当前需求的1.5倍预留别卡得太死。第二存储别省钱但也不用过度。制造业的数据量比不上互联网但训练数据的读取速度很关键。建议训练节点配NVMe盘冷数据放机械硬盘或者NAS没必要一上来就上全闪存储系统那个预算可以留给以后有需要时再用。第三网络是隐形瓶颈。单机多卡训练卡间通信决定效率多机训练集群网络就是命脉。小规模2台以内服务器用万兆以太网够用规模上去了再考虑更高速的方案不要一上来就上最贵的网络方案。注意供电和散热是本地部署最容易翻车的点。一台8卡服务器的功耗随随便便就是几千瓦起步你所在的厂房有没有预留足够的电量空调能不能压得住噪音和温度这些听起来很基础的问题在实际项目里真的能把人折腾到崩溃。3. 数据底座AI能学到什么取决于你喂它什么算力解决的是“能算”数据解决的是“算得准不准”。制造业数据底座的痛不是没有数据而是数据根本没法用。3.1 数据采集从设备里把数据掏出来制造业的数据源头大概可以分成三类设备层数据PLC、传感器、DCS、SCADA、业务层数据MES、ERP、QMS、WMS、外部数据天气、行情、供应链信息。设备层数据往往是“有没有”的问题——很多老设备根本没有数字化接口你只能加装传感器去采集。业务层数据则是“准不准”的问题——系统里录的和现场实际的经常对不上。采集这块通信协议是绕不开的坎。老设备走Modbus、OPC-UA新设备走EtherCAT、Profinet还有些专用设备只有厂家私有协议。打通这些协议有两种路线一种是采购工业网关把多种协议统一转成MQTT或OPC-UA上报到平台另一种是直接上采集软件在工控机上装Agent去读数据。我的经验是协议杂、设备老的情况下工业网关更省事设备比较新、协议统一的情况下软件Agent成本更低。3.2 数据质量治理脏数据比没有数据更可怕数据进来之后第一件事不是建模型是清洗。制造业数据的脏三句话说不完。采集时间戳对不齐——PLC里是毫秒级采样MES里是秒级ERP里按天算你要做时序分析就得重采样对齐。同一实体多个编码——一个物料在A系统叫“MA-1025”在B系统叫“壳体-铝-1025”在台账里叫“铝合金壳”要做关联就得先做实体对齐。我把数据治理的核心总结成三件事格式统一、缺失补齐、口径对齐。格式统一就是时间戳、数值单位、编码规则用同一套标准缺失补齐就是针对因停机或传感器故障导致的数据空洞做插值或标记口径对齐就是让各个系统对同一个业务概念有统一定义——这个最费时间因为要跟业务部门一个一个对。提示数据清洗不是一次性工作是要持续运转的流程。我见过太多企业花大力气做了一次数据治理没过半年又回到老样子。根源在于没有把数据质量的责任落到具体的人和系统上。我的建议是每条数据链路的入口就设置质量检查点不合格的直接拦截而不是等数据进了湖再说。3.3 数据标注与版本管理容易被忽视的隐形工程采到的图像、日志、振动波形只有打上标签才能训练模型。标注这件事听着简单做起来全是坑。缺陷检测场景里好的缺陷样本本来就少正负样本比例可能是千比一老师傅标注的标准还不统一同一张图张师傅标“划痕”李师傅标“压伤”模型直接学懵。标注层面的建议就三条先做标注规范文档配图配说明让所有人按同一套标准来再引入多人交叉标注有分歧的一律讨论到一致再入库最后做抽检和复核宁可少标也要标得准。数据版本管理也一样重要这个版本是改了标注、加了新样本还是调整过采样频率都要有据可查。训练的时候才发现数据有问题想追溯是哪个环节引入的没有版本管理就只能抓瞎。4. 模型底座不是所有场景都需要大模型模型底座这块最需要破除的迷信是AI转型 大模型转型。实际上制造业里90%以上的AI场景用的都不是大模型而是专门的、小而精的模型。4.1 模型分层大模型和小模型各干各的活我一般把制造业AI模型分成三层模型类型典型场景优点缺点工业视觉模型外观缺陷检测、OCR识别、安全行为识别精度高、延迟低需要标注数据、泛化能力有限时序预测模型设备预测性维护、质量参数预测、能耗优化数据要求低、解释性强对数据质量敏感大语言模型设备维修知识问答、工艺文档生成、售后客服理解能力强、知识面广幻觉风险、算力消耗大这三层模型是并行共生的关系。视觉模型负责看时序模型负责算大模型负责读和写。比如一条智能产线视觉模型发现工件表面的缺陷时序模型判断某个参数有异常趋势大模型把维修手册、历史故障记录、当天的报警信息汇总成一份检修建议推送给老师傅。这才是制造业AI的正确打开方式——各干各的活谁也别替代谁。4.2 大模型本地部署的实操路径如果确实要用大模型知识问答、文档分析、报告生成这些场景本地部署是制造业的主旋律。部署路径我建议按这个顺序走别跳步**第一步先上RAG别急着微调。**RAG检索增强生成的意思是让模型先去检索你企业自己的知识库检修手册、工艺规范、故障案例再基于检索结果生成答案。这样做的好处是对算力要求低、更新知识不需要重新训练、回答有出处、能有效降低幻觉。我见过很多企业一上来就微调模型花了大量算力结果过了一个月工艺规范更新了回答又错了还得再来一遍。**第二步理性选择模型尺寸。**7B、14B、32B、70B差别很大。7B的模型用一张消费级显卡就能跑起来14B需要专业级显卡70B以上的模型一张卡都放不下需要多卡并行。对绝大多数制造企业的文档问答场景7B~14B能力完全够用没必要一上来就追求最大尺寸。模型的大小选择取决于你要处理的任务复杂度以及你能接受多长的响应时间。**第三步用推理框架做加速。**裸跑的模型效率很低必须上推理框架。以目前生态较成熟的vLLM为例部署一个量化后的模型只要几条命令就能跑起来# 安装vllm建议在独立的conda环境里 pip install vllm # 启动一个OpenAI兼容的API服务 python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --tensor-parallel-size 2 \ --quantization awq \ --max-model-len 8192 \ --gpu-memory-utilization 0.9几个参数的意义--tensor-parallel-size指用几张卡并行推理--quantization指量化方式AWQ或GPTQ相当于给模型“瘦身”显存占用能降到原来的60%甚至更低--gpu-memory-utilization控制显存利用率。启动后你的业务系统就能通过标准的API接口调用大模型能力跟调用云端服务没有什么区别。这里有个经验之谈部署的时候一定要先做压测。拿线上真实的问题集去测试看并发上来之后响应时间怎么变化、显存够不够、需不需要加节点。有一家做设备远程运维的企业部署完之后在测试环境里表现很好一上生产就卡成PPT后来发现是并发请求直接把显存打满了最后加了两张卡才解决。注意本地部署大模型不是装完就结束了。模型要持续维护知识库要频繁更新新版本的模型要重新评估。所以在规划阶段就要把模型服务化、监控、生命周期管理这些事情考虑进去给模型底座一个长期运营的身份。5. 平台底座AI应用怎么上线、怎么管、怎么让人用起来底座建设的最后一层也是最容易被忽略的一层是平台。很多企业走完前三步模型训练出来了效果也不错结果卡在上线环节——模型在实验环境跑得好好的到了生产环境没人会用、没人敢用、没人维护最后变成一堆好看的报告。5.1 MLOps让模型像软件一样上线和运维AI模型上线和传统软件有个本质区别软件是写死的逻辑模型是会衰减的资产。车间换了新型号设备、工艺参数调整、原材料供应商变了模型的效果都会波动。这就需要一个完整的MLOps链路训练、评估、上线、监控、回流。训练阶段要记录每一次实验的参数、数据版本、评估指标评估阶段要设置可量化的阈值比如质检模型的漏检率必须低于千分之三才能上线上线阶段要做灰度发布先小流量跑一段时间效果稳定了再全量监控阶段要盯着模型的核心指标一旦漂移就触发告警回流阶段要把新产生的正确样本自动收进训练集。这几个环节光靠人工是做不起来的得靠平台化工具把流程固化下来。制造业的MLOps不需要做到多复杂很多互联网大厂的开源工具已经很好用了。关键不在于用哪个工具而在于把流程跑通哪怕是用最简单的脚本把“数据更新→模型重训→评估对比→发布”这个循环自动化也比每次手动操作强十倍。5.2 从试点到铺开先打透一个场景再谈规模平台底座还有一部分是组织和流程的支撑。我见过太多企业喜欢一上来规划十几个AI场景做完规划就一年过去了一个场景都没落地。正确的打开方式是选定一个痛点最明确、数据相对最好、ROI最容易算清的场景打透。比如一开始只做“关键设备的预测性维护”设定明确的KPI故障停机时间降低20%、备件库存下降15%。半年内把这一个场景做深做透形成一套从数据、模型、上线到运维的完整范式然后把这个范式复制到第二、第三个设备。做AI转型跟做其他变革一样一开始就需要一场轻松的胜利来建立信心——车间老师傅看到AI真的能提前三天预警故障后面的推广工作就顺畅了。组织层面我建议成立一个由业务、IT、数据三方组成的“铁三角”小组由分管生产的副总级别的人挂帅。没有业务侧深度参与的AI项目迟早会做成分散的试验品没有IT侧强力支撑的AI项目上线后就是各种基础设施问题的牺牲品没有数据侧专注投入的AI项目数据质量和模型效果永远无法突破。6. 常见问题与避坑清单做智能制造AI底座建设我总结了这些踩过的坑希望你能绕开常见问题可能原因排查思路GPU利用率低只有20%数据处理环节成为瓶颈模型太小/数据加载太慢检查数据读入链路适当加大Batch Size模型训练完效果还行一上线就拉胯训练数据和生产数据分布不一致数据漂移对比训练集和线上的特征分布建立数据漂移监控质检模型漏检率高训练样本中缺陷类型覆盖不全补充难例样本做数据增强采用基于半监督的方案本地大模型回答得慢模型参数过大或推理优化没做做量化、换更小尺寸的模型、用批处理方案业务部门不配合没有共同的KPI业务方觉得是IT的事把AI项目的目标与业务部门的考核指标绑定数据“干净”了一次又变脏数据治理没有嵌入日常流程在数据入口增加自动校验纳入日常运维职责老板问什么时候能赚钱项目缺乏分阶段的业务价值闭环把大目标拆成季度级里程碑每个阶段都交付可量化的业务结果除了上表这些还有几个心得值得多说两句**别一上来就搞大模型预训练。**如果你不是有几百张显卡、专门的算法团队和持续的数据供给预训练这件事基本不用考虑。绝大多数制造企业的正确姿势是基于开源模型做本地化适配用RAG让模型学会企业知识用微调让模型贴合特定业务场景而不是从零造轮子。**数据湖别做成数据沼泽。**没有规范和治理的数据湖半年之后就是乱葬岗。我见过有企业把几十个系统的数据一股脑抽到数据湖里没有任何分层和目录管理三个月后数据团队自己都找不到数据在哪里。数据湖的规划一定要和应用场景绑定用哪个场景就先把哪个场景的数据治理好。**别只买硬件不建平台。**硬件是越用越旧的平台是越用越厚的。我见过有些企业买了高配的训练服务器结果半年下来使用率不到30%因为没有平台工具支撑算法工程师根本没法高效使用这些算力。硬件投入的ROI是靠平台效率来兑现的。写在最后底座建设的本质是用确定性去抵御不确定性。算力、数据、模型、平台每一层都有成熟的方法和工具关键是有些人愿意老老实实把每一层打好而有些人只想跳过地基直接盖楼。时间会给出答案。就我个人经验来说制造业智能化转型这趟浑水能趟过去的人靠的不是技术多超前而是对这些“不性感”的基础工作有多较真。先从最小的场景跑通再横向复制先让老板看到实实在在的ROI再谈更大更远的蓝图。这个顺序我建议你不要乱。