1. 先把概念掰开揉碎：内生AI和外挂AI到底指什么
工业AI选型最近聊得特别多，但我发现“内生AI”和“外挂AI”这两个提法，行业里真正能说清楚的人并不多。我第一次听到这两个词是在一次设备选型评审会上，供应商在演示文稿里放了一张对比图，左侧写“内生AI”，右侧写“外挂AI”，底下密密麻麻列了一堆参数。当时团队里几位老工程师的反应非常真实：听着有点道理，但真要落到采购清单和验收条款上，脑子里是一团浆糊。
这个词组听起来像是营销造出来的概念，但仔细琢磨之后会发现，它确实直指工业AI落地中最核心的一个决策点——AI的能力到底放在哪里。把这个分歧点想明白了，后面所有的参数对比、成本核算、运维规划才有了讨论的基点。
1.1 内生AI：AI是设备出厂就自带的能力
所谓内生AI，说的是AI推理能力在架构层面和设备本体深度融合，它不是外接的一个模块，而是设备出厂时就具备的原生属性。工业相机里内置了推理引擎，PLC控制器里集成了神经网络加速单元，边缘网关直接可以运行目标检测模型，这些形态都算内生AI。
它的核心特征是：感知、推理、结论输出整个链路封闭在设备内部，数据和结果都不出设备本体。
我举一个实际例子。某工厂的旋转设备振动监测项目里，我们部署了一批自带AI芯片的智能振动分析仪。这个设备内部集成了频谱分析和故障分类模型，传感器采集到的振动信号直接在设备端完成特征提取和模式识别，诊断结论就地生成并显示在设备屏幕上。现场不需要额外接服务器，不需要考虑网络布线，工人看一眼屏幕上的诊断码就知道这台设备是正常、预警还是故障。
工厂的设备维护人员当时评价说：“这东西就跟一个自带判定的温度计一样，读数出来，结论也出来了。”这个类比很形象——内生AI把“测量”和“判断”做进了一个整体。
这里有一个容易混淆的点需要澄清。某些设备厂商宣传自己支持AI，但实际是设备采集数据之后发给云端服务，云端算完再把结果推回设备端展示。这种方案在终端用户看来似乎“设备有AI”，但从架构上讲它其实是外挂AI，只是有一个集成度较高的前端而已。真正意义上的内生AI，要求推理过程发生在设备内部，设备断电或者脱离网络之后，AI能力依然可以工作。
1.2 外挂AI：AI从外部接入，盘活存量设备
外挂AI的形态与内生AI正好相反。AI能力不要求设备本身具备，而是通过独立于设备之外的系统来提供。这个独立的系统可能是一台服务器、一个工业AI平台、一组边缘计算节点，也可能是云端服务。设备要做的只是把数据送出去，再从外部拿回推理结果。
这种方式在存量设备改造中非常常见。很多制造企业产线上跑的是五年前、十年前采购的老设备，这些设备本身没有AI能力，甚至部分老设备的控制系统连标准化的数据接口都没有。全部换新设备在成本上不现实，于是就在旁边加装数据采集器，把设备运行数据送进一台AI推理服务器，由服务器上的模型做故障诊断、质量预测或者工艺优化，再把结果反馈给现场人员或者设备的控制系统。
举个现实的案例。有一条食品包装产线，十几台老式封口机分布在车间不同位置，设备厂家已经不支持软件升级，但设备机械状态仍然良好。我们团队在产线旁部署了一套外挂AI系统，通过加装传感器和数据网关采集封口温度、压力、速度等参数，用一台推理服务器做统一建模，实时判断每台封口机的热封质量趋势。操作员在产线工位上就能看到系统推送的预警信息，提前换模具、调温度，有效降低了封口不良率。
这个案例中，设备本身没有任何AI能力，但整个系统因为外部AI的接入而拥有了智能，这就是外挂AI的精髓所在。
1.3 两套方案本质上是两种架构思维
定义说完之后，我想把话往深里说一步。内生AI和外挂AI的差别，表层看是“推理算力放哪里”，深层看其实是两种完全不同的架构思维。
内生AI的架构思路是：感知、推理、执行闭环不出设备。它追求的是设备作为自主智能体，能够在最短时间、最小外部依赖的条件下完成判断和动作。这种思维天然适配工业现场对确定性、实时性、安全性的极端要求。
外挂AI的架构思路是：感知在设备，推理在平台，执行回到设备。它追求的是AI能力的集中化、共享化，把算力放在最合适的地方统一调度，让大量设备共享一个或多个强大的“大脑”。
这两种思路没有绝对的优劣之分，甚至在某些项目中是互补的。这两年我接触的项目里，越来越多的复杂场景采用混合架构：设备端做初筛，疑似异常样本再上传到中心AI系统做二次研判，两个“大脑”各管一段。
所以选型要回答的第一个问题，不应该是“内生AI好还是外挂AI好”，而应该是“我们这个系统，感知-推理-执行这个闭环，应该画在哪一层”。把这个想清楚了，后面所有细节都不会跑偏。
2. 为什么会有这样的选择：两种方案底层的技术逻辑
概念理清了，接下来要弄明白的是：为什么行业里会出现这样两种不同的形态分化？这背后有扎实的技术逻辑作为支撑。
2.1 实时性与确定性：内生AI的立身之本
工业现场对延迟的敏感程度，远超大多数人的想象。一套高速缺陷检测系统，从工业相机完成拍摄到PLC执行剔除动作，中间留给AI推理的时间窗口可能只有几十毫秒。在这个量级下，推理必须在设备内部完成，任何外部的数据传输都会引入不可控的延迟。
我见过一个非常典型的案例。某冲压产线要做工件表面缺陷在线检测，最初设计的方案是相机捕获图像后，通过网络传到车间机房的GPU服务器进行推理。实验室环境下，这个链路整体时延勉强能压进100毫秒，但到了真实生产环境，网络偶发抖动、交换机转发延迟、服务器负载波动等多重因素叠加，端到端时延常常飙升到300毫秒以上。后果很直接：产线频繁停机，冲压设备停下来等检测结果，产能损失惨重。
后来工程师换了一个方案：把推理芯片集成到相机内部，图像在相机端完成检测，只输出一个“OK/NG”信号给PLC。端到端时延稳定在30毫秒左右，而且无论车间网络怎么抖动，检测速度都不受影响。产线效率恢复，设备维护团队也松了一口气。
这个案例很好地解释了内生AI存在的根本原因：工业控制的核心诉求是确定性。推理延迟需要一个可保证的上限，而不是一个“正常情况下比较快”的统计描述。安全联锁、高速分拣、闭环控制这类场景，延迟的可预测性比延迟的平均值重要得多。
2.2 算力弹性与模型复杂度：外挂AI的舒适区
工业AI的应用场景并不全是毫秒级实时任务，大量任务对延迟的要求是秒级甚至分钟级，但对模型复杂度和算力规模的要求却非常高。
比如企业要做多个产线、多台设备的联合建模，需要把分散在各处的数据汇聚起来，训练一个全局性的质量预测模型。又比如某些场景要处理超高分辨率的工业图像，单张图的检测就需要消耗大量算力。这种计算密集型、数据密集型任务，设备本体的嵌入式算力根本撑不起来，必须依赖外部算力池。
外挂AI方案的算力弹性是它最大的优势。独立的AI服务器或者算力中心，可以根据业务需要灵活配置高规格GPU、大内存、高速存储，模型复杂度放宽了，迭代跑得也更快。而且模型的部署和更新极其方便，直接在中心服务器上替换模型版本即可，不需要到每一台设备跟前去更新固件。
最近一两年，工业大模型的应用热潮进一步强化了外挂AI的地位。设备故障诊断知识问答、工艺文档智能检索、甚至基于大模型的产线调度优化，这些任务使用的模型动辄数十亿参数，经过量化压缩后依然远超嵌入式设备的算力上限。如果目标场景需要这类能力，基本只能选择外挂方案，设备端顶多做轻量级的交互入口。
2.3 数据主权与传输成本：选型背后常常是数据问题
还有一个藏在技术逻辑背后的关键驱动力，是数据主权和传输成本。
工业数据的敏感性怎么强调都不为过。工艺参数、设备运行曲线、产品缺陷图像，这些数据在制造企业眼里就是核心竞争力的一部分。如果采用外挂AI，意味着数据要跨设备、跨网络传输，甚至要上云。很多企业在这个节点上就直接拍板：数据不出厂区、甚至不出设备，物理上把风险隔绝掉。这时候内生AI就成了唯一合法选项。
传输成本同样是一个硬约束。工业现场的视觉检测相机帧率可以高达每秒几十帧，不做压缩的情况下一天的图像数据量轻松超过一个TB。把这么庞大的数据全部传到中心服务器做推理，网络带宽、存储空间、数据清洗的成本都非常可观。内生AI在数据源头完成特征抽取和判断，只把结论或极小体积的特征向量传送出去，数据传输量可以下降两到三个数量级。
这里要提醒一点：数据问题并不只是技术问题，它常常牵涉企业的合规管理制度。做选型之前，先确认数据出不出设备、出不出厂区，这个前提一旦确定，很多技术参数对比的筛选范围就自然收窄了。
3. 选型核心：从六个维度做技术权衡
概念和技术逻辑理清之后，就到了真正动手的部分。我在多个工业AI项目里沉淀了一套选型评估维度，一共六个，按重要程度排下来，大家在评审时逐条对照，不要凭感觉拍板。
3.1 维度一：响应时延与实时性要求
第一个维度是响应时延。把系统的时延要求量化出来，是选型的第一步，也是优先级最高的硬性筛选条件。
我习惯把时延要求分成三档：
- 毫秒级（1-50ms）：安全联锁、高速分拣、实时闭环控制。这类场景基本别无选择，只能内生AI，推理必须发生在设备端。
- 百毫秒级（50-200ms）：在线质量检测、设备预测性维护。内生和外挂理论上都能满足，具体取决于网络质量和系统架构。
- 秒级及以上（超过1s）：生产调度、废品统计、报表类AI。外挂AI绰绰有余，不需要为难设备本体。
实操上，我建议在项目需求规格书里把每个应用场景的目标时延明确写出来，用这个量化指标做第一道筛选。时延硬性要求卡在100毫秒以内的场景，直接进内生AI通道；时延在几百毫秒到数秒区间的，外挂方案通常性价比更高。
这里有个容易犯的错误：很多团队在需求阶段写“越快越好”，结果选型评审时没有一个可量化的参数来约束方案。供应商演示的时候说“我们延迟很低”，到底多低没有人较真。量化指标必须落实到数字，否则后面就是扯皮。
3.2 维度二：数据敏感度与合规边界
第二个维度是数据敏感度。这个维度的判断方法其实很简单，就是做一张映射表，把AI场景和数据类型列出来，逐个标注“是否允许数据出设备”“是否允许出厂区”。
举例来说，设备运行工况参数可能允许进厂区内的中心机房做统计分析，但绝不允许上云；产品缺陷图像可能只允许留在设备端做即时判定，不允许集中存储；工艺配方参数属于最高等级敏感数据，任何情况下不允许离开设备本地。
这些约束条件写清楚之后，外挂AI的可选空间立刻缩小一大半。很多时候，数据合规问题不是技术团队能左右的，但技术团队必须主动把约束条件引入选型流程，而不是等安全部门检查时才发现方案走不通。
3.3 维度三：算力规模与模型约束
第三个维度是算力需求与模型复杂度。把目标场景的模型规模和时间约束放在一起看，基本能判断出方案的形态。
小模型（参数量百万级以下）、单次推理算力需求不高、要求低功耗低发热，这类场景适合内生AI。设备端的小型AI加速器跑起来毫无压力。中等模型（千万到亿级参数）、需要定期更新训练、推理负载波动较大，这类适合部署在工厂级别的AI服务器上，属于外挂AI的范畴。大模型（十亿参数以上）几乎只能外挂，部署在算力中心或者云端。
这里有一个关键参数经常被忽略——功耗。工业设备在产线现场运行，环境温度、散热条件、供电能力都有严格限制。一台集成高性能AI算力卡的设备，功耗可能比普通设备高出几十瓦到上百瓦。不是每个工位都能扛住这个热负荷和电量负荷。选型时一定要把设备整体的功耗预算算清楚，别只盯着推理性能指标看。
3.4 维度四：设备生命周期与改造难度
第四个维度是设备的新旧程度和改造空间。这个问题直接决定方案的入口。
如果是新购设备，在设计阶段就可以把AI能力作为设备选型的需求提出来，要求供应商在设备出厂时集成AI算力。这种情况下，内生AI的增量成本不高，而且和设备系统的融合度最好。如果是老设备改造，用外挂AI往往更现实。不需要动设备本体，在旁边加装一个AI盒子、接一台边缘服务器，数据采集上来就能开展AI应用。
我踩过一个教训：有个项目团队在全厂改造中坚持把所有老旧设备替换成带AI的新型号，预算飙了好几倍，产线停机损失更是远超预期。后来复盘时发现，那些老设备的核心机械和控制功能都完好，只是缺智能分析能力，完全可以通过外挂AI解决。这个案例说明，设备生命周期是选型的重要约束，不要为了架构上的“纯净”而付出不必要的代价。
反过来也有一个极端：某企业新建产线时过度依赖外挂AI，把设备原生就能完成的基础判断全部集中到中心服务器处理，结果服务器一宕机，整条产线的检测功能全部瘫痪。这类单点故障风险，原本通过设备端的本地判断就能化解。
3.5 维度五：运维能力与团队配置
第五个维度是运维能力，选型中经常被低估。内生AI和外挂AI的运维模式差异很大，对团队能力的要求也完全不同。
内生AI设备分散在工厂各处，固件升级、模型更新、故障排查都需要到设备现场操作。如果工厂的IT和自动化团队人手有限，分布在不同产线的几十台设备要更新一次模型，光跑现场就得耗掉几个星期的时间。外挂AI的运维高度集中，模型更新只要在中心服务器上一次性发布，所有接入设备立即生效。但代价是持续的基础设施运维投入——服务器、网络、存储、备份、安全防护，每一项都需要专人负责。
给个建议：选型评分表里一定要加入“组织能力适配度”这一项。团队里如果有熟悉嵌入式开发和边缘部署的工程师，内生AI的运维负担是可以接受的；如果团队更擅长服务器管理和应用开发，外挂AI的维护成本会更低。不要拿自己团队的短板去硬扛架构的运维要求。
3.6 维度六：成本模型与投入结构
最后是绕不开的成本问题。但我要强调：只看采购价格是远远不够的，必须做全生命周期成本对比。
内生AI的成本结构是“前高后低”。设备采购单价明显高，因为AI算力作为硬件的一部分计入整机成本；但运行过程中，不依赖外部系统的持续订阅费用，也没有数据流量费。外挂AI的成本结构正好相反：“前低后高”。前期平台接入和硬件采购的支出相对少，但后续的算力租赁、平台订阅、数据流量、存储扩容费用逐年叠加，三年五年算下来总额可能反超。
具体计算建议这样操作：把五年作为一个评估周期，把硬件采购、软件许可、实施集成、运维人力、电力消耗、数据流量全部拉通，一列一项地算。我参与的项目里，好几家在算完五年总拥有成本（TCO）之后，都调整了最初的方案选择。
| 成本项 | 内生AI | 外挂AI |
|---|---|---|
| 设备购置成本 | 高 | 低 |
| 软件/平台订阅 | 低 | 高 |
| 算力基础设施投入 | 无 | 有 |
| 运维人力成本 | 分散、偏高 | 集中、中等 |
| 电力与散热成本 | 较低 | 较高 |
| 数据流量成本 | 无 | 有 |
4. 实操参考：一份可以拿去用的选型流程
六个维度讲完，还需要一个完整的执行流程把维度串起来。下面这套流程是我在多个项目里打磨过的，共六个步骤，建议原样拿去用。
4.1 第一步：场景需求量化表
选型的起点不是“我们要上AI”，而是“我们要解决什么具体问题”。把每一个拟引入AI的场景单独拆出来，量化描述四个关键参数：
- 感知数据形态：是图像、时序信号、结构化数据还是文本，形态决定技术路径
- 数据规模：每秒产生多少条记录、每天多少GB的数据量级
- 响应时间要求：从事件发生到系统给出结论的最长允许延迟
- 输出动作：判定结果仅供人员参考，还是直接作为控制系统的输入信号
把这四个参数用表格列出来，评审团队对需求的理解就已经合格了一半。我见过太多选型失败的项目，问题根本不是方案不对，而是需求没有量化，导致后面所有的评分和对比都建立在模糊描述上。
4.2 第二步：数据分布与网络拓扑摸底
有了需求量化表，下一步是摸清现状。把现有的数据管道完整看一遍，搞清楚数据现在存储在哪些环节，各子系统之间的数据通路是什么形态。
这一步特别要注意历史遗留的数据孤岛问题。很多工厂的数据分散在设备系统、质量系统、ERP系统多个平台中，数据字段口径不统一，链路也不通。外挂AI如果要做跨系统的联合建模，第一步就要投入大量精力做数据集成，这个成本在选型阶段必须计入。
网络拓扑同样关键。设备到中心服务器的网络链路是千兆内网还是现场总线？延迟和抖动是多少？是否有备用链路？特别是有图像传输需求的场景，一定要实测带宽和丢包率，不要拿网线标称值当作可用带宽。我做过一个项目，现场网络标签上写着千兆，实际布线不规范，有效吞吐量只有标称值的三分之一，传图像完全不可行，最后方案从外挂AI改成了内生AI。
4.3 第三步：数据安全分级
安全分级不是安全部门的专属工作，选型团队必须自己做一版初稿。在需求量化表的基础上增加一列“数据流出限制”，具体分三级：
- 一级：完全不允许流出设备，推理必须发生在设备本地
- 二级：可流入厂区内部系统，不允许出厂区，外挂AI只能部署在厂内隔离网络
- 三级：允许上云或者在受控范围内共享，外挂AI和云化部署均可纳入考虑
分级结果直接约束方案边界。一级数据场景基本只能内生AI，二级数据场景的外挂AI必须内网私有化部署，三级数据场景才谈得上云化。这一步做完，选型的约束边界已经非常清晰了。
4.4 第四步：算力评估与模型可行性确认
这一步是把业务需求翻译成算力需求。做一个粗粒度的估算：
单次推理需要的算力 ≈ 模型复杂度 × 输入数据规模 ÷ 允许的单次推理时间
具体数字不要拍脑袋，可以让AI平台供应商提供基准测试报告，也可以自己在候选硬件上跑一组标准模型做验证。我更建议后者，因为供应商的测试条件往往经过优化，和真实工况有差距。
每个候选方案最好在真实环境下做30天以上的现场测试，用真实工况数据跑，不要只依据供应商演示PPT上的效果。工业现场的复杂程度，只有真正跑过才知道。测试期间的准确率、时延、稳定性数据要完整留存，作为最终评审判定的依据。
4.5 第五步：试点项目设计与对比
选型评审做得再细，都不如实实在在跑一轮对比试点。建议方案是这样的：对同一场景，同时准备一个内生AI方案和一个外挂AI方案，用同一套测试数据集、同一个验收标准，在同样的现场条件下运行一段时间，把两个方案的实际表现数据完整记录下来。
试点周期建议设定为30天，确保覆盖设备不同工况下的运行状态。重点跟踪四个指标：推理准确率、端到端响应时延、系统可用率、误报漏报率。这四个指标拿到实测数据之后，选型的结论就有说服力了，不再是谁的声音大听谁的。
4.6 第六步：独立决策评审
最后一个步骤不是技术活，但最容易被跳过。选型决策不应该由供应商或者单一部门完成，而应该由使用部门、IT部门、自动化部门、安全部门共同参与，形成独立评审意见。
评审之后，把选型的原因和依据整理成一份存档文档，重点记录“我们为什么选A不选B”。这件事不是为了追究责任，而是确保整个项目换人之后，当年的决策上下文不会丢失。我在多个客户现场看到过这类后果：前任工程师选的架构，后任接手时完全不知道当初为什么这么选，遇到问题就想推翻重来，造成大量资源浪费。
5. 现场踩坑记录与排查经验
这一部分是我想重点分享的内容。项目做得多了，就会发现好多问题并不是选型表上列的那些参数能提前暴露的，只有真正到了现场才会遇到。我挑几个有代表性的坑，逐个拆开讲。
5.1 外挂AI方案最容易栽在网络抖动上
前面提到的冲压产线案例里，我们最初以为拉了一条专线就能保证网络可靠性，但真实的工业环境远比想象中复杂。大功率设备启动瞬间的电流冲击产生的电磁干扰，能直接影响通讯线缆的信号质量；网线部署时间久了之后接触不良或者性能衰减，也会造成间歇性丢包。哪怕只是几毫秒的抖动，在高速产线里就意味着一次误判和一次不必要的停机。
后续处理给了两个方向。最彻底的解决方案是让关键路径上的AI推理全部下沉到设备端，也就是转成内生AI方案。另一个工程折中方案是保留外挂AI架构，但加入本地缓存和设备端轻量预判机制——大多数正常样本在设备本地用简单模型过一遍，只有疑似异常的样本才发送到中心系统做二次研判，这样既保住了外挂AI的模型复杂度优势，又把网络抖动的影响面限制在了少量样本路径上。这种混合方案在很多现场成了“退路”。
5.2 内生AI的硬算力瓶颈：模型压缩后的精度代价
内生AI在推广过程中收到的最多吐槽就是算力不够。设备端集成的AI芯片普遍以低功耗、低成本作为设计目标，跑轻量级模型没有问题，遇到深度神经网络或者大尺寸图像输入就力不从心。模型压缩、量化、剪枝这些技术可以把模型体积缩小，但压缩后的精度损失必须通过大量实验来评估，不是算法工程师在电脑上拍脑袋就能确定的。
我的建议是：内生AI选型时，先把模型在开发环境训练好，然后针对目标硬件做压缩优化，最后放到设备上实测，用原始测试集的精度作为验收标尺。如果压缩后精度损失超过了场景可接受的范围，那就说明这个场景的模型复杂度不适合内生AI，该上外挂就不要硬扛。
有一个项目就是这么处理的。最初测试阶段，我们试图把一台视觉检测模型完整塞进设备的嵌入式芯片，精度掉了6个点，生产现场无法接受。后来换成了外挂AI方案，服务器上的GPU跑完整模型，精度恢复到目标值。虽然成本上去了，但品质指标保住了。
5.3 数据标注质量是训练环节的隐形坑
不管选择内生还是外挂，AI模型的效果都离不开高质量的训练数据。工业场景的数据标注有几个特殊性：某些缺陷类型非常罕见，正样本数量少到模型学不出来；某些判断逻辑依赖老师傅的多年经验，普通标注员根本拿不准边界；还有些缺陷形态差异巨大，同一个类别下面有不同的子形态，标注口径不一致会直接毁掉模型。
我遇到过一次验收指标久拖不决的情况，项目连续三周准确率报表没有进步。排查到最后发现，问题不是出在模型结构上，而是训练集的标注一致性极差。后来从产线请了一位有二十年经验的老班长，重新梳理了标注规范，又组织了双人交叉标注和抽检校准，模型的准确率才肉眼可见地提升。
这个教训值得所有项目团队重视：选型评审时，一定要把数据标注规范、标注人力资源、标注质量抽检机制纳入项目范围。AI模型的质量上限，在数据标注完成的那个时刻就已经大致确定了。
5.4 模型更新节奏差异：中心升级快但需控频度
外挂AI的模型更新非常方便，中心服务器上替换模型版本就行。最初我们觉得很省事，结果发现更新太频繁同样有副作用。模型行为的变化会直接冲击现场操作员的信任——昨天还判合格的产品，今天同一批产品开始出现判定差异，如果现场没有人提前沟通“模型升级了，判定规则可能变了”，一线工人会认为是系统在抽风，严重的情况下直接拔掉整个检测系统的电源。
内生AI的设备端更新倒是没有“太频繁”的问题，频率低得多，但每次更新都要跑现场。固件升级、模型烧录、功能重启，一台一台操作，如果设备数量多、分布散，完成一轮更新的时间成本相当可观。这个问题必须在系统设计初期就考虑进去，建立起远程批量更新的通道，不要把模型更新做成挨个跑现场的苦力活。
5.5 预测性维护选型：设备级还是产线级
最后聊一下预测性维护，这是工业AI应用最广泛也最容易选错型的场景。预测性维护本质上可以分为两级，选型逻辑完全不同。
设备级预测性维护，比如单台空压机、单台泵或者单台电机的轴承寿命预测，数据源集中在设备自身，响应要求不高，在稳态工况下使用内生AI完全足够。设备本地采集振动、温度、电流信号，本地芯片跑模型，结论本地展示或者简单上报，部署简单，成本也低。
产线级或者车间级的预测性维护就不一样了。它要汇聚多台设备、多个工位的数据做联合分析，找出跨设备的关联故障模式。比如一套联动的热处理系统，前段温度的波动可能会影响后段设备的寿命，这种跨设备的关联分析只有在中心层面聚合数据才有可能实现。这时候就必须外挂AI了。
很多项目在这里犯的错误，是把设备级的问题拿去套产线级方案，结果花了外挂AI的钱，最后做出来的却是“一台设备一个模型”的孤岛式预测，数据和算力都浪费了。选型之前先问清楚：你想预测的是这台设备的寿命，还是这条产线的整体健康度？答案不同，方案路径完全不同。
6. 一点个人体会
做了这么多年工业项目，我越来越倾向于一个观点：内生AI和外挂AI之间，本质不存在哪个“更好”的问题，只存在哪个“更匹配”的问题。匹配的对象，是具体的场景特征、设备状态、团队能力和预算约束。
我个人的习惯是，每一轮选型分析做完之后，都回到最开始的问题重新问一遍：这个场景，抛开所有供应商的营销话术不谈，它的核心诉求究竟是实时性、数据安全、算力弹性，还是成本可控？不同答案指向的最优方案往往截然不同。
不要迷信任何一种单一架构。过于推崇内生AI，可能让系统陷入算力不足和升级困难的泥潭；过于依赖外挂AI，又会让产线的关键决策完全押注在不可控的网络与中心系统上。在真实的工业环境里，最稳妥的设计常常是两头兼顾的路：关键路径上的决策在设备端“保底”，全局性的协同调度在中心层面“统筹”。
这套选型方法和流程我已经反复用过多次，每一次都让团队从“拍脑袋式”的讨论走到了“摆数据”的决策。在工业AI这件事上，慢一点，把能预想的坑都提前想一遍，比什么都重要。毕竟产线一停机，损失的是真金白银，不是PPT上的概念。
