为 LLM 推理选配 GPU 服务器

大多数 LLM 选型问题，归根结底只有一个：模型本身，加上承载你的业务流量所需的显存，能否装进 GPU？本指南给出具体算法，并套用到 FlexDedi 的两款 GPU 服务器上：配备一块 NVIDIA L40S 48 GB 的 GPU L40S，以及配备两块 NVIDIA RTX PRO 6000 Blackwell 96 GB 的 GPU RTX PRO，同时提供两者的 vLLM 启动命令。

显存计算公式

VRAM needed ≈ weights + KV cache + runtime overhead

运行时开销包括 CUDA 上下文、激活值、CUDA Graph 和显存分配器碎片；每块 GPU 预留几 GB 即可。vLLM 会按 --gpu-memory-utilization 设定的比例（下文示例中为 0.90）预留 GPU 显存，加载权重，测算激活值占用的显存，再把剩下的全部分配给 KV 缓存。

请以 nvidia-smi 报告的容量为准进行规划。由于 GDDR 显存上的 ECC 会占用一部分容量，这个数字可能比标称值少几 GB。按 0.90 的利用率，本指南采用的可用预算为：单块 L40S 约 40 GB，每块 RTX PRO 6000 约 85 GB，两块合计约 170 GB。

权重：参数量 × 每参数字节数

weights (GB) ≈ parameters (billions) × bytes per parameter

INT4 每个参数实际占用略多于半个字节，因为量化缩放因子（通常还有嵌入层和输出层）仍以更高精度保存。两款 GPU 都在硬件层面支持 FP8。Blackwell 还新增了 FP4 Tensor Core，但只有当你的推理服务栈为该 GPU 和模型提供了 FP4 内核时才能发挥作用。降低精度可能会损失准确率，因此在切换之前，请先用你自己的评测集验证量化后的模型。

对于混合专家（MoE）模型，显存占用取决于总参数量，因为每个专家都必须常驻显存；而每个 token 的计算量取决于小得多的激活参数量。

KV 缓存：随流量增长的部分

每个活跃序列中的每个 token，都会在每一层保存一个 Key 向量和一个 Value 向量：

KV bytes per token = 2 × layers × KV heads × head dimension × bytes per element
KV cache ≈ KV bytes per token × tokens per sequence × concurrent sequences

公式中的参数可以从模型的 config.json 中读取：num_hidden_layers、num_key_value_heads 和 head_dim（或用 hidden_size 除以 num_attention_heads）。正是分组查询注意力（GQA）让 KV 头数远少于注意力头数，这些数字才得以控制在可接受的范围内。

--kv-cache-dtype fp8 能把缓存减半，代价通常是少量的准确率损失，值得在你的评测集上验证。vLLM 会随着 token 的到来按块分配缓存，因此短请求不会预占整个上下文的空间。但无论如何，都应按你愿意承接的最坏情况做规划：缓存一旦占满，新请求就只能排队等待。

示例 1：在单块 L40S 上运行 14B 模型

在 GPU L40S 上部署 Qwen/Qwen3-14B-FP8，以下数字均为近似值：

• 预算：约 40 GB
• 权重：约 16 GB（14.8B 参数，每个 1 字节，外加以更高精度保存的层）
• 开销：约 3 GB
• KV 缓存：40 − 16 − 3 ≈ 21 GB
• 按每 token 80 KiB 计算的容量：21 GB ÷ 80 KiB ≈ 250,000 个 token

也就是说，在模型完整的 32K 上下文下约可并发 7 条序列；如果每条 4K token，则约可并发 60 条。

curl -LsSf https://astral.sh/uv/install.sh | sh
uv venv --python 3.12 --seed && source .venv/bin/activate
uv pip install vllm --torch-backend=auto
vllm download-kernels   # optional: fetch prebuilt kernels instead of compiling at startup

