多路视频流边缘推理调度方案对比时分复用 GPU Time-Slicing 与 MPS 策略在 Jetson 上的评测一、问题定义与评测环境在 Jetson Orin NX 平台上同时处理 4-8 路视频流的 AI 推理任务时GPU 调度策略直接影响吞吐量与尾延迟。 NVIDIA 提供两种核心并发机制(1)Time-Slicing时分复用将 GPU 时间片轮转分配给多个 CUDA Context(2)MPSMulti-Process Service将多个进程的 CUDA Kernel 合并到单一 Context 中执行消除 Context Switch 开销。评测环境硬件Jetson Orin NX 16GB, JetPack 6.0, 1024 CUDA Cores 32 Tensor Cores模型YOLOv8n (TensorRT INT8, ~8ms/帧) ResNet-18 (TensorRT FP16, ~3ms/帧)流模拟4/6/8 路 1080p 独立进程每进程独立 CUDA Context指标吞吐量(fps 总和)、P99 尾延迟、GPU 利用率二、Time-Slicing 调度机制与实测数据Time-Slicing 是默认的 GPU 并发策略。NVIDIA 驱动为每个 CUDA Context 分配固定的执行时间片默认 3ms通过/sys/module/nvgpu/parameters/timeslice_us可调时间片到期后强制切换 Context。Time-Slicing 实测数据(YOLOv8n × N 路90 秒持续运行)路数总吞吐(fps)单路平均(fps)P99尾延迟(ms)GPU利用率4 路112.328.124.791%6 路128.521.438.294%8 路131.716.556.396%尾延迟上升分析当路数从 4 增至 8 时P99 延迟从 24.7ms 跳升至 56.3ms。原因在于(1) Context 切换开销随路数线性增长8 路时每次切换 ~30μs × 8 240μs 额外开销(2) 各进程的 CUDA Kernel launch 时间不同步导致部分帧刚获得时间片就被中断需等待一整轮8 × 3ms 24ms才能再次执行。/** * 使用 CUDA Event 测量 Time-Slicing 下的帧延迟 * 通过事件时间戳精确计算从推理发起到完成的端到端时间 */ #include cuda_runtime.h #include stdio.h #include sys/time.h typedef struct { cudaEvent_t start; cudaEvent_t stop; struct timeval wall_start; /* 挂钟时间(用于检测排队延迟) */ } frame_timer_t; /** * 初始化帧计时器 * return 0成功, -1初始化失败 */ int frame_timer_init(frame_timer_t* timer) { if (timer NULL) return -1; cudaError_t err cudaEventCreate(timer-start); if (err ! cudaSuccess) { fprintf(stderr, [错误] cudaEventCreate(start)失败: %s\n, cudaGetErrorString(err)); return -1; } err cudaEventCreate(timer-stop); if (err ! cudaSuccess) { fprintf(stderr, [错误] cudaEventCreate(stop)失败: %s\n, cudaGetErrorString(err)); cudaEventDestroy(timer-start); return -1; } return 0; } /** * 记录推理开始时间 */ void frame_timer_start(frame_timer_t* timer, cudaStream_t stream) { gettimeofday(timer-wall_start, NULL); cudaEventRecord(timer-start, stream); } /** * 同步并计算推理延迟 * return 延迟(毫秒), -1同步失败 */ float frame_timer_elapsed_ms(frame_timer_t* timer) { cudaError_t err cudaEventSynchronize(timer-stop); if (err ! cudaSuccess) { fprintf(stderr, [错误] cudaEventSynchronize失败: %s\n, cudaGetErrorString(err)); return -1.0f; } float gpu_ms 0.0f; err cudaEventElapsedTime(gpu_ms, timer-start, timer-stop); if (err ! cudaSuccess) { fprintf(stderr, [错误] cudaEventElapsedTime失败: %s\n, cudaGetErrorString(err)); return -1.0f; } /* 计算挂钟时间(含队列等待GPU执行) */ struct timeval wall_end; gettimeofday(wall_end, NULL); float wall_ms (wall_end.tv_sec - timer-wall_start.tv_sec) * 1000.0f (wall_end.tv_usec - timer-wall_start.tv_usec) / 1000.0f; /* wall_ms - gpu_ms 调度排队延迟 */ return wall_ms; }三、MPS 调度机制与实测数据MPS 的核心思路是将多个进程的 CUDA Kernel 提交合并到 MPS Server 的单一 Context 中。GPU 调度器看到的是一个进程提交多个 Kernel因而可以在 Kernel 级别并发执行只要 CUDA Core/Tensor Core 资源不冲突而不是在 Context 级别串行轮转。MPS 启动配置# 设置MPS独占模式(需要root权限) sudo nvidia-smi -i 0 -c EXCLUSIVE_PROCESS # 启动MPS Control Daemon export CUDA_MPS_PIPE_DIRECTORY/tmp/mps_pipe export CUDA_MPS_LOG_DIRECTORY/tmp/mps_log nvidia-cuda-mps-control -d # 验证MPS状态 echo get_server_list | nvidia-cuda-mps-controlMPS 实测数据路数总吞吐(fps)单路平均(fps)P99尾延迟(ms)GPU利用率4 路118.729.720.188%6 路142.223.726.892%8 路156.419.633.497%对比分析8 路场景总吞吐MPS 156.4 fps vs Time-Slicing 131.7 fps提升18.8%P99 延迟MPS 33.4ms vs Time-Slicing 56.3ms降低40.7%GPU 利用率两者接近~96%但 MPS 的有效利用率更高Context 切换浪费被消除MPS 在尾延迟上的优势源于消除了 Context 切换开销。当多个进程提交的 Kernel 均较小时 3msMPS 可以将它们合并到同一时间片内执行大幅降低排队延迟。四、混合场景评测与选型建议实际业务中常出现检测(YOLOv8n) 分类(ResNet-18)混合部署场景。对两种模型在不同调度策略下的性能进行对比混合场景数据4路检测 2路分类共计6个进程调度策略检测总fps分类总fps检测P99分类P99Time-Slicing82.4178.345.2ms18.7msMPS93.1189.631.5ms14.2msMPS 在混合场景下的优势更为显著因为大小 Kernel 可以在同一 Context 内交错执行小 KernelResNet-18, 3ms不必等待大 KernelYOLOv8n, 8ms的完整时间片。选型建议场景推荐方案理由2-4 路同构推理Time-SlicingMPS 额外守护进程开销(5%)不值得4 路同构推理MPSContext 切换开销 5%阈值异构模型混合MPSKernel 级并发最大化 GPU 利用率需进程隔离(安全)Time-SlicingMPS 共享 Context一个进程出错可能影响全局调试/ProfilingTime-SlicingMPS 会使 Nsight 等工具的进程级 Profiling 复杂化五、总结在 Jetson Orin NX 上进行多路视频流推理时MPS 策略在 6 路及以上场景展现出明确的优势总吞吐提升 15-19%P99 尾延迟降低 35-41%。其核心价值在于消除 CUDA Context 切换开销和实现 Kernel 级并发。然而 MPS 也有代价(1) 需要 root 权限配置(2) 进程间故障隔离被削弱(3) Profiling 复杂性增加。对于 4 路以下的小规模部署Time-Slicing 的简洁性和隔离性更具工程价值。实际项目中4 路以下 Time-Slicing 4 路以上 MPS的混合策略是一条经过验证的工程路径。