端侧AI的持续性能，要在接近交付状态的整机上测量：固定模型与输入，连续运行真实任务，同时记录响应时间、温度、频率、功耗和失败事件。刚开机时的一次最快结果，只能说明当时条件下的表现；设备装进外壳、开启摄像头和通信、运行到温度稳定之后，能否持续完成任务，才决定它是否适合长期部署。
这里的“持续”没有适用于所有产品的统一时长。常开摄像头、偶尔唤醒的语音设备和短时工作的手持终端，负载节奏完全不同。验收首先要回答：设备在什么环境里，以什么频率工作，需要连续服务多久，允许怎样降级。
算得动与持续算得动，是两份证据
推理涉及计算、内存访问和数据搬运，这些活动会消耗电能并产生热量。设备初始温度较低时，可以短时间保持较高性能；温度升高后，系统可能调整频率与电压，限制功耗。限制出现后，同一个模型、相同输入也可能需要更长处理时间。
NVIDIA的Jetson Linux r38.4文档说明，热管理会利用风扇和时钟节流控制温度；当热区超过相应阈值，DVFS机制降低工作频率及相关电压。文档还区分过流、电压下降等瞬态事件引起的硬件节流。因此，“频率下降”需要结合温度和供电证据判断原因，不能一律归结为散热。Jetson Thor电源与性能文档
对于产品团队，最有用的比较单位是完整工作负载。图像任务需要包含采集、解码、缩放、推理和输出；语音任务需要包含录音、端点检测、识别及播放；本地大模型需要区分输入处理与逐字生成。只测其中一个算子，会遗漏其他模块对功耗、内存和调度的竞争。
一块开发板放在开放桌面上表现良好，并不保证进入密闭外壳后保持同样速度。散热片接触、风道、安装方向、附近热源与环境温度都会影响热量排出。硬件、结构与软件团队应使用同一份测试条件，避免每个人都测得“正常”，组合之后却无法复现。
先定义用户等待的到底是哪段时间
响应时间从哪里开始、到哪里结束，应在测试前写清楚。摄像头检测可以从帧进入应用到结果可用；语音对话可以分别记录讲话结束到首段回复、完整回复播放结束；执行设备还需要记录指令到达至动作完成。
这些时间不能互换。模型生成首个字很快，但音频合成排队很久，用户仍然会感觉迟钝。设备推理每秒处理很多帧，但只保留最后一帧、前面积压大量数据，也可能使实时交互失去意义。
持续测试至少保留三类观察：每次任务的结果是否正确，任务是否在约定时限内结束，以及未完成任务如何处理。平均时延有助于概览，尾部时延和超时比例则揭示偶发卡顿。报告分位数时必须说明样本量、测量区间与统计方法，不能把极少量请求的百分位当稳定指标。
对连续视觉输入，可以同时记录输入帧率、实际处理帧率、丢帧数和结果年龄。对问答设备，可以保存输入长度、输出长度、首字时间、生成时间和取消情况。用户看到的可用性，来自这些指标共同满足要求。
冷启动、预热和热稳定分别看
第一次运行可能包含模型加载、内存分配、图编译或内核准备。把这些成本全部混入平均值，会让人误判每次任务都很慢；把第一次完全删除，又可能掩盖设备重启后真实的等待。
可以将记录分为冷启动、软件预热和持续运行三个阶段。冷启动回答设备多久可服务；软件预热回答缓存和编译准备完成后的基本速度；持续运行回答整机热状态变化后是否仍满足任务要求。
预热完成不等于达到热稳定。缓存可能很快准备好，外壳和散热组件却还在升温。应观察温度、频率和时延曲线是否进入相对稳定区间，并保留仍在变化的情况。不能只运行固定次数，就在没有温度证据时标成“稳态”。
一篇2026年3月的边缘推理论文，用同一小模型和固定输入比较手机、NPU与笔记本GPU平台，专门记录温度与持续负载表现。作者也明确限制：这是特定模型、输入及软硬件组合的刻画，不能独立推广为所有芯片的能力排名。它提供的实用启发，是把连续运行纳入协议，而不是照搬某台设备的速度结论。论文方法与局限
让监测数据与任务日志对得上
诊断时需要一条统一时间轴。每次推理记录开始、结束、结果状态；系统监测记录温度、频率、内存与功率；应用记录队列长度、丢帧和后台活动。随后才能判断，某次延迟上升是否与频率限制、内存压力或突发输入同时发生。
在Jetson平台，tegrastats可提供处理器和内存相关状态，具体字段与所用系统版本对应。它适合辅助观察，但某一电源轨的读数不应直接当成整机插座功率。包含显示、传感器、通信与外设的产品，还需要按实际供电边界测量总能耗。NVIDIA监测说明
Android的Thermal API可以提供热状态相关信息，但官方文档提示存在设备实现差异：部分设备的状态值不能完整反映节流，热余量接口还存在调用频率与NaN返回值限制。接口不可用应保留为不可用，不能把缺失值解释成温度正常。Android Thermal API
监测也会占用资源。采样过密、不断写大量日志，可能改变被测设备本身的负载。先确认采样开销，再固定采样周期；比较不同方案时使用同样的采集方法。原始记录与汇总结果分开保存，异常点不要为使曲线好看而删除。
出现变慢时，按证据定位
如果时延升高同时温度上升、频率下降，可优先检查散热与功耗约束。若温度变化不大而输入队列越来越长，可能是到达速度持续超过处理能力。若模型阶段稳定、端到端时延变差，则要检查图像解码、通信、音频播放或业务处理。
内存不足也可能表现为卡顿。模型权重之外，输入缓冲、中间张量、上下文缓存和多个并发任务都会占空间。增加并发有时提高总吞吐，却使单次等待更长；小内存设备还可能出现分配失败或进程退出。记录失败原因，比只统计成功请求的速度更重要。
供电问题需要单独排除。线缆压降、适配器能力或外设同时启动，可能影响可用功率。不要通过关闭保护机制、提高热阈值来使测试暂时通过；这会改变安全边界，也使结果不再代表正常交付配置。
定位阶段每次调整一个主要因素。更换散热结构时保持模型和功率模式一致；更换模型时保持输入集和设备条件一致。多个因素一起改变，即使速度改善，也难以解释下一批设备应复制哪一项设计。
把降级做成可验证的产品行为
热负载上升时，可以考虑降低非关键视觉处理频率、限制并发、缩短非必要生成或切换较轻模型。具体顺序应由业务优先级决定：设备状态反馈和必要的本地操作，应与耗时的分析任务分别设计。
降级必须保留语义。降低图像采样率后，某类短暂事件可能更难被观察；缩短生成长度后，回复可能不完整；切换模型后，准确率和指令遵循能力可能变化。性能策略需要同时检查结果质量，不能只以温度下降作为成功。
恢复策略同样需要测试。负载降低后立即恢复最高性能，可能让设备反复在两个状态间切换。可以根据连续观测和稳定区间决定恢复，避免频繁抖动。具体阈值来自目标平台与项目评估，不应复制另一款芯片的保护温度。
若允许云端协同，还要分别覆盖断网、网络抖动和云端不可用。把任务转移到云端会改变数据路径、费用和等待时间，不能把它当成无条件有效的散热方案。设备需要明确哪些能力可本地完成，哪些必须等待网络恢复。
一份能交接的验收记录
验收材料应包含整机型号与硬件版本、外壳与散热配置、系统和驱动、模型及量化方式、输入集、后台任务、环境条件、供电方式和功率模式。每次改动都能与对应结果关联，后续才有条件复现。
结果至少回答四个问题：启动后何时可用，持续运行是否满足任务时限，异常时如何降级，恢复后是否回到正常状态。通过条件需要在测试前约定，保留失败与不可测项；不同任务类型分别判断，避免用一个总分盖住关键失败。
产品从开发板走向整机，算力参数只是起点。真正值得交付的是可重复的服务能力：在约定环境和负载下，设备持续给出可用结果，并在资源不足时表现得清楚、可控。准备项目资料时，可将这些条件与AI硬件方案中的硬件、软件与整机需求一起梳理。