pg电子官网：AI智能硬件、端侧大模型与嵌入式Edge AI

模型文件只有几个GB，看起来已经能放进一台旗舰手机的存储。真正开始部署以后，工程师最先撞上的通常不是“装不下”，而是这个模型一旦加载起来，RAM、KV Cache、Activation Memory和Memory Bandwidth会把整台设备逼到边缘：后台App被清掉，屏幕开始发烫，电量以肉眼可见的速度往下掉。这时再回头看需求文档，会发现一个尴尬的事实——这台设备真正需要做的事情，可能只是Wake Word、Noise Classification和几十条Command Understanding，而这些任务用一个几百万参数的模型就能完成。pg电子端侧AI在讨论端侧大模型时始终坚持一个前提：“能不能运行”只是入门问题，“为什么需要这么大”才是设计问题。

这篇文章用Model-to-Device Fit Map来拆解这个判断链：Use Case → Required Capability → Model Size → Memory → Compute → Power → Latency → Device Fit。第一步永远是Use Case。一副只需要识别用户是否在说话、并把三十个固定指令映射成动作的耳机，与一台需要在离线状态下分析本地文档、生成摘要并回答追问的AI PC，对Required Capability的要求相差几个数量级。如果一开始就用“最强模型”做起点，后面每一层都会被迫为它买单：Model Size决定Memory，Memory决定能不能常驻，能不能常驻决定每次唤醒要不要重新加载权重，加载权重又直接反映到Latency和Power上。

Memory这一层尤其容易被低估。很多人只看参数量和文件大小，但一个20B级别的模型即使量化到INT4，在设备上运行时还要为Context Length分配KV Cache，为每一层的中间结果分配Activation Memory，这些加起来往往比权重本身还难处理。更麻烦的是Memory Bandwidth：生成式模型每输出一个token都要把大量权重从内存读一遍，设备内存带宽远低于服务器，这意味着即使算力够，速度也会被“搬数据”卡住。pg电子模型内容里反复强调，端侧大模型的瓶颈很多时候不在算，而在读。

Power和Thermal是设备与服务器最根本的差异。服务器可以插电、装风扇，设备只有一块电池和一层外壳。一个大模型在手机上连续工作十分钟，SoC温度上升后触发Thermal Throttling，频率下降，速度变慢，用户感受到的是“越用越卡”。与其说这是硬件不行，不如说是模型选错了尺寸。反过来，如果任务确实需要复杂本地文档分析和多轮推理，那么更大的模型可能是必要的，此时设备形态、散热设计和电池容量都要为它重新规划，而不是把它当作一个“下载安装”就能解决的软件问题。

Device Fit是这条链的终点，也是pg电子端侧AI真正想回答的问题：这个设备、这个任务、这个功耗预算之下，最小有效模型是什么。它可能是一个TinyML级别的关键词模型，可能是一个1B到3B的Small Language Model，也可能确实需要更大规模。核心判断只有一句：端侧AI设计不是尽量把最大的模型搬到设备上，而是找到设备任务真正需要的最小有效模型。

芯片宣传页写着几十TOPS。把自己的模型扔上去以后，最尴尬的情况是它有几个算子根本没跑在NPU上。两颗标称同为50 TOPS的NPU（这里的数字只是示意），运行同一个量化后的端侧大模型，一颗几秒出结果，另一颗要等好几倍的时间，而且越跑越慢。这不是营销撒谎，而是TOPS这个指标本身只描述了硬件在理想条件下每秒能做多少次乘加运算，它既不知道你的模型长什么样，也不知道你的Runtime能不能把模型完整地映射到NPU上。pg电子官网在讨论AI芯片时的第一条原则就是：TOPS不能成为唯一性能指标。

