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,即可让"坏机器"表现与"好机器"完全一致。
相关推荐
lichenyang4533 天前
Docker 学习笔记(四):Dockerfile,把项目打成自己的镜像
docker·容器
lichenyang4533 天前
Docker 学习笔记(三):Docker 网络、bridge、子网和容器互通
docker·容器
lichenyang4533 天前
Docker 学习笔记(二):docker run 的参数到底在控制什么?
docker·容器
云恒要逆袭8 天前
运行你的第一个Docker容器
后端·docker·容器
程序员老赵10 天前
10 分钟部署 OpenCode:Docker 一键安装,浏览器打开就能用 AI 写代码(附完整命令与排错)
docker·容器·ai编程
武子康13 天前
调查研究-183 Apple container:Mac 上用轻量 VM 跑 Linux 容器,Swift 会改写本地容器体验吗?
docker·容器·apple
2601_9618752416 天前
决战申论100题2026|最新|范文
linux·容器·centos·debian·ssh·fabric·vagrant
java_cj16 天前
深入kube-apiserver认证机制:从Bearer Token到mTLS的完整认证链解析
linux·运维·服务器·云原生·容器·kubernetes
程序员老赵16 天前
服务器没有桌面?Docker 跑个 Chrome,浏览器就能远程用
docker·容器·devops
正经教主16 天前
【docker基础】 第八周:容器监控与应用更新策略
运维·docker·容器