# LLM推理批处理基准测试：从第一性原理量化连续批处理的性能收益

> 一个可复现的LLM推理批处理基准测试项目，通过对比Hugging Face静态批处理与自定义连续批处理调度器，量化分析了批处理策略对延迟、吞吐量、GPU内存和KV缓存的影响。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-06-03T19:42:58.000Z
- 最近活动: 2026-06-03T19:50:45.840Z
- 热度: 145.9
- 关键词: LLM推理, 批处理, 基准测试, 连续批处理, vLLM, 性能优化, TTFT, 吞吐量, KV缓存, GPU内存
- 页面链接: https://www.zingnex.cn/forum/thread/llm-9f0ca3ee
- Canonical: https://www.zingnex.cn/forum/thread/llm-9f0ca3ee
- Markdown 来源: ingested_event

---

## 原作者与来源

- 原作者/维护者：prasannakotyal
- 来源平台：GitHub
- 原始标题：llm-inference-benchmarking
- 原始链接：https://github.com/prasannakotyal/llm-inference-benchmarking
- 来源发布时间/更新时间：2026-06-03

## 研究背景与问题定义

在大语言模型（LLM）推理服务中，批处理（Batching）是提升吞吐量和资源利用率的核心技术。传统的静态批处理要求所有请求具有相同的序列长度，而连续批处理（Continuous Batching）允许在批次执行过程中动态加入新请求，显著提高了GPU利用率。

然而，批处理策略的选择涉及复杂的权衡：更大的批次可以提升吞吐量，但可能增加首个Token的延迟（TTFT）；连续批处理虽然更灵活，但在请求长度差异较大时可能产生额外的调度开销。这些权衡关系需要通过系统性的基准测试来量化。

该项目正是为了回答这些关键问题而诞生：不同的批处理策略在实际硬件上的表现如何？连续批处理相比静态批处理能带来多大的性能提升？这些收益是否在所有场景下都成立？

## 方法论：可复现的测试框架

项目设计了一套完整的可复现测试框架，核心特点包括：

### 双后端对比设计

测试对比了两种PyTorch执行路径：

- **hf-static**：使用Hugging Face Transformers的标准静态批处理，所有请求必须具有相同的输入长度
- **continuous**：自定义实现的KV缓存调度器，支持在批次运行期间动态加入新请求，模拟vLLM和SGLang风格的连续批处理行为

值得注意的是，自定义调度器完全基于标准PyTorch实现，没有使用vLLM或SGLang的自定义CUDA内核，这使得测试结果更具普适性，也便于其他开发者理解和复现。

### 合成提示设计

测试使用合成Token ID而非自然语言提示，这一设计决策具有多重考量：

- **长度精确控制**：可以精确控制输入序列的长度，不受tokenizer分词差异的影响
- **可复现性**：相同的测试配置在任何环境下都能产生完全相同的输入
- **独立性**：测试结果不依赖于特定tokenizer的行为特性

### 测试参数矩阵

测试覆盖了完整的参数空间：

- **模型规模**：Qwen2.5-0.5B和Qwen2.5-1.5B两个参数量级
- **提示长度**：64、256、512个Token
- **批次大小**：1、4、8
- **并发请求数**：4、8、16
- **生成目标**：每个请求交替生成16或32个Token

这种全面的参数覆盖确保了测试结果的普适性和指导价值。

## 硬件环境与配置

测试在RunPod云平台上执行，具体配置如下：

- **GPU**：2x NVIDIA RTX PRO 4000 Blackwell，每卡24,467 MiB显存
- **驱动版本**：580.159.04
- **CUDA版本**：13.0
- **PyTorch**：2.12.0+cu130
- **Transformers**：5.10.1
- **精度**：FP16

所有测试结果、原始数据和可视化图表都完整记录在项目的results/和assets/目录中。

## 关键发现与数据分析

### 发现一：批处理对吞吐量的决定性影响

测试数据清晰地表明，批处理是提升吞吐量的最关键因素。以Qwen2.5-0.5B为例：

- 批次大小从1提升到8，吞吐量从约50 tokens/sec提升到280+ tokens/sec，提升幅度超过5倍
- Qwen2.5-1.5B上同样观察到显著收益，从约42 tokens/sec提升到240+ tokens/sec

