第 12 讲：阿加犀 AidLux 部署与量产——把端侧 AI 应用做成 7×24 产品

本篇速览

• 开发态和量产态是两种东西：开发态追求"能跑通"，量产态追求"没人盯着也能长期稳定跑"。把前者直接当后者，是端侧项目翻车最常见的根源。
• 量产要管好五件事：进程守护 （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 里配 Restart=on-failure，进程异常退出它会自动拉起。但重启策略要讲究，不能无脑无限重启------如果应用是因为配置错误"起不来"，无限重启只会疯狂刷日志。工程上常用：Restart=on-failure + RestartSec=5（等 5 秒再起，避免瞬间反复）+ 启动频率限制（一段时间内重启太多次就放弃并报警）。还要区分"可恢复的崩溃"（重启能解决，如偶发内存错误）和"不可恢复的错误"（重启也白搭，如模型文件缺失），前者靠自愈，后者要报警让人介入。

2.4 多组件的启动依赖编排

第 11 讲的系统有多个组件，启动有先后：AidGenSE 服务要先起来，编排器才能连；通道要先建连，结果才能发。systemd 用 After= 和 Requires=/Wants= 表达这种依赖------比如编排器的 unit 声明 After=aidgense.service，确保大模型服务先就绪。把启动依赖显式声明出来，系统重启时各组件就能按正确顺序自动拉起，而不是"谁抢到谁先起、起来发现依赖没好又崩"。这正是把第 11 讲 7.4"依赖顺序"问题在系统层面固化解决。

2.5 看门狗：最后的保险

systemd 能管"进程死了重启"，但管不了"进程活着却卡死"（比如死锁、无限等待）。这种"假活"要靠看门狗（watchdog） ：应用定期"喂狗"（发送心跳），看门狗超时没收到心跳就强制重启进程（甚至重启系统）。对 7×24 的端侧设备，看门狗是防"卡死无人发现"的最后保险。实现上，硬件看门狗（/dev/watchdog）或软件看门狗均可，核心思想一致：用一条独立的心跳，证明应用"不仅在、而且在正常干活"。

2.6 资源限制：用 cgroup 给应用上"笼子"

多组件共用一块板子，要防"一个组件失控吃光资源、拖死全局"。Linux 的 cgroup 能给进程限制 CPU、内存上限，在 systemd 的 unit 里直接配：MemoryMax=1G（内存超限就 OOM 重启它，而不是拖垮整机）、CPUQuota=150%（限制 CPU 用量）。给大模型这类"资源大户"设上限尤其重要------宁可它自己被限流重启，也不能让它把视频采集、系统进程饿死。资源隔离的思想和看门狗互补：看门狗管"它活着没"，cgroup 管"它别太过分"。给关键服务都配上资源上限，整机稳定性就上一个台阶。

2.7 最小权限：别用 root 跑你的应用

开发时图省事常用 root 跑应用，量产要改过来------最小权限原则 ：给应用建一个专用用户（如 aidlux），只授予它必需的权限（访问摄像头、音频、自己的目录），其余一律不给。unit 里的 User=aidlux 就是干这个的。好处有二：一是安全 ------应用即使有漏洞被利用，能破坏的也仅限它那一亩三分地，动不了系统；二是稳定 ------应用误操作（比如删错文件）时，权限受限能挡住很多"自杀式"事故。配合 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 的监控数据存成时间序列，出问题先看"故障前的指标趋势"（内存是不是一直在涨、温度是不是先飙了）；三是现场保留 ------异常时自动抓一份"现场"（最近的日志、当前指标、核心转储），别等设备一重启把证据冲掉；四是分级响应------能远程重启服务解决的别动系统，能远程解决的别派人跑现场。把诊断能力建在交付之前，出问题才不至于两眼一抹黑。

四、版本与升级（OTA）

4.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.1），systemctl enable 让应用开机自启，配上重启策略与启动依赖。然后重启设备验证：断电再上电，看应用是否自动起来、各组件是否按序就绪、功能是否正常。能扛住"重启"这关，才算真正脱离了"手动启动"。

5.3 接通日志与监控

配上日志规范与 logrotate（6.2）、跑起资源监控采集（6.3、6.4）、设好告警。验证：让应用跑一会儿，看日志是否按规范落盘、轮转是否生效、指标是否在采集、触发一次告警看能否收到。

5.4 做一次升级与回滚演练

别等真升级才第一次走流程。交付前完整演练一次：推送一个（哪怕是改了版本号的）新版本，走完整的 OTA 流程，验证升级成功；再故意制造一次"升级失败"，验证能正确回滚到旧版本。演练过的升级流程才可信------没在交付前演练过的 OTA，第一次真用时大概率出状况。

5.5 量产镜像：把"调好的系统"做成可批量烧录的母盘

当要部署的不是一台、而是一批设备，逐台手动配置就不现实了。做法是做母盘（量产镜像）：把一台设备从系统到应用、配置、模型全部调好、验收通过，再把它的系统整体做成镜像，批量烧录到其他设备。要点：镜像里把"与具体设备无关"的部分都预置好（应用、服务、配置模板、模型），把"逐台不同"的部分（设备编号、网络参数、密钥）留到首次启动时初始化。烧录后每台设备首次上电跑一个初始化脚本，写入自己的身份信息，即可直接投入使用。母盘 + 首启初始化，是从"做一台"到"做一批"的关键一跃，也是量产规模化的起点。

