人工智能深度学习推理引擎本地部署嵌入式物联网【免费下载链接】tflite-microInfrastructure to enable deployment of ML models to low-power resource-constrained embedded targets (including microcontrollers and digital signal processors).项目地址https://gitcode.com/gh_mirrors/tf/tflite-micro点击查看免费下载tflite-micro 的data/continuous_builds目录沉淀着一套由持续构建Continuous Build工作流自动生成的监控产物其核心是若干记录二进制体积的 CSV 时序数据与配套的趋势图。本文以 data/continuous_builds/README.md 为骨架结合仓库内真实产物与tensorflow/lite/micro/tools/metrics/下的生成脚本系统讲解这套体积监控体系的产物格式、生成管线、三个被监控二进制的测量语义、阈值回归检测机制以及如何在本地完整复现这套流程帮助你掌握用尺寸数据度量并发现性能波动的完整实战方案。目录结构一次 CI 构建沉淀下来的监控产物依据 data/continuous_builds/README.md该目录包含持续构建工作流自动生成的产物artifacts意图是监控这些产物例如体积数据以度量并发现任何性能波动长期目标则是基于这些产物通过某种 Dashboard 持续监控这些性能数据点。当前仓库中实际的产物布局如下data/continuous_builds/ ├── README.md └── size_profiling/ └── linux_x86_64_release/ # 目标平台 架构 构建类型 ├── baseline_memory_footprint.csv ├── baseline_memory_footprint.png ├── interpreter_memory_footprint.csv ├── interpreter_memory_footprint.png ├── keyword_benchmark.csv └── keyword_benchmark.png目录命名linux_x86_64_release由TARGETlinux、TARGET_ARCHx86_64与BUILD_TYPErelease三部分拼接而成即每个目标平台/构建配置各占一个子目录。目录内每个被监控的二进制对应一对文件.csv是可追加的时序体积记录.png是脚本自动绘制的历史趋势图另外两个图见 baseline_memory_footprint.png 与 interpreter_memory_footprint.png。这套 CI 的整体机制分层测试、审批门、Merge Queue 等可参见 docs/continuous_integration.md。CSV 数据格式把二进制体积变成可追溯的时间序列每个.csv文件都是一张扁平时序表表头固定为字段含义date采样时间戳YYYY-MM-DD HH:MM:SS.ffffff来自datetime.datetime.now()sha构建时仓库 HEAD 的 40 位 Git commit SHAtextELF 可执行文件中 text 段代码段体积单位字节datadata 段已初始化数据体积单位字节bssbss 段未初始化数据体积单位字节total三者之和即体积总量单位字节字段定义可在 create_size_log.py 中直接看到脚本先按这六列创建或复用CSV再把size命令输出的text、data、bss与dec四列逐一追加为一行其中dec列被映射为total。以baseline_memory_footprint.csv为例仓库内首行与末行的真实数据为date,sha,text,data,bss,total 2022-01-10 23:04:44.309131,c53927869b2ce15345c6c1751164ca6e4aa47c02,1394,520,8,1922 ... 2022-07-14 13:15:35.665349,0e825b99b34596907f53e1fa245028576414cfd0,1433,568,8,2009可以看到total恒等于text data bss如139452081922。这份数据从 2022-01-10 持续采样到 2022-07-14接近半年、整体高频多数日期 1~2 条的累积记录并保留了每次采样对应的 commit SHA使任何一次体积变化都能回溯到具体提交——这正是可监控、可检测、可追溯的数据基础。生成管线脚本如何从编译走到检测体积产物的生成与检测由tensorflow/lite/micro/tools/metrics/下三个脚本接力完成全程可在本地复现。入口脚本create_size_log_x86.shcreate_size_log_x86.sh 是面向 x86-64 Linux release 构建的入口流程如下清理本地构建与第三方依赖下载缓存make -f tensorflow/lite/micro/tools/make/Makefile clean clean_downloads下载第三方依赖make -f tensorflow/lite/micro/tools/make/Makefile third_party_downloads指定三个被监控的二进制见第 35 行BINARY_LISTkeyword_benchmark,baseline_memory_footprint,interpreter_memory_footprint python3 tensorflow/lite/micro/tools/metrics/create_size_log.py --build_typerelease --targetlinux --target_archx86_64 --binary_list${BINARY_LIST}对产物目录执行阈值检测与绘图第 47-48 行LOG_DIR${ROOT_DIR}/data/continuous_builds/size_profiling/${TARGET}_${TARGET_ARCH}_${BUILD_TYPE} python3 tensorflow/lite/micro/tools/metrics/detect_size_increase_and_plot_history.py --input_dir${LOG_DIR} --output_dir${LOG_DIR} --binary_list${BINARY_LIST}若脚本检测到体积增长超阈值则退出码非 0脚本打印Size increase may exceed threshold并exit -1从而让 CI 任务失败、触发人工介入否则输出Size does not increase or size increase does not exceed threshold。构建与采样create_size_log.pycreate_size_log.py 的_build_and_profile对每个二进制依次执行构建 → 测量 → 追加记录构建_build_a_binary调用make -f tensorflow/lite/micro/tools/make/Makefile binary_name BUILD_TYPE... TARGET... TARGET_ARCH...测量_profile_a_binary对gen/target_dir/bin/binary_name执行 GNU binutils 的size命令源码第 51、61 行把输出按空白切分为 DataFrame再以build_info当前时间 git rev-parse HEAD得到的 SHA补全date与sha后追加写回 CSVreport.to_csv(csv_path, indexFalse, headerFalse, modea)。脚本支持的参数与默认值如下均可覆盖参数默认值说明--binary_listkeyword_benchmark,baseline_memory_footprint,interpreter_memory_footprint逗号分隔的二进制列表--build_typerelease构建类型--targetlinux主机目标平台--target_archx86_64目标架构脚本依赖 Python 3 与pandas源码第 20 行import pandas as pd。阈值检测与绘图detect_size_increase_and_plot_history.pydetect_size_increase_and_plot_history.py 承担回归检测 可视化双重职责两个关键常量定义在第 22-27 行# 仅回溯最近 60 天的体积历史 SIZE_HISTORY_DEPTH 60 # text 与 total 段单次增量超过该阈值字节即判定失败 SIZE_THRESHOLD_SETTING { text: 512, total: 512, }检测逻辑为读取 CSV 最后 60 行用size_log[section_name].diff()求最近一次增量若text或total的最近增量超过 512 字节则收集一条失败消息所有二进制的消息汇总后抛出RuntimeError脚本退出非 0。也就是说这套机制检测的是最近一次提交导致的体积突增是否越过阈值而不是绝对体积上限。绘图部分第 39-56 行为每个二进制生成一张 3×2 的子图三行分别对应text、data、total左列为绝对体积纵轴Abs Sz(bytes)折线o-右列为逐次增量纵轴Incr Sz (bytes)并以Source: binary_name与采样起止日期作为总标题保存为binary_name.png。本仓库linux_x86_64_release/目录下的三张 PNG 正是该脚本的输出依赖matplotlib。三个被监控的二进制测量方法论为什么偏偏监控这三个二进制它们的语义与测量方法论在 tensorflow/lite/micro/examples/memory_footprint/README.md 中有完整说明核心思路是用减法把 TFLite Micro 的体积开销拆解开。baseline_memory_footprint无操作基线构建 memory_footprint 下的baseline_memory_footprint目标构建规则见 Makefile.inc得到的是一个无操作应用no-op application通常只包含平台相关的初始化代码。它被视为与 TFLM 无关的固定开销基线。interpreter_memory_footprintTFLM 框架同目录下的interpreter_memory_footprint源码 interpreter_memory_footprint.cc会拉入创建解释器实例所需的全部 TFLM 框架代码解释器、内存规划器等但刻意不注册任何内核因此该二进制无法真正执行推理。两个体积之差即为 TFLM 框架Framework的代码量估算interpreter_memory_footprint − baseline_memory_footprint。keyword_benchmark完整应用与内核开销keyword_benchmark.cc构建规则见 Makefile.inc基于带打乱权重/偏置的关键词检测模型tensorflow/lite/micro/models/keyword_scrambled.tflite仅用于平台性能与体积测量而非精度验证。它包含框架 该模型所需内核 系统库因此keyword_benchmark − interpreter_memory_footprint≈ 该应用引入的内核代码量其运行逻辑封装在 micro_benchmark.h 的MicroBenchmarkRunner模板类中——它通过RecordingMicroAllocator与RecordingMicroInterpreter创建解释器、AllocateTensors()分配张量、Invoke()执行推理并提供PrintAllocations()打印内存分配明细。一个值得注意的方法论细节由于baseline/interpreter目标未注册内核MicroMutableOpResolver 产生的代码量会被计入内核开销而非框架开销文档明确这是为了简单、稳健并纳入系统库贡献而有意为之的取舍。文档还给出过参考快照按此法测得 64 位 x86 平台 TFLM 框架约 20411 字节旧数据快照仅作参考。差值方法论总结TFLM 框架代码量 ≈ interpreter_memory_footprint − baseline_memory_footprint 关键字模型内核代码量 ≈ keyword_benchmark − interpreter_memory_footprint文档同时提醒完整应用通常还包含 FlatBuffer 格式的 TFLite 模型与内存 arena它们一般落在 ELF 的 data 段同样是整体内存占用的重要部分但不属于本文讨论的代码量范畴。从数据看趋势仓库内 CSV 揭示的体积演变仓库内三份 CSV 记录了 2022-01 至 2022-07 的真实演变可以直接观察到几次阶梯式增长与提交 SHA 一一对应baseline_memory_footprint.csv单位字节时间点textdatabsstotal2022-01-101394520819222022-01-311433568820092022-07-14143356882009interpreter_memory_footprint.csv时间点textdatabsstotal2022-01-1022599146424240872022-01-3123756160024253802022-03-0926232164824279042022-04-2727648182424294962022-07-142761618242429464keyword_benchmark.csv时间点textdatabsstotal2022-01-10816571568224001056252022-01-31831411696224481072852022-03-09858771744224481100692022-04-27872771920224801116772022-06-16886451920224801130452022-07-1288597192022480112997几个可验证的观察点框架开销按差值法2022-01-10 时框架约为24087−192222165字节到 2022-07-14 增至29464−200927455字节半年内框架体积增长了约 5KB内核开销keyword_benchmark 与 interpreter 之差从 2022-01-10 的105625−2408781538字节增至 2022-07-14 的112997−2946486533字节bss 差异keyword_benchmark 的 bss 段约 22.4KB 起步显著大于前两者8~24 字节这与完整应用携带的大规模静态缓冲区形态一致具体段归属可结合 memory_footprint README 中模型与 arena 通常落在 data 段的说明进一步分析每次跃迁都伴随新的sha字段例如 interpreter 在 2022-01-31 的746f880a...提交后从 24087 跳到 25380体现了体积变化可回溯到具体提交的设计意图。本地复现把监控管线跑起来在仓库根目录按以下步骤即可完整复现整套体积监控需要make、GNUsize、Python 3、pandas、matplotlib# 1. 清理构建缓存并下载第三方依赖 make -f tensorflow/lite/micro/tools/make/Makefile clean clean_downloads make -f tensorflow/lite/micro/tools/make/Makefile third_party_downloads # 2. 构建三个二进制、用 size 采样并追加到 CSV python3 tensorflow/lite/micro/tools/metrics/create_size_log.py \ --build_typerelease --targetlinux --target_archx86_64 \ --binary_listkeyword_benchmark,baseline_memory_footprint,interpreter_memory_footprint # 3. 回溯最近 60 天历史、检测 text/total 增量是否超过 512 字节阈值并生成趋势图 python3 tensorflow/lite/micro/tools/metrics/detect_size_increase_and_plot_history.py \ --input_dirdata/continuous_builds/size_profiling/linux_x86_64_release \ --output_dirdata/continuous_builds/size_profiling/linux_x86_64_release \ --binary_listkeyword_benchmark,baseline_memory_footprint,interpreter_memory_footprint产物写入data/continuous_builds/size_profiling/linux_x86_64_release/二进制位于gen/linux_x86_64_release/bin/。如需监控其他平台可仿照 create_size_log_x86.sh 把--target/--target_arch换成目标配置例如 ARM Cortex-M 平台并保持输出目录命名规则一致。想单独运行基准本身也可直接使用 benchmarks README 中的make -f tensorflow/lite/micro/tools/make/Makefile run_keyword_benchmark等目标。长期愿景以产物为数据源的性能 Dashboarddata/continuous_builds/README.md 明确写到长期目标是通过基于这些产物的 Dashboard 来监控这些性能数据点。当前这套 CSV PNG 的落地形态已经为这一目标铺好了路时序友好记录以追加方式持续累积天然是按时间排序的序列数据可直接喂给时序数据库或图表组件可追溯每条记录携带 commit SHA异常体积跃迁可一键定位到具体提交阈值化512 字节的 text/total 增量阈值已内置到检测脚本中Dashboard 可以在此基础上做趋势告警、跨平台对比与长期漂移分析。换句话说现阶段持续构建 → 采样体积 → 追加 CSV → 检测阈值 → 输出趋势图的闭环已经是一个轻量、可扩展、可本地复现的性能监控雏形。小结本文以 data/continuous_builds/README.md 为线索完整还原了 tflite-micro 持续构建体积监控体系的三个层次产物层linux_x86_64_release/下的 CSV 与 PNG字段为date/sha/text/data/bss/total、管线层create_size_log_x86.sh→create_size_log.py采样 →detect_size_increase_and_plot_history.py阈值检测与绘图、语义层baseline/interpreter/keyword_benchmark三个二进制的减法方法论。这套体系的价值在于把体积与性能波动从一次性的静态检查变成了可追溯、可阈值告警、可持续观测的动态闭环——这既是文档所述意图的直接落地也是未来 Dashboard 化监控的现成数据源。赞分享人工智能深度学习推理引擎本地部署嵌入式物联网【免费下载链接】tflite-microInfrastructure to enable deployment of ML models to low-power resource-constrained embedded targets (including microcontrollers and digital signal processors).项目地址https://gitcode.com/gh_mirrors/tf/tflite-micro点击查看免费下载相关推荐OpenBLAS 持续基准测试pybench实践指南基于 pytest-benchmark 与 CodSpeed 的性能回归监控OpenBLAS 持续基准测试pybench实践指南基于 pytest benchmark 与 CodSpeed 的性能回归监控 导读 本文围绕 Open高性能计算科学计算Modin ASV 基准测试从本地性能回归检查到持续性能看板Modin ASV 基准测试从本地性能回归检查到持续性能看板 导读 本文以 asv_bench/README.md https://link.gitcode.数据分析数据工程大数据Resume-Matcher 的 Agentic 端到端监控e2e_monitor基于证据包的智能质量巡检与回归检测设计Resume Matcher 的 Agentic 端到端监控e2e_monitor基于证据包的智能质量巡检与回归检测设计 本文是一份技术设计解析核心素材AI 应用人工智能大模型后端前端上一篇极致优化Emscripten WebAssembly压缩全攻略gzip/brotli/wasm-gzip下一篇终极Atuin指南如何与tmux和screen完美集成提升终端效率创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考