TGI推理引擎压力测试：ShareGPT数据集准备与应用实战指南

如果你正计划对Text Generation Inference（TGI）推理引擎进行压力测试，却苦于找不到真实、结构化且富含多轮对话特征的数据集，那么开源社区里的ShareGPT数据集，无疑是当前最适配的选择。它源于真实的用户与AI对话，能很好地模拟线上请求的复杂性和多样性。

不过，直接拿ShareGPT的原始数据去“喂”给TGI是行不通的。两者在数据格式和结构上存在差异，需要经过一番精心的准备和转换。下面，我们就来详细拆解将ShareGPT数据集用于TGI压力测试的五个关键准备步骤。

一、验证ShareGPT数据格式兼容性

ShareGPT的原始数据通常以JSONL格式存储，每一行都是一个独立的对话样本。其内部字段结构（比如包含`human`和`gpt`角色的`conversations`列表）与TGI默认期望的Hugging Face格式并不完全匹配。如果直接使用，很可能会导致推理服务启动失败或请求解析异常。因此，格式转换是第一步。

首先，确保你已经下载了ShareGPT-90k这类清洗过的数据集，文件路径假设为`sharegpt_90k_clean.jsonl`。

接下来，核心任务是提取用户输入。你需要编写一个Python脚本，逐行读取JSON对象，并从中提取`conversations`字段里所有的`human`消息。这些消息就是模拟用户请求的源头。

然后，将每一条`human`消息封装成TGI能够识别的独立请求体。标准格式类似于：{"inputs": "用户提问内容", "parameters": {"max_new_tokens": 512}}。这里的`parameters`可以根据你的测试需求调整。

最后，将所有转换好的请求体写入一个新的JSONL文件，例如命名为`tgi_loadtest_inputs.jsonl`。务必确保每行只有一个合法的JSON对象，没有多余的逗号分隔，也没有外层的数组包裹。

二、构建多轮上下文模拟请求流

要知道，TGI本身并不维护会话状态。但真实的用户交互往往是多轮的，模型需要理解上下文才能给出连贯的回答。为了在压力测试中检验TGI的这种上下文感知能力（例如其prompt cache机制对前序KV缓存的复用效果），我们必须手动构造包含历史对话的长prompt。

具体怎么做呢？先从ShareGPT数据集中随机挑选出100个包含3轮及以上对话的优质样本。

针对每一个样本，严格按照对话发生的顺序，拼接`human`和`gpt`的消息。关键一步是，必须为这些消息添加正确的角色标记，例如`[INST]...[/INST]`或`<|user|>...<|assistant|>`。这完全取决于你将要部署的模型所使用的分词器（tokenizer）协议，必须严格匹配。

拼接完成后，使用对应模型的`AutoTokenizer`对文本进行编码，计算token长度。为了确保测试的有效性，需要过滤掉那些总长度超过模型上下文窗口（context window）80%的样本，避免因长度截断影响测试结果。

将剩余的、长度合适的样本保存为新的JSONL文件，比如`tgi_multiturn_prompts.jsonl`。每行的格式应为：{"inputs": "完整上下文字符串", "parameters": {...}}。

三、生成不同长度与复杂度的请求变体

如果所有测试请求的长度和复杂度都差不多，那就像只用一种重量测试举重运动员，无法全面暴露其极限。TGI内部的动态批处理（dynamic batching）和PagedAttention内存管理等机制，在面对不同负载时表现可能迥异。

因此，我们需要根据ShareGPT数据中真实指令的分布情况，构造出能覆盖多种场景的测试子集：

短平快的问答：模拟简单的信息查询。
中等长度的推理：模拟需要多步思考的问题。
长上下文摘要：模拟基于长文档的归纳总结。

首先，统计数据集中所有`human`消息的token长度分布，找到三个关键分位点，例如P25（约32 tokens）、P50（约68 tokens）和P90（约215 tokens）。

接着，分别筛选出长度落在这三个区间的请求各1000条，保存为三个独立的文件：`short_qa.jsonl`、`reasoning.jsonl`和`long_summary.jsonl`。

为了更贴近现实，还可以对`long_summary.jsonl`中的请求做一些“加料”——随机注入1到2个干扰句或无关的背景描述。这能模拟真实用户输入中常见的噪声，确保TGI的输入清洗（input sanitization）逻辑能在测试中被充分激活。

最后，别忘了用`jq`这样的命令行工具校验一下生成文件的语法。例如，执行jq -r 'keys' short_qa.jsonl | head -n 1，应该返回["inputs", "parameters"]，以确保格式完全正确。

四、注入系统提示词与工具调用模拟字段

ShareGPT的部分对话样本包含了`system`字段（系统指令）或`tools`描述（工具调用定义）。然而，TGI默认可能会忽略这些元信息。如果你的压力测试目标包含了对自定义系统提示词生效性的验证，或者需要测试function calling的兼容性，就必须主动将这些信息嵌入到请求中。

对于含有`system`键的样本，需要将其值提取出来，并按照模型要求的格式进行封装。例如，格式化为"<|system|>{system_content}<|end|>"，然后将其前置拼接到`inputs`字段的开头。

对于含有`tools`字段的样本，则需要按照TGI所支持的`tool_choice`参数规范，在`parameters`字段中显式地添加"tool_choice": "auto"以及具体的"tools": [...]列表。

完成拼接后，务必再次检查`inputs`的总长度是否超出了模型的最大位置嵌入（position embedding）限制。如果超限，应策略性地截断末尾非关键性的描述语句，优先保留核心指令和上下文。

将处理好的这些专门用于测试高级功能的样本，保存到如`tgi_system_tools_testset.jsonl`这样的独立文件中。这样，你就能清晰地评估TGI对ShareGPT中这些高级元数据的支持边界了。

五、校验token级一致性与编码偏差

这是至关重要却又常被忽视的一步。同一段文本，经过不同的tokenizer处理，产生的token数量可能会有显著差异。如果测试客户端本地计算的token长度与TGI服务端实际处理的长度不一致，会导致预期的批处理大小（batch size）失真，进而使测得的吞吐量、延迟和显存占用等关键指标失去准确性。

因此，必须保证校验环节与TGI服务端使用完全一致的tokenizer。

首先，确认TGI容器内加载的模型ID（例如`meta-llama/Llama-3-8b-Instruct`），并从Hugging Face仓库拉取对应的`tokenizer.json`或`tokenizer.model`文件。

接着，在本地环境复现这个tokenizer实例，用它对你准备好的`tgi_loadtest_inputs.jsonl`中的所有`inputs`字段执行编码（encode）操作，并精确记录每条请求的`input_ids`长度。

然后，进行数据清洗：剔除那些token数为0（空请求）或超过你设定上限（例如4096）的异常请求。用清洗后的数据生成一个纯净的最终测试集，可以命名为`tgi_validated_inputs.jsonl`。

最后，计算这个最终集合的平均token长度和标准差。在压力测试运行后，将此数据与TGI日志中实际观测到的`batch_token_size`等指标进行比对。如果偏差超过±5%，就需要立刻检查双方使用的tokenizer版本和配置是否完全一致。这一步的严谨性，直接决定了压力测试结果的可靠度。

来源：互联网