maximum timeflow轻量平台跑分结果：使用stm与ws63芯片实体硬件测试结果

一、测试基本信息

二. STM平台测试的模型来源

数据来源：生成过程说明_从maximum_timeflow到ONNX.md

三、模型原始数据来源（“原料”）

模型权重与输入全部来自仓库源码，未使用任何外部模型。

3.1 权重数据

来源文件：platform/liteos_m/float_weights_output.c

权重数组（const float NAME[] = {...} 形式）：

• 权重合计：4624 个 float = 18496 B（FP32）
• 另记录输入向量 g_serving_default_dense_input_0（128 个 float）

3.2 层语义规格

来源文件：tools/check_real_model.py

• 权重按 [in][out] 行主序存储
• 前向计算：out = in @ W + b
• 三层规格：
    - 第一层：128 → 32，ReLU 激活
    - 第二层：32 → 16，ReLU 激活
    - 第三层：16 → 1，末层无激活

3.3 黄金校验常量

来源文件：tests/golden/liteos_m_real_model.h

由 tools/gen_liteos_golden.py 用 numpy 独立算出。

3.4 重要取舍说明

（1）弃用坏记录值

float_weights_output.c 中的记录输出数组 g_StatefulPartitionedCall_0 值为 4631576035757424490934435840.0（4.6e27）。tools/check_real_model.py 已明确指出这是 INT8→float32 反量化脚本的产物，不可作为黄金数据。因此导出脚本的校验基准改用上述 golden 头文件的 logit/sigmoid 常量对。

（2）补 Sigmoid 末层

仓库 LiteOS-M 核心在末层 dense 之后施加 sigmoid epilogue（golden 对中的 sigmoid 项即设备上报的异常概率）。原始记录只到 logit。为了让平台基准测试"完整训练模型"而非裸 logit 头，导出图在最后加 Sigmoid 节点；同时保留一个 Identity 节点把裸 logit 暴露为命名张量，供校验用。

四、FP32 ONNX 模型生成过程

4.1 脚本信息

• 脚本位置：tools/export_onnx_mlp.py（本次会话新增，已同步进 WSL 工作副本）

4.2 生成流程

1. 解析：正则 (?:static\s+|extern\s+)?const\s+float\s+(\w+)\s*$$\s*$$\s*=\s*\{(.*?)\}\s*; 提取全部 float 数组，去掉 C 的 f/F 后缀转 float32。
2. 建图：按层规格依次 MatMul → Add →（前两层）Relu；末层 MatMul → Add → Identity(logit) → Sigmoid(output)。权重以 initializer 注入，形状 [in][out]。
3. 双图策略：
      - 校验图：声明 output 与 logit 两个输出，便于同时核对黄金 logit 与 sigmoid
      - 交付图：只声明 output 一个输出（平台只消费单一声明输出）
      - 两图节点相同，仅输出声明不同
4. 校验门槛（不达标即退出码 1、不写文件）：
      - onnx.checker.check_model 通过
      - onnxruntime 前向：logit 与 GOLDEN_LOGIT 误差 < 1e-6，且 sigmoid 与 GOLDEN_SIGMOID 误差 < 1e-6
5. 保存：onnx.save 交付图，opset 13，ir_version 8

4.3 校验结果

校验结论：VERIFY: PASS，写出 19202 字节

4.4 执行命令

python3 tools/export_onnx_mlp.py "/mnt/c/.../st平台导入项目/real_model_mlp_128_32_16_1_fp32.onnx"

4.5 交付图结构（onnx.checker 复核）

五、INT8 ONNX 模型生成过程（静态量化 QDQ）

5.1 脚本信息

• 脚本位置：_bench/s7_quant.py（未入库）

5.2 校准数据

共 64 个样本，input 形状 [1,128]：

5.3 量化参数

quantize_static(
    model_input  = FP32 onnx,
    model_output = INT8 onnx,
    calibration_data_reader = Reader(),
    quant_format = QuantFormat.QDQ,
    per_channel  = True,
    weight_type  = QuantType.QInt8,
)

5.4 量化校验结果

校验结论：VERIFY: PASS

5.5 体积对比

5.6 交付图结构

