Dynamic Batching不能靠torch.nn.DataParallel实现，因其仅支持静态多GPU并行，要求输入提前pad对齐且batch size固定；而Dynamic Batching需在推理入口层异步攒批、动态对齐、统一前向与结果拆分。
PyTorch模型服务中Dynamic Batching为什么不能靠torch.nn.DataParallel解决
Dynamic Batching的核心是运行时合并不同长度/尺寸的请求（比如不同长度的文本、不同分辨率的图像），而torch.nn.DataParallel只做设备级并行（多GPU复制模型+分batch维度），输入仍需提前pad对齐、固定batch size。它不感知请求到达节奏，也不动态攒批——本质是静态batch，和dynamic无关。
真正需要的是：在推理入口层拦截请求、暂存、按时间窗或数量阈值触发合并、统一预处理（如pad到当前批最大长度）、送入模型一次前向，再拆分结果返回。这必须自己搭调度逻辑，不能依赖PyTorch内置并行模块。
用asyncio.Queue + 后台任务实现低延迟攒批
关键不是“越快越好”，而是平衡延迟与吞吐：等太久用户等不及，太急则batch太小失去收益。推荐用异步队列配合周期性检查任务，比纯线程sleep更可控。
- 每个请求封装为
dict（含原始输入、callback或future句柄、timestamp）入队 - 后台
asyncio.create_task每10ms轮询一次队列，若积压≥4个或最老请求超15ms，就取出当前全部请求 - 提取输入字段（如
texts），用torch.nn.utils.rnn.pad_sequence或自定义pad逻辑对齐，生成input_ids等tensor - 模型前向后，用原始请求顺序反向索引输出，调用各自callback
注意：模型必须支持batch_size > 1且内部无状态（如没用nn.LSTM的hidden跨样本传递）。若用Hugging Face transformers，确保model.config.is_decoder == False（encoder-only模型天然适合）。
transformers.Pipeline不支持Dynamic Batching，但可复用其预处理
transformers.Pipeline是单请求封装，内部会为每个调用单独tokenize → tensor → forward → decode。直接拿它套dynamic batching会重复初始化tokenizer、反复调用__call__，反而增加开销。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
正确做法是剥离预处理：用pipeline.tokenizer的__call__方法批量处理list of texts，传return_tensors="pt"和padding=True，得到已pad的batch tensor；再手动送入pipeline.model。这样避免pipeline的额外封装层，也方便你控制pad策略（比如用padding="longest"而非"max_length"）。
示例关键行：
inputs = pipeline.tokenizer(
batch_texts,
return_tensors="pt",
padding="longest",
truncation=True,
max_length=512
)
outputs = pipeline.model(**inputs)
CPU/GPU内存碎片和torch.cuda.empty_cache()的误用风险
动态batch大小浮动时，GPU显存分配不连续，容易产生碎片。有人想定期调torch.cuda.empty_cache()清理，这是危险操作：它不释放被tensor占用的显存，只回收缓存池里未被引用的块；且强制同步，拖慢吞吐。实际有效手段只有两个：
- 预估最大可能batch size，在服务启动时用dummy input warmup，让CUDA缓存分配好大块显存
- 用
torch.compile(model, dynamic=True)（PyTorch 2.2+）让编译器适配不同shape输入，减少重编译开销
真正要监控的是torch.cuda.memory_allocated()趋势——如果随请求增长持续上升不回落，说明有tensor没被释放（比如闭包里意外持有output），这才是该查的泄漏点。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
