asdwb/cara_latency_prediction

--- license: apache-2.0 language: - en tags: - llm-serving - latency-prediction - heterogeneous-serving - scheduling size_categories: - 100K<n<1M --- # CARA Latency Prediction Dataset A large-scale dataset for training latency predictors in heterogeneous LLM serving systems. Contains 404,258 request-level records from 18 model instances across 4 GPU types, collected under varying QPS levels (8-24). Data from sweep 2 (March 18-19, 2026) with no concurrency cap. ## Dataset Description Each record captures the **instance state at scheduling time** and the **actual end-to-end latency** after request completion. This enables training learned latency predictors that map observable system state to request latency — analogous to learned index structures in databases. ### Key Statistics | Split | Records | Prompts Source | QPS Range | Notes | |-------|---------|---------------|-----------|-------| | Train | 359,258 | cara_model_estimator train split | 8-24 | 671 records dropped (unresolvable queue entries) | | Test | 45,000 | cara_model_estimator test split | 8-24 | 0 dropped | ### Cluster Configuration 18 instances across 4 GPU types serving 4 Qwen2.5 model sizes: | Model | GPU | Instances | Tensor Parallel | vLLM Version | |-------|-----|-----------|----------------|--------------| | Qwen2.5-72B | A100 80GB x2 | 2 | 2 | cara_v_11 | | Qwen2.5-14B | V100 32GB x4 | 3 | 4 | cara_v_11 | | Qwen2.5-7B | A30 24GB | 5 | 1 | cara_v_11 | | Qwen2.5-3B | A30 24GB | 3 | 1 | cara_v_11 | | Qwen2.5-3B | P100 16GB | 5 | 1 | cara_v_11_p100 | ## Files **Updated April 2026**: Data replaced with clean sweep 2 collection (no concurrency cap). Queue detail files enriched with per-request `actual_output_tokens` via cross-referencing (99.96% match rate). | File | Records | Description | |------|---------|-------------| | `train.jsonl` | 359,258 | Training data, flat schema (schedule_state fields at top level) | | `test.jsonl` | 45,000 | Test data, flat schema | | `train_queue_details.jsonl` | 359,258 | Training data with per-request `running_requests[]` and `waiting_requests[]` + enriched `actual_output_tokens` | | `test_queue_details.jsonl` | 45,000 | Test data with per-request lists + enriched `actual_output_tokens` | ### Flat vs Queue Details - **Flat files** (`train.jsonl`, `test.jsonl`): Schedule state fields flattened to top level. Suitable for XGBoost and tabular models. - **Queue detail files**: Full nested `schedule_state` with per-request running/waiting lists. Each queue entry includes `actual_output_tokens` (enriched post-collection). Suitable for LSTM sequence models. ## Schema ### Flat records (`train.jsonl`, `test.jsonl`) **Identifiers:** - `request_id` (str): Unique request identifier (UUID) - `instance_id` (str): CloudLab hostname + port (e.g., `c240g5-110103.wisc.cloudlab.us_port8300`) - `instance_type` (str): Model + GPU type (e.g., `qwen2.5-3b_p100`) **Request features:** - `num_prompt_tokens` (int): Input prompt length in tokens - `num_predicted_output_tokens` (int): Max tokens parameter (1024 for all requests in this dataset) - `actual_output_tokens` (int): Actual generated output tokens (recovered via `round((e2e-ttft)/tpot)+1`) **Schedule state (from vLLM `/instance_stats` at scheduling time):** - `num_running` (int): Currently running requests on this instance - `num_waiting` (int): Queued requests (typically 0 — vLLM continuous batching absorbs load) - `num_active_decode_seqs` (int): Actively decoding sequences - `decode_ctx_p50/p95/max` (float): Decode context length percentiles (0 for some instances) - `pending_prefill_tokens` (int): Total pending prefill tokens (often 0) - `pending_decode_tokens` (int): Total pending decode tokens (0 for some instances) - `kv_cache_utilization` (float): KV cache usage fraction [0, 1] - `kv_free_blocks` (int): Available KV cache blocks - `token_budget_per_iter` (int): Scheduler token budget per iteration - `prefill_chunk_size` (int): Chunked prefill size - `max_num_seqs` (int): Max concurrent sequences allowed - `num_preempted` (int): Cumulative preemption count - `ema_decode_tok_per_s` (float): EMA decode throughput (tokens/sec) - `ema_prefill_tok_per_s` (float): EMA prefill throughput (tokens/sec) - `ema_decode_iter_ms` (float): EMA per-iteration decode latency (ms) - `kv_evictions_per_s` (float): KV cache eviction rate **Derived (flat files only):** - `running_requests_count` (int): Count from per-request list - `waiting_requests_count` (int): Count from per-request list **Overhead:** - `probe_latency_ms` (float): Time to fetch instance state from vLLM - `prediction_latency_ms` (float): Latency predictor inference time **Timestamps:** - `prediction_timestamp` (float): Unix time when scheduling decision was made - `completion_timestamp` (float): Unix time when request completed **Target labels:** - `actual_e2e_latency` (float): End-to-end latency in seconds (client-measured) - `actual_ttft` (float): Time to first token in seconds - `actual_tpot` (float): Mean time per output token in seconds (mean inter-token latency) ### Queue details (`train_queue_details.jsonl`, `test_queue_details.jsonl`) Full nested structure with `schedule_state` containing all aggregate fields plus per-request lists: - `schedule_state.running_requests[]` — per running request: - `request_id` (str): vLLM internal ID (`chatcmpl-` prefixed UUID) - `num_prompt_tokens` (int): Request's prompt length - `num_computed_tokens` (int): Tokens already processed (prefill progress) - `total_num_tokens` (int): Total allocated tokens at snapshot - `num_output_tokens` (int): Output tokens generated so far (0 during prefill) - `actual_output_tokens` (int): **Final output length** (enriched post-collection via cross-referencing request_ids, 99.96% match rate) - `schedule_state.waiting_requests[]` — same schema as running_requests ## Collection Method 1. Real prompts sampled from the [cara_model_estimator](https://huggingface.co/datasets/asdwb/cara_model_estimator) dataset 2. Sent through a coordinator with random scheduling to 18 heterogeneous instances 3. Sidecar on each instance captures (state, latency) pairs 4. Collected at 10 QPS levels (9-36) covering idle to saturated conditions 5. Train/test split aligned with cara_model_estimator splits (no prompt overlap) ## Intended Use - Training latency predictors for LLM serving schedulers (XGBoost, LSTM, neural networks) - Benchmarking simulation-based vs learned latency prediction - Studying heterogeneous LLM serving behavior across GPU types - Evaluating scheduling policies under different load conditions ### Enriched Queue Entry Fields (queue_details files) Each entry in `running_requests[]` and `waiting_requests[]` includes: | Field | Description | |-------|-------------| | `num_prompt_tokens` | Request's prompt length | | `num_computed_tokens` | Tokens already processed (prefill progress) | | `total_num_tokens` | Total sequence length at snapshot | | `num_output_tokens` | Output tokens generated so far | | `actual_output_tokens` | **Final output length** (enriched via cross-referencing request_ids) | ### Offline Evaluation Results (verified April 2026) | Model | E2E MAE | E2E MAPE | Spearman rho | |-------|---------|----------|-------------| | XGBoost (oracle output) | 0.289s | 3.7% | 0.999 | | Roofline (analytical) | 0.531s | 10.7% | 0.987 | | XGBoost TTFT | 0.015s | 16.2% | 0.946 | | XGBoost TPOT | 0.002s | 42.0% | 0.978 | ## Citation If you use this dataset, please cite: ```bibtex @dataset{cara_latency_2026, title={CARA Latency Prediction Dataset}, author={Wei Da}, year={2026}, url={https://huggingface.co/datasets/asdwb/cara_latency_prediction} } ``` ## Related - [cara_model_estimator](https://huggingface.co/datasets/asdwb/cara_model_estimator) — Multi-model quality and length estimation dataset - CARA: Context-Aware Resource Allocation for heterogeneous LLM servinglicense: Apache-2.0许可证 language: - 英语 tags: - 大语言模型服务(LLM-serving) - 延迟预测(Latency-prediction) - 异构服务(Heterogeneous-serving) - 调度(Scheduling) size_categories: - 100K < n < 1M # CARA延迟预测数据集 本数据集为面向异构大语言模型(LLM)服务系统的延迟预测器训练提供大规模支撑，共包含404258条请求级记录，数据采集自4种GPU类型上的18个模型实例，采集时QPS（每秒查询率）范围为8至24。本次数据集来自2026年3月18日至19日的第二轮采集（Sweep 2），未设置并发上限。 ## 数据集描述 每条记录均记录了调度时刻的实例状态，以及请求完成后的实际端到端延迟(end-to-end latency)。借此可训练可观测系统状态到请求延迟的映射学习型延迟预测器，其设计思路与数据库中的学习型索引结构类似。 ### 关键统计 | 数据集划分 | 记录条数 | 提示源 | QPS范围 | 备注 | |-------|---------|---------------|-----------|-------| | 训练集 | 359,258 | cara_model_estimator 训练划分 | 8-24 | 丢弃671条无法解析的队列条目 | | 测试集 | 45,000 | cara_model_estimator 测试划分 | 8-24 | 无丢弃记录 | ### 集群配置 18个实例分布在4种GPU类型上，部署了4种尺寸的Qwen2.5模型： | 模型 | GPU配置 | 实例数量 | 张量并行度(Tensor Parallel) | vLLM版本 | |-------|-----|-----------|----------------|--------------| | Qwen2.5-72B | A100 80GB x2 | 2 | 2 | cara_v_11 | | Qwen2.5-14B | V100 32GB x4 | 3 | 4 | cara_v_11 | | Qwen2.5-7B | A30 24GB | 5 | 1 | cara_v_11 | | Qwen2.5-3B | A30 24GB | 3 | 1 | cara_v_11 | | Qwen2.5-3B | P100 16GB | 5 | 1 | cara_v_11_p100 | ## 文件 **2026年4月更新**：本次数据集已替换为干净的第二轮采集数据（未设置并发上限）。队列详情文件已通过交叉引用补充了每条请求的`actual_output_tokens`（实际输出Token数）字段，匹配率达99.96%。 | 文件 | 记录条数 | 描述 | |------|---------|-------------| | `train.jsonl` | 359,258 | 训练数据，采用扁平化结构（调度状态字段位于顶层），适用于XGBoost与表格模型 | | `test.jsonl` | 45,000 | 测试数据，采用扁平化结构 | | `train_queue_details.jsonl` | 359,258 | 训练数据，包含每条请求的`running_requests[]`与`waiting_requests[]`列表，以及补充的`actual_output_tokens`字段 | | `test_queue_details.jsonl` | 45,000 | 测试数据，包含每条请求的列表与补充的`actual_output_tokens`字段 | ### 扁平化结构与队列详情的区别 - **扁平化文件**（`train.jsonl`、`test.jsonl`）：调度状态字段扁平化至顶层，适用于XGBoost与表格模型。 - **队列详情文件**：包含完整的嵌套`schedule_state`结构，以及每条请求的运行/等待队列列表，每个队列条目均包含`actual_output_tokens`（采集后补充的字段），适用于LSTM序列模型。 ## Schema ### 扁平化记录（`train.jsonl`、`test.jsonl`） #### 标识符字段： - `request_id`（字符串）：唯一请求标识符（UUID） - `instance_id`（字符串）：CloudLab主机名加端口（例如`c240g5-110103.wisc.cloudlab.us_port8300`） - `instance_type`（字符串）：模型与GPU类型组合（例如`qwen2.5-3b_p100`） #### 请求特征字段： - `num_prompt_tokens`（整数）：输入提示的Token长度 - `num_predicted_output_tokens`（整数）：最大生成Token数（本数据集所有请求均为1024） - `actual_output_tokens`（整数）：实际生成的输出Token数（通过公式`round((e2e-ttft)/tpot)+1`计算恢复） #### 调度状态（来自vLLM的`/instance_stats`接口，采集于调度时刻）： - `num_running`（整数）：当前实例上正在运行的请求数 - `num_waiting`（整数）：排队请求数（通常为0，vLLM连续批处理机制可实现负载均衡） - `num_active_decode_seqs`（整数）：正在主动解码的序列数 - `decode_ctx_p50/p95/max`（浮点数）：解码上下文长度的分位数（部分实例为0） - `pending_prefill_tokens`（整数）：待处理的预填充Token总数（通常为0） - `pending_decode_tokens`（整数）：待处理的解码Token总数（部分实例为0） - `kv_cache_utilization`（浮点数）：KV缓存使用率，取值范围[0, 1] - `kv_free_blocks`（整数）：可用的KV缓存块数 - `token_budget_per_iter`（整数）：调度器每次迭代的Token预算 - `prefill_chunk_size`（整数）：分块预填充的大小 - `max_num_seqs`（整数）：允许的最大并发序列数 - `num_preempted`（整数）：累计的请求抢占次数 - `ema_decode_tok_per_s`（浮点数）：指数移动平均(EMA)解码吞吐量（Token/秒） - `ema_prefill_tok_per_s`（浮点数）：指数移动平均(EMA)预填充吞吐量（Token/秒） - `ema_decode_iter_ms`（浮点数）：指数移动平均(EMA)每轮迭代解码延迟（毫秒） - `kv_evictions_per_s`（浮点数）：KV缓存驱逐速率 #### 仅扁平化文件包含的派生字段： - `running_requests_count`（整数）：从请求列表中统计的运行请求数 - `waiting_requests_count`（整数）：从请求列表中统计的等待请求数 #### 开销字段： - `probe_latency_ms`（浮点数）：从vLLM获取实例状态的耗时（毫秒） - `prediction_latency_ms`（浮点数）：延迟预测器的推理耗时（毫秒） #### 时间戳字段： - `prediction_timestamp`（浮点数）：做出调度决策时的Unix时间 - `completion_timestamp`（浮点数）：请求完成时的Unix时间 #### 目标标签： - `actual_e2e_latency`（浮点数）：端到端延迟（秒，客户端测量值） - `actual_ttft`（浮点数）：首令牌生成时间(Time to First Token, TTFT)（秒） - `actual_tpot`（浮点数）：平均每输出令牌耗时(Time Per Output Token, TPOT)（秒，平均令牌间延迟） ### 队列详情记录（`train_queue_details.jsonl`、`test_queue_details.jsonl`） 完整的嵌套结构，`schedule_state`包含所有聚合字段，以及每条请求的列表： - `schedule_state.running_requests[]` — 每条运行中的请求，包含以下字段： - `request_id`（字符串）：vLLM内部ID（以`chatcmpl-`为前缀的UUID） - `num_prompt_tokens`（整数）：请求的提示长度 - `num_computed_tokens`（整数）：已处理的Token数（预填充进度） - `total_num_tokens`（整数）：快照时刻分配的总序列长度 - `num_output_tokens`（整数）：当前已生成的输出Token数（预填充阶段为0） - `actual_output_tokens`（整数）：最终输出长度（采集后通过交叉引用请求ID补充的字段，匹配率99.96%） - `schedule_state.waiting_requests[]` — 字段结构与`running_requests[]`完全一致 ## 采集方法 1. 真实提示样本取自[cara_model_estimator](https://huggingface.co/datasets/asdwb/cara_model_estimator)数据集 2. 通过协调器将请求随机调度至18个异构实例 3. 每个实例的侧车程序采集（实例状态，延迟）对 4. 以10个QPS层级（9-36）采集数据，覆盖从空闲到饱和的全部工况 5. 训练/测试划分与cara_model_estimator的划分对齐，无提示重叠 ## 预期用途 - 训练大语言模型服务调度器的延迟预测器（可使用XGBoost、LSTM、神经网络等模型） - 开展基于仿真与基于学习的延迟预测方法的基准对比测试 - 研究异构大语言模型服务在不同GPU类型下的运行行为 - 在不同负载条件下评估调度策略的性能 ### 补充的队列条目字段（队列详情文件） `running_requests[]`与`waiting_requests[]`中的每个条目均包含以下字段： | 字段 | 描述 | |-------|-------------| | `num_prompt_tokens` | 请求的提示长度 | | `num_computed_tokens` | 已处理的Token数（预填充进度） | | `total_num_tokens` | 快照时刻分配的总序列长度 | | `num_output_tokens` | 当前已生成的输出Token数 | | `actual_output_tokens` | 最终输出长度（采集后通过交叉引用请求ID补充的字段） | ### 离线评估结果（2026年4月验证） | 模型 | 端到端平均绝对误差(E2E MAE) | 端到端平均绝对百分比误差(E2E MAPE) | 斯皮尔曼秩相关系数(Spearman rho) | |-------|---------|----------|-------------| | XGBoost（神谕输出） | 0.289s | 3.7% | 0.999 | | 屋顶线(Roofline)分析模型 | 0.531s | 10.7% | 0.987 | | XGBoost（TTFT预测） | 0.015s | 16.2% | 0.946 | | XGBoost（TPOT预测） | 0.002s | 42.0% | 0.978 | ## 引用 若使用本数据集，请引用以下BibTeX条目： bibtex @dataset{cara_latency_2026, title={CARA Latency Prediction Dataset}, author={Wei Da}, year={2026}, url={https://huggingface.co/datasets/asdwb/cara_latency_prediction} } ## 相关资源 - [cara_model_estimator](https://huggingface.co/datasets/asdwb/cara_model_estimator) — 多模型质量与长度估计数据集 - CARA：面向异构大语言模型服务的上下文感知资源分配(Context-Aware Resource Allocation)