这一发现验证了批处理在LLM推理中的核心价值，也为生产环境的配置优化提供了量化依据。

### 发现二：TTFT与队列深度的关系

当并发请求数超过活跃批次容量时，TTFT（首个Token生成时间）显著增加：

- 在提示长度512、批次大小8、并发数16的配置下
- Qwen2.5-0.5B的平均TTFT达到约368ms
- Qwen2.5-1.5B的平均TTFT达到约480ms

这表明在高压场景下，请求队列管理策略对用户体验有直接影响。

### 发现三：KV缓存内存的线性增长

测试量化了KV缓存内存随提示长度的线性增长关系：

**Qwen2.5-0.5B**：
- 64 Token提示：每请求1.11 MB
- 512 Token提示：每请求6.36 MB

**Qwen2.5-1.5B**：
- 64 Token提示：每请求2.60 MB
- 512 Token提示：每请求14.85 MB

这一数据对于容量规划和显存管理具有直接指导意义。

### 发现四：连续批处理的场景依赖性

最有趣的发现是连续批处理的性能表现具有强烈的场景依赖性：

**表现优异的场景**：
当活跃请求的序列长度保持对齐时，连续批处理与静态批处理性能相当甚至略优。例如Qwen2.5-1.5B在提示64、批次8、并发8的配置下，连续批处理达到248.0 tokens/sec，静态批处理为241.2 tokens/sec。

**表现不佳的场景**：
当请求长度差异较大时，Python实现的调度器需要将活跃请求按缓存长度分组处理，导致吞吐量显著下降。在提示512、批次8、并发16的配置下，连续批处理的吞吐量从静态批处理的275.9 tokens/sec下降到145.1 tokens/sec。

这一发现揭示了连续批处理实现中的关键挑战：请求长度的异构性会抵消连续批处理的理论优势。

## 工程实践价值

### 可复现性保证

项目使用uv进行依赖管理，通过pyproject.toml和uv.lock锁定所有依赖版本，确保任何人在任何时间都能复现相同的测试结果。

### 自动化测试脚本

项目提供了完整的测试脚本：

- `run_smoke.sh`：快速冒烟测试，验证环境配置正确
- `run_runpod_suite.sh`：完整的基准测试套件
- `run_runpod_qwen_1_5b_suite.sh`：更大模型的扩展测试

### 数据可视化

测试结果被整理为多种图表形式：

- 吞吐量对比图
- TTFT分布图
- ITL（Token间延迟）热力图
- KV缓存增长曲线
- 峰值内存使用图

这些可视化帮助快速识别性能模式和异常点。

## 对生产部署的启示

### 批处理策略选择

基于测试结果，可以得出以下实践建议：

1. **优先使用批处理**：无论选择哪种策略，批处理带来的吞吐量提升都是巨大的
2. **请求长度对齐很重要**：如果使用连续批处理，尽量保证请求长度的一致性，或实现智能的请求分组策略
3. **监控队列深度**：当并发请求超过批次容量时，TTFT会显著增加，需要配置适当的背压机制

### 容量规划参考

测试提供的KV缓存和内存使用数据可以直接用于容量规划。例如，服务Qwen2.5-1.5B模型处理512 Token提示时，每请求需要约14.85 MB的KV缓存，这意味着24GB显存的GPU在批次大小为8时，仅KV缓存就会占用约120 MB，加上模型权重和激活值，需要仔细计算可用容量。

## 技术局限与未来方向

项目文档诚实地指出了当前实现的局限性：

- **Python调度器开销**：自定义的连续批处理调度器使用纯Python实现，在请求分组时产生额外开销
- **未使用优化内核**：未集成vLLM或SGLang的自定义CUDA内核，这些内核可能提供更好的性能

未来的改进方向包括：

- 集成更高效的调度实现
- 测试更大规模的模型（7B、13B级别）
- 探索动态批次大小调整策略
- 添加多GPU并行推理测试

## 总结

这个项目通过严谨的实验设计和全面的数据分析，为LLM推理批处理策略的选择提供了量化的决策依据。其核心贡献不仅在于具体的性能数字，更在于建立了一套可复现、可扩展的基准测试方法论。

对于正在构建或优化LLM推理服务的工程师来说，这些测试结果提供了宝贵的参考数据，帮助在实际场景中找到延迟、吞吐量和资源利用率之间的最佳平衡点。