你在午休时问 AI 一个问题，可能很快得到回答；深夜再问，却可能遇上排队。对服务商来说，难题不只是“今天有多少人来”，而是请求会不会在几秒内突然扎堆、大家调用什么模型、每次输入和回答有多长。机器备少了，用户要等；备多了，大量 GPU 又会闲置。FineServe 想补上的，正是这张更细的“客流图”。
论文作者从一个未具名的全球商业算力 marketplace 收集了四个月的线上轨迹，共计 14.8 亿次请求，覆盖 57 个模型、10 个模型家族。它记录请求到达时间、模型类别以及输入和输出的 token 数量。token 可以粗略理解为模型处理文字时使用的基本单位。作者还抽取 10 万条请求，将其分为 10 类任务意图，并据此分析不同模型与任务怎样形成不同的负载。
这是一篇单一团队发布的论文。本文涉及数据质量、观察结论和工具能力的说法均来自作者及其项目，尚无独立信源复核。
总量会把真正的问题藏起来
LLM Serving——把大模型作为在线服务持续接收请求并生成回答——很像一家全天营业、每桌用餐时间又不固定的餐厅。系统既要控制延迟，也就是单个用户等多久；又要提高吞吐量，也就是单位时间处理多少请求。多塞一些请求通常更省机器，却也可能拉长排队和回答时间。
研究这类系统需要工作负载轨迹（Workload Trace）：按时间记下请求何时到来、调用哪个模型、输入输出多长。过去的研究常借用云计算轨迹，或把公开对话数据与人工设定的到达规律拼在一起。这样便于实验，却可能把真实流量想得过于均匀。
FineServe 的关键变化，是不再把平台流量揉成一条平均曲线。作者分别观察模型架构、参数规模和任务意图。模型架构包括 Dense 与 Mixture-of-Experts（MoE）：Dense 模型处理每个 token 时会动用全部参数；MoE 模型则把 token 分给一部分“专家”模块。两者使用算力的方式不同，面对突发流量时的表现也可能不同。
小模型抖得快，MoE 冲得高
作者用两个时间尺度观察请求到达。长期看，他们比较相邻五分钟窗口的请求分布，判断需求是否发生漂移。短期看，他们按秒统计五分钟内的波动：CV 衡量请求量是否忽高忽低，MSSD 则关注相邻两秒之间跳得有多剧烈。
结果显示，10B 参数以下的 Dense 模型长期变化最明显。随着 Dense 模型变大，负载相对稳定；MoE 模型的长期漂移较低。短期形态则不同：小型 Dense 模型的请求总量在五分钟内相对均匀，但每秒变化很快；MoE 请求更像间歇出现的大波峰，幅度高，秒与秒之间反而较平滑。
这种区别不能靠一个“平均请求率”概括。作者统计发现，即使在突发最不占主导的类别中，最繁忙的 5% 秒数也贡献了接近 9.5% 的小时请求量；某些时段，小型 Dense 模型的这一比例可达 15%—18%。对调度系统来说，短暂尖峰并不是可以忽略的噪声。
论文还指出，MSSD 普遍在中午附近最低、深夜较高。换句话说，高负载时流量反而更连续；低负载时，零散请求更容易制造剧烈抖动。不过，作者也称全球汇总后的每日总量没有明显昼夜潮汐。这两点并不矛盾：总量可以相对平稳，细分模型与秒级流量仍会波动。
一次请求有多“重”，不能只看输入
请求何时到来只决定排队压力，输入和输出长度才决定每单要做多少计算。FineServe 将两者合称为 token geometry，也就是一类请求通常“读多少、写多少”，以及二者如何关联。
作者发现，所有架构的输入长度都有明显长尾：大多数请求较短，但少量请求非常长。输出长尾较弱，其中 MoE 的长输出更常见。更值得注意的是，输入变长，并不总会带来更长的回答。
在 10B 以下 Dense 模型中，输出中位数会随输入增长而上升，在约 1.5K—2K token 附近达到峰值，随后下降；从峰值到超长输入区间，中位输出长度减少超过 60%。较大的 Dense 模型仍有类似趋势，但程度较弱。MoE 则呈现“增长后趋于饱和”的形态。作者推测，超长输入更常对应总结、压缩等任务，但这只是对观察结果的解释，并非因果验证。
任务类型又增加了一层差异。作者的分类结果中，科学类请求接近一半；写作、角色扮演和娱乐也占有较大比例。编程、商业等任务的输入长度形成较平滑的集中区间；法律、科学、金融、健康等类别会在若干固定长度附近出现尖峰；写作、娱乐和角色扮演则分布得更宽。相比之下，多数任务的输出主要集中在 0—300 token。论文据此认为，任务信息对预填充阶段——模型读取输入的阶段——尤其重要，而不同任务的输出差异相对有限。
把“潮汐图”变成压力测试
FineServe 不只提供分析，还给出一个 workload generator，即工作负载生成器。用户可以指定模型组合、可选的任务比例和负载规模，再用两种方式生成测试请求。
第一种是轨迹重放：按原有时间和请求特征重新播放。第二种是参数化合成：先模拟请求到达时间，再生成相互关联的输入、输出长度，最后把不同模型的请求流混合起来。它像是先分别还原不同店铺的客流规律，再把它们放回同一座商场，而不是拿一条统一曲线套给所有模型。
生成器用 Gamma 分布刻画分段内的请求间隔；若某类模型在毫秒尺度上出现多个请求扎堆，则再用负二项分布补充这种聚集。作者以每类架构 1000 个生成请求做检查，称合成流量在请求强度、突发频率和时间波动上接近重放轨迹。这里的目标不是逐个复刻原请求，而是保留宏观动态。论文没有给出更完整的误差指标，因此还不能判断这种“接近”在不同基准测试中有多稳健。
为什么值得关注
容量规划要决定高峰期准备多少算力。若所有模型共用一条平均曲线，平台可能给波动大的小型 Dense 模型留少了机器，又给相对稳定的模型留出过多余量。FineServe 的价值，在于让研究者分别测试快速抖动、大幅尖峰、长输入和任务结构变化，从而更贴近多模型平台的真实困难。
它也把数据分析变成了可操作的实验入口。路由决定请求送往哪台机器，调度决定谁先执行，容量规划决定提前备多少资源。FineServe 提供的细粒度组合，可以让这些策略面对同一套可重复的负载，而不是各自使用一套过于理想化的假设。作者给出的项目地址是 FineServe GitHub。
局限与未知
- 论文没有公开 marketplace 名称、具体地域构成及模型清单；“global”主要指平台覆盖与汇总范围，不能直接解释为各地区样本均衡。
- 作者称数据已完全清洗、不含可识别用户的内容，但正文没有披露更具体的脱敏流程、审计方式及公开数据的完整程度。
- 数据集、生成器及“真实度”目前都来自论文团队自身陈述。参数化实验只展示每组 1000 个请求的比较，尚不足以证明它能覆盖所有模型、任务和极端峰值。