生产线上的 PLC 报警后，网关要做的事通常很具体：读取告警码、设备状态和运行日志，给出排查顺序，再把结果交给工程师。若每次都经公网调用云端 API，链路会多出网络波动、服务排队、调用额度和外部服务可用性等变量。对于需要断网运行、数据不便离开厂区的场景，把部分推理留在本地值得尝试。
36氪援引 IDC 的预测显示，全球 AI 计算市场规模将从 2022 年的 195 亿美元增长到 2026 年的 346.6 亿美元，其中 GenAI 计算市场将从 8.2 亿美元增长到 109.9 亿美元。这组数字说明 AI 计算投入仍在增加，但具体把推理放在云端还是网关，最终要看任务和工程成本。
先看任务，别先看参数
边缘部署更适合几类需求：原始日志和工艺参数不便出厂，现场网络不稳定，请求频繁且格式固定，模型任务可以收敛到告警解释、字段提取、日志摘要或知识检索。
如果请求量很低，问题开放且上下文很长，云端 API 往往更省事。所谓“Token 不经济”，通常出现在调用频繁、输入输出相对稳定的业务中。低频任务直接购买和维护网关，未必比按量调用便宜。
还要划清模型的责任。设备急停、联锁保护和阈值控制应继续由 PLC、规则引擎等确定性系统处理。大模型可以解释告警、整理日志和生成排查建议，不宜成为安全控制回路里的唯一决策者。
3B—7B 是容量范围，系列名不能代替选型
当候选清单里出现 Llama 4、Qwen 3 等系列时，先核对具体版本的参数规模、架构、上下文长度、授权条款和工具链支持情况。目标是部署 3B—7B 模型，就应从实际发布的对应版本中筛选，不能只凭系列名判断它能否进入网关。
模型效果也不能用通用榜单替代。更可靠的办法是从真实 PLC 告警、设备日志和维修手册中整理测试集，检查字段提取是否准确、排查步骤是否完整、遇到信息不足时会不会编造答案。模型小一些没有关系，前提是它能稳定完成限定任务。
MoE 模型尤其要谨慎。每次推理只激活部分专家，并不代表设备只需存放这部分权重。运行时通常仍要为大量总权重准备存储和内存，具体占用还受卸载策略影响。对内存紧张的边缘网关，Dense 模型的容量和延迟通常更容易预估。
RK3588 上最容易卡住的是算子和内存
在 Firefly 的产品页 中，可以看到 AI 边缘计算与 RK3588 相关行业定制条目。这类 Arm 设备适合承担网关和现场推理任务，但 NPU 不会自动接管所有计算。
以 RKNN-Toolkit 为例，模型转换前要检查算子支持情况。遇到不兼容的自定义算子，转换可能失败，也可能回退到 CPU。后者更隐蔽：程序能够运行，首 token 延迟却被 CPU 路径拖慢。因此，验收时要查看实际执行日志，确认每一层究竟跑在 NPU 还是 CPU 上。
量化同样要看完整链路。AWQ、GPTQ、INT4 和 FP8 只是算法或格式名称，模型完成量化，不等于 RK3588 的运行时能够直接执行。应先锁定芯片、工具版本和模型结构，再决定量化方案。
一个更稳妥的顺序是先用 llama.cpp 等运行时建立 CPU 基线，确认模型、分词器和提示词没有问题，再进入 NPU 转换和算子优化。Docker 可以封装权重与用户态依赖，但无法抹平不同批次设备的驱动、固件和内核差异，这些版本也要单独记录。
16GB 内存先扣掉这些账
16GB 物理内存不等于模型可以使用 16GB。部署前至少要计算下面几项：
可用余量 = 物理内存 − 操作系统 − 驱动与运行时 − 模型权重 − KV Cache − 输入输出缓冲 − 监控进程
权重文件能够拷进设备，只能说明存储空间够用。模型加载、首轮推理和长上下文生成时，峰值内存还会继续上升。连续排障记录越长，并发会话越多，KV Cache 的压力也越明显，最终可能触发 OOM 或 Swap。
工业场景没有必要把全部历史日志塞进提示词。可以先按设备、告警码和时间范围检索相关片段，再交给模型；同时限制上下文、并发和输出长度。如果运行时支持 KV Cache 量化，也应在真实任务上验证质量和内存变化，不能只看模型启动是否成功。
云边对比，先把测试条件写全
边缘部署常被描述为低延迟、近乎零成本，但缺少模型版本、提示词、并发、网络环境、采样参数和输出长度时，漂亮的数字没有可比性。建议用同一批请求同时测试网关与云端 API，并保留完整配置。
| 评测项 | 边缘网关需要记录 | 云端 API 需要记录 |
|---|---|---|
| 首 token 延迟 | 冷启动、热启动、CPU 回退情况 | 网络耗时、服务排队和限流情况 |
| 完整响应时间 | 生成吞吐、输出长度、设备温度 | 输出长度、网络波动、服务状态 |
| 峰值内存 | 权重、KV Cache、缓冲区和系统占用 | 通常由服务商管理 |
| 结果质量 | 固定测试集上的准确性与稳定性 | 使用同一测试集和提示词 |
| 成本 | 硬件、适配、电费、维护和升级 | Token、API 套餐和网络费用 |
| 可用性 | 断网运行、电源、驱动和 OOM | 公网、额度和服务商可用性 |
本地推理的成本不能只算电费，硬件折旧、模型适配和运维工时都要计入。云端也不必一概排除：当任务变化快、请求量不稳定或需要更强模型时，保留云端路由通常更灵活。
数据安全也不能简单写成“物理隔离”。网关仍可能通过远程运维、镜像更新和日志平台连接外部系统。模型文件、接口密钥、访问权限和审计记录，都应纳入现有的工业安全流程。
先跑通一个小场景
可以从告警解释、维修日志摘要或手册问答中挑一个边界清楚的任务，先建立云端和 CPU 基线，再做量化、NPU 转换和内存优化。复杂问题保留云端兜底，网关优先处理高频、固定、数据敏感的请求。
每次测试都应记录模型版本、量化格式、工具链、固件、提示词模板和失败样本。对于一台 16GB 的 RK3588 网关，能够稳定处理限定任务，比勉强塞入更大的模型更有价值。
边缘部署可以减少不必要的公网往返，也能让部分数据留在现场。它能否进入生产环境，还要看真实日志下的输出质量、断网表现、长时间运行状态和后续升级成本。模型成功启动，只能算第一步。