本篇速览开发态和量产态是两种东西开发态追求能跑通量产态追求没人盯着也能长期稳定跑。把前者直接当后者是端侧项目翻车最常见的根源。量产要管好五件事进程守护systemd 自启 崩溃自愈 看门狗、日志可观测规范 轮转 指标监控、版本升级OTA 回滚、硬件可靠性SD 卡寿命、断电、散热、验收烤机 断电恢复 升级演练。一条贯穿全讲的原则凡是量产环境必须自动完成、不能靠人的事都要在交付前做成机制而不是靠运维记住。本讲是系列收官前 11 讲解决做出来本讲解决交得出去、活得下去。一、从能跑到能交付、能量产1.1 综合实战之后还差最后一步第 11 讲我们把视觉、检测、大模型、跨系统通信装配成了一个能跑的端到端应用。在你的开发板上它跑得很好。但请注意一个前提那块板子插着电、连着你的调试终端、有你在旁边盯着。真实世界不是这样——设备要装到车间、门店、园区一跑就是几个月没人天天看着会断电、会过热、会升级、会出各种你想不到的幺蛾子。从我板上能跑到客户现场长期稳定跑中间这段路叫工程化量产。它不加任何新的 AI 能力却决定了你的成果到底是一个Demo还是一个产品。这一讲我们就走完这最后一步。1.2 开发态 vs 量产态的本质区别把两者的差异想清楚才知道量产要补什么维度开发态量产态启动方式手动敲命令开机自启、崩溃自愈出错时你就在旁边看无人值守要自动恢复日志打到终端看两眼落盘、轮转、可远程查升级重刷固件远程 OTA、可回滚运行时长跑几小时7×24 跑数月环境恒温实验室高低温、断电、振动一句话总结开发态靠人兜底量产态要靠机制兜底。量产工程化的全部工作就是把那些开发时靠你手动做的事变成系统自动完成的机制。1.3 量产要回答的五个问题把量产拆成五个必须回答的问题本讲逐一解决一是进程——应用怎么开机自己起来、崩了自己复活二是日志——出了事怎么看、磁盘会不会被日志撑爆三是升级——怎么远程更新应用和模型、升级失败怎么回退四是硬件——SD 卡写多了会不会死、断电会不会变砖、过热会不会降频五是验收——交付前怎么证明它扛得住这五个问题都有答案了你的产品才算真正能出门。1.4 本讲目标与范围读完本讲你应该能用 systemd 把第 11 讲的应用做成开机自启、崩溃自愈的服务配上规范的日志与资源监控设计一套带 OTA 升级与回滚的交付流程并用一份量产检查清单做交付前验收。本讲不限定具体板型A1、X1 都适用讲的是端侧 Linux 设备通用的量产工程方法落到 AidLux 环境时具体命令以官方文档为准。二、进程管理让应用自己活得好2.1 为什么不能手动启动就完事开发时你习惯了python orchestrator.py手动跑。量产时这行不通设备重启后没人去敲这条命令进程半夜崩了没人去重启。你需要一个管家负责开机自动拉起应用、盯着它、崩了自动重启。在 Linux 上这个管家就是systemd——系统的初始化与进程管理器几乎所有现代 Linux 发行版包括 AidLux 的 Linux 侧都用它管理服务。2.2 systemd给应用上户口把应用交给 systemd 管就是写一个unit 文件.service告诉它启动什么命令、用什么用户、工作目录在哪、环境变量是什么、崩了怎么办。注册后systemctl start/stop/enable就能控制应用enable让它开机自启。这一步的本质是把一个你手动跑的脚本变成一个受系统管理的、有生命周期的服务。第 6.1 节给出完整示例。2.3 崩溃自愈与重启策略systemd 最强大的地方是自愈在 unit 里配Restarton-failure进程异常退出它会自动拉起。但重启策略要讲究不能无脑无限重启——如果应用是因为配置错误起不来无限重启只会疯狂刷日志。工程上常用Restarton-failureRestartSec5等 5 秒再起避免瞬间反复 启动频率限制一段时间内重启太多次就放弃并报警。还要区分可恢复的崩溃重启能解决如偶发内存错误和不可恢复的错误重启也白搭如模型文件缺失前者靠自愈后者要报警让人介入。2.4 多组件的启动依赖编排第 11 讲的系统有多个组件启动有先后AidGenSE 服务要先起来编排器才能连通道要先建连结果才能发。systemd 用After和Requires/Wants表达这种依赖——比如编排器的 unit 声明Afteraidgense.service确保大模型服务先就绪。把启动依赖显式声明出来系统重启时各组件就能按正确顺序自动拉起而不是谁抢到谁先起、起来发现依赖没好又崩。这正是把第 11 讲 7.4依赖顺序问题在系统层面固化解决。2.5 看门狗最后的保险systemd 能管进程死了重启但管不了进程活着却卡死比如死锁、无限等待。这种假活要靠看门狗watchdog应用定期喂狗发送心跳看门狗超时没收到心跳就强制重启进程甚至重启系统。对 7×24 的端侧设备看门狗是防卡死无人发现的最后保险。实现上硬件看门狗/dev/watchdog或软件看门狗均可核心思想一致用一条独立的心跳证明应用不仅在、而且在正常干活。2.6 资源限制用 cgroup 给应用上笼子多组件共用一块板子要防一个组件失控吃光资源、拖死全局。Linux 的cgroup能给进程限制 CPU、内存上限在 systemd 的 unit 里直接配MemoryMax1G内存超限就 OOM 重启它而不是拖垮整机、CPUQuota150%限制 CPU 用量。给大模型这类资源大户设上限尤其重要——宁可它自己被限流重启也不能让它把视频采集、系统进程饿死。资源隔离的思想和看门狗互补看门狗管它活着没cgroup 管它别太过分。给关键服务都配上资源上限整机稳定性就上一个台阶。2.7 最小权限别用 root 跑你的应用开发时图省事常用 root 跑应用量产要改过来——最小权限原则给应用建一个专用用户如 aidlux只授予它必需的权限访问摄像头、音频、自己的目录其余一律不给。unit 里的Useraidlux就是干这个的。好处有二一是安全——应用即使有漏洞被利用能破坏的也仅限它那一亩三分地动不了系统二是稳定——应用误操作比如删错文件时权限受限能挡住很多自杀式事故。配合 systemd 的ProtectSystem、ProtectHome等沙箱选项还能把应用能碰什么进一步收紧。量产安全就从别用 root这件小事做起。三、日志与可观测性3.1 日志规范级别、格式、落盘量产排障全靠日志所以日志要规范不能像开发时那样随手 print。基本要求分级DEBUG/INFO/WARN/ERROR量产默认 INFO出问题再开 DEBUG、带时间戳和模块名知道什么时候、哪个组件、关键事件必记启动、停止、异常、升级、资源告警、落到文件而非只到终端。Python 用logging模块配handlers即可。一条好日志的标准是三个月后你不在现场光看日志也能还原出当时发生了什么。3.2 日志轮转别让磁盘被日志吃光7×24 跑几个月日志会越积越多把存储尤其是 SD 卡撑爆直接把系统搞挂。必须做日志轮转日志到一定大小或按天就切一个新文件只保留最近 N 份旧的删掉或压缩。Linux 标配logrotate配一下多大切、留几份、是否压缩即可6.2。这是量产设备最容易被忽略、却最致命的一条——无数设备不是死于 Bug而是死于日志写满了磁盘。3.3 关键指标监控除了应用日志还要盯系统级指标它们往往是故障的先兆CPU/内存占用是否爬升爬升泄漏、温度是否过热逼近降频线、存储剩余是否被日志/数据蚕食、NPU 利用率是否异常。把这些指标定期采集、记录6.4异常时告警。第 11 讲 8.5 给应用埋的业务指标和这里的系统指标合起来就是完整的可观测性。监控的价值在早知道——在设备彻底挂掉之前先从指标的异常趋势里看出苗头。3.4 远程查看与告警设备装在现场总不能每次出问题都跑去接显示器。要具备远程能力日志能远程拉取SSH/日志上报、指标能远程看、异常能主动告警发到你的运维通道。端侧设备常在私网远程方案要按网络条件选——能直连就 SSH不能直连就让设备主动上报到运维端。告警要克制只对需要人介入的事告警如连续重启失败、温度越限、存储将满别把告警做成噪音否则真正的警报会被淹没。3.5 远程诊断设备出问题怎么隔空把脉设备装在现场出了问题没法接显示器怎么诊断靠一套隔空把脉的组合一是日志远程可达——设备把日志上报到运维端或你能 SSH 上去捞二是指标历史可查——6.4 的监控数据存成时间序列出问题先看故障前的指标趋势内存是不是一直在涨、温度是不是先飙了三是现场保留——异常时自动抓一份现场最近的日志、当前指标、核心转储别等设备一重启把证据冲掉四是分级响应——能远程重启服务解决的别动系统能远程解决的别派人跑现场。把诊断能力建在交付之前出问题才不至于两眼一抹黑。四、版本与升级OTA4.1 版本管理纪律升级的前提是版本清晰。每个交付物——应用代码、AI 模型、配置文件、系统镜像——都要有明确版本号且记录这批设备跑的是哪套版本。前面各讲反复维护的那张版本总表到量产就是升级管理的底账。没有清晰版本OTA 就是瞎升你不知道哪台设备该升、升完变成什么样、出问题回退到哪。版本纪律是量产升级的地基。4.2 应用与模型的热更新最高频的升级是应用代码和 AI 模型换检测模型、升级大模型。这类更新要尽量做成热更新不刷整个系统只替换应用文件和模型文件然后重启对应服务。配合第 11 讲的回归基线——新模型/新版本先在基线上验证没变糟再推送到设备。模型更新尤其要谨慎模型是 AI 应用的核心换错了直接影响效果所以先基线验证、再小范围灰度、最后全量是稳妥的节奏。4.3 系统 / 镜像升级偶尔要升级整个系统AidLux OS、底层驱动、QNN。这类升级比应用升级重、风险高通常整镜像替换。要点升级前备份关键数据、升级包做完整性校验hash、升级过程保证断电可恢复见 7.2、7.4。系统级升级频率低但每一次都要当成大手术对待。4.4 回滚升级的后悔药升级总会偶尔失败或引入新问题所以必须预留回滚。常见做法是A/B 分区系统装两份A、B升级写到另一份新版本验证没问题再切换启动一旦新版本起不来或有问题自动切回旧版本。这样即使升级失败设备也能回到上一个能用的状态而不是变砖。回滚机制是量产升级的生命线——没有回滚的 OTA是在拿现场设备赌博。4.5 灰度发布别一次推全量就算有回滚也不该把新版本一次推到所有设备。稳妥的做法是灰度分批发布先推给一两台小白鼠设备观察一段时间功能正常、指标平稳再扩大到一小批最后才全量。灰度的意义是把新版本可能带未知问题的爆炸半径控制到最小——哪怕某版有 Bug也只影响几台、且能回滚而不是全现场同时趴窝。配合版本上报每台设备上报自己跑的版本你能清楚掌握哪些已升、哪些还旧、哪些升级失败。灰度 回滚 版本上报这三件套凑齐OTA 才算真正成熟。4.6 配置也要版本化且和代码、模型绑定升级时容易只盯着代码和模型漏了配置。但第 11 讲那份config.yaml同样决定行为——改了队列长度、冷却时间系统表现就不同。所以配置也要版本化并且和代码、模型绑定发布某版应用配套某版配置、某版模型三者作为一个发布单元一起升、一起退。否则会出现代码是新版、配置是旧版的错位行为诡异还难排查。把应用 配置 模型当成一个整体版本来管理升级和回滚才不会留下半新半旧的烂摊子。五、操作步骤把 Demo 做成可交付5.1 固化环境与依赖把应用运行的环境固化下来依赖的库版本、模型文件、配置文件都打成明确的交付包记录版本4.1。目标是在一台全新的同型号板子上按文档能完整复现出同样的运行环境——这是可交付的第一标准。和第 01 讲的环境就绪呼应只是这次是为批量复制做准备。5.2 配置 systemd 开机自启写好 unit 文件6.1systemctl enable让应用开机自启配上重启策略与启动依赖。然后重启设备验证断电再上电看应用是否自动起来、各组件是否按序就绪、功能是否正常。能扛住重启这关才算真正脱离了手动启动。5.3 接通日志与监控配上日志规范与 logrotate6.2、跑起资源监控采集6.3、6.4、设好告警。验证让应用跑一会儿看日志是否按规范落盘、轮转是否生效、指标是否在采集、触发一次告警看能否收到。5.4 做一次升级与回滚演练别等真升级才第一次走流程。交付前完整演练一次推送一个哪怕是改了版本号的新版本走完整的 OTA 流程验证升级成功再故意制造一次升级失败验证能正确回滚到旧版本。演练过的升级流程才可信——没在交付前演练过的 OTA第一次真用时大概率出状况。5.5 量产镜像把调好的系统做成可批量烧录的母盘当要部署的不是一台、而是一批设备逐台手动配置就不现实了。做法是做母盘量产镜像把一台设备从系统到应用、配置、模型全部调好、验收通过再把它的系统整体做成镜像批量烧录到其他设备。要点镜像里把与具体设备无关的部分都预置好应用、服务、配置模板、模型把逐台不同的部分设备编号、网络参数、密钥留到首次启动时初始化。烧录后每台设备首次上电跑一个初始化脚本写入自己的身份信息即可直接投入使用。母盘 首启初始化是从做一台到做一批的关键一跃也是量产规模化的起点。六、关键配置与脚本6.1 systemd unit 示例# /etc/systemd/system/caption.service [Unit] DescriptionSmart Camera Caption Service Afternetwork.target aidgense.service # 依赖网络与大模型服务先就绪 Wantsaidgense.service [Service] Typesimple Useraidlux WorkingDirectory/home/aidlux/caption EnvironmentCONFIG_PATH/home/aidlux/caption/config.yaml ExecStart/usr/bin/python3 /home/aidlux/caption/orchestrator.py Restarton-failure # 崩溃自愈 RestartSec5 # 每次重启间隔5秒 StartLimitIntervalSec300 # 300秒内 StartLimitBurst5 # 最多重启5次超过放弃 StandardOutputappend:/var/log/caption/app.log StandardErrorappend:/var/log/caption/app.log [Install] WantedBymulti-user.targetsystemctl enable caption即开机自启。关键点都写在注释里依赖顺序、崩溃自愈、重启频率限制、日志落盘。6.2 logrotate 配置# /etc/logrotate.d/caption /var/log/caption/*.log { daily # 按天轮转 rotate 14 # 保留14份 maxsize 50M # 单文件超50M也切 compress # 旧日志压缩 missingok notifempty copytruncate # 应用持续写时安全切换 }这份配置保证日志最多占14 天 × 每天 ≤50M的空间磁盘不会被日志撑爆7.1。6.3 健康检查与看门狗脚本# healthcheck.py —— 健康检查 喂狗可被 systemd 定时调用或内嵌进应用importos,time,requestsdefapp_alive():try:# 探活大模型服务与应用关键链路rrequests.post(http://127.0.0.1:8888/v1/chat/completions,json{model:qwen2.5-0.5b-instruct,messages:[{role:user,content:ping}]},timeout10)returnr.status_code200exceptException:returnFalseifapp_alive():withopen(/dev/watchdog,w)aswd:# 喂硬件看门狗wd.write(1)else:# 不喂狗看门狗超时将触发重启同时记日志便于排查print(health check failed,flushTrue)核心思想用一次真实的链路探活作为活没活着、干没干活的判据活着就喂狗异常就让它触发恢复。6.4 资源监控采集脚本#!/bin/bash# monitor.sh —— 定期采集关键指标追加到日志配合 cron/systemd timer 运行TS$(date%Y-%m-%d %H:%M:%S)CPU$(top-bn1|awk/Cpu\(s\)/{print $2})MEM$(free-m|awk/Mem:/{printf %d/%dMB, $3, $2})TEMP$(cat/sys/class/thermal/thermal_zone0/temp2/dev/null|awk{printf %.1fC, $1/1000})DISK$(df-h/|awkNR2{print $4 free})echo$TScpu$CPU% mem$MEMtemp$TEMPdisk$DISK/var/log/caption/metrics.logCPU、内存、温度、存储四条线长期记录后就能看出趋势——内存是否缓慢爬升、温度是否逼近降频、磁盘是否在被蚕食。6.5 OTA 升级脚本骨架#!/bin/bash# ota_update.sh —— 应用 OTA 骨架系统级请配合 A/B 分区方案set-ePKG$1# 升级包路径BACKUP/home/aidlux/caption.bakAPP/home/aidlux/caption sha256sum-c$PKG.sha256# 1) 校验升级包完整性cp-r$APP$BACKUP# 2) 备份当前版本systemctl stop caption# 3) 停服务tar-xf$PKG-C$APP# 4) 部署新版本systemctl start caption# 5) 起服务sleep10if!systemctl is-active--quietcaption;then# 6) 起不来则回滚rm-rf$APP;mv$BACKUP$APPsystemctl start captionecho升级失败已回滚;exit1fiecho升级成功骨架覆盖升级的关键环节校验 → 备份 → 停 → 部署 → 起 → 验证 → 失败回滚。真实 OTA 还会加灰度、版本上报、断点续传但能校验、能备份、能回滚是不可省的三件事。6.7 用 systemd timer 跑定时任务监控采集6.4、日志清理、定期健康上报这类定时干一次的活别再用 cron 散养交给systemd timer统一管理。一个.timer单元配一个.service声明多久跑一次# /etc/systemd/system/monitor.timer [Timer] OnBootSec2min # 开机2分钟后首次 OnUnitActiveSec60s # 之后每60秒一次 [Install] WantedBytimers.targetsystemctl enable --now monitor.timer即可生效。比起 crontimer 的好处是与 systemd 生态统一——能查日志、能管依赖、能控制失败行为定时任务也纳入了可观测、可管理的体系而不是一堆没人记得的 crontab 条目。七、坑点7.1 SD 卡寿命与频繁写很多端侧设备用 SD 卡或 eMMC 存储它们有写入寿命。日志、监控数据、临时文件如果高频小量地写会慢慢磨死存储导致设备数月后莫名其妙挂掉。对策日志轮转限量3.2、监控数据降频与压缩、高频临时数据放内存盘tmpfs、只读分区保护系统。把写存储当成一种要省着用的资源是端侧量产和服务器开发很大的不同。7.2 断电与文件系统损坏现场设备随时可能被直接断电正在写盘时断电容易导致文件系统损坏、甚至开不了机。对策关键数据写入后fsync落盘、用日志型文件系统、系统分区只读 数据分区独立、升级过程设计成断电可恢复A/B 分区天然具备。别假设设备会被优雅关机——量产要按随时被拔电来设计。7.3 高温降频与散热端侧 AI 持续跑 NPU/CPU 会发热温度一高芯片自动降频性能骤降识别变慢、帧率掉严重还会触发过热保护重启。对策监控温度6.4、保证散热散热片/风道/外壳开孔、性能压测要在目标环境温度下做实验室 25℃ 通过不代表车间 45℃ 能过、必要时给负载限功耗。温度问题只在连续高负载 真实环境下暴露所以烤机8.1必须模拟现场温度。7.4 升级变砖与恢复升级中断断电、包损坏、空间不足可能让设备起不来俗称变砖。对策升级包完整性校验6.5、留足存储空间、用 A/B 分区保证至少有一个能启动的系统、预留 recovery 通道如串口/U 盘恢复。变砖是量产升级最严重的事故必须在方案层面杜绝而不是赌它不发生。7.5 系统时间不同步很多端侧设备没有 RTC 电池断电后系统时间会错乱导致日志时间戳不可信、证书校验失败、定时任务错乱。对策有网络就配 NTP 自动对时离线场景要么加 RTC 电池要么在应用层对时间可能不准做容错。时间看着是小事乱起来会让排障和日志分析寸步难行。7.6 数据与隐私合规量产绕不开的一环端侧 AI 设备采的是真实世界的数据——人脸、语音、行为量产就绕不开数据合规。几个要点一是最小化采集——只采业务必需的数据能不存就不存二是本地优先——端侧的一大优势就是数据可不出设备尽量本地处理、本地留存、少上传三是存储安全——必须留存的数据要加密、定期清理别在设备上无限堆积敏感数据四是告知与授权——涉及个人信息尤其人脸、语音要有合规的告知与授权机制。合规不是产品做完再补的补丁而是设计期就要考虑的约束——尤其当设备要进入政企、医疗、教育这类强合规场景时这一条可能直接决定能不能落地。八、验证量产前验收8.1 长时间烤机最重要的验收是烤机让设备在目标负载、目标环境温度下连续运行至少 72 小时关键设备更久期间盯死三件事——功能是否一直正常、内存是否持续爬升爬升泄漏、温度是否稳定在安全线内。烤机能暴露几乎所有跑一下没事、跑久了出事的问题内存泄漏、过热、存储磨损、句柄泄漏。没过烤机的设备谈不上量产。8.2 断电重启恢复模拟现场断电在应用运行中直接断电再上电验证设备能自动起来、应用能自动拉起、数据没损坏、功能正常。反复做几次。这项验收直接对应 2.2 的自启、7.2 的断电可靠性——只有扛住断电-上电循环的设备才配装到无人值守的现场。8.3 升级 / 回滚演练交付前完整演练升级与回滚5.4推一个新版本验证能升上去再制造一次失败验证能退回来。两项都通过OTA 才算可信。演练要覆盖升级中断电这种极端情况确认 A/B 分区或回滚机制能兜住。8.4 量产检查清单把本讲落成一份交付前 checklist逐项打勾才算完应用已注册为 systemd 服务开机自启断电重启后能自动拉起崩溃自愈与重启频率限制已配置看门狗已生效日志分级落盘logrotate 轮转已配置磁盘不会被撑爆CPU/内存/温度/存储监控在跑异常能告警所有交付物应用/模型/配置/镜像版本清晰可查OTA 升级与回滚已演练通过升级包有完整性校验72 小时烤机通过功能正常、无内存泄漏、温度达标断电-上电循环测试通过无文件系统损坏系统时间同步方案已落实NTP 或 RTC 容错这份清单和第 11 讲的联调清单接成一条线联调清单管拼得对不对这份清单管交得出去、活得下去。8.5 量产交付物清单交付不是只给一块能跑的板子而是一套可维护的交付物。一份完整的端侧 AI 交付应包含可运行系统烧好镜像、配好自启的设备安装部署文档新板子如何复现环境版本清单应用/模型/配置/镜像各是什么版本运维手册怎么看日志、怎么重启、常见告警怎么处理升级与回滚流程OTA 怎么操作、出问题怎么退验收报告烤机、断电、升级演练的结果。很多团队只交付了第一项结果客户一出问题就只能找回原厂——把后面几项也交付了产品才算真正交得出去客户才有自己运维的能力。8.6 量产验收报告模板验收别停留在感觉没问题要落成一份可签字的报告。模板要点测试项烤机 / 断电 / 升级 / 回滚 / 功能×预期标准如72h 无重启、内存涨幅 5%、温度 阈值×实测结果×是否通过×备注。逐项填实测数据而不是只打勾。这份报告一方面是你内部能否交付的判据另一方面交付给客户时是这台设备经过了哪些考验的凭证。把验收从口头承诺变成白纸黑字的数据量产的专业度就体现在这里。8.7 量产常见故障速查表把量产期的高发故障归成一张速查表运维可照表初判“设备起不来” → 镜像损坏 / 断电变砖7.2、7.4“跑着跑着变慢” → 高温降频或内存泄漏7.3、8.1“用到某天突然挂” → 存储写满或写死7.1、3.2“升级后不开机” → 升级中断、需回滚7.4、4.4“日志时间全乱” → RTC/NTP 失效7.5“服务反复重启” → 配置错误或资源超限2.3、2.6。现场问题大多能对上这几类先照表定位方向再翻对应章节深挖。九、FAQQ1为什么一定要 systemd写个开机脚本不行吗开机脚本只能启动一次管不了崩溃自愈、依赖顺序、日志重定向、资源限制。systemd 是 Linux 标准的进程管家这些能力开箱即用。量产别重复造轮子用 systemd。Q2Restart 设成 always 会有什么后果如果应用因配置错误起不来always会让它无限疯狂重启、刷爆日志。要配RestartSec和StartLimitBurst做频率限制并区分可恢复崩溃和致命错误——后者要告警而不是重启。Q3没有 RTC 电池的设备时间怎么保证有网就 NTP 对时纯离线就接受时间不准并在应用层容错如用相对时间、单调时钟或硬件上加 RTC。关键是别让时间错乱悄悄污染日志和定时任务。Q4SD 卡设备还能跑 7×24 吗能但要善待存储日志轮转限量、高频写放 tmpfs、监控数据降频压缩、选工业级高耐久卡。把写次数当资源省着用SD 卡设备也能长期稳定。Q5A/B 分区具体怎么实现依赖 Bootloader 与分区表设计划两个系统分区当前从 A 启动升级写到 B 并校验重启试从 B 启动成功则固化、失败则回 A。具体实现随平台U-Boot 等而定以设备/AidLux 的 OTA 方案为准。Q6烤机要烤多久至少 72 小时连续满载关键设备建议一到两周且要在目标环境温度下烤。时间不够内存泄漏、过热、存储磨损这类慢性病暴露不出来。Q7模型可以远程更新吗要注意什么可以且是高频需求。注意先在第 11 讲的回归基线上验证新模型没变糟、再小范围灰度、最后全量模型文件大升级包要校验完整性、支持失败回滚。Q8监控告警会不会太多变成噪音会如果什么都告警。只对需要人介入的事告警连续重启失败、温度越限、存储将满、服务长时间不可用普通的波动只记录不告警。告警的信噪比比数量重要。Q9多设备怎么统一管理设备量上来后要设备管理平台批量 OTA、批量配置、集中监控、分组灰度。自建或用现成方案均可核心是把单台设备的量产能力乘以一个管理平台变成批量能力。这是量产规模化的下一步。Q10到这里我还缺什么才能独立交付一个端侧 AI 产品技术上你已具备全链路能力从融合系统、推理、视觉、大模型、语音、跨系统通信到多组件集成与本讲的量产工程。剩下的是项目经验——在真实业务里把这套方法反复用、踩坑、沉淀。方法论你都拿到了接下来就是去找一个真场景把它做成。十、结论这一讲我们走完了从能跑到能交付的最后一公里用 systemd 给应用上了户口、配上崩溃自愈与看门狗用规范日志、轮转与监控让它可观测用带校验、备份、回滚的 OTA 让它可升级、不赌博并直面了 SD 卡寿命、断电、高温这些只有真到量产才会撞上的硬件现实。最后一份烤机 断电恢复 升级演练 检查清单的验收组合给了你交付前的底气。把镜头拉到最远回顾这十二讲走过的路我们从一块板子和一套融合系统出发01搭起推理底座02、打通多框架迁移03、解决模型供给与量化04做出视觉05、视频06两条感知线再把大模型搬上端侧07、服务化08打通跨系统通信09、装上语音10最后把所有零件装配成端到端应用11、并把它做成能 7×24 交付的产品12。从认识一块板到交付一个产品这条从融合系统到端侧大模型、从单组件到多组件、从 Demo 到量产的完整链路你已经全部走过。工具链的每个组件你都能查文档学会但这条怎么把能力一步步做成产品的主线是文档不会直接告诉你的。希望这十二讲给你的不只是 AidLux 各个组件的用法更是一套端侧 AI 工程化的思维方式——先认清工具的真实边界再把单点做扎实然后编排成系统最后工程化成产品。这四步与具体用哪家的工具链无关是任何端侧 AI 项目从想法走到落地都绕不开的路径组件会更新换代但这套从单点到系统再到产品的方法论会长期管用。带上它去把你自己的端侧 AI 想法做成真正能跑、能交付、能长期服役的东西吧。本文 systemd、logrotate、看门狗、A/B 分区、NTP 等为 Linux 端侧设备通用量产方法在 AidLux 环境落地时的具体命令、服务名、OTA 方案以官方文档与设备方案为准烤机时长、温度阈值、存储寿命等随硬件与场景而异以真机实测为准。文中配置与脚本为结构示意投产前请按实际环境调整。