2、Edge AI基础与推理日志概述
边缘计算与AI推理的结合正在重塑智能系统的部署范式。当模型从云端下沉到边缘设备，日志的角色发生了根本性转变——它不再仅仅是系统运行状态的记录工具，而是成为连接模型性能、硬件资源与业务结果的关键纽带。本章将厘清边缘计算、AI推理与日志三者的关系，并深入剖析日志与指标、追踪在可观测性体系中的分工与协作，为后续字段设计与问题定位奠定认知基础。
上图展示了边缘AI系统的基本架构与可观测性数据流。边缘计算层负责数据采集与预处理，AI推理引擎完成模型加载、前向计算与后处理，而日志、指标、追踪三支柱则从不同维度对系统进行观测。理解这三者的关系，是设计有效日志字段的前提。
2.1 边缘计算与AI推理的融合逻辑
核心原理：为什么推理必须下沉到边缘
边缘计算的核心动机是降低延迟、节省带宽、增强数据隐私。以工业质检场景为例，一台高速相机每秒产生200MB图像数据，若全部上传云端推理，网络延迟将导致产线无法实时响应。将AI推理部署在边缘设备上，推理结果可在毫秒级内返回，同时仅上传异常样本或聚合统计结果。这种"数据在边缘、模型在边缘、决策在边缘"的模式，对日志系统提出了新要求：日志必须记录推理的完整上下文，包括输入数据的来源标识、模型版本、推理耗时、硬件资源状态等。
| 对比维度 | 云端推理 | 边缘推理 |
|---|---|---|
| 网络依赖 | 高，断网即失效 | 低，本地可独立运行 |
| 延迟敏感度 | 百毫秒级 | 微秒至毫秒级 |
| 数据出境 | 原始数据全量上传 | 仅上传结果或摘要 |
| 日志关注点 | 请求量、模型精度 | 硬件资源、推理耗时、掉线恢复 |
| 典型部署 | GPU集群 | Jetson、RK3588、树莓派 |
判断方法：识别边缘推理的日志需求
判断一个系统是否需要专门的推理日志设计，可以从三个问题入手：第一，推理失败时能否快速定位是模型问题、数据问题还是硬件问题？第二，模型更新后，能否对比新旧版本的推理质量差异？第三，当设备离线再恢复时，能否追溯离线期间的推理行为？如果任一问题答案为否，则说明日志体系存在缺口。
案例拆解：智能门禁设备的日志设计
某智能门禁项目部署了人脸识别模型，设备端使用RK3588芯片。初期日志仅记录"识别成功/失败"状态，导致现场问题频发：用户反馈识别速度时快时慢，且偶发识别错误。通过增加结构化日志字段——包括人脸检测耗时、特征提取耗时、比对阈值、底库规模、CPU/GPU占用率、温度——后发现：当设备温度超过75℃时，NPU降频导致推理耗时从80ms飙升至300ms；而识别错误多发生在光线不足场景，日志中的人脸质量分字段（0-100）低于40。据此优化了散热方案并增加了低质量人脸提示，问题解决。
2.2 日志在模型部署与运维中的角色
核心原理：日志是模型生命周期的"黑匣子"
模型部署不是终点，而是运维的起点。在模型生命周期中，日志承担三个核心角色：部署验证——确认模型加载成功、权重文件完整、输入输出维度正确；运行监控——记录推理延迟、吞吐量、错误率的变化趋势；问题回溯——当业务方反馈"识别不准"时，通过日志还原当时的输入数据、模型参数和系统状态。没有日志，模型运维就像蒙眼开车。
操作流程：部署阶段的日志检查清单
- 启动日志：记录模型文件路径、MD5校验值、加载耗时、内存占用。
- 预热日志：记录首次推理的耗时（通常比稳态慢3-5倍），确认是否触发懒加载。
- 请求日志：为每次推理分配唯一request_id，记录输入shape、预处理参数、推理耗时、后处理参数。
- 资源日志：周期性记录CPU/GPU/NPU利用率、内存余量、温度、功耗。
- 版本日志：模型更新时记录新旧版本号、更新原因、回滚标记。
常见误区：日志与监控混为一谈
许多团队将日志等同于监控，认为"有日志就够了"。实际上，日志是离散的事件记录，而监控需要连续的指标聚合。例如，日志可以告诉你"12:03:15 推理超时"，但无法告诉你"过去5分钟超时率从1%上升到15%"。后者需要指标系统。日志擅长回答"发生了什么"，指标擅长回答"趋势如何"，追踪擅长回答"为什么慢"。三者必须协同。
2.3 日志、指标与追踪的关系
核心原理：可观测性的三支柱模型
在分布式系统可观测性领域，日志、指标、追踪被称为"三支柱"。在边缘AI场景中，三者的关系可以这样理解：日志是"点"——记录每次推理的具体事件；指标是"面"——聚合所有推理的统计特征；追踪是"线"——串联一次请求从数据采集到结果返回的全链路。三者互补，缺一不可。
| 维度 | 日志 (Logs) | 指标 (Metrics) | 追踪 (Traces) |
|---|---|---|---|
| 数据形态 | 文本/JSON结构化事件 | 数值型时间序列 | 树状Span集合 |
| 典型问题 | 为什么失败？ | 是否变慢？ | 慢在哪里？ |
| 存储成本 | 高（需保留细节） | 低（聚合后压缩） | 中（按需采样） |
| 边缘场景示例 | 推理错误码、输入异常 | 平均延迟、错误率、NPU利用率 | 从图像采集到结果输出的各阶段耗时 |
| 采集方式 | 主动写入 | 定时拉取/推送 | 请求上下文传递 |
判断方法：如何选择记录方式
在边缘AI场景中，判断使用哪种观测方式可遵循以下原则：需要知道具体原因时用日志（如"为什么这个批次推理失败"）；需要发现趋势变化时用指标（如"延迟是否随温度升高而增加"）；需要定位性能瓶颈时用追踪（如"预处理耗时占比是否过高"）。实际项目中，通常以指标作为长期监控基线，以日志作为问题定位依据，以追踪作为性能分析工具。
案例拆解：智慧零售终端的综合观测
某智慧零售终端部署了商品识别模型，用于自助结账。系统同时启用了三支柱：指标监控显示"平均推理延迟"从80ms缓慢上升至120ms，但日志中无错误记录。通过追踪功能，发现耗时增加主要出现在"图像预处理"阶段——进一步分析日志，发现该阶段包含"图像旋转校正"逻辑，而近期上架的某商品包装图案导致校正算法迭代次数增加。最终通过优化预处理算法，延迟恢复至85ms。此案例展示了三支柱的协作路径：指标发现问题→追踪定位阶段→日志分析根因。
常见误区：过度依赖单一支柱
部分团队只记录日志，不采集指标，导致无法提前发现性能劣化趋势；也有团队只关注指标，当指标异常时缺乏日志细节支撑，无法定位根因。正确的做法是：以指标为"仪表盘"，以日志为"维修手册"，以追踪为"电路图"。在资源受限的边缘设备上，可优先保证日志与指标，追踪采用采样策略（如1%请求采样）。