搜集汇总

数据集介绍

构建方式

在异构大语言模型服务系统中，构建精准的延迟预测模型需要依赖高质量的数据支撑。该数据集通过精心设计的实验流程，在真实的服务环境中采集了404,258条请求级别的记录。数据来源于一个包含18个模型实例、覆盖4种GPU类型的异构集群，这些实例部署了不同规模的Qwen2.5模型。数据采集过程模拟了从空闲到饱和的多种负载场景，查询率在每秒8至24次请求之间动态变化。每条记录均精确捕捉了调度时刻的实例内部状态与请求完成后的端到端实际延迟，确保了状态与结果之间的因果对应关系。训练集与测试集的划分严格遵循了上游提示数据的分割，避免了数据泄露，为模型训练提供了可靠的基础。

特点

该数据集的核心价值在于其全面且细粒度的系统状态表征能力。它不仅提供了实例级别的聚合指标，如运行请求数、等待队列长度及键值缓存利用率等，还通过队列详情文件揭示了每个运行中或等待请求的微观状态，包括提示令牌数、已计算令牌数以及通过交叉验证获取的实际输出令牌数。这种双层数据结构设计，既支持XGBoost等传统表格模型所需的扁平化特征，也为LSTM等序列模型处理嵌套的请求列表提供了便利。数据集覆盖了从A100到P100等多种GPU硬件，以及从3B到72B的不同模型规模，充分体现了异构服务环境的复杂性，为研究负载条件下的系统行为差异提供了丰富样本。

