从应用场景到实际返回，附开源 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.0+cu130。[4]
第一组实际输入是中文工单：
“我的信用卡被扣了两次，请尽快退款，否则我要取消服务。”
同时问三个问题：该由哪个部门处理、是否需要今天处理、处理优先级多高。下面是本地 API 一次实际返回的关键字段，不是示意值：
部门：billing（账单/退款）
该选项概率：0.9928
今天处理的 Noul 值：0.9316
优先级 Score：2.5901
优先级 confidence：0.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 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install torch==2.14.0 --index-url https://download.pytorch.org/whl/cpu
python -m pip install laya==0.3.5 transformers==5.17.0 huggingface-hub==1.32.0 numpy==2.5.3 safetensors==0.8.0
python -m pip check
Windows PowerShell 把前两行换成：
py -3.12 -m venv .venv
.\.venv\Scripts\Activate.ps1
我们那台笔记本使用 cu130 版本。若要复现同类 CUDA 环境，替换掉 CPU 安装命令：
python -m pip install torch==2.14.0 --index-url https://download.pytorch.org/whl/cu130
python -c "import torch; print(torch.__version__); print(torch.cuda.is_available())"
这是部署时实际遇到的一个问题：机器有显卡，第一次装出来的却是 CPU 版。换对包后，检查结果才是 2.14.0+cu130 和 True。其他显卡、驱动应按 PyTorch 官方说明选择，不能直接套用这台机器的配置。[5]
第二步：用水泵样例提出三个问题
保存下面代码为 pump_smoke.py，执行 python pump_smoke.py。首次运行会下载模型文件，后续调用在本机计算。要在断网环境使用，还需要提前准备完整缓存并验证离线加载。
"""水泵辅助研判样例，不连接设备控制。"""
import json
import os
os.environ.setdefault("USE_TF", "0")
import laya
# 合成状态：数值和阈值仅供测试，不是工业标准。
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。
agent = laya.load(
"convaiinnovations/laya-multilingual",
device="cpu"
)
result = agent.predict(state, questions)
print("实际设备：", agent.device)
print(json.dumps(result, ensure_ascii=False, indent=2))
确认 CUDA 可用后，把 device="cpu" 改成 device="cuda"，并核对程序打印的实际设备。SDK 发生回退时，不能把 CPU 运行时间记成 GPU 成绩。
这段水泵代码是待运行样例，未附带伪造的结果。它有意只做三个问题；完整九问题请求和八类边界场景另放在部署测试附件里。
第三步：不要只测这一条“好判断”的数据
同一台泵，至少再测正常、单项异常、多项异常、关键数据缺失、数据过期、长输入截断，以及阈值上下两侧的样本。
Laya 多语言模型的默认输入上限是 1024 token，状态、问题和选项要共同占用预算。长篇设备档案可能被截断；输入了完整 JSON，不代表模型看到了全部内容。项目也披露了零样本表现与概率校准的限制，需要在本领域重新评估。[3]
实际落地时，缺失、过期或超预算输入先拦住，交给人工。数据合法性、阈值比较和保护联锁走确定性逻辑，不让模型“猜一个还能用的结果”。
值不值得接入，拿自己的案例算账
我的建议是，从一个已有人工处理流程的场景开始，别一上来就让模型决定停机。
抽取脱敏历史事件，按设备和时间分开训练、验证与测试数据，避免同一次故障两边出现。用现有规则做对照，观察“规则＋模型”是否减少了转派和等待，同时记录严重异常漏判、误报、人工复核比例。
模型阈值在验证集调整，固定后再看测试集。下载、冷加载、首次推理、预热后 P50/P95 分开记录。我们目前只有前述中文冒烟结果，没有水泵诊断准确率，也没有稳态速度结论。
JEV 值得物联网行业关注，是因为它把“模型输出如何进入业务流程”摆到了台前。Laya 则给了团队一个可以动手验证的开源入口。
对设备企业来说，积累的检修结论、运行上下文和处置反馈，比装上一个模型更难得。把这些资料整理成可验证的案例，才知道这次热点和自己的产品有没有关系。
你最想让 JEV 这类模型接手哪一种重复判断？是故障分流、工单排序，还是已有运行方案的选择？
资料与测试记录
[1] TypeSafe：JEV 发布说明，2026-09-15
[2] TypeSafe 官方接口定义
[3] Laya 官方开源仓库与模型说明
[4] 云物通科技本地测试记录，2026-09-22；中文工单 API 返回与依赖记录已随交付附件保存。本文引用既有执行日志，本轮未重跑模型。
[5] PyTorch 安装说明
资料核对截至 2026-09-22。业务应用为方案讨论；本地实测对象为 Laya，不是 JEV 官方模型。
欢迎关注我们的开源项目
联犀 things · Go 物联网开源模块
从设备接入、物模型到设备数据与 OTA，为你的智能应用打好基础。
觉得有用，欢迎点亮 Star！
也欢迎关注联犀，持续分享 AI＋物联网的开发进展、开源实践与应用案例。
