一台 GPU 实际能服务多少人。
能放下您模型的机器，不等于能服务您用户的机器。权重是一次性支付的通行费；付清之后剩下的，才是您用来服务用户的全部预算。真正决定容量的，是那部分剩余显存，而不是显卡本身的大小，而且它变化的速度远快于显存本身。
简短的答案
- 容量取决于剩余显存，而非整张显卡
- Llama 3.3 70B在 4-bit 下，在服务任何人之前就要预留 40 GB。此后每多一个并发请求，都再多花 2.9 GB。
- 这就是为什么显存要付两次钱
- 在同一款显卡上，从 48 GB 升到 240 GB，显存变为 5.0× 倍，席位数却变为 35× 倍。因为权重的钱已经付过了。
- 候选清单里最不划算的一台
- NVIDIA L40S 每月 $714，可容纳 2 个并发请求 — 每席位 $357.00。
- 最优的那一台，价格反而更低
- 4 × NVIDIA L4 只要 $564，即可容纳 19 — 每席位 $29.68，账单反而更低。
简要版本
每一篇告诉您模型放不放得下的指南，回答的都是关于单个请求的问题。而产品不是单个请求。一旦有两个人同时使用您的接口，机器就需要在显存里再放一份对话——然后是第三份，第四十份——而权重本身始终只存一份。
所以，真正决定您能服务多少人的，不是显卡的大小，而是显卡大小减去模型之后，再除以一段对话的成本。这两个数字在您下单之前就已经确定，这也让容量成为机器学习领域少数几件能靠纸笔算清楚、而且算得准的事情之一。
权重是通行费。入场时一次性支付，与流量无关；不会随用户增多而增长，也不会退还。
KV 缓存就是租金。按并发请求计费，请求保持打开状态期间持续计费，且与对话长度成正比。
容量 = 剩余显存 ÷ 租金。这就是为什么显存翻倍的机器，往往能多服务十倍的人，而不只是两倍。
而恰好放得下模型的最便宜机器，通常是最不划算的选择。它放得下，是因为几乎没有剩余显存——而那点剩余，才是您真正花钱买的部分。
以下内容运行的是与配置器相同的运算，基于同一份产品目录，精度 4-bit，上下文 8k。如果您还不熟悉这套显存计算方法，它本身有一篇专门的指南——本页讲的，是当不止一个人同时使用时会发生什么。
权重之外，剩下多少显存
把本站的参考模型，放到用同一款显卡构建的每一种节点规格上。同样的芯片，同样的单卡价格，一切都相同——只有显存大小在变。请留意最后两栏，它们变化的速度截然不同。
| 节点 | 显存 | 权重之外的剩余显存 | 并发请求 | 每月 |
|---|---|---|---|---|
| NVIDIA L4 | 24 GB | — | 放不下它 | $125 |
| 2 × NVIDIA L4 | 48 GB | 8 GB | 2 | $285 |
| 4 × NVIDIA L4 | 96 GB | 56 GB | 19 | $564 |
| 8 × NVIDIA L4 | 192 GB | 152 GB | 52 | $1,106 |
| 10 × 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 给您的效果。权重只存一份，每张显卡都把自己剩余的显存贡献给同一个对话池。如果改为在同一节点上运行两个独立副本，您就要两次支付通行费，换来的席位总数反而更少。
| 节点 | 显存 | 每月 | 并发请求 | 每用户 |
|---|---|---|---|---|
| 2 × NVIDIA L4 | 48 GB | $285 | 2 | $142.50 |
| NVIDIA RTX A6000 | 48 GB | $286 | 2 | $143.00 |
| 2 × NVIDIA RTX 4090 | 48 GB | $416 | 2 | $208.00 |
| 4 × NVIDIA L4 | 96 GB | $564 | 19 | $29.68 |
| 2 × NVIDIA RTX A6000 | 96 GB | $597 | 19 | $31.42 |
| 2 × NVIDIA RTX 5090 | 64 GB | $692 | 8 | $86.50 |
| NVIDIA L40S | 48 GB | $714 | 2 | $357.00 |
| 2 × NVIDIA A100 PCIe | 80 GB | $802 | 13 | $61.69 |
| 4 × NVIDIA RTX 4090 | 96 GB | $814 | 19 | $42.84 |
| NVIDIA A100 PCIe | 80 GB | $1,091 | 13 | $83.92 |
对照价格栏，看这两个标了颜色的单元格。NVIDIA L40S 每月 $714，可容纳 2；4 × NVIDIA L4 只要 $564——花得更少——却能容纳 19。也就是说，只花 0.79× 的账单，换来 10× 的席位数，而大多数候选清单留下的，恰恰是那台更贵的机器，因为它是模型能放进单张显卡的那一台。
把整个产品目录都算进来，而不只是前十行，这个模型每席位价格最低的方案是 8 × NVIDIA RTX A6000，每月 $2,239：119 个并发请求，每个 $18.82。这张账单远比上面候选清单里的任何一台都大，但它仍然是让一个用户坐上席位最便宜的方式——而这句话，决定了您配置的是一款产品，还是一个原型。
上下文长度是另一个乘数
以上内容都假设上下文为 8k。这个假设起到的作用，比选哪台机器还要大。缓存既按 token 计费，也按用户计费，所以同一个节点能提供多少个席位，完全取决于您允许对话变得多长。
一台机器，四个模型，四种上下文长度。该节点是 8 × NVIDIA L4，每月 $1,106——是我们产品目录中，能同时容纳全部四个模型的最便宜方案，因此下面的每一个数字，都是在同一份显存基础上测得的。
| 模型 | 每 token 缓存 | 4k | 8k | 32k | 128k |
|---|---|---|---|---|---|
| Llama 3.1 8B | 128 KiB | 325 | 162 | 40 | 10 |
| Qwen 3 32B | 256 KiB | 150 | 75 | 18 | 4 |
| Llama 3.3 70B | 320 KiB | 105 | 52 | 13 | 3 |
| Qwen 3 235B-A22B (MoE) | 188 KiB | 67 | 33 | 8 | 2 |
在同一台机器上，Llama 3.3 70B 能支持的并发用户数从 105 变为 3——相差 35× 倍——原因仅仅是命令行里设置的一个数字。硬件本身没有任何变化。
由此得出两点。第一，您该看的上下文栏，是您实际提供的长度，而不是模型卡片宣传的长度——一个支持 128k 的模型，并不要求您为它预留 128k。第二，每 token 的缓存开销在体量相近的模型之间差异悬殊，因为决定它的是注意力设计，而不是参数量；表中体量最大的一些模型，缓存反而是最小的之一，这是这整个领域里最违反直觉的一个事实。
四种找回容量的办法
按投入产出比从高到低排列。第一种几乎免费，却也几乎总被忽略。
--max-model-len 设置为您真实的上限。| 模型 | 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 上，Llama 3.3 70B 能容纳 52 个并发对话，而单独一个用户在这台机器上，速度大约是每秒 17 个 token。坐满全部 52 个席位，并不代表每个人都能拿到每秒 17 个 token——生成过程共用同一份显存带宽，总吞吐量会随批处理增大而上升，每用户的速率则随之下降。带宽上限的到来，远早于显存上限。
好消息是，这两道上限往往同步变化：权重之外剩余显存较多的机器，除少数例外，通常也是带宽更高的机器。按余量来选择，很少会牺牲速度。在您最终选定的机器上，如何配置推理服务栈是另一篇指南要讲的内容，本文里的这些数字，最终要靠那些参数标志来兑现。
按您自己的用户数来选择
按顺序往下看，遇到第一条符合您负载情况的描述就停下来。
- 一次只处理一个请求。批处理任务、内部工具、单个开发者使用。买一台能把模型放进单张显卡的最便宜机器，然后就不必往下读了——这个页面上的每一栏，回答的都是您不需要的问题。
- 偶尔有寥寥数人使用。团队内部工具，或早期产品。要核算的是峰值并发请求数，而不是用户总数：注册用户有一百人，同时在线的往往只是其中寥寥几个。然后选择席位数明显高于该峰值、价格最低的机器。
- 有真实流量的正式产品。按每席位价格而非整机价格给产品目录排序，把上下文长度限制在实际提供的范围内，把缓存精度降到 8-bit，最终胜出的往往是一台您原本不会因月费而入围的机器。
- 长文档，或长对话。先看上下文表，再看机器表。到了 32k 及以上，缓存占据的比重如此之大，以至于选哪个模型，已经不如模型背后的注意力设计重要。
- 流量忽高忽低，难以预测。按绝不能掉链子的峰值来配置，因为缓存耗尽时无法临时借用——找不到地方安放对话的请求，只能在队列里等待。如果峰值罕见但极大，用按 token 计费的 API 处理溢出部分，会比为一个月只出现两次的峰值去配置整台机器更便宜。
无论您停在哪一行，请先做这道减法，再做别的任何事：取机器的显存，减去您的模型在您将要使用的精度下的权重，看看还剩下什么。那部分剩余，才是您真正租用的产品。配置器会在我们运营的每一款节点上运行同样的运算，而一个月要花多少钱，则是另外单独算清楚的事。