企业官网建设流程全解析

这两年我在制造业圈子里听到最多的一个词就是AI，但说着说着就变成了“空中楼阁”。很多企业上了大屏、建了展厅、做了几个演示Demo，回头一看，真正能在车间里稳定跑起来、能算清投入产出比的场景少得可怜。问题出在哪？不是AI不行，而是底座没打好。

这篇文章我想和你聊的，就是制造业智能化转型里那个最不性感、但最要命的部分——底座建设。它不是讲某个算法有多牛，也不是帮你选某个大模型，而是把算力、数据、模型、平台这几层地基怎么搭、怎么选、怎么避坑，讲清楚。我会用这些年在一线踩过的坑、验证过的方法，给你一版可以直接参考的落地路径。

1. 制造业智能化转型，先弄清楚“底座”到底是什么

制造业做AI，和互联网公司做AI，本质上不是一回事。互联网公司从出生那天起就是数字化的，数据是自然沉淀的，用户行为、点击流、交易记录都在数据库里躺着。制造业不是这样，绝大多数企业的现状是：核心技术在设备里，经验在老师傅脑子里，数据散落在PLC、MES、ERP、Excel甚至纸质表单里。这种底子，直接上AI，等于在沙地上盖楼。

1.1 制造业AI落地，卡在三个地方

先说资金和硬件。一张工业级GPU卡动辄几万到几十万，一套像样的训练集群下来大几百万就没了。老板问你要多少预算，你不能只给个PPT。他真正想问的是三件事：到底要买什么样的硬件？买回来多久能回本？团队有没有能力把它用起来？

再说数据。制造业的数据天生就是脏的、乱的、断的。设备采样的时间戳不统一，同一个工件在MES里叫“A型壳体”，在质检系统里叫“机加工件A”，口径对不上。更麻烦的是，很多数据根本没有采集——老师傅拿卡尺量了尺寸，记在本子上，你上哪去做预测性维护？

最后是组织和流程。IT部门懂技术不懂业务，设备部门懂设备不懂数据，生产部门只看产量不看算法。三个部门之间没有共同语言，项目一启动就进入“互相拉扯”模式。我见过太多项目死在这上面——不是技术不行，是没人能对最终结果负责。

1.2 底座建设不是买硬件，是四层体系

我把智能制造AI转型的底座拆成四层，这四层缺一不可：

这四层之间是层层支撑的关系。数据底座做得不好，再强的算力也只是在空转；模型底座选型错了，平台底座再顺滑也发挥不出效果。很多企业一上来就买卡、训模型，结果发现数据出不来、业务对不上，最后卡在中间进退两难。所以，我的建议永远是：动辄谈大模型之前，先花三个月把底子摸清楚。

2. 算力底座：本地部署与云端租用怎么权衡

算力底座是花钱最凶的一层，也是老板最敏感的一层。做算力规划之前，必须想清楚一个前提：你的数据能不能出厂？制造业的数据涉及产品配方、工艺参数、客户订单，很多企业出于商业秘密和合规要求，根本不允许数据离开厂区。这一条就把很多企业推向了本地部署。

2.1 本地、云端、混合三种模式怎么选

我见过三类典型做法，各有各的适用场景：

**纯本地部署。**适合数据敏感度高、有专职运维团队、业务实时性要求高的企业。比如汽车零部件的视觉质检，图像数据必须在产线端处理，延迟超过几百毫秒就影响节拍，这种场景必须本地推理。缺点是前期投入大、扩容周期长，而且GPU集群的运维难度比普通服务器高一个档次。

**纯云端租用。**适合数据不敏感、业务以离线分析和研发为主、不希望背上资产包袱的企业。比如做工艺参数优化，用历史数据在云上训练模型，跑完就释放资源，按量付费。优点是弹性好，缺点是长期跑推理的话，费用并不比自建便宜，而且每次数据传输都有安全隐患。

**本地+云端混合。**这是目前制造企业里我比较推荐的方式——核心数据、核心模型推理放本地，研发探索、大模型的批量离线任务放云端。用一句话概括：训练可以在云上弹性跑，推理必须在本地稳定跑。

这里有个实际案例。我陪一家电子制造企业做过规划，他们的逻辑是：产线质检模型必须在本地跑，因为一秒都不能断；但新工艺的仿真分析、新产品的缺陷模式探索，这些计算量波动很大，放在云上按需租用，省了一大笔买卡钱。最后他们的算力预算比最初的方案省了40%左右，而且灵活性更高。

2.2 硬件选型的几个实操原则

给企业做算力规划时，我一般会按使用场景分三档：

硬件参数的细节，不同时期市场的产品差异很大，我就不列具体型号了，但有几个原则值得说：

第一，显存决定你的天花板。做视觉模型的，输入图像分辨率高、批量大，显存小了直接爆。做语言模型的，上下文长度、模型参数规模都是显存杀手。选卡的时候按当前需求的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模型分成三层：

这三层模型是并行共生的关系。视觉模型负责看，时序模型负责算，大模型负责读和写。比如一条智能产线：视觉模型发现工件表面的缺陷，时序模型判断某个参数有异常趋势，大模型把维修手册、历史故障记录、当天的报警信息汇总成一份检修建议，推送给老师傅。这才是制造业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底座建设，我总结了这些踩过的坑，希望你能绕开：

除了上表这些，还有几个心得值得多说两句：

**别一上来就搞大模型预训练。**如果你不是有几百张显卡、专门的算法团队和持续的数据供给，预训练这件事基本不用考虑。绝大多数制造企业的正确姿势是：基于开源模型做本地化适配，用RAG让模型学会企业知识，用微调让模型贴合特定业务场景，而不是从零造轮子。

**数据湖别做成数据沼泽。**没有规范和治理的数据湖，半年之后就是乱葬岗。我见过有企业把几十个系统的数据一股脑抽到数据湖里，没有任何分层和目录管理，三个月后数据团队自己都找不到数据在哪里。数据湖的规划一定要和应用场景绑定，用哪个场景，就先把哪个场景的数据治理好。

**别只买硬件，不建平台。**硬件是越用越旧的，平台是越用越厚的。我见过有些企业买了高配的训练服务器，结果半年下来使用率不到30%，因为没有平台工具支撑，算法工程师根本没法高效使用这些算力。硬件投入的ROI，是靠平台效率来兑现的。

写在最后

底座建设的本质，是用确定性去抵御不确定性。算力、数据、模型、平台，每一层都有成熟的方法和工具，关键是有些人愿意老老实实把每一层打好，而有些人只想跳过地基直接盖楼。时间会给出答案。

就我个人经验来说，制造业智能化转型这趟浑水，能趟过去的人，靠的不是技术多超前，而是对这些“不性感”的基础工作有多较真。先从最小的场景跑通，再横向复制，先让老板看到实实在在的ROI，再谈更大更远的蓝图。这个顺序，我建议你不要乱。