这篇文章用Real Performance Stack来拆开“真实速度”是怎样被一层层决定的：Model → Precision → Operator → Runtime → Compiler → Memory → NPU → Thermal → Actual Latency。最上层是Model本身：层数、注意力形态、激活函数、是否有动态shape。第二层是Precision：NPU A原生支持INT8和INT4矩阵运算，NPU B只对INT8做了完整优化，那么同一个INT4模型在B上要么被反量化成INT8执行，要么直接回退到CPU。第三层是Operator：模型里一个不太常见的归一化层或者自定义算子，硬件Runtime不支持，整个子图就会被切成几段，部分在NPU、部分在CPU，中间反复搬运数据。

Runtime和Compiler这两层决定了模型图能被优化到什么程度：能不能做算子融合、能不能安排好内存布局、能不能提前分配好缓冲区避免运行时申请。这些都不体现在TOPS里，却直接决定实际执行效率。Memory这一层则常常是生成式模型的真正瓶颈：Decode阶段每个token都要读取全部权重，NPU算得再快，内存带宽跟不上就只能等待。两颗芯片TOPS相同，但一颗配了更宽的内存总线，实际token速度可能相差数倍。

最底下的Thermal层往往在Benchmark里被忽略。跑30秒的测试，两颗芯片都能维持峰值频率；真正的应用场景是连续几分钟甚至几十分钟，此时散热差的那颗会降频，Sustained Performance才是用户实际感受到的速度。pg电子设备内容里一再提醒：Benchmark要看持续曲线，不要只看第一分钟。

所以Actual Latency是这九层共同作用的结果，TOPS只是其中一层的一个数字。它更像硬件能力上限的一部分，而不是应用真实速度的成绩单。一个芯片写着更高TOPS，并不自动代表你自己的模型跑得更快——真正要问的是：我的模型、我的精度、我的算子，在这颗芯片的Runtime上能覆盖多少，剩下的那部分去了哪里。

一块工业振动传感器，MCU的RAM以KB计，Flash以几百KB计，供电靠电池，安装在一台设备上一装就是几年。按照“AI需要大算力”的直觉，这种设备和AI毫无关系。但真实情况是，它每秒钟采集的原始加速度数据如果全部通过无线发出去，电池撑不了几天，网络也承受不了几百个这样的节点同时上传。TinyML要解决的从来不是“把ChatGPT缩进微控制器”，而是让这个最靠近现实世界的数据入口，自己拥有一个最基本的判断：现在是正常，还是异常。pg电子嵌入式AI把这种能力称作“传感器旁边的判断”。

这篇文章用Sensor-to-Decision Loop来描述TinyML在设备里的位置：Sensor → MCU → Tiny Model → Normal / Anomaly → Trigger → Higher-level System。Sensor层是原始信号：振动、声音、加速度、温度。MCU层负责采样、简单滤波和特征提取，比如把一段时间窗内的振动做频谱变换。Tiny Model是一个几十KB、通常INT8量化的小网络，只回答一个非常窄的问题：这个频谱像不像正常状态。Normal / Anomaly是它的输出。Trigger则决定只有出现异常时才唤醒无线模块、通知网关或应用处理器。Higher-level System可以是网关上更大的模型，也可以是云端分析平台，但它们只在被触发时介入。

这个回路的关键在于资源约束反过来定义了模型的形态。RAM只有几百KB，意味着模型的权重、输入缓冲和中间结果加起来必须比这个数还小；Flash有限，意味着模型文件不能随意增长；Power有限，意味着MCU大部分时间要睡眠，Always-on的只能是极低功耗的采样和一个很轻的判断。所以TinyML里的Keyword Spotting、Vibration Anomaly、Gesture Recognition、Sensor Classification，本质上都是把“需要立即判断且信息量不大”的任务留在设备上，把“需要更多上下文”的任务交给上层。

pg电子嵌入式AI内容里特别强调TinyML和端侧大模型的区别：前者面向Microcontroller级别、KB级内存、常年电池供电的设备，后者面向手机、PC和边缘设备上GB级内存的场景。两者都叫“端侧”，但工程约束完全不同，把TinyML写成“手机上的大语言模型”是概念混淆。

