优化Qwen批量推理，其实只需要五步。如果你发现自家的千问模型在跑批量任务时速度慢、GPU利用率上不去、吞吐量跟并发不成正比，那大概率是批处理策略、调用方式或者环境配置没有适配模型的特性。别急，下面这几个实用技巧，能帮你把性能提上去。

先从最直接的调整说起。

一、切换为非流式调用模式

流式调用能实时吐token，体验确实好，但在批量处理场景下，它会带来大量的网络往返和状态维护开销。单个请求的延迟会被拉高，整体吞吐也被卡在通信瓶颈上。换成非流式调用，模型一次性收完整输入，一次性返回最终结果，通信和调度成本直接降下来。

具体操作上，先确认当前调用中 streaming 参数已设为 False；如果用了 LangChain 这类封装库，将 ChatOpenAI 或类似 LLM 实例的 streaming 显式置为 False；在原始 transformers 调用中，直接使用 model.generate() 并确保没有启用 streamer 或 callback；最后验证输出是否为完整的字符串，而不是生成器对象——确认无误，就算切成功了。

二、动态调整批处理大小（Batch Size）

Batch size 这个参数，直接平衡着 GPU 计算密度和显存占用。太小了计算单元喂不饱，太大了要么 OOM，要么 padding 导致无效 token 比例飙升。最稳妥的做法是根据你的输入长度分布和显卡显存，实际测试一下。

准备一组典型样本，至少 32 个查询-文档对或指令输入；依次测试 batch_size = [1, 2, 4, 8, 16, 32] 下的平均端到端延迟和 GPU 显存峰值；记录每轮有效 tokens 占比（非 padding tokens / 总 input tokens）；最后挑选一个显存安全、有效 tokens 占比 ≥ 85%、且延迟增幅已趋于平缓的值，作为最终设定。

三、启用半精度加载与推理（FP16）

千问系列模型在 FP16 模式下，几乎无损生成质量，同时显存占用能降一半，矩阵运算吞吐也会提升，省出来的显存还可以拿来加大 batch size 或者拉长上下文。一举多得。

加载模型时指定 torch_dtype=torch.float16；确保 tokenizer 输出的 input_ids 张量也在同一设备和 dtype；在 model.generate() 中显式传入 torch_dtype=torch.float16（如果用 vLLM 则在 engine 初始化时设置 dtype）；万一出现 NaN 输出或 loss 爆炸，换成 bfloat16（torch.bfloat16），它的动态范围更宽，兼容性也更好。

四、精简依赖与禁用冗余组件

对于千问的小参数模型（比如 Qwen3-0.6B、Qwen3-Reranker-0.6B），vLLM 的 PagedAttention、bitsandbytes 的量化调度层这些重型组件根本用不上。硬塞进去只会增加内存拷贝和调度延迟，在轻量模型上，负面效果尤其明显。

建议把 vllm、bitsandbytes、flash-attn、xformers 等非必需包直接卸载掉；只保留 transformers、torch、sentencepiece 三个核心依赖；检查一下 PYTHONPATH 和环境变量，将 TOKENIZERS_PARALLELISM=true 这类可能引发 tokenizer 多进程锁竞争的设置清掉；启动前执行 os.environ.pop('TOKENIZERS_PARALLELISM', None) 强制关闭 tokenizer 并行。

五、预填充输入并统一序列长度

批量内各输入长度差异一拉大，padding 就会产生大量无效计算，白白浪费 GPU 资源。通过截断长文本、补齐短文本到统一长度，能显著提升 GPU warp 利用率和 cache 命中率，在重排序（rerank）这类任务上效果尤其突出。

先统计训练/线上请求中 input tokens 长度的 95 分位数，设为目标 max_length；调用 tokenizer 时设置 truncation=True、padding='max_length'、max_length=目标值；对于短于目标值的样本，在左侧或右侧填充 tokenizer.pad_token_id（注意 reranker 类模型通常需要 left-padding）；最后验证 padding 后的 attention_mask 是否正确屏蔽了 pad token，确保其不参与计算。

这五步执行下来，千问模型的批量推理性能基本就能拉满了。从实际经验看，大多数场景下用上这三板斧，吞吐量翻倍并非难事。当然，具体数值还得根据你的硬件和数据特点微调，但方向对了，结果就不会差。