5.7 选择 QDQ INT8 的原因

• 平台 Model Zoo 原生提供大量 *_qdq_int8.onnx 模型，证明该格式是平台一等公民
• 整数权重与整数 MAC 在 Cortex-M（CMSIS-NN）上是快路径
• Flash 占用更小

5.8 执行命令

python3 <量化脚本> <FP32 路径> <输出路径>/real_model_mlp_128_32_16_1_int8.onnx

数据来源：生成过程说明_从maximum_timeflow到ONNX.md

六、ST Edge AI Developer Cloud 基准测试结果

以下三组基准测试数据均在 STM 芯片官方（意法半导体）的 ST Edge AI Developer Cloud 网站上通过连接远程的真实实体硬件开发板测试跑分的。

6.1 第一次基准测试（FP32 模型）

数据来源：2026-09-22T12_12_53.985Z-benchmark-results.csv

模型 SHA256：3840f9dfcf3991f9828ae6d80f67c9aef3f653478df1e69493b1a8d02f9a586f

模型 MD5：94b3315a891f159c2ad9d33adffc9ce1

优化策略：balanced

第一次基准测试关键发现

• 推理最快：STM32H735G-DK（17,314 cycles / 0.031480 ms）
• 推理最慢：STM32H7S78-DK（68,071 cycles / 0.113453 ms），且该板使用了外部 Flash（useExternalFlash=true），内部 Flash 仅 12,788 B
• STM32H573I-DK 的 Flash 占用最大（19,756 B），内核 Flash 为 14,884 B，高于其他板子的 12,788 B
• 所有板子 RAM 占用统一为 2,560 B，权重均为 4,872 B，激活值均为 736 B
• 所有测试均未使用外部 RAM（useExternalRam=false）

6.2 第二次基准测试（FP32 模型，重复验证）

数据来源：2026-09-22T12_22_15.513Z-benchmark-results.csv

模型 SHA256：3840f9dfcf3991f9828ae6d80f67c9aef3f653478df1e69493b1a8d02f9a586f（与第一次相同）

模型 MD5：94b3315a891f159c2ad9d33adffc9ce1（与第一次相同）

优化策略：balanced

第二次基准测试说明

本次测试结果与第一次完全一致（相同的 SHA256/MD5、相同的 benchmarkId、相同的 cycles 和 duration_ms），属于对同一模型的重复提交验证，确认了结果的可复现性。

6.3 第三次基准测试（INT8 QDQ 量化模型）

数据来源：2026-09-22T12_43_34.929Z-benchmark-results.csv

模型 SHA256：9836e730455a300711142e6a67d1bf076b1ffb07f3b072180dbbd209ad276c6e（与 FP32 不同）

模型 MD5：0ea0678903c8b3a999b18215bb72d271（与 FP32 不同）

优化策略：balanced

第三次基准测试关键发现

• 推理最快：STM32H735G-DK（29,065 cycles / 0.052847 ms）
• 推理最慢：STM32H7S78-DK（45,806 cycles / 0.076343 ms），同样使用了外部 Flash
• STM32H573I-DK 的总 Flash 占用为 21,408 B（高于其他板的 21,320 B），内核 Flash 为 2,716 B（高于其他板的 2,628 B）
• RAM 占用大幅降低：所有板子 RAM 统一降至 640 B（FP32 为 2,560 B），降幅 75%
• 权重占用增大：INT8 模型在平台上的权重为 18,692 B（含 QDQ 节点的 scale/zero_point 等开销），大于 FP32 的 4,872 B
• 激活值略降：从 736 B 降至 640 B
• 所有测试均未使用外部 RAM

七、FP32 与 INT8 模型基准测试对比

7.1 推理性能对比（按开发板）

注：FP32 数据取自第一次基准测试（2026-09-22T12_12_53.985Z-benchmark-results.csv），INT8 数据取自第三次基准测试（2026-09-22T12_43_34.929Z-benchmark-results.csv）

对比分析

• 大多数开发板上，INT8 模型的推理周期数和耗时反而高于 FP32 模型（增幅约 57%~68%）。这可能因为：
    - QDQ 模型在平台上引入了额外的 QuantizeLinear/DequantizeLinear 节点开销
    - 该 MLP 模型规模较小（仅 3 层），量化带来的计算量节省不足以抵消 QDQ 节点开销
