4090 能跑多大参数的模型：按参数量和量化方式算清你的上限

很多人手里有一张 4090，想本地跑开源模型，第一句就是「能跑多大的」。答案不是一个数，而是取决于参数量、量化档位、上下文长度和并发数这四件事怎么搭。这篇给你一套能自己算的粗估方法，先把上限框出来，再看什么情况下这套估算不成立。

很多人手里有一张 4090，想本地跑开源模型，第一句就是「能跑多大的」。这个问题用一句话回答不了，因为同一张卡，量化档位、上下文长度、并发数怎么搭，能装的参数量能差出好几个台阶。这篇给你一套能自己动手算的粗估方法，先把上限框出来，再看什么情况下这套估算会失效。

先说清一点：下面讲的是「能装进显存」和「大致能跑得动」的估算，不是保证你能跑到某个吞吐。实际帧率、首字延迟受框架、驱动、算子实现影响很大，结论要以你在自己机器上测出来的数字为准。站内的价格与参数资料只作参考，具体数字到对应的站内页面核对。

为什么没有「能跑多大」的标准答案

因为决定上限的不是显卡型号一个变量。同一张卡，量化档位从高往低换，能装的参数量直接翻倍；上下文从短拉到长，KV 缓存又会吃掉一大块；再叠上并发，原本跑得动的模型可能就起不来了。所以正确的心智模型是：给定预算，看你怎么分配。

• 要分开看两件事：「装得下」看显存占用，「跑得动」还得看吞吐和首字延迟，前者是硬门槛，后者是体验线
• 显存占用主要由三块构成：权重、KV 缓存、框架自身开销，只算权重一定会低估，长上下文场景尤其明显
• 先量出自己机器上的空闲显存基线，再往上套算式，比直接抄别人晒的结论靠谱得多
• 别人的结论往往只对应他那套上下文和并发配置，换个用法就不成立，所以估算要带条件

显存花在哪：权重、KV 缓存、框架开销

把这三块拆开算，是整套方法的核心。权重是最大的一块，量化的意义就是把它压小；KV 缓存随上下文长度和并发线性增长，长对话里它经常是压垮显存的最后一根稻草；框架本身还有固定开销和临时缓冲预留，所以真实可用显存小于标称值。

权重占用

由参数量和量化位宽共同决定，位宽越低省得越多，代价通常是输出质量下降

KV 缓存

随上下文长度和同时在跑的请求数增长，长上下文加多并发时可能反超权重

框架开销

推理框架的固定占用加临时缓冲，实际可用显存要在这个基础上再打折

手算顺序：从参数量倒推显存

标准顺序是正向算：先按量化档位估权重，再按计划支持的上下文和并发估 KV 缓存，最后加框架开销。如果反过来，你有固定的显存预算，就先扣掉后两块，剩下的额度留给权重，再倒推能上多大的参数量。两种算法得到的是同一件事的两面。

1. 估权重确定目标模型的参数量和打算用的量化档位，按位宽比例估权重占用；不同档位的位宽与占用换算，到站内 硬件名词（/ai-dict/category/hardware） 核对当时的说明
2. 估 KV 缓存用你实际要支持的上下文长度和并发数来估，不要拿模型支持的最大值当默认值
3. 加框架开销跑一次空载或最小请求，看框架本身占了多少，再额外留一段安全余量
4. 回测校准把估算值和实际加载后的占用对比一次，差额记下来，下次估算就有自己的系数了

如果嫌手算麻烦，站内的 部署测算（/models/deploy） 页面有现成的对照口径可以套，但记得它给的也是估算区间，最终仍以你机器上的实测为准。

什么情况下这套估算不适用

这套方法默认模型完整驻留显存、接近单卡独跑。一旦引入下面这些手段，估算的边界就变了——不是算错，而是前提不成立了。

• 张量分片、CPU offload、显存换页：会把「装不下」变成「能跑但慢」，体验和估算完全不是一回事
• 上下文远超预期或同时多路请求：KV 缓存可能反超权重，此时上限由并发数而不是参数量决定
• 框架做了权重共享或量化缓存优化：占用可能比手算低，别拿保守估算当硬结论
• 已经频繁触发换页：判断标准是延迟抖动，而不是启动时有没有报错，抖动明显就说明越界了

落到行动：四步确认自己的上限

概念讲完不如自己跑一遍。下面四步是给个人用户设计的验证流程，做完你会得到一张属于自己的对照表，下次换模型直接套，不用再满世界问「能不能跑」。

1. 记录空载基线开机后先跑一次空载或最小请求，记下框架稳定占用，作为后续预算的底数
2. 算一遍再对比按目标模型和量化档位算出权重加缓存的总和，和基线数字对比，看还剩多少空间
3. 从小档位往上试从保守档位开始，每上一档记录首字延迟和持续吞吐，别只看能不能加载成功
4. 沉淀成对照表把可用档位和对应的质量感受记下来，换模型时先查表再动手，省掉重复试错

能加载不等于能好用，判断上限的最后一关是延迟稳不稳，而不是显存占用有没有爆。