Agent 集群结合连续批处理将 LLM 任务时间缩短 36 倍

发生了什么

一位 LocalLLaMA 用户在 Intel B70 GPU（32GB VRAM）上对 Qwen 27B 进行了基准测试，对比了单用户聊天与使用连续批处理的 50 个 Agent 集群。单用户吞吐量测得提示词处理为 85.4 tokens/s，生成为 13.4 tokens/s，导致 50 个顺序任务（51,200 输入 token，25,600 生成 token）耗时 42 分钟。切换为 1 个协调器加 49 个并行 Agent 后，组合吞吐量提升至 1,100 tokens/s，在 70 秒内完成相同工作量——实现了 36 倍加速。由于批处理调度开销，首 token 延迟为 11 秒。

为何重要

运行本地推理的独立开发者和小型团队常将 LLM 视为单轮聊天机器人，导致 GPU 在请求间隙闲置。连续批处理（已是 vLLM 和 llama.cpp 服务器模式的默认功能）在多个请求同时到达时自动填补这些闲置容量。对于研究管道、代码审查工作流或文档处理而言，结论显而易见：并行化 Agent 任务比等待顺序响应更能有效利用硬件。只要工作负载结构得当，单张消费级 GPU 即可表现得像小型推理集群。

亚太视角

Qwen 27B 是阿里巴巴开发的模型，具备强大的中文及多语言性能，使该基准测试直接关联到中国、新加坡及东南亚构建本地优先应用的开发者。Intel B70 被定位为在 GPU 供应受限或昂贵市场中具有成本竞争力的 NVIDIA 替代方案。该地区构建 RAG 管道、法律文档分析或多语言客户支持工具的团队，可利用 vLLM 的 OpenAI 兼容 API 端点应用此批处理模式，无需修改客户端代码即可接受并发请求。本地运行 Qwen 27B 还能避免新加坡、日本和韩国等受监管行业关心的数据驻留问题。

本周行动项

使用 vllm serve Qwen/Qwen2.5-27B-Instruct --max-num-seqs 64 部署 vLLM 与 Qwen 27B，然后利用 Python 的 asyncio 和 httpx.AsyncClient 发送 10 个并发请求，以在承诺采用 Agent 框架前，测量实际的批处理吞吐量与顺序基线。