用于 LLM 推理的最佳 GPU，是在满足内存、延迟和可靠性目标的同时，以最低可接受成本覆盖你真实提示词组合的那块 GPU。它不一定总是最新的 GPU、每小时挂牌最便宜的实例，或者基准测试分数最高的显卡。
对于大多数企业 AI 团队来说，简短答案是：
- 当内存是瓶颈时，选择 H200：70B 级别的 serving、长上下文 RAG、高并发，或会把 H100 推到极限边缘的 KV cache。
- 当你需要成熟的生产标准、强大的软件支持、广泛的云可用性，以及不错的吞吐量而又不想迁移到新的 Blackwell 能力时，选择 H100。
- 当你的技术栈能够利用 Blackwell 时代的精度和拓扑结构，并且供应商能够证明真实可用性、价格和运维支持时，选择 B200、GB200 或更新的 Blackwell 系统。
- 当成本效益比峰值延迟更重要、模型能够轻松装入，并且你的工作负载是批处理、内部使用或中等上下文时，选择 L40S 或 A100。
- 用于本地 LLM 推理、开发、演示和小规模私有负载时，选择 RTX 4090、RTX 5090 或工作站级 GPU，而不是企业级多租户 serving。
- 当流量呈脉冲式、模型选择经常变化，或者运营 serving 技术栈并不是你的核心竞争力时，使用 模型 API 或路由器，而不是租 GPU。
本指南说明如何按内存、吞吐量、延迟和每 token 成本来选择 用于 LLM 推理的最佳 GPU。它还包括一个决策矩阵、一个基准测试计划，以及一个你可以在租用或购买算力之前复用的每美元 token 计算表。
用于 LLM 推理的最佳 GPU：快速决策矩阵
| 工作负载 | 最佳起步 GPU | 通常适配的原因 | 注意事项 |
|---|---|---|---|
| 7B-13B 聊天、内部工具、原型 | L40S、RTX 4090、RTX 5090、A100 40GB 或 L4 级云算力 | 当模型较小且并发中等时，更低的小时成本可能比加速器的峰值速度更重要。 | 不要把本地演示的延迟外推到生产流量的 p95/p99。 |
| 30B-34B 推理 | L40S、A100 80GB、H100 PCIe/SXM | 具备足够内存以支持实用的 serving 配置，同时比 H200 或 B200 的小时成本门槛更低。 | 长上下文和高并发可能会把工作负载推向 H100/H200 领域。 |
| 70B 级推理 | H100、H200 或 A100/H100 多 GPU | H100 是成熟基线；当内存和 KV cache 压力减少所需 GPU 数量时，H200 更具吸引力。 | 量化、张量并行和 batch 策略决定真实成本。 |
| 长上下文 RAG | 优先 H200，然后是 H100 NVL/SXM 或 B200（如果可用） | KV cache 和 prompt prefill 可能让容量与内存带宽比原始小时价格更重要。 | 请使用真实上下文长度进行基准测试，而不只是短提示词。 |
| 高吞吐批处理推理 | A100、L40S、H100 或 H100 spot/marketplace | 当任务可以排队时，单位成本的吞吐量往往优于最低延迟。 | 把重试、中断、冷启动和存储成本都算进去。 |
| 面向客户、对延迟敏感的聊天 | H100、H200 或 B200，取决于模型大小 | 更新一代的数据中心 GPU 对 serving 技术栈、带宽和并发余量的支持更好。 | p95 和 p99 延迟比平均 tokens/秒更重要。 |
| 本地 LLM 推理 | RTX 4090、RTX 5090、RTX PRO 工作站卡 / RTX 6000 级别 | 本地显卡适合私有开发、离线测试和小模型。 | 消费级显卡不能替代受管理的多租户可靠性。 |
| 受监管或企业生产环境 | 来自支持、网络、隔离和审计控制完善的提供商的 H100/H200/B200 | 运维层可能比 GPU 名称本身更重要。 | 检查 SLA、替换策略、网络、存储和可观测性。 |
经验法则：用于 LLM 推理的最佳 GPU 会随着模型大小、上下文长度、并发、精度、serving 框架和价格而变化。让 GPU 去匹配你的工作负载。
为什么内存通常决定第一轮候选名单
LLM 推理使用 GPU 内存的不只是模型权重。生产服务器还需要 KV cache、运行时开销、批处理缓冲区、adapter、分词器/服务器开销，有时还需要 speculative decoding 或结构化输出缓冲区。
使用这个第一轮内存模型：
required_vram =
model_weights
+ KV_cache_for_target_context_and_concurrency
+ runtime_overhead
+ safety_margin
KV cache 是一个模型为什么能在简短演示中运行、却在生产环境中失败的原因。长提示、更大的批次、更多并发请求以及更大的输出上限都会增加内存压力。用于 LLM 推理的最佳 GPU 性价比往往是那块能够避免额外分片、避免因内存不足而重试，或者允许在不损害 p95 延迟的情况下保持更大 batch 的 GPU。
内存容量也会改变运维方式：
| 内存状况 | 这对 LLM serving 的含义 |
|---|---|
| 有充足余量 | 你可以调整 batch size、上下文长度和并发，而不会立即有 OOM 风险。 |
| 接近上限 | 量化、更小的 batch、更短的上下文或 tensor 并行变成必需项。 |
| 超过上限 | 你需要更多 GPU、内存更大的 GPU、更小的模型、更低精度，或者通过 API 路由。 |
NVIDIA 将 H200 列为配备 141GB HBM3e 内存和 4.8TB/s 内存带宽。NVIDIA 的 H100 页面将 H100 定位为成熟的 Hopper 基础，而 AWS P5 页面展示了 H100 和 H200 实例家族，每个节点最多 8 块 GPU，并具备 NVSwitch GPU-to-GPU 带宽。对于采购工作来说，关键不在于某一行规格，而在于额外内存是否能减少 GPU 数量、简化分片，或提高可接受吞吐量。
吞吐量：每秒 token 数还不够
原始 tokens/sec 很有用，但它不是买家真正关心的指标。对于生产服务，请衡量被接受的工作量：
accepted_output_rendimento =
accepted output tokens or accepted responses
/ wall-clock benchmark duration
然后按成本归一化：
token_per_dollar =
accepted output tokens per hour
/ effective hourly cost
这就是 最佳 LLM 推理 GPU token/s/usd 搜索背后的核心指标。更便宜的 GPU 在保持高利用率且延迟目标更灵活时可能胜出。更昂贵的 GPU 在它能提升 batch size、减少副本、避免内存故障，或让 p95/p99 延迟保持在服务级别目标内时可能胜出。
将吞吐量分成两个阶段：
| 阶段 | 什么会给 GPU 带来压力 | 需要测量什么 |
|---|---|---|
| Prefill | 提示长度、注意力计算、内存移动、缓存复用 | 首 token 时间、提示 tokens/sec、队列等待 |
| Decode | 输出长度、batch 调度、KV cache 带宽 | 输出 tokens/sec、token 间延迟、p95/p99 完成时间 |
对于长上下文 RAG 和 agent 流量，prefill 可能占主导。对于长回复的流式聊天，decode 可能占主导。对于批量分类，每分钟接受的请求数可能比流式延迟更重要。
延迟：要为 p95 和 p99 选择，而不是为平均速度选择
在面向用户的 SLA 下，最佳 LLM 推理 GPU 是那块在负载下仍能将尾延迟控制住的 GPU。平均延迟会掩盖排队、嘈杂邻居、缓存失效、冷启动以及 OOM 后的重试。
在每次 GPU 测试中跟踪这些指标：
able>| 指标 | 为什么重要 |
|---|---|
| 首 token 时间 | 用户感知的响应速度和 prefill 效率。 |
| Token 间延迟 | 流式体验质量和 decode 速度。 |
| 端到端延迟 | 任务完成总时间。 |
| p95 和 p99 延迟 | 生产环境中真实的 SLO 健康状况。 |
| 队列等待 | 服务器是否在生成开始前就已经过载。 |
| OOM 和重试率 | 基准是否足够稳定，能否指导采购。 |
| GPU 利用率和 HBM 带宽利用率 | GPU 是否是瓶颈，还是流水线在别处等待。 |
如果 H200 的报价是 H100 的 1.4 倍，而它为你的工作负载提供 1.8 倍可接受输出吞吐量，那么 H200 可能会胜出。如果它的价格是 2.2 倍，但 p95 只改善 10%，那么 H100 很可能胜出。如果 L40S 便宜得多，并且能够满足 13B 模型的延迟目标，那么对于该场景来说，L40S 可能是LLM 推理性价比最佳 GPU。
本地 LLM 推理的最佳 GPU
本地 LLM 推理的最佳 GPU与企业级 serving 的最佳 GPU 是不同的问题。本地推理通常更看重采购价格、桌面功耗、VRAM、隐私以及开发者便利性。生产环境 serving 更看重可用性、可观测性、替换策略、互连、多租户隔离和支持。
对于本地使用：
- RTX 4090 和 RTX 5090 是本地开发小型与量化模型的强力选择，因为它们提供高性能消费级 GPU 性能以及足以支持许多实验的 VRAM。
- RTX PRO / RTX 6000 级工作站 GPU 在你需要更多 VRAM、工作站驱动或专业支持时更合适。
- Mac 的统一内存或 CPU 推理 可能对测试有用，但不应被视为 GPU serving 的基准。
- 多 GPU 本地机器 适合研究，但除非你的团队负责供电、散热、网络、监控和故障恢复，否则很难达到云数据中心的运营水平。
使用本地 GPU 来验证提示词、质量、量化和应用行为。使用云端或数据中心 GPU 来验证生产并发、p95/p99 延迟、可用性、每个可接受 token 的成本以及发布流程。
按模型和 serving 模式推荐的 GPU
| serving 模式 | GPU 精选列表 | 原因 |
|---|---|---|
| 7B/8B 支持机器人，中等上下文 | L40S、A100 40GB/80GB、H100 PCIe、本地开发级 RTX | 模型足够小，因此较低的每小时成本可能比顶级内存更重要。 |
| 13B-34B 私有助手 | L40S、A100 80GB、H100 | 根据并发和延迟目标选择；当尾延迟很重要时，H100 很有用。 |
| 70B 中等上下文聊天 | H100、H200、2x A100/H100，取决于精度 | 对量化、张量并行和批处理策略进行基准测试。 |
| 长上下文 RAG 70B | H200、H100 NVL/SXM、B200（若可用） | 内存和 KV cache 压力可能占主导。 |
| 多租户企业 API | 来自提供商并带支持的 H100/H200/B200 | 支持、可观测性、隔离和替换策略都很重要。 |
| 离线批量推理 | A100、L40S、H100 spot 或 marketplace | 每美元吞吐量可能比最低延迟更重要。 |
| 开发者笔记本或台式机 | RTX 4090、RTX 5090、RTX PRO/工作站 | 非常适合本地 LLM 推理和提示词开发；但这不是完整的生产环境方案。 |
租用或购买前的基准测试计划
不要仅凭通用基准测试来选择LLM 推理的最佳 GPU。请运行一个尽可能接近你产品的复现测试。
- 冻结工作负载。 记录模型 ID、量化、精度、提示词长度分布、输出长度分布、目标上下文、并发以及质量检查。
- 冻结 serving 栈。 在所有 GPU 测试中，尽可能使用相同版本的 vLLM、SGLang、TensorRT-LLM、NIM 或自定义服务器。
- 冻结硬件配置。 记录 GPU SKU、GPU 数量、PCIe/SXM/NVL、CPU、RAM、存储、驱动、CUDA 版本、网络和摆放方式。
- 运行三种流量轨迹。 短聊天、长上下文 RAG 以及批量/离线提示词会暴露不同的瓶颈。
- 测量 p50、p95、p99。 面向客户的推理不能只看平均延迟。
- 跟踪失败。 统计 OOM、超时、驱逐、冷启动失败和重试放大。
- 计算可接受成本。 用有效成本除以可接受输出 token、可接受响应或已完成任务。
- 至少运行一天 canary。 在真实流量窗口内，marketplace 价格、提供商可用性和排队情况都可能变化。
最小基准测试表：
| 指标 | 候选 GPU A | 候选 GPU B | 候选 GPU C |
|---|---|---|---|
| GPU 每小时价格 | |||
| 有效每小时成本 | |||
| 每小时可接受输出 token 数 | |||
| 每 100 万可接受输出 token 成本 | |||
| 首 token p95 时间 | |||
| 端到端延迟 p95/p99 | |||
| OOM 或重试率 | |||
| GPU 平均利用率 | |||
| 运营备注 |
当模型 API 胜过租用 GPU 时
用于 LLM 推理的最佳 GPU，实际上可能是完全不租 GPU。当你拥有专有权重、持续高利用率、自定义 kernel、强数据局部性，或者有一支能够让 GPU 保持忙碌的 serving 团队时，直接控制 GPU 才更有价值。
在以下情况下，使用模型 API 或路由器：
- 流量不稳定。
- 你需要多个模型提供商，而不是单一固定的 open-weight 模型。
- 模型选择经常变化。
- 你更需要故障切换，而不是裸金属控制。
- GPU 空闲时间带来的成本会超过任何按 token 计算的 API 溢价。
- 你的团队希望在不运营 serving 集群的情况下，获得使用日志、预算限制、账单和提供商治理能力。
Flatkey 正适合这一决策路径：一个密钥、一个余额、一张账单、300 多个官方模型、1,000 多个按调用付费工具，以及请求级使用记录。如果某个工作负载不需要自托管权重，那么在承诺部署 GPU 集群之前，应先比较 GPU 的每个可接受 token 成本与托管模型路由的成本。
如需相关成本决策，请参阅 Flatkey 关于 GPU 租赁价格、H100 vs A100、H200 vs H100、GPU 集群租赁、vLLM vs SGLang 和 AI 模型价格比较 的指南。
最终建议
用于 LLM 推理的最佳 GPU取决于工作负载：
- 当显存、长上下文和 KV cache 压力决定成本时，使用 H200。
- 当你需要经过验证的生产标准，而且工作负载适配时，使用 H100。
- 当 Blackwell 容量可用、serving 栈已经准备好，并且你的 benchmark 证明了溢价合理时，使用 B200 或 GB200。
- 当性价比优先于最小延迟时，使用 L40S 或 A100。
- 用于开发和本地 LLM 推理时，使用 RTX 类本地 GPU，而不是企业多租户 serving。
- 当直接运营 GPU 并不是产品优势时，使用 Flatkey 或其他模型 API 层。
购买指标不是“哪块 GPU 最快？”而是 在你的产品所需的延迟和可靠性水平下，每个可接受 token 的成本。
常见问题
用于 LLM 推理的最佳 GPU 是什么？
用于 LLM 推理的最佳 GPU 取决于工作负载。对于受显存限制的 70B 和长上下文 serving，H200 通常是最强的起点。H100 是成熟的生产标准。对于更小模型、批处理任务或本地推理，只要能以更低成本满足延迟目标，L40S、A100、RTX 4090 或 RTX 5090 可能更合适。
用于 LLM 推理，哪块 GPU 的性价比最高？
用于 LLM 推理，性价比最高的 GPU 是每个可接受 token 或可接受响应成本最低的 GPU，而不是每小时价格最低的 GPU。在选择之前，请计算有效小时成本、每小时可接受输出 token、p95/p99 延迟和失败率。
如何按 token/s/usd 计算用于 LLM 推理的最佳 GPU？
使用每小时可接受输出 token 数除以有效小时成本。有效成本应包括 GPU 租赁、存储、带宽、空闲时间、重试、支持和工程开销。然后在 GPU 之间比较相同模型、精度、上下文长度和 serving 栈。
H100 还是 H200 更适合 LLM 推理？
当显存容量、带宽、长上下文或更大的 KV cache 会改变 serving 形态时，H200 通常更好。当模型能够很好地装入、容量更便宜或更容易获得，而且 benchmark 达到延迟和吞吐目标时，H100 通常更好。
B200 是用于 LLM 推理的最佳 GPU 吗？
当供应商有真实可用容量、serving 框架支持你打算使用的精度和拓扑，并且 benchmark 证明更低的可接受成本时，B200 或 GB200 系统可能非常适合大规模 LLM 推理。不要仅凭发布承诺就购买 Blackwell 容量；请测试你的流量。
用于本地 LLM 推理的最佳 GPU 是什么？
对于本地 LLM 推理，RTX 4090 和 RTX 5090 是开发者常用的高性能选择；而当你需要更多 VRAM 或工作站级专业支持时，RTX PRO 或 RTX 6000 级显卡更合适。本地 GPU 更适合开发、隐私和小规模部署，而不是企业级 serving 的全面可靠性。
已验证来源
- NVIDIA H200 GPU: https://www.nvidia.com/en-us/data-center/h200/
- NVIDIA H100 Tensor Core GPU: https://www.nvidia.com/en-us/data-center/h100/
- NVIDIA A100 Tensor Core GPU: https://www.nvidia.com/en-us/data-center/a100/
- NVIDIA DGX B200: https://www.nvidia.com/en-us/data-center/dgx-b200/
- NVIDIA L40S GPU: https://www.nvidia.com/en-us/data-center/l40s/
- NVIDIA GeForce RTX 5090: https://www.nvidia.com/en-us/geforce/graphics-cards/50-series/rtx-5090/
- RunPod GPU 云价格：https://www.runpod.io/pricing
- Lambda GPU 云价格：https://lambda.ai/pricing
- AWS EC2 P5 实例：https://aws.amazon.com/ec2/instance-types/p5/
- Google Cloud GPU 机器类型：https://docs.cloud.google.com/docs/compute-area/gpus
- vLLM 的 OpenAI 兼容服务器文档：https://docs.vllm.ai/en/latest/serving/openai_compatible_server.html