使用方法

该数据集旨在服务于大语言模型服务系统中的延迟预测研究。使用者可依据不同的建模需求选择相应的数据文件：对于基于树模型或神经网络的表格预测任务，可直接使用扁平化的`train.jsonl`与`test.jsonl`文件，其中特征已被展平，便于快速进行特征工程与模型训练。若研究涉及序列建模或需要分析请求间的交互影响，则应使用包含完整嵌套结构的队列详情文件，这些文件保留了每个请求的详细上下文信息。数据集已预先分割，研究者可在训练集上开发预测模型，并在独立的测试集上评估其端到端延迟、首令牌时间及每令牌时间的预测精度，进而用于优化调度策略或进行异构服务的仿真基准测试。

背景与挑战

背景概述

随着大规模语言模型（LLM）服务需求的激增，异构计算环境下的高效资源调度成为关键研究议题。CARA Latency Prediction 数据集由 Wei Da 等人于2026年构建，旨在为异构LLM服务系统中的延迟预测提供大规模训练数据。该数据集聚焦于解决在动态负载下，如何准确预测请求端到端延迟的核心问题，从而优化调度决策，提升系统吞吐与资源利用率。其通过采集涵盖四种GPU类型、十八个模型实例的四十余万条请求级记录，为学习型延迟预测器的开发奠定了实证基础，推动了智能调度算法在云原生LLM服务领域的演进。

