rtx5090-5m-bench
收藏资源简介:
该数据集是一个为特定基准测试生成的人工合成工作负载,用于评估在NVIDIA RTX 5090 GPU上使用NVFP4量化(W4A4)的Llama-3.1-8B-Instruct模型通过vLLM框架服务的性能。工作负载的核心目标是模拟多用户并发请求,以找到在满足每个模拟用户最低输出令牌速率(≥15 tokens/秒)的前提下,能够最大化聚合输出令牌吞吐量的并发用户数N。工作负载由一系列预定义的对话请求构成,这些请求根据总上下文长度(提示令牌数 + 请求的输出令牌数)被划分为7个等权重的桶:1,000、2,000、4,000、8,000、16,000、24,000 和 30,000令牌。每个请求的提示部分经过聊天模板处理,包含系统消息和多样化的自然语言内容,以确保其唯一性,从而在测试中禁用前缀缓存(模拟保守的未缓存服务场景)。每个请求强制生成512个输出令牌(忽略EOS),并使用固定的生成参数(temperature=0)。该工作负载使用一个固定的随机种子和指定的Hugging Face分词器生成,并保存为`workload.jsonl`文件。其设计旨在压力测试服务端在混合不同长度上下文请求时的吞吐量、延迟和资源利用率,特别是针对NVFP4量化的权重、激活和键值(KV)缓存。工作负载的规模由并发用户数N和每个用户持续提交请求的5分钟测量窗口决定,其中每个请求的总令牌数严格限制在30,000以内。
This dataset is an artificially generated synthetic workload for a specific benchmark, designed to evaluate the performance of the Llama-3.1-8B-Instruct model with NVFP4 quantization (W4A4) served via the vLLM framework on an NVIDIA RTX 5090 GPU. The core objective of the workload is to simulate multi-user concurrent requests to find the number of concurrent users N that maximizes the aggregated output token throughput while meeting a minimum output token rate per simulated user (≥15 tokens/second). The workload consists of a series of predefined dialogue requests, which are divided into 7 equally weighted buckets based on total context length (prompt tokens + requested output tokens): 1,000, 2,000, 4,000, 8,000, 16,000, 24,000, and 30,000 tokens. The prompt portion of each request is processed with a chat template, including system messages and diverse natural language content to ensure uniqueness, thereby disabling prefix caching in the test (simulating a conservative uncached service scenario). Each request is forced to generate 512 output tokens (ignoring EOS) and uses fixed generation parameters (temperature=0). The workload is generated using a fixed random seed and a specified Hugging Face tokenizer, saved as a `workload.jsonl` file. Its design aims to stress-test the servers throughput, latency, and resource utilization when handling mixed-length context requests, particularly focusing on NVFP4 quantized weights, activations, and key-value (KV) cache. The scale of the workload is determined by the number of concurrent users N and a 5-minute measurement window during which each user continuously submits requests, with the total tokens per request strictly limited to 30,000.
数据集概述:Manual RTX 5090 NVFP4 vLLM Benchmark Plan
数据集目标
本数据集旨在通过严谨的基准测试,确定在单张租用的RTX 5090显卡上,使聚合输出token吞吐量最大化的并发用户数N,同时确保每个模拟用户(simulated user)在精确5分钟测量窗口内获得至少15个输出token/秒的速率。测试结果受固定的上下文长度混合比例约束,并非适用于所有流量分布的通用容量数据。
核心优化问题
- 最大化:
aggregate_output_tok_s(N, config)(聚合输出token/秒) - 约束条件:
min(user_output_tok_s) >= 15.0(每位用户的最小速率)measurement_window == 300 seconds(测量窗口精确为300秒)prompt_tokens + requested_output_tokens <= 30,000(总token上限)request_errors == 0(无请求错误)engine_restarts == 0(无引擎重启)OOM_events == 0(无内存溢出事件)
- 指标定义:
aggregate_output_tok_s= 所有用户输出token总和 / 300user_output_tok_s[i]= 用户i输出token数 / 300mean_user_tok_s= aggregate_output_tok_s / N
- 严格要求:严格约束的是每位用户的最小速率,而非仅平均值。
模型选择
- 模型:
nvidia/Llama-3.1-8B-Instruct-NVFP4 - 模型信息:
- NVIDIA发布的NVFP4量化版本,基于Meta Llama 3.1 8B Instruct。
- 80亿参数,Llama架构,128k原生上下文限制,支持vLLM和NVIDIA Blackwell兼容性。
- 对Transformer块线性权重和激活进行FP4量化,保留
lm_head等选定组件为更高精度。
- 量化配置:
quant_algo: NVFP4,quant_method: modelopt - 推理引擎要求:
- 对模型和KV缓存均使用NVFP4。
- NVFP4 KV存储采用打包的4位数据和FP8块尺度(非完全无尺度的4位表示)。
- 使用vLLM的ModelOpt FP4路径加载检查点。
- 未量化层使用其检查点数据类型(
--dtype auto)。 - 主KV缓存使用NVFP4(
--kv-cache-dtype nvfp4)。
执行兼容性说明(2026-07-10)
- 驱动
570.144的RTX 5090在被拒绝并销毁前,CUDA初始化失败,错误码804(非支持硬件上的向前兼容尝试)。 - 驱动
595.58.03的RTX 5090通过CUDA初始化,报告计算能力(12, 0)。v0.22.1稳定版镜像因原生NVFP4 KV启动路径失败被拒绝。 - 第三个试用的vLLM nightly镜像(
sha256:a671d5fcda...)在SM120上报告trtllm_prefill=false、trtllm_decode=false,并在模型加载前拒绝NVFP4 KV。 - 通过窄范围兼容性补丁,使用FlashInfer 0.6.13 FA2 NVFP4-KV路径,在SM120上成功启动引擎并完成基准测试。
- 相同虚拟机用于BF16-KV对比测试:BF16启动使用FlashAttention v2,分配179,376个KV缓存token,32/31/28用户固定输出配置均未通过15 tok/s约束。无限输出变体因自然EOS过早结束,不可与强制512 token结果比较。
测试方法
工作负载生成
使用七个等权重的总上下文桶(Total context buckets),每个桶包含prompt token和固定的512个强制输出token:
| 总上下文 | prompt token | 强制输出token |
|---|---|---|
| 1,000 | 488 | 512 |
| 2,000 | 1,488 | 512 |
| 4,000 | 3,488 | 512 |
| 8,000 | 7,488 | 512 |
| 16,000 | 15,488 | 512 |
| 24,000 | 23,488 | 512 |
| 30,000 | 29,488 | 512 |
- 使用种子生成
workload.jsonl,确保prompt唯一性(前缀缓存未命中)。 - 每个请求参数:
temperature = 0,max_tokens = 512,ignore_eos = true,stream = true。
测量与搜索流程
- 五分钟测量窗口:每个候选并发数
N运行300秒,记录aggregate_output_tok_s。 - 自适应并发搜索:
- 从7个用户开始,有效则加倍:7 -> 14 -> 28 -> 56 ...
- 遇失败则减半,找到有效下限。
- 在最后一个有效和第一个无效并发数之间二分搜索。
- 对峰值吞吐和15 tok/s边界附近每个整数测试。
- 对最佳
N及其两个邻居重复测试三次。 - 选择所有确认窗口中
min_user_tok_s >= 15.0的最高中位聚合吞吐量。
引擎调优外循环
保持检查点和工作负载固定,对每种更改的服务器设置赋予新的config_id,重启、预热后重新执行并发搜索。调优顺序:
max-num-batched-tokensmax-num-seqs(至少不小于候选用户数)- 分块预填充大小、部分预填充并发和长预填充阈值
gpu-memory-utilization(从0.92谨慎向0.95–0.96调整)- NVFP4 KV尺度处理
结果记录与报告
- 每个完整五分钟后附加一行JSONL结果(含聚合吞吐、最小用户速率、延迟百分位、GPU利用率、功耗等)。
- 同时输出CSV行和终端行。
- 主要通过/失败判定基于300秒吞吐量和最小用户速率约束。
- 最终摘要包含:模型精确版本、GPU和主机信息、vLLM/CUDA/驱动版本、量化后端确认、KV缓存配置。
环境与资源
- 预算:约2-4 GPU小时(含预配、编译、粗搜索、细化、一轮调优和确认窗口)。
- 资源:单张按需RTX 5090(已验证可靠主机,直接SSH,足够磁盘,CUDA/驱动>=12.8)。




