大模型的热度这两年算是被彻底拉满了。无论是参数规模、多模态能力还是各种落地场景的想象空间资本市场和开发者社区都在拼命往里扎。但一个很有意思的现象是大家讨论最多的、投入最狠的往往集中在“模型训练”“智能涌现”和“对话交互”这一个环节上。至于这个模型跑起来之后怎么连接真实的物理世界、怎么把智能送进每一台设备、怎么让基础设施本身具备感知和决策能力——这类话题反而显得冷清。我自己做物联网和边缘计算有年头了最近一年明显感觉到一个趋势大模型真正要释放价值绝不只是跑在云端数据中心里而是必须下沉到终端、网关、传感器这些“神经末梢”上去。这一层行业内习惯叫 AIoT。如果说大模型时代的上半场是“算法军备竞赛”那下半场拼的绝对是基础设施的厚度。这背后恰恰藏着一个被严重低估的万亿级空白。这篇文章我就从自己的实操经验出发聊聊为什么我觉得未来十年属于 AIoT 基础设施以及这波机会到底藏在哪里。1. 内容整体设计与思路拆解大模型之后AIoT 为什么是“被低估”的那一个很多人一听 AIoT 就觉得是老生常谈。毕竟物联网这个概念喊了十几年“万物互联”嘛传感器加云平台加 App听起来没什么新意。但实际上AIoT 和大模型深度绑定之后它已经不是原来那个物联网了。1.1 从“训练”到“连接”再到“控制”价值重心正在转移大模型解决的核心问题是“理解”和“生成”。你给它一段文字它能给出答案你给它一张图它能描述内容你给它一堆传感器数据它理论上也能判断设备状态、预测故障趋势。但问题在于任何模型的能力要想真正产生经济效益最后都得落到一个动作上调整空调温度、控制灌溉阀门、调度工厂产线、调节路灯亮度。这个链路一共三步感知、决策、执行。大模型目前把“决策”这一步做得非常强但“感知”和“执行”恰恰依赖的是 AIoT 基础设施——你要有足够的传感节点采集数据要有可靠的网络把数据传到算力附近要有边缘计算设备在本地完成低延迟推理还要有成熟的执行机构把决策指令变成物理动作。过去几年大家疯狂堆算力、堆参数本质上是在强化“决策”这个单点能力。但商业闭环需要的从来不是单点强而是全链路通。你模型再聪明感知层数据进不来或者执行层响应太慢整个系统照样不转。这个简单的逻辑很多局内人反而没想透。1.2 “设备的智能化”和“智能的设备化”是两码事我经常打一个比方。大模型本身像一个刚毕业的顶尖学霸知识储备丰富、推理能力极强。但你不能让一个学霸整天坐在家里空想你得给他安排工作环境、给他配齐信息输入渠道、让他能实际动手操作。AIoT 基础设施就是这个工作环境和手脚。这里有个认知误区。绝大多数人谈论“AI 赋能物联网”时想的是“给我的设备装个 ChatBot”让设备能跟人对话。这当然是一种应用但它的想象力太小了。真正的 AIoT 基础设施是让智能长在设备里、泡在网络里、融在流程里。用行业黑话讲就是“智能无处不在”用大白话讲就是每一个传感器、每一个摄像头、每一个电机控制器都自带算力都能在本地处理一部分智能任务同时又能跟云端的大模型协同作战。所以你如果只是把大模型当成一个“更聪明的云端大脑”那确实是低估了 AIoT。大模型真正的杀手级应用是作为 AIoT 基础设施的操作系统级组件让整个物理世界的运行方式被重新定义一次。1.3 为什么是“万亿级”算一笔基础设施的账万亿级这个说法听起来像资本故事里的套话。但我从工程角度算过一笔粗账。一个中等规模的智慧工厂要实现比较完整的 AIoT 改造传感器部署、边缘计算节点、工业网关、数据中台、AI 推理平台再加上后期的运维和算法迭代整体投入动辄千万级。全国制造业企业数百万家哪怕只有一小部分启动升级算出来的空间都是惊人的。再看智慧农业、智慧城市、智能楼宇、车路协同、家庭自动化这些赛道每个都是千亿级以上的盘子。AIoT 基础设施的可怕之处在于它不是一个单次交付的项目而是一个持续产生服务费、运维费、迭代费的长周期业务。这种商业模式天然具备高黏性、高复购的特征叠加起来自然就是万亿级的体量。2. 核心细节解析与实操要点从大模型到 AIoT技术栈到底怎么搭聊完了宏观逻辑落回技术本身。大模型要真正嵌入 AIoT 基础设施绝不是把 GPT 类的模型直接塞进边缘设备那么简单。从模型选型、推理加速到通信协议每一层都有大量细节需要打磨。2.1 边缘推理的模型选型不是所有场景都需要千亿参数我在实际项目里遇到过很多甲方上来就要求“能不能在我们工厂本地跑一个 ChatGPT 同级别的模型”。这种需求大多是因为对模型参数规模没有概念。工业现场最常见的 AI 任务不外乎三类视觉质检检测缺陷、识别字符、时序预测设备故障预测、能耗优化、语义理解中控语音交互、运维知识问答。这三类任务里前两类用轻量级模型就够了。比如视觉质检经典的做法是用 YOLO 系列或者更轻的 MobileNet 系列参数量只有几 M 到几十 M配合工控机上的一张消费级显卡或者 NPU 加速卡就能跑得很流畅。第三类才需要大语言模型但也不是非得上几百 B 的大模型通常在 7B 到 14B 这个区间的开源模型经过领域微调配合检索增强生成RAG已经能覆盖绝大多数工业知识问答场景。我自己的经验是边缘侧的模型选型要遵循“够用就行留有余量”的原则。先把任务类型拆清楚再评估网络带宽和响应时延的约束最后反推模型该多大、量化该做多狠。动不动上大模型只会把基础设施的预算全烧在 GPU 上得不偿失。注意边缘设备选型时不仅要看模型推理的帧率或时延还要关注模型的峰值内存占用和长时间运行后的温升表现。工业现场设备往往在封闭机柜里连续运行散热条件远不如数据中心这一点经常被算法工程师忽略。2.2 本地部署大模型从 Ollama 到 vLLM 的实战对比基础设施要落地本地化部署大模型是绕不开的环节。很多工厂的数据根本不允许出园区合规要求就决定了模型必须跑在本地。这也是为什么像 Ollama、vLLM 这类推理框架热度居高不下的原因——它们是连接大模型和物理世界的“最后一公里”载具。先说 Ollama。它的优势是极低的部署门槛。下载安装、拉取模型、一行命令启动 API 服务整个过程不到十分钟就能跑通。我用它做过一个设备运维知识库的 PoC把企业内部的设备手册、故障案例、维修记录整理成向量库接上 Ollama 跑的 Qwen 系列模型一个售后工程师就能通过自然语言查询历史故障的处理方案。这个 PoC 从零到一一个下午就搞定了中间没有写过一行模型推理代码全靠 Ollama 把工程复杂度封装掉了。但 Ollama 的问题也很明显它是单机友好的工具面向生产环境的并发能力、服务治理、弹性伸缩都比较弱。当你需要把模型服务开放给几十上百个终端并发调用时就需要上 vLLM 这类生产级推理引擎。vLLM 的核心优势是 PagedAttention 和 Continuous Batching这两个机制能大幅提升吞吐。这里有个实操细节值得展开说就是vLLM 的缓存命中率优化。在线推理服务里用户请求经常会有公共前缀比如系统提示词很长或者多轮对话里前面几轮内容不变。vLLM 的 prefix caching 机制会自动缓存这些公共前缀对应的 KV Cache后续请求直接复用从而缩短首 Token 时延。但默认配置下这个缓存可能命中率不高。我调优时会做两件事一是尽量固定系统提示词不要每轮请求都动态拼接用户信息进去二是把--enable-prefix-caching显式打开并适当调大--max-num-seqs让更多并发请求落在同一个 prefix 区间内。实测下来在固定长系统提示词的业务下吞吐能提升 40% 以上。实操提示本地部署大模型的硬件选型可以把握一个粗略参考——7B 模型做 4bit 量化后大约需要 6-8GB 显存一张 24GB 的消费级显卡就能跑得不错13B-14B 模型建议直接上 48GB 以上的专业卡。显存不够硬跑模型会频繁做内存交换延迟能差出好几倍。2.3 网络与协议AIoT 基础设施的“神经系统”模型部署好之后接下来的核心问题就是设备的数据怎么传、指令怎么下。这一层是 AIoT 基础设施最繁琐但也最见功力的部分。现在主流的物联网络方案里Wi-Fi 适合室内高带宽场景4G/5G 适合广域移动场景LoRa 和 NB-IoT 适合低功耗远距离场景。但在真实的 AIoT 项目中网络方案从来不是单选题——成熟的项目几乎都是混合组网。我做过一个大型园区的能效管理项目园区内冷水机组、空调末端、照明回路分散在十几栋楼里。策略是楼内设备走 RS485 总线汇聚到楼栋网关网关之间走工业以太网再往上通过 5G 加密隧道送到云端平台。三层架构的好处是既保证了末端设备的低成本接入又兼顾了主干网络的高吞吐和高可靠。协议层面物联网行业有个“老而弥坚”的协议叫 MQTT。它基于发布/订阅模式特别适合传感器数据上报和远程控制指令下发这类场景。实践中我会把设备数据按主题分层管理比如factory/plant1/device_type/device_id这样上层大模型在做时序分析时可以很方便地按主题订阅到特定设备维度的数据流。2.4 数据管道把“脏乱差”的物理数据喂给大模型大模型对数据质量的要求很多做物联网的老工程师是低估的。传感器数据天生带着噪声丢包、乱序、重复上报、量纲不统一这些问题在传统 SCADA 系统里也许靠人工看报表还能忍受但一旦接入大模型做自动分析脏数据会让模型输出完全不可用。所以在 AIoT 基础设施架构里我坚持要在数据源和大模型之间加一层数据清洗与标准化管道。具体工作包括三块缺失值处理传感器掉线产生的空洞用插值或者前值填充但必须给数据打上“补全”标签防止后面做预测时误判。异常值剔除明显超出物理量程的数据比如零下 40 度的室温读数直接剔除并触发告警这往往是传感器硬件故障的前兆。时间对齐多路传感器采样频率不一致必须按统一时间戳重采样否则模型看到的时序关系是错乱的。我之前见过一个智慧农业项目就因为土壤湿度传感器数据没做对齐处理大模型在做灌溉决策时把不同深度土层的数据当成了同一时刻的数据导致推理出的灌溉量偏差很大。这个问题折磨了团队快两周最后定位到是数据管道少做了一个时间对齐的算子。3. 实操过程与核心环节实现从一个智慧农业场景看 AIoT 基础设施全链路聊完技术坑拿一个具体的“农业大模型”场景串一遍全链路。这个标题下的热搜词里出现了“农业大模型”说明产业界对 AI 种地这件事有真实的需求。农业这个场景特别能说明问题因为它的物理环境复杂、变量多、现场条件差没有一个可靠的基础设施再强的模型也是空中楼阁。3.1 痛点拆解做智慧农业真正的难点不在“农”而在“智”传统大棚种植的痛点很明确浇水施肥全靠老师傅经验土壤墒情靠手感气象变化靠老天的脸色。年轻人不愿意进大棚干活老师傅的经验传承不下来。所以农业大模型的核心价值在于——把老师傅的经验数据化、模型化让系统自动判断什么时候该灌溉、什么时候该施肥、施多少量。但要做到这一点首先得把物理世界的信号变成数字世界的张量。这一步靠什么靠的就是遍布田间的传感器网络。我的做法是三层感知架构土壤层部署土壤温湿度传感器、pH 值传感器、氮磷钾复合离子传感器分别埋在 10cm、20cm、40cm 三个深度。不同深度数据反映不同根系层的水分和养分状况。气象层大棚内外各部署一套微型气象站采集空气温湿度、光照强度、二氧化碳浓度、风速风向。气象数据是模型做短期灌溉预测的关键输入。设备层水肥一体机的电磁阀状态、水泵电机的电流电压、施肥桶的液位这些设备数据反映了执行环节是否真正落地。3.2 端侧推理没有网的大棚模型怎么“自己思考”农业场景有一个容易被互联网背景的工程师忽略的残酷现实很多大棚的通信环境极差。蔬菜大棚为了保温墙体厚实金属骨架对信号还有屏蔽作用偏远生产基地可能连 4G 信号都只有一格。这种环境下把所有数据上传到云端再推理下发指令的架构几乎不可用。所以边缘计算是智慧农业 AIoT 基础设施的必选项。我在项目里用的是工规级边缘网关内置一块低功耗 NPU跑一个裁剪过的时序预测模型。这个模型的输入是过去 12 小时每隔 5 分钟采样一次的土壤湿度、温度和光照序列输出是未来 24 小时是否需要灌溉的建议。模型精度不算顶级但胜在四个字本地运行、断网可用。这个边缘模型的实时输出会传回云端的大模型做总体验证。一旦云端大模型发现边缘模型的判断出现系统性偏差比如连续三天边缘模型都忽略了蒸腾量偏大导致的水分预警就会自动触发模型迭代流程把新的训练数据回流到训练平台生成新版本边缘模型再下发。这个“云端训练—边缘执行—反馈回流”的闭环是我理解的大模型与 AIoT 融合的标准范式。3.3 大模型智能灌溉决策从数据到行动核心的灌溉决策功能我们尝试了一个进阶方案不是简单基于阈值去报警而是用大模型去做“语义时序”联合推理。举个例子。某一天上午 10 点系统监测到土壤 20cm 深度湿度下降速度加快同时气象站显示未来 3 小时可能有降雨。传统阈值逻辑会在湿度跌破 30% 时直接触发灌溉。但大模型可以把这些多模态信息汇总成一个综合判断输出类似这样的结果“当前土壤墒情尚可支撑作物蒸腾约 4-5 小时且气象雷达显示 2 小时后有一次中雨过程建议暂缓灌溉待降雨后根据实时墒情再决定是否补水。”这个建议再通过知识库检索增强附加上“该作物在苗期对渍水敏感注意雨后及时排水”等针对性提醒。这是一个典型的“大模型负责思考、边缘设备负责感知、控制器负责执行”的协作链路。这套系统搭完之后基地的灌溉用水量比原先的人工经验模式节省了差不多 30%而且因为减少了无效灌溉带来的沤根问题整个生长季的烂根发病率明显下降。农业这个靠天吃饭的行业第一次让我感觉“天时”是被计算出来的而不是等出来的。3.4 sim-to-real 仿真AIoT 基础设施的“试车场”最后再聊一个大家容易忽略的板块——仿真基础设施。行业里叫 sim-to-real也就是“从仿真到现实”的技术路线。大模型和 AIoT 系统上线前不可能直接拿真实设备反复试验尤其是涉及机械臂控制、产线调度这类高风险场景试错的代价极高。比较成熟的方案是构建一个数字孪生环境把物理设备的运动学模型、传感噪声模型、网络时延模型全部塞进仿真器里。大模型输出的控制指令先跑一遍仿真看有没有碰撞风险、执行器约束是否满足、极端场景下的响应是否稳定。确认安全了再下发到真实设备。这块以前主要用在机器人领域但我觉得它完全可以泛化到更广义的 AIoT 基础设施中。跑批量的仿真测试不仅能显著缩短现场调试周期而且能让模型在虚拟环境里见过足够多的“意外”到时候真出了问题也不至于毫无准备。4. 常见问题与排查技巧实录AIoT 基础设施落地会踩的五个大坑这部分是纯实战总结。AIoT 基础设施的项目和纯软件项目有个巨大差异不可控的外部因素太多了。硬件故障、通信抖动、现场环境变化每一个都能让架构师设计得再完美的系统瞬间翻车。这里挑五个我踩过最深的坑聊。4.1 通信掉线问题不只是“加个心跳包”那么简单用 MQTT 做设备通信的项目最恶心的故障就是设备无故掉线。很多新手会花大量时间排查网络折腾防火墙策略和路由表。我的排查顺序其实是反过来的先看电源再看网关资源最后才看链路。设备掉线超过一半的情况是供电不稳。工业现场经常有电机启动、变频器工作时产生的电压跌落一些廉价物联网网关的电源适配器余量不足电网稍微波动一下就直接重启了。解决方法是换宽压电源并在网关入口加一个延迟上电模块。其次容易忽视的是网关资源耗尽——设备商默认配置的 512MB 内存跑上容器化网关服务后可用内存很容易被日志文件挤爆导致服务假死。这个问题加一个简单的定时任务清理日志就能解决。4.2 推理延迟抖动模型快不代表系统快边缘 AI 推理项目验收时甲方最关心的指标是响应延迟。但很多团队在实验室测的延迟和现场完全对不上。原因也很典型实验室环境网络干净而现场要把图片上传到 GPU 服务器中间隔着一层 Wi-Fi 或者 4G稍有干扰延迟就飙升。对这种场景我的建议是能边缘处理就边缘处理别过分依赖集中式的推理节点。传输延迟和推理延迟的比例大概是 2:8。所以真正的优化重点是网络层而不是模型层。做智慧安防的门禁项目时我们干脆在门禁一体机里嵌入了轻量人脸识别模型所有比对都在本地完成云端只负责账本管理和策略下发。这样不仅延迟降到 200 毫秒以内可靠性还上了一个台阶——断网也不影响门禁开门这点对客户来说比什么都重要。4.3 模型幻觉问题AIoT 场景里幻觉是会“出事故”的大模型落地 AIoT 场景最大的安全隐患是幻觉。在纯聊天场景里模型一本正经地胡说八道最多被用户吐槽但在设备控制场景里一句错误的操作建议可能导致设备损坏甚至安全事故。做农业系统时我要求所有大模型的输出在控制类指令上必须经过校验器校验。校验器里写死了设备的物理安全边界灌溉阀门开度只能在 0-100% 之间且单次开启时长不能超过 X 小时施肥泵的启停必须与液位传感器联动防止空转烧泵。大模型的输出经过校验器过滤后才会真正下发到 PLC 执行任何超出安全边界的输出都会被直接拦截。我在几个项目里实践下来最有效的一条原则是大模型负责建议规则引擎负责安全人负责最终仲裁。别让模型拥有对物理设备的完全控制权这句话值得写进每一份 AIoT 项目的需求文档里。4.4 OT/IT 融合之痛鸡同鸭讲的两个世界AIoT 项目有一半时间不是在写代码而是在跟甲方运维老师傅对接协议。OT操作技术侧的老师傅习惯的是 Modbus 寄存器、PLC 梯形图、继电器逻辑IT 侧的程序员张口闭口 RESTful API、JSON Schema、微服务。这两个体系的工程师坐在一起开会除非有翻译否则前两周基本是在鸡同鸭讲。我的做法是在项目启动阶段就建立一个双向映射表把甲方设备点表里的每一个寄存器地址翻译成 IT 侧的数据模型字段并约定好量纲、数据类型和刷新频率。这个映射表是整个项目的“通用语言”后续所有联调都以它为准能少吵无数次架。4.5 运维复杂度边缘节点一多K8s 也挡不住人性的弱点AIoT 项目做到一定规模后瓶颈往往不在技术上而在运维上。当你有上千个边缘网关散布在几十个厂区总会有各种意外某一个网关磁盘写满、某一个节点证书过期、某一家分厂把网关塞进了弱电井没人管。靠 SSH 逐个上去敲命令根本维护不过来。比较顺畅的方案是搭建一个中心化的设备运维平台所有边缘节点自动上报健康状态包括 CPU、内存、磁盘、网络连通性、Agent 版本。平台可以自动下发配置、批量升级应用。但这套体系要求边缘侧和中心侧的通信必须稳定所以在架构设计阶段就要把运维通道当成和业务通道同等重要的一等公民来规划。5. 基础设施的“下一个十年”万亿空白里的机会分布最后回归到这个话题的落点上如果未来十年真的属于 AIoT 基础设施那机会到底分布在哪些具体的方向上基于对行业的观察和自己的实践我梳理了几个重点突破方向。5.1 端侧大模型和推理芯片的规模化商用端侧大模型不是概念预热而是已经在设备落地了。手机、车载、智能家居设备都开始要求在本地具备大模型的推理能力。这就推动整个产业链发生结构性变化推理芯片不再只需要跑通 CNN 这类小模型而是要能高效运行 Transformer 这类大模型架构。未来端侧芯片的竞争焦点会集中在三件事算力密度每瓦性能、内存带宽决定能跑多大的模型、工具链成熟度开发者迁移成本。谁能把这三个指标做到平衡谁就能在未来的 AIoT 芯片市场占住身位。这个方向上国产芯片的机会窗口正在打开。5.2 面向 AIoT 场景能力裁剪的中间件除了芯片软件中间件的机会同样可观。海量设备产生的数据要接入大模型底层需要解决协议适配、数据分发、模型调度一整套基础服务。现在的市场现状是要么上重型云平台成本高、绑得深要么全部自研周期长、坑多。中间恰好出现了一个尴尬的断层。未来一定会出现一批轻量级、场景化的 AIoT 中间件能帮助企业快速把设备数据对接到大模型工作流里。这类产品有点像 AIoT 领域的“胶水层”虽然不显眼但属于基础设施中的基础设施。谁先把这个胶水层做扎实谁就掌握了生态入口。5.3 从卖设备到卖“智能服务”的商业重构硬件本身将越来越不值钱。单一传感器硬件的毛利会被卷到一个相当低的水平。真正的价值在于设备联网后产生的数据服务和智能决策服务。这意味着 AIoT 基础设施的商业模式要从“交付硬件”转向“订阅服务”。举个例子一家做空压机节能改造的公司真正提供给客户的不再是空压机和传感器而是一个“压缩空气按需供应”的托管服务。后台的大模型通过实时分析用气规律动态调节空压机的启停组合和排气压力客户只需要按最终节省的电费分成付费。这种模式下客户买的不是设备是省下来的钱。这才是 AIoT 基建最性感的商业形态。6. 实操心得与阶段性建议提前入局的人能做什么说再多趋势和判断最终还是要落到行动上。我最后给准备入局 AIoT 基础设施赛道的团队几条发自内心的建议。第一别急着买服务器先找到高频刚需的场景。大模型也好、AIoT 也罢都是手段客户真正关心的永远是自己业务里的具体问题产线的良率能不能提升、能耗能不能降低、设备停机时间能不能缩短。技术选型要紧贴这些问题来找答案脱离场景的架构只是空中楼阁。第二团队里必须有人同时懂 OT 和 IT。AIoT 项目跟纯互联网项目最大的不同是它一半是软件工程一半是硬件工程和现场工程。一个全员都是算法工程师的团队去现场大概率会被设备接线和工业协议折磨得没脾气。找一个有五六年工控经验的老人比多招两个算法工程师更能帮项目走出泥潭。第三用“小闭环”跑通一个场景再横向复制。我不建议一上来就铺几百个点位的大盘子。先在一个车间、一个大棚、一栋楼里跑通全链路哪怕覆盖范围很小只要指标验证是正向的再总结成标准化方案向外复制。这样做的好处是试错成本可控而且容易拿到客户对效果的信任背书。我自己的体会是技术也好、项目也好最怕的不是难而是方向不明。大模型的这波浪潮来得又快又猛很容易让人产生一种“再不追就晚了”的焦虑。但做了这么多年基础设施相关的事情我愈发坚定一个判断热闹的永远是浪潮尖上的概念而真正活得久、赚到钱的往往是那些在海底默默铺设管道的人。现在这个时间点做 AIoT 基础设施就是在做那个管道层。它不容易上热搜但它是未来十年真正承载智能时代的地基。 大模型之后，AIoT基础设施才是下一个万亿级机遇与落地实践
大模型的热度这两年算是被彻底拉满了。无论是参数规模、多模态能力还是各种落地场景的想象空间资本市场和开发者社区都在拼命往里扎。但一个很有意思的现象是大家讨论最多的、投入最狠的往往集中在“模型训练”“智能涌现”和“对话交互”这一个环节上。至于这个模型跑起来之后怎么连接真实的物理世界、怎么把智能送进每一台设备、怎么让基础设施本身具备感知和决策能力——这类话题反而显得冷清。我自己做物联网和边缘计算有年头了最近一年明显感觉到一个趋势大模型真正要释放价值绝不只是跑在云端数据中心里而是必须下沉到终端、网关、传感器这些“神经末梢”上去。这一层行业内习惯叫 AIoT。如果说大模型时代的上半场是“算法军备竞赛”那下半场拼的绝对是基础设施的厚度。这背后恰恰藏着一个被严重低估的万亿级空白。这篇文章我就从自己的实操经验出发聊聊为什么我觉得未来十年属于 AIoT 基础设施以及这波机会到底藏在哪里。1. 内容整体设计与思路拆解大模型之后AIoT 为什么是“被低估”的那一个很多人一听 AIoT 就觉得是老生常谈。毕竟物联网这个概念喊了十几年“万物互联”嘛传感器加云平台加 App听起来没什么新意。但实际上AIoT 和大模型深度绑定之后它已经不是原来那个物联网了。1.1 从“训练”到“连接”再到“控制”价值重心正在转移大模型解决的核心问题是“理解”和“生成”。你给它一段文字它能给出答案你给它一张图它能描述内容你给它一堆传感器数据它理论上也能判断设备状态、预测故障趋势。但问题在于任何模型的能力要想真正产生经济效益最后都得落到一个动作上调整空调温度、控制灌溉阀门、调度工厂产线、调节路灯亮度。这个链路一共三步感知、决策、执行。大模型目前把“决策”这一步做得非常强但“感知”和“执行”恰恰依赖的是 AIoT 基础设施——你要有足够的传感节点采集数据要有可靠的网络把数据传到算力附近要有边缘计算设备在本地完成低延迟推理还要有成熟的执行机构把决策指令变成物理动作。过去几年大家疯狂堆算力、堆参数本质上是在强化“决策”这个单点能力。但商业闭环需要的从来不是单点强而是全链路通。你模型再聪明感知层数据进不来或者执行层响应太慢整个系统照样不转。这个简单的逻辑很多局内人反而没想透。1.2 “设备的智能化”和“智能的设备化”是两码事我经常打一个比方。大模型本身像一个刚毕业的顶尖学霸知识储备丰富、推理能力极强。但你不能让一个学霸整天坐在家里空想你得给他安排工作环境、给他配齐信息输入渠道、让他能实际动手操作。AIoT 基础设施就是这个工作环境和手脚。这里有个认知误区。绝大多数人谈论“AI 赋能物联网”时想的是“给我的设备装个 ChatBot”让设备能跟人对话。这当然是一种应用但它的想象力太小了。真正的 AIoT 基础设施是让智能长在设备里、泡在网络里、融在流程里。用行业黑话讲就是“智能无处不在”用大白话讲就是每一个传感器、每一个摄像头、每一个电机控制器都自带算力都能在本地处理一部分智能任务同时又能跟云端的大模型协同作战。所以你如果只是把大模型当成一个“更聪明的云端大脑”那确实是低估了 AIoT。大模型真正的杀手级应用是作为 AIoT 基础设施的操作系统级组件让整个物理世界的运行方式被重新定义一次。1.3 为什么是“万亿级”算一笔基础设施的账万亿级这个说法听起来像资本故事里的套话。但我从工程角度算过一笔粗账。一个中等规模的智慧工厂要实现比较完整的 AIoT 改造传感器部署、边缘计算节点、工业网关、数据中台、AI 推理平台再加上后期的运维和算法迭代整体投入动辄千万级。全国制造业企业数百万家哪怕只有一小部分启动升级算出来的空间都是惊人的。再看智慧农业、智慧城市、智能楼宇、车路协同、家庭自动化这些赛道每个都是千亿级以上的盘子。AIoT 基础设施的可怕之处在于它不是一个单次交付的项目而是一个持续产生服务费、运维费、迭代费的长周期业务。这种商业模式天然具备高黏性、高复购的特征叠加起来自然就是万亿级的体量。2. 核心细节解析与实操要点从大模型到 AIoT技术栈到底怎么搭聊完了宏观逻辑落回技术本身。大模型要真正嵌入 AIoT 基础设施绝不是把 GPT 类的模型直接塞进边缘设备那么简单。从模型选型、推理加速到通信协议每一层都有大量细节需要打磨。2.1 边缘推理的模型选型不是所有场景都需要千亿参数我在实际项目里遇到过很多甲方上来就要求“能不能在我们工厂本地跑一个 ChatGPT 同级别的模型”。这种需求大多是因为对模型参数规模没有概念。工业现场最常见的 AI 任务不外乎三类视觉质检检测缺陷、识别字符、时序预测设备故障预测、能耗优化、语义理解中控语音交互、运维知识问答。这三类任务里前两类用轻量级模型就够了。比如视觉质检经典的做法是用 YOLO 系列或者更轻的 MobileNet 系列参数量只有几 M 到几十 M配合工控机上的一张消费级显卡或者 NPU 加速卡就能跑得很流畅。第三类才需要大语言模型但也不是非得上几百 B 的大模型通常在 7B 到 14B 这个区间的开源模型经过领域微调配合检索增强生成RAG已经能覆盖绝大多数工业知识问答场景。我自己的经验是边缘侧的模型选型要遵循“够用就行留有余量”的原则。先把任务类型拆清楚再评估网络带宽和响应时延的约束最后反推模型该多大、量化该做多狠。动不动上大模型只会把基础设施的预算全烧在 GPU 上得不偿失。注意边缘设备选型时不仅要看模型推理的帧率或时延还要关注模型的峰值内存占用和长时间运行后的温升表现。工业现场设备往往在封闭机柜里连续运行散热条件远不如数据中心这一点经常被算法工程师忽略。2.2 本地部署大模型从 Ollama 到 vLLM 的实战对比基础设施要落地本地化部署大模型是绕不开的环节。很多工厂的数据根本不允许出园区合规要求就决定了模型必须跑在本地。这也是为什么像 Ollama、vLLM 这类推理框架热度居高不下的原因——它们是连接大模型和物理世界的“最后一公里”载具。先说 Ollama。它的优势是极低的部署门槛。下载安装、拉取模型、一行命令启动 API 服务整个过程不到十分钟就能跑通。我用它做过一个设备运维知识库的 PoC把企业内部的设备手册、故障案例、维修记录整理成向量库接上 Ollama 跑的 Qwen 系列模型一个售后工程师就能通过自然语言查询历史故障的处理方案。这个 PoC 从零到一一个下午就搞定了中间没有写过一行模型推理代码全靠 Ollama 把工程复杂度封装掉了。但 Ollama 的问题也很明显它是单机友好的工具面向生产环境的并发能力、服务治理、弹性伸缩都比较弱。当你需要把模型服务开放给几十上百个终端并发调用时就需要上 vLLM 这类生产级推理引擎。vLLM 的核心优势是 PagedAttention 和 Continuous Batching这两个机制能大幅提升吞吐。这里有个实操细节值得展开说就是vLLM 的缓存命中率优化。在线推理服务里用户请求经常会有公共前缀比如系统提示词很长或者多轮对话里前面几轮内容不变。vLLM 的 prefix caching 机制会自动缓存这些公共前缀对应的 KV Cache后续请求直接复用从而缩短首 Token 时延。但默认配置下这个缓存可能命中率不高。我调优时会做两件事一是尽量固定系统提示词不要每轮请求都动态拼接用户信息进去二是把--enable-prefix-caching显式打开并适当调大--max-num-seqs让更多并发请求落在同一个 prefix 区间内。实测下来在固定长系统提示词的业务下吞吐能提升 40% 以上。实操提示本地部署大模型的硬件选型可以把握一个粗略参考——7B 模型做 4bit 量化后大约需要 6-8GB 显存一张 24GB 的消费级显卡就能跑得不错13B-14B 模型建议直接上 48GB 以上的专业卡。显存不够硬跑模型会频繁做内存交换延迟能差出好几倍。2.3 网络与协议AIoT 基础设施的“神经系统”模型部署好之后接下来的核心问题就是设备的数据怎么传、指令怎么下。这一层是 AIoT 基础设施最繁琐但也最见功力的部分。现在主流的物联网络方案里Wi-Fi 适合室内高带宽场景4G/5G 适合广域移动场景LoRa 和 NB-IoT 适合低功耗远距离场景。但在真实的 AIoT 项目中网络方案从来不是单选题——成熟的项目几乎都是混合组网。我做过一个大型园区的能效管理项目园区内冷水机组、空调末端、照明回路分散在十几栋楼里。策略是楼内设备走 RS485 总线汇聚到楼栋网关网关之间走工业以太网再往上通过 5G 加密隧道送到云端平台。三层架构的好处是既保证了末端设备的低成本接入又兼顾了主干网络的高吞吐和高可靠。协议层面物联网行业有个“老而弥坚”的协议叫 MQTT。它基于发布/订阅模式特别适合传感器数据上报和远程控制指令下发这类场景。实践中我会把设备数据按主题分层管理比如factory/plant1/device_type/device_id这样上层大模型在做时序分析时可以很方便地按主题订阅到特定设备维度的数据流。2.4 数据管道把“脏乱差”的物理数据喂给大模型大模型对数据质量的要求很多做物联网的老工程师是低估的。传感器数据天生带着噪声丢包、乱序、重复上报、量纲不统一这些问题在传统 SCADA 系统里也许靠人工看报表还能忍受但一旦接入大模型做自动分析脏数据会让模型输出完全不可用。所以在 AIoT 基础设施架构里我坚持要在数据源和大模型之间加一层数据清洗与标准化管道。具体工作包括三块缺失值处理传感器掉线产生的空洞用插值或者前值填充但必须给数据打上“补全”标签防止后面做预测时误判。异常值剔除明显超出物理量程的数据比如零下 40 度的室温读数直接剔除并触发告警这往往是传感器硬件故障的前兆。时间对齐多路传感器采样频率不一致必须按统一时间戳重采样否则模型看到的时序关系是错乱的。我之前见过一个智慧农业项目就因为土壤湿度传感器数据没做对齐处理大模型在做灌溉决策时把不同深度土层的数据当成了同一时刻的数据导致推理出的灌溉量偏差很大。这个问题折磨了团队快两周最后定位到是数据管道少做了一个时间对齐的算子。3. 实操过程与核心环节实现从一个智慧农业场景看 AIoT 基础设施全链路聊完技术坑拿一个具体的“农业大模型”场景串一遍全链路。这个标题下的热搜词里出现了“农业大模型”说明产业界对 AI 种地这件事有真实的需求。农业这个场景特别能说明问题因为它的物理环境复杂、变量多、现场条件差没有一个可靠的基础设施再强的模型也是空中楼阁。3.1 痛点拆解做智慧农业真正的难点不在“农”而在“智”传统大棚种植的痛点很明确浇水施肥全靠老师傅经验土壤墒情靠手感气象变化靠老天的脸色。年轻人不愿意进大棚干活老师傅的经验传承不下来。所以农业大模型的核心价值在于——把老师傅的经验数据化、模型化让系统自动判断什么时候该灌溉、什么时候该施肥、施多少量。但要做到这一点首先得把物理世界的信号变成数字世界的张量。这一步靠什么靠的就是遍布田间的传感器网络。我的做法是三层感知架构土壤层部署土壤温湿度传感器、pH 值传感器、氮磷钾复合离子传感器分别埋在 10cm、20cm、40cm 三个深度。不同深度数据反映不同根系层的水分和养分状况。气象层大棚内外各部署一套微型气象站采集空气温湿度、光照强度、二氧化碳浓度、风速风向。气象数据是模型做短期灌溉预测的关键输入。设备层水肥一体机的电磁阀状态、水泵电机的电流电压、施肥桶的液位这些设备数据反映了执行环节是否真正落地。3.2 端侧推理没有网的大棚模型怎么“自己思考”农业场景有一个容易被互联网背景的工程师忽略的残酷现实很多大棚的通信环境极差。蔬菜大棚为了保温墙体厚实金属骨架对信号还有屏蔽作用偏远生产基地可能连 4G 信号都只有一格。这种环境下把所有数据上传到云端再推理下发指令的架构几乎不可用。所以边缘计算是智慧农业 AIoT 基础设施的必选项。我在项目里用的是工规级边缘网关内置一块低功耗 NPU跑一个裁剪过的时序预测模型。这个模型的输入是过去 12 小时每隔 5 分钟采样一次的土壤湿度、温度和光照序列输出是未来 24 小时是否需要灌溉的建议。模型精度不算顶级但胜在四个字本地运行、断网可用。这个边缘模型的实时输出会传回云端的大模型做总体验证。一旦云端大模型发现边缘模型的判断出现系统性偏差比如连续三天边缘模型都忽略了蒸腾量偏大导致的水分预警就会自动触发模型迭代流程把新的训练数据回流到训练平台生成新版本边缘模型再下发。这个“云端训练—边缘执行—反馈回流”的闭环是我理解的大模型与 AIoT 融合的标准范式。3.3 大模型智能灌溉决策从数据到行动核心的灌溉决策功能我们尝试了一个进阶方案不是简单基于阈值去报警而是用大模型去做“语义时序”联合推理。举个例子。某一天上午 10 点系统监测到土壤 20cm 深度湿度下降速度加快同时气象站显示未来 3 小时可能有降雨。传统阈值逻辑会在湿度跌破 30% 时直接触发灌溉。但大模型可以把这些多模态信息汇总成一个综合判断输出类似这样的结果“当前土壤墒情尚可支撑作物蒸腾约 4-5 小时且气象雷达显示 2 小时后有一次中雨过程建议暂缓灌溉待降雨后根据实时墒情再决定是否补水。”这个建议再通过知识库检索增强附加上“该作物在苗期对渍水敏感注意雨后及时排水”等针对性提醒。这是一个典型的“大模型负责思考、边缘设备负责感知、控制器负责执行”的协作链路。这套系统搭完之后基地的灌溉用水量比原先的人工经验模式节省了差不多 30%而且因为减少了无效灌溉带来的沤根问题整个生长季的烂根发病率明显下降。农业这个靠天吃饭的行业第一次让我感觉“天时”是被计算出来的而不是等出来的。3.4 sim-to-real 仿真AIoT 基础设施的“试车场”最后再聊一个大家容易忽略的板块——仿真基础设施。行业里叫 sim-to-real也就是“从仿真到现实”的技术路线。大模型和 AIoT 系统上线前不可能直接拿真实设备反复试验尤其是涉及机械臂控制、产线调度这类高风险场景试错的代价极高。比较成熟的方案是构建一个数字孪生环境把物理设备的运动学模型、传感噪声模型、网络时延模型全部塞进仿真器里。大模型输出的控制指令先跑一遍仿真看有没有碰撞风险、执行器约束是否满足、极端场景下的响应是否稳定。确认安全了再下发到真实设备。这块以前主要用在机器人领域但我觉得它完全可以泛化到更广义的 AIoT 基础设施中。跑批量的仿真测试不仅能显著缩短现场调试周期而且能让模型在虚拟环境里见过足够多的“意外”到时候真出了问题也不至于毫无准备。4. 常见问题与排查技巧实录AIoT 基础设施落地会踩的五个大坑这部分是纯实战总结。AIoT 基础设施的项目和纯软件项目有个巨大差异不可控的外部因素太多了。硬件故障、通信抖动、现场环境变化每一个都能让架构师设计得再完美的系统瞬间翻车。这里挑五个我踩过最深的坑聊。4.1 通信掉线问题不只是“加个心跳包”那么简单用 MQTT 做设备通信的项目最恶心的故障就是设备无故掉线。很多新手会花大量时间排查网络折腾防火墙策略和路由表。我的排查顺序其实是反过来的先看电源再看网关资源最后才看链路。设备掉线超过一半的情况是供电不稳。工业现场经常有电机启动、变频器工作时产生的电压跌落一些廉价物联网网关的电源适配器余量不足电网稍微波动一下就直接重启了。解决方法是换宽压电源并在网关入口加一个延迟上电模块。其次容易忽视的是网关资源耗尽——设备商默认配置的 512MB 内存跑上容器化网关服务后可用内存很容易被日志文件挤爆导致服务假死。这个问题加一个简单的定时任务清理日志就能解决。4.2 推理延迟抖动模型快不代表系统快边缘 AI 推理项目验收时甲方最关心的指标是响应延迟。但很多团队在实验室测的延迟和现场完全对不上。原因也很典型实验室环境网络干净而现场要把图片上传到 GPU 服务器中间隔着一层 Wi-Fi 或者 4G稍有干扰延迟就飙升。对这种场景我的建议是能边缘处理就边缘处理别过分依赖集中式的推理节点。传输延迟和推理延迟的比例大概是 2:8。所以真正的优化重点是网络层而不是模型层。做智慧安防的门禁项目时我们干脆在门禁一体机里嵌入了轻量人脸识别模型所有比对都在本地完成云端只负责账本管理和策略下发。这样不仅延迟降到 200 毫秒以内可靠性还上了一个台阶——断网也不影响门禁开门这点对客户来说比什么都重要。4.3 模型幻觉问题AIoT 场景里幻觉是会“出事故”的大模型落地 AIoT 场景最大的安全隐患是幻觉。在纯聊天场景里模型一本正经地胡说八道最多被用户吐槽但在设备控制场景里一句错误的操作建议可能导致设备损坏甚至安全事故。做农业系统时我要求所有大模型的输出在控制类指令上必须经过校验器校验。校验器里写死了设备的物理安全边界灌溉阀门开度只能在 0-100% 之间且单次开启时长不能超过 X 小时施肥泵的启停必须与液位传感器联动防止空转烧泵。大模型的输出经过校验器过滤后才会真正下发到 PLC 执行任何超出安全边界的输出都会被直接拦截。我在几个项目里实践下来最有效的一条原则是大模型负责建议规则引擎负责安全人负责最终仲裁。别让模型拥有对物理设备的完全控制权这句话值得写进每一份 AIoT 项目的需求文档里。4.4 OT/IT 融合之痛鸡同鸭讲的两个世界AIoT 项目有一半时间不是在写代码而是在跟甲方运维老师傅对接协议。OT操作技术侧的老师傅习惯的是 Modbus 寄存器、PLC 梯形图、继电器逻辑IT 侧的程序员张口闭口 RESTful API、JSON Schema、微服务。这两个体系的工程师坐在一起开会除非有翻译否则前两周基本是在鸡同鸭讲。我的做法是在项目启动阶段就建立一个双向映射表把甲方设备点表里的每一个寄存器地址翻译成 IT 侧的数据模型字段并约定好量纲、数据类型和刷新频率。这个映射表是整个项目的“通用语言”后续所有联调都以它为准能少吵无数次架。4.5 运维复杂度边缘节点一多K8s 也挡不住人性的弱点AIoT 项目做到一定规模后瓶颈往往不在技术上而在运维上。当你有上千个边缘网关散布在几十个厂区总会有各种意外某一个网关磁盘写满、某一个节点证书过期、某一家分厂把网关塞进了弱电井没人管。靠 SSH 逐个上去敲命令根本维护不过来。比较顺畅的方案是搭建一个中心化的设备运维平台所有边缘节点自动上报健康状态包括 CPU、内存、磁盘、网络连通性、Agent 版本。平台可以自动下发配置、批量升级应用。但这套体系要求边缘侧和中心侧的通信必须稳定所以在架构设计阶段就要把运维通道当成和业务通道同等重要的一等公民来规划。5. 基础设施的“下一个十年”万亿空白里的机会分布最后回归到这个话题的落点上如果未来十年真的属于 AIoT 基础设施那机会到底分布在哪些具体的方向上基于对行业的观察和自己的实践我梳理了几个重点突破方向。5.1 端侧大模型和推理芯片的规模化商用端侧大模型不是概念预热而是已经在设备落地了。手机、车载、智能家居设备都开始要求在本地具备大模型的推理能力。这就推动整个产业链发生结构性变化推理芯片不再只需要跑通 CNN 这类小模型而是要能高效运行 Transformer 这类大模型架构。未来端侧芯片的竞争焦点会集中在三件事算力密度每瓦性能、内存带宽决定能跑多大的模型、工具链成熟度开发者迁移成本。谁能把这三个指标做到平衡谁就能在未来的 AIoT 芯片市场占住身位。这个方向上国产芯片的机会窗口正在打开。5.2 面向 AIoT 场景能力裁剪的中间件除了芯片软件中间件的机会同样可观。海量设备产生的数据要接入大模型底层需要解决协议适配、数据分发、模型调度一整套基础服务。现在的市场现状是要么上重型云平台成本高、绑得深要么全部自研周期长、坑多。中间恰好出现了一个尴尬的断层。未来一定会出现一批轻量级、场景化的 AIoT 中间件能帮助企业快速把设备数据对接到大模型工作流里。这类产品有点像 AIoT 领域的“胶水层”虽然不显眼但属于基础设施中的基础设施。谁先把这个胶水层做扎实谁就掌握了生态入口。5.3 从卖设备到卖“智能服务”的商业重构硬件本身将越来越不值钱。单一传感器硬件的毛利会被卷到一个相当低的水平。真正的价值在于设备联网后产生的数据服务和智能决策服务。这意味着 AIoT 基础设施的商业模式要从“交付硬件”转向“订阅服务”。举个例子一家做空压机节能改造的公司真正提供给客户的不再是空压机和传感器而是一个“压缩空气按需供应”的托管服务。后台的大模型通过实时分析用气规律动态调节空压机的启停组合和排气压力客户只需要按最终节省的电费分成付费。这种模式下客户买的不是设备是省下来的钱。这才是 AIoT 基建最性感的商业形态。6. 实操心得与阶段性建议提前入局的人能做什么说再多趋势和判断最终还是要落到行动上。我最后给准备入局 AIoT 基础设施赛道的团队几条发自内心的建议。第一别急着买服务器先找到高频刚需的场景。大模型也好、AIoT 也罢都是手段客户真正关心的永远是自己业务里的具体问题产线的良率能不能提升、能耗能不能降低、设备停机时间能不能缩短。技术选型要紧贴这些问题来找答案脱离场景的架构只是空中楼阁。第二团队里必须有人同时懂 OT 和 IT。AIoT 项目跟纯互联网项目最大的不同是它一半是软件工程一半是硬件工程和现场工程。一个全员都是算法工程师的团队去现场大概率会被设备接线和工业协议折磨得没脾气。找一个有五六年工控经验的老人比多招两个算法工程师更能帮项目走出泥潭。第三用“小闭环”跑通一个场景再横向复制。我不建议一上来就铺几百个点位的大盘子。先在一个车间、一个大棚、一栋楼里跑通全链路哪怕覆盖范围很小只要指标验证是正向的再总结成标准化方案向外复制。这样做的好处是试错成本可控而且容易拿到客户对效果的信任背书。我自己的体会是技术也好、项目也好最怕的不是难而是方向不明。大模型的这波浪潮来得又快又猛很容易让人产生一种“再不追就晚了”的焦虑。但做了这么多年基础设施相关的事情我愈发坚定一个判断热闹的永远是浪潮尖上的概念而真正活得久、赚到钱的往往是那些在海底默默铺设管道的人。现在这个时间点做 AIoT 基础设施就是在做那个管道层。它不容易上热搜但它是未来十年真正承载智能时代的地基。