真实部署里TinyML还会遇到传感器漂移、温度变化和噪声让准确率下降的问题，这也是为什么回路里需要一条从上层系统回到传感器的反馈路径：调整采样率、更新阈值、必要时更新模型。核心判断是：TinyML的价值不是把ChatGPT缩进微控制器，而是让最靠近现实世界的数据入口拥有最基本的判断能力。

技术上，一颗联网摄像头把一天24小时的视频全部推到云端并不困难，很多产品也确实这么做。问题在于这样做之后发生了什么：带宽费用随着设备数量线性增长，云端要为大量根本没有任何事件发生的画面付出存储和计算成本，用户的完整生活画面离开了家，一旦网络抖动，识别结果就会延迟甚至丢失。pg电子智能传感器讨论的“智能”不是传感器后面接一个云AI，而是传感器自己先做判断，决定哪些数据值得离开设备。

这篇文章用Data Reduction Funnel来描述这个过程：Raw Sensor Data → Local Processing → Feature → Event → Relevant Data → Cloud / Storage。漏斗最上面是原始数据，24小时视频流或者持续的音频流。Local Processing层做降采样、区域裁剪、运动检测，把绝大部分静止画面直接丢掉。Feature层提取运动区域、目标框、音频频谱这类中间表示。Event层是本地模型给出的判断：Person Detected、Vehicle Entered、Glass Break。Relevant Data层则根据事件截取前后几秒的片段。最后离开设备去往Cloud或Storage的，只是事件加少量片段。

每往下一层，数据量都在大幅缩减，而收益是多方面的。Bandwidth从“持续上传”变成“按事件上传”；Privacy方面，完整画面留在设备内，云端只看到“有人”而不是“是谁在做什么”；Latency方面，本地判断是毫秒级的，不用等网络往返；Energy方面，射频模块是很多设备最耗电的部件之一，少传数据直接延长续航。这也是为什么Always-on的传感器几乎必须在本地过滤。

但pg电子官网并不主张“一律少传”。某些场景需要完整记录：安防合规要求保留全部录像，工业质检需要保存原始图像用于事后追溯，医疗监测需要连续波形。这些场景下，漏斗的形状会不一样——本地仍然做事件判断，但原始数据同时写入本地存储或按策略上传。Use Case决定漏斗有多窄，而不是技术本身。

真正的工程难点在Event层的准确性：误报会让用户关掉通知，漏报会让整个系统失去意义。这也是智能传感器为什么需要在本地持续做模型更新和阈值调整。核心判断是：边缘智能不是让设备产生更多数据，而是让设备知道哪些数据值得离开设备。

一副AI眼镜的演示视频往往很惊艳：看一眼菜单就能翻译，看一眼商品就能识别，看一眼路牌就能导航。演示结束以后，真正的问题才出现——镜腿在半小时后开始发热，贴着太阳穴的位置明显不舒服，电池在两个小时内耗尽。视觉模型能力再强，用户也不会每天戴一副发烫的眼镜出门。pg电子设备在讨论可穿戴AI时有一个基本立场：贴近人体的设备，功耗和热设计本身就是AI能力的一部分。

这篇文章用Wearable AI Budget来分析：Battery → Sensor Duty Cycle → Model Wake-up → Inference → Thermal → User Experience。Battery是整个预算的总量，眼镜和耳机的电池容量受重量和体积限制，通常只有手机的一个零头。Sensor Duty Cycle决定摄像头、麦克风、IMU各自有多长时间是开着的——摄像头常开和每分钟拍一帧，能耗差几十倍。Model Wake-up是模型从休眠到可以推理的开销，如果每次都要重新加载权重，唤醒本身就很耗电。Inference是真正做计算的能耗，取决于模型大小、精度和运行在哪个单元上。

