企业官网建设流程全解析

1. 边缘AI工作负载的选型逻辑与整体设计

1.1 为什么要在单板计算机上跑三类模型

把CNN、VLM和SLM这三类模型放在同一台Raspberry Pi 5上跑，这个思路本身就值得聊一聊。很多人第一次听到这个组合的反应是"疯了吧"，毕竟Pi 5的算力放在那里，CPU是四核Cortex-A76，主频2.4GHz，内存最大8GB LPDDR4X，没有独立GPU，只有VideoCore VII负责图形和部分加速。但实际做下来你会发现，这三类模型恰好代表了边缘侧最常见的三种智能需求，而且它们的资源画像完全不同，组合在一起反而能形成互补。

CNN负责的是感知层的任务，比如图像分类、目标检测、人脸识别这类。它的特点是模型相对小、推理速度快、对内存带宽要求高但对内存容量要求低。一个量化后的MobileNetV3或者YOLOv8n，模型文件也就几MB到十几MB，推理一次几十毫秒。这类负载在Pi 5上跑起来是最成熟的，各种推理框架都有现成的优化。

VLM也就是视觉语言模型，负责的是理解层的任务。你给它一张图加一段文字提问，它能告诉你图里发生了什么、某个物体是什么颜色、场景里有没有异常。这类模型参数量通常在几亿到几十亿之间，即使量化后也需要几百MB到几GB的内存。在Pi 5上跑VLM是这三类里最吃力的，但也不是完全跑不动，关键看你怎么选模型和怎么量化。

SLM是小语言模型，负责的是交互层的任务。用户用自然语言提问，SLM负责理解意图、组织回答、做简单的推理和总结。参数量通常在1B到7B之间，量化后可以压到几百MB到2GB左右。Pi 5的8GB版本跑一个量化后的3B模型是可行的，但速度不会太快，大概每秒几个token的水平。

这三者组合起来的逻辑是：CNN做实时感知，发现"有东西出现了"；VLM做深度理解，回答"这东西是什么、什么状态"；SLM做自然交互，处理"用户想知道什么、怎么回答"。这是一个完整的边缘智能闭环，从看到、看懂到说清楚。

1.2 低功耗约束下的方案取舍

"低功耗"这三个字是整个项目的核心约束。Pi 5的官方功耗标称是5V/5A，也就是25W满血，但实际跑AI负载时你不可能让它一直满血。我的实测数据是：空载约3W，跑CNN推理约5-7W，跑VLM推理约8-12W，跑SLM生成约7-10W。如果三个同时跑，峰值能到15W以上，这时候Pi 5的散热就成了大问题，不加主动散热会直接降频。

所以方案设计的第一个原则就是分时复用，而不是三个模型同时常驻内存同时跑。具体做法是：CNN常驻，因为它小且快，随时待命做触发检测；VLM和SLM按需加载，用完就释放或者切换到低功耗待机状态。这样峰值功耗可以控制在10W以内，配合一个普通的铝制散热片加小风扇就能稳住。

第二个原则是量化优先。所有模型都必须做量化，CNN用INT8，VLM和SLM用INT4或者INT8。量化带来的精度损失在边缘场景下通常可以接受，但换来的内存占用和功耗下降是实实在在的。以SLM为例，一个3B模型FP16需要6GB内存，INT4量化后只要1.5GB左右，这个差距直接决定了能不能在8GB的Pi 5上跑起来。

第三个原则是模型选型要克制。不要想着在Pi 5上跑7B甚至更大的模型，那是跟自己过不去。CNN选MobileNet系列或者YOLO nano系列，VLM选参数量在1B以下的轻量版本，SLM选1B到3B之间的量化版本。这个选型范围是经过实测验证的，再大就会频繁触发内存交换，速度会掉到不可用的程度。

1.3 整体架构与数据流设计

整个系统的架构可以分成三层：感知层、理解层、交互层。感知层由CNN负责，持续或者定时从摄像头抓帧做推理，输出检测结果。理解层由VLM负责，当CNN检测到需要深入分析的画面时，把对应的图像帧和预设的问题一起送给VLM，得到结构化的描述。交互层由SLM负责，接收用户的自然语言输入，结合VLM的输出和CNN的检测结果，生成最终的回答。

