1. 本章学习目标学完本章后应能够理解为什么“搭载 Cortex-M4 和几个传感器”不等于拥有 AI 硬件加速器。如何区分普通 MCU、具备 ML / DSP 加速指令的 CPU以及专用 NPU。TinyML 中 Vibration、Voice、Vision 三类任务的计算需求为什么逐级增加。Arm Cortex-M55、Helium 和 Ethos-U55 / U65 分别承担什么角色。CMSIS-NN 和 Vela 编译器如何把模型映射到 Cortex-M 与 Ethos-U。为什么模型推理性能不仅取决于乘加运算次数也取决于内存和数据搬运。如何根据 EEG、ECG、EMG、PPG、HRV、GSR / EDA 的任务复杂度选择硬件而不是盲目购买所谓“AI 开发板”。2. 本章内容导读近年来很多开发板都会在名称或宣传中加入“AI”字样但板载传感器本身不会自动赋予设备人工智能能力普通 Cortex-M4 也不会因为被安装在“AI 开发板”上就变成专用 AI 芯片。本章从“什么才是真正的 AI 硬件加速”出发介绍 Arm 面向端侧机器学习形成的一条性能路线普通 Cortex-M 通过 CMSIS-NN 优化运行模型Cortex-M55 借助 Helium 向量扩展提升 DSP 和机器学习计算效率再由 Ethos-U55 / U65 microNPU 专门加速神经网络。与此同时Vela 编译器负责分析模型把可支持的网络算子交给 NPU把暂时无法支持的部分留给 CPU。本章最重要的结论是AI 加速能力 ≠ 开发板名称里带有“AI” ≠ 板载传感器数量多 ≠ 单纯提高 CPU 主频 真正的 AI 加速能力 合适的计算架构 专用指令或 NPU 优化内核 模型编译器 合理的内存系统 可验证的延迟与能耗提升3. “AI 开发板”的 AI 到底在哪里3.1 传感器不是 AI 加速器一块开发板可能带有麦克风摄像头加速度计陀螺仪温湿度传感器PPG、ECG 或其他生理信号传感器。这些器件负责感知外界是数据来源但它们本身通常不负责执行神经网络。可以把整个系统分成三层传感器 负责采集声音、图像、振动或生理信号 处理器 负责滤波、特征提取、模型推理和设备控制 软件与模型 决定如何从数据中得到分类或预测结果因此“板载很多传感器”只能说明它方便采集数据不能证明它拥有更强的 AI 运算能力。3.2 能运行模型不等于有专用硬件加速普通 Cortex-M4、STM32、nRF52 或 ESP32 也可以运行小型机器学习模型。只要模型足够小使用 C / C 实现推理就能够在没有专用 NPU 的 MCU 上完成分类。但这里应区分三个层级层级硬件特点代表方式是否属于专用 AI 加速通用 MCU 运行 ML使用普通 CPU 指令执行模型Cortex-M4、M7 等运行小型模型否CPU 内置 DSP / ML 增强指令通过 SIMD、点积、向量指令提升计算效率Cortex-M55 Helium属于 CPU 级加速但不是独立 NPU专用神经网络加速器由专门硬件执行卷积、矩阵乘法等网络运算Ethos-U55 / U65是因此比较准确的说法是Cortex-M4 可以运行机器学习Cortex-M55 是针对 DSP 和 ML 增强的通用 CPUEthos-U55 / U65 才是专门面向神经网络推理的 microNPU。Arm 官方将 Cortex-M55 描述为首批采用 Helium 向量处理技术、面向高效 DSP 和机器学习的 Cortex-M CPUEthos-U55 则被定义为面向受限嵌入式系统、专门加速 ML 推理的 microNPU。(Arm)4. TinyML 的三类典型负载Vibration、Voice、Vision本章按照计算需求由低到高把 TinyML 应用大致归纳为三个方向Vibration 振动 / 时序传感器 → Voice 语音 → Vision 视觉Arm 官方 TinyML 资料同样将应用归纳为 Vibration、Voice 和 Vision并分别覆盖异常检测、关键词识别、自动语音识别、目标检测和姿态估计等任务。(Arm)4.1 Vibration振动和低维时间序列Vibration 不应只理解为电机振动它可以代表一类低维、连续的传感器时间序列任务例如工业电机振动异常检测人体动作识别设备健康监测传感器融合简单 ECG、PPG、EDA 状态分类基于统计特征的 EMG 动作识别。这类任务通常具有以下特点输入通道较少数据维度相对有限常使用统计特征或频域特征模型可以是决策树、SVM、小型 MLP 或 1D CNN很多任务可以在普通 Cortex-M4 / M7 上完成。4.2 Voice语音和多阶段信号处理语音任务的计算链通常更长麦克风采样 → 降噪 → 回声消除 → 波束形成 → 分帧和加窗 → MFCC / 频谱特征 → 神经网络推理 → 关键词或语音结果简单的 Keyword Spotting关键词检测可以运行在普通 MCU 上完整的 Automatic Speech Recognition自动语音识别则通常需要更高算力、更多内存和更复杂的模型。这里有一个非常重要的认识一个完整语音应用的耗时不只来自神经网络还来自前端信号处理。即使把神经网络加速了几十倍如果波束形成、降噪、回声消除和 MFCC 仍然很慢整个系统也不一定获得相同比例的加速。4.3 Vision视觉任务视觉任务通常计算量最大因为一张图像本身就包含大量像素。常见任务包括图像分类人体存在检测人脸识别手势检测缺陷检测目标检测。视觉任务不仅需要更多乘加运算还需要保存较大的输入张量和中间特征图因此 RAM、Flash 和内存带宽都会成为限制。4.4 三类任务并没有绝对边界Vibration、Voice、Vision 只是一种粗略的计算量分级。实际需要多少算力还取决于输入通道数量采样率或图像分辨率时间窗口长度网络层数模型参数数量数据精度目标准确率推理频率前处理复杂度。例如同样是语音任务单麦克风 2 个关键词与多麦克风 波束形成 降噪 连续语音识别对硬件的要求完全不同。模型准确率每提高一点也可能需要显著增加模型宽度、深度和计算量。5. Cortex-M55带有 ML 能力的 CPU而不是独立 NPU5.1 Helium 是什么Cortex-M55 的关键技术是Arm Helium也就是 Arm M-Profile Vector Extension简称 MVE。普通 CPU 往往一次处理一个或少量数据而向量指令可以在一次指令中并行处理多个数值。例如神经网络和数字信号处理中经常需要执行多个采样值同时相乘 多个乘法结果累加 向量点积 滤波器卷积 矩阵运算Helium 可以提高这类操作的执行效率特别适合FIR / IIR 滤波FFT音频处理图像处理int8 神经网络向量点积多通道传感器处理。Arm 官方给出的特定基准结果显示Cortex-M55 相比此前 Cortex-M 处理器可获得最高约 5 倍 DSP 性能和 15 倍机器学习性能提升这些数字是特定条件下的官方性能指标并不代表所有模型都能得到相同加速。(Arm)5.2 为什么 int8 点积很重要量化神经网络经常使用 int8 参数和激活值。一个卷积层本质上需要反复计算其中(x_i) 是输入(w_i) 是权重(b) 是偏置乘法和累加会执行大量次数。Cortex-M55 的向量和点积能力可以一次处理多个 int8 数据提高卷积、全连接层等操作的效率。这也是为什么同样运行 int8 模型M55 通常比只依靠普通标量指令的 MCU 更高效。5.3 AI 计算也是内存访问问题本章有一个很容易被忽略但非常重要的观点机器学习不仅是计算问题也是数据访问问题。模型推理需要不断读取网络权重输入数据中间特征偏置参数量化参数。如果处理器计算速度很快但内存无法及时提供数据计算单元仍会等待。因此评估 AI 硬件不能只看主频 MAC/s TOPS还要看SRAM 容量 Flash 带宽 缓存 总线 数据复用 权重压缩 中间张量占用这也是为什么模型大小和 RAM 峰值往往比单纯的参数数量更能决定一个模型是否可以部署。5.4 Cortex-M55 的安全能力Cortex-M55 支持 TrustZone可将系统划分为安全区域和非安全区域用于隔离密钥、安全启动、敏感固件和普通应用代码。对于联网 IoT 和可穿戴生理信号设备这类硬件隔离有助于提高系统机密性和完整性。(Arm)但 TrustZone 并不意味着产品自动安全。实际系统还需要安全启动固件签名通信加密密钥管理权限控制安全升级漏洞测试。6. Ethos-U55真正面向 MCU 系统的 microNPU6.1 microNPU 是什么NPU 是 Neural Processing Unit神经网络处理单元。它不是为了替代整个 CPU而是专门处理神经网络中高度重复的计算例如卷积矩阵乘法全连接层激活函数池化循环网络中的部分计算。Ethos-U55 是为受限嵌入式和 IoT 设备设计的 microNPU。它通常与 Cortex-M CPU 配合使用而不是独立运行整个程序。Arm 官方说明其支持常见 CNN 和 RNN 运算并能在受限面积和功耗条件下加速端侧 ML 推理。(Arm)6.2 CPU 和 NPU 如何分工一个完整系统通常按下面方式运行Cortex-M CPU 负责传感器采集 负责滤波和特征处理 负责系统控制与通信 负责模型中 NPU 不支持的算子 Ethos-U microNPU 负责支持的卷积、矩阵乘法等神经网络子图因此NPU 并不是把 CPU 完全替换掉而是形成异构计算系统通用控制和信号处理 → CPU 重复密集的神经网络运算 → NPU这也是 M55 与 U55 配合的意义M55 擅长通用程序、DSP 和向量计算U55 专门加速神经网络。6.3 Ethos-U55 的可配置性Ethos-U55 可以按照不同硬件面积、功耗和性能目标配置为不同规模。课程介绍的配置范围为每周期 32、64、128 或 256 次 Multiply-Accumulate乘加运算。配置越大峰值计算能力越高芯片面积通常越大功耗可能更高对存储和总线的要求也更高。因此NPU 并不是越大越好而要与实际模型和功耗目标匹配。6.4 权重压缩为什么有价值Ethos-U 支持压缩模型权重。压缩不仅能减小模型存储空间还能减少从 Flash 或其他存储器读取数据的次数。这会同时改善模型大小存储带宽数据搬运能耗部分推理延迟。在嵌入式系统中移动数据有时比执行一次乘法更耗能因此降低数据搬运往往与提高计算能力同样重要。7. Ethos-U65从 MCU 级系统扩展到更大边缘平台Ethos-U65 延续了 Ethos-U55 的架构思路但支持更高性能、更多系统配置并可应用于 Cortex-A、Cortex-R 和 Neoverse 等平台。它也支持带有 DRAM 的系统而不仅限于 MCU 常见的片上 SRAM 和 Flash 架构。Arm 当前资料显示U65 可提供约为 U55 两倍的端侧 ML 性能并支持 Cortex-M 裸机 / RTOS 系统以及 Cortex-A 富操作系统系统。(Arm)两者可以简单理解为对比项Ethos-U55Ethos-U65主要定位面积和功耗受限的 MCU / IoT 系统更高性能边缘与端点系统常见配合Cortex-MCortex-M、Cortex-A、Cortex-R 等存储环境片上 SRAM、Flash 为主可扩展至带 DRAM 的系统最大配置课程中介绍到 256 MAC/cycle可扩展到 512 MAC/cycle适合任务关键词识别、轻量视觉、嵌入式分类更复杂语音、视觉和边缘任务需要注意U55 和 U65 是芯片厂商可集成到 SoC 中的处理器 IP并不是购买任意 Cortex-M 开发板就自动拥有这些 NPU。8. Vela连接神经网络模型与 Ethos-U 的桥梁8.1 只有硬件没有编译器也不够神经网络模型由许多算子组成例如Conv2D Depthwise Conv2D Fully Connected Pooling Reshape Softmax LSTMNPU 不一定支持模型中的所有算子而且不同算子还可能受到尺寸、数据类型和参数配置限制。因此需要编译器完成分析模型计算图判断哪些算子可以在 NPU 上运行把这些算子组成可加速子图生成 NPU 命令序列压缩和重新组织权重保留无法加速的 CPU 算子。Vela 就承担这一工作。8.2 Vela 的模型部署流程课程中的流程可以整理为在电脑上训练神经网络 ↓ 转换并量化为 TensorFlow Lite 模型 ↓ 使用 Vela 离线编译器分析模型 ↓ 将支持的网络子图编译为 Ethos-U 命令 ↓ 生成新的优化版 TensorFlow Lite 模型 ↓ 部署到 Cortex-M Ethos-U 系统Arm 官方文档说明Vela 会将 LiteRT / TensorFlow Lite 模型编译为适合 Ethos-U 运行的优化版本。它会识别 NPU 支持的子图无法映射到 NPU 的部分仍保留由 CPU 上的相应内核执行。(Arm开发者)8.3 CPU fallback 是什么假设模型结构如下Conv2D → ReLU → 某个 NPU 不支持的特殊算子 → Fully ConnectedVela 可能把支持的部分交给 Ethos-UConv2D ReLU → NPU特殊算子则退回 CPU特殊算子 → Cortex-M这就是CPU fallbackCPU 回退执行。CPU 回退并不意味着整个模型不能运行但如果回退算子很多CPU 与 NPU 之间需要频繁交换中间数据就可能降低整体性能。因此在设计模型时不能只问模型准确率高不高还要问这个模型的算子能否被目标 NPU 高效支持8.4 CMSIS-NN 的作用对于运行在 Cortex-M CPU 上的网络部分可以调用 CMSIS-NN 优化内核。CMSIS-NN 针对不同 Cortex-M 能力提供不同实现包括无 SIMD 的 Cortex-M带 DSP 扩展的 Cortex-M4 等处理器带 MVE / Helium 的 Cortex-M55。它包含卷积、全连接、池化、激活、Softmax 和 LSTM 等优化函数并遵循 TFLM 的 int8 / int16 量化规范。(arm-software.github.io)完整的软件与硬件关系可以概括为模型 ↓ Vela 分析和划分计算图 ↓ 支持的算子 → Ethos-U 不支持的算子 → Cortex-M CMSIS-NN9. 为什么“神经网络快了”不代表整个应用快了课程给出了两个不同层次的性能示例。9.1 只测试神经网络在课程中的语音识别网络示例里M4 使用 CMSIS-NN相比未优化参考内核获得明显加速使用带 Helium 的 Cortex-M55 后继续提升再加入 Ethos-U55 后神经网络本身获得更大幅度的加速。该示例用于展示从参考内核、优化软件、向量 CPU 到专用 NPU 的逐层性能提升但结果只适用于课程中的特定模型、平台和配置不能直接当作所有项目的固定倍数。9.2 测试完整语音助手完整语音助手除了神经网络还包括波束形成回声消除降噪音频均衡MFCC编解码关键词检测语音识别。课程中的完整应用示例显示M55 与 U55 的组合不仅缩短推理时间还显著降低能耗但整体加速倍数低于“只测试神经网络”时的理论提升因为应用中仍有大量非神经网络工作。这说明评价 AI 硬件时应测量端到端延迟 而不只是单个神经网络延迟整个应用每次处理的能耗 而不只是 NPU 峰值 TOPS10. 如何判断一块板是否真正具备 AI 加速能力可以从下面五个问题判断。检查问题应关注的内容芯片是否有 ML 专用架构向量扩展、点积指令、NPU、DSP 或其他加速单元是否有配套优化库CMSIS-NN、CMSIS-DSP、厂商 NN / DSP 库是否有模型编译工具Vela、模型转换器、量化器、算子分析工具支持哪些模型和数据格式int8 / int16、CNN、RNN、具体算子列表是否有真实性能数据延迟、RAM、Flash、能耗、CPU 回退比例购买开发板前还应区分以下宣传宣传说法实际含义“AI 开发板”可能只是适合学习和采集数据“支持 TinyML”通常说明能够运行小型模型“AI-capable CPU”CPU 有利于 ML / DSP 的指令或架构“内置 NPU”通常表示有专用神经网络加速单元“X TOPS”只是峰值指标不能单独代表真实应用速度11. 本章硬件选型地图根据课程内容可以得到下面的粗略选择思路任务复杂度典型任务可考虑的平台较低统计特征分类、简单异常检测、低维传感器Cortex-M4 / M33 / M7普通 ESP32、STM32、Nordic中等多通道时序、小型 1D CNN、关键词检测Cortex-M55、带高效 DSP / ML 指令的 MCU较高高级语音、轻量视觉、较复杂 CNN / RNNCortex-M55 Ethos-U55更高完整语音识别、更复杂视觉、DRAM 模型更高性能系统 Ethos-U65 等 NPU这只是架构层面的指导。最终选择仍应以具体模型的准确率推理延迟RAMFlash能耗运算符支持成本为依据。12. 与生理信号 TinyML 项目的联系本章对生理信号项目最重要的启发不是再次重复“采集—训练—部署”的流程而是明确生理信号设备是否需要 AI 加速器应由实际计算负载决定而不是由项目名称决定。12.1 不同生理信号对硬件的需求并不相同信号常见计算特点一般硬件需求NPU 的潜在价值GSR / EDA低采样率、慢变化、统计与峰值特征较多普通 MCU 通常足够简单分类时价值有限复杂多模态网络时才明显HRV主要是心搏检测后的窗口统计特征普通 MCU 通常足够传统特征模型通常不需要 NPUPPG滤波、峰值检测、运动伪迹处理M4 / M33 / ESP32 / STM32 可完成使用原始波形 CNN 或多通道模型时可能有帮助ECG较高采样率、QRS 检测、波形分类中等性能 MCU1D CNN、长窗口或多导联模型可能受益EMG采样率较高常含多通道和频域处理DSP 性能较重要多通道 CNN、手势识别网络可能明显受益EEG多通道、高数据量、频谱和时空特征复杂RAM、DSP 和算力要求较高深度网络、睡眠分期或多通道模型更可能需要 NPU多模态融合多种传感器同步、特征融合内存和算力需求最高NPU 对复杂融合网络更有价值这是基于各信号典型数据规模和算法特点做出的工程判断具体是否需要 NPU仍需使用真实模型测试。12.2 GSR / EDA 项目未必需要 NPU以 GSR / EDA 疼痛相关状态识别为例如果模型输入是均值标准差斜率SCR 次数上升时间恢复时间再使用 Random Forest、小型 SVM 或小型 MLP普通 ESP32-S3、STM32 或 Nordic MCU 通常就可能满足实时要求。这时盲目使用 NPU可能带来工程复杂度增加开发板成本增加算子适配工作增加实际收益很小。因此对 GSR / EDA 项目更重要的往往是采集电路质量 标签可靠性 被试者差异 滤波和特征设计 模型泛化能力而不是先购买更强的 AI 加速器。12.3 EEG、EMG 和多模态模型更可能受益如果项目发展到多通道 EEG EMG PPG EDA IMU并使用多分支 CNN、时序网络或较复杂特征融合模型那么RAM 峰值会增加中间张量会增大推理延迟会上升CPU 占用会变高。这时 Cortex-M55 的 Helium 或 Ethos-U 类 NPU可能带来实际价值。但仍需要确认网络是否已完成 int8 / int16 量化关键算子是否被 NPU 支持Vela 编译后 CPU fallback 是否过多前处理是否反而成为主要瓶颈RAM 和 Flash 是否足够节省的能耗是否值得增加硬件成本。12.4 生理信号系统中的理想分工对于复杂的多通道生理信号设备可以采用MCU / CPU ADC 与数字传感器采集 滤波和重采样 通信和任务调度 安全控制 部分特征提取 NPU 运行支持的 CNN / RNN / MLP 子图 确定性程序 检查模型置信度 限制输出范围 处理传感器断线 执行安全策略其中最值得注意的是NPU 只负责提高神经网络计算效率并不会自动改善数据质量、标签可靠性、模型公平性或医疗安全性。13. 关键概念解释概念通俗解释技术解释本章中的作用AI-capable CPU更适合运行 AI 的通用处理器包含向量、DSP 或 ML 相关指令的 CPU解释 Cortex-M55 的定位Hardware Accelerator专门替某类计算加速的硬件针对特定操作设计的数据通路和计算单元区分普通 MCU 与真正加速器Helium / MVECortex-M 的向量计算能力Armv8.1-M 的 M-Profile Vector Extension提高 DSP 和 ML 效率SIMD一条指令处理多个数据Single Instruction, Multiple Data支持滤波、点积和矩阵计算MAC乘法并累加Multiply-Accumulate神经网络和 DSP 的基础运算microNPU给小型设备使用的 NPU面向低功耗嵌入式设备的神经网络加速器Ethos-U55 / U65 的定位Vela模型与 Ethos-U 之间的编译桥梁将 TFLite 模型优化为 Ethos-U 可执行形式决定哪些算子由 NPU 执行CPU fallbackNPU 不支持时交给 CPU未被编译进 NPU 子图的算子由 CPU 运行影响真实端到端性能CMSIS-NNCortex-M 神经网络优化库面向量化网络的高效计算内核加速 CPU 侧模型运算Memory bandwidth数据供给速度存储器与处理器之间的传输能力解释为什么算力高不等于应用快Hardware–software co-design硬件和模型共同设计联合优化架构、网络、量化、内存和工具链本章最核心的方法论14. 本章案例复盘完整语音助手为何需要 CPU NPU环节更适合的计算单元原因麦克风采样CPU / 外设需要实时控制 DMA、I²S 等接口波束形成CPU DSP / Helium属于典型数字信号处理回声消除和降噪CPU DSP / Helium算法控制和向量计算并存MFCC 特征提取CPU DSP / Helium包含 FFT、滤波器组和对数运算神经网络Ethos-U NPU卷积和矩阵运算密集结果判断CPU需要阈值、状态机和业务逻辑设备控制CPU需要确定性控制外设这个案例表明一个真正高效的 TinyML 系统通常不是“所有任务都放进 NPU”而是让每种计算运行在最合适的硬件上。15. 本章还不能解决的问题本章解释了 AI 硬件加速路线但还不能直接回答某个具体模型在目标芯片上的 RAM 峰值是多少。Edge Impulse 导出的模型能否完整映射到 Ethos-U。某个算子为什么会发生 CPU fallback。如何为特定芯片编写 Vela 配置文件。如何实测每次推理的能耗。如何测量前处理、模型和后处理各自的耗时。如何设计包含 Cortex-M 和 NPU 的具体 SoC。多通道 EEG / EMG 网络需要多大的 SRAM。模型精度与计算量之间的最佳平衡点在哪里。使用 NPU 后是否能够满足具体医疗或工业安全标准。这些问题需要在后续章节中结合真实模型、目标开发板和性能分析工具进一步验证。16. 本章总结本章最突出的收获是学会识别“能运行 AI”和“具备 AI 加速器”之间的区别。传感器只负责提供数据普通 Cortex-M 可以依靠软件运行小型模型Cortex-M55 通过 Helium 向量扩展提高 DSP 与机器学习效率而 Ethos-U55 / U65 则使用专用 microNPU 加速神经网络。Vela 编译器负责把可支持的模型子图交给 NPUCMSIS-NN 则优化 CPU 侧计算。真正的 TinyML 性能来自模型、CPU、NPU、内存和工具链的协同而不是开发板包装上的“AI”字样。对于生理信号项目也不应先问“哪块 AI 板最强”而应先测量任务的采样率、模型结构、RAM、延迟和能耗再判断普通 MCU、向量 CPU 或专用 NPU 哪一种最合适。17. 参考资料资料名称类型链接与本章内容的关系Arm Cortex-M55官方文档Arm Cortex-M55说明 Helium、ML / DSP 性能、TrustZone 和 M55 的定位。(Arm)Arm Ethos-U55官方文档Arm Ethos-U55说明 U55 是面向受限嵌入式系统的 microNPU。(Arm)Arm Ethos-U65官方文档Arm Ethos-U65说明 U65 的性能、DRAM 支持和 Cortex-A / M 扩展能力。(Arm)Arm tinyML Applications官方资料Arm tinyML Resources用于说明 Vibration、Voice、Vision 三类 TinyML 任务。(Arm)CMSIS-NN Software Library官方文档CMSIS-NN Documentation说明 Cortex-M 上的卷积、全连接、池化和量化优化内核。(arm-software.github.io)Ethos-U Vela Compiler官方文档Vela Compiler Documentation说明如何把 LiteRT / TFLite 模型编译为 Ethos-U 优化模型。(Arm开发者)Arm Ethos-U Vela官方开源项目Vela GitLab Repository提供 Vela 源代码和模型优化工具LiteRT for MicrocontrollersGoogle 官方文档LiteRT for Microcontrollers说明量化神经网络在 MCU 上的基本推理运行时TinyML for Ubiquitous Edge AI综述论文arXiv:2102.01255解释 TinyML 的低功耗定义及硬件—软件协同背景。(arXiv)Measuring What Really Matters: Optimizing Neural Networks for TinyML学术论文arXiv:2104.10645强调应结合真实硬件测量延迟、能耗和实现效果而不能只看理论运算量。(arXiv)