结合你的场景（实时系统、单GPU多进程加载独立计算图）和环境配置，我从几个核心角度给你梳理排查思路，这些都是处理TensorFlow 1.x多进程GPU推理问题的常用方向：

1. 先查CUDA上下文切换的开销 #

TensorFlow 1.x中每个进程都会创建独立的CUDA上下文，而你的GTX 1080 Ti属于Pascal架构，CUDA上下文切换本身是有固定开销的——当多个进程频繁抢占GPU计算资源时，这个切换耗时会被放大，直接导致单推理请求的延迟上升。

你可以用nvidia-smi的命令实时监控上下文切换频次：

nvidia-smi --query-compute-apps=pid,context_switches --format=csv

如果看到切换次数持续很高，那这就是核心原因之一。

另外，哪怕你设置了allow_growth=false和固定内存占比，多个进程的CUDA上下文初始化、内存分配过程也可能存在隐性的锁竞争，这同样会拖慢单推理速度。

2. 计算图加载的时机与资源竞争 #

你提到每个进程都要单独加载计算图，而TF1.x的计算图加载（不管是从文件读取还是重新构建）本身会占用CPU和GPU资源。如果多个进程同时启动并加载计算图，会出现短暂的CPU资源竞争，甚至导致GPU初始化操作排队，后续的推理请求就会带着“累积延迟”运行。

可以做两个小验证：

• 先让所有进程完成计算图加载后，再统一启动推理请求，看看单推理耗时是否有所改善；
• 考虑用单进程多线程替代多进程——TF1.x的单进程内tf.Session支持多线程调度，能更好地复用GPU资源，还能避免多进程的上下文切换开销，不过要注意实时系统的线程调度策略是否符合你的需求。

3. 实时系统的CPU调度优先级问题 #

你这是实时系统，但Linux默认的CFS（完全公平调度）策略不会给你的推理进程特殊优先级，如果有其他系统进程抢占CPU，会间接导致GPU的推理任务等待CPU的输入/预处理结果——这时候看硬件监控GPU和CPU都没跑满，但实际是调度层面的瓶颈。

可以试试给推理进程设置实时调度优先级，用chrt命令：

chrt -f 99 ./your_inference_binary

设置后再观察单推理耗时的变化，很多实时系统的性能问题都出在调度优先级上。

4. TensorFlow 1.x的GPU调度限制 #

TF1.x对多进程的GPU资源隔离支持不如TF2.x完善，每个进程的tf.Session都是独立的，CUDA runtime会自动分配SM（流式多处理器）资源，但多个进程的推理任务可能会抢占同一个SM的计算单元，导致每个任务的计算时间被拉长。

你可以尝试设置TF的环境变量来优化线程模式：

export TF_GPU_THREAD_MODE=gpu_private

这个参数会让每个进程的GPU线程更独立，减少进程间的资源竞争。

5. CUDA/cudnn版本的兼容性问题 #

CUDA 9.2在Pascal架构上的多进程支持确实有一些已知的小问题，比如多进程内存分配时的锁竞争会导致延迟上升。如果条件允许，可以尝试升级到CUDA 10.0（兼容TF1.12），或者把cudnn升级到7.4（兼容CUDA9.2）——不过因为你是源码编译的TF，升级后需要重新编译，这个成本要提前考虑。

内容的提问来源于stack exchange，提问作者Vali Rusu