选型 指南 · 阅读需 10 分钟

# 一台 GPU 实际能服务多少人。

能放下您模型的机器，不等于能服务您用户的机器。权重是一次性支付的通行费；付清之后剩下的，才是您用来服务用户的全部预算。真正决定容量的，是那部分剩余显存，而不是显卡本身的大小，而且它变化的速度远快于显存本身。

简短的答案

- **容量取决于剩余显存，而非整张显卡:** **Llama 3.3 70B**在 4-bit 下，在服务任何人之前就要预留 **40 GB**。此后每多一个并发请求，都再多花 **2.9 GB**。
- **这就是为什么显存要付两次钱:** 在同一款显卡上，从 48 GB 升到 240 GB，显存变为 5.0× 倍，席位数却变为 **35×** 倍。因为权重的钱已经付过了。
- **候选清单里最不划算的一台:** [NVIDIA L40S](https://gpuserver.io/zh/gpu/l40s) 每月 **$714**，可容纳 2 个并发请求 — 每席位 **$357.00**。
- **最优的那一台，价格反而更低:** [4 × NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) 只要 **$564**，即可容纳 19 — 每席位 **$29.68**，账单反而更低。

## 简要版本

每一篇告诉您模型*放不放得下*的指南，回答的都是关于单个请求的问题。而产品不是单个请求。一旦有两个人同时使用您的接口，机器就需要在显存里再放一份对话——然后是第三份，第四十份——而权重本身始终只存一份。

所以，真正决定您能服务多少人的，不是显卡的大小，而是显卡大小*减去*模型之后，再除以一段对话的成本。这两个数字在您下单之前就已经确定，这也让容量成为机器学习领域少数几件能靠纸笔算清楚、而且算得准的事情之一。

**权重是通行费。**入场时一次性支付，与流量无关；不会随用户增多而增长，也不会退还。

**KV 缓存就是租金。**按并发请求计费，请求保持打开状态期间持续计费，且与对话长度成正比。

**容量 = 剩余显存 ÷ 租金。**这就是为什么显存翻倍的机器，往往能多服务十倍的人，而不只是两倍。

**而恰好放得下模型的最便宜机器，通常是最不划算的选择。**它放得下，是因为几乎没有剩余显存——而那点剩余，才是您真正花钱买的部分。

以下内容运行的是与[配置器](https://gpuserver.io/zh/configure)相同的运算，基于同一份产品目录，精度 4-bit，上下文 8k。如果您还不熟悉这套显存计算方法，[它本身有一篇专门的指南](https://gpuserver.io/zh/guides/vram-sizing)——本页讲的，是当不止一个人同时使用时会发生什么。

## 权重之外，剩下多少显存

把本站的参考模型，放到用同一款显卡构建的每一种节点规格上。同样的芯片，同样的单卡价格，一切都相同——只有显存大小在变。请留意最后两栏，它们变化的速度截然不同。

**Llama 3.3 70B 在 4-bit、8k 上下文下的并发请求数，按同一款显卡构建的各节点规格列出**

| 节点 | 显存 | 权重之外的剩余显存 | 并发请求 | 每月 |
|---|---|---|---|---|
| [NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) | 24 GB | — | 放不下它 | $125 |
| [2 × NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) | 48 GB | 8 GB | 2 | $285 |
| [4 × NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) | 96 GB | 56 GB | 19 | $564 |
| [8 × NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) | 192 GB | 152 GB | 52 | $1,106 |
| [10 × NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) | 240 GB | 200 GB | 69 | $1,371 |

第一行就是全部道理：一张连权重都放不下的显卡，谁都服务不了，而且差得远不止一点。之后的每一行，显存都按相等的幅度增加，席位数却以加速的幅度增加，因为 40 GB 的通行费只在第一行支付一次，此后再也不用付。

**这道算术，一行就能写完。** `seats = (memory − weights) ÷ cache_per_request`。对 4-bit 精度下的 Llama 3.3 70B 而言，这是 40 GB 的通行费，加上每个打开的对话 2.9 GB 的租金。先减后除——顺序反过来，就是机器在演示阶段够用、上线后却掉链子的原因。

## 一个用户实际花费多少

现在把同样这些模型，按买家的方式排序：最便宜的排在最前面。最后一栏是月费除以机器能同时容纳的人数——当您要做的不只是一个演示时，这是唯一能诚实比较两台机器的一栏。

有一个前提要先说明，因为它会改变每一个数字：这里的每个席位数，都是针对铺满整个节点的*一个*模型实例而言的，也就是 `--tensor-parallel-size` 给您的效果。权重只存一份，每张显卡都把自己剩余的显存贡献给同一个对话池。如果改为在同一节点上运行两个独立副本，您就要两次支付通行费，换来的席位总数反而更少。

**能容纳 Llama 3.3 70B 的十个最便宜节点，及各自的每并发用户成本**

| 节点 | 显存 | 每月 | 并发请求 | 每用户 |
|---|---|---|---|---|
| [2 × NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) 2 张显卡 · 每张 24 GB | 48 GB | $285 | 2 | $142.50 |
| [NVIDIA RTX A6000](https://gpuserver.io/zh/gpu/rtx-a6000) 单卡 · 48 GB | 48 GB | $286 | 2 | $143.00 |
| [2 × NVIDIA RTX 4090](https://gpuserver.io/zh/gpu/rtx-4090) 2 张显卡 · 每张 24 GB | 48 GB | $416 | 2 | $208.00 |
| [4 × NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) 4 张显卡 · 每张 24 GB | 96 GB | $564 | 19 | $29.68 |
| [2 × NVIDIA RTX A6000](https://gpuserver.io/zh/gpu/rtx-a6000) 2 张显卡 · 每张 48 GB | 96 GB | $597 | 19 | $31.42 |
| [2 × NVIDIA RTX 5090](https://gpuserver.io/zh/gpu/rtx-5090) 2 张显卡 · 每张 32 GB | 64 GB | $692 | 8 | $86.50 |
| [NVIDIA L40S](https://gpuserver.io/zh/gpu/l40s) 单卡 · 48 GB | 48 GB | $714 | 2 | $357.00 |
| [2 × NVIDIA A100 PCIe](https://gpuserver.io/zh/gpu/a100-40gb) 2 张显卡 · 每张 40 GB | 80 GB | $802 | 13 | $61.69 |
| [4 × NVIDIA RTX 4090](https://gpuserver.io/zh/gpu/rtx-4090) 4 张显卡 · 每张 24 GB | 96 GB | $814 | 19 | $42.84 |
| [NVIDIA A100 PCIe](https://gpuserver.io/zh/gpu/a100-80gb) 单卡 · 80 GB | 80 GB | $1,091 | 13 | $83.92 |

对照价格栏，看这两个标了颜色的单元格。NVIDIA L40S 每月 $714，可容纳 2；4 × NVIDIA L4 只要 $564——*花得更少*——却能容纳 19。也就是说，只花 0.79× 的账单，换来 10× 的席位数，而大多数候选清单留下的，恰恰是那台更贵的机器，因为它是模型能放进单张显卡的那一台。

**这并不是在反对单卡机器。** 能放进单张显卡的模型，不需要拆分，不需要互联，也不需要张量并行参数，而且回应单个用户的速度，比把同一模型摊在四张显卡上更快。如果您的负载是一次一个请求——批处理任务、内部工具、演示——那台机器就是正确的选择，每用户一栏与您无关。这一栏只有在人们同时到达时才开始变得重要，而且从那一刻起，重要性会急剧上升。

把整个产品目录都算进来，而不只是前十行，这个模型每席位价格最低的方案是 [8 × NVIDIA RTX A6000](https://gpuserver.io/zh/gpu/rtx-a6000)，每月 $2,239：119 个并发请求，每个 $18.82。这张账单远比上面候选清单里的任何一台都大，但它仍然是让一个用户坐上席位最便宜的方式——而这句话，决定了您配置的是一款产品，还是一个原型。

## 上下文长度是另一个乘数

以上内容都假设上下文为 8k。这个假设起到的作用，比选哪台机器还要大。缓存既按 token 计费，也按用户计费，所以同一个节点能提供多少个席位，完全取决于您允许对话变得多长。

一台机器，四个模型，四种上下文长度。该节点是 [8 × NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4)，每月 $1,106——是我们产品目录中，能同时容纳全部四个模型的最便宜方案，因此下面的每一个数字，都是在同一份显存基础上测得的。

**单节点在 4-bit 下的并发请求数，按模型和上下文长度列出**

| 模型 | 每 token 缓存 | 4k | 8k | 32k | 128k |
|---|---|---|---|---|---|
| Llama 3.1 8B 4 GB 的权重 | 128 KiB | 325 | 162 | 40 | 10 |
| Qwen 3 32B 16 GB 的权重 | 256 KiB | 150 | 75 | 18 | 4 |
| Llama 3.3 70B 35 GB 的权重 | 320 KiB | 105 | 52 | 13 | 3 |
| Qwen 3 235B-A22B (MoE) 118 GB 的权重 | 188 KiB | 67 | 33 | 8 | 2 |

在同一台机器上，Llama 3.3 70B 能支持的并发用户数从 105 变为 3——相差 35× 倍——原因仅仅是命令行里设置的一个数字。硬件本身没有任何变化。

由此得出两点。第一，您该看的上下文栏，是您实际提供的长度，而不是模型卡片宣传的长度——一个*支持* 128k 的模型，并不要求您为它预留 128k。第二，每 token 的缓存开销在体量相近的模型之间差异悬殊，因为决定它的是注意力设计，而不是参数量；[表中体量最大的一些模型，缓存反而是最小的之一](https://gpuserver.io/zh/guides/mixture-of-experts)，这是这整个领域里最违反直觉的一个事实。

## 四种找回容量的办法

按投入产出比从高到低排列。第一种几乎免费，却也几乎总被忽略。

限制声明的上下文长度 免费，且收益最大 推理服务栈会按您声明的最大长度预留缓存，而不是按您实际使用的长度。声明 128k、实际只用 8k，就白白浪费了十六倍于所需的显存——而那部分显存，正是您全部的席位容量。从一开始就把 `--max-model-len` 设置为您真实的上限。

把缓存量化到 8-bit 席位数大致翻倍 把*权重*量化到 4-bit，对缓存没有任何影响：在所有常见技术栈中，缓存都会保持 16-bit，除非您主动要求改变。这只需要一个参数标志，在对话类负载上，质量代价通常察觉不到，下表就是它带来的收益。

把权重进一步量化 一次性收益，仅此而已 把权重减半，省下的显存直接交给缓存，因此能在一台拥挤的机器上买到更多席位。但这只是针对固定通行费的一次性收益，而且要付出质量代价——[哪种格式代价几何](https://gpuserver.io/zh/guides/awq-vs-gptq-vs-fp8)，是另一个需要单独决定的问题。

要租的是剩余显存，不是整张显卡 结构性的解决办法 以上每一种手段，起作用的都只是边际改善。换到一个显存远超您权重大小的节点，则会改变问题本身的形态，也是这四种办法里唯一一个会随着您的增长持续带来回报的。

**同一节点在 8k 上下文下，分别使用 16-bit 缓存与 8-bit 缓存时的并发请求数**

| 模型 | 16-bit 缓存 | 8-bit 缓存 | 席位增量 |
|---|---|---|---|
| Llama 3.1 8B | 162 | 325 | +163 |
| Qwen 3 32B | 75 | 150 | +75 |
| Llama 3.3 70B | 52 | 105 | +53 |
| Qwen 3 235B-A22B (MoE) | 33 | 67 | +34 |

同一个节点，同样的权重，同样的花费。唯一变化的是缓存存储的精度，而这一点，就是一台服务团队的机器和一台服务产品的机器之间的区别。

## 占有席位，不等于获得服务

在您用上面这些数字配置任何东西之前，有一点需要先纠正，也正是这一点让本页面保持诚实：这里统计的，是机器能让多少对话保持*打开*状态，并不保证所有对话都能被快速响应。

显存和带宽是两道不同的上限。在 [8 × NVIDIA L4](https://gpuserver.io/zh/gpu/nvidia-l4) 上，Llama 3.3 70B 能容纳 52 个并发对话，而单独一个用户在这台机器上，速度大约是每秒 17 个 token。坐满全部 52 个席位，并不代表每个人都能拿到每秒 17 个 token——生成过程共用同一份显存带宽，总吞吐量会随批处理增大而上升，每用户的速率则随之下降。带宽上限的到来，远早于显存上限。

**把席位数当作上限，而不是目标。** 一台坐满最后一个席位的机器，是一台所有人都在等待的机器。席位数告诉您哪些硬件甚至有能力承受您的并发量——它淘汰掉做不到的机器，而那通常是候选清单里的大多数——然后您再去衡量每用户实际想要的速率，并留出低于上限的余地。按上限配置，是买错机器的第二大常见原因，仅次于完全忽略缓存。

好消息是，这两道上限往往同步变化：权重之外剩余显存较多的机器，除少数例外，通常也是带宽更高的机器。按余量来选择，很少会牺牲速度。在您最终选定的机器上，[如何配置推理服务栈](https://gpuserver.io/zh/guides/serve-llama-70b)是另一篇指南要讲的内容，本文里的这些数字，最终要靠那些参数标志来兑现。

## 按您自己的用户数来选择

按顺序往下看，遇到第一条符合您负载情况的描述就停下来。

1. **一次只处理一个请求。**批处理任务、内部工具、单个开发者使用。买一台能把模型放进单张显卡的最便宜机器，然后就不必往下读了——这个页面上的每一栏，回答的都是您不需要的问题。
2. **偶尔有寥寥数人使用。**团队内部工具，或早期产品。要核算的是峰值并发请求数，而不是用户总数：注册用户有一百人，同时在线的往往只是其中寥寥几个。然后选择席位数明显高于该峰值、价格最低的机器。
3. **有真实流量的正式产品。**按每席位价格而非整机价格给产品目录排序，把上下文长度限制在实际提供的范围内，把缓存精度降到 8-bit，最终胜出的往往是一台您原本不会因月费而入围的机器。
4. **长文档，或长对话。**先看上下文表，再看机器表。到了 32k 及以上，缓存占据的比重如此之大，以至于选哪个模型，已经不如模型背后的注意力设计重要。
5. **流量忽高忽低，难以预测。**按绝不能掉链子的峰值来配置，因为缓存耗尽时无法临时借用——找不到地方安放对话的请求，只能在队列里等待。如果峰值罕见但极大，[用按 token 计费的 API 处理溢出部分](https://gpuserver.io/zh/guides/api-vs-self-hosting)，会比为一个月只出现两次的峰值去配置整台机器更便宜。

无论您停在哪一行，请先做这道减法，再做别的任何事：取机器的显存，减去您的模型在您将要使用的精度下的权重，看看还剩下什么。那部分剩余，才是您真正租用的产品。[配置器](https://gpuserver.io/zh/configure)会在我们运营的每一款节点上运行同样的运算，而[一个月要花多少钱](https://gpuserver.io/zh/guides/monthly-vs-hourly)，则是另外单独算清楚的事。

## 按用户配置机器，而不是按模型。

配置器收录了我们出租的每一款节点，运行与本页相同的显存运算，并在您付款之前，就告诉您加载模型之后还剩下多少。

[打开配置器](https://gpuserver.io/zh/configure) [阅读指南](https://gpuserver.io/zh/guides)

## 其他指南

- [成本 · 6 分钟 何时月付比按小时计费更划算 基于真实数字计算出的盈亏平衡点、按小时计价直到账单才会显现出的三项隐藏成本，以及让估算数字翻上三倍的闲置时间陷阱。 阅读指南](https://gpuserver.io/zh/guides/monthly-vs-hourly)
- [成本 · 9 分钟 自托管对比按 token 计费的 API 按 token 计费的 API 与租用 GPU 之间的盈亏平衡点，基于我们自己的价格与吞吐量计算得出——以及这套算法遗漏的四件事。 阅读指南](https://gpuserver.io/zh/guides/api-vs-self-hosting)
- [实践 · 11 分钟 在单个节点上部署 Llama 3.3 70B 从交付完成的服务器，到一个兼容 OpenAI 的推理端点：这中间有真正重要的启动参数，也有会悄悄把吞吐量拦腰砍半的那两个参数。 阅读指南](https://gpuserver.io/zh/guides/serve-llama-70b)

---

来源：https://gpuserver.io/zh/guides/concurrent-users/。本文件由与网站相同的数据生成；如果此处的数字与页面不一致，以页面为准，本文件视为过期——权威来源是 https://gpuserver.io/。