数据流是这样的：摄像头采集图像 -> CNN推理 -> 如果检测到目标则触发VLM -> VLM生成描述 -> 结果存入一个轻量级的上下文缓存 -> 用户提问时SLM读取缓存并生成回答。整个流程中，CNN是常驻的，VLM和SLM是按需调用的。为了进一步省电，CNN的推理频率可以动态调整，比如没有检测到目标时每秒跑2帧，检测到目标后提升到每秒10帧。

这个架构的关键在于触发机制的设计。如果CNN每帧都触发VLM，那功耗和延迟都会爆炸。我的做法是设置一个置信度阈值和冷却时间：只有当检测置信度超过0.7且距离上次VLM调用超过5秒时，才触发一次VLM推理。这样既保证了响应的及时性，又避免了频繁调用带来的功耗浪费。

2. 核心细节解析与实操要点

2.1 CNN模型的选择与量化部署

在Pi 5上跑CNN，我的首选是YOLOv8n或者YOLOv5n，这两个模型在COCO数据集上的mAP都在0.25-0.28之间，对于边缘场景的粗检测足够用了。模型文件大小在6MB左右，INT8量化后可以压到3MB出头。推理框架用ONNX Runtime或者NCNN，这两个在ARM平台上的优化都比较成熟。

量化过程我用的是ONNX Runtime的静态量化工具。具体步骤是：先准备一个校准数据集，大概200-500张代表性图片就够了，然后用onnxruntime.quantization.quantize_static做INT8量化。校准数据集的选择很关键，要覆盖你实际场景中可能出现的各种光照、角度、背景。我试过用随机图片做校准，结果量化后的模型在暗光环境下漏检率明显上升，换成实际场景的图片后就好了。

部署时的参数配置有几个要点。首先是输入尺寸，YOLOv8n默认是640x640，但在Pi 5上跑这个尺寸的推理一次大概要80-120ms。如果对实时性要求不高，可以降到416x416或者320x320，速度能提升到30-50ms，精度损失在可接受范围内。其次是线程数，ONNX Runtime默认会用满所有核心，但这样会导致CPU温度快速上升触发降频。我的做法是限制到2个线程，速度只慢20%左右，但温度能低10度以上。

import onnxruntime as ort import numpy as np # 配置推理会话 options = ort.SessionOptions() options.intra_op_num_threads = 2 options.inter_op_num_threads = 1 options.graph_optimization_level = ort.GraphOptimizationLevel.ORT_ENABLE_ALL session = ort.InferenceSession("yolov8n_int8.onnx", options, providers=['CPUExecutionProvider']) # 推理 input_name = session.get_inputs()[0].name frame = preprocess(image, size=416) # 预处理到416x416 outputs = session.run(None, {input_name: frame})

注意：量化后的模型第一次推理会有一个预热过程，大概需要跑3-5次才能达到稳定速度。所以在实际部署时，启动后先跑几次空推理做预热，避免第一次真实请求时延迟过高。

2.2 VLM的轻量化策略与内存管理

VLM在Pi 5上跑，模型选择是第一道坎。我试过几个方案：LLaVA-1.5的7B版本量化后也要4GB多内存，跑起来非常吃力；后来换成了参数量更小的轻量VLM，比如基于SigLIP加小语言模型的组合，整体参数量控制在1B以内，INT4量化后内存占用在600MB左右，这个就舒服多了。

VLM的推理流程比CNN复杂得多，它要同时处理图像编码和文本生成。图像编码部分通常是一个ViT或者类似的视觉编码器，这部分计算量相对固定；文本生成部分是自回归的，每生成一个token都要跑一次前向传播。在Pi 5上，图像编码大概需要200-400ms，文本生成每个token需要50-100ms。生成一段20个token的描述，总共需要1.5-2.5秒。这个速度对于非实时场景是可以接受的。