vllm serve Qwen/Qwen3-14B-FP8 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --kv-cache-dtype fp8 \
  --max-num-seqs 64 \
  --host 10.0.0.10 --port 8000 \
  --api-key "$VLLM_API_KEY"

请先安装最新的 NVIDIA 数据中心驱动，并确认 nvidia-smi 能列出 GPU；RTX PRO 6000 等 Blackwell 显卡需要使用 NVIDIA 的开源内核模块。vLLM 启动时会在日志中输出 KV 缓存大小，以及在你设定的 --max-model-len 下的最大并发数，请将其与你的估算结果对比。把 --host 绑定到内网地址并设置 --api-key，可以让该端点不暴露在公网上，并要求每个请求都携带 Bearer Token。

示例 2：在两块 RTX PRO 6000 上运行 70B 模型

BF16 精度的 70B 模型，权重约需 141 GB（70.6B 参数 × 2 字节），超出了单块 GPU 的容量。采用张量并行后，每块 GPU 各承载一半的权重和一半的 KV 头：

• 每块 GPU 的预算：约 85 GB
• 每块 GPU 的权重：约 70.5 GB
• 每块 GPU 的开销：约 3 GB
• 每块 GPU 的 KV 缓存：约 11.5 GB
• FP8 下每块 GPU 每 token 占用：160 KiB ÷ 2 = 80 KiB
• 容量：11.5 GB ÷ 80 KiB ≈ 140,000 个 token，约合 4 条 32K 序列或 34 条 4K 序列

如果改用 FP8 权重（约 70 GB，即每块 GPU 35 GB），每块 GPU 的 KV 预算将增加到约 47 GB：大约可容纳 570,000 个 token，即 17 条 32K 序列。正因为差距如此之大，在这台服务器上运行 70B 级模型时，FP8 检查点（checkpoint）值得认真评估。

export HF_TOKEN=hf_your_token   # Llama weights are gated: accept the license on Hugging Face first
vllm serve meta-llama/Llama-3.3-70B-Instruct \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --kv-cache-dtype fp8 \
  --host 10.0.0.10 --port 8000 \
  --api-key "$VLLM_API_KEY"

基于 PCIe 的张量并行

两块 GPU 之间都没有 NVLink，因此两块 RTX PRO 6000 之间的通信走 PCIe 5.0；可以用 nvidia-smi topo -m 查看具体路径。张量并行需要在每一层内部同步各块 GPU，因此只有在模型单卡放不下，或者需要降低大模型单个请求的延迟时，才值得采用。

如果模型单卡就能放下，更好的做法是每块 GPU 各运行一个副本。这样显卡之间没有通信流量，vLLM 会把请求分摊到两块卡上：

vllm serve Qwen/Qwen3-14B-FP8 --data-parallel-size 2 --max-model-len 32768 --kv-cache-dtype fp8

对于大模型，--pipeline-parallel-size 2 是第三种选择。它按层而不是按张量切分，交换的数据更少，代价是会产生流水线气泡，因此请用你自己的真实流量，将它与张量并行做对比测试。

哪些模型能装进哪台服务器

以下为利用率 0.90、KV 缓存采用 FP8 时的大致容纳情况：

CPU、内存和 NVMe 同样重要

系统内存。 权重在加载时会经过主机内存，Linux 页缓存会保留最近加载过的模型文件，这样重启时就不必再从磁盘重新读取。一条常见的经验法则是：系统内存至少要与显存总量相当。GPU L40S 为 48 GB 显存配备了 256 GB 内存，GPU RTX PRO 为 192 GB 显存配备了 576 GB 内存。多出来的内存可用于 API 服务、分词、向量数据库和嵌入模型等检索组件，以及借助 LMCache 等工具把 KV 缓存卸载到 CPU 内存。

CPU。 GPU L40S 中的 EPYC 9355P（32 核）和 GPU RTX PRO 中的 EPYC 9455P（48 核）负责调度、分词以及前后处理。主机 CPU 一旦跑满，就会表现为 GPU 在各步之间出现空闲，用 nvidia-smi dmon 可以观察到。

