libtorch多线程推理实战：线程安全边界与高性能并发方案

从一个实际问题开始说吧。我去年在做一个视频分析服务，模型本身是 PyTorch 训练好的，推理部分要拿到 C++ 服务端跑。模型不大，单帧延迟也低，但业务是并发的，客户端不断把请求打进来。我最初很自然地写了一个全局 torch::jit::script::Module，然后每次请求来了直接 forward，结果上线没多久就出现两种诡异现场：要么服务进程直接段错误崩溃，要么某几个线程返回的结果是错的，而且不是必现，是偶发，压测越久越明显。排查到后面基本确认，问题不是模型本身，而是 libtorch 在多线程下的使用姿势不对。

这篇文章就专门说清楚一件事：C++ 环境下用 libtorch 做多线程推理，到底怎么用才是安全的。我会结合自己的实测经历，把线程安全边界、底层原因、代码设计、常见崩溃和排查手段全讲一遍，适合正在把 PyTorch 模型转到 C++ 服务端、或者打算用 libtorch 做高并发推理的开发者参考。

1. 多线程用 libtorch，一开始就容易掉进哪些坑

1.1 最典型的两种崩溃现场

先说两种我见过最多的错误用法。

第一种，全局共享同一个 Module，多个线程同时调用 forward。表面看好像没什么问题，因为 Module 本身只是模型结构加参数，理论上“读操作”可以并发。但 libtorch 的 forward 并不只是读参数，它会临时构建计算图、分配中间张量、调用底层算子库，这些过程会读写共享状态，所以多个线程同时调用同一个实例的 forward 属于典型的未定义行为，崩溃概率极高。这种错误很迷惑人，因为低并发、低压力下可能完全正常，一旦请求量上来就炸。

第二种，每个线程各自加载一次模型文件，比如每个线程里都做一次 torch::jit::load()。这种做法线程安全倒是安全了，但模型加载涉及大量内存分配、反序列化和算子注册，一个 1GB 的模型如果开了 16 个线程，光模型副本就是 16GB，而且加载耗时会被放大 16 倍，服务启动时间直接不能看。

还有些人会把 CPU 推理的 set_num_threads 设置到全局，但没搞清楚它具体作用范围，结果所有线程加起来把 CPU 跑满，任务反而互相抢资源，延迟更高。这个放到后面“性能坑”部分细说。

1.2 搞清楚“不是线程安全的模块”到底是什么

Libtorch 官方文档其实明确写了：Module 不是线程安全的。它给出的建议是，如果要在多线程环境里做推理，要么用多个模块实例，要么用锁来保证一次只有一个线程执行推理。这句话看着简单，但实操起来有两个关键点容易被忽略。

第一，多个模块实例是怎么来的？官方推荐的方式是在主线程先加载模型，然后用 clone() 复制出多个实例再分发到线程。注意，不是让你在多个线程里重复 load()，load() 是完整读文件，clone() 则是在内存里复制一份模块结构。clone() 快得多，而且线程安全的前提是你在多线程开始之前就把所有副本准备好。如果你在运行期再动态 clone() 或者动态 load()，那又可能踩到别的坑。

第二，就算每个线程独立持有一个模块实例，也不代表你可以完全放飞。因为 PyTorch 在推理时还存在全局的线程池、内存分配器、缓存分配器等等。比如 CPU 版本依赖 OpenMP，GPU 版本依赖 CUDA context，这些东西本身是进程级的共享资源。所以“模块级安全”不等于“整个进程安全”，这句话后面我会反复提到。

2. 多线程推理方案选型：共享模型还是每线程一份

2.1 方案一：全局 model + 互斥锁串行推理

最省事的做法是：全局只保留一个 torch::jit::script::Module，每次推理前加锁，推理完再解锁，所有请求排队进入 forward。

cpp复制std::mutex mtx;
torch::jit::script::Module module;

void inference(const torch::Tensor& input) {
    std::lock_guard<std::mutex> lock(mtx);
    auto output = module.forward({input});
    // ...
}

