从应用场景到实际返回附开源 Laya 安装命令与水泵测试代码。最近 JEV 引起的讨论让做物联网的人也有理由多看一眼。9 月 15 日TypeSafe 发布 JEV。它不负责写一大段分析而是接收当前状态和问题返回程序可以直接使用的选择、评分与概率。[1]这件事和物联网的关系比“给平台加个聊天窗口”更直接设备数据进来以后系统每天都在做判断。故障该派给谁几张工单先处理哪张现场描述的是设备异常还是仪表出了问题已有几套运行方案此刻该把哪套提交给值班员我们关注 JEV就是想看看这类判断能不能换一种做法。为此我们已经把同类开源项目 Laya 部署到了本地跑了中文测试。下面把应用思路、真实结果和安装方法一起展开。先看一个家里的联动场景晚上 11 点多回家客厅有点热家人已经开启卧室睡眠模式。这时如果一开门就全屋亮灯、播放欢迎语联动虽然执行成功人却未必满意。下面这张动图从一个假设的家庭场景看 JEV 这类模型可以放在哪个位置。JEV 做判断收到门磁、有人状态、时间、室温和睡眠设置后在“正常回家、安静回家、暂不联动”等已定义选项中提出建议。图中“安静回家”是预设选项。规则负责把关和执行检查数据是否新鲜、设备是否在线只允许已批准的动作。客厅灯亮至 20%、窗帘关闭、空调设为 26℃低风这些参数来自场景模板不是模型临时编的。卧室不参与判断不确定时保留原状或交给人确认。如果需要一句“为什么这么做”的解释可以再交给生成式大模型整理。它也不直接下发设备指令。当然“深夜睡眠模式”这种固定组合用规则就能做好不必硬加 AI。值得验证的是上下文越来越多、住户描述经常变化时决策模型能否减少复杂的条件分支而不是给每次开关灯都加一次推理。JEV 在物联网里能做哪几件事先看它的三种输出Choice 从给定选项里选一个Noul 回答“是否”的概率Score 按预设等级打分。[2]这不是三个新名词的问题而是能否接进现有业务。设备故障归类少一次来回转派一台循环水泵温度升高、振动增大、出水量下降。光看数值可以触发三条告警再加上“刚做过检修”“润滑逾期”“传感器近期更换”等信息判断就没那么简单了。可以让模型在“机械维修、仪表检查、人工分诊”中选一个复核队列把结果送进工单系统。原始数据和候选概率一起保留维修人员能改派。动图采用合成水泵数据变化过程已压缩“机械维修、优先复核”是预设的分诊建议。规则先处理缺失、过期和阈值检查再让模型辅助分诊工单仍需人工接手。保护联锁独立执行不等待模型也不由模型建议直接触发停机。处置后回填真实故障、误报与改派记录才能检验这套判断有没有用。有没有用先看工单转派次数和接手时间不急着给它贴上“预测性维护”的标签。运维工单排序先去哪个现场同样是异常备用设备能否顶上、现场是否有人、是否影响连续生产都会改变处理顺序。这时可以用 Score 给复核紧急程度评分用 Noul 判断是否需要升级给值班负责人。模型提供排序依据人员安排仍由业务规则和负责人决定。这里真正需要验证的是严重问题有没有被排到后面。平均处理速度提高不能抵消一次严重漏判。运行策略选择在批准过的方案里提建议楼宇空调、循环泵组、储能配套系统都可能有几套经过工程人员确认的运行方案。把负荷趋势、班次、设备可用性和现场限制整理好让模型从已有方案中提出候选比要求它临时编一套控制逻辑更容易评估。但流量、功率、费用计算仍交给程序或专业算法不能指望语言判断替代数值优化。此外边缘侧也可以研究事件筛选哪些上传、哪些先汇总。不过得先测目标工控机的内存和时延不能因为模型“小”就默认任何网关都能装。这些是可探索的接入方向包括联犀在内的物联网平台都可以从现有设备状态、工单和事件接口着手评估。本文不代表这些功能已经在联犀上线。想私有化先分清 JEV 和 Laya大家问“私有化 JEV 怎么部署”这里有个容易混淆的地方。截至本文核对时我们没有找到 JEV 官方可供下载、自行部署的模型权重。本文本地部署的对象是Laya一个独立开源项目不是 JEV 官方开源版也不代表两者能力相同。[1][3]它同样提供 Choice、Noul、Score适合拿来验证这种产品思路。我们选的是多语言模型约 3.22 亿参数支持中文不是把三个模型全部装一遍。[3]另外返回的结构符合约定不等于判断就正确。尤其不能把某个选项的概率直接宣传成“故障识别准确率”。我们已经跑通了什么先把实测和样例分开说。9 月 22 日我们在 Windows 笔记本上完成了 Laya 本地测试Python 3.12.13、RTX 5060 Laptop 8GB、32GB 内存。使用 Laya 0.3.5多语言模型PyTorch 2.14.0cu130。[4]第一组实际输入是中文工单“我的信用卡被扣了两次请尽快退款否则我要取消服务。”同时问三个问题该由哪个部门处理、是否需要今天处理、处理优先级多高。下面是本地 API 一次实际返回的关键字段不是示意值部门billing账单/退款 该选项概率0.9928 今天处理的 Noul 值0.9316 优先级 Score2.5901 优先级 confidence0.4195 运行设备cuda 本次接口记录耗时1880.46 ms评分标准有四档0 为“低可以等待”1 为“普通近期处理”2 为“高今天处理”3 为“紧急立即处理”。因此 2.5901 不是百分制分数。优先级的 confidence 也没有高到可以忽略人工复核。这次测试证明了中文输入、三类问题和本地 CUDA 推理链路已经跑通还不能证明它会诊断水泵。原记录中的水泵请求已经整理出来但没有对应的实际推理输出我们不替模型编答案。耗时也只按日志说话首次 SDK 推理记录为 2386.02 ms上述 API 调用为 1880.46 ms。这是两次不同调用不是 P50/P95更不是稳定吞吐量首次下载和模型加载另算。[4]怎么安装先把一个中文模型跑起来以下默认 Linux、Python 3.12、CPU 独立环境。版本按前述测试记录整理但这套 Linux CPU 命令尚未在本轮执行Windows CUDA 的既有实测不能替代跨平台验证。第一步建环境装依赖python3.12-mvenv .venvsource.venv/bin/activate python-mpipinstall--upgradepip python-mpipinstalltorch2.14.0 --index-url https://download.pytorch.org/whl/cpu python-mpipinstalllaya0.3.5transformers5.17.0 huggingface-hub1.32.0numpy2.5.3safetensors0.8.0 python-mpip checkWindows PowerShell 把前两行换成py-3.12-m venv.venv.\.venv\Scripts\Activate.ps1我们那台笔记本使用 cu130 版本。若要复现同类 CUDA 环境替换掉 CPU 安装命令python-mpipinstalltorch2.14.0 --index-url https://download.pytorch.org/whl/cu130 python-cimport torch; print(torch.__version__); print(torch.cuda.is_available())这是部署时实际遇到的一个问题机器有显卡第一次装出来的却是 CPU 版。换对包后检查结果才是2.14.0cu130和True。其他显卡、驱动应按 PyTorch 官方说明选择不能直接套用这台机器的配置。[5]第二步用水泵样例提出三个问题保存下面代码为pump_smoke.py执行python pump_smoke.py。首次运行会下载模型文件后续调用在本机计算。要在断网环境使用还需要提前准备完整缓存并验证离线加载。水泵辅助研判样例不连接设备控制。importjsonimportos os.environ.setdefault(USE_TF,0)importlaya# 合成状态数值和阈值仅供测试不是工业标准。state{设备:循环水泵07,轴承温度℃:103.4,振动mm/s:11.8,流量m3/h:64.3,近30分钟:温度上升振动增大流量下降,维护:润滑逾期有金属颗粒记录,数据状态:完整5秒前采集,规则检查:温度和振动已触发人工复核}# 三题分别做分流、升级建议和优先级判断。questions{复核队列:{type:choice,instructions:应先交给哪个队列复核,criteria:{机械维修:振动、温升或润滑异常,仪表检查:测量数据相互矛盾,人工分诊:信息不足无法判断}},升级复核:{type:noul,instructions:是否需要优先人工复核},紧急程度:{type:score,instructions:评估复核优先级不决定停机。,criteria:[按计划,近期,优先,立即复核]}}# 明确选择中文多语言模型默认 CPU。agentlaya.load(convaiinnovations/laya-multilingual,devicecpu)resultagent.predict(state,questions)print(实际设备,agent.device)print(json.dumps(result,ensure_asciiFalse,indent2))确认 CUDA 可用后把devicecpu改成devicecuda并核对程序打印的实际设备。SDK 发生回退时不能把 CPU 运行时间记成 GPU 成绩。这段水泵代码是待运行样例未附带伪造的结果。它有意只做三个问题完整九问题请求和八类边界场景另放在部署测试附件里。第三步不要只测这一条“好判断”的数据同一台泵至少再测正常、单项异常、多项异常、关键数据缺失、数据过期、长输入截断以及阈值上下两侧的样本。Laya 多语言模型的默认输入上限是 1024 token状态、问题和选项要共同占用预算。长篇设备档案可能被截断输入了完整 JSON不代表模型看到了全部内容。项目也披露了零样本表现与概率校准的限制需要在本领域重新评估。[3]实际落地时缺失、过期或超预算输入先拦住交给人工。数据合法性、阈值比较和保护联锁走确定性逻辑不让模型“猜一个还能用的结果”。值不值得接入拿自己的案例算账我的建议是从一个已有人工处理流程的场景开始别一上来就让模型决定停机。抽取脱敏历史事件按设备和时间分开训练、验证与测试数据避免同一次故障两边出现。用现有规则做对照观察“规则模型”是否减少了转派和等待同时记录严重异常漏判、误报、人工复核比例。模型阈值在验证集调整固定后再看测试集。下载、冷加载、首次推理、预热后 P50/P95 分开记录。我们目前只有前述中文冒烟结果没有水泵诊断准确率也没有稳态速度结论。JEV 值得物联网行业关注是因为它把“模型输出如何进入业务流程”摆到了台前。Laya 则给了团队一个可以动手验证的开源入口。对设备企业来说积累的检修结论、运行上下文和处置反馈比装上一个模型更难得。把这些资料整理成可验证的案例才知道这次热点和自己的产品有没有关系。你最想让 JEV 这类模型接手哪一种重复判断是故障分流、工单排序还是已有运行方案的选择资料与测试记录[1] TypeSafeJEV 发布说明2026-09-15[2] TypeSafe 官方接口定义[3] Laya 官方开源仓库与模型说明[4] 云物通科技本地测试记录2026-09-22中文工单 API 返回与依赖记录已随交付附件保存。本文引用既有执行日志本轮未重跑模型。[5] PyTorch 安装说明资料核对截至 2026-09-22。业务应用为方案讨论本地实测对象为 Laya不是 JEV 官方模型。欢迎关注我们的开源项目联犀 things · Go 物联网开源模块提供设备接入、物模型、设备数据与 OTA 等基础能力。本文介绍的完整 AI 平台能力不等于该仓库的开源范围。https://gitee.com/unitedrhino/things欢迎点亮 Star也欢迎关注联犀持续分享AI物联网的开发进展、开源实践与应用案例历史阅读推荐一个 AIoT 物联网平台免费商用还能做自己的 SaaS每月电费花在哪这套智慧能源管理平台3D数字孪生看能耗AI查数据、辅助配置告警别再一笔笔画了WorkBuddy 几分钟搞定配电室组态CAD 一次图、2D 和 3D纯 Go 的 CAD 解析库 go-cad开源啦,dwg/dxf格式直接解析纯 Go 实现的文档解析库 docling,开源了AI 时代的真万物互联人和多个 AI Agent 如何通过设备通道与外部渠道协作做物联网项目不必先买平台授权联犀私有化部署永久免费