NVMe。 加载时间约等于模型大小 ÷ 持续读取速度。粗略估算，假设读取速度为 5 GB/s，141 GB 大约需要 30 秒。Gen5 硬盘（GPU L40S 为 2 × 3.84 TB，GPU RTX PRO 为 2 × 7.68 TB）还能同时存放多个模型版本；用 export HF_HOME=/srv/models 把 Hugging Face 缓存指向这些硬盘即可。

吞吐量：预期表现与测量方法

推理分为两个阶段。预填充（Prefill）阶段并行处理提示词，属于计算密集型；提示词越长，首 token 时延（TTFT）越高。解码（Decode）阶段每一步为每条序列生成一个 token，在批量较小时受限于显存带宽，因为每一步都要读取一遍权重。由此可以得出单条流的速度上限，但这只是上限，并非实测值：

decode tokens/s per sequence ≤ memory bandwidth ÷ bytes read per token (≈ weight bytes)

例如，在显存带宽为 864 GB/s 的 L40S 上运行 14B FP8 模型（约 16 GB），单条流的速度不会超过约 54 tokens/s，实际数值还会更低。NVIDIA 公布的 RTX PRO 6000 Blackwell Server Edition 显存带宽约为 1.6 TB/s。

批处理会改变这一局面。每个解码步骤只需读取一次权重，就能服务批次中的所有序列，因此总吞吐量会随并发数上升，直到算力或 KV 缓存耗尽；与此同时，每个用户获得的 tokens/s 会下降。vLLM 的连续批处理（continuous batching）会自动处理这一切；你要做的是在总吞吐量与每输出 token 时延（TPOT）之间，找到产品能够接受的平衡点。请用你自己的提示词长度进行测量：

export OPENAI_API_KEY="$VLLM_API_KEY"   # sent as the bearer token
vllm bench serve --backend vllm --model Qwen/Qwen3-14B-FP8 \
  --base-url http://10.0.0.10:8000 \
  --dataset-name random --random-input-len 1024 --random-output-len 256 \
  --num-prompts 200 --max-concurrency 16 \
  --percentile-metrics ttft,tpot --metric-percentiles 95,99

用多个不同的 --max-concurrency 值重复测试，选出仍能满足 p95 和 p99 延迟目标的最大值。

GPU L40S 还是 GPU RTX PRO

以下情况选择 GPU L40S（$979/月）：

• 模型参数量在约 14B 以内（BF16 或 FP8），或在 30B 左右（INT4）；
• 除了一个中等规模的对话模型，还要同时提供嵌入、重排序、语音转文字或图像生成服务；
• 你更倾向于用多台较小的服务器横向扩展，或者除了阿什本、阿姆斯特丹或法兰克福之外，还需要达拉斯机房。

以下情况选择 GPU RTX PRO（$2,199/月）：

• 需要部署 70B 级稠密模型、大型 MoE 模型，或为大量并发用户提供长上下文服务；
• 希望同时运行两个模型，每块 GPU 一个；
• 除了推理服务，还要用 LoRA 或 QLoRA 进行微调，192 GB 显存能带来明显优势；
• 希望推理服务栈一旦支持，就能立即用上 FP4 硬件。

按每 GB 显存计算，RTX PRO 服务器更便宜：每 GB 每月约 $11.45，而 L40S 服务器约为 $20.40。

在 FlexDedi 上运行

参数量在约 14B 以内的模型，建议从 GPU L40S（$979/月）起步；70B 级模型、大型 MoE 模型或长上下文业务，则选择 GPU RTX PRO（$2,199/月）。两者均配备 25 Gbps 端口、不限流量和 Gen5 NVMe，均按订单组装，通常当天交付。把应用服务器部署在它们旁边，通过免费的内网通信，让推理 API 永远不直接面向公网；并为每台主机套用 Linux 安全基线。更多信息请参阅 AI 推理页面。