这个方案的好处是内存占用极小，实现极其简单，而且绝对安全。坏处也明显：如果单次推理耗时 30ms，那服务的 QPS 上限就是 33 左右，无论你开多少个线程，吞吐量都没有提升。如果你的业务并发量很低，比如内部工具、离线批量任务，这方案完全够用。但如果你把它当作在线服务的高并发方案，那瓶颈会锁死在推理延迟上。

我在实际压测里发现一个问题：锁竞争倒是其次，关键是 CPU 推理场景下，OpenMP 可能会把单次 forward 的耗时拉得很高，导致每个线程排队时间长得离谱。用锁只是保证不崩，并不能真正解决吞吐问题。

2.2 方案二：每个线程持有一个模型实例

这是我最终采用的方案。思路是：

1. 主线程先 torch::jit::load() 加载基础模型；
2. 利用 module.clone() 在内存中复制出 N 份模型（N 等于你期望的并发线程数）；
3. 把每个克隆实例绑定到固定的线程，线程内只调用自己持有的那份实例；
4. 推理时不加锁，彻底避开线程间共享。

cpp复制std::vector<torch::jit::script::Module> modules;
modules.reserve(worker_count);

auto base_module = torch::jit::load(model_path);
for (int i = 0; i < worker_count; ++i) {
    modules.push_back(base_module.clone());
}

// 每个 worker 持有一个 index，只访问 modules[index]

clone() 的耗时跟模型大小相关，但比重新 load() 快很多。我实测一个 60MB 的模型，load() 大概 300ms，clone() 只需要十几毫秒，差距非常明显。所以这个方案对内存的压力主要来自模型参数复制，但通常模型体积在几十到几百 MB，而一个服务需要的并发线程一般也就几个到几十个，内存是完全可接受的。

2.3 我的推荐：先按“每线程一个实例”来设计，再考虑优化

现在很多人问我，到底能不能共享一个模型做到更高并发？我的答案是：共享 + 加锁只能作为低并发兜底方案，真正想提升吞吐率，首先要走每线程一个实例的路。

为什么不能先尝试共享模型加“内部锁”？因为 PyTorch 推理内部不只有你看到的 forward 这层锁边界，它底层还有缓存分配器、算子库调度，你以为加锁保护了模块，但实际上模块内部的算子执行可能把临时结果写到全局缓存里，多线程还是会踩。所以与其猜测什么地方安全，不如从架构上隔离。

如果你觉得多个模型副本的内存实在承担不起，可以考虑那种“模块数量 = 硬件并发度”的设计。比如 CPU 机器上，物理核数 8 核，你开 4 个线程，每个线程一份模型，每份模型内部再允许 2 个 OpenMP 线程，这样内存不会无限膨胀，性能也能有效扩展。后面“线程池与 OpenMP 调优”我会给具体参考值。

3. Libtorch 线程安全边界和底层原理

3.1 为什么 autograd 是罪魁祸首

很多做纯部署的人看到 autograd 三个字会有点抵触，觉得这是训练才用的东西。但 libtorch 的模块继承自 torch::jit::script::Module，它的前向过程仍然基于 JIT interpreter，执行过程中会记录算子执行轨迹。即使你不需要反向传播，JIT 默认也会维护一些执行状态，这些状态在多线程同时访问同一个模块时会彼此干扰。

最直接的安全做法是在每次推理时包一层 torch::NoGradGuard：

cpp复制torch::NoGradGuard no_grad;
auto output = module.forward({input});

这就等于告诉 libtorch，这里不需要梯度跟踪，可以减少很多临时图的构建和记录，不仅更安全，性能也会稍微好一点。

另外，模型导出时最好就切到推理模式。如果你是通过 Python 训练完再导出 TorchScript，记得在 Python 侧先调 model.eval()，再 torch.jit.trace 或 script。如果模型里带着 Dropout 或 BatchNorm，这些层在 train 和 eval 模式下的行为差异很大，导出前忘记切模式，后面推理结果都可能是错的，这个问题和线程无关，但在部署时特别常见。

3.2 ModulePtr 与模块深拷贝的真相

clone() 看起来像深拷贝，但它不是简单的 memcpy。PyTorch 内部中，模型参数、缓冲区都存放在 TensorImpl 里面，clone() 会重新创建张量并复制数据，因此每个克隆实例拥有独立的参数存储。我在实际验证中发现，clone() 后一个模块的参数发生变化，另一个模块的参数不会联动变化，这就是独立的证据。