• 唯一例外：STM32H7S78-DK 上 INT8 模型耗时降低了 32.7%（从 0.113 ms 降至 0.076 ms），可能因为该板上 FP32 模型使用了外部 Flash（useExternalFlash=true），而 INT8 虽然也使用了外部 Flash，但内部 Flash 占用从 12,788 B 降至 2,628 B，大幅减少了外部 Flash 读取延迟

7.2 资源占用对比（以典型板为例，排除 H7S78-DK 和 H573I-DK 特殊情况）

资源分析

• RAM 大幅降低是 INT8 量化最显著的优势（2,560 → 640 B），对 RAM 极为紧张的 Cortex-M 场景意义重大
• Flash 总量增大是因为 QDQ 格式引入了大量 scale/zero_point 参数（initializer 从 6 个增至 36 个）
• 内核 Flash 大幅降低（12,788 → 2,628 B），说明量化后实际计算内核更精简
• 权重在平台上的表现增大，可能因为平台对 QDQ 节点的权重管理方式不同于纯 INT8 权重

八、开发板性能排名

8.1 FP32 模型推理速度排名

数据取自 2026-09-22T12_12_53.985Z-benchmark-results.csv

8.2 INT8 模型推理速度排名

数据取自 2026-09-22T12_43_34.929Z-benchmark-results.csv

九、环境准备中遇到的问题记录

数据来源：生成过程说明_从maximum_timeflow到ONNX.md

十、复现命令汇总与真实性声明

# 0) 环境准备
sudo apt install python3-pip && python3 -m pip install --user onnx onnxruntime numpy

# 1) 生成 FP32 ONNX
cd <maximum_timeflow 仓库>
python3 tools/export_onnx_mlp.py <输出路径>/real_model_mlp_128_32_16_1_fp32.onnx

# 2) 生成 INT8 ONNX（QDQ 量化）
python3 <量化脚本> <FP32 路径> <输出路径>/real_model_mlp_128_32_16_1_int8.onnx

# 3) 结构复核
python3 -c "import onnx; m=onnx.load('<文件>'); onnx.checker.check_model(m); print([n.op_type for n in m.graph.node])"

• 全部数字（误差、大小、节点清单、基准测试结果）均为实测输出，未估算未外推
• INT8 的精度损失（绝对 2.147e-3）与文件级 2.00× / 纯权重 4.00× 两种体积口径均如实标注
• 模型来源仅为仓库源码权重，未引入任何第三方预训练模型
• 所有基准测试数据均来源于 ST Edge AI Developer Cloud 平台的实际测试输出

十一、OpenHarmony(liteos-m)平台使用实体ws63开发板的跑分

WS63 芯片的硬件能力不如 STM 系列板子的芯片能力，因此测试内容做了相应简化——只做了这款芯片力所能及的事情。具体而言：

• WS63 板子上运行的是 FP32 精度的模型推理（未进行 INT8 量化测试）；
• 测试程序为仓库中的 htf_bench_constrained，专为资源受限目标设备设计；
• 模型权重以编译时常量形式嵌入固件（built-in weights, no file I/O），不依赖外部存储读取；
• 测试在设备端直接完成计时与数值校验，不依赖宿主机参与。

数据来源：WS63_device_benchmark_report.html、WS63_Device_Benchmark-JSON_artifact.json、WS63_Device_Benchmark-Raw_UART_Log.log

测试环境：

软件环境：

数据来源：WS63_Device_Benchmark-JSON_artifact.json（JSON artifact 中的 env 字段）

时钟频率测量：

WS63 板子的时钟频率不是从数据手册假设的，而是在启动时实际测量得到：

数据来源：WS63_device_benchmark_report.html（Portable facts 表格中 “measured clock rate” 行）、WS63_Device_Benchmark-JSON_artifact.json（clock_rate 条目）

模型规格：

WS63 板上运行的模型与 ST 平台测试使用的是同一个 MLP 模型（3 层全连接网络），模型规格如下：