内存管理是VLM部署的关键。Pi 5的8GB内存看着不少，但系统本身要占1GB左右，CNN常驻占几百MB，留给VLM的空间大概有5-6GB。如果VLM加载后不释放，SLM就没法加载了。我的做法是用一个简单的内存池管理：VLM和SLM共享一块内存区域，需要哪个就加载哪个，切换时把另一个的权重换出到SD卡上的交换文件。虽然切换有延迟（大概2-3秒），但保证了两个模型都能跑起来。

import psutil import gc def load_vlm_model(model_path): # 检查可用内存 available = psutil.virtual_memory().available / (1024**3) if available < 2.0: # 少于2GB可用内存 unload_slm_model() # 先卸载SLM gc.collect() # 加载VLM模型 model = load_quantized_model(model_path) return model def unload_slm_model(): global slm_model if slm_model is not None: del slm_model slm_model = None gc.collect()

提示：Pi 5的SD卡读写速度对模型切换影响很大。如果用普通SD卡，加载一个600MB的模型要10秒以上。建议用USB 3.0的固态硬盘或者NVMe扩展板，加载时间能缩短到2-3秒。

2.3 SLM的推理优化与交互设计

SLM我选的是参数量在1B到3B之间的模型，量化到INT4后内存占用在500MB到1.5GB之间。推理框架用llama.cpp的ARM优化版本，它对NEON指令集的支持比较好，在Pi 5上跑3B模型大概能到每秒4-6个token。这个速度对于简单的问答交互是够用的，但别指望它能流畅地写长文章。

SLM的推理优化有几个关键点。第一是上下文长度要控制，默认的2048或者4096上下文会占用大量内存做KV Cache。在Pi 5上我建议把上下文限制在512到1024之间，这样KV Cache的内存占用能控制在100MB以内。第二是批处理大小设为1，边缘场景不需要批处理，设大了反而浪费内存。第三是启用mmap加载，这样模型权重不用全部读进内存，按需分页加载，能省不少内存。

# llama.cpp 推理参数示例 ./main -m models/slm-3b-q4.gguf \ -n 128 \ # 最多生成128个token -c 512 \ # 上下文长度512 -b 1 \ # 批大小1 --mlock \ # 锁定内存防止交换 -t 2 \ # 使用2个线程 --temp 0.7 \ # 温度参数 -p "用户问题"

交互设计上，SLM的提示词工程很重要。因为模型小，它对提示词的格式很敏感。我的做法是设计一个固定的模板，把CNN的检测结果、VLM的描述、用户的问题按固定格式拼接，这样SLM的输出稳定性会好很多。模板大概是这样的：

[系统] 你是一个边缘智能助手。当前检测到：{cnn_results}。场景描述：{vlm_description}。 [用户] {user_question} [助手]

注意：小模型很容易产生幻觉，尤其是在没有明确上下文的时候。所以每次调用SLM之前，一定要把CNN和VLM的结果作为上下文传进去，让它的回答有据可依。我试过不给上下文直接问，它经常编造不存在的东西。

3. 实操过程与核心环节实现

3.1 系统环境准备与依赖安装

Pi 5的系统我推荐用64位的Raspberry Pi OS Bookworm，内核版本6.1以上，对ARMv8.2指令集的支持比较完整。装好系统后第一件事是更新固件和内核，然后调整GPU内存分配。Pi 5的GPU内存默认是76MB，跑AI负载不需要太多GPU内存，但如果你要用摄像头做图像采集，建议调到128MB。

# 更新系统 sudo apt update && sudo apt full-upgrade -y # 调整GPU内存（在/boot/firmware/config.txt中） # 添加或修改：gpu_mem=128 # 安装基础依赖 sudo apt install -y python3-pip python3-venv cmake build-essential \ libopenblas-dev libomp-dev libjpeg-dev libpng-dev # 创建虚拟环境 python3 -m venv ~/ai-env source ~/ai-env/bin/activate # 安装推理框架 pip install onnxruntime numpy opencv-python-headless

