端侧 AI 不是“一个模型 + 一块芯片”。
它更像一个小型工程系统:传感器先采集真实世界的数据,信号处理单元把数据整理干净,AI 加速器负责跑模型,CPU 做调度,MCU 负责低功耗控制。
这两年一说端侧 AI,大家很容易先想到模型。
模型有多大?能不能本地跑?是不是大模型?有没有 NPU?TOPS 有多少?
这些问题当然重要。但如果我们真的回到一个设备里,比如一副耳机、一台摄像头、一部手机、一个车载传感器,事情就没有这么简单。
端侧 AI 不是“一个模型 + 一块芯片”。
它更像一个小型工程系统:传感器先采集真实世界的数据,信号处理单元把数据整理干净,AI 加速器负责跑模型,CPU 做调度,MCU 负责低功耗控制。
所以这篇文章,我们先不急着讨论某个芯片强不强,也不做“CPU、GPU、NPU 谁更厉害”的排行榜。
我们先把这张地图理清楚:
CPU、GPU、NPU、TPU、MCU、DSP、ISP、FPGA、ASIC,到底分别站在什么位置?它们和端侧 AI 又是什么关系?
这些名词单独看都能查到定义,但放到一个设备里,就很容易混。
原因在于:它们并不是同一层级的“芯片排行榜”,而是一套端侧计算系统里的不同角色。
可以先分成四大类:
| 控制与调度层:MCU、CPU。负责低功耗常开、外设控制、系统逻辑和任务调度。 | |
| 信号处理层:DSP、ISP。负责把声音、图像、传感器信号先处理干净。 | |
| AI 加速层:GPU、NPU、TPU。负责并行计算、神经网络推理和张量计算。 | |
| 定制硬件层:FPGA、ASIC。负责更高效率、更低功耗或特定任务的硬件定制。 |
端侧 AI 计算单元地图
后面我们就按这四层来拆。
先看谁让设备“活着”,再看谁把真实世界的信号整理干净,接着看谁真正跑 AI 模型,最后再看为什么有些场景还需要 FPGA 或 ASIC 这种更定制化的硬件。
读完这篇,你不一定能设计一颗芯片,但至少可以把这些缩写放回正确位置:
谁负责控制?谁负责信号?谁负责模型?谁负责硬件定制?
这比单独背定义更重要。
先说第一层:控制与调度层。
这一层负责的问题不是“模型跑得有多快”,而是设备能不能稳定工作。
MCU 是 Microcontroller Unit,中文常叫单片机或微控制器。
它通常不是用来跑大模型的,而是负责非常基础、非常稳定、非常省电的控制任务。
比如:
| 读取按键; | |
| 采集传感器; | |
| 控制电机、LED 或简单外设; | |
| 维持低功耗待机; | |
| 处理简单逻辑; | |
| 在需要时唤醒更大的系统。 |
在耳机、手表、家电、传感器节点、遥控器、智能门锁里,MCU 很常见。
它不一定算力强,但它能长期待机,功耗低,成本低,稳定性好。
这对端侧 AI 很重要。
因为很多端侧设备不是一直插着电,也不是一直高性能运行。它们更常见的状态是:大部分时间低功耗待机,只有在检测到某个事件时,才唤醒更大的计算单元。
比如一副耳机,一直等着用户说出唤醒词。
如果让大 CPU 或 GPU 一直高负载监听,功耗很快就受不了。更合理的方式,是让低功耗单元先做前置检测,必要时再唤醒更复杂的模型。
有些 MCU 现在也能跑很小的机器学习模型,这就是 TinyML 常说的方向。Arm 的 Cortex-M 系列以及 Ethos-U NPU 相关生态,就是面向低功耗嵌入式 AI 的典型方向之一。[1][2]
但要注意:MCU 能跑 AI,不等于 MCU 适合跑所有 AI。
它更适合小模型、低频率、低功耗、强约束场景。
CPU 是 Central Processing Unit,中央处理器。
它最通用,什么都能做:
| 跑操作系统; | |
| 管理任务; | |
| 执行应用逻辑; | |
| 调度 GPU、NPU、DSP; | |
| 处理复杂但不一定高度并行的计算。 |
如果 MCU 像值班工程师,CPU 更像项目经理。
它负责协调整个系统:什么时候采集数据,什么时候调用模型,结果返回给哪个应用,异常怎么处理。
CPU 当然也能跑 AI 推理。很多小模型、小任务,直接在 CPU 上跑也完全可以。
但从效率上看,CPU 通常不是跑大规模神经网络的最佳选择。
原因也很直观:神经网络里有大量矩阵乘法、卷积和重复计算,CPU 更擅长复杂控制逻辑,而不是海量并行运算。
所以在端侧 AI 系统里,CPU 很重要,但它更多是调度中心,而不一定是 AI 计算主力。
第二层,是信号处理层。
很多人聊端侧 AI,会直接从模型开始讲。
但真实世界的数据,不是直接变成模型输入的。
麦克风采到的是原始声音信号,摄像头采到的是原始图像信号,传感器采到的是时序数据。这些数据往往要先经过处理,才能送给模型。
这里就出现了 DSP 和 ISP。
DSP 是 Digital Signal Processor,数字信号处理器。
它擅长处理连续信号,比如:
| 音频; | |
| 语音; | |
| 通信信号; | |
| 振动信号; | |
| 雷达信号; | |
| 传感器时序数据。 |
比如语音唤醒,不一定一上来就把原始麦克风波形丢给神经网络。
前面可能还有降噪、滤波、回声消除、特征提取。MFCC 这类传统语音特征,也和音频前处理、信号处理关系很近。
DSP 在端侧 AI 里,经常扮演“前处理专家”的角色。
它不一定负责最终模型推理,但它会影响模型看到什么样的数据。
这件事非常关键。
因为模型的输入质量,往往决定了后面的识别效果。
ISP 是 Image Signal Processor,图像信号处理器。
它主要负责摄像头图像进入 AI 模型之前的处理,比如:
| 去噪; | |
| 白平衡; | |
| 曝光; | |
| HDR; | |
| 锐化; | |
| 色彩校正; | |
| 畸变校正。 |
如果没有 ISP,摄像头采集到的原始图像并不一定适合直接给 AI 模型使用。
在手机、摄像头、车载视觉系统里,ISP 非常重要。
你可以把 ISP 理解成视觉 AI 的“图像整理师”。
它先把画面处理到一个更可用的状态,然后后面的模型再做人脸识别、目标检测、场景理解。
所以端侧 AI 不是从神经网络才开始的。
很多时候,AI 之前的信号处理,已经决定了后面模型能不能稳定工作。
第三层,才是大家最常听到的 AI 加速层。
这里包括 GPU、NPU、TPU。
它们都和大量计算有关,但侧重点不一样。
GPU 是 Graphics Processing Unit,图形处理器。
它最早主要用于图形渲染,但后来大家发现,GPU 很适合做大量并行计算。
深度学习里有很多矩阵运算、卷积运算,本质上就是大量相似计算重复执行。GPU 很适合这种任务,所以它成为 AI 训练和推理的重要硬件。
在云端训练大模型,在工作站上跑深度学习,在高性能计算里做大规模并行计算,GPU 都是非常重要的角色。
但到了端侧设备,问题会变复杂。
GPU 很强,但强不等于永远合适。
端侧设备要考虑:
| 功耗; | |
| 发热; | |
| 成本; | |
| 尺寸; | |
| 电池续航; | |
| 是否需要持续运行; | |
| 是否会影响系统其他任务。 |
所以在手机、耳机、摄像头这类设备里,GPU 可以参与 AI 推理,但很多持续、低功耗、实时的 AI 任务,会更希望交给专门的 NPU 或低功耗加速器。
一句话:
GPU 擅长并行计算,但端侧 AI 不只看算力,还要看功耗和持续运行能力。
NPU 是 Neural Processing Unit,神经网络处理器。
它的目标很明确:专门加速神经网络推理。
NPU 通常会针对神经网络里的常见计算做优化,比如:
| 矩阵乘法; | |
| 卷积; | |
| 激活函数; | |
| 低精度计算; | |
| 模型推理流水线。 |
它的优势是,在适合的模型上,能比 CPU 更快,比 GPU 更省电。
这就是为什么现在很多手机、摄像头、AI PC、车载芯片都在强调 NPU。
对端侧 AI 来说,NPU 的意义不只是“跑得快”。
更重要的是:
| 能不能低延迟; | |
| 能不能低功耗; | |
| 能不能长期运行; | |
| 会不会发热; | |
| 会不会拖慢系统; | |
| 能不能在本地完成推理。 |
比如语音唤醒、人脸识别、图像增强、目标检测,这些任务都很适合放到端侧加速器上。
如果说 GPU 让 AI 训练和并行计算跑得更快,那么 NPU 的意义,是让 AI 在手机、摄像头、车机、AI PC 这些设备里跑得更省电、更稳定。
高通的 Hexagon NPU、Arm Ethos-U 系列,都是典型例子。[2][3]
TPU 是 Tensor Processing Unit,最典型的是 Google 推出的 AI 加速器。
TPU 和 NPU 一样,都属于面向 AI 的专用加速器。但 TPU 这个名字更强地绑定 Google 生态。
Google Cloud TPU 面向大规模机器学习训练和推理,强调张量和矩阵计算。[4]
Edge TPU 则是 Google Coral 生态里的边缘 AI 推理加速器,主要面向边缘设备上的低功耗推理。[5]
所以我们可以这样理解 TPU:
TPU 是面向张量计算的专用 AI 加速器代表。
它不一定是所有端侧设备里的通用配置,但它很好地说明了一个趋势:
AI 任务越来越需要专用硬件,而不是全靠通用 CPU。
第四层,是定制硬件层。
这两个词经常出现在芯片和硬件加速讨论里。
FPGA 是 Field-Programmable Gate Array,现场可编程门阵列。
它的特点是:硬件逻辑可以重新配置。
你可以把 FPGA 理解成一个可重构车间。产线不是固定的,可以根据任务重新布置。
它常用于通信、工业控制、原型验证、低延迟处理、特定算法加速等场景。
FPGA 也可以做 AI 加速,但开发门槛比较高,更偏硬件工程师和系统工程师。
ASIC 是 Application-Specific Integrated Circuit,专用集成电路。
它是为某一类任务专门设计的芯片。
优点是效率高、功耗低、性能好。缺点是设计成本高,灵活性差,一旦做出来就很难改。
从这个角度看,很多 NPU、TPU,本质上都可以看作 AI 方向的专用 ASIC。
只是我们平时会把 NPU、TPU作为更具体的名字拿出来讲。
现在我们可以回到最开始的问题。
端侧 AI 到底跑在谁身上?
答案不是某一个芯片。
更准确地说,它跑在一个异构计算系统上。
所谓异构计算,就是不同类型的计算单元各做各的事。
端侧 AI 数据流
真实芯片里,这些模块可能已经集成在同一个 SoC 里。
比如手机芯片、车载芯片、智能摄像头芯片里,CPU、GPU、NPU、ISP、DSP 往往不是一块块分开的板卡,而是同一个系统级芯片内部的不同功能单元。
这也是为什么我们不能只看一个指标。
比如只看 NPU 的 TOPS,并不能完整判断端侧 AI 体验。
还要看:
| 模型能不能放进内存; | |
| 数据从传感器到模型的路径是否顺; | |
| 前处理是否稳定; | |
| CPU 调度是否高效; | |
| 功耗能不能接受; | |
| 长时间运行会不会发热; | |
| 结果返回是否足够及时; | |
| 整个系统是否可靠。 |
端侧 AI 是系统工程,不是单点算力竞赛。
计算单元分工速查
所以,CPU、GPU、NPU、TPU、MCU 这些词,不能只靠背定义。
更重要的是把它们放回系统里看。
MCU 负责低功耗控制,CPU 负责调度,DSP 和 ISP 负责把真实世界的信号整理好,GPU、NPU、TPU 负责不同类型的计算加速,FPGA 和 ASIC 则代表更定制化的硬件实现方式。
端侧 AI 也不是把最大的模型塞进最小的设备。
它更像一次工程分配:
哪些任务应该常开?哪些信号应该先处理?哪些模型适合本地跑?哪些计算应该交给 NPU?哪些任务干脆不该放在端侧?
模型只是其中一部分。
真正决定产品能不能落地的,是功耗、延迟、内存、成本、稳定性,以及这些计算单元之间的协作方式。
这也是为什么端侧 AI 很有意思。
它不是单纯的算法问题,也不是单纯的芯片问题。
它是模型、硬件、信号、系统和产品体验之间的一次工程平衡。
[1] Arm Developer. Edge AI on Arm Cortex-M and Ethos-U. https://developer.arm.com/edge-ai/arm-cortex-m-and-ethos-u" target="_blank">https://developer.arm.com/edge-ai/arm-cortex-m-and-ethos-u
[2] Arm. Arm and Partners: tinyML Resources. https://www.arm.com/campaigns/arm-tinyml" target="_blank">https://www.arm.com/campaigns/arm-tinyml
[3] Qualcomm. Qualcomm Hexagon NPU / Qualcomm AI Engine. https://www.qualcomm.com/processors/hexagon" target="_blank">https://www.qualcomm.com/processors/hexagon https://www.qualcomm.com/processors/ai-engine" target="_blank">https://www.qualcomm.com/processors/ai-engine
[4] Google Cloud. Introduction to Cloud TPU / Cloud TPU Documentation. https://cloud.google.com/tpu/docs" target="_blank">https://cloud.google.com/tpu/docs https://cloud.google.com/tpu/docs/intro-to-tpu" target="_blank">https://cloud.google.com/tpu/docs/intro-to-tpu
[5] Google Coral. Edge TPU / Coral Documentation. https://coral.ai/docs/" target="_blank">https://coral.ai/docs/
[6] Google AI Edge. LiteRT for Microcontrollers. https://ai.google.dev/edge/litert/docs/microcontrollers" target="_blank">https://ai.google.dev/edge/litert/docs/microcontrollers
[7] TensorFlow. TensorFlow Lite for Microcontrollers. https://www.tensorflow.org/lite/microcontrollers" target="_blank">https://www.tensorflow.org/lite/microcontrollers
[8] Qualcomm Developer. AI Engine Direct SDK. https://www.qualcomm.com/developer/software/qualcomm-ai-engine-direct-sdk" target="_blank">https://www.qualcomm.com/developer/software/qualcomm-ai-engine-direct-sdk