相对的，如果你使用浅拷贝方式，比如直接把 torch::jit::script::Module 对象赋值给另一个变量：

cpp复制torch::jit::script::Module m2 = m1;

它们内部的 shared_ptr 会指向同一个实现对象。m2 不是独立模型，而是 m1 的别名。这种情况下把 m1 和 m2 分给不同线程使用，本质上还是线程共享同一个实例，依然会崩。这一点我踩过一次：一开始我以为赋值就是拷贝，结果排查了半天，最后发现是共享引用计数导致的崩溃。

所以这里给一个明确判断：

• 想要多线程安全：用 module.clone()。
• 不要用 = 赋值后分线程。
• 不要乐观地以为模块结构里有 shared_ptr 就能随便共享，PyTorch 内部的锁粒度远没有覆盖前向计算全过程。

3.3 线程池与 OpenMP 对推理效率的影响

PyTorch CPU 推理依赖 OpenMP 做算子内并行，intra_op 是单个算子内部的并行线程数，inter_op 是不同算子之间的并行度。很多人在多线程推理场景里不设置这两个值，系统默认会用满所有 CPU 核心。如果你再开 16 个业务线程，每个线程里的算子又各自尝试用满所有核，结果就是线程之间频繁抢占 CPU，性能不仅不升，反而会因为上下文切换开销导致整体吞吐下降。

我在一台 16 核的 Linux 机器上做过对照压测。业务线程数从 1 加到 8，torch::get_num_threads() 保持 16 默认值不变，结果总吞吐从 110 QPS 下滑到 70 QPS。后来我把每个业务线程里的 intra_op 线程数调到 2，业务线程数开到 8，总吞吐反而上升到 320 QPS 左右。所以关键不是“线程越多越好”，而是业务线程数和算子内并行线程数要做乘积规划，让总并行度略低于或等于 CPU 核数。

设置方式：

cpp复制#include <torch/torch.h>
#include <ATen/Parallel.h>

// 设置 intra-op 并行线程数
at::set_num_threads(2);
// 设置 inter-op 并行线程数
at::set_num_interop_threads(1);

注意，at::set_num_threads 要在初始化阶段调用，而且它对整个进程生效，所以如果不同的线程想要不同的值，会非常麻烦。这也是我后来倾向“每线程持有独立模型实例”的原因之一：你可以让每个线程在推理前设置一次，但如果你需要频繁切换线程数配置，会遇到 OpenMP 线程池重建的开销。在标准服务模型里，最好一开始就把固定线程数设好，不要让每份模型都创建独立的 OpenMP worker。

GPU 推理还有另一层坑：CUDA 的 context 是进程级共享，多线程同时访问同一块显卡时，会竞争 stream 和显存分配器。常见的做法是在每个业务线程里维护自己的 CUDA stream 或扩展流，但这属于更高级的优化。如果只是刚上手，建议先用 module.to(at::kCUDA) 并让推理在同一线程内完成，避免线程间共享 CUDA 上下文。

4. 实操：TorchScript 模型在 C++ 线程池里做安全推理

4.1 先导出 TorchScript 模型并固定输入输出

C++ libtorch 普遍加载的是 TorchScript 格式，而不是 .pth 权文文件。先看 Python 侧导出代码：

python复制import torch

class MyModel(torch.nn.Module):
    def __init__(self):
        super().__init__()
        self.conv = torch.nn.Conv2d(3, 16, 3, padding=1)
        self.fc = torch.nn.Linear(16 * 32 * 32, 10)

    def forward(self, x):
        x = self.conv(x)
        x = torch.relu(x)
        x = x.view(x.size(0), -1)
        x = self.fc(x)
        return x

model = MyModel()
model.eval()

example = torch.rand(1, 3, 32, 32)
traced_model = torch.jit.trace(model, example)
traced_model.save("my_model.pt")

导出时有个细节：example 的形状如果定了，模型就对输入尺寸敏感。如果你后续推理想支持变化尺寸，需要额外做 dynamic input 处理，或者用 torch.jit.script。但如果你的应用场景是图像检测或固定分辨率处理，直接用 trace 最省心。