当前挑战

在异构LLM服务领域，准确预测请求延迟面临多重挑战。其一，系统状态具有高维动态性，如KV缓存利用率、解码序列数等指标相互耦合，使得延迟与状态间映射关系高度非线性。其二，构建过程中需克服数据采集的复杂性，需在真实负载下同步捕获调度时刻实例状态与请求完成后的实际延迟，并处理队列条目解析、令牌数跨引用匹配等数据一致性问题。此外，数据集需覆盖从空闲到饱和的多种负载场景，以保障预测模型在动态QPS下的泛化能力，这对实验设计与数据清洗提出了严峻考验。

常用场景

经典使用场景

在大规模语言模型服务系统中，资源调度与延迟预测是保障服务质量的核心挑战。CARA延迟预测数据集为这一领域提供了关键支持，其经典使用场景在于训练基于学习的延迟预测器。通过捕获调度时刻的实例状态与请求完成后的端到端延迟数据，该数据集使研究者能够构建从可观测系统状态到请求延迟的映射模型，类似于数据库中的学习索引结构。这一过程通常涉及利用XGBoost等表格模型或LSTM等序列模型，在异构GPU集群环境下，对包含运行请求队列、等待请求队列及丰富系统指标的复杂状态进行建模，从而实现对请求延迟的精准预测，为智能调度决策提供数据基础。

