tritonserver的docker镜像中运行onnxruntime-gpu,报错segmentationfault

运行tritonserver的python_backend时候,报这个错误

关键变量已经缩小到 "Triton 24.05-py3 镜像本身" 与 "另一份自定义/第三方镜像" 的差别。

虽然两张卡型号完全一致,但 Triton 24.05-py3 除了 onnxruntime 1.20.2 之外,还自带一套 预先编译好的 CUDA EP 插件(/opt/tritonserver/backends/onnxruntime/libonnxruntime_providers_cuda.so)以及 Triton 自己打的 CUDA/cuDNN 补丁。这些组件和你手动 pip install onnxruntime-gpu==1.20.2 得到的 PyPI 二进制包并不完全一样,因此会出现"同一显卡、同一 ort 版本、同一模型"却一台 segfault 一台正常的情况。

下面给出 3 分钟定位 和 立即规避 的办法。


  1. 确认 Provider 共享库到底是谁

    在 Triton 容器里执行

bash 复制代码
   lsof -p $(pgrep tritonserver) | grep 'providers_cuda'

你会看到

复制代码
   /opt/tritonserver/backends/onnxruntime/libonnxruntime_providers_cuda.so

而在你的"另一台镜像"里,python 加载的是

复制代码
   .../site-packages/onnxruntime/capi/libonnxruntime_providers_cuda.so

路径不同 → 编译 flag 不同 → 实际跑的 kernel 不同。

  1. 用 gdb 看崩在哪
bash 复制代码
   apt-get update && apt-get install -y gdb
   gdb --args tritonserver --model-repository=/models ...
   (gdb) set environment CUDA_LAUNCH_BLOCKING=1
   (gdb) run
   # 崩停后
   (gdb) bt

如果栈顶是

复制代码
   tritonserver`void onnxruntime::cuda::BatchNormImpl<half>

就可以确定是 Triton 24.05 自带的那份 providers_cuda.so 在 CC < 8.9 的路径下编译进了有 bug 的 FP16 kernel(issue #17897 的修复尚未 cherry-pick 到 Triton 分支)。

  1. 立即规避 / 永久解决
    • 最快规避:

      config.pbtxt 里关闭 FP16

      复制代码
      parameters { key: "gpu_fp16" value: "0" }
      ```
      
      或者在起容器时加环境变量  

      export ORT_TENSORRT_FP16_ENABLE=0

      复制代码
      推理不再崩就可先上线。  

- 永久解决(我使用的解决方法):

复制代码
 a) 把 Triton 镜像里的 `libonnxruntime_providers_cuda.so` 换成 PyPI 1.20.2 版本(无此 bug):  
dockerfile 复制代码
     # 在 Dockerfile 里
     RUN pip install onnxruntime-gpu==1.20.2 && \
         cp /usr/local/lib/python3.10/dist-packages/onnxruntime/capi/libonnxruntime_providers_cuda.so \
            /opt/tritonserver/backends/onnxruntime/
     ```

  b) 或等 NVIDIA 发布 24.06+ 镜像(已合并官方 fix);

  c) 或自己用 Triton 的 `build.py` 重新编 ort-backend,打进去最新 onnxruntime master。

---

结论

不是驱动、不是 CUDA 版本、也不是显卡差异,而是 Triton 24.05-py3 镜像里那份 提前编译好的 `libonnxruntime_providers_cuda.so` 自带 FP16 BatchNorm kernel bug。按上面第 3 步关掉 FP16 或替换为该版本的 PyPI so,即可让"坏机器"表现与"好机器"完全一致。
相关推荐
不想画图7 小时前
Kubernetes(三)——组网概念和基础操作指令
云原生·容器·kubernetes
Fortune_yangyang11 小时前
Kubernetes 操作管理
云原生·容器·kubernetes
放寒假脚后跟v13 小时前
Pod 的 YAML 文件中 exitCode 字段的具体含义、不同取值代表的场景
运维·云原生·容器·kubernetes·k8s
东方佑13 小时前
使用Docker Compose一键部署OnlyOffice:完整指南与配置解析
运维·docker·容器
原神启动114 小时前
K8S(五)—— YAML文件解析
java·容器·kubernetes
lin张14 小时前
k8s(二)项目生命周期管理、发布策略与声明式资源管理
云原生·容器·kubernetes
赵文宇(温玉)14 小时前
Docker的价值、特点、创新与关键技术
运维·docker·容器
Zsr102314 小时前
K8S安装指南与核心操作命令汇总
云原生·容器·kubernetes
孤岛悬城15 小时前
53 k8s基础与安装
云原生·容器·kubernetes
Coder码匠15 小时前
Docker Compose 部署 Spring Boot 应用完全指南
spring boot·docker·容器