我个人的做法是，在测试阶段先用 Python 加载同一个权重，跑一个随机输入得到基准输出，然后把 TorchScript 模型在 C++ 里加载再跑同样的随机输入，比较最大误差。这个步骤非常重要，因为很多模型在 Python 里能跑，但 trace 后行为会有细微变化，如果没做对比，后面出错很难定位是 C++ 调用的问题还是模型导出的问题。

4.2 完整的线程池 + 模型实例池代码实现

下面给出一个可以直接改着用的实现框架。它做的事情是：预加载模型、克隆出多个副本、固定绑定线程，最后通过一个简单线程池接任务。

cpp复制#include <torch/script.h>
#include <ATen/Parallel.h>
#include <iostream>
#include <memory>
#include <thread>
#include <vector>
#include <queue>
#include <mutex>
#include <condition_variable>
#include <atomic>

class ModelWorker {
public:
    // 每个 worker 持有一个独立的 module 副本
    explicit ModelWorker(torch::jit::script::Module module, int intra_threads)
        : module_(std::move(module)) {
        // 设置本线程的算子内并行线程数
        at::set_num_threads(intra_threads);
    }

    torch::Tensor infer(const torch::Tensor& input) {
        torch::NoGradGuard no_grad;
        module_.eval();
        auto output = module_.forward({input});
        return output.toTensor();
    }

private:
    torch::jit::script::Module module_;
};

class ThreadPool {
public:
    ThreadPool(size_t workers, int intra_threads, const std::string& model_path) {
        auto base_module = torch::jit::load(model_path);
        base_module.eval();

        for (size_t i = 0; i < workers; ++i) {
            auto module_copy = base_module.clone();
            // 如果需要 GPU，可以在这里统一迁移
            // module_copy.to(at::kCUDA);
            workers_.emplace_back(
                std::make_unique<ModelWorker>(std::move(module_copy), intra_threads)
            );
            threads_.emplace_back([this, i] { this->runLoop(i); });
        }
    }

    ~ThreadPool() {
        stop_ = true;
        cv_.notify_all();
        for (auto& t : threads_) {
            if (t.joinable()) {
                t.join();
            }
        }
    }

    std::future<torch::Tensor> submit(const torch::Tensor& input) {
        auto task = std::make_shared<std::packaged_task<torch::Tensor()>>(
            [this, input]() -> torch::Tensor {
                // 用当前线程绑定的 worker 做推理
                size_t idx = workerIndex_;
                torch::Tensor result = workers_[idx]->infer(input);
                return result;
            }
        );
        std::future<torch::Tensor> fut = task->get_future();
        {
            std::lock_guard<std::mutex> lock(queueMtx_);
            tasks_.push([task] { (*task)(); });
        }
        cv_.notify_one();
        return fut;
    }

private:
    void runLoop(size_t workerIndex) {
        // 每个线程绑定固定 worker，不能随意换
        workerIndex_ = workerIndex;
        while (!stop_) {
            std::function<void()> task;
            {
                std::unique_lock<std::mutex> lock(queueMtx_);
                cv_.wait(lock, [this] { return stop_ || !tasks_.empty(); });
                if (stop_ && tasks_.empty()) {
                    return;
                }
                task = std::move(tasks_.front());
                tasks_.pop();
            }
            task();
        }
    }

    std::vector<std::unique_ptr<ModelWorker>> workers_;
    std::vector<std::thread> threads_;
    std::queue<std::function<void()>> tasks_;
    std::mutex queueMtx_;
    std::condition_variable cv_;
    std::atomic<bool> stop_{false};
    // 注意：真正的线程局部 worker 索引应该用 thread_local
    // 这里简化逻辑，实际代码里建议用 thread_local
    static thread_local size_t workerIndex_;
};

thread_local size_t ThreadPool::workerIndex_ = 0;

上面的代码逻辑能跑，但我实际写生产代码时，不会把 workerIndex_ 用那么随意，通常会在线程入口处通过 thread_local 精确记录当前线程持有的模型副本下标。核心原则是：线程和模型实例一一绑定，不能随便让线程池里的任务漂移到错误的模型上。