散热是必须提前考虑的。我一开始用被动散热片，跑CNN推理10分钟后CPU温度就到85度开始降频了。后来换了一个带小风扇的主动散热器，温度稳定在60-65度，性能输出稳定多了。如果你打算长时间跑AI负载，主动散热是刚需，别省这个钱。

电源也要注意。Pi 5官方推荐5V/5A的电源，如果你用普通的5V/3A电源，跑AI负载时可能会因为供电不足导致系统不稳定。我实测过，用3A电源跑VLM推理时，系统会随机重启，换成5A电源后就没事了。

3.2 CNN推理服务的搭建与调优

CNN推理服务我封装成了一个简单的HTTP服务，用Flask或者FastAPI都行。服务启动时加载模型并预热，然后监听请求。每个请求进来后做预处理、推理、后处理，返回检测结果。为了省电，我加了一个空闲检测机制：如果连续30秒没有请求，就把推理线程挂起，CPU占用降到接近零。

from fastapi import FastAPI import uvicorn import threading import time app = FastAPI() last_request_time = time.time() model = None @app.on_event("startup") async def startup(): global model model = load_cnn_model("yolov8n_int8.onnx") # 预热 for _ in range(5): dummy = np.random.randn(1, 3, 416, 416).astype(np.float32) model.run(dummy) @app.post("/detect") async def detect(image_data: bytes): global last_request_time last_request_time = time.time() # 预处理 frame = preprocess(image_data) # 推理 outputs = model.run(frame) # 后处理 detections = postprocess(outputs) return {"detections": detections} # 空闲检测线程 def idle_monitor(): while True: if time.time() - last_request_time > 30: # 挂起推理线程，降低功耗 time.sleep(1) time.sleep(0.1) threading.Thread(target=idle_monitor, daemon=True).start()

调优方面，我做了几组对比测试。输入尺寸从640降到416，推理时间从110ms降到45ms，mAP从0.28降到0.24。线程数从4降到2，推理时间从45ms升到55ms，但CPU温度从78度降到62度。综合下来，416输入加2线程是最佳平衡点。

后处理部分也有优化空间。YOLO的输出是8400个候选框，做NMS（非极大值抑制）的时候如果全量计算会比较慢。我的做法是先按置信度过滤掉低于0.3的框，剩下的再做NMS，这样后处理时间能从15ms降到5ms以内。

3.3 VLM的按需加载与推理流程

VLM的加载我设计成按需触发。CNN检测到目标后，把对应的图像帧存到一个队列里，VLM服务从队列取帧做推理。为了避免频繁加载卸载，VLM服务启动后就常驻，但推理线程在没有任务时处于休眠状态。

import queue import threading vlm_queue = queue.Queue(maxsize=5) vlm_model = None def vlm_worker(): global vlm_model while True: try: frame, question = vlm_queue.get(timeout=1) except queue.Empty: continue # 确保模型已加载 if vlm_model is None: vlm_model = load_vlm_model("vlm-1b-q4.onnx") # 图像编码 image_features = vlm_model.encode_image(frame) # 文本生成 description = vlm_model.generate(image_features, question, max_tokens=30) # 存入上下文缓存 context_cache.append({ "timestamp": time.time(), "description": description }) vlm_queue.task_done() threading.Thread(target=vlm_worker, daemon=True).start()

VLM推理的延迟主要花在图像编码上。我试过把图像分辨率从336x336降到224x224，编码时间从350ms降到180ms，但描述质量下降明显，一些细节就看不到了。最后折中用了288x288，编码时间250ms左右，质量还能接受。

文本生成部分，max_tokens设成30是一个经验值。设太小描述不完整，设太大生成时间线性增长。30个token大概能生成两到三句话，对于"图里有什么、什么状态"这类问题够用了。生成温度设成0.3，让输出更确定、更聚焦，避免小模型发散。

3.4 SLM的交互实现与上下文管理

SLM的交互流程是这样的：用户通过一个简单的Web界面或者命令行输入问题，系统把问题、最近的CNN检测结果、最近的VLM描述拼成提示词，送给SLM生成回答。上下文缓存只保留最近5条记录，更早的丢弃，避免提示词过长。

