文章目录1. 多路难点在哪2. 多路的最小链路3. 建议顺序2 路 → 4 路别直接 8 路4. 开始前再确认一遍5. 建议先做 2 路再复制成 4 路6. 四路最小配置示例6.1 主配置ds_rtsp_multi4.txt6.2 推理配置pgie_config_multi.txt7. 跑起来后先看什么8. 容量预估9. 最常见的坑10. 没桌面时怎么看多路结果11. 多路通了以后再做什么12. 跑通后可以对照这几条13. 小结摘要单路 RTSP 检测通了之后下一步通常是多路。很多人一上来就开 8 路结果掉帧、花屏、OOM 一起来最后分不清是网络、解码还是模型的问题。本文从 2 路扩到 4 路把source怎么加、batch-size怎么对齐、tiled-display怎么看、容量怎么估、常见坑怎么查说清楚。适合已经跑通单路 DeepStream 的人。1. 多路难点在哪单路通了不等于多路只是“复制粘贴 source”。多路真正叠加的是这几件事每路都要解码streammux 要把多路合成 batch推理要按 batch 吃进去OSD / 拼屏 / 编码出口也会跟着变重网络带宽和摄像头抖动会互相拖累所以多路不是“把 FPS 乘以路数”而是整条链路的容量问题。DeepStream 的价值也在这里它把多路合批这件事做成默认路径而不是你自己用 OpenCV 开 N 个线程硬拼。官方对deepstream-app多源和 streammux 的说明见DeepStream Reference ApplicationGst-nvstreammux一句话记住官方建议streammux和primary-gie的batch-size尽量等于输入路数。2. 多路的最小链路可以先这样理解多路 RTSP → 硬解码 → streammux 合批 → primary-gie 推理 → OSD → tiled-display / 落盘 / 推流和单路相比配置上多出来的核心只有三块变化点单路多路source只有[source0][source0]…[sourceN]batch-size通常是 1等于路数tiled-display可关调试时建议开方便一眼看齐别的东西比如模型路径、标签、OSD、功耗档思路和单路一样。先别同时换模型、换分辨率、换推流否则定位成本会翻倍。3. 建议顺序2 路 → 4 路别直接 8 路阶段目标先别做2 路证明合批和拼屏没问题一上来改业务模型4 路看内存、温度、掉帧边界同时开跟踪、二次网络、推流再加路按板型容量推进掉帧还没定位就继续加经验上Orin Nano先把 24 路 720p 稳住再谈更高路数Orin NX48 路比较常见看模型和分辨率AGX Orin路数余量更大但网络和散热仍然会先卡你具体上限别背“某型号一定能跑 N 路”。输入分辨率、编码格式、模型大小、interval、是否拼屏编码都会改结论。4. 开始前再确认一遍单路那篇的前置条件这里都还成立。多路额外再确认cat/etc/nv_tegra_releasesudonvpmodel-qdeepstream-app--versiontegrastats然后每一路 RTSP 都能单独打开不要在 DeepStream 里才发现第 3 路密码错了。分辨率尽量先统一例如都先按 1280×720 进 streammux少留一个变量。板子上别同时挂着重推理脚本多路一开资源争用会立刻放大。单路验证命令还是先用gst-launch-1.0 rtspsrclocationrtsp://相机地址latency200!rtph264depay!h264parse!avdec_h264!videoconvert!autovideosink每一路都过一遍再进 DeepStream。网络侧也建议先心里有个数。四路 1080p、每路大概 48 Mbps交换机和 Orin 网口都未必是瓶颈但 Wi-Fi 摄像头、跨网段录像机、共享带宽的交换机经常会先把某一路拖死。多路掉帧时先问一句是四路一起慢还是某一路先挂。5. 建议先做 2 路再复制成 4 路如果你手里只有单路配置最小改法是复制出[source1]改 URI把streammux.batch-size改成2把primary-gie.batch-size改成2pgie里的batch-size同步改成2tiled-display开成rows1 columns22 路画面齐、perf 稳之后再复制成 4 路。这一步看起来笨但能把“合批逻辑错了”和“板子容量不够”分开。很多人直接从 1 跳到 8最后日志一长串不知道从哪一行看起。batched-push-timeout也不要乱拧。直播源通常保留一个相对合理的超时示意里是40000微秒量级让 muxer 在等不满 batch 时也能往下推。设得太大某一路卡住时整批更慢设得太激进又容易出现不完整 batch。第一次多路先用 sample/单路附近的默认值确认链路通了再微调。6. 四路最小配置示例下面给一个4 路 RTSP 拼屏显示的最小思路。路径按你自己的环境改。6.1 主配置ds_rtsp_multi4.txt[application] enable-perf-measurement1 perf-measurement-interval-sec5 [tiled-display] enable1 rows2 columns2 width1280 height720 gpu-id0 nvbuf-memory-type0 [source0] enable1 type4 urirtsp://相机1地址 gpu-id0 latency200 cudadec-memtype0 [source1] enable1 type4 urirtsp://相机2地址 gpu-id0 latency200 cudadec-memtype0 [source2] enable1 type4 urirtsp://相机3地址 gpu-id0 latency200 cudadec-memtype0 [source3] enable1 type4 urirtsp://相机4地址 gpu-id0 latency200 cudadec-memtype0 [streammux] gpu-id0 live-source1 batch-size4 batched-push-timeout40000 width1280 height720 enable-padding0 nvbuf-memory-type0 [primary-gie] enable1 gpu-id0 batch-size4 gie-unique-id1 config-filepgie_config_multi.txt nvbuf-memory-type0 [osd] enable1 gpu-id0 border-width2 text-size12 text-color1;1;1;1 text-bg-color0.3;0.3;0.3;1 fontSerif show-clock0 clock-x-offset800 clock-y-offset820 clock-text-size12 clock-color1;0;0;0 nvbuf-memory-type0 [sink0] enable1 type2 sync0 source-id0 gpu-id0 nvbuf-memory-type0这里最容易写错的是source开了 4 路但batch-size还停在 1streammux.batch-size和primary-gie.batch-size不一致tiled-display的rows * columns小于路数看起来像少了一路live-source忘了开成 1官方也明确说过batch 设得比路数大或小都可能把延迟搞怪。多路第一次先对齐再谈“优化”。6.2 推理配置pgie_config_multi.txt[property] gpu-id0 net-scale-factor0.003921568627451 model-color-format0 onnx-file/home/ubuntu/models/yolov8n.onnx model-engine-file/home/ubuntu/models/yolov8n_b4_fp16.engine labelfile-path/home/ubuntu/models/labels.txt batch-size4 network-mode2 num-detected-classes80 interval0 gie-unique-id1 process-mode1 network-type0 cluster-mode2 maintain-aspect-ratio1 symmetric-padding1 [class-attrs-all] pre-cluster-threshold0.25 nms-iou-threshold0.45注意两点engine 的 batch 最好和运行 batch 对齐单路建出来的batch1engine拿去硬跑batch4轻则重建、重则报错或性能很差。多路第一次建议在目标板上按目标 batch 重新建 engine。interval是多路保命开关interval0表示每帧都推推理。路数一多先把它改成1或2隔帧推理往往比盲目换更大板子更快止血。7. 跑起来后先看什么deepstream-app-cds_rtsp_multi4.txt第一遍只盯四件事四路是不是都有画面框是不是都在perf 打印是否大致平稳tegrastats里内存和温度有没有顶满建议另开一个终端tegrastats重点看观察项正常时大概感觉危险信号GPU有稳定占用忽高忽低且画面卡RAM有余量持续顶满、开始杀进程温度可控持续高温后 FPS 明显掉网络各路延迟差不多某一路长期拖后腿多路场景里最慢的那一路常常决定整条链路的体感。所以别只看平均 FPS也要看是不是某一路经常卡住。8. 容量预估现场一般按这个顺序压测单路 720p 稳住2 路同配置4 路同配置再决定要不要升分辨率、加跟踪、开编码推流每加一档记一张表路数输入模型interval端到端 FPS 感觉内存温度结论1720pyolov8n0………基线2720pyolov8n0…………4720pyolov8n0…………4720pyolov8n1…………如果你发现2 路很好4 路开始掉帧先降分辨率、加interval再怀疑板型不够画面都在但某一路长期黑屏先查那路相机和网络不要先改模型一开拼屏编码推流就崩先关输出编码只保留检测链路把瓶颈拆开选型上可以粗看板型多路检测常见起步备注Orin Nano24 路轻量检测内存和散热先卡你Orin NX48 路较常见看模型和分辨率AGX Orin更高路数更从容仍要算解码和出口这是经验区间不是承诺值。合同里的“支持 N 路”一定要写清分辨率、码率、模型和是否实时编码。还有一个实用取舍业务不要求每帧都检时优先加interval而不是先换更大模型再硬扛。隔帧检测对很多门禁、通道、仓库巡检场景足够用却能明显降低 GPU 和温度压力。真要“每路每帧”再回头压分辨率、换更小模型或者上更大内存的板型。9. 最常见的坑现象多见原因先查什么只显示一路source 没全开或 tile 行列不够enable、rows/columns起得来但很卡batch 不对、分辨率太大、interval0batch-size、输入尺寸、interval某几路黑屏那几路 RTSP 本身有问题单独gst-launchengine 报错/重建很久batch 和 engine 不匹配按目标 batch 重建跑一会内存涨输出编码、泄漏、分辨率过大先简化 sink看tegrastats换板后全挂engine 不是本板生成目标板重建拼屏看着花宽高和源不一致、padding 乱统一 streammux 尺寸还有一个很典型单路 sample 很好多路换成自己模型后全军覆没。这时优先查parser 是否适配num-detected-classes/ labels 是否对齐预处理是否和训练一致batch engine 是否在本机构建DeepStream 不会替你自动修好 YOLO 适配问题。排障时我习惯按层剥源每路单独gst-launch合批batch-size、live-source、tile 行列推理engine、labels、parser、interval出口显示 / 落盘 / 推流是否把整机拖垮不要一上来同时改四层。多路日志本来就密一次只动一个变量定位会快很多。10. 没桌面时怎么看多路结果SSH 上去、没有显示器时sink type2往往不合适。多路调试可以先写文件先确认四路都有框再谈实时看。只看 perf 日志先验证链路稳不稳不急着盯画面。后面再上 RTSP 出口多路检测 多路再编码推流是另一层复杂度。第一次多路我更建议先拼屏本地看或先落盘回看。一上来就“四路进、四路出再推平台”出问题会很难拆。11. 多路通了以后再做什么到这一步后面通常才有资格谈跟踪tracker二次分类 / 属性网络区域告警、落图、推消息Docker 固化与开机自启评估要不要从 Nano/NX 升到 AGX或以后看 Thor顺序别反。业务逻辑堆上去之前至少先证明N 路能稳定进batch 推理能稳住你知道掉帧时该降哪一档参数12. 跑通后可以对照这几条按上面从 2 路扩到 4 路之后可以自己核对单路配置能不能平稳扩到多路而不是靠重写一整套batch-size是否和路数对齐engine 是否按目标 batch 重建拼屏里各路画面、检测框是否都能一眼看清掉帧时会不会先动interval、分辨率、功耗档而不是先怪模型出问题时能不能按「源 → 合批 → 推理 → 出口」分层排查这几条都过得去多路就不再只是演示而是可以拿去估板型、估容量了。13. 小结Orin 上多路 DeepStream难点通常不在“再复制几个 source”而在合批、容量和短板定位。先把 2 路、4 路按同一套配置跑稳把batch-size、拼屏和tegrastats看懂后面加跟踪和告警才没有问题。