如果你用的是现成的线程池库，比如 bshoshany/thread-pool 或自己写的任务队列，控制模型和线程对应关系时更要小心。常见的反模式是任务队列里的输入进来后，随机取一个模型副本去推理，结果同一份模型副本还是可能被多个线程并发调用，安全性荡然无存。所以要么在线程函数里做“取当前线程对应的复制品”，要么在任务提交时就指定 worker 序号。

4.3 forward 环节必须养成的三个好习惯

第一个好习惯是 eval() 和 NoGradGuard 一个都不能省。很多人在 Python 训练时代码里从不写 eval()，到 C++ 部署后也懒得写。但 libtorch 里如果模型里有 BatchNorm，eval() 模式用的是累计均值方差，不调用它就用错了统计量，结果是推理数值乱七八糟，有时甚至会毫厘之差导致后处理判断错位。加 torch::NoGradGuard 是因为推理时候不需要自动求导。

第二个好习惯是输入张量要主动搬到模型所在的设备上。假如模型在 CPU，你传入 torch::cuda::kCUDA 张量，某些场景会报错，某些场景会触发非法内存访问。最好在 infer 入口统一判断：

cpp复制if (input.device() != module_.parameters().front().device()) {
    input = input.to(module_.parameters().front().device());
}

这个检查在 C++ 服务里能省下大量低级 bug。

第三个好习惯是多线程下不要对同一份输出张量做原地修改后再返回上层。由于张量底层是引用计数的，如果你在一个线程里把返回的张量 swap 到全局变量，另一个线程可能正在读取同一个张量导致数据竞争。部署时尽量保持“输入不可变，输出新张量”的推理风格，降低踩坑概率。

5. 常见问题与排查技巧实录

5.1 一上多线程就段错误，怎么定位

段错误是最典型的竞态问题。但你要区分它是模型实例的竞态，还是底层库的全局状态竞态。

我自己遇到的一个例子是：用了一个全局单例的预处理器，把图像解码、Resize、Normalize 全部封装好给多线程用。我当时以为它内部只有局部变量，是线程安全的，结果后来发现它里面缓存的中间矩阵被多个线程同时覆盖。最后段错误直接指到 opencv 的 resize 内部。所以排查时不要一口气就认定是 libtorch 的问题，先把业务代码里的缓存、指针、单例全部检查一遍。

如果你基本确认是模型实例的并发问题，建议先用最暴力的方法验证：直接给所有 forward 加全局大锁。如果加了锁之后不崩了，再把锁细化。如果能跑出正确结果，那就说明问题出在模型实例共享上，根本不是别的库的问题。

还可以使用 gdb 查看崩溃现场，bt 看到线程栈后，重点关注是否所有线程都卡在 torch::jit::interpreter 的同一个地址上。如果是，那基本就是同一模块被并发执行。再用 p module 或者查看调用栈中的 this 指针，确认它们指向的是不是同一对象。

关于 ASAN 和 TSAN，我提一句：TSAN 是排查线程竞态的利器，但它在检测 libtorch 内部状态时可能报一堆误报，而且内存开销很大。个人建议先用“全局锁验证法”，再用 TSAN。如果直接 TSAN，你可能被几十页报告淹没，反而看不清。生产环境也不建议常开 TSAN，只适合本地复现。

5.2 推理结果时对时错

这种问题非常痛苦，因为进程不崩，但某个线程算出来的数值不对。典型原因有几个：

• 模型里包含 BatchNorm/Dropout，并且没有切到 eval 模式，导致推理结果随输入分布变化；
• 使用了共享权重，但某个线程无意中修改了参数值，比如自己写了一个“后处理”模块误操作了参数；
• 输入张量内存被别的地方复用，比如把临时变量的引用传了出去，后面对它做修改时数据已损坏。

如果是“随机一个线程出错”，可以把错误场景改成多线程各推理相同输入，比较输出差异。如果同一个输入在多线程下输出不一致，说明竞态确实存在。如果多线程下每个线程的输出都和 Python 基准一致，说明推理本身没问题，问题大概率在预处理或者后处理阶段。

我还遇到过一种情况：模型是 float32，但输入图像原始数据是 uint8，我犯懒没转，直接传 uint8 张量，导致某些线程上输出结果不对。后来把输入统一转成 float32 并确保归一化方式与训练时一致才正常。这种问题跟多线程没有直接关系，但在多线程场景下因为错误暴露的随意性，很容易让人误判成线程安全 bug。

5.3 CPU 占用爆炸或 GPU 性能不升反降

CPU 场景下前面说过，是 intra_op 默认线程数太高导致的。假设 CPU 是 16 核，业务线程 8 个，每个线程推理时默认创建 16 个 OpenMP 线程，总共有 128 个线程在抢 CPU。上下文切换开销比推理本身还多。

经验参考：

• 如果你开 4 个业务线程，at::set_num_threads(4)；
• 如果你开 8 个业务线程，at::set_num_threads(2)；
• 如果模型是那种很难并行的小算子组成的，干脆 at::set_num_threads(1)，让多线程取代算子内并行，减少同步开销。

GPU 场景下，多线程最容易踩的坑是每份模型副本都把 at::cuda::stream() 切到默认流上，所有线程提交算子到同一个 stream，导致 GPU 上任务相互排队。可以先检查 GPU 利用率，如果利用率高但吞吐没涨，瓶颈可能在多个线程同时向同一个 stream 串行提交。解决方法是每个线程维护一个独立 CUDA stream，并把输入输出先放到对应 stream 上，也就是 torch::cuda::CUDAStreamGuard 的使用。这个相对进阶，建议先从 CPU 线程模型切入验证思路，再移植到 GPU。

如果你用了每线程一个模型的方案，GPU 显存占用也会成倍增加。模型如果只有几十 MB，问题不大；如果有几个 GB，比如大型 Transformer，那克隆 8 份就是几十 GB，一般部署环境扛不住。这种时候建议换个思路：模型权重共享，但每线程有独立的“执行上下文”。但这在 libtorch JIT 层面并不好做，需要深入内部缓存机制，我建议先用单模型串行或 batching 服务方案，等业务规模确实有需求再走 TensorRT、Triton 这类专业推理框架。

5.4 多线程问题速查表

6. 一些个人实测的小建议

最后说几个我在实际项目中验证过、比较重要的体会。

如果你现在项目里已经用共享模型加锁跑着，并且业务量还能扛，可以先不动架构。但强烈建议你提前做好压力测试，把并发数压到两倍以上，看看什么时候开始崩。很多项目崩在线下压测测不出来，一上线就被流量打崩，就是因为线下压测并发数不够。

如果你刚开始设计一个新服务，建议直接把“线程 / 进程内隔离”写进架构约束里。每个业务线程只在初始化阶段访问一次模型副本，之后所有帧数据都通过队列进入线程自己的推理循环。这样你永远不需要考虑推理线程安全问题，因为模型实例从出生到销毁都只在单个线程里流动。我曾经在一个项目里用“每线程一个线程安全队列 + 每线程一个模型”的方式，把推理并发问题彻底从代码库里消除了，排查成本大大降低。

另外，torch::jit::load 和 torch::jit::clone 的耗时差异真的非常大，因此建议你在启动阶段把所有模型实例准备好。如果模型文件特别大，可以用 mmap 方式加载或考虑把多个实例预先加载到共享内存中，但这是另一篇长文的主题了。

我还有一个很日常但容易忘的操作：发布前在多线程压测环境里做一次输出一致性校验。随机准备一批样本，让每个线程推理同一份样本，统计输出的最大绝对误差。理想情况下，同一模型的不同副本输出应该完全一致。如果连这个都不一致，那问题可能出在参数复制、随机层、或没有在推理前固定随机种子等细节上。这个检查很简单，但能挡住很多问题。

libtorch 多线程推理说难，其实只要掌握了“实例独立 + 模式正确 + 线程池调优”这三个核心，就已经能应对绝大多数业务场景。真正复杂的部分是底层算子库和 CUDA stream 的部分，但这些通常会在性能压测阶段才暴露出来。希望这篇内容能让你少踩几个我踩过的坑。