def build_prompt(user_question): # 获取最近的检测结果 recent_detections = get_recent_detections(n=3) # 获取最近的VLM描述 recent_descriptions = get_recent_descriptions(n=2) prompt = f"""[系统] 你是一个边缘智能助手。最近的检测结果：{recent_detections}。 最近的场景描述：{recent_descriptions}。 请根据以上信息回答用户问题，如果信息不足请如实说明。 [用户] {user_question} [助手]""" return prompt def generate_response(user_question): prompt = build_prompt(user_question) # 调用SLM推理 response = slm_model.generate(prompt, max_tokens=128, temperature=0.7) return response

SLM的推理速度是交互体验的瓶颈。3B模型在Pi 5上每秒4-6个token，生成128个token需要20-30秒，这个等待时间太长了。我的优化是：第一，把max_tokens降到64，生成时间减半；第二，启用流式输出，生成一个token就显示一个，用户感知的等待时间会短很多；第三，对于简单问题，直接用规则引擎回答，不走SLM。

流式输出的实现用llama.cpp的streaming接口，每生成一个token就通过SSE推送给前端。这样用户看到文字一个个蹦出来，虽然总时间没变，但体验好很多。

实操心得：SLM的提示词里一定要加"如果信息不足请如实说明"这句话。不加的话，小模型会强行编造答案，加了之后它至少会说"根据当前信息无法判断"，这个体验反而更好。

4. 常见问题与排查技巧实录

4.1 内存不足与交换风暴的排查

内存不足是Pi 5跑AI负载最常见的问题。表现是系统突然变得极慢，SSH连接卡顿，推理时间从几十毫秒变成几秒。这时候用free -h看，会发现swap使用量飙升，这就是交换风暴。

排查思路是：先用ps aux --sort=-%mem看哪个进程占内存最多，确认是哪个模型的问题。然后检查是不是模型没有正确释放，比如VLM推理完后没有del掉中间变量。Python的垃圾回收有时候不及时，需要手动gc.collect()。

预防措施有几个：第一，给每个模型进程设置内存上限，用systemd的MemoryMax或者ulimit；第二，用zram做压缩内存交换，比SD卡交换快很多；第三，监控内存使用，超过阈值就主动卸载不常用的模型。

# 启用zram sudo apt install zram-tools # 编辑/etc/default/zramswap # 设置：ALGO=lz4，PERCENT=50 # 监控内存 watch -n 1 'free -h && echo "---" && ps aux --sort=-%mem | head -5'

4.2 推理速度突然下降的定位

推理速度突然下降通常有三个原因：CPU降频、内存交换、线程争抢。定位方法是先看CPU频率，cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq，如果低于1.5GHz就是降频了，检查温度cat /sys/class/thermal/thermal_zone0/temp，超过80度就是散热问题。

如果CPU频率正常但速度还是慢，就看内存。vmstat 1看si和so列，如果有持续的非零值就是内存交换。这时候要么减少模型内存占用，要么加zram。

线程争抢比较隐蔽，表现是CPU占用高但推理速度慢。用top -H看线程级别的CPU占用，如果多个推理线程在抢核心，就把线程数降下来。我遇到过CNN用4线程、VLM用4线程、SLM用4线程，三个一起跑的时候互相抢，总速度反而比各自用2线程慢。

4.3 模型量化后的精度损失评估

量化后的精度损失是必须评估的。CNN的评估相对简单，跑一个验证集看mAP下降多少。我的经验是INT8量化后mAP下降在1-3个百分点以内是可以接受的，超过5个点就要考虑是不是校准集有问题。

VLM和SLM的评估就麻烦一些，因为它们输出的是文本，没有明确的数值指标。我的做法是准备一组标准问题和参考答案，量化前后各跑一遍，人工对比输出的质量。重点关注的是：有没有出现重复生成、有没有明显的语法错误、事实性错误有没有增加。

如果精度损失太大，可以尝试混合量化：对精度敏感的层用INT8，其他层用INT4。ONNX Runtime和llama.cpp都支持这种混合量化配置，虽然配置麻烦一点，但效果比全INT4好很多。

