打算自己租卡或买卡跑推理时，最容易卡在「A100 看起来更快，A6000 看起来更便宜」这一步。这篇不讲参数表，只给一套能套用到任意两张卡上的比较顺序：先量模型要多少显存，再算这张卡能同时接几个请求，最后把租金或整机成本折成每千次调用的钱。照着走一遍，你会知道自己该选数据中心卡还是专业卡，以及什么情况下这个结论不成立。
打算自己租卡或买卡跑推理时，最容易卡在「A100 看起来更快，A6000 看起来更便宜」这一步。这两张卡的定位确实不在一个赛道上，但跑推理到底选谁，跟它们各自的绝对性能关系不大，跟你手里的模型、并发和业务形态关系很大。
下面不讲参数表，只给一套能套用到任意两张卡上的比较顺序：先量模型要多少显存，再算这张卡能同时接几个请求，最后把租金或整机成本折成每千次调用的钱。照着走一遍，你会知道自己该选数据中心卡还是专业卡，以及什么情况下这个结论不成立。具体规格口径到 /compute/gpus 核对当时的数字。
先分清两类卡的差别到底在哪
数据中心卡与专业卡的差异，核心不在「谁快谁慢」，而在几个结构性维度：显存容量与带宽、是否支持高速卡间互联、功耗与散热形态、驱动与虚拟化支持。这四项决定了你能跑什么模型、能跑多并发、能不能多卡拼成一张。把它们混成一句「A100 更强」来做决策，通常会选错。
| 维度 | 影响什么 | 什么时候成为硬门槛 |
|---|---|---|
| 显存容量 | 单卡能装多大模型、能开多长上下文 | 模型权重加 KV 缓存装不下时，无论多快都用不了 |
| 显存带宽与算力 | 单位时间能出多少 token、能接多少并发 | 高并发或长上下文场景下决定吞吐上限 |
| 卡间互联 | 多卡能否当一张卡做张量并行 | 需要跨卡拆分大模型或做并行推理时是关键 |
| 功耗与形态 | 机箱、供电、散热、噪音是否适配 | 自建机房或办公环境部署时直接影响可行性 |
一个实用顺序是：先到 /compute/gpus 对照规格口径，再到 /models/deploy 把你要跑的模型换算成显存需求。单机单卡、小并发、量化后的中小模型，专业卡常常够用；一旦模型装不下或要求多卡张量并行，数据中心卡就是硬门槛，不是性价比问题。
第一步永远是算显存，不是比价格
显存需求可以拆成三块：权重占用、KV 缓存、框架与激活开销。权重随量化档位变化很大，同一模型换一档量化，可能从装不下变成绰绰有余；KV 缓存则随并发数和上下文长度线性上涨，这是最容易被低估的部分。
- 权重占用：由模型规模和量化档位决定，换档位比换卡见效快
- KV 缓存：峰值并发乘以单请求上下文长度，长上下文加高并发最容易把卡撑爆
- 框架与激活开销：推理框架、编译缓存、临时张量都会吃掉一部分显存，别按理论下限卡边
- 余量：显存刚好卡在临界值时，留出余量比省一半租金重要，具体余量口径见 /compute/sizing
判断标准很简单：把「峰值并发 × 单请求上下文」算进去再选卡。相关名词口径可以到 /ai-dict/category/hardware 对照，避免各家用词不一致导致算错。
第二步把这卡折成每次调用的钱
显存达标之后，再谈钱才有意义。这里要算三笔账：卡时租金或整机折旧、实际吞吐（每秒能出多少 token）、利用率（一天里有多少时间真有请求）。三笔乘除下来，才能得到可比较的单位成本，而不是拿月租直接比。
| 账目 | 怎么估 | 容易踩的坑 |
|---|---|---|
| 卡时成本 | 租金或整机价除以可用卡时 | 只算电费不算机位、运维和折旧 |
| 实际吞吐 | 用你的真实输入输出长度压测 | 拿官方跑分当自己的吞吐 |
| 利用率 | 按业务波峰波谷估真实占用比例 | 默认 7×24 满载，实际远低于此 |
| 单位成本 | 折成每千次同类请求多少钱 | 不同卡用不同口径横向比 |
低利用率是自部署最贵的隐藏项：卡闲着照样计费，小团队先按真实业务波峰波谷估利用率，别按理想值算。把结果统一折成「每千次同类请求多少钱」后，再和按量调 API 的当期价比一遍，参考 /compute/tco 与 /compute/price-index 的数字。如果算出来差距不大，优先选按量调用而不是买卡。
什么情况下这套比较不成立
这套方法默认「成本是首要变量」。只要前提变了，结论就得推翻，下面几种情况要单独判断。
- 数据不能出内网、必须私有化部署时，成本不是首要变量，先满足合规再看性价比，参考 /compute/platforms
- 要做微调或训练而不是纯推理时，显存带宽和互联权重要往上提，专业卡的性价比结论不适用，见 /compute/finetune
- 业务是断续的、每次只有几条请求时，任何自持卡方案都比按量调用贵，别硬凑
- 卡源紧张、租金波动大时，先看当期实际可租到的型号，别按理想价做预算，见 /compute/availability
还有一类容易被忽略的情况：模型会持续升级。如果半年后你大概率要换更大的模型，那现在的选型就要按「下一代模型装不装得下」来留余量，而不是按当前模型刚好够用。这种情况下宁可显存上探一档，也别卡死在临界值。
下单前的五步决策清单
- 算显存下限列出模型、量化档位、最大上下文和峰值并发，算出显存下限，再到 /compute/gpus 筛出达标的卡型。
- 比单卡吞吐在同样量化档位和上下文长度下压测候选卡，比每秒出 token 数，别用官方跑分代替。
- 估利用率折成本按真实波峰波谷估利用率，把卡时成本折成每千次请求成本，口径参考 /compute/tco。
- 和按量调用对一遍拿折算结果对比按量调 API 的当期价，差距在一倍以内优先不自建，数字到 /price-watch 看。
- 留扩容余地确认能不能加卡、能不能降级到更小模型，把每条结论写在一张纸上，避免被单张跑分图带偏。
选卡的顺序是先问装不装得下，再问接得住几个，最后才问值不值。
跑分口径不统一是选型最大的干扰源，同一个模型在不同框架、不同量化下的数字能差出好几档。看别人的对比时，先确认它用的上下文长度、并发数和量化档位，再决定要不要采信，也可以到 /benchmarks 与 /benchmarks/registry 核对口径。
下一步把候选卡型的当期租金、吞吐口径和可用性放在一起对，比自己逐条查快得多。→常见问题
预算有限，是不是直接买便宜的专业卡就行？
不一定。专业卡在单卡、小并发、量化模型上确实划算；但显存装不下模型、或者需要多卡并行时，便宜的那张卡会直接出局，省下的钱换来的是改模型、降上下文、限并发，这些隐性成本常比差价高。先把显存和并发算出来再谈便宜。
数据中心卡贵这么多，多出来的钱花在哪？
主要花在更大的显存与带宽、卡间高速互联、以及更完整的驱动与虚拟化支持上。如果你的场景用不到多卡并行、不需要超大显存、也不打算切分给多人用，这部分能力就是闲置的，可以按当期租金和吞吐去 /compute/price-index 核对实际差价再说。
我该按租卡还是按量调 API 来比？
看利用率。请求稳定、一天大部分时间都有负载时，租卡摊下来的单次成本才有可能低于按量调用；请求零星、有明显波峰波谷时，按量调用更划算。先记录两周真实用量再决定，别用峰值用量去估全年，具体口径见 /compute/tco。
