人工智能深度学习推理引擎本地部署嵌入式物联网【免费下载链接】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点击查看免费下载本文围绕 docs/continuous_integration.md 展开系统讲解 TFLite MicroTFLM仓库的持续集成设计与实操贡献者/维护者分层测试策略、ci:ready/ci:full标签如何控制测试范围、GitHub Merge Queue 的合入校验流程、与 TensorFlow 上游的自动同步机制以及如何用官方 CI Docker 镜像在本地完整复现 CI 环境。读完本文你将掌握 TFLM 从提交、审批、测试到合入的完整链路并能在本地跑通与 CI 一致的测试脚本。一、CI 总览一套面向安全与速度的分层工作流TFLM 是一个面向微控制器、DSP 等低功耗资源受限设备的推理运行时其 CI 需要同时验证纯软件逻辑Bazel / Makefile 构建、单元测试与真实硬件Cortex-M、Xtensa、Hexagon、RISC-V行为。为了在「外部贡献的安全审计」与「维护者的迭代速度」之间取得平衡CI 采用分层Tiered策略角色自动执行的测试需要人工审批的测试维护者 受信任贡献者Trusted Contributors全部Basic Privileged无直接绕过环境门控environment gate外部贡献者低风险检查Lint、文件检查等 Basic 测试硬件在环测试Cortex-M、Xtensa、Hexagon、RISC-V与 Windows 构建这套策略的核心体现在 PR 工作流 .github/workflows/pr_test.yml 中。其入口 jobgatekeeper通过 GitHub API 查询 PR 作者的仓库协作权限const trustedRoles [admin, maintain, write, triage]; const isTrusted trustedRoles.includes(permission.permission);受信任角色含 bot默认在每次 push 时获得basic测试范围外部贡献者只有在 PR 被打上ci:ready/ci:full标签后才被唤醒测试后续的approval-gatejob 通过 GitHub Actions 的environment机制实现门控外部贡献者走integration-test环境需人工批准受信任者使用空字符串即不设门控environment: ${{ needs.gatekeeper.outputs.is_trusted false integration-test || }}当外部贡献者的 PR 需要跑硬件测试时PR 页面上的approval-gatejob 会显示Pending状态维护者审阅代码后点击Review Deployment - Approve即可放行。需要注意推送新代码会重置审批维护者需对最新提交重新批准这确保了被测试的始终是当前提交的代码。二、标签体系ci:ready与ci:full控制测试范围TFLM 用两个标签精确控制 PR 的 CI 行为标签作用ci:ready触发 CI由维护者对准备就绪的外部 PR 打上唤醒 CI 工作流并为特权测试套件生成审批请求。默认只跑basic范围的测试。ci:full扩展范围将测试范围从basic扩大到all纳入全部硬件目标如 RISC-V、Hexagon、Corstone 300 等。gatekeeper的 scope 判定逻辑来自 pr_test.yml如下let scope none; if (labels.includes(ci:full)) { scope all; } else if (labels.includes(ci:ready)) { scope basic; } else if (isTrusted) { scope basic; // 维护者与 bot 默认每次 push 都跑 basic }当scope none时所有测试 job 直接跳过tests-passed视为成功这避免了对外部未就绪 PR 浪费 CI 资源。各硬件套件对scope的使用方式也不同例如 suite_cortex_m.yml 中 Bluepill 与 QEMU 单元测试在basic或all下都运行而 Corstone 300GCC / Arm Clang仅在scope all时执行pr_test.yml 中的 RISC-V 套件同样只在scope all时被调用。三、GitHub Merge Queue合入前的最后一道关卡所有 PR 最终通过 GitHub Merge Queue 落盘。流程为PR 通过 review 且所有必需检查required checks通过维护者点击Merge when ready将 PR 加入队列merge_group.yml 在临时合并分支上运行完整测试套件trigger-sha使用github.sha所有硬件套件 scope 均强制为all通过后才真正合入main。Merge Queue 的核心价值在于验证多个 PR 组合在一起不会破坏main。单独的 PR 各自通过测试并不代表合并后仍然健康排队合入机制把「组合回归」作为合入前提。与 PR 触发不同merge_group事件没有权限门控——它运行的就是最终要合入的合并结果因此直接以all范围跑全套call-cortex-m: uses: ./.github/workflows/suite_cortex_m.yml with: trigger-sha: ${{ github.sha }} scope: all四、与 TensorFlow 上游的自动同步TFLM 与主 TensorFlow 仓库共享大量代码同步方向是单向的权威来源Source of Truth共享代码的修改必须先提交到 TensorFlow 仓库自动同步通过定时任务 .github/workflows/sync.yml 每天 UTC 14:00约美西 7/8 点自动执行也支持workflow_dispatch手动触发产出形式同步脚本跑完后由 TFLM-bot 自动创建 PRAutomated sync from github.com/tensorflow/tensorflow并自动打上bot:sync-tf与ci:ready标签从而走正常 CI 流程。同步逻辑实现在 ci/sync_from_upstream_tf.sh 中其关键步骤包括读取 ci/tflite_files.txt 中维护的共享文件清单并区分普通 TFLite 代码tensorflow/lite/...与转换器代码tensorflow/compiler/mlir/lite/...浅克隆上游 LiteRTTensorFlow Lite 所在仓库到临时目录按清单删除本地旧文件防止残留陈旧产物将上游文件复制回本地对应路径并用sed把上游 include 路径tflite/...反向改写为本地路径tensorflow/lite/...或tensorflow/compiler/mlir/lite/...用 Bazel 重新生成 Flatbuffer schemaschema_generated.h并复制到源码树保证 Makefile 构建也能使用。五、硬件测试套件五类目标平台PR 与 Merge Queue 会按 scope 触发五类硬件套件每个套件都是独立的可复用 workflowworkflow_call分别汇总多个具体测试 job套件 Workflow覆盖内容suite_core.ymlBazel 测试test_bazel.yml、Makefile 测试test_makefile.yml、杂项检查test_misc.yml如代码风格、文件合法性检查suite_cortex_m.ymlBluepillSTM32F103、QEMU 单元测试basic/all、Corstone 300 GCC 与 Arm Clang仅 allsuite_xtensa.ymlXtensa 各 DSP 内核HiFi 系列、Fusion F1、Vision P6suite_hexagon.yml高通 Hexagon DSPsuite_riscv.ymlRISC-V 目标suite_cortex_m.yml展示了「软件仿真 真实硬件」的组合验证思路Bluepill 与 QEMU 是快速基础检查Corstone 300 则更接近真实 Arm Cortex-M 系统用 Dockerfile.corstone300 构建的ghcr.io/tflm-bot/corstone300:0.1镜像运行其中 Arm Clang 任务还涉及 vcpkg 安装 Arm 工具链与 license 激活。此外run_core.yml、run_cortex_m.yml、run_hexagon.yml、run_riscv.yml、run_xtensa.yml等定时工作流schedule workflow_dispatch会在主仓库定期重跑全套测试并在失败时通过 issue_on_error.yml 自动创建 issue形成日常监控闭环。六、本地复现 CI官方 Docker 镜像CI 环境可完全在本地用 Docker 复现这是调试 CI 失败的最快路径。6.1 构建镜像在仓库根目录执行docker build -t tflm-ci -f ci/Dockerfile.micro .也可以直接拉取预构建镜像docker pull ghcr.io/tflm-bot/tflm-ci:version版本号参考 suite_cortex_m.yml 中使用的0.6.10等 tag。ci/Dockerfile.micro 展示了 CI 容器的完整依赖构成它基于python:3.11-bookwormQEMU从 bookworm-backports 安装qemu-user用于 Cortex-M 用户态仿真测试编译工具链clang-22/clang-22/clang-format-22/clang-tidy-22并创建无版本号软链接供clang-format、clang-tidy检查使用Python 依赖matplotlib、numpy、pandas、PillowC 数组生成、psutil、pyyaml、requests、robotframeworkRenode 测试、ruff与yapfPython 格式检查、pyreflyPython 类型检查Bazel 工具链运行 install_bazelisk.sh 与 install_buildifier.sh 安装 bazeliskBazel 版本管理器与 buildifierBUILD 文件格式化/校验工具Git 安全目录git config --system --add safe.directory *避免容器内挂载仓库时的 dubious ownership 报错。镜像还内置了xxd——这正是 docs/automatically_generated_files.md 中提到的、历史上用于把模型/测试数据转成 C 数组xxd -i data file data_file.cc的工具。6.2 交互式运行将本地 TFLM 目录挂载进容器即可在容器内对本地改动运行测试docker run -v /path/to/local/tflite-micro:/path/to/docker/tflite-micro -it tflm-ci /bin/bash更简洁的惯用写法进入容器并自动切到挂载目录docker run -it --rm -v $(pwd):/opt/tflm -w /opt/tflm tflm-ci /bin/bash6.3 清理docker ps --all docker rm docker image ID七、CI 脚本目录把测试变成可复用的 shell仓库将 CI 检查全部沉淀为脚本统一放在 tensorflow/lite/micro/tools/ci_build/ 下GitHub Actions 只是这些脚本的调度层本地也可以直接调用。常用的包括脚本用途test_bluepill.shCortex-M Bluepill 构建与测试test_cortex_m_qemu.shCortex-M QEMU 单元测试test_cortex_m_corstone_300.shCorstone 300 系统级测试默认 GCC可传armclangtest_xtensa_hifimini.sh/test_xtensa_hifi3z.sh/test_xtensa_hifi5.sh/test_xtensa_fusion_f1.sh/test_xtensa_vision_p6.sh各 Xtensa DSP 内核test_hexagon.shHexagon DSPtest_riscv.shRISC-Vtest_makefile.sh/test_bazel.sh两种构建系统的全量单元测试test_bazel_asan.sh/test_bazel_msan.shAddressSanitizer / MemorySanitizertest_code_style.sh/test_clang_tidy.sh代码风格与静态分析test_size.sh二进制体积回归检查test_project_generation.sh工程生成Makefile 模板一致性检查配合 run_in_docker.sh 与 docker_run_tflm.sh即可在本地容器中精确复现任一 CI job 的行为例如# 在 tflm-ci 容器中运行 Bluepill 测试与 suite_cortex_m.yml 中一致 tensorflow/lite/micro/tools/ci_build/test_bluepill.sh tflite-micro/八、相关配套文件索引CI 文档docs/continuous_integration.md数据文件生成机制docs/automatically_generated_files.md工作流定义.github/workflows/pr_test.yml、merge_group.yml、sync.yml、各suite_*.yml/run_*.ymlDocker 镜像ci/Dockerfile.micro、ci/Dockerfile.corstone300、ci/Dockerfile.hexagon、ci/Dockerfile.xtensa同步脚本与文件清单ci/sync_from_upstream_tf.sh、ci/tflite_files.txtCI 测试脚本tensorflow/lite/micro/tools/ci_build/九、常见问题速查我的外部 PR 为什么approval-gate一直是 Pending因为硬件在环测试需要维护者手动批准请等待维护者点击Review Deployment - Approve。注意每次 push 后审批都会重置。如何让 CI 跑更多目标让维护者给 PR 打上ci:full标签scope 会从basic扩到all加入 RISC-V、Hexagon、Corstone 300 等。如何在本地调试 CI 失败构建tflm-ci镜像并挂载仓库进入容器直接运行对应的test_*.sh脚本环境和 CI 完全一致。CI 是每天都自动跑吗是的。除 PR / Merge Queue 触发外run_core.yml、run_xtensa.yml等工作流按 schedule 定期运行全套测试失败会自动创建 issue 跟踪。赞分享人工智能深度学习推理引擎本地部署嵌入式物联网【免费下载链接】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点击查看免费下载相关推荐Wasmtime 持续集成CI体系详解PR 流水线、Merge Queue 与发布产物Wasmtime 持续集成CI体系详解PR 流水线、Merge Queue 与发布产物 导读 本文基于 Wasmtime 仓库的 docs/contrib语言运行时JIT编译编译器Apache TVM 持续集成CI体系全解析从 Jenkins 流水线到本地复现工具链Apache TVM 持续集成CI体系全解析从 Jenkins 流水线到本地复现工具链 Apache TVMOpen Machine Learning模型编译深度学习推理引擎K3s 持续集成与自动化体系深度解析GitHub Actions 与 Drone 双平台 CI 及本地复现指南K3s 持续集成与自动化体系深度解析GitHub Actions 与 Drone 双平台 CI 及本地复现指南 本文以 K3s 仓库的官方 CI 文档 do云原生容器编排集群管理边缘计算容器运行时上一篇JasminumZotero中文文献元数据智能抓取与自动化管理解决方案下一篇XHS-Downloader企业级小红书内容采集与自动化下载解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 TFLite Micro 持续集成（CI）体系全解析：分层权限、Merge Queue、上游同步与本地 Docker 复现
人工智能深度学习推理引擎本地部署嵌入式物联网【免费下载链接】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点击查看免费下载本文围绕 docs/continuous_integration.md 展开系统讲解 TFLite MicroTFLM仓库的持续集成设计与实操贡献者/维护者分层测试策略、ci:ready/ci:full标签如何控制测试范围、GitHub Merge Queue 的合入校验流程、与 TensorFlow 上游的自动同步机制以及如何用官方 CI Docker 镜像在本地完整复现 CI 环境。读完本文你将掌握 TFLM 从提交、审批、测试到合入的完整链路并能在本地跑通与 CI 一致的测试脚本。一、CI 总览一套面向安全与速度的分层工作流TFLM 是一个面向微控制器、DSP 等低功耗资源受限设备的推理运行时其 CI 需要同时验证纯软件逻辑Bazel / Makefile 构建、单元测试与真实硬件Cortex-M、Xtensa、Hexagon、RISC-V行为。为了在「外部贡献的安全审计」与「维护者的迭代速度」之间取得平衡CI 采用分层Tiered策略角色自动执行的测试需要人工审批的测试维护者 受信任贡献者Trusted Contributors全部Basic Privileged无直接绕过环境门控environment gate外部贡献者低风险检查Lint、文件检查等 Basic 测试硬件在环测试Cortex-M、Xtensa、Hexagon、RISC-V与 Windows 构建这套策略的核心体现在 PR 工作流 .github/workflows/pr_test.yml 中。其入口 jobgatekeeper通过 GitHub API 查询 PR 作者的仓库协作权限const trustedRoles [admin, maintain, write, triage]; const isTrusted trustedRoles.includes(permission.permission);受信任角色含 bot默认在每次 push 时获得basic测试范围外部贡献者只有在 PR 被打上ci:ready/ci:full标签后才被唤醒测试后续的approval-gatejob 通过 GitHub Actions 的environment机制实现门控外部贡献者走integration-test环境需人工批准受信任者使用空字符串即不设门控environment: ${{ needs.gatekeeper.outputs.is_trusted false integration-test || }}当外部贡献者的 PR 需要跑硬件测试时PR 页面上的approval-gatejob 会显示Pending状态维护者审阅代码后点击Review Deployment - Approve即可放行。需要注意推送新代码会重置审批维护者需对最新提交重新批准这确保了被测试的始终是当前提交的代码。二、标签体系ci:ready与ci:full控制测试范围TFLM 用两个标签精确控制 PR 的 CI 行为标签作用ci:ready触发 CI由维护者对准备就绪的外部 PR 打上唤醒 CI 工作流并为特权测试套件生成审批请求。默认只跑basic范围的测试。ci:full扩展范围将测试范围从basic扩大到all纳入全部硬件目标如 RISC-V、Hexagon、Corstone 300 等。gatekeeper的 scope 判定逻辑来自 pr_test.yml如下let scope none; if (labels.includes(ci:full)) { scope all; } else if (labels.includes(ci:ready)) { scope basic; } else if (isTrusted) { scope basic; // 维护者与 bot 默认每次 push 都跑 basic }当scope none时所有测试 job 直接跳过tests-passed视为成功这避免了对外部未就绪 PR 浪费 CI 资源。各硬件套件对scope的使用方式也不同例如 suite_cortex_m.yml 中 Bluepill 与 QEMU 单元测试在basic或all下都运行而 Corstone 300GCC / Arm Clang仅在scope all时执行pr_test.yml 中的 RISC-V 套件同样只在scope all时被调用。三、GitHub Merge Queue合入前的最后一道关卡所有 PR 最终通过 GitHub Merge Queue 落盘。流程为PR 通过 review 且所有必需检查required checks通过维护者点击Merge when ready将 PR 加入队列merge_group.yml 在临时合并分支上运行完整测试套件trigger-sha使用github.sha所有硬件套件 scope 均强制为all通过后才真正合入main。Merge Queue 的核心价值在于验证多个 PR 组合在一起不会破坏main。单独的 PR 各自通过测试并不代表合并后仍然健康排队合入机制把「组合回归」作为合入前提。与 PR 触发不同merge_group事件没有权限门控——它运行的就是最终要合入的合并结果因此直接以all范围跑全套call-cortex-m: uses: ./.github/workflows/suite_cortex_m.yml with: trigger-sha: ${{ github.sha }} scope: all四、与 TensorFlow 上游的自动同步TFLM 与主 TensorFlow 仓库共享大量代码同步方向是单向的权威来源Source of Truth共享代码的修改必须先提交到 TensorFlow 仓库自动同步通过定时任务 .github/workflows/sync.yml 每天 UTC 14:00约美西 7/8 点自动执行也支持workflow_dispatch手动触发产出形式同步脚本跑完后由 TFLM-bot 自动创建 PRAutomated sync from github.com/tensorflow/tensorflow并自动打上bot:sync-tf与ci:ready标签从而走正常 CI 流程。同步逻辑实现在 ci/sync_from_upstream_tf.sh 中其关键步骤包括读取 ci/tflite_files.txt 中维护的共享文件清单并区分普通 TFLite 代码tensorflow/lite/...与转换器代码tensorflow/compiler/mlir/lite/...浅克隆上游 LiteRTTensorFlow Lite 所在仓库到临时目录按清单删除本地旧文件防止残留陈旧产物将上游文件复制回本地对应路径并用sed把上游 include 路径tflite/...反向改写为本地路径tensorflow/lite/...或tensorflow/compiler/mlir/lite/...用 Bazel 重新生成 Flatbuffer schemaschema_generated.h并复制到源码树保证 Makefile 构建也能使用。五、硬件测试套件五类目标平台PR 与 Merge Queue 会按 scope 触发五类硬件套件每个套件都是独立的可复用 workflowworkflow_call分别汇总多个具体测试 job套件 Workflow覆盖内容suite_core.ymlBazel 测试test_bazel.yml、Makefile 测试test_makefile.yml、杂项检查test_misc.yml如代码风格、文件合法性检查suite_cortex_m.ymlBluepillSTM32F103、QEMU 单元测试basic/all、Corstone 300 GCC 与 Arm Clang仅 allsuite_xtensa.ymlXtensa 各 DSP 内核HiFi 系列、Fusion F1、Vision P6suite_hexagon.yml高通 Hexagon DSPsuite_riscv.ymlRISC-V 目标suite_cortex_m.yml展示了「软件仿真 真实硬件」的组合验证思路Bluepill 与 QEMU 是快速基础检查Corstone 300 则更接近真实 Arm Cortex-M 系统用 Dockerfile.corstone300 构建的ghcr.io/tflm-bot/corstone300:0.1镜像运行其中 Arm Clang 任务还涉及 vcpkg 安装 Arm 工具链与 license 激活。此外run_core.yml、run_cortex_m.yml、run_hexagon.yml、run_riscv.yml、run_xtensa.yml等定时工作流schedule workflow_dispatch会在主仓库定期重跑全套测试并在失败时通过 issue_on_error.yml 自动创建 issue形成日常监控闭环。六、本地复现 CI官方 Docker 镜像CI 环境可完全在本地用 Docker 复现这是调试 CI 失败的最快路径。6.1 构建镜像在仓库根目录执行docker build -t tflm-ci -f ci/Dockerfile.micro .也可以直接拉取预构建镜像docker pull ghcr.io/tflm-bot/tflm-ci:version版本号参考 suite_cortex_m.yml 中使用的0.6.10等 tag。ci/Dockerfile.micro 展示了 CI 容器的完整依赖构成它基于python:3.11-bookwormQEMU从 bookworm-backports 安装qemu-user用于 Cortex-M 用户态仿真测试编译工具链clang-22/clang-22/clang-format-22/clang-tidy-22并创建无版本号软链接供clang-format、clang-tidy检查使用Python 依赖matplotlib、numpy、pandas、PillowC 数组生成、psutil、pyyaml、requests、robotframeworkRenode 测试、ruff与yapfPython 格式检查、pyreflyPython 类型检查Bazel 工具链运行 install_bazelisk.sh 与 install_buildifier.sh 安装 bazeliskBazel 版本管理器与 buildifierBUILD 文件格式化/校验工具Git 安全目录git config --system --add safe.directory *避免容器内挂载仓库时的 dubious ownership 报错。镜像还内置了xxd——这正是 docs/automatically_generated_files.md 中提到的、历史上用于把模型/测试数据转成 C 数组xxd -i data file data_file.cc的工具。6.2 交互式运行将本地 TFLM 目录挂载进容器即可在容器内对本地改动运行测试docker run -v /path/to/local/tflite-micro:/path/to/docker/tflite-micro -it tflm-ci /bin/bash更简洁的惯用写法进入容器并自动切到挂载目录docker run -it --rm -v $(pwd):/opt/tflm -w /opt/tflm tflm-ci /bin/bash6.3 清理docker ps --all docker rm docker image ID七、CI 脚本目录把测试变成可复用的 shell仓库将 CI 检查全部沉淀为脚本统一放在 tensorflow/lite/micro/tools/ci_build/ 下GitHub Actions 只是这些脚本的调度层本地也可以直接调用。常用的包括脚本用途test_bluepill.shCortex-M Bluepill 构建与测试test_cortex_m_qemu.shCortex-M QEMU 单元测试test_cortex_m_corstone_300.shCorstone 300 系统级测试默认 GCC可传armclangtest_xtensa_hifimini.sh/test_xtensa_hifi3z.sh/test_xtensa_hifi5.sh/test_xtensa_fusion_f1.sh/test_xtensa_vision_p6.sh各 Xtensa DSP 内核test_hexagon.shHexagon DSPtest_riscv.shRISC-Vtest_makefile.sh/test_bazel.sh两种构建系统的全量单元测试test_bazel_asan.sh/test_bazel_msan.shAddressSanitizer / MemorySanitizertest_code_style.sh/test_clang_tidy.sh代码风格与静态分析test_size.sh二进制体积回归检查test_project_generation.sh工程生成Makefile 模板一致性检查配合 run_in_docker.sh 与 docker_run_tflm.sh即可在本地容器中精确复现任一 CI job 的行为例如# 在 tflm-ci 容器中运行 Bluepill 测试与 suite_cortex_m.yml 中一致 tensorflow/lite/micro/tools/ci_build/test_bluepill.sh tflite-micro/八、相关配套文件索引CI 文档docs/continuous_integration.md数据文件生成机制docs/automatically_generated_files.md工作流定义.github/workflows/pr_test.yml、merge_group.yml、sync.yml、各suite_*.yml/run_*.ymlDocker 镜像ci/Dockerfile.micro、ci/Dockerfile.corstone300、ci/Dockerfile.hexagon、ci/Dockerfile.xtensa同步脚本与文件清单ci/sync_from_upstream_tf.sh、ci/tflite_files.txtCI 测试脚本tensorflow/lite/micro/tools/ci_build/九、常见问题速查我的外部 PR 为什么approval-gate一直是 Pending因为硬件在环测试需要维护者手动批准请等待维护者点击Review Deployment - Approve。注意每次 push 后审批都会重置。如何让 CI 跑更多目标让维护者给 PR 打上ci:full标签scope 会从basic扩到all加入 RISC-V、Hexagon、Corstone 300 等。如何在本地调试 CI 失败构建tflm-ci镜像并挂载仓库进入容器直接运行对应的test_*.sh脚本环境和 CI 完全一致。CI 是每天都自动跑吗是的。除 PR / Merge Queue 触发外run_core.yml、run_xtensa.yml等工作流按 schedule 定期运行全套测试失败会自动创建 issue 跟踪。赞分享人工智能深度学习推理引擎本地部署嵌入式物联网【免费下载链接】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点击查看免费下载相关推荐Wasmtime 持续集成CI体系详解PR 流水线、Merge Queue 与发布产物Wasmtime 持续集成CI体系详解PR 流水线、Merge Queue 与发布产物 导读 本文基于 Wasmtime 仓库的 docs/contrib语言运行时JIT编译编译器Apache TVM 持续集成CI体系全解析从 Jenkins 流水线到本地复现工具链Apache TVM 持续集成CI体系全解析从 Jenkins 流水线到本地复现工具链 Apache TVMOpen Machine Learning模型编译深度学习推理引擎K3s 持续集成与自动化体系深度解析GitHub Actions 与 Drone 双平台 CI 及本地复现指南K3s 持续集成与自动化体系深度解析GitHub Actions 与 Drone 双平台 CI 及本地复现指南 本文以 K3s 仓库的官方 CI 文档 do云原生容器编排集群管理边缘计算容器运行时上一篇JasminumZotero中文文献元数据智能抓取与自动化管理解决方案下一篇XHS-Downloader企业级小红书内容采集与自动化下载解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考