面向LLM服务研究的数据集中心：从请求流到可复现实验

搞过LLM服务落地的朋友应该都有体会费了很大劲把推理服务部署上线之后想认真做一轮实验评估比如对比不同调度策略、分析KV缓存命中率、验证某个批处理优化到底能省多少时间结果最先卡住的往往不是算法而是没有一份像样的实验数据。手头要么是训练用的文本语料要么是几段被反复复制过的人工提问根本没法用于有意义的系统级测试。这就是我着手搭一个“A dataset hub for LLM serving research”的初衷。简单说这不是一个给模型喂文本的数据集而是一个专门给推理服务系统做实验用的数据集合里面有真实的请求流、请求样本、服务日志和配套元数据能让调度、缓存、并发、延迟这类研究有据可依。适用人群很明确做推理系统开发的同学、研究低延迟优化的研究生、以及任何想把自己的Serving框架跑出可信结论的人。我先把这个数据集中心的完整设计思路、搭建过程、踩过的坑和实际用法展开讲争取看完后你能直接照着一套逻辑搭出自己的实验数据底座。1. 先想清楚服务研究到底需要什么样的数据1.1 训练数据与服务数据是两套逻辑很多人第一反应是数据集嘛网上到处都是随便抓几份不就行了。这里有个本质误区。语言模型训练需要的是文本语料追求的是多样性、领域覆盖和文本质量而服务系统研究所需要的是能够反映线上推理负载特征的请求数据。它们关心的维度完全不同。服务数据最核心的几个维度是请求什么时候到达、输入输出有多长、请求之间是否存在共享前缀、模型回答的终止原因是什么、排队等了多久、TTFT首令牌延迟是多少、中间是否命中了KV缓存。训练数据里完全没有这些东西。举一个很直观的例子你想研究连续批处理策略下GPU利用率的优化空间。你的实验需要对一组真实到达的请求进行调度这组请求的到达时间分布会直接影响批处理窗口、排队策略和抢占次数。如果你拿的是人工构造的均匀间隔请求实验结论跟生产环境会有巨大偏差。这就是服务研究需要专门数据集的根本原因——它研究的是系统行为不是模型能力。1.2 为什么公共数据集都“差一口气”我并不否认网上有不少能用的公开资源。比如ShareGPT这类对话数据集包含了大量真实用户与模型的交互文本LongBench提供了覆盖长上下文的任务集LMSYS之类的评测数据也有不少真实提示词。但这些数据集做服务实验时会遇到几个现实问题。第一个问题是缺少时间维度。绝大多数公开请求数据集只包含“提示词回答”没有请求到达时间戳你没法还原真实的并发负载只能自己额外生成一个到达模型这本身就引入了噪声。第二个问题是缺少服务端观测信息。你研究KV缓存复用率的时候需要知道每条请求在前缀树里命中了多少token、有没有走缓存逻辑你研究调度策略时需要知道排队延迟、预填充耗时、解码耗时。公开数据集通常完全没有这些字段。第三个问题是格式不统一。不同来源的数据字段命名混乱token计算方式也不一致。有的按词数估算有的用不同tokenizer重新编码有的还把对话轮次和系统提示混在一起。你拿这些数据做实验之前光清洗和标准化就要花掉大量时间。第四个问题是授权和合规。部分对话数据有使用限制有些甚至不允许用于模型训练或系统研究。在使用公共数据时如果只图省事后面可能有合规风险。也就是说公共数据集能解决“有哪些文本”的问题但解决不了“请求长什么样、系统表现如何”的问题。服务研究的数据需求必须专门建设。1.3 数据中心的定位不是存储是可复现实验的基准把“一个数据集中心”理解成一个文件仓库是对它的低估。真正能让服务研究受益的数据中心应该达到三个目标。第一任何一条实验数据都能被单独加载和分析带上完整上下文。查看一条请求记录时不光能看到文本还能看到它属于哪个请求流、什么服务条件、命中情况如何。第二同一份数据可以被不同的实验复用和对比。A组做调度实验、B组做缓存实验他们跑的是同一批请求这样两组结论之间才有可比性。这种“共享负载”本身就是服务系统实验里很关键的元素。第三数据要能支撑结果复现。服务系统的实验特别容易受环境和输入变化影响。数据集中记录的请求顺序、随机种子、参数设置都要足够详细保证你在相同条件下能跑出接近的结果。所以我在设计这个数据集中心时给自己的定位是它不是一个被动存放数据的仓库而是从实验需求倒推出来的一套数据基础设施。2. 数据集中心怎么设计才用得上2.1 三类核心数据形态服务研究的实验目标不同对数据形态的要求也不同。我按实验场景拆下来发现至少需要三类数据。第一类叫请求流数据。这是带时间戳的连续请求序列每一条请求有到达时间、完成时间、排队时长、服务时长等信息。它主要服务于调度实验、负载均衡实验、过载模拟实验。你把这段请求流灌给一个推理服务它就能在接近真实负载的条件下接受调度考验。第二类叫单请求样本池。这是大量独立的请求样本每一条有明确的输入内容、期望输出长度分布、使用的模型和参数。这类数据用于对服务做压测比如固定并发数下测最大吞吐、测不同输入输出长度组合下的延迟曲线。这个池子里的请求不需要有连续的时间关系它们只负责“在指定强度下提供稳定不变的负载”。第三类叫服务日志数据。这是已完成的真实服务运行记录包含调度结果、缓存命中情况、资源占用、各阶段耗时。服务日志更多用于行为分析比如看看系统中哪一类请求最容易被队列拖延、前缀命中率在什么场景下最高、不同类型的结束原因对算力效率的影响。三类数据各有侧重又在字段上保持一致这样就可以在同一个框架内做交叉验证。2.2 一条记录该有哪些字段具体到一条请求记录我最终设计成了下面这样的结构。这个JSON格式是数据中心里的基础单元无论哪类数据都会落到这个统一结构上。{ request_id: req_00001234, timestamp: 2024-11-18T03:12:45.128Z, arrival_order: 12345, client: { region: ap-east, sdk_version: openai-python-1.35.0, api_key_hash: a3f2c9 }, model: llama-3.1-8b-instruct-fp8, endpoint: /v1/chat/completions, sampling: { max_tokens: 512, temperature: 0.7, top_p: 0.9, top_k: 40, stop: [|eot_id|] }, messages: [ {role: system, content: You are a helpful assistant.}, {role: user, content: 请用三句话总结这份文档}, {role: assistant, content: 文档主要内容是...}, {role: user, content: 能不能再口语化一点} ], completion: { finish_reason: stop, content: 口语化一点的总结版本..., usage: { prompt_tokens: 218, completion_tokens: 176, cached_tokens: 60, total_tokens: 394 } }, server_metrics: { scheduler: priority_fcfs, queue_delay_ms: 32.4, prefill_dur_ms: 145.2, decode_dur_ms: 710.8, ttft_ms: 190.6, cache_hit: true, kv_cache_hit_ratio: 0.275, gpu_util: 0.87 } }字段的设计逻辑其实很清晰。timestamp 和 arrival_order 是重放请求流的基础缺少任何一个你都无法还原并发特征。client 和 model 用于后续按用户画像或模型版本做分组分析。sampling 参数必须记录因为同一个请求在temperature非法或非法参数下模型返回变化很大会直接影响token数分布。messages 是请求原文必须是模板展开后的完整形态不能只存用户最后一句话。completion.usage 里的 cached_tokens 特别重要。现在很多推理框架都支持前缀缓存cached_tokens 记录的是这次请求命中了多少缓存 token这直接决定服务端实际需要做多少预填充。如果这个字段缺失任何关于缓存优化效果的分析都无从谈起。server_metrics 里的耗时拆解是服务研究里最珍贵的一层数据。queue_delay_ms 反映调度压力prefill_dur_ms 反映输入处理算力decode_dur_ms 反映逐token生成开销ttft_ms 则是用户感知的“首字延迟”。有了这几个数字你才能把一条请求的整段生命周期拆开看而不是糊在一起看一个总耗时。2.3 数据组织方式与命名规范设计是骨架目录结构是肌肉。一开始我打算把所有数据堆在一起后来自测了几次发现找一条请求都快找疯了就重新按场景分了层。数据集中心的根目录下我按经典数据集中心的范式分成三个大的集合flows存放请求流数据samples存放单请求样本池logs存放真实服务日志。每个集合下再按“来源渠道/业务场景/日期”细分。比如 flows/chat_qa/2025-01/、samples/code_agent/2025-03/。这样组织的好处是你可以直接扫目录就知道有哪些可用的实验数据也能在报告里精确写出自己用的是哪一份。我还给每个数据集配了一个 README包含六项必填信息采集时间范围、请求总量、平均输入输出长度、模型版本、脱敏说明、使用限制。这六项信息在实际协作中特别有用很多人拿到数据集不关心这六项实验做到一半才发现数据根本不符合前提浪费大量时间。为数据集打标签也很重要。一个请求数据集里可能混合了不同服务场景的数据我给每条请求加了一个 scenario 字段标记它是对话、代码生成、摘要、工具调用里的哪一类。这样在做子实验时不需要把所有数据装到系统里跑一遍直接过滤就能快速选取自己需要的子集。2.4 为什么要记录这些服务端指标有人可能会问记录请求本身不就行了吗为什么还要记录服务端的耗时和缓存指标这里有一个关键点——服务研究不仅需要知道“系统接收了什么请求”更需要知道“系统在这条请求上表现如何”。举个例子如果你想对比两种调度算法的优劣但数据里只有请求内容没有每条请求在算法A下的服务指标你只能重新跑一遍实验。而服务日志数据把这些结果都记录下来你就可以直接基于历史结果做分析不必每次都从零开始跑。更重要的是有了服务端指标你可以做跨时间的对比实验这在Serving系统长期演进时价值极高。3. 从零搭一个数据中心的实操过程3.1 第一步从网关日志里把请求捞出来数据中心的建设最难的往往不是设计而是采集。我给自己的生产服务网关加了一个旁路记录模块把所有通过 /v1/chat/completions 进来的请求在方法级别打了一份快照日志。终端层面我用的是OpenAI兼容接口所以日志天然就有 request body 和 response body 两段JSON。但要注意一个坑直接记录原始request body里经常会带上未脱敏的内容。我在打快照之前先做了一次字段清洗把含有敏感信息的字段直接丢弃只保留模型选择、消息数组和采样参数。这步处理在数据采集阶段做远比后置清洗高效。网关日志还需要和上游推理引擎的指标做关联。我在服务端给每条请求下发了一个全局唯一的 trace_id通过响应头的x-trace-id返回给网关网关日志里记下这个ID。后面分析的时候只要用trace_id关联服务端记录就能拿到预填充耗时、解码耗时、缓存命中这些信息。这一步相当于给请求数据装了一张“体检单”。如果你没有现成的生产服务也可以从已有公开数据集出发但要自己在外部挂一层模拟网关生成请求流。比如把ShareGPT或LongBench里的真实用户提示抽出来打上时间戳并注明是模拟负载然后再跑实验。这种方式得到的数据在loader层面没有本质差别只是采集来源不同。3.2 第二步清洗、对齐与脱敏原始日志拿到手之后直接入库会导致很多后患。我在第二次整理时把清洗流程规范化成了四步。第一步是剔除自动化监测请求。常见的监听探测会带特定user-agent或者固定的检查文本这些请求对负载分析会产生强烈干扰。尤其是健康检查请求通常非常短如果把几千个健康检查混入请求流会在调度实验里凭空制造出大批量短任务严重拉低平均延迟。我专门维护了一个“噪音规则库”一次性把这类异常自动化请求在采集阶段就过滤掉。第二步是统一token计算。不同的框架和模型tokenizer算出来的token数不一致我的做法是统一用一份采样时的tokenizer配置对原文重新编码算出标准token数。如果你记录的是重新编码后的统计值那后续在不同框架间做对比实验时token口径就能对齐。第三步是字段对齐。网关日志、引擎指标和请求原文往往来自不同文件需要按照trace_id让三者对齐。这一步看似简单实际做的时候很容易遇到时间戳时区不一致、耗时字段单位不一样毫秒vs秒、JSON字段大小写不统等等问题。我最后的方案是在采集侧就统一输出成标准JSON不做事后转换。第四步是脱敏。用户提问里会包含很多个人信息的可能性。我在存储前用一组正则和黑名单做检测能替换的直接替换不能判断的整段丢弃。脱敏宁可激进不可保守因为一旦对外发布的数据里有漏网之鱼会直接影响整个数据中心的信用。这三步走完以后才是真正可以用于实验的干净数据。3.3 第三步把绝对时间改造成可重放的相对时间轴请求流数据最核心的能力是“重放”。所谓重放就是把一段真实请求流按记录时的到达特征重新灌给一个测试服务模拟生产负载。但是绝对时间戳有一个问题真实请求流可能有闲忙时段之分如果你按原始时间精确回放往往要跑好几个小时才能覆盖一个有代表性的高峰和低谷这样的实验周期太长了。我用的做法是引入一个压缩系数把整个请求流的时间轴压缩到一个可接受的实验时长内。比如原本6小时的流量压缩到30分钟里重放压缩系数就是12。你只需要把每条请求记录的相对时间偏移除以压缩系数就能得到新的到达时间点。压缩后的请求组里仍会保持原始曲线的峰谷特性这一点对调度算法实验很重要。不过这里也有个前提压缩后的请求间隔如果太小服务可能来不及处理系统行为会从“正常排队”退化成“全量积压”。所以压缩系数的上限要根据你所测系统的实际吞吐能力来定。我先跑一次低压缩系数的预测试看系统能不能维持基础处理再逐步提高压缩倍数。3.4 第四步导入索引与检索数据量上去后简单的文件扫描已经不能满足使用需求了。我最终搭建的版本里给数据集加了一层轻量的元数据索引使用了SQLite组织索引中记录每条请求的ID、所属数据集、请求类型、输入长度、输出长度、到达时间、标识字段。这样写论文或做实验报告时可以很方便地统计数据集规模不需要每家团队都去解析全部原始文件。同时我把原始数据文件统一转换成JSONL格式每条记录一行。这个格式的好处是既能被Python脚本逐行处理又不至于因为单文件过大导致无法加载。同时我保留了Parquet格式的导出副本给数据分析阶段使用。如果你的实验环境以Pandas/Spark为主直接读Parquet会更方便。4. 用数据中心做几个真实服务研究4.1 负载调度实验用请求流还原并发和排队调度策略研究是LLM服务系统里被讨论最多的话题之一。不同调度器在处理“长请求与短请求交错到达”时的表现差异非常大而要用真实数据验证这个差异请求流数据就派上了用场。我做过的实验是从请求流数据里取一段包含典型峰谷特征的流量分别用FCFS先来先服务、最短作业优先和带优先级的连续批处理策略去调度它然后对比各策略下的平均排队延迟和中位TTFT。结论并不意外最短作业优先在这种混合负载下能把短请求的TTFT压得很低但代价是长请求的尾延迟显著拉高而带优先级的连续批处理在两者之间取得了更好的均衡。但重点不在于结论本身而在于请求流数据让这个实验的负载条件完全可复现。换任何人在相同条件下做实验看到的都是同一段流量。做这类实验时有几个细节特别值得注意。第一请求流里多轮对话的关联关系不能被截断如果你把同一个会话的多条请求切成单条独立请求分发到不同副本里会造成对话上下文错乱进而影响tokens统计和调度行为第二重放时必须是“到达驱动”而不是“固定并发驱动”否则丢掉了请求流最核心的随机到达特征。4.2 吞吐上限实验用单请求样本池压测调度实验关注的是“这个负载下系统表现如何”而吞吐上限实验关注的是“系统顶得住多高强度的压力”。两者使用不同模式后者用固定并发数灌请求观测系统在处理能力极限时的表现。单请求样本池就是为了这个目的准备的。我从样本池里按输入长度和输出长度分层抽样构造了几组不同的测试集合一组偏短输入短输出模拟聊天场景一组偏长输入适中输出模拟文档处理场景一组偏工具调用输入输出都中等但停止符出现概率高。每组固定并发20路、30路、50路分别压测记录吞吐量和P99延迟。实测下来最惊喜的一点是工具调用类请求的吞吐往往比纯文本对话高不少原因是这类请求大量触发stop条件提前结束生成有效计算量小于名义输出长度。如果没有样本池里精准的分层数据很难得到可复现的结论。压测时要注意控制一个变量请求内容本身不能因为压测次数的增加而产生缓存放大效应。如果同一批请求反复灌入服务端前缀缓存可能把大部分计算都省掉测出来的就不是真实吞吐而是缓存吞吐。我的处理方式是设置一个循环节内不重复的请求池并周期性清理缓存。4.3 前缀命中分析用服务日志算缓存复用率服务日志数据是我个人最喜欢的一层因为它揭示了很多表面上看不到的细节。最典型的就是KV缓存命中分析。很多推理系统都支持前缀缓存但真实场景里命中率到底高不高多数人并没有量化概念。我统计了一周的服务日志后发现聊天场景下用户通过多轮对话共享上下文的请求占比非常高尤其是系统提示词固定且用户轮次持续追加时前缀命中率能到60%以上。而在代码生成场景里因为每轮请求往往是全新代码片段前缀命中率就会明显偏低。还有一类很有意思的分析是“潜在可复用而未命中”的场景。日志里会存在请求结构相似但前缀缓存未命中的记录比如两个用户问了同一个专业问题但开头寒暄不同导致共享前缀被截断缓存无法复用。这类数据对做prompt规范化研究非常有价值。要支撑这类分析服务日志的字段质量必须过硬。我在日志里单独记录了一条请求的“实际正常输入部分长度”和“缓存命中部分长度”两者比值就是一条准确的缓存命中率指标。这比事后用相同tokenizer强行对齐计算的命中率要可靠很多。5. 实验复现时的常见问题与处理速查表跑了几轮实验下来我把自己踩过的坑和排查思路整理成了一张表希望帮你少走弯路。症状可能原因处理方式重放后的排队延迟明显低于线上历史值压缩系数过高请求间隔被过度缩小系统来不及形成真实队列积压降低压缩系数先以低倍数重放并验证排队曲线形态TTFT实测值跟服务日志对不上记录的服务端耗时未区分“无缓存”和“命中缓存”两种情况对比日志里的cached_tokens字段分类统计后再对比同样请求在复现实验里token数不一致模型版本或tokenizer版本变化数据集里记录模型快照和tokenizer配置复现前统一锁定KV缓存命中率结果波动过大缓存策略在复现环境里未开启或反馈策略不同确认复现环境的前缀缓存阈值和日志一致某段请求流重放后出现大量超时压缩后的到达率超过系统处理能力上限先压测系统基线吞吐再设定压缩系数数据集中出现大量空输出请求采集过程里把异常请求中断、超时也记录进来了过滤掉finish_reason为error或length无效的记录5.1 重放结果显示排队时间对不上这是我在调度实验初期最头疼的问题。把线上流量压缩后重放得到的平均排队延迟总是比线上低很多。后来排查发现压缩流量虽然保住了峰谷相对形态但把本来长达数分钟的“平峰期”也压缩掉了系统在高峰期来临前没有足够的积累队列就没法形成类似线上的积压感。解决办法是引入预热阶段在正式请求段开始前用低强度的背景负载给系统预热一段时间让队列和缓存先进入接近线上的状态再开始正式记录。这一步对缩短实验时长的帮助很大也不破坏负载曲线的基本形态。5.2 模型版本变化导致token数和耗时失真在持续维护数据中心的几个月里我先后换过两次模型版本结果发现同一个实验在不同时间跑出来的数据没法直接对比。旧版本模型生成文本更长平均completion_tokens比新版本多出一大截这个差异会直接干扰解码耗时的对比。后来我在每条请求字段里都增加了model_version画像标注并在README中注明对应时刻的模型快照。实验对比时要么限定同一个版本区间要么对不同版本的耗时做归一化处理。这是服务研究比训练研究更敏感的一点训练可以事后处理语料服务实验必须语义上锁定版本。5.3 数据质量剔除脏数据对实验结果的影响有一次调度对比实验我跑出了一个奇怪的结论一种明显更优的调度策略反而表现更差。排查到最后才发现是数据清洗不够彻底请求流里混入了一批内部批量任务请求其特征是请求量大但每条极短完全覆盖了正常用户请求的负载规律。这些批量任务才是调度策略表现差异的真正原因。从那以后我建立了一条规则任何数据集在发布前至少经过两个层次的过滤第一层是“机器人/监控任务过滤”第二层是“极端离群请求过滤”。离群请求要设置合理的上下阈值比如输入长度超过某种极端上限或低于某种下限的记录都要单独标注让使用方自行决定是否纳入实验。数据集中可以保留这些标注但绝对不能悄悄混在进行实验的干净数据集里。5.4 权限与许可服务数据涉及的范围比训练语料更广因为它包含了用户请求、模型输出、系统运行指标等多层信息。我的建议是凡是可能涉及用户内容的数据至少要经过脱敏处理后再考虑接近公开发布对于不希望二次分发的内容要建立明确的权限分级。我最终给数据中心设置了三个访问级别完全公开、注册研究者可访问、内部实验专用。完全公开部分只包含不涉及真实用户的模拟请求流和脱敏后的统计信息注册研究者可以访问脱敏后的真实请求流但必须遵循非商业研究用途的限制内部实验专用数据则保留完整的服务端指标。分级看起来会提高获取门槛但保护了数据中心的长期可持续性。6. 后续可以怎么发展数据中心搭建这个数据中心只是一个起点。我自己的规划是下一步把它从“数据仓库”升级成“基准测试套件”。具体来说就是把数据中心里的请求流按场景封装成标准benchmark附上明确的评估指标和参考基线。比如对话场景benchmark、代码生成场景benchmark、长文本分析场景benchmark。这样研究人员跑完实验后不需要到处找别人的测法做对比直接跟参考基线对表就能知道自己的方案处于什么水平。另外我还打算增加一个“负载生成器”模块能够从数据中心现有的请求样本中学习分布特征然后生成任意时长的合成流量。这样不依赖外部数据的团队也能在服务上线前做容量规划。这类合成流量虽然不完全等同于真实流量但因为在分布层面保留了真实请求的特征比纯随机流量要可靠得多。最后是社区共建。数据集中心这类基础设施单靠一两个团队维护很难持续覆盖整个领域的数据形态。如果能形成一套公开的数据贡献规范让不同类型的服务都往一个统一的schema里上报请求流那这个数据集中心的生态价值就能真正发挥出来。很多研究团队其实不缺算法创意缺的是可以横向比较的统一底座这正是数据集中心最值得投入的理由。回到我个人的体会做这个项目最大的收获不是数据集本身而是意识到服务系统实验的“输入”和“输出”必须被同时记录和规范。很多人花时间优化调度策略最后复查实验记录时发现连负载条件都没对齐结论自然站不住。先把数据底座立住后续所有优化工作才谈得上可验证、可持续。