很多人下完 glm-4.7-flash 权重，卡在「我这卡到底能不能跑」这一步：网上说法从几张卡到一张消费卡都有，差的全是量化档位、上下文长度和并发数。这篇按可复现的估算路径走一遍，给出从参数量推显存的算法、各量化档的取舍，以及显存不够时的降级顺序；具体数字请到站内部署测算页按当时的模型规格核对。
很多人下完 glm-4.7-flash 的权重，第一件事就是问「我这卡到底能不能跑」。网上答案从好几张卡到一张消费卡都有，看着像玄学，其实差的全是量化档位、上下文长度和并发数这几项没说清楚。同一个模型，别人按短上下文单并发跑通了，你按长上下文多路并发去对，结论当然对不上。
这篇不给你一个孤立数字，而是给一条能自己算的路径：从参数量推权重显存，加上 KV Cache 和运行时开销，再按量化档位做取舍；显存不够时按成本从低到高降级。具体参数量、层数配置和当时可用的卡型规格，请到站内模型库和算力页面按当期条目核对。
先搞清楚为什么别人说的数字对不上
显存占用不是「权重占多少」这么一件事。它至少由四块拼起来：权重、KV Cache、激活与运行时开销、框架预留。只算权重是最常见的误判来源，很多「我算下来够用」最后跑不起来，就是漏了后三块，尤其是长上下文场景下的 KV Cache。
- 权重
- 模型参数本身占的显存，量化档位直接决定这一块的大小
- KV Cache
- 缓存注意力键值，随上下文长度和并发数增长，量化权重并不等比缩小它
- 激活与运行时开销
- 前向计算过程中的中间张量，跟框架实现和批大小有关
- 框架预留
- CUDA 上下文、显存碎片和预分配吃掉的部分，通常别把预算卡在临界点
- 同一份权重，上下文从几 K 拉到几十 K、并发从 1 提到 8，KV Cache 可能翻好几倍，结论自然不同
- 量化档位不同，权重体积差别很大，但 KV Cache 往往还是按较高的精度算
- 推理框架不同（vLLM、llama.cpp 一类），预分配策略和实测值也不一样
- 是否开 CPU offload 会显著改变「能跑」的判断，但代价是速度
按参数量推显存的三步算法
下面这套算法不依赖具体数字，你拿到模型规格后可以自己代进去。模型参数量、层数、注意力头维度这些规格，到 站内模型库 /models 看当期条目，别用记忆里的旧数据。
- 算权重下限参数量乘以每参数字节数，得到纯权重占用。比如高精度档位每参数占用明显高于低比特档位。算完再乘一个 1.1 上下的缓冲系数，别按理论值卡死。
- 算 KV Cache与层数、注意力头维度、上下文长度、并发数成正比。先把计划用的最大上下文和峰值并发定下来，再乘出来；这两项只要翻倍，KV Cache 就跟着翻。
- 留运行时余量把 CUDA 上下文、显存碎片、框架预分配估进去，通常还要再留一块。三步相加得到估算值，再和显卡可用显存比对。
| 占用项 | 随什么变化 | 容易漏掉的地方 |
|---|---|---|
| 权重 | 参数量、量化档位 | 只算权重就下结论 |
| KV Cache | 上下文长度、并发数 | 以为量化权重能等比缩小它 |
| 运行时开销 | 批大小、框架实现 | 短输入测试通过不代表长输入也行 |
| 框架预留 | 预分配策略、显存碎片 | 预算卡在临界点，跑一会儿就 OOM |
量化档位怎么选：先保能跑，再谈质量
量化不是越低越好，也不是越高越保险，得看任务类型。高精度档位适合短上下文、单并发、对输出质量敏感的场景，代价是显存需求更大；中间档位是多数本地部署的默认解，显存节省明显，常见问答和摘要类任务体感差异不大。
- 短上下文加单并发、追求稳定输出：优先高精度档位
- 通用问答、摘要、轻量客服：中间档位通常够用，显存压力小
- 长链推理、代码生成、结构化输出：不建议压到最低档，容易不稳
- 只是想先跑通流程做验证：可以用低比特档位，但要准备好回退方案
低比特档位适合显存紧张或者只想先跑通流程的场景，但涉及长链推理、代码生成、结构化输出时更容易出现不稳，这类任务别为了省显存硬压。选档位前先明确任务类型和可接受的回退方案，别一上来就追最省显存那档。具体不同档位在各类任务上的表现，到站内评测栏目按当期结果核对。
显存不够时的降级顺序
显存不够时，别第一反应就是换卡或上多卡。按成本从低到高排，先动最容易改的项，改完用同一组输入复测，确认是真的解决了问题而不是碰巧跑通。
- 先降上下文和并发这两项对 KV Cache 的影响最直接，改动成本也最低。把最大长度和并发上限调低，重跑同一组长输入，看是否还 OOM。
- 再换更激进的量化档位换档后准备好一组固定测试集，复核效果是否退化。别只看能不能跑，还要看输出质量能不能接受。
- 然后才是多卡分摊张量并行或多卡涉及通信开销和框架配置，排障成本明显上升，前面两步都试过再考虑。
- 最后才用 CPU offload它能救急，但会拖慢生成速度，适合验证阶段，不适合长期顶着用。
下单买卡或租卡前的核对清单
买卡或租卡之前，先把三项锁死：量化格式、计划使用的上下文长度、峰值并发。缺一项估算就不成立，拿着残缺的假设去比卡型规格，很容易买错档位。
| 核对项 | 为什么必须锁定 | 去哪里看 |
|---|---|---|
| 量化格式 | 直接决定权重占用 | 站内模型库 /models 当期条目 |
| 上下文与并发 | 决定 KV Cache 大小 | 自己的业务峰值，别按平均值估 |
| 加速卡规格 | 显存容量和带宽都要匹配 | 站内算力页面 /compute/gpus 逐项比 |
- 把估算值留出余量后再对照加速卡规格，别按理论下限选卡
- 短期验证优先按量租卡，确认可行再决定买卡，避免买错卡位
- 框架侧的最大长度、并发上限、显存利用率要手动设上限，默认值可能直接吃满
- 拿一组真实业务输入做压力测试，比拿一句话试跑靠谱得多
要提醒的是，这条路径不适用于已经确定要用超长上下文加高并发、且不接受任何质量回退的场景，那种情况得直接按多卡预算规划。反过来，只是自己本地试玩、短对话用，按最低档位加小显存卡通常也能先跑起来。具体规格和当时的可选卡型，到站内算力页面核对当期数字。
下一步想知道自己手里的卡到底能跑到什么程度，可以拿站内的换算工具先粗算一遍，再决定是调参数还是换卡。→常见问题
一张消费级显卡能跑 glm-4.7-flash 吗？
要看三件事凑不凑得上：量化档位压到多低、上下文开多长、并发是不是保持单路。三项都往保守方向走，小显存卡有机会跑通；只要追求长上下文或同时服务多人，显存需求会明显上去。先按估算流程算一遍，再拿 /compute/gpus 的规格对照，别按别人的单点结论下判断。
量化到低比特会影响回答质量吗？
影响程度跟任务类型强相关。普通问答、摘要、改写这类任务，低比特档位通常感觉不出明显差别；长链推理、代码生成、严格 JSON 输出这类对细节敏感的任务，掉档更容易暴露。稳妥做法是同一条提示词分别跑高、低档位，自己比一遍再定，别只看别人给的结论。
估算出来的值和实测差很多怎么办？
先确认框架有没有预分配显存、并发上限有没有被设死、上下文是不是按最大长度预留了，这三点最容易让实测高于估算。再看是不是开了 CPU offload，它会让部分权重不落在显存里，数字反而变小但速度下降。逐项排掉之后，剩下的差值通常来自显存碎片和运行时开销。
