在大型语言模型（LLM）部署的实际场景中，评估推理服务的吞吐量和延迟至关重要，尤其是当系统需要处理高并发请求时。传统负载测试往往依赖具体提示数据，这限制了灵活性。而 Tokenflood 作为一个专为指令调优 LLM 设计的负载测试框架，通过模拟任意 token 洪水负载，提供了一种高效的基准方法。它允许用户仅指定提示长度、前缀长度、输出长度和请求率，即可生成模拟工作负载，从而快速探索不同提供商、硬件配置或提示优化的影响。本文将聚焦于使用 Tokenflood 实现并发 token 洪水测试，讨论如何处理率限制并分布式部署多 API 端点，实现可扩展的性能基准。
Tokenflood 的核心优势在于其启发式负载生成机制。它不要求预先准备海量提示数据，而是使用单 token 字符串集（如空格加大写字母）来填充提示和前缀部分，确保生成的输入接近真实 token 分布。同时，附加一个固定任务（如“计数到 10000”）来控制输出长度。这种方法确保了测试的可靠性，因为非推理 LLM 的处理时间主要取决于输入输出长度和缓存机制，而非内容复杂性。通过这种方式，Tokenflood 可以模拟真实生产负载，例如电商推荐系统中的长提示查询或聊天机器人中的短响应交互。
要实现并发 token 洪水测试，首先需要安装 Tokenflood 并配置端点。安装命令简单：pip install tokenflood。对于自托管场景，如使用 vLLM 服务器，启动一个小型模型服务，例如 vllm serve HuggingFaceTB/SmolLM-135M-Instruct。然后，创建端点配置文件（endpoint.yml），指定提供商、模型和 base_url。例如，对于本地 vLLM：
provider: hosted_vllm
model: HuggingFaceTB/SmolLM-135M-Instruct
base_url: http://127.0.0.1:8000/v1
api_key_env_var: null
对于云提供商如 OpenAI，只需设置 provider: openai 和 model: gpt-4o-mini，并通过环境变量 OPENAI_API_KEY 提供密钥。Tokenflood 底层依赖 LiteLLM，支持 OpenAI、Anthropic、Bedrock 等数十种提供商，这使得测试跨平台基准变得无缝。
接下来，定义运行套件（run_suite.yml）来配置并发洪水负载。关键参数包括请求率阶段、测试时长和负载类型。请求率使用数组定义多个阶段，例如从 1 req/s 逐步增加到 10 req/s，每个阶段持续 10 秒。这允许观察吞吐量随负载增长的变化。负载类型指定 token 参数：
name: token_flood_benchmark
requests_per_second_rates:
- 1.0
- 3.0
- 5.0
- 10.0
test_length_in_seconds: 10
load_types:
- prompt_length: 2048
prefix_length: 1024
output_length: 128
weight: 1
- prompt_length: 4096
prefix_length: 2048
output_length: 64
weight: 1
percentiles:
- 50
- 90
- 99
input_token_budget: 500000
output_token_budget: 50000
error_limit: 0.3
task: 'Task: Generate a detailed summary of the following text.'
token_set:
tokens:
- ' A'
- ' B'
这里，weight 参数控制不同负载类型的采样比例，确保测试覆盖多种场景，如长提示高缓存 vs. 短提示低缓存。input_token_budget 和 output_token_budget 作为安全阀，防止测试超出预算。运行命令 tokenflood run run_suite.yml endpoint.yml 会生成结果文件夹，包括延迟分位数图（latency_quantiles.png）、请求 CSV 和摘要 YAML。这些输出帮助量化吞吐量，例如在 5 req/s 下，50% 分位延迟为 500ms 时，表示系统可稳定处理该负载。
处理率限制是并发测试的关键挑战。许多提供商如 OpenAI 有 TPM（Tokens Per Minute）和 RPM（Requests Per Minute）限制，直接洪水可能触发限流。Tokenflood 通过预估 token 使用并在启动前确认来缓解，但对于高并发，需要分布式策略。首先，使用多个 API 密钥分散负载：在端点配置中，通过 api_key_env_var 指定不同环境变量，如 OPENAI_KEY_1、OPENAI_KEY_2，然后在运行时设置多个端点文件，每个绑定一个密钥。LiteLLM 支持密钥轮换，Tokenflood 可扩展为多端点运行套件，虽需自定义脚本，但可通过并行进程实现，例如使用 Python 的 multiprocessing 模块同时运行多个 tokenflood run 实例，每个针对不同密钥。
对于分布式负载，进一步扩展到多端点：配置多个区域的端点，如 Azure 的欧洲和美国部署。端点 YAML 可添加 extra_headers 以选择特定模型变体。分布式测试时，监控全局吞吐量需聚合结果：每个实例输出独立 CSV，然后使用 Pandas 合并计算整体分位数。例如，假设两个端点各处理 50% 负载，总吞吐量为单端点两倍，但需注意网络延迟影响——Tokenflood 单独测量网络延迟（network_latency.csv），便于隔离推理 vs. 传输瓶颈。可落地参数包括：率限制阈值设为提供商的 80%（如 OpenAI gpt-4o-mini 的 30k TPM 限为 24k），轮换间隔 60s；分布式节点数基于预算，起始 2-4 个；错误率监控，每 30 请求检查，若超 30% 则回滚率。
在基准测试中，关注关键指标：吞吐量（tokens/s）、延迟分位（P50/P90/P99）和成本效率（$/query）。例如，测试自托管 Llama-3.1-8B 时，增加前缀缓存从 1024 到 2048 token 可将 P50 延迟从 1720ms 降至 1100ms，吞吐量提升 50%。分布式场景下，多端点可将总吞吐从 10 req/s 扩展到 40 req/s，但 P99 延迟可能因同步开销升 20%。监控清单：1) 预热请求验证端点可用性；2) 实时 token 使用仪表盘（集成 Prometheus）；3) 回滚策略：若错误率 >20%，降率 50%；4) 成本估算：运行前计算总 token * 单位价。
Tokenflood 的这种设计不仅适用于单机基准，还支持生产级模拟，如评估 Kubernetes 集群的 LLM 服务弹性。通过最小配置即可启动测试，它降低了 LLM 负载模拟的门槛，帮助工程师在部署前优化资源分配。实际落地时，建议从小规模预算（如 10k input tokens）开始，逐步 scaling，同时结合日志分析 token 偏差（目标 <10%）。
资料来源：基于 Tokenflood GitHub 仓库（https://github.com/twerkmeister/tokenflood）的官方文档和示例。