Orin 上多模型常驻与显存预算

文章目录

[Orin 上多模型常驻与显存预算](#Orin 上多模型常驻与显存预算)
- [1. 结论先行](#1. 结论先行)
- [2. 贯穿示例：四路门店多模型主机](#2. 贯穿示例：四路门店多模型主机)
- [3. 统一内存下「显存」指什么](#3. 统一内存下「显存」指什么)
- [4. 常驻与按需加载的划分](#4. 常驻与按需加载的划分)
- [5. 粗估预算：先列表，再上板测](#5. 粗估预算：先列表，再上板测)
- [6. 各 SKU 的容量直觉](#6. 各 SKU 的容量直觉)
- [7. 内存吃紧时的调整顺序](#7. 内存吃紧时的调整顺序)
- [8. 按需加载的工程约束](#8. 按需加载的工程约束)
- [9. 常见误区与排查](#9. 常见误区与排查)
- [10. 可直接粘贴的检查表](#10. 可直接粘贴的检查表)
- [11. 与后续链路的衔接](#11. 与后续链路的衔接)
- [12. 术语对照](#12. 术语对照)
- [13. 上线前总检查](#13. 上线前总检查)
- [14. 金样机压测口径](#14. 金样机压测口径)

摘要：单模型检测跑通之后，业务常会叠第二层、第三层：跟踪、属性分类、OCR、偶发小 VLM。Orin 是 统一内存 架构，GPU 引擎、视频缓存、系统进程抢的是同一池物理内存。本文用「四路门店主机：主检 + 跟踪 + 属性 + 可选 OCR」贯穿示例，写清常驻与按需加载怎么划、怎么估预算、怎么用 tegrastats 验收，以及内存吃紧时该减路数、上 DLA 还是升 SKU。适合已跑通多路 DeepStream / 二次推理、准备叠模型的人。具体容量以模组手册与板上实测为准。

图1. 统一内存上的常驻模型与视频链路

可对照已发布文：

1. 结论先行

情况	建议做法	不建议做法
只有主检测	先把单引擎 + 路数压稳	预留「以后再加三个模型」却不测内存
主检 + 跟踪 + 一个小属性网	NX 16GB / AGX 较宽裕；Nano 要减路数或按需加载	三份大 YOLO 同时常驻
第二、第三个模型很少触发	按需加载，用完可卸载	全部开机 preload
辅模型是规整 CNN	评估 DLA 卸载，腾 GPU 与带宽	把主 YOLO 硬塞 DLA
峰值内存经常顶满、频繁换页	减路数 / 降分辨率 / 升 SKU	只调 `conf` 阈值假装优化

常驻回答「哪些引擎一直占着内存」；预算回答「峰值还剩多少余量」。 两者都要在目标板、目标功耗档、目标外壳里测，不能只看 .engine 文件大小。

2. 贯穿示例：四路门店多模型主机

设定如下：

Orin NX 16GB，封闭小壳，工作功耗档
常驻：YOLO 主检测（GPU FP16，batch=4）+ tracker + 行人属性 sgie（DLA0）
按需：收银区告警后加载工牌 OCR 小网（GPU），处理完可卸载
业务还想试「偶发小 VLM 看图」，但暂不要求常驻

本文要回答三件事：

常驻集合能不能在 16GB 上稳住峰值余量
OCR / VLM 该常驻还是按需
若换成 NX 8GB 或 Orin Nano 8GB，哪里会先顶满

验收时建议按层叠加，不要一次全开：

只开 4 路 + pgie，记稳态内存与 FPS
加 tracker，再记一笔
加属性 sgie，再记一笔
触发 OCR 加载，抓峰值
对比各层增量，写入预算表

这样比「全开后再猜谁吃内存」快得多。

3. 统一内存下「显存」指什么

桌面 GPU 常把「显存」和「系统内存」分开。Orin 上是 统一内存（Unified Memory） ：CPU、GPU、编解码器、DeepStream 缓冲共享同一块物理 RAM。口语里说「显存不够」，板上多数时候其实是 整机可用内存不够。

占用项	典型来源
TensorRT 引擎运行时	权重、workspace、中间激活
DeepStream 缓冲	streammux / 解码 / OSD 队列
Tracker 状态	轨迹与特征缓存
系统与容器	Linux、Docker、业务 Agent
临时加载模型	OCR / VLM 加载瞬间的峰值

因此预算表要写 整机可用内存峰值余量 ，不要只记 nvidia-smi 式「显存」口径（Orin 上常用 tegrastats / free）。

.engine 文件大小只能当下限参考：运行时还要加上 workspace、中间激活、以及 DeepStream 为 batch 准备的缓冲。经验上，运行占用经常是文件大小的数倍；以文件大小做合同承诺会翻车。

图2. 引擎、视频缓冲与系统进程共享同一内存池

4. 常驻与按需加载的划分

模型 / 组件	建议策略	理由
主检测 pgie	常驻	每帧都要
tracker	常驻	与检测同生命周期
高频属性 sgie	常驻	几乎每帧有目标
低频 OCR	按需	事件触发才用，加载有延迟可接受
大参数 VLM	独立进程 / 按需，默认不进 DeepStream	常驻极易挤爆预算
仅调试用的第三检测头	不上量产镜像	避免「临时」变永久常驻

原则：

帧路径上的模型优先常驻，保证尾延迟稳定。
事件路径上的模型优先按需，用冷启动换内存。
按需模型要写清：加载超时、失败降级、是否允许与主链并行。

系列《Orin 上 DeepStream 二次推理》里的 sgie，若业务上「几乎人人都要属性」，应按常驻规划；若只有 VIP 通道才做 OCR，则放到事件 worker 里按需加载。

5. 粗估预算：先列表，再上板测

先做一张 常驻清单（数字为量级示意，必须以本机实测替换）：

项	估占用	备注
系统 + Docker 空闲底噪	1.5～3 GB	镜像与后台服务差异大
4 路 720p 解码 + mux 缓冲	0.5～1.5 GB	分辨率 / 队列深度敏感
YOLO FP16 batch=4 引擎运行时	1～3 GB	比 `.engine` 文件大
tracker	0.2～0.8 GB	目标数峰值敏感
属性 sgie（DLA）	0.3～1 GB	DLA 仍可能占统一内存
合计粗估	约 4～9 GB	NX 16GB 通常有余量；8GB 要抠

验收时看两个数：

稳态占用：业务跑满 10 分钟后的 Used
峰值占用：OCR 加载瞬间、多目标高峰、OSD 开全时

建议预留 15%～25% 空闲作抖动余量；长期低于 10% 空闲，换页与掉帧风险会明显上升。

bash 复制代码

# 业务起来前后对比
free -h
tegrastats --interval 1000
# 容器场景可再看
docker stats --no-stream

测速与功耗档必须固定，否则内存曲线和 FPS 会对不上。见 Orin 上同一模型 FPS 不同：测量方法、功耗和前后处理拆解、Orin 上功耗档与降频排查。

记录建议做成一张简单表，列「配置组合 / Used / 可用余量 / FPS / 备注」，每次只改一个变量。升级 JetPack 或重建引擎后要重测：运行时占用可能变，不能沿用旧预算表。

6. 各 SKU 的容量直觉

模组	内存量级	多模型常驻直觉
Orin Nano 4GB	紧	单主检 + 少路数；慎叠 sgie
Orin Nano 8GB	入门可用	2～3 路 + 小 sgie 要实测；无 DLA
Orin NX 8GB	中端紧凑	主检 + tracker 可行；双辅模型常驻易紧
Orin NX 16GB	中端主力	主检 + tracker + sgie 常驻较常见
AGX Orin 32/64GB	旗舰	多模型 + 更大缓冲余量大

Nano 没有 DLA ，辅模型只能和主检挤 GPU 与内存带宽。NX / AGX 可把规整辅模型放到 DLA，减轻 GPU 侧竞争，见 Orin 上 DLA 与 GPU 的分工与使用。

选型文已强调「多模型必须同时常驻 → 优先更大内存 SKU」；本文补的是：常驻清单怎么列、峰值怎么验，避免只看参数表下单。

同一业务在 Nano 8GB 上「能 Demo」、在 NX 16GB 上「能量产」，差别经常不在 FPS 标称，而在常驻集合是否允许留出余量。Demo 机关掉 OSD、少开一路、不触发 OCR，内存曲线会好看很多，不能直接写进合同。

图3. 帧路径常驻，事件路径按需

7. 内存吃紧时的调整顺序

建议按下面顺序减压，一次只改一类：

关掉调试 OSD / 录像落盘，先看推理真占用
缩小 streammux 队列与缓存（在可接受延迟内）
提高 sgie 的最小框阈值，减少 crop 并发
把低频模型改为按需加载
辅模型迁 DLA（有 DLA 的 SKU）
减路数或降分辨率
升 SKU 内存档（8→16，或 NX→AGX）

不要第一步就换更大 YOLO：主检变大，常驻底噪一起涨，往往更挤。

主检 interval、sgie batch-size 与路数关系，见多路检测文与二次推理文；改 batch 后要重建引擎，见系列《Orin 上 JetPack 与 TensorRT 引擎升级清单》。

INT8 有时能降运行时占用，但省不下视频缓冲与系统底噪；没有验收集就上 INT8，可能用精度换一点内存，现场更难排查。量化路径见系列《Orin 上 INT8 与量化部署》。

8. 按需加载的工程约束

按需不是「用的时候 trtexec 现场编引擎」。量产约束：

约束	说明
引擎预编译	目标板上事先建好 `.engine`，加载只 deserialize
超时	加载超过 N 秒则告警并走无 OCR 降级
互斥	避免同时加载两个大模型把峰值叠满
卸载	空闲 M 秒后释放；注意碎片与反复加载成本
进程隔离	VLM 建议独立进程，崩溃不影响 DeepStream

python 复制代码

# 示意：事件 worker 内按需加载
def handle_event(event):
    if needs_ocr(event):
        engine = ocr_pool.acquire(timeout_s=2.0)  # 预热好的引擎句柄
        try:
            event["ocr"] = run_ocr(engine, event["crop_path"])
        finally:
            ocr_pool.release(engine)

probe 里仍只写队列，不在 OSD 回调里同步加载大模型。见 Orin 上边缘 Agent 落地。

9. 常见误区与排查

图4. 多模型内存问题排查顺序

现象	多见原因	处理
开机一段时间后变慢	内存顶满开始换页	看 `free` / `tegrastats`，减常驻
一开 sgie 就 OOM	常驻超预算或 batch 过大	减 sgie batch、过滤类别、升内存
文件上 engine 很小，运行却很大	运行时 workspace / 激活未计入	以运行峰值为准，不以文件大小为准
Docker 内正常、宿主机卡顿	多容器重复常驻同一模型	合并进程或共享引擎服务
升了 16GB 仍紧	路数与队列一起加了	一次只加一层，重测峰值
VLM 偶发拖垮主链	与 DeepStream 同进程同机硬挤	隔离进程 + 按需 + 限流

排查口诀：先分清常驻清单 → 再测稳态与峰值 → 再决定按需 / DLA / 减路 / 升配。

现场若出现「重启后前几分钟正常、之后变慢」，同时盯内存与频率：可能是换页，也可能是壳温降频。两者处理完全不同，不要混为一谈。

10. 可直接粘贴的检查表

上线前：

已列出常驻模型与按需模型两张表
已在目标 SKU、目标功耗档测稳态与峰值内存
峰值后仍保留约定空闲余量（例如 ≥15%）
低频模型有超时与降级路径
DLA 辅模型已单独建引擎并验收 fallback
加模型后的 FPS / 事件条数与基线可对照

11. 与后续链路的衔接

主题	说明
多路与 batch	Orin 上用 DeepStream 跑多路检测
二次推理	系列《Orin 上 DeepStream 二次推理》
DLA 分流	Orin 上 DLA 与 GPU 的分工与使用
INT8 降占用	系列《Orin 上 INT8 与量化部署》
引擎升级	系列《Orin 上 JetPack 与 TensorRT 引擎升级清单》
功耗与降频	Orin 上功耗档与降频排查
NX 内存档选型	同系列 Orin NX 8GB 与 16GB 选型文
总览	NVIDIA Jetson Orin 完全使用手册

12. 术语对照

术语	含义
统一内存	CPU / GPU / 编解码共享同一物理内存池
常驻	进程生命周期内一直加载、可立即推理的模型或组件
按需加载	事件触发时再加载引擎，用完可释放
workspace	TensorRT 构建/运行时的临时显存（统一内存）工作区
峰值余量	最高占用之后仍剩余的可用内存比例
换页	内存不足时把页面换到存储，导致延迟尖刺

13. 上线前总检查

检查项	通过标准
常驻清单	与配置 / 容器实际加载一致
稳态内存	连续运行后 Used 稳定、无持续爬升泄漏
峰值内存	OCR / 多目标高峰时可接受，且有余量
FPS	相对「仅主检」基线掉幅在合同范围
降级	按需加载失败时主链仍可用
SKU 结论	实测支持当前常驻集合，或已给出升配理由

14. 金样机压测口径

量产前至少做一轮 金样机（批量复制前的样机）压测：

项目	建议
时长	连续 2 小时以上，覆盖业务高峰时段
负载	真实路数 + 常驻全开 + 按需模型按真实触发率打入
观察	内存曲线是否爬升、是否逼近换页、FPS 是否随壳温掉
对照	与「仅主检」基线同机、同功耗档、同外壳

若 2 小时内 Used 持续爬升，优先查泄漏（未释放的队列、落盘、按需加载未卸载），不要先升 SKU。

Orin 上多模型部署，核心不是「还能不能再塞一个 engine」，而是 把常驻集合写成预算表，用稳态与峰值验收，再决定按需、DLA、减路或升 SKU。统一内存下没有独立的「显存小金库」；帧路径模型常驻保延迟，事件路径模型按需保容量。具体数字以目标板实测为准。