4.4 常见问题速查表

避坑技巧：Pi 5的USB接口和WiFi模块共享带宽，如果你用USB摄像头同时跑WiFi传输，摄像头帧率会不稳定。解决办法是把摄像头接在USB 3.0接口上，WiFi用5GHz频段，减少干扰。

5. 功耗优化与散热实战

5.1 动态调频与功耗实测

Pi 5的CPU支持动态调频，默认的调速器是ondemand，会根据负载自动调整频率。但在AI推理场景下，ondemand的反应不够快，负载上来了频率还没升上去，导致推理时间波动大。我试过改成performance调速器，频率锁定在2.4GHz，推理速度稳定了，但空载功耗从3W升到了5W。

最后的方案是用conservative调速器，它的调频比ondemand保守，不会频繁升降频，功耗和性能的平衡比较好。另外可以手动设置频率上限，比如限制在2.0GHz，推理速度只慢10%左右，但功耗能降15%。

# 查看当前调速器 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor # 设置为conservative echo conservative | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor # 限制最大频率为2.0GHz echo 2000000 | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq

实测数据：空载3.2W，CNN推理5.8W，VLM推理9.5W，SLM推理8.2W。三个模型分时复用的情况下，平均功耗在6-7W之间。如果用5V/5A的电源，留足了余量。

5.2 散热方案对比与选择

散热方案我试过三种：纯被动散热片、散热片加小风扇、半导体主动制冷。纯被动散热片跑CNN推理10分钟后温度到85度降频，不行。散热片加小风扇温度稳定在60-65度，功耗增加0.5W左右，是最实用的方案。半导体主动制冷效果最好，温度能压到45度以下，但功耗增加3-4W，而且有冷凝水风险，不推荐。

风扇的选择也有讲究。Pi 5的官方风扇是PWM控制的，可以根据温度自动调速，噪音控制得不错。第三方的风扇便宜但噪音大，而且有些是常转的，不能调速。如果在意噪音，建议用官方风扇或者类似的PWM风扇。

散热硅脂也要注意。Pi 5的CPU和散热片之间如果不用硅脂，热阻会很大。我试过不用硅脂直接贴散热片，温度比用硅脂高8-10度。用普通的导热硅脂就行，不需要太贵的。

5.3 低功耗模式下的推理调度

为了进一步省电，我设计了一个简单的推理调度器。系统有三个功耗档位：空闲档、感知档、交互档。空闲档只跑CNN的低频检测（每秒1帧），功耗3-4W；感知档CNN全速跑（每秒10帧），VLM待命，功耗6-8W；交互档VLM和SLM都激活，功耗9-12W。

档位切换由事件驱动：CNN检测到目标进入感知档，用户提问进入交互档，30秒无事件回到空闲档。这样在大多数时间里系统都处于空闲档，平均功耗能控制在5W以内。

class PowerManager: def __init__(self): self.mode = "idle" self.last_event_time = time.time() def on_detection(self): self.mode = "perception" self.last_event_time = time.time() self.set_cnn_fps(10) def on_user_query(self): self.mode = "interaction" self.last_event_time = time.time() self.load_vlm_and_slm() def check_idle(self): if time.time() - self.last_event_time > 30: self.mode = "idle" self.set_cnn_fps(1) self.unload_vlm_and_slm()

这个调度器的效果很明显，平均功耗从8W降到了5W左右，而且响应延迟没有明显增加，因为档位切换只需要几百毫秒。

6. 实际部署中的经验与建议

6.1 模型文件的管理与版本控制

跑久了你会发现模型文件的管理是个麻烦事。不同版本的量化模型、不同的校准集、不同的推理框架，文件散落在各处，时间长了根本记不住哪个是哪个。我的做法是用一个简单的目录结构加一个manifest文件来管理。

目录结构按模型类型分：models/cnn/、models/vlm/、models/slm/，每个模型一个子目录，里面放模型文件、配置文件、校准数据。manifest文件用YAML格式，记录每个模型的来源、量化参数、评估指标、部署日期。这样换模型或者回滚版本的时候一目了然。

