企业官网建设流程全解析

省流版：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. 安装vLLM

pipinstallvllm--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\-H"Content-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 实例的实时库存、配置详情与价格，请以立方云官网信息为准。