多路视频流边缘推理调度方案对比：时分复用 GPU Time-Slicing 与 MPS 策略在 Jetson 上的评测

多路视频流边缘推理调度方案对比：时分复用 GPU Time-Slicing 与 MPS 策略在 Jetson 上的评测

一、问题定义与评测环境

在 Jetson Orin NX 平台上同时处理 4-8 路视频流的 AI 推理任务时，GPU 调度策略直接影响吞吐量与尾延迟。 NVIDIA 提供两种核心并发机制：(1)Time-Slicing（时分复用），将 GPU 时间片轮转分配给多个 CUDA Context；(2)MPS（Multi-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 秒持续运行)：

尾延迟上升分析：当路数从 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-control

MPS 实测数据：

对比分析（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 均较小时（< 3ms），MPS 可以将它们合并到同一时间片内执行，大幅降低排队延迟。

四、混合场景评测与选型建议

实际业务中常出现"检测(YOLOv8n) + 分类(ResNet-18)"混合部署场景。对两种模型在不同调度策略下的性能进行对比：

混合场景数据（4路检测 + 2路分类，共计6个进程）：

MPS 在混合场景下的优势更为显著，因为大小 Kernel 可以在同一 Context 内交错执行，小 Kernel（ResNet-18, 3ms）不必等待大 Kernel（YOLOv8n, 8ms）的完整时间片。

选型建议：

五、总结

在 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"的混合策略是一条经过验证的工程路径。