Triton Python 模型报 shared memory key 初始化失败，为什么加显存池没用？

如果日志同时出现下面两段，先检查容器内的 /dev/shm：

Unable to initialize shared memory key
No space left on device

Python 后端在 Triton 主进程和模型进程之间使用共享内存。这个空间与 cuda_memory_pool_byte_size 管理的显存池分开，扩大后者无法增加 /dev/shm 容量。

官方 issue #6195 记录了 Triton 2.36.0 的类似问题。维护者指出，当时案例里的共享内存需求按 Python 模型实例计算，与 CUDA memory pool 无关。问题与维护者说明

在报错的容器里查容量

进入运行 Triton 的同一个容器后执行：

df -h /dev/shm

也可以在宿主机查看容器创建时设置的上限，输出单位是字节：

docker inspect --format '{{.HostConfig.ShmSize}}' triton-container

把示例容器名换成实际名称。不要只看宿主机根分区的剩余空间；报错指向的共享内存挂载有自己的容量限制。

接着检查模型的 instance_group 和启动日志，数清实际创建了多少 Python 模型实例。同一套部署有多个模型时，应把它们一起纳入预算，而不是只盯着当前失败的那个模型。

按当前版本和负载调整部署配置

Docker 可以在创建容器时用 --shm-size 设置共享内存容量。将变更写入真正使用的启动脚本或编排配置，并安排重建容器的时间；现有请求可能受影响，先保留可回退配置。Docker 容器运行参数

容量应结合实例数、输入输出大小和并发峰值测算。必要时先降低实例数或测试负载，观察共享内存使用，再决定最终设置。若托管平台不允许扩容，需要调整负载或部署方式。

不要把旧 issue 中的 128MB 当成通用推荐。该数字对应原报告的具体配置。当前 Python 后端文档描述的是每实例先分配 1MB、再按需增长，并提供 shm-default-byte-size 和 shm-growth-byte-size 参数；这两个参数调整分配策略，不能凭空扩大容器总上限。Python 后端共享内存说明

验收要覆盖请求过程

重建后先检查所有预期模型是否 READY，再发送测试请求并观察 /dev/shm。至少覆盖计划中的最大输入、最大并发及多个模型同时运行的情况。只在启动时有空闲，不能保证后续增长也有空间。

如果日志最后是 No such file or directory、权限错误或 stub 退出，诊断方向会不同。保留完整首个错误再查，不要看到 shared memory 字样就无限加容量。也不要为绕过问题开启特权容器、共享宿主机 IPC，或直接删除其他进程仍在使用的共享内存文件。