RTX 5090部署vLLM推理服务实测：吞吐量、并发与成本全解析

省流版RTX 5090 的 32GB 显存适合部署 7B、8B 等中小规模模型的 vLLM 推理服务也可在量化、上下文和并发参数受控的前提下尝试更大模型。实际吞吐、可承载并发与单位成本会受模型版本、量化格式、输入输出长度、请求分布、vLLM 版本和实例价格影响建议在目标业务负载下压测确认。一、为什么选 vLLM 5090做推理大模型推理的瓶颈通常不只在算力也在显存管理和请求调度。传统部署方式在并发请求增加时可能出现显存利用率不理想、请求排队或吞吐下降等情况具体表现仍取决于模型、推理后端和请求模式。vLLM 的核心优势在于 PagedAttention将 KV Cache 按块管理减少连续预留带来的浪费配合 Continuous Batching可以在请求到达和生成过程中持续调度批次提高多请求场景下的资源利用效率。RTX 5090 配备 32GB GDDR7 显存理论显存带宽约 1,792 GB/s适合中小规模模型的单卡推理。显存规划不能只看模型权重还要为 KV Cache、CUDA runtime、临时缓冲和其他运行时开销预留空间。Blackwell 架构支持现代低精度推理能力但实际可用的量化方案仍应以模型、推理框架和镜像兼容性为准。二、环境准备与部署1. 硬件与驱动检查5090 基于 Blackwell 架构。应使用支持该 GPU 架构的 NVIDIA 驱动和框架发行包若需要编译 PyTorch、CUDA 扩展或使用特定镜像还应按对应发布说明核对 CUDA Toolkit 与依赖版本。连接实例后先确认nvidia-smi预期应能识别到 RTX 5090 及其显存容量驱动版本是否可用请以当前镜像、PyTorch 与 vLLM 的兼容性要求为准。2. 安装vLLMpipinstallvllm--upgrade安装完成后建议记录 vLLM、PyTorch、CUDA runtime 与驱动版本方便后续排查兼容性和复现实验结果。3. 启动推理服务以Llama 3 8B为例vllm serve meta-llama/Llama-3-8B-Instruct\--max-model-len32768\--max-num-seqs64\--gpu-memory-utilization0.92\--enable-prefix-caching\--host0.0.0.0\--port8000--max-model-len 32768限制单个请求允许的最大序列长度。是否能稳定支持 32K取决于模型权重、KV Cache、运行时开销及实际请求情况。--max-num-seqs 64限制同时处于调度范围内的最大序列数不等同于“可同时稳定承载 64 个 32K 请求”。--gpu-memory-utilization 0.92指定该 vLLM 实例可使用的 GPU 显存目标比例会影响可留给 KV Cache 的空间最终 KV Cache 块池还受模型权重、启动 profile、CUDA Graph 与当前版本实现影响。--enable-prefix-caching启用前缀缓存。对存在相同系统提示词、模板或文档前缀的请求可能有帮助实际收益取决于请求重复度。--max-model-len × --max-num-seqs可用于估算理论最坏 KV 数据量但不等同于 vLLM 实际预分配的 KV Cache 容量。首次部署建议先用较保守的上下文与并发参数启动再根据启动日志、显存余量和压测结果逐步调整。4. 验证服务curlhttp://localhost:8000/v1/chat/completions\-HContent-Type: application/json\-d{ model: meta-llama/Llama-3-8B-Instruct, messages: [{role: user, content: 你好}] }三、性能实测不同模型的吞吐量数据吞吐量、首 token 时间和可承载并发必须绑定模型版本、权重量化格式、vLLM 版本、驱动、输入输出长度、并发请求组成及压测方法解读。原有第三方汇总数值缺少统一复现条件因此不建议将其直接作为当前部署的容量承诺或成本测算依据。实际压测时建议至少记录以下指标单请求和多并发下的 TTFT、输出 token 速率与端到端延迟。固定输入长度、固定最大输出长度下的总吞吐量。GPU 显存占用、KV Cache 使用情况及排队请求数。长上下文、突发并发和目标业务真实 prompt 下的 P95/P99 延迟。关键结论7B、8B 级模型通常是 32GB 单卡上更容易获得显存余量的服务起点但实际并发人数不能仅由某个 batch 吞吐数字换算。13B、14B 模型能否以 BF16/FP16 或量化方式稳定运行取决于权重体积、上下文长度、KV Cache 精度和并发目标部署前应以启动日志和压测确认。对于更大模型量化可以降低权重占用但仍需同时评估 KV Cache 与运行时余量不能仅按“权重能加载”判断可服务性。并发与延迟关系并发增加通常有利于提高总吞吐但也可能增加排队时间和单请求延迟。实时对话、批处理生成和离线任务的目标不同应以目标 TTFT、P95 延迟和总吞吐共同确定--max-num-seqs而不是套用固定的并发上限。四、成本测算按小时租赁 vs 自建立方云5090租赁成本按小时和包月的实例价格、库存和计费规则会随时间及具体配置变化请以创建实例页面和官网当日信息为准。短期验证、临时扩容和阶段性压测通常适合按量使用长期稳定负载可再比较包月方案与自建总拥有成本。推理成本估算可使用以下口径估算单位 token 成本每百万 token 成本 ≈ 单位时间实例成本 ÷ 同一压测口径下每小时处理 token 数 × 1,000,000其中“每小时处理 token 数”必须使用目标模型、量化格式、输入输出长度和真实并发下的实测值还应计入空闲时间、失败重试、模型加载和数据传输等业务成本。因此该指标更适合比较同一业务负载下的不同方案而不宜脱离压测条件给出固定结论。与RTX 4090的对比5090 的 32GB 显存和更高显存带宽为较大模型、较长上下文或更高并发预留了更多空间。与 4090 的实际吞吐差异、实例价格差异及每 token 成本应在相同模型、量化格式、推理后端、上下文和压测方法下比较。自建成本参考自建需要综合考虑 GPU 与整机采购、折旧、电力、网络、运维、人力和扩容周期云端则需考虑实例单价、存储、数据传输和空闲时段的资源释放。是否租赁优于自建没有固定利用率分界线应以实际负载曲线和服务周期测算。五、生产环境优化建议1. 低精度与KV Cache优化对显存或带宽敏感的任务可评估权重量化和 FP8 KV Cache 等方案。例如vllm serve模型名称\--kv-cache-dtype fp8_e4m3\--max-model-len目标上下文长度\--max-num-seqs目标并发上限\--gpu-memory-utilization目标比例是否支持 FP8 权重量化、具体参数名称以及精度和性能收益取决于模型、vLLM 版本及硬件支持。启用后应分别验证输出质量、长文本稳定性、KV Cache 容量和实际吞吐不应将特定第三方成绩直接外推到其他模型或配置。2. 多模型共享一张卡5090 可以尝试在同一 GPU 上部署聊天、嵌入或重排等不同服务但每个进程都会占用模型权重、KV Cache 和运行时显存。--gpu-memory-utilization是单个 vLLM 实例的显存目标比例不应视为跨进程的严格显存切片或配额隔离机制。多进程部署前建议先按各模型实际显存占用预留安全余量并在目标版本中逐一启动、观察nvidia-smi和服务日志。若追求隔离性、稳定性或可预测的资源分配应优先评估单服务部署、专用 GPU 或平台提供的隔离能力。3. 监控与告警vLLM 可暴露 Prometheus 指标。不同版本的指标名称和标签可能不同建议以当前服务的/metrics输出为准重点关注请求排队、成功率、端到端延迟及 P95/P99 延迟。Prefill 与 decode 吞吐、生成 token 数和异常率。GPU 显存、GPU 利用率、KV Cache 使用情况及 OOM 日志。告警阈值应按业务 SLO、模型和压测基线设定。例如 GPU 利用率偏低不必然意味着预处理瓶颈KV Cache 占用偏高也不必然意味着应立刻扩容应结合排队、延迟、错误率和实际用户体验判断。六、以立方云为例的部署路径如果不想本地配置硬件可以在立方云租用 5090 实例创建实例选择 RTX 5090 卡型并按当前页面确认计费方式、镜像内容、数据盘和网络配置。环境安装SSH 连接后安装或核对 vLLM、PyTorch、CUDA runtime 与模型依赖。启动服务按上述命令启动 vLLM通过nvidia-smi、服务日志和健康检查确认 GPU 状态。压测验证使用curl、压测工具或业务真实请求验证吞吐、延迟、显存和错误率是否满足需求。释放资源短期不再使用时按平台当前规则停止或删除实例删除前应备份模型、代码、结果文件和必要环境信息。模型文件建议放在已确认具有相应持久化规则的目录或数据盘中。停止实例、删除实例、系统盘、数据盘、镜像和对象存储的保留及计费规则可能不同应以操作当天的平台说明为准删除后关联数据不应再视为可用或可恢复。七、常见问题1. 5090能同时跑几个模型取决于每个模型的权重体积、量化格式、上下文、KV Cache、并发目标和运行时开销。8B 聊天模型与小型嵌入模型有可能共存但不能仅凭模型参数量判断也不能把--gpu-memory-utilization当作精确的跨进程配额。应以逐个启动后的实际显存占用和压测结果为准。2. vLLM和 Ollama 比吞吐量提升多少两者的定位、模型格式、批处理方式、KV Cache 策略和默认参数不同。vLLM 的 PagedAttention 与 Continuous Batching 在多请求服务场景中通常具有优势但具体提升幅度必须在相同模型、量化格式、上下文、硬件和请求负载下实测不能用固定倍数概括。3. 为什么batch大了延迟反而更高vLLM 会在吞吐与请求响应之间调度。批次或排队请求增多时总吞吐可能提升但单个请求的等待时间也可能增加。实时对话应根据目标 TTFT 和 P95 延迟逐步调整--max-num-seqs、最大输出长度等参数是否使用 speculative decoding也应先验证模型支持与实际收益。4. 模型加载后显存占用稳定吗模型权重通常相对稳定但请求长度、并发、KV Cache、CUDA Graph 和临时缓冲都会影响运行过程中的显存占用。应设置合理的--max-model-len并结合启动日志、GPU 显存、KV Cache 相关指标和业务压测观察余量。5. 按小时计费适合长期服务吗短期验证和弹性扩容通常适合按小时使用若服务 7×24 运行且负载稳定应基于当日实例价格、包月方案、存储与网络费用以及自建总拥有成本综合比较。立方云是网鼎科技旗下专注 GPU 算力租赁的平台提供 RTX 5090 等高性能 GPU 实例支持按当前产品规则提供相应计费方式。如需了解 5090 实例的实时库存、配置详情与价格请以立方云官网信息为准。