Thermal是这条链上最容易被演示掩盖的一环。眼镜没有风扇，散热面积很小，而且直接贴着皮肤。SoC连续推理几分钟，热量积累到某个阈值，系统要么降频、要么强制停止AI功能。降频意味着识别变慢，停止意味着功能不可用，两者都会直接反映到User Experience。手机可以拿在手里发热，眼镜和耳机不行，这是形态决定的硬约束。

所以可穿戴AI的设计核心是Inference Duty Cycle：不是让视觉模型一直跑，而是用极低功耗的Always-on传感（比如IMU检测到头部停顿、麦克风检测到唤醒词）作为触发条件，只在需要时唤醒NPU上的模型，做完立即回到低功耗状态。这也是pg电子智能传感器和pg电子嵌入式AI反复讨论的分层结构在可穿戴设备上的具体形式：MCU / DSP常开，NPU间歇工作，云端只在必要时介入。

这篇文章里的所有能耗比例都是示意，pg电子不虚构任何真实设备的续航或温度数据。核心判断是：智能硬件里的AI性能永远不能脱离产品形态讨论，尤其是贴近人体的设备，功耗和热设计本身就是AI能力的一部分。

量化是端侧模型部署最常用的工具：FP16到INT8体积减半，到INT4再减半，内存占用和带宽压力同步下降。很多人由此形成一个直觉——量化得越狠，设备跑得越快。真实部署里经常出现相反的情况：INT4模型文件确实小了，但在某台设备上比INT8版本更慢，功耗也更高。pg电子模型内容把这种现象叫作“量化的现实检查”，它揭示的是模型压缩和硬件软件栈之间的错位。

这篇文章用Quantization Reality Check来梳理：FP16 Model → Quantize → INT8 / INT4 → Operator Support → Hardware Runtime → Fallback? → Latency / Power / Accuracy。前三步是模型侧的工作，把权重和激活映射到更低位宽。真正决定结果的是后面几步。Operator Support问的是：这颗NPU的Runtime有没有INT4矩阵乘法的原生实现？有没有对应的反量化算子？如果没有，Hardware Runtime只能做两件事之一：把INT4权重在运行时反量化成INT8或FP16再计算，或者把这部分子图整个Fallback到CPU。

Fallback是最常见的性能杀手。假设模型90%的算子在NPU上跑，10%不支持的算子回退到CPU，这10%并不只是“慢一点”——每次跨单元执行都要把Tensor从NPU内存搬到CPU内存，算完再搬回去，Memory Copy和同步的时间可能超过计算本身。于是一个体积更小的INT4模型，在这台设备上的Latency反而高于INT8，功耗也因为CPU被频繁唤醒而上升。pg电子官网在讨论异构计算时反复强调：数据搬运本身就是成本。

Accuracy是另一个不能回避的维度。INT4不是“完全无损”，尤其是对激活值分布不均匀的层和对精度敏感的注意力头，激进量化可能让模型在某些任务上出现明显退化。所以量化方案需要和评估集一起验证，而不是只看文件大小。Latency、Power、Accuracy三者必须一起看，缺一个都可能做出错误决策。

这也是为什么硬件感知优化会成为端侧AI的重点：同一个模型在不同SoC上需要不同的量化策略、不同的算子选择、不同的内存布局。核心判断是：模型压缩只有和真实硬件的软件栈一起优化才有意义，文件更小不等于设备执行一定更快。

2026年，端侧AI最明显的变化之一是从Local Model走向Local Agent：设备上的模型不再只是回答问题，而是能理解一个目标，调用设备工具，执行一串本地工作流——整理相册、总结文档、创建日程、调整设置。厂商的宣传语通常是“一切都在本地完成，数据不上传云端”。这句话是真的，但它只回答了隐私问题的一半。pg电子端侧AI认为另一半更重要：一个能读你所有照片、所有文件、能开麦克风的本地Agent，即使一个字节都不上传，它能访问什么、能执行什么，仍然必须被单独治理。

