选显卡的群里最常见的劝法就一句：「显存够就能跑」。这句话在 DeepSeek 部署讨论里流传极广，也坑了无数新手——卡买回来，模型确实加载进去了，然后第一批长文档一来，服务直接卡死。错在哪？这句话把「能加载」当成了「能服务」，把静态容量当成了动态表现。正确说法是：显存够只是第一道门票，跑得好还要过后面好几关。
错在哪：把门槛当成全部
加载一个模型，显存里先躺下的是权重，这部分确实能按参数量估算。但推理是动态过程：每来一个请求，都要额外开辟空间存放上下文、缓存中间结果。权重占的是「住房」，请求占的是「客人」，房子买了不代表接得下客人。只核对权重和显存的数字，等于只看了建筑面积没看能住几口人。
显存之外还有几道关
第一关是算力：显存装得下，算得慢照样没法用，几十秒等一个回复没人受得了。第二关是带宽：权重再小，读不快就喂不饱计算单元。第三关是并发：多人同时请求时，空间和算力要分着用，单个请求能跑不等于一百个请求能跑。第四关是软件栈：驱动、推理框架、量化格式哪一环不匹配，都会让「理论上能跑」落空。显存算错的连锁反应还不止于此，恢复环境的容量跟着错，容灾时照样卡住，参考容灾演练和预案文档。
一个典型翻车现场
某团队拿一张24G的卡部署开源模型，权重占用十四G，表面剩十G很宽裕。单发请求测试一切正常，上线后第三天客服高峰，二十个人同时提问，服务无响应。复盘发现：并发请求的上下文缓存把剩余显存吃光，系统开始用内存硬扛，速度掉到原来的百分之一以下。这不是显存不够，是没给并发留余量。事后靠监控才定位到瓶颈，指标采集的思路见自建监控和托管监控。
正确说法分三步
第一步，算静态账：权重大小加上框架固定开销。第二步，算动态账：目标并发数乘以单请求的上下文占用，这部分往往比权重还大，估算方法见参数量除以二就是显存的误区。第三步，留安全余量：按动态峰值再留两到三成空闲，防止碎片化和突发流量。三步都过，才能说这张卡「能跑」。
三笔账各管什么，列出来更不容易漏项。
| 账目 | 算什么 | 怎么估 | 漏算的后果 |
|---|---|---|---|
| 静态账 | 权重大小加上框架固定开销 | 权重按参数量估算 | 把「能加载」当成「能服务」，只看建筑面积不看能住几口人 |
| 动态账 | 目标并发数乘单请求的上下文占用 | 按真实高峰并发估，这部分往往比权重还大 | 二十人同时提问，上下文缓存吃光剩余显存，服务无响应 |
| 余量 | 动态峰值之外的空闲 | 再留两到三成 | 碎片化和突发流量没有缓冲 |
动手前的核对清单
- 权重占用是否算上了量化格式的开销；
- 并发数是按真实高峰估的，还是拍脑袋；
- 上下文长度上限定了多少，超长请求怎么办；
- 留了多少空闲显存应对碎片和突发；
- 算力和带宽能不能匹配延迟要求。
如果为了省显存做了压缩，精度会不会打折也要验证，量化相关的前提见量化部署零损失的误区；想靠多张卡摊压力的话，先看多卡一定比单卡快的误区，别把并行想得太简单。
自查清单
- 静态账：权重加框架开销，逐项列出
- 动态账：并发数乘单请求占用，按高峰估
- 余量：峰值之外再留两到三成
- 验证：按真实文档长度做一轮并发测试
划重点：显存是住房，请求是客人，看房先问能住几口人。
关于「显存够就能跑」，问得最多的三个
- 显存差一点点能不能硬跑？：差一点会触发内存交换，速度断崖式下跌，宁可换小一号的模型或做量化，也别让系统频繁腾挪。
- 为什么官方说能跑、我这里跑不动？：官方标的是最低加载门槛，通常按短上下文单请求测，和你真实业务的并发与文档长度不是一回事。
- 怎么快速验证这张卡行不行？：从 ModelScope 拉模型后，用接近生产的长文档按目标并发压一轮，观察延迟和显存峰值，比任何估算都可信。
显存够只是及格线，跑得稳才是交卷。下单前把静态账、动态账、余量三笔算清，能避开九成翻车。