# models/manifest.yaml cnn: yolov8n_int8: path: cnn/yolov8n_int8.onnx input_size: 416 quant_type: int8 map: 0.24 date: 2024-01-15 vlm: vlm_1b_q4: path: vlm/vlm_1b_q4.onnx quant_type: int4 memory_mb: 620 date: 2024-01-20 slm: slm_3b_q4: path: slm/slm_3b_q4.gguf quant_type: q4_k_m memory_mb: 1500 date: 2024-01-22

6.2 长时间运行的稳定性保障

Pi 5跑AI负载长时间运行，稳定性是个挑战。我遇到过几次系统在跑了几小时后突然无响应，排查发现是内存泄漏。Python的某些库在反复推理后会有内存泄漏，尤其是图像处理相关的库。解决办法是定期重启推理服务，比如每24小时重启一次。

另一个稳定性问题是SD卡磨损。模型文件频繁读写会加速SD卡老化，我有一张卡用了三个月就出现坏块了。建议把模型文件放在USB固态硬盘上，SD卡只放系统。如果一定要用SD卡，至少要用高耐久度的型号。

还有温度问题。夏天室温高的时候，即使有风扇，CPU温度也可能到75度以上。我的做法是设置一个温度阈值，超过70度就自动降频，超过80度就暂停推理任务，等温度降下来再继续。这个逻辑用一个小脚本就能实现。

#!/bin/bash # thermal_guard.sh while true; do temp=$(cat /sys/class/thermal/thermal_zone0/temp) temp=$((temp/1000)) if [ $temp -gt 80 ]; then # 暂停推理服务 systemctl stop inference.service sleep 30 systemctl start inference.service elif [ $temp -gt 70 ]; then # 降频 echo 1500000 | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq fi sleep 10 done

6.3 实际场景中的效果评估

我在一个模拟的智能监控场景里跑了这套系统，效果是这样的：CNN每秒处理8-10帧，检测到人或者车辆的时候触发VLM，VLM用2秒左右生成描述，比如"画面中有一辆白色轿车停在路边，旁边有一个行人"。用户问"刚才有什么经过"，SLM结合最近的检测和描述，回答"5秒前有一辆白色轿车经过，车速较慢"。

整个流程的端到端延迟在3-5秒之间，对于非实时的监控场景是够用的。功耗方面，平均6.5W，一天耗电约0.156度，一个月不到5度电，成本可以忽略。

精度方面，CNN的漏检率在10%左右，主要是小目标和遮挡目标。VLM的描述准确率大概70%，有时候会把颜色说错或者漏掉细节。SLM的回答准确率在80%左右，主要问题是偶尔会编造信息。这些精度对于辅助人工监控是够用的，但不能完全替代人工。

6.4 后续扩展的方向

这套系统还有不少可以扩展的地方。比如加入音频处理，用一个小型的语音识别模型做语音交互；或者加入异常检测，用自编码器对CNN的特征做异常判断；还可以做多Pi协同，几个Pi 5分别负责不同的摄像头，通过消息队列共享检测结果。

模型方面，可以关注一些新的轻量化架构，比如MobileViT、EfficientFormer这些，它们在精度和速度的平衡上比传统CNN更好。VLM方面，一些专门为边缘设计的紧凑VLM也在不断出现，参数量更小、推理更快。

功耗方面，如果对续航有要求，可以考虑用太阳能板加电池的方案。Pi 5的功耗在5W左右，一块20W的太阳能板加一个10000mAh的电池，理论上可以支撑一天24小时的运行。当然实际要考虑天气和充电效率，需要留足余量。

我个人在实际操作中的体会是，边缘AI部署最大的挑战不是模型本身，而是系统工程。内存、功耗、散热、稳定性，每一个环节都可能成为瓶颈。模型选型要克制，不要追求大而全，而是要根据实际需求选最合适的。量化是必须的，但要注意评估精度损失。散热和电源不能省，否则性能再好也发挥不出来。最后，一定要做长时间运行的测试，很多问题只有在跑了几小时甚至几天后才会暴露出来。