这篇文章用Local Agent Permission Ladder来划分权限层级：Read Public Data → Read User Data → Open App → Prepare Action → Modify Setting → Sensitive Action → User Approval。最低一级是读取公开数据，比如设备状态、时间、公共知识。往上是读取用户数据——文件、照片、联系人、位置，这一级已经需要明确授权，而且应该按类别而不是一揽子授权。再往上是打开App，Agent可以启动应用但不应自动操作其内部内容。Prepare Action是准备一个动作但不执行，比如起草一封邮件、填好一个表单，等待用户确认。

Modify Setting开始进入高风险区：修改网络、权限、账户设置，这些动作影响范围大且不易察觉。Sensitive Action是最高风险：支付、删除数据、发送消息、控制摄像头和麦克风、修改安全设置。这一级无论Agent多“聪明”，都必须停在User Approval前面，由用户明确批准，而且每次批准只对当次动作有效，不能泛化成永久授权。

这个阶梯之外还有两个不可缺少的机制：Audit和App Boundary。Audit是Agent做过什么要有日志，用户可以回看；App Boundary是Agent不能跨越应用沙箱去读别的应用的私有数据。这些都和云端无关，纯粹是本地治理问题。本地推理让数据传输环节的隐私风险大幅降低，但Agent能力越强，本地访问和执行的边界就越需要清晰。

pg电子官网不会宣传“本地AI绝对安全”。权限、Storage Security、Model Security、App Isolation都是端侧AI必须一起做的事情。核心判断是：本地推理解决的是数据传输的一部分隐私问题，但Agent能访问什么、能执行什么仍然必须单独治理。

设备出厂那天，模型是在实验室里反复验证过的版本，效果很好。第二年，几件事同时发生：新的模型版本发布了，效果更好但需要新的Runtime；硬件换了一批新的元器件，出现了Hardware Revision B；部分用户的固件已经升级到新版本，另一部分因为没连网还停留在旧版；某个批次的设备在更新后识别结果突然变差，而客服完全不知道它到底跑的是哪一版模型。pg电子边缘计算把这个阶段称作AI智能硬件的“第二年问题”——模型烧进去只是开始，真正的工程从设备离开工厂以后才展开。

这篇文章用Device AI Lifecycle来描述整个周期：Ship → Model v1 → Monitor → Update → Canary → Validate → Deploy → Rollback if Needed → Long-term Support。Ship是出厂，Model v1是初始版本。Monitor是持续收集设备端的运行指标：推理延迟、失败率、功耗、温度、异常事件，没有监控就谈不上后面的任何决策。Update是新模型准备好了，但绝不直接全量推送。Canary是灰度：先给1%的设备，观察几天，再扩大到10%，最后全量。Validate是在灰度期间验证精度、功耗、兼容性是否达标。

Rollback是这条链上最容易被忽视、也最关键的一环。新模型可能效果更差，可能功耗更高，可能在Hardware Revision A上根本不兼容。如果设备更新后无法恢复到上一版本，一次失败的OTA就会变成一次召回。所以模型OTA必须设计成可回滚的：设备本地保留上一版模型，版本清单可查，回滚路径经过测试。

Firmware OTA和Model OTA需要区分对待。Firmware是设备的系统逻辑，Model是AI权重和推理Pipeline，两者可以分开更新，但版本必须兼容：新模型要求的Runtime版本、Runtime要求的固件版本、固件支持的硬件版本，构成一个必须被明确管理的兼容矩阵。一个产品可能有几十万台设备分布在不同的Hardware Revision、Firmware和Model Version组合上，这就是Fleet Management存在的原因。

Debug的第一步永远是确认版本：Device A跑的是Model v1.2，Device B跑的是v1.3，结果不同很可能不是bug而是版本差异。Long-term Support意味着几年生命周期内，这套更新、验证、回滚和版本管理的机制要一直运转。核心判断是：AI智能硬件不是“模型烧进去就结束”，而是一套需要长期更新、验证、回滚和版本管理的软件—硬件系统。