准备买机器或换模型时最容易卡在一句话：我这块卡到底能跑多大的模型。网上答案要么是别人的实测跑分，要么是厂商参数量口号，换到你自己的量化档位和使用场景就全不作数。这篇不给你绝对结论，只给一套可自己套用的判据：显存怎么算、量化档位怎么对应、多长的上下文和多高的并发会把余量吃掉，以及到站内哪个页面核当时的规格与租卡行情。
准备买机器或换模型时，最容易卡在一句话：我这块卡到底能跑多大的模型。网上答案要么是别人的实测跑分，要么是厂商的参数量口号，换到你的量化档位、你的上下文长度、你的并发量上，就全不作数。这篇不给你绝对结论，只给一套能自己套用的判据。
思路分四步：先算显存账，再选量化档位，然后按显存档位对号入座，最后把并发和上下文这两笔隐形开销算进去。具体型号的显存规格、当时的租卡行情和各家模型参数，都到站内对应页面核对，别照抄别人的配置单。
先算显存账，再谈显卡型号
很多人买卡的顺序错了：先看型号，再看能不能跑。正确顺序是先估显存需求，再去挑卡。显存占用不是只有权重那一块，权重、KV 缓存、推理框架的运行时开销要分开估，其中权重之外的余量往往是压死人的那部分。
- 权重占用
- 模型参数本身加载进显存的部分，随参数量和量化精度变化
- KV 缓存
- 处理上下文时保存的键值对，随上下文长度和并发数增长
- 运行时开销
- 推理框架、显存碎片、临时缓冲区占用的部分，容易被忽略
- 上下文长度直接决定 KV 缓存大小，想开长上下文就按长度留余量，不能只按参数量买卡
- 精度每降一档，权重体积大致按比例缩小，但质量损失不是线性的，低比特档位要按任务敏感度判断，不能一刀切
- 量化、张量分片、CPU offload 是三条不同的救急路，各自的阈值和代价见 /models/deploy 的测算入口
- 估算时留出的余量建议按「权重之外的占用至少留出权重的一半」这个粗口径起步，实际再按框架微调
量化档位怎么对应：质量、显存、速度三角
量化档位的本质是用一点质量换显存和速度。档位越低保得越多，但质量损失不是均匀分布的：有些任务掉一点就崩，有些任务掉很多也看不出来。所以选档位的正确姿势是拿自己的真实任务去对照，而不是看通用榜单上的排名。
| 任务类型 | 对量化的敏感度 | 建议倾向 |
|---|---|---|
| 代码生成、数学推理、结构化输出 | 高 | 优先保精度，显存不够就先缩模型规模 |
| 摘要、分类、批量改写 | 中 | 可用中低档位，先测一遍再定 |
| 客服问答、知识检索 | 中低 | 低档位通常够用，重点看召回质量 |
| 创意写作、长文润色 | 取决于个人偏好 | 建议自己比两版，别人说好不算 |
同一档位在不同推理框架下，显存和速度差别明显，选框架前先确认它支不支持你要用的量化格式。有时换个框架比换个档位更划算。档位取舍的完整逻辑另见量化档位相关文章，这里只讲它和显存选型的对应关系。
显存档位对照表：从入门卡到多卡
下面这张表不写死数字，按容量分段，你拿自己手上的卡对号入座即可。每一档标注典型用途和不适用的情况。真正的显存规格以站内加速卡规格库为准，别用电商页的模糊描述。
| 显存分段 | 可承载的量化档位 | 适合的模型规模 | 典型用途 |
|---|---|---|---|
| 入门档（小容量） | 中低档位 | 小参数模型 | 单机试验、个人试玩 |
| 主流档 | 中档位 | 中等参数模型 | 个人日常、轻量写作 |
| 进阶档 | 中高档位 | 中大参数模型 | 小团队内部服务 |
| 高容量档 | 高精度档位 | 大参数模型 | 对外服务、质量敏感任务 |
| 多卡组合 | 按分片策略走 | 超大模型 | 需要评估通信开销和机位 |
- 表里的「典型用途」是参考，不是承诺，实际表现取决于框架、上下文和并发
- 需要长上下文、需要高并发、需要微调，这三类都要在对照表结果上再往上留一档
- 多卡不是简单叠加，张量并行的通信开销可能吃掉一部分收益，选之前想清楚值不值
- 具体型号的显存规格到 /rankings 核对，别用非官方渠道的参数
并发和上下文：最容易被低估的两笔开销
单用户能跑，不等于能对外服务。并发数上去以后，显存和吞吐同时吃紧，卡数怎么估见并发测算相关文章，这里只讲排查顺序。
- 第一步：确认是不是显存不足看报错信息和显存占用曲线，是加载就失败，还是跑一会儿才崩
- 第二步：确认是不是上下文过长把输入截短再试一遍，如果稳定了就说明是 KV 缓存吃掉的，给会话长度设上限
- 第三步：确认是不是并发打满单请求跑通、多请求排队或超时，就是并发问题，要么限流要么加卡
- 第四步：最后才怀疑模型本身前面三步都排除后再考虑换模型或调档位，别一上来就换
长上下文是隐形成本：一次塞几万字和一次几百字，显存占用不是一个量级。
量化档位调低后再压不住的，别硬扛。这时候要回到「租卡还是继续调 API」的分界线判断，而不是继续降精度，因为质量掉到影响业务时，省下的显存没有意义。
买卡、租卡还是继续调 API：三条路的判断点
先明确三件事：数据能不能出内网、负载是稳定还是波峰、有没有人愿意长期维护机器。这三件事的答案基本就决定了你该走哪条路，剩下的只是算账。
- 数据合规要求：必须不出内网，才把自建放进候选
- 峰值并发：波峰很高但平时闲置，租卡通常更划算
- 闲置成本：算总账时把电费、机位、折旧都放进去，别只比卡价和 API 单价
- 运维人力：没人管机器的话，自建就是长期负债
自建与调用的分界线、租卡与按量调用的分界线，两篇文章里已经算过账，这里不重复。给一个简化判据：上面四项里超过两项命中，才考虑自购；只命中一项，优先租或调 API。当时的租卡行情和各家价格到 /price-watch 核对。
下一步先按显存档位表把自己的卡对上号，再去站内核对规格和当时的行情，最后决定买、租还是继续调 API。→常见问题
显存不够，是降量化还是换小模型？
先降量化。量化一般只损失一部分质量，换小模型等于换掉了能力上限，很多任务会直接从「能做」掉到「做不了」。降量化后如果质量明显不行，再考虑换模型或上多卡。另外别忽略上下文和并发这两项，先把它们压下来往往比降量化更划算。
只想本地跑着玩、不对外服务，需要按并发算吗？
不需要，单人使用按单条会话的显存占用估就行，把上下文长度留够余量即可。但要注意「跑着玩」和「拿它当主力」是两回事：一旦你开始拿它批量处理文件或接进编辑器，负载性质就变了，最好在买卡前就把这个场景想清楚。
网上别人说能跑，我买同样的卡为什么跑不动？
大概率差在这几处：量化格式不同、推理框架不同、上下文长度不同、有没有开显存卸载。别人的实测往往只报模型能不能加载，不报能不能在你要的长度下稳定输出。建议拿自己的真实任务在目标配置上试，或者先租一台同规格的机器验证再下单。
