打算自己租卡或买卡跑模型时，最容易卡住的一步是：到底要几张卡才够。销售说的「一张卡能带几十路并发」通常不带上下文长度和量化档位的条件。这篇给一条能自己动手算的路径：权重显存怎么估、KV 缓存怎么随上下文和批大小涨、运行时还要留多少余量，最后从并发数反推卡数，并说清哪些情况下这套算法不适用。
打算自己租卡或买卡跑模型时，最容易卡住的一步不是选哪个框架，而是：到底要几张卡才够。销售嘴里那句「一张卡能带几十路并发」，通常不带上下文长度、不带量化档位、不带延迟要求，所以没法直接照搬。
这篇给一条能自己动手算的路径：权重显存怎么估、KV 缓存怎么随上下文和批大小涨、运行时还要留多少余量，最后从并发数反推卡数。算出来的数字只当规划用，真实值要靠实测校准；涉及规格与当期的数字，一律到站内页面核对。
为什么必须先估算，不能先买卡
因为卡数不是一个独立问题，它是三个输入变量的输出：模型规模加量化档位、单请求上下文长度、目标并发与延迟。这三个不定下来，卡数就没有唯一答案，谁给你的数字都是在替你假设。
- 先写清三个输入：模型规模与量化档位、平均与峰值上下文长度、目标并发和可接受延迟
- 把「能跑起来」和「能跑到目标并发」分开看，前者只看权重能否放下，后者才决定卡数
- 先做一次粗算，再拿实测去修正，比直接问别人要一个卡数靠谱
- 如果只是个人低频试用或夜间批处理，延迟要求宽松，可以直接按最小可跑配置起步，不必做完整测算
第一步：权重显存怎么估
最粗的算法是参数量乘每参数字节数。常见精度下每参数占用字节数不同，量化档位越低占用越小，但精度损失得用自己的任务验证，别只听别人说「几乎无损」。这一步只解决「放不放得下」，不解决并发。
- 每参数字节数
- 精度与量化档位决定，档位越低占得越少，代价是效果可能变差
- 嵌入层与输出层
- 这两块常被单独对待，是否量化会明显影响总占用，别默认它们跟着一起压
- 多卡切分副本
- 张量并行时权重会被切开，但通信缓冲和部分副本会带来额外占用
建议自己做一张对照表：左边写模型规格，右边写各量化档位的理论占用，再乘以一个安全系数。模型规格与可用档位到 /models 与 /compute/gpus 核对当时的数字。
这里有个容易踩的坑：MoE 类模型的激活参数和总参数不是一回事，按总参数算会明显高估。反过来，如果你的服务会同时加载多个模型做路由，那就得叠加，不能只算最大的那个。这条算法对超长上下文模型也不完全适用，因为那时瓶颈已经不在权重。
第二步：KV 缓存才是并发的大头
KV 缓存随「层数 × 头数维度 × 序列长度 × 批大小」线性增长。上下文翻倍，占用基本翻倍，这是长上下文服务最容易被低估的一项。很多人算完权重觉得一张卡能扛，一上并发就爆显存，问题都出在这里。
- 先算 KV 再算并发，顺序别反，因为并发上去后 KV 往往超过权重本身
- 区分预填充阶段和逐 token 生成阶段的占用差异，两者峰值不在同一个时刻
- 确认是否开启分页式管理来减少碎片，碎片会让实际可用显存低于账面
- 短请求且随用随释放的场景，用平均长度估更贴合，但要按峰值留安全余量
| 变量 | 变大时的影响 | 怎么处理 |
|---|---|---|
| 上下文长度 | KV 占用近似线性上升 | 按峰值长度规划，别用平均值 |
| 并发批大小 | KV 占用近似线性上升 | 分档测，找拐点 |
| 层数与头维度 | 由模型结构定死 | 换模型前先重算 |
| 请求长短混合 | 碎片变多，有效显存下降 | 按峰值批留余量 |
判断标准很简单：把「权重 + KV(平均) + 余量」压在显存七成以内，剩下三成留给峰值和碎片。如果平均长度下就已经到八成，那这套配置做长上下文服务基本没戏，要么加卡，要么限制上下文。
第三步：运行时开销与碎片要留多少
框架自身、CUDA 上下文、通信库、临时激活值都会占显存。实测经验是权重加 KV 之外再留一段固定余量，具体数值因框架和卡型而异，别照抄别人的比例，自己测一次就有数。
- 跑单请求基线只发一个请求，记录稳定后的显存占用，这是你的地板
- 逐步加并发每次加一路，记录占用，观察曲线何时开始非线性上升
- 记录拐点非线性上升的那一点就是实际可用的并发上限，比理论值可信
- 复测长上下文把上下文拉到峰值长度再跑一遍，看拐点是否前移
不适用情形：多卡张量并行时通信缓冲与单卡不同，不能直接拿单卡数字乘卡数。另外混合精度、激活重计算这些开关也会改变占用曲线，换配置就要重测。
第四步：从显存反推单卡并发数
可用显存等于总显存减权重减运行时余量。单请求占用等于权重分摊加它那条上下文的 KV。两者相除得到理论上限，再根据调度效率、长短请求混跑、突发排队打个折扣。折扣打多少没有标准答案，取决于你的流量形状。
| 上下文档位 | 高精度档位 | 中档量化 | 低档量化 |
|---|---|---|---|
| 短上下文 | 按实测填 | 按实测填 | 按实测填 |
| 中等上下文 | 按实测填 | 按实测填 | 按实测填 |
| 长上下文 | 按实测填 | 按实测填 | 按实测填 |
| 超长上下文 | 基本不适用 | 按实测填 | 按实测填 |
把这张表填满，你就有了一张能拿去和同事、和供应商对话的底稿。格子里的数字不要抄网上的，自己跑一遍最靠谱。租卡规格与价格可到 /compute/gpu-rental 和 /models/deploy 对照当期的数字。
不适用情形：如果你的业务有明显波峰，用平均并发算出来的卡数会在高峰期直接排队超时。这种情况要么按峰值配，要么上排队和限流，把口子收住。
第五步：吞吐与卡数的换算
吞吐看的是每秒生成多少 token，受批大小、卡间通信、是否连续批处理影响。它和并发数不是同一个量：并发高不等于吞吐高，卡顿的时候往往并发上去了、每秒 token 反而下来了。
- 测单卡延迟基线记录首 token 时间和每 token 时间，测速方法见 /tools/speed-test
- 换算目标吞吐用目标 QPS 乘以平均输出长度，得到需要的每秒 token 数
- 反推卡数用单卡吞吐去除目标吞吐，向上取整，再按延迟要求留冗余
- 验证延迟最后一定要在目标并发下复测延迟，别只看吞吐数字
卡数不是越少越好，也不是越多越好，找的是满足延迟前提下的最小卡数。
判断标准：如果加卡之后延迟没有明显改善，说明瓶颈不在算力，可能在调度、网络或存储，这时候继续买卡是浪费。不适用情形：有明显波峰波谷的业务，按峰值配卡会长期闲置，更该考虑弹性租用或排队削峰。
量化档位怎么选：先看能不能接受，再看省不省
顺序别搞反：先用自己能接受的最高精度跑通，再往下压档位，每压一档都要在同一批真实任务上比对效果。上来就压到最低档，后面出的问题很难定位是模型还是量化导致的。
- 看结构化输出是否还稳定，尤其是需要严格格式的接口
- 看长上下文下是否掉点，长文任务对量化更敏感
- 看工具调用这类需要精确判断的场景是否变差
- 把省下的显存换算成多出的并发或少买的卡，再决定值不值
不适用情形：涉及金额、医疗、法务等对错误容忍度低的任务，不建议为了省卡硬压到低精度档位。省下的钱可能不够赔一次错误输出。
一张可执行的排查清单
- 定场景：写清模型、量化档位、平均与峰值上下文、目标并发、可接受延迟
- 算三段：权重显存、KV 缓存峰值、运行时余量与碎片
- 实测校：单请求基线 → 加并发观察曲线 → 找拐点 → 反推卡数
- 留后手：准备一档降量化的备用方案、一个排队或限流策略，以及监控显存与排队时长的指标
- 定期复核：模型、上下文习惯和流量都会变，隔一段时间重跑一次测算
复核的时候顺手看一眼站内的价格与规格变化：相关规格与价格到 /compute 与 /price-watch 看当期数据。同样是满足需求，成本和可选项可能已经不一样了。
下一步拿你的真实模型、真实上下文和真实并发填一遍上面的表格，再到站内对照当期规格和价格，就能把卡数范围收窄到一两档。→常见问题
为什么我按权重算明明放得下，一上并发就爆显存？
因为权重只是一部分，KV 缓存和运行时余量才是并发时增长最快的。上下文越长、并发越高，KV 缓存可能超过权重本身。先按峰值上下文算 KV，再留固定余量给框架和碎片，剩下的才是真正能用的并发空间。
上下文长度翻倍，显存会正好翻倍吗？
KV 缓存部分接近线性增长，但权重和运行时余量不变，所以总占用不会严格翻倍，会略低于翻倍。真正要小心的是：长上下文请求和短请求混跑时按峰值算，容易高估平均也容易低估瞬时峰值，规划要按峰值留余量。
量化到更低档位一定更划算吗？
不一定。低档位省显存、能提并发，但如果你的任务对结构化输出、长文稳定性或工具调用敏感，效果下滑带来的返工成本可能超过省下的卡钱。做法是在同一批真实任务上对比后再决定，而不是只看显存数字。
单卡并发数和总吞吐是一回事吗？
不是。并发数是同时在处理的请求数量，吞吐是单位时间产出的 token 数。有时并发上去了，但因为调度和通信开销，单请求变慢、总吞吐反而没涨。先把延迟基线测出来，再找满足延迟前提下的最小卡数。
这套算法什么时候不适用？
几种情况：MoE 模型按总参数算会明显高估；多卡并行时通信缓冲不能按单卡线性外推；流量有明显波峰波谷时按峰值配卡会长期闲置。这些场景更适合实测加弹性租用，而不是纯手算。
