算法平台是整个视觉系统的引擎室：模型从训练到上线、从云端到边缘，全生命周期都在这里管。
上一篇讲了智慧园区视觉系统为什么要拆成算法平台和业务平台两层。这一篇把算法平台拆开讲透------它不是一个大推理服务，而是七个模块的组合。很多团队的"算法平台"其实就是几个推理脚本加一个模型文件夹，模型一多就乱：版本对不上、升级要停服务、新算法接入要改代码。
|------------------------------------------------------------------------------------------------------------------------------------|
| 核心判断 ：算法平台的本质是把模型变成可注册、可调度、可计量、可回滚的标准资源。它由七个模块组成：模型仓库、统一推理服务、模型调度器、算力管理、训练微调闭环、OTA 下发与版本管理、监控可观测性。统一推理服务是核心引擎，其他六个模块围绕它运转。 |
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 本文看点 * 算法平台的定位与边界 * 模型仓库怎么建（元数据 + 文件存储 + 校验） * 统一推理服务怎么设计（热加载 + 动态批处理） * 多模型调度器怎么做（路由 + 级联 + 优先级） * 算力管理与边缘协同 * 训练微调闭环（误报数据怎么回流） * OTA 下发与版本管理（灰度 + 回滚） * 监控可观测性 * 技术选型参考与落地路线图 |
01 算法平台的定位与边界
先划清楚边界，避免什么都往里塞：
|--------------|-------------|
| 算法平台管 | 算法平台不管 |
| 模型注册、存储、版本管理 | 业务场景配置、报警规则 |
| 统一推理服务与模型调度 | 摄像头接入、视频流管理 |
| 算力资源管理与分配 | 用户界面、大屏展示 |
| 模型训练、微调、评估 | 事件处置、工单流转 |
| 模型 OTA 下发与回滚 | 组织权限、审计流程 |
| 推理性能与模型效果监控 | 业务报表与统计 |
一句话：算法平台管 " 模型 " 和 " 推理 " ，业务平台管 " 场景 " 和 " 事件 "。两边通过统一推理 API 对接，业务方按能力名调用，不碰模型细节。下面逐个模块讲怎么搭。
02 模块一：模型仓库（ Model Registry ）
模型文件存在对象存储，元数据存在数据库，注册时自动校验和跑基准测试。
2.1 为什么需要模型仓库
没有仓库时，模型文件散落在各人电脑和服务器上，版本靠文件名猜（person_v2_final_final.onnx），出了问题查不到是哪个版本、谁训的、用什么数据训的。模型仓库就是模型的"代码仓库"------有版本、有元数据、有校验、有生命周期。
2.2 两层结构
|------|---------------------------------------|---------------------------|
| 层 | 存什么 | 技术选型 |
| 文件存储 | 模型权重文件（.pt / .onnx / .engine / .rknn） | 对象存储：MinIO / S3 / 阿里云 OSS |
| 元数据库 | 模型的描述信息、版本、性能指标、状态 | 关系型数据库：PostgreSQL / MySQL |
两者通过model_id + version关联。文件存储管"大文件"，元数据库管"可查询的描述"。
2.3 元数据字段
|------|--------------------------------------------------------------------------------------|
| 类别 | 字段 |
| 基础信息 | model_id、name、version、能力名（capability）、描述、创建人、创建时间 |
| 技术信息 | 框架（PyTorch / ONNX / TensorRT / RKNN）、输入分辨率、输出字段、精度（FP32/FP16/INT8）、硬件适配（GPU/NPU/CPU） |
| 性能信息 | mAP、召回率、误报率、单帧延迟、显存/内存占用、测试集名称与版本 |
| 业务信息 | 适用场景（室内/室外/白天/夜间）、敏感等级、是否允许边缘部署 |
| 关联信息 | 训练数据集 ID、上游模型版本（微调自哪个版本）、训练任务 ID |
2.4 注册与校验流程
模型不是传上去就算注册了，要走校验流程：
1.上传模型文件到对象存储，计算文件哈希（防篡改）；
2.校验输入输出规格是否与声明一致（加载模型跑一张测试图）；
3.自动跑基准测试：延迟、显存占用、在标准测试集上的精度；
4.基准结果写入元数据，模型标记为"测试中"；
5.人工或自动评估通过后，才能进入灰度。
校验不通过的模型直接拒绝注册，避免"带病上线"。
2.5 模型生命周期
|----------------|-------------------------|
| 状态 | 含义 |
| 测试中 | 刚注册，只在测试环境可用 |
| 灰度中 | 小部分摄像头/边缘节点在跑 |
| 稳定（stable） | 默认版本，业务方调用 stable 时路由到它 |
| 弃用（deprecated） | 有新版本替代，仍可用但不推荐 |
| 归档 | 不再可用，文件保留可追溯 |
**所以呢？**模型仓库解决的是"模型从哪来、是什么版本、效果怎么样、谁在用"这四个问题。没有它，后面的调度和升级都是空中楼阁。
03 模块二：统一推理服务（ Inference Server ）
请求进来先路由，再攒批，再送 GPU；模型可以热加载，服务不重启。
3.1 设计目标
统一推理服务是算法平台的核心引擎。它的设计目标很明确：一个服务跑所有模型，而不是每个模型起一个容器。支持热加载（加模型不重启）、高吞吐低延迟、对外统一API。
3.2 内部架构
|--------|----------------------------|
| 组件 | 职责 |
| 请求入口 | HTTP / gRPC 接口，接收推理请求 |
| 模型路由器 | 根据能力名 + 版本策略，找到对应的模型实例 |
| 模型加载池 | 管理已加载的模型实例，负责加载、卸载、版本切换 |
| 动态批处理器 | 在时间窗口内攒多个请求一起推理，提高 GPU 利用率 |
| 推理执行器 | 调用对应框架后端执行推理 |
| 结果返回 | 标准化输出（bbox、置信度、类别、mask） |
3.3 模型热加载与懒卸载
•按需加载：模型注册后不立刻占显存，第一次被调用时才加载；
•懒卸载：长时间（如 10 分钟）没有请求的模型自动卸载，释放显存给更活跃的模型；
•版本切换零中断：加载新版本后，等旧版本的在途请求处理完再切流量，旧版本在内存里保留一段时间，出问题秒级回滚。
3.4 动态批处理
视频分析是高并发小请求，单张图送 GPU 利用率很低。动态批处理的做法是：在一个短时间窗口（5--10ms）内把多个请求攒成一批，一起送 GPU 推理，再把结果分别返回。批大小动态调整------请求多就加大 batch，请求少就及时出 batch 不等，在延迟和吞吐之间找平衡。不同模型可以配不同的批处理策略（大模型batch 小，小模型batch 大）。
3.5 统一 API
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| textPOST /v1/infer { "capability": "person_detect", "version": "stable", // stable / latest / 指定版本 "image": "<base64 或 URL>", "params": { "conf_threshold": 0.5 } } → {"model_id": "person_detect","version": "v2.3","detections": {"bbox": \[x,y,w,h, "class": "person", "confidence": 0.92}],"latency_ms": 12.3 } |
业务方永远只看能力名和标准化输出，不关心底层是 YOLO 还是别的、跑在 GPU 还是 NPU。
3.6 多框架适配
推理服务通过适配层支持多框架：PyTorch、ONNX Runtime、TensorRT、RKNN（瑞芯微）、OpenVINO（Intel）。模型注册时声明框架和硬件，推理服务用对应后端加载。新硬件或新框架只需加一个适配器，不改业务代码。
**所以呢？**统一推理服务把"几十种模型"变成"一个 API"，把"每个模型一个服务"变成"一个服务动态加载所有模型"。这是算法平台能稳住的核心。
04 模块三：模型调度器（ Scheduler ）
4.1 调度器做什么
调度器是连接业务平台和推理服务的中间层，它决定：哪个摄像头的哪一帧，跑哪些模型，按什么顺序，送到哪个推理实例。业务平台配的是场景规则（"大门摄像头要跑人员和车辆"），调度器把它翻译成具体的推理调用。
4.2 按摄像头配置路由
每个摄像头有一份算法配置：跑哪些能力、置信度阈值、用哪个版本、抽帧率。调度器读取配置，把视频帧送到对应模型。配置可动态更新（比如夜间自动切换到夜间增强版模型），不用重启服务。
4.3 级联推理：先粗后细
这是视频分析最常用的优化手段。以安全帽检测为例：
1.第一级：全图跑人员检测，得到人员 bbox；
2.第二级：只对每个人员 bbox 区域跑安全帽识别；
3.第二级的输入图比全图小很多，推理快几倍，而且只关注人头部区域，误报更少。
支持多级级联：检测 → 跟踪 → 行为识别。调度器自动管理级联的数据传递，第一级的输出作为第二级的输入。
4.4 优先级与过载保护
|-----|------------|----------------|
| 优先级 | 典型算法 | 过载时策略 |
| 高 | 烟火、入侵、摔倒 | 保帧率、保精度，优先分配算力 |
| 中 | 人员计数、车辆识别 | 适当降帧 |
| 低 | 占道、未戴口罩、着装 | 降分辨率或暂停 |
队列管理也很重要：每个模型一个请求队列，满了丢弃最旧的帧。视频分析里，丢旧帧比积压好------积压会导致延迟越来越高，而旧帧的分析结果已经没有意义了。
4.5 流水线编排（ DAG ）
调度器支持 DAG（有向无环图）编排：一帧可以同时并行跑多个模型，也可以串联级联。比如大门摄像头的配置：
|----------------------------------------------------------------------------------|
| text帧输入 ├─ 并行：人员检测 ──级联──> 安全帽识别 ├─ 并行：车辆检测 ──级联──> 车牌识别 └─ 并行：烟火检测结果汇总 → 事件输出 |
业务方在界面上配置这个 DAG，调度器自动执行，不用写代码。
05 模块四：算力管理与边缘协同
5.1 算力池化
把所有 GPU / NPU 抽象成统一算力池，推理服务不绑定具体某张卡。调度器根据当前负载分配算力。支持 GPU 切分（如 NVIDIA MIG、vGPU），一张物理卡可以跑多个模型实例，提高利用率。
5.2 边缘盒子管理
•注册与心跳：边缘盒子上线后注册到平台，定期上报状态（CPU、GPU、温度、已加载模型、运行任务）；
•故障迁移：盒子离线时，它负责的摄像头任务自动迁移到云端或邻近盒子；
•远程运维：远程重启、日志拉取、模型加载状态查看，不用跑现场。
5.3 云边协同
|----|-----------------------|-----------------|
| 位置 | 跑什么 | 为什么 |
| 边缘 | 实时推理（检测、跟踪、简单行为） | 低延迟、省带宽，只传事件和截图 |
| 云端 | 复杂分析（大模型、跨摄像头追踪、数据统计） | 算力充足，非实时 |
模型从云端 OTA 下发到边缘，边缘的推理结果（事件、误报标记）回传云端，形成闭环。
5.4 模型优化
•量化：FP32 → INT8，推理速度翻倍，精度损失通常 < 1%；
•蒸馏：用大模型教小模型，边缘盒子跑小模型；
•算子融合：TensorRT / RKNN 工具链优化，减少内存搬运；
•针对性转换：不同 NPU 有自己的模型格式（瑞芯微 RKNN、昇腾 OM），平台自动转换并验证精度。
**所以呢？**调度器决定"怎么跑"，算力管理决定"在哪跑、跑不跑得动"。两者配合，才能让几十种模型在几百路视频上稳定运行。
06 模块五：训练微调闭环
训练→注册→灰度→OTA→边缘加载→监控→数据回流，形成一个不断自我优化的闭环。
6.1 数据回流：模型持续变好的燃料
模型上线不是终点。真实场景里的误报、漏报、难例，才是模型最需要学习的数据。算法平台要做的第一件事是把业务平台的误报标记自动回传：保安在手机上点"误报"，这张截图和上下文就自动进入算法平台的数据集，按场景、类型、时间分类存储。
6.2 自动标注 + 人工审核
•自动标注：用当前最优模型给新数据打标签，减少人工工作量；
•人工审核：标注平台里审核员修正自动标注的错误，重点审核低置信度样本；
•数据版本：每次审核通过后生成一个数据集版本，可追溯、可复现。
6.3 自动微调流水线
满足触发条件（误报率超标 / 定期 / 手动）后，流水线自动执行：
1.拉取最新数据集版本；
2.基于当前 stable 模型做微调（冻结 backbone，只训 head，或全量微调）；
3.在标准测试集 + 最新难例集上评估；
4.精度达标则自动注册到模型仓库（标记为"测试中"）；
5.不达标则通知算法工程师排查。
整个过程不需要算法工程师每次手动跑脚本，平台自动完成。算法工程师的精力放在数据质量和模型结构改进上。
6.4 效果评估门槛
新模型不是训完就能上线，必须过评估门槛：
|--------|--------------------------|
| 指标 | 要求 |
| 整体 mAP | 不低于当前 stable 版本 |
| 难例集召回率 | 有提升（这是微调的目标） |
| 误报率 | 不高于当前 stable 版本 |
| 推理延迟 | 不高于当前 stable 版本（边缘部署硬约束） |
四项全过才能进入灰度，任何一项不达标打回。
07 模块六： OTA 下发与版本管理
7.1 下发流程
模型在云端注册后，通过 OTA 下发到边缘盒子：
1.选择目标边缘节点（全部 / 按区域 / 按标签）；
2.云端推送模型文件，边缘下载后校验哈希和大小；
3.校验通过后后台热加载，不中断当前推理；
4.加载完成后按灰度策略切流量。
7.2 灰度策略
|-----------|------------|------------|
| 阶段 | 范围 | 观察 |
| 影子模式 | 后台跑，不报警 | 与旧模型输出差异率 |
| 灰度 5% | 少量盒子 / 摄像头 | 误报率、漏报率、延迟 |
| 灰度 30% | 扩大范围 | 同上 + 盒子负载 |
| 灰度 100% | 全量 | 持续监控 |
| 标记 stable | 成为默认版本 | --- |
7.3 一键回滚
灰度任何阶段发现异常（误报飙升、延迟超标、盒子负载打满），一键回滚到上一版本。回滚是配置级操作，秒级生效，边缘盒子自动切回旧模型。所有切换（谁、何时、从哪个版本到哪个版本、原因）都有审计日志。
7.4 边缘热加载
边缘盒子收到新模型后在后台加载，加载完成后才切流量，旧模型在内存里保留一段时间。整个过程不重启推理服务，正在处理的视频流不中断。这对7×24 运行的安防场景至关重要。
**所以呢？**训练闭环让模型"越用越准"，OTA 灰度让模型"敢上线、能回退"。两者合起来，模型迭代从"季度发版"变成"周级甚至日级"，而且不中断业务。
08 模块七：监控与可观测性
8.1 三层监控
|------|----------------------------------------|
| 层 | 监控什么 |
| 基础设施 | GPU / CPU / 内存 / 网络 / 温度、边缘盒子在线状态、磁盘空间 |
| 模型性能 | 每个模型的延迟、吞吐、显存占用、推理成功率、超时率、版本分布 |
| 业务效果 | 每个能力的报警量、误报率（人工反馈）、漏报率（抽样）、按场景/区域维度 |
8.2 关键指标与告警
•推理延迟 P99：超过阈值告警（视频分析要求实时，延迟高了等于没用）；
•模型错误率：推理失败、超时、OOM，飙升时告警；
•边缘盒子离线：心跳超时立即告警；
•误报率异常：某个模型的误报标记突然增多，可能是场景变化或模型退化，触发重训；
•数据漂移：输入数据分布与训练集差异过大时预警（模型可能不再适用）。
告警分级推送：一般告警到企业微信 / 钉钉，紧急告警（盒子大面积离线、推理服务不可用）到短信 / 电话。
09 技术选型参考
|--------|----------------------------------------------|----------------------------|
| 模块 | 推荐选型 | 说明 |
| 模型仓库 | MinIO + PostgreSQL | 对象存储存模型文件，关系库存元数据 |
| 统一推理服务 | Triton Inference Server / BentoML / 自研 | Triton 支持多框架和动态批处理，自研可控性更强 |
| 模型调度器 | 自研（Go / Python） | 场景编排和级联逻辑与业务强相关，建议自研 |
| 算力管理 | Kubernetes + NVIDIA Device Plugin / KubeEdge | 云端 K8s，边缘用 KubeEdge 统一管理 |
| 训练微调 | PyTorch + MLflow | MLflow 管实验和模型版本 |
| 消息队列 | Kafka | 事件流转、视频帧分发、数据回流 |
| 监控 | Prometheus + Grafana + ELK | 指标 + 日志 + 可视化 |
| 边缘框架 | KubeEdge / OpenYurt | 边缘节点统一纳管、离线自治 |
选型原则：核心模块（推理、调度）自研可控，基础设施（存储、编排、监控）用成熟开源。不要什么都自己写，也不要什么都用第三方黑盒。
10 落地路线图
|-----|--------|----------------------------------------|
| 阶段 | 时间 | 目标 |
| 阶段一 | 1--2 月 | 模型仓 + 统一推理服务跑通，接入 2--3 个核心算法（人员、车辆、烟火） |
| 阶段二 | 2--3 月 | 调度器 + 算力管理，边缘盒子接入，支持级联推理和动态抽帧 |
| 阶段三 | 2--3 月 | 训练微调闭环 + OTA 灰度发布 + 监控告警，模型可以自动迭代 |
| 阶段四 | 持续 | 扩展更多算法、优化效果、多园区统一管理 |
不要一上来就做全平台。先把"模型仓 + 统一推理 + 2--3 个算法"这条核心链路跑通，让业务方先用起来，再逐步加调度、训练闭环、OTA。
最后
算法平台不是一天建成的，也不是买一个产品就能解决的。它的核心价值是把模型的全生命周期管起来------从训练出来、注册、推理、调度、升级到回滚，每一步都有记录、有数据、有退路。
|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 核心结论 ：算法平台 = 模型仓库（管模型是什么）+ 统一推理服务（管模型怎么跑）+ 调度器（管模型跑在哪）+ 算力管理（管跑不跑得动）+ 训练闭环（管模型怎么变好）+ OTA 版本管理（管模型怎么升级）+ 监控（管模型跑得好不好）。七个模块围绕统一推理引擎运转，模型就从"散落在各处的文件"变成了"可注册、可调度、可计量、可回滚的标准资源"。 |
模型会过时，平台不会。把模型的事管起来，系统才能跟着园区一起长。