网络结构：

• 输入维度：128
• 输出维度：1
• 层数：3

内存与储存占用

数据来源：WS63_device_benchmark_report.html（Portable facts 表格）、WS63_Device_Benchmark-JSON_artifact.json（entries 中 kind=metric 的条目）

模型精度声明

WS63 测试中使用的模型为 FP32 精度，INT8 量化模型未在 WS63 板上测试：

数据来源：WS63_device_benchmark_report.html（Provenance 表格中 FP32 model / INT8 model 行）、WS63_Device_Benchmark-JSON_artifact.json（model_fp32 / model_int8 字段均为 null）

数值正确性验证

在 WS63 板子上运行推理后，benchmark 程序自动将设备计算结果与宿主机上 numpy 计算的黄金值进行比对：

数值误差（2.98e-08）远小于容忍阈值（0.001），说明 WS63 板上的 FP32 推理结果与宿主机计算结果高度一致。

数据来源：WS63_device_benchmark_report.html（Numerical correctness 表格）、WS63_Device_Benchmark-JSON_artifact.json（metric 条目中 anomaly probability 和 softmax-constant regression）

推理性能测试结果

完成前向传播计时

在 WS63 板上对 300 次推理进行逐次计时，统计结果如下：

注：最小耗时为 0 ns 表明部分推理在单个时钟tick 内完成（计时分辨率限制），实际耗时被量化为 0。p50/p95/max 均为 1.00 ms，说明在 1 ms 的系统 tick 分辨率下，大部分推理耗时落在 1 个 tick 区间内。

性能图表描述

Benchmark 报告生成了横向柱状图，展示"Constrained target: inference timing (THIS machine)“，单位为 μs/call。柱状图显示 full forward pass [128→1, 3 layers] 的平均耗时为 533.33 μs，颜色标记为"measured on target”（绿色），表示该数据为设备端实测值。

数据来源：WS63_device_benchmark_report.html（Timing section 中的表格和 SVG 图表）、WS63_Device_Benchmark-JSON_artifact.json（entries 中 kind=timing 的条目）

推导指标

数据来源：WS63_device_benchmark_report.html（Comparisons and derived figures 表格）、WS63_Device_Benchmark-JSON_artifact.json（per-inference latency 条目）

UART通信接口

WS63 开发板通过 UART 串口与宿主机通信，使用 AT 指令集触发 benchmark 运行。原始串口日志如下：

AT+HTFBENCH
[HTF AI] native engine ready: 3 layers, in=128 out=1, buffer=128 floats
[HTF AI] native engine ready: 3 layers, in=128 out=1, buffer=128 floats
=====HTF_BENCH_JSON_BEGIN=====
{ ... JSON artifact ... }
=====HTF_BENCH_JSON_END=====
OK

通信流程说明：

1. 宿主机通过串口发送 AT+HTFBENCH 指令启动 benchmark；
2. WS63 板子初始化 native engine，打印两条就绪日志（引擎启动两次，可能为日志重复打印）；
3. 板子执行推理测试，将 JSON 格式的 benchmark 结果通过串口输出，用 =====HTF_BENCH_JSON_BEGIN===== 和 =====HTF_BENCH_JSON_END===== 标记包裹；
4. 测试完成后返回 OK 表示执行完毕。

数据来源：WS63_Device_Benchmark-Raw_UART_Log.log

结果判定

Benchmark 程序内置了自动验证机制，对所有测试用例进行正确性校验：

报告顶部的总体验证结论为：“All runs validated their own results.”（所有运行均通过了自身结果验证。）

数据来源：WS63_device_benchmark_report.html（顶部 verdict 区块）、WS63_Device_Benchmark-JSON_artifact.json（Run verdict 条目）

附录：原始 Benchmark ID 索引

FP32 模型（第一次/第二次测试共用）

数据来源：2026-09-22T12_12_53.985Z-benchmark-results.csv / 2026-09-22T12_22_15.513Z-benchmark-results.csv

INT8 模型（第三次测试）

数据来源：2026-09-22T12_43_34.929Z-benchmark-results.csv

注：截图与机器输出的文档不会放在此文档里，请移步相关文件夹查看。