ulimit -u 在容器中无法防止算力投毒，因其仅限制用户级进程数、不生效于容器init、且被cgroup v2覆盖；真正有效的是CPU配额、PID总数限制和运行时干预三重防线。
限制单容器线程数不能靠 ulimit 防止“算力投毒”——这是常见误解。ulimit -u（即 nproc）在容器内实际失效，它只限制用户级进程/线程创建数量，但现代应用（尤其是 python、java、go 等）的线程行为受运行时调度和 cgroup 控制，ulimit 无法精准拦截恶意计算密集型任务。
为什么 ulimit -u 在容器中防不了算力投毒
算力投毒指攻击者在容器内运行隐蔽高 CPU 占用代码（如暴力哈希、加密轮询、无限递归计算），不依赖大量线程，而靠单线程持续满载 CPU 或利用多线程并行榨干核心。这类行为：
- 不触发 nproc 限制：一个 Python 进程开启 4 个线程（
threading.Thread）仍算作 1 个进程，ulimit -u 100 完全放行； - 绕过 ulimit 生效路径：Docker 默认不加载 pam_limits.so，且容器 init 进程不读取
/etc/security/limits.conf； - 被 cgroup v2 覆盖：Linux 内核以
pids.max和cpu.max为准，ulimit 属于用户态软限制，优先级更低、易被绕过。
真正有效的三重防线
防算力投毒必须组合控制：不是“限线程数”，而是“限算力总量 + 限并发粒度 + 限执行上下文”：
-
CPU 时间配额（最核心）：用
--cpus=0.8或--cpu-quota=80000 --cpu-period=100000，硬性限制容器每 100ms 最多使用 80ms CPU 时间，超限则被内核节流，计算任务自然降速； -
PID 总数硬限（防放大）：用
--pids-limit=64，阻止通过 fork 多进程或启动数十个 worker 进程横向扩展算力，对 PyTorch DataLoader、Node.js cluster 等场景尤其关键； -
运行时干预（精准拦截）：在容器启动脚本中加入资源检查，例如：
echo 'vm.max_map_count=65530' > /proc/sys/vm/max_map_count 2>/dev/null || true（防 mmap 滥用）
或用prlimit --as=2G --cpu=300 --nproc=32 $$对主进程再加一层 cgroup 兼容限制。
配置示例（Docker Compose）
以下片段可直接用于生产环境，兼顾防御性与可观测性：
services:
ml-worker:
image: my-ai-app:py310-cuda12
deploy:
resources:
limits:
cpus: '0.75'
memory: 2G
pids_limit: 48
ulimits:
nproc: { soft: 48, hard: 48 }
cpu: 300 # 秒级软超时，触发 SIGXCPU
command: sh -c "prlimit --as=1536M $$ && exec python train.py"
注意：prlimit 命令需基础镜像含 util-linux，Alpine 用户请改用 apk add util-linux。
验证是否起作用
进入容器后执行：
-
cat /sys/fs/cgroup/cpu.max→ 应显示类似75000 100000（对应 0.75 核）； -
cat /sys/fs/cgroup/pids.max→ 应为48； - 运行
stress-ng --cpu 4 --timeout 10s后观察top -b -n1 | head -20，CPU 使用率应被稳定压制在 75% 左右，不会飙到 400%。