六、关键配置与脚本

6.1 systemd unit 示例

# /etc/systemd/system/caption.service
[Unit]
Description=Smart Camera Caption Service
After=network.target aidgense.service      # 依赖：网络与大模型服务先就绪
Wants=aidgense.service

[Service]
Type=simple
User=aidlux
WorkingDirectory=/home/aidlux/caption
Environment=CONFIG_PATH=/home/aidlux/caption/config.yaml
ExecStart=/usr/bin/python3 /home/aidlux/caption/orchestrator.py
Restart=on-failure                          # 崩溃自愈
RestartSec=5                                # 每次重启间隔5秒
StartLimitIntervalSec=300                   # 300秒内
StartLimitBurst=5                           # 最多重启5次，超过放弃
StandardOutput=append:/var/log/caption/app.log
StandardError=append:/var/log/caption/app.log

[Install]
WantedBy=multi-user.target

systemctl 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 定时调用或内嵌进应用
import os, time, requests

def app_alive():
    try:   # 探活大模型服务与应用关键链路
        r = requests.post("http://127.0.0.1:8888/v1/chat/completions",
                          json={"model": "qwen2.5-0.5b-instruct",
                                "messages": [{"role": "user", "content": "ping"}]},
                          timeout=10)
        return r.status_code == 200
    except Exception:
        return False

if app_alive():
    with open("/dev/watchdog", "w") as wd:   # 喂硬件看门狗
        wd.write("1")
else:
    # 不喂狗，看门狗超时将触发重启；同时记日志便于排查
    print("health check failed", flush=True)

核心思想：用一次真实的链路探活作为"活没活着、干没干活"的判据，活着就喂狗，异常就让它触发恢复。

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/temp 2>/dev/null | awk '{printf "%.1fC", $1/1000}')
DISK=$(df -h / | awk 'NR==2{print $4" free"}')
echo "$TS cpu=$CPU% mem=$MEM temp=$TEMP disk=$DISK" >> /var/log/caption/metrics.log

CPU、内存、温度、存储四条线，长期记录后就能看出趋势------内存是否缓慢爬升、温度是否逼近降频、磁盘是否在被蚕食。

6.5 OTA 升级脚本骨架

#!/bin/bash
# ota_update.sh ------ 应用 OTA 骨架（系统级请配合 A/B 分区方案）
set -e
PKG=$1                      # 升级包路径
BACKUP=/home/aidlux/caption.bak
APP=/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) 起服务
sleep 10
if ! systemctl is-active --quiet caption; then   # 6) 起不来则回滚
    rm -rf "$APP"; mv "$BACKUP" "$APP"
    systemctl start caption
    echo "升级失败，已回滚"; exit 1
fi
echo "升级成功"

骨架覆盖升级的关键环节：校验 → 备份 → 停 → 部署 → 起 → 验证 → 失败回滚。真实 OTA 还会加灰度、版本上报、断点续传，但"能校验、能备份、能回滚"是不可省的三件事。

6.7 用 systemd timer 跑定时任务

监控采集（6.4）、日志清理、定期健康上报这类"定时干一次"的活，别再用 cron 散养，交给 systemd timer 统一管理。一个 .timer 单元配一个 .service，声明"多久跑一次"：

# /etc/systemd/system/monitor.timer
[Timer]
OnBootSec=2min          # 开机2分钟后首次
OnUnitActiveSec=60s     # 之后每60秒一次

[Install]
WantedBy=timers.target

systemctl enable --now monitor.timer 即可生效。比起 cron，timer 的好处是与 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）。现场问题大多能对上这几类，先照表定位方向，再翻对应章节深挖。

九、FAQ

Q1：为什么一定要 systemd，写个开机脚本不行吗？

开机脚本只能"启动一次"，管不了崩溃自愈、依赖顺序、日志重定向、资源限制。systemd 是 Linux 标准的进程管家，这些能力开箱即用。量产别重复造轮子，用 systemd。

Q2：Restart 设成 always 会有什么后果？

如果应用因配置错误"起不来"，always 会让它无限疯狂重启、刷爆日志。要配 RestartSec 和 StartLimitBurst 做频率限制，并区分"可恢复崩溃"和"致命错误"------后者要告警而不是重启。

Q3：没有 RTC 电池的设备时间怎么保证？

有网就 NTP 对时；纯离线就接受时间不准并在应用层容错（如用相对时间、单调时钟），或硬件上加 RTC。关键是别让"时间错乱"悄悄污染日志和定时任务。

Q4：SD 卡设备还能跑 7×24 吗？

能，但要善待存储：日志轮转限量、高频写放 tmpfs、监控数据降频压缩、选工业级高耐久卡。把"写次数"当资源省着用，SD 卡设备也能长期稳定。

Q5：A/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 方案以官方文档与设备方案为准；烤机时长、温度阈值、存储寿命等随硬件与场景而异，以真机实测为准。文中配置与脚本为结构示意，投产前请按实际环境调整。