实际应用

在实际的云原生LLM服务平台中，高效的资源管理和服务质量保障至关重要。CARA延迟预测数据集直接服务于此类平台的核心调度器开发。基于该数据集训练的预测模型，能够被集成到生产环境的调度系统中，实时预估将一个新请求分配到特定模型实例（如运行在不同GPU上的Qwen2.5系列模型）上所产生的延迟。这使得调度器能够在满足服务等级协议的前提下，实现负载均衡、最小化平均延迟或最大化吞吐量等优化目标。例如，在由A100、V100、A30、P100等多种GPU构成的异构集群中，系统可以利用预测结果，智能地将请求路由至最合适的实例，从而显著提升整体资源利用率和用户体验。

衍生相关工作

CARA延迟预测数据集作为异构LLM服务研究的重要资源，已催生了一系列相关经典工作。其最直接的衍生研究是围绕CARA（上下文感知资源分配）框架本身展开，该框架利用数据集训练的预测器来实现智能调度。此外，数据集支持了对不同预测模型（如XGBoost与LSTM）在延迟预测任务上的性能基准测试，比较了学习型方法与理论分析型方法（如性能天花板模型）的优劣。更进一步，该数据集为探索更高级的调度策略提供了实验平台，例如研究在动态查询率负载下的调度稳定性，或是结合模型质量估计进行多目标优化。这些工作共同推动了学习增强系统在LLM服务领域的深入应用。