std::mutex+队列直接攒batch会卡死，因高并发下锁竞争导致等待远超推理时间，且固定等待触发易造成padding浪费或OOM；正确做法是分层缓冲、双阈值控制与按shape分组拼batch。
为什么 std::mutex + 队列直接攒 batch 会卡死或吞吞吐
动态批处理不是简单地等几个请求一起送进模型——GPU 显存和计算单元需要连续、对齐的输入，而用户请求到达时间、输入长度、batch size 都是随机的。如果只用一个 std::mutex 锁住全局队列，所有线程在入队/出队时争抢锁，尤其在高并发下，wait() 时间远超推理本身；更糟的是，若按固定等待时间（如 10ms）触发 flush，可能把刚到的长序列和短序列硬凑成 batch，导致 padding 过多、显存浪费甚至 OOM。
真正可行的做法是分层缓冲 + 时间/尺寸双阈值控制：
- 每个工作线程维护本地小队列（无锁
moodycamel::ConcurrentQueue或带松弛策略的boost::lockfree::queue），避免全局锁瓶颈 - 引入中央调度器（单线程或专用线程），周期性检查：当前待处理请求数 ≥
min_batch_size或 最老请求等待时间 ≥max_latency_ms - 合并时按输入 shape 分组（例如图像模型按分辨率分桶，NLP 模型按 token 数分段），只在同一桶内拼 batch，避免跨桶 padding
如何用 torch::jit::script::Module 支持变长输入拼接
PyTorch C++ API 默认要求 forward() 输入 tensor 的 batch 维必须固定，但动态批处理天然要拼不同请求。不能靠反复调用 forward() 单样本——那等于放弃批处理收益；也不能手动 pad 后堆叠再 forward——padding 会污染梯度（虽推理不用梯度，但影响输出精度和显存占用）。
正确路径是导出模型时启用 dynamic_axes 并在 C++ 端用 torch::stack() + torch::nn::functional::pad() 做结构化拼接：
立即学习“C++免费学习笔记（深入）”；
// 示例：拼接两个不同长度的文本 embedding 请求（shape [1, L1, D] 和 [1, L2, D]）
auto padded_a = torch::nn::functional::pad(a, torch::nn::functional::PadFuncOptions({0, max_len - L1}));
auto padded_b = torch::nn::functional::pad(b, torch::nn::functional::PadFuncOptions({0, max_len - L2}));
auto batched = torch::stack({padded_a, padded_b}, /*dim=*/0); // → [2, max_len, D]
注意：pad() 必须在 CPU 上完成（GPU pad 开销大且难同步），拼好再 .to(device)；且模型导出时需明确声明 dynamic_axes={"input": {0: "batch", 1: "seq"}}，否则 JIT 会固化 shape。
cudaStream_t 和 at::cuda::getCurrentCUDAStream() 怎么配合避免 GPU 同步阻塞
常见错误是每个 batch 推理后立刻调用 torch::cuda::synchronize()，这会让 CPU 死等 GPU 完成，吞掉所有并发潜力。动态批处理必须让数据搬运、计算、结果回传流水起来。
实操要点：
- 为每个推理任务分配独立
cudaStream_t（用cudaStreamCreateWithFlags(..., cudaStreamNonBlocking)） - 输入 tensor 拷贝用
tensor.to(device, /*non_blocking=*/true)，并指定 stream：tensor.copy_(host_tensor, /*non_blocking=*/true)→ 内部自动绑定当前 stream - 调用
module.forward()前，确保所有输入 tensor 已通过record_stream()关联到该 stream：input_tensor.record_stream(stream) - CPU 端不主动同步；用
cudaEvent_t标记完成点，由回调线程检测事件触发结果分发
漏掉 record_stream() 是最隐蔽的坑：Tensor 内存可能被后续 stream 提前复用，导致脏数据或 crash。
怎么防止 std::shared_ptr 生命周期错乱导致推理中途析构模型
多线程服务中，常把 torch::jit::script::Module 包在 std::shared_ptr 里传给工作线程，但如果主线程提前退出、或某个线程异常退出未释放引用，模块可能被意外析构，而 GPU kernel 还在跑——直接触发 CUDA illegal memory access。
安全做法只有两种：
- 全局唯一实例：用
static const std::shared_ptr<:jit::script::module></:jit::script::module>+std::call_once初始化，彻底规避引用计数竞争 - 若必须多实例（如多模型热加载），则用
std::weak_ptr在工作线程中临时升级：auto module = module_weak.lock(); if (!module) return; // 模块已卸载，并在每次 forward 前检查module->is_compiled()
别信“我只在主线程析构”，C++ 线程局部存储和 shared_ptr 的原子操作在高并发下极易暴露竞态——宁可多一次 lock，别赌内存安全。
