很多人攒了一台带消费级显卡的机器，想本地跑个模型试试，结果要么下完权重发现加载就报显存不足，要么勉强跑起来慢到没法用。问题通常不在卡本身，而在你选的模型规模、量化档位和实际要干的活对不上。这篇不给你打包票说哪张卡行不行，而是给一套自己算、自己试、自己判够不够用的方法：先看显存天花板，再看量化和速度的取舍，最后按任务类型决定是本地跑还是换条路。
很多人攒了一台带消费级显卡的机器，想本地跑个模型试试，结果要么下完权重发现加载就报显存不足，要么勉强跑起来慢到没法用。问题通常不在卡本身，而在你选的模型规模、量化档位和实际要干的活对不上。所以先别急着问「够不够」，先把这三个变量摆到桌面上，一个一个对齐。
这篇不给你打包票说哪张卡行不行，而是给一套自己算、自己试、自己判的方法。顺序是：先看显存天花板，再看量化和速度怎么取舍，最后按任务类型决定本地跑还是换条路。每一步都强调本机实测，因为别人的结论套到你的机器上经常不成立。
先算显存天花板，别急着下权重
第一件事不是下模型，是搞清楚你这张卡真正能给模型用多少显存。显卡标称的显存总量不等于可用量，系统和桌面环境会先占走一部分，扣多少因操作系统和桌面环境而异，自己开机后实测一遍最准，别照搬别人的数。
| 要算的部分 | 包含什么 | 怎么确认 |
|---|---|---|
| 系统常驻占用 | 系统、驱动、桌面环境先吃掉的那块 | 开机静置后看显存占用，记下差值 |
| 模型权重 | 参数规模乘以量化后的每个参数占用 | 按目标量化和参数规模粗算，再到站内页面核算 |
| KV 缓存 | 随上下文长度和并发数增长 | 用真实输入长度压测，观察占用变化 |
| 运行时开销 | 推理框架自身的内存占用 | 换框架前后各测一次，对比差距 |
判断顺序是：先看显卡显存总量，再扣掉系统和驱动的常驻占用，剩下的才是模型能用的部分。模型吃显存的大头是权重、KV 缓存和运行时开销三块，参数规模只是其中一项。具体某张卡对应多少参数、什么量化档，可以到 /models/deploy 按你的卡和模型跑一遍测算，不要凭感觉估。
量化是消费级显卡的命门，但要认代价
同样的卡，换低一档量化往往就能从跑不动变成跑得动，代价是输出质量和稳定性会变。这个取舍没有统一答案，需要你自己拿真实任务比对，而不是听别人说某档「几乎无损」就信。
- 准备对照任务从你实际要做的活里挑三到五条，覆盖最长和最难的那几条，别只拿一句短提示测试。
- 固定提示词跑不同量化档同一提示词在各量化档各跑一遍，把输出存下来并排看，重点看是否还能直接用。
- 分开看质量与速度质量类任务对量化更敏感，格式抽取、分类这类任务通常更耐受；速度用同一输入长度对比出字快慢。
- 定一个底线什么程度的输出你能接受、慢到什么速度你会放弃，提前写下来，避免测完还在纠结。
- 速度要一起看：量化通常能降显存占用并提升生成速度，但不同推理框架的优化程度差别很大，想横向比较可以按 vllm-vs-ollama-selection 的思路自己搭对比环境
- 不适用的情况：如果你只是偶尔试玩、不追求稳定产出，那不必纠结量化损失，跑得起来就行
- 别忽略框架版本：同一个量化档在不同框架、不同版本下表现可能差很多，换框架后要重新测一遍
按任务类型判断：够用还是别硬扛
显存和量化都算完之后，真正的分水岭是任务类型。同样的硬件，跑单轮问答够用，跑长上下文加高并发就完全不够，这不是调参能补上的差距。
| 任务类型 | 本地跑是否合适 | 判断依据 |
|---|---|---|
| 单轮问答、文本摘要 | 通常合适 | 对延迟不敏感，能接受慢慢出结果 |
| 代码补全、格式转换 | 多数合适 | 输入输出都不长，速度可接受即可 |
| 长上下文多轮对话 | 偏勉强 | KV 缓存随长度涨，容易顶到显存上限 |
| 高并发或多工具调用 | 不合适 | 并发数和响应稳定性都撑不住 |
自测顺序是：先用小规模输入跑通，再逐步加压到你的真实输入长度和并发数，观察显存是否溢出、速度是否掉到不可接受。不要只测一句短提示就下结论，那几乎必然给你过于乐观的答案。
决策分界线在于：如果压测下来速度或稳定性不达标，与其继续在本地硬调，不如评估租卡或按量调 API。两条路的成本和适用场景不一样，具体对比思路见 /guides/self-host。
准备买卡或升级前，先过一遍核对清单
准备花钱之前，把下面这套口径固定下来，之后每次看中一张卡都按同一套算，而不是只比显存数字大小。卡的代际、显存带宽和驱动支持同样影响体验，概念对照可以查 /ai-dict/category/hardware。
- 目标模型的参数规模和你要用的量化档
- 真实输入长度，不是演示用的短提示
- 同时几个人用，也就是并发数
- 你能容忍的最慢出字速度
- 显存之外还要留多少余量给系统和别的程序
- 预算内是买卡还是按量调用，两条路各算一遍
价格和型号随时在变，不要按网上的旧结论下单。实际规格与租用对照到 /compute/gpus 看当时的数字，租金行情到 /compute/price-index 核对，别把几个月前的印象当现状。
下一步想知道自己的卡和框架实际能跑出什么速度，用站内速度测试跑一遍最直接，测完再决定本地跑、租卡还是调 API。→常见问题
显存够就一定跑得动吗？
不一定。显存只是第一道门槛，过了之后还要看生成速度和输入长度上限。上下文越长，运行时占用的缓存越大，可能出现短提示能跑、长文本就崩的情况。所以判够不够用，必须用你真实的最长输入去压测一遍，而不是拿一句短话试通就算数。
同样的卡，为什么别人说能跑我说跑不动？
常见差异来自三处：量化档位不同、推理框架不同、以及系统本身占用的显存不同。对方可能用的是更低精度或更省显存的框架，也可能后台没跑别的程序。想排除干扰，先对齐这三项再比较，别直接照搬别人的结论。
普通开发者的钱该花在显卡还是别的地方？
看你的使用频率和任务性质。高频、单机、对数据不出本地有要求的，值得考虑本地卡；偶发使用、需要长上下文或并发的，租卡或按量调用往往更划算。判断依据和隐藏成本，参考 self-host 里那套分界线，再结合当前租卡行情算一遍。
