聊低显存模型排行这件事，我得先说明白一个前提。市面上很多所谓“排行榜”看着热闹，实际拿到自己机器上一跑，发现根本跑不起来，或者跑起来慢得没法用。问题出在“低显存”这三个字太模糊了。你说8GB显存能跑，他说8GB显存跑不动，两边都没说谎，只是各自说的不是同一件事。我写这一章的目的，就是把边界划清楚，让后面的排行有据可依，而不是拍脑袋排座次。
我自己折腾本地部署这几年，踩过的坑够写一本小册子。最开始我也迷信参数和榜单，后来发现显存这东西是个动态变量，跟你的量化方式、上下文长度、批大小、甚至驱动版本都有关系。所以这一章我会从适用边界、评测维度、显存构成、数据来源四个角度拆开讲，尽量把话说透。
1.1 低显存模型排行的适用边界：显存容量、量化版本与可运行性定义
先说显存容量。我习惯把“低显存”分成三档来看：4GB到6GB算入门档，8GB算主流档，10GB到12GB算进阶档。为什么这么分？因为消费级显卡和核显的实际可用显存就在这几个区间聚集。RTX 3060 12GB、RTX 4060 8GB、还有一堆8GB的笔记本独显，这是大多数人手里的真实硬件。你拿一张24GB的卡来谈“低显存排行”，对普通用户没什么参考价值。
量化版本是第二个必须说清楚的东西。同一个模型，FP16版本和Q4_K_M版本，显存占用能差出两倍多。我见过有人拿Q4量化的7B模型说“7B在8GB上很轻松”，也见过有人拿FP16的7B说“8GB根本不够”。两种说法各自成立，但混在一起比较就是耍流氓。所以我在排行里会明确标注量化格式，GGUF的Q4_K_M、Q5_K_M、Q8_0，AWQ的4bit，GPTQ的4bit，这些是不同的起跑线。
可运行性这个词也得界定。我的标准是：模型能加载、能完成一轮完整对话、不出现显存溢出崩溃、首字延迟在可接受范围内。光是“能加载”不算数，我试过不少模型加载成功但一生成就OOM，这种在排行里我会直接标红。另外可运行性还跟上下文长度挂钩，4K上下文能跑和32K上下文能跑，完全是两个难度级别。
1.2 排行评测维度设计：生成质量、推理速度、上下文长度、部署难度与稳定性
评测维度这块我想了很久，最后定了五个：生成质量、推理速度、上下文长度、部署难度、稳定性。生成质量是最主观的，我一般用固定的一组中文问答、代码题和摘要任务来打分，尽量让不同模型面对同样的题。中文能力我会额外看成语理解、多轮指代和口语化表达，有些模型英文很溜，中文一开口就露馅。
推理速度我关注两个数：首字延迟和生成吞吐。首字延迟决定你等多久能看到第一个字，吞吐决定长回答要等多久。这两个指标在低显存设备上经常打架，有的模型首字快但吐字慢，有的反过来。我实测下来，7B模型在8GB显存上Q4量化，首字延迟能压到一秒以内算优秀，吞吐能到每秒20个token以上算流畅。
部署难度和稳定性是容易被榜单忽略的维度。有的模型在llama.cpp里跑得飞起，换到Ollama就各种报错；有的模型短对话稳如老狗，一到长上下文就胡言乱语或者直接崩。我会记录每个模型在至少两个推理框架下的表现，以及连续跑二十轮对话有没有出现显存泄漏。稳定性差的模型，质量再高我也不建议放进日常使用清单。
1.3 显存占用构成拆解：模型权重、KV Cache、运行时开销与框架差异
显存占用不是一块铁板，我习惯拆成四块来看。第一块是模型权重，这是大头，参数量乘以量化位宽再除以八，大致能估出来。7B模型Q4量化大概3.5GB到4GB，Q8量化翻倍到7GB左右。这块相对固定，只要量化格式定了，权重占用就定了。
第二块是KV Cache，这块最容易被低估。上下文越长，KV Cache越大，而且它跟批大小成正比。我见过有人用4K上下文测出来8GB够用，换成32K上下文直接爆显存。KV Cache的估算跟模型层数、隐藏维度、注意力头数都有关系，粗略算法是每token每层占几个KB，乘起来就是总额。长文档场景下，KV Cache能占到总显存的三四成。
第三块是运行时开销，CUDA上下文、框架自身的缓冲区、临时张量，这些零零碎碎加起来通常有几百MB到1GB多。第四块是框架差异，llama.cpp的显存管理比较抠门，vLLM为了高吞吐会预分配大块显存，Transformers则相对随性。同一个模型同一个量化，换框架显存占用能差出1GB以上，这在排行里必须注明测试框架。
1.4 排行数据来源与测试条件说明：硬件平台、量化格式、批大小与上下文设置
数据来源这块我得坦白，我的排行数据主要来自自己的实测，加上一部分社区复现记录。硬件平台固定在几张卡上：RTX 3060 12GB、RTX 4060 8GB、还有一台核显笔记本做对照。驱动版本和CUDA版本我会记录在案，因为这些也会影响显存占用和推理速度。我不太信任只给结论不给条件的榜单，所以自己写排行会把测试条件摆出来。
量化格式我会优先选社区最常用的那几个：GGUF的Q4_K_M和Q5_K_M，AWQ的4bit，GPTQ的4bit。批大小默认设为1，因为低显存场景下很少有人开大batch。上下文设置分三档测试：2K短对话、8K中等长度、16K长文档。每档我都会记录峰值显存和是否溢出，溢出的模型直接不进主榜。
最后说可复现性。我会把每个模型的加载命令、量化文件来源、测试用的提示词模板都写清楚，方便你自己复现。有些模型在不同版本的llama.cpp上表现差异很大，我会标注测试时的commit号或者版本号。排行这东西，条件说清楚了，结论才有意义。你要是拿我的数据去对比别人在不同条件下跑出来的结果，那大概率会对不上，这不是谁错了，是条件不一样。
8GB显存这个档位挺特殊的。我自己手里那张RTX 4060 8GB跑了大半年，最大的感受是：能跑的模型不少，跑得舒服的不多。你可能见过一些榜单把十几二十个模型排得整整齐齐，我实测下来的结论是，8GB这个卡点上真正值得日常拿来用的，一只手数得过来。这一章我按场景拆成几个小榜，每个榜都基于我自己跑出来的体感，条件在上一章交代过了，Q4_K_M量化为主，上下文默认4K，框架以llama.cpp和Ollama为主。
2.1 8GB显存可运行的大模型排行：通用对话与中文能力榜单
通用对话这块，我排第一的是Qwen2.5-7B-Instruct的Q4_K_M版本。这模型中文语感在我试过的7B级别里是断层领先的，成语用得自然，多轮对话指代也稳。显存占用实测加载后大概4.8GB，留出KV Cache和运行时开销，8GB卡上跑4K上下文很从容。我连续跟它聊了三十多轮，没出现显存爬升或者胡言乱语的情况。唯一让我有点不爽的是它的默认系统提示词风格偏正经，想要轻松点的语气得自己调。
第二梯队我给Yi-1.5-6B和GLM-4-9B的Q4量化版。Yi的中文短句能力不错，回答干脆不啰嗦，显存占用比Qwen略低一点。GLM-4-9B参数大一圈，Q4量化后权重占到5.5GB左右，4K上下文下峰值显存逼近7GB，跑是能跑，余量不多。我拿它测长一点的回答时翻过一次车，生成到一半OOM了，后来把上下文压到2K才稳。所以GLM这个模型我归到“能用但得小心”那一类。
Baichuan2-7B和InternLM2-7B我也试了，中文能力中规中矩，没有明显短板也没有让人记住的亮点。Baichuan2的多轮对话偶尔会丢上下文，InternLM2的回答风格偏保守。这两个模型我的建议是：如果你手头已经有量化文件，拿来用没问题；要专门去下，优先级排在Qwen和Yi后面。
小参数这边我单独提一下Qwen2.5-3B-Instruct。这模型显存占用只有2GB出头，8GB卡上跑32K上下文都绰绰有余。中文能力放在3B级别里算是超预期，日常问答、简单摘要够用。缺点是复杂推理容易绕进去，你问它一个需要三步逻辑的问题，它经常在第二步就偏了。我拿它当“快速响应助手”用，复杂任务还是切回7B。
2.2 8GB显存可运行的大模型排行：代码生成与轻量知识库场景榜单
代码场景我第一个推DeepSeek-Coder-V2-Lite-Instruct，16B MoE架构但激活参数少，Q4量化后显存占用大概5.2GB。这模型补全Python和JavaScript的准确率在我测过的8GB能跑的模型里排第一，函数签名和常见库调用很少出错。我拿它写过一个Flask小项目，基本没怎么改就能跑。缺点是对冷门库的支持一般，你让它写Rust的某个小众crate，它容易编API。
CodeQwen1.5-7B是另一个我常用的。它的优势是补全速度快，首字延迟能压到0.6秒左右，写代码时那种“边打边出建议”的体验比较顺。质量上比DeepSeek-Coder稍弱一点，复杂逻辑题偶尔会写出能跑但很啰嗦的代码。我一般拿它做行内补全，整段生成还是切DeepSeek。
轻量知识库场景我重点试过RAG流程。8GB显存跑embedding模型加生成模型，资源要算着花。我的组合是bge-small-zh做向量化（显存占用不到500MB），生成用Qwen2.5-7B的Q4版本。整套跑起来峰值显存7.2GB左右，检索加生成一轮大概3秒。这个组合我拿一份两百页的产品手册测过，问答准确率能到八成以上，回答里引用的段落基本对得上。
有个坑我得提醒一下。知识库场景很多人喜欢上长上下文模型，觉得上下文越长越好。我实测下来8GB卡上32K上下文跑7B模型，KV Cache能多吃掉2GB多显存，加上权重和运行时开销直接顶到天花板。我的做法是上下文控制在8K以内，靠检索把相关段落喂进去，比硬拉长上下文稳得多。
2.3 不同参数量与量化组合的可运行性排行：7B、8B、9B及小参数模型
参数量和量化的组合我做了个矩阵测试，结论比想象中清晰。7B模型配Q4_K_M是8GB卡上的甜点区，权重3.8GB左右，加上4K上下文的KV Cache和运行时开销，峰值显存在5.5GB到6GB之间，余量健康。7B配Q5_K_M权重涨到4.5GB，峰值逼近7GB，还能跑但长上下文要收着点。7B配Q8_0权重7GB出头，4K上下文下勉强能加载，生成稍微长一点就危险，我不推荐日常用。
8B模型这个档位有点尴尬。我试了Llama-3.1-8B-Instruct的Q4版本，权重4.3GB，4K上下文峰值6.5GB左右，能跑。中文能力比Qwen2.5-7B差一截，英文对话倒是很顺。我的判断是：纯英文场景可以选它，中文为主还是回到7B。9B模型像GLM-4-9B和Gemma-2-9B，Q4量化权重5GB上下，4K上下文峰值7GB出头，属于“能加载能跑但别折腾”的区间。我拿Gemma-2-9B跑过一次8K上下文的摘要任务，直接OOM了，压回4K才成功。
小参数模型我分两档看。3B到4B这档，Qwen2.5-3B和Phi-3.5-mini表现最好，显存占用2GB到3GB，8GB卡上随便跑，还能开大一点的batch。1.5B及以下这档，我主要拿来做分类、抽取、改写这类窄任务，通用对话能力明显不够看。Qwen2.5-1.5B做文本分类的准确率意外地好，我拿它跑过一个工单打标的活儿，比规则匹配强不少。
量化格式这块我再啰嗦一句。同样的7B模型，AWQ 4bit和GGUF Q4_K_M的显存占用差不多，但AWQ在vLLM上的吞吐明显高。问题在于8GB卡跑vLLM本身就有压力，vLLM的预分配策略会多吃显存。我实测AWQ加vLLM在8GB上跑7B模型，4K上下文经常触发OOM，换llama.cpp加GGUF就稳了。所以8GB这个档位，我的量化推荐排序是GGUF Q4_K_M优先，AWQ其次，GPTQ再次。
2.4 8GB显存部署体验排行：加载速度、首字延迟、吞吐与内存溢出风险
加载速度这个维度被很多榜单忽略了，实际用起来很影响心情。我测下来GGUF格式的7B Q4模型从点击加载到可以对话，llama.cpp大概8到12秒，Ollama因为多了层封装会慢个三四秒。AWQ格式在vLLM上加载反而快，5秒左右，但前面说了vLLM在8GB上容易OOM，快也没用。我日常用Ollama就是因为省心，加载慢点能接受，别崩就行。
首字延迟和吞吐我放在一起说。Qwen2.5-7B在llama.cpp上4K上下文，首字延迟0.8秒左右，吞吐每秒22个token上下，这是我8GB卡上的体验基准线。DeepSeek-Coder-V2-Lite首字稍慢，1.1秒左右，吞吐反而高一些，能到每秒26个token。GLM-4-9B首字延迟要1.5秒以上，吞吐掉到每秒15个token，长回答等起来有点磨人。小参数模型里Qwen2.5-3B首字能压到0.4秒，吞吐每秒35个token，响应快得明显。
内存溢出风险我单独列了个红榜。GLM-4-9B在8K上下文下我遇到过两次OOM，一次是生成到一半崩的，一次是加载KV Cache时直接失败。Llama-3.1-8B在6K上下文边缘试探时也崩过一次。Qwen2.5-7B和Yi-1.5-6B我连续跑了一周日常使用，没碰到溢出。DeepSeek-Coder-V2-Lite在长代码补全时偶尔吃紧，把上下文从8K压到4K就没事了。我的建议是：8GB卡上别贪上下文长度，4K是安全线，6K要看模型，8K以上只建议小参数模型尝试。
最后说个我自己的使用习惯。我在8GB卡上同时只加载一个模型，切换场景时手动换。有人喜欢用Ollama的keep_alive让模型常驻，省加载时间，代价是显存一直被占着。我试过一段时间，发现后台常驻一个7B模型后，开浏览器看视频都开始卡了。后来改成用完就卸，虽然每次多等十秒，但整机体验顺很多。这个取舍看你自己的使用频率，没有标准答案。
显存占用这件事，我吃过亏才搞明白。刚开始玩本地部署的时候，我以为显存占用就是模型文件大小，下载个4GB的GGUF扔进8GB卡里，心想还剩4GB够用了吧。结果一加载直接爆了。后来一点点拆开看，才知道显存这玩意儿跟洋葱似的，一层一层剥开全是账。这一章我就按我自己踩过的坑，把显存占用拆开对比给你看。
3.1 低显存大模型显存占用对比：FP16、GGUF、AWQ与GPTQ量化差异
我拿同一个模型Qwen2.5-7B做了四组对比，显存占用的差距让我重新认识了量化这回事。FP16版本最实在也最粗暴，权重就要14GB出头，8GB卡连想都别想，我是在朋友的24GB卡上跑的基准。GGUF Q4_K_M的权重压到4.2GB左右，加载后加上运行时开销，4K上下文下峰值显存在5.5GB上下。这个数字跟我预期差不多。
AWQ 4bit和GPTQ 4bit的权重文件大小跟GGUF Q4_K_M接近，4GB到4.5GB这个区间晃。但我实测下来发现一个有意思的现象：AWQ在vLLM上加载时，框架会预分配一大块显存池，8GB卡上经常还没开始推理就OOM了。GPTQ的情况类似，但没AWQ那么激进。我后来在llama.cpp上跑AWQ转换的模型，显存占用反而跟GGUF差不多，差别主要出在推理框架的显存管理策略上，不是量化格式本身。
这里有个反直觉的点我得说清楚。很多人以为量化位数越低显存越省，Q4一定比Q5省。权重层面确实如此，但实际运行时的显存峰值不只是权重。Q4量化的模型推理时反量化操作会产生额外的临时张量，不同框架处理这些临时张量的方式不一样，有时候Q4的峰值显存跟Q5差不了多少。我拿Qwen2.5-7B的Q4_K_M和Q5_K_M在llama.cpp上做了对比，4K上下文下峰值分别是5.4GB和6.1GB，差距700MB左右，比权重差值略小一点。
速度方面我顺手做了个记录。同样Qwen2.5-7B，GGUF Q4_K_M在llama.cpp上吞吐每秒22个token，AWQ 4bit在vLLM上跑出了每秒31个token的成绩。vLLM的PagedAttention确实快，前提是显存够用。8GB卡上我试了三次AWQ加vLLM跑7B，只有一次在2K上下文下没崩，其余两次都在加载阶段就挂了。我的结论是：8GB这个档位，GGUF是唯一让我不操心的选择，AWQ和GPTQ留给12GB以上的卡去发挥。
3.2 上下文长度对显存占用的影响对比：短对话、长文档与多轮会话
上下文长度对显存的影响比我最初估计的大得多。KV Cache不是线性增长那么简单，不同模型的注意力头数和隐藏维度决定了每token的缓存开销。我拿Qwen2.5-7B的GGUF Q4_K_M版本做了个梯度测试，2K上下文时显存峰值5.0GB，4K跳到5.5GB，8K直接干到6.8GB，16K我没敢试，按这个斜率估摸着要8GB以上。
长文档场景特别能体现这个问题的严重性。我拿一份五十页的PDF做摘要，文本切完token大概一万二。为了塞进去我把上下文设到14K，加载完模型显存已经占了6.2GB，一跑推理直接OOM。后来切成4K分段摘要再合并，峰值显存5.6GB，跑得稳稳当当。这个过程让我彻底放弃了“大上下文一劳永逸”的幻想。
多轮会话的显存增长曲线跟长文档不太一样。短对话每轮新增的token少，KV Cache慢慢涨，但很多框架有对话截断或者滑窗机制，显存不会无限膨胀。我用Ollama跟Qwen2.5-7B聊了四十多轮，显存从初始的5.2GB慢慢爬到5.9GB然后稳住了，Ollama默认的上下文窗口到了上限会截掉最早的对话。这个行为在长会话里挺关键，你要是没注意框架的截断策略，聊到一半突然回复质量断崖式下跌，八成是丢上下文了。
小参数模型在这方面的优势很明显。Qwen2.5-3B的Q4版本，32K上下文下显存峰值才4.1GB，8GB卡上跑起来轻轻松松。我试过拿它做整本书的摘要，三十二万字的文本切段喂进去，从头到尾没崩过。代价是生成质量确实不如7B，摘要的细节保留度差一截。我的用法是：长文档先拿小模型粗筛段落，再喂给7B做精读，显存和效果都能兼顾。
3.3 推理框架显存占用对比：llama.cpp、Ollama、vLLM与Transformers
框架之间的显存差异让我重新审视了“跑得动”和“跑得好”的区别。llama.cpp是我用得最多的，显存管理比较克制，加载Qwen2.5-7B Q4_K_M后基础占用4.8GB，随上下文增长平滑上升，4K下5.5GB，8K下6.8GB，没有突然的尖峰。这个线性特征让我能比较准确地预估能不能跑。
Ollama底层就是llama.cpp，但封装了一层模型管理服务，显存占用比裸跑llama.cpp多出200MB到400MB。这多出来的部分不是白吃的，Ollama帮你管模型加载卸载、API服务、并发请求排队，省了很多手工活。我日常用Ollama就是因为这层封装，多花几百兆显存换省心，8GB卡上我觉得值。但要跑极限场景，比如8K上下文加7B模型，我会切回裸llama.cpp抠那几百兆余量。
vLLM的显存策略完全是另一个路子。它启动时预分配一大块显存做KV Cache池，默认拿总显存的90%。8GB卡上它一上来就占7.2GB，模型权重再一加载直接爆。我试过把gpu_memory_utilization调到0.7，勉强能加载7B模型，但可用的KV Cache块少得可怜，并发两个请求就排队。vLLM在24GB以上的卡上是神器，8GB卡上我是真伺候不起。
Transformers加bitsandbytes的4bit量化我也试了。加载Qwen2.5-7B大概占5.8GB，比GGUF多出1GB多，原因是PyTorch的显存分配器碎片比较多，加上bitsandbytes的反量化开销。它的好处是跟HuggingFace生态无缝衔接，做实验调参方便。我拿它跑过几轮LoRA微调的推理验证，显存峰值冲到7.5GB，勉强没崩，但全程提心吊胆。日常部署我还是回llama.cpp，Transformers留给折腾代码的时候用。
框架选择这块我有个自己的排序。8GB卡上纯推理，llama.cpp排第一，Ollama第二，Transformers第三，vLLM除非你只跑2K上下文的小模型否则别碰。这个排序在12GB卡上会变，vLLM能往上提，16GB以上vLLM就是首选了。显存越紧张，框架的显存管理策略就越关键。
3.4 显存占用对比表设计：理论估算、实测峰值与可复现测试记录
我做显存对比表的时候犯过一个错，一开始只记了模型文件大小，觉得这就算显存占用了。后来发现文件大小跟实际占用差得远，同一个4.2GB的GGUF文件，llama.cpp加载后占4.8GB，多出来的是计算图、临时缓冲区和CUDA上下文。这个差距在7B模型上大概600MB，小模型上比例更高。
理论估算我用的公式是：权重占用加KV Cache加运行时开销。权重占用看量化格式，GGUF Q4_K_M大概是参数量的0.6倍GB数，7B模型约4.2GB。KV Cache按每token每层两倍隐藏维度乘2字节算，Qwen2.5-7B的4K上下文大概0.8GB。运行时开销我统一按0.6GB估，这个数在不同框架间有浮动，llama.cpp偏低，Transformers偏高。三项加起来5.6GB，跟我实测的5.5GB很接近。
实测峰值我建议一定要记录三个数：加载后空闲占用、推理时峰值占用、连续跑十分钟后的稳定占用。这三个数能反映不同的问题。加载后空闲占用看框架的基础开销，推理峰值看KV Cache和临时张量的真实需求，连续跑的稳定占用能暴露显存泄漏。我测GLM-4-9B的时候就发现连续跑二十分钟后显存缓慢爬升了300MB，虽然没崩，但说明有轻微泄漏。
可复现测试记录我列了个固定模板：硬件型号、驱动版本、框架及版本、模型文件哈希、量化格式、上下文长度、批大小、提示词内容、生成token数、峰值显存读数。看着繁琐，但换个人照着复现能对得上号。我上次跟朋友对同一个模型的测试结果差了1.2GB，查了半天发现是他驱动版本老了一截，CUDA上下文占用不一样。从那以后我测试记录里连驱动版本都写进去。
表格的形式我倾向用三列：理论估算、我的实测、偏差说明。偏差超过15%的标黄，超过30%的标红。目前跑下来标红的基本都是vLLM和Transformers的条目，llama.cpp和Ollama的偏差可控。这个表我建议每个玩低显存部署的人都自己维护一份，别人的数据只能参考，你卡上的真实表现才是做决策的依据。
显存这东西，4GB和8GB之间隔着的不是4个G，是一整个使用场景的差距。我手头常备三张卡，一张4GB的旧卡、一张8GB的主力卡、还有一张12GB的卡偶尔借来玩玩。这一章我就按这三个档位，把跑过的模型排个座次，顺带说说每个档位到底能干什么、不能干什么。全是自己踩出来的体感，参数党别较真，参考着看。
4.1 4GB与6GB入门档低显存模型排行及可用场景
4GB卡能跑的模型，说难听点就是“能喘气”级别。我拿GTX 1650那张4GB卡测了一圈，Qwen2.5-0.5B的Q4版本加载完占1.2GB，跑起来峰值不到1.8GB，流畅得不像话。Qwen2.5-1.5B的Q4_K_M加载后2.1GB，4K上下文推理峰值冲到3.4GB，刚好卡在红线下面。Phi-3-mini的Q4版本稍微吃力点，加载2.4GB，峰值3.7GB，偶尔触发系统内存回退，速度掉得厉害。
这个档位排第一的我给Qwen2.5-1.5B，中文理解在这么小的体量里算奇迹了。问它简单的客服问题、做文本分类、提取个会议时间地点，准确率能看。排第二的是Qwen2.5-0.5B，纯粹是因为它稳，什么卡都能跑，当个玩具或者极简对话机器人够用。Gemma-2B的Q4版本我也试了，3.1GB加载完，峰值3.8GB，跑是能跑，但中文能力比Qwen差一截，英文场景可以考虑。
6GB卡的情况好转不少。Qwen2.5-3B的Q4_K_M加载2.6GB，8K上下文峰值4.2GB，留了1.8GB余量，跑得从容。这个档位我首推Qwen2.5-3B，做本地轻量知识库检索问答很够用，我拿它配合一个简单的向量库做了个公司制度查询工具，响应快、不崩、答案虽然偶尔缺细节但方向基本对。备选是Llama3.2-3B，英文对话明显比Qwen顺，中文就凑合了。
6GB还有个隐藏玩法，跑Qwen2.5-1.5B的FP16版本，3.1GB加载，不量化损失精度，小模型在FP16下生成质量确实比Q4好一截。我拿它做代码补全的测试，补全的语法正确率比量化版高了两成左右。代价是上下文只能开到4K，再大就爆。这个取舍看你更在乎质量还是更在乎能塞多长的文本。
入门档有个坑我得提一嘴，很多教程推荐在4GB卡上跑7B模型的Q2量化。我试过Qwen2.5-7B的Q2_K，文件2.8GB，加载后占3.9GB，看着能跑对吧？一推理就现原形，Q2量化的质量崩得亲妈都不认识，回复经常胡言乱语，速度还慢，每秒八个token晃悠。这种“能跑”跟“能用”之间隔着一条银河，我的建议是4GB卡老老实实玩3B以下的模型，别硬上大模型的极端量化版。
4.2 8GB主流档低显存模型排行与综合推荐
8GB是现在最甜的点位，也是我折腾最多的一张卡。Qwen2.5-7B的Q4_K_M在我这张RTX 3060 Ti上加载4.8GB，4K上下文峰值5.6GB，8K下6.9GB，日常使用留了1GB出头余量，心里踏实。这个模型我排8GB档第一，中文综合能力在7B这个体量里没对手，写邮件、改文案、答技术问题都能接住。
排第二的是Llama3.1-8B的Q4_K_M，加载5.1GB，4K峰值5.9GB。它的英文能力和逻辑推理确实比Qwen稍强，我拿它做英文邮件起草和简单代码评审，输出结构比Qwen更规整。中文就一般了，偶尔冒出翻译腔。这两我一般是按任务切着用，中文活给Qwen，英文活给Llama。
GLM-4-9B是我最近才认真跑的，之前觉得9B在8GB卡上肯定爆，实际Q4_K_M加载5.4GB，4K峰值6.3GB，居然撑住了。它的中文知识问答质量在7B到9B这个区间里很能打，我拿它答了一些法规和制度类的问题，细节比我预期的好。代价是加载慢，从点击运行到能对话要四十多秒，而且连续跑半小时后显存会缓慢爬到7.1GB，得重启一下。排第三，但值得备着。
Yi-1.5-6B是个偏科生。Q4版本加载4.3GB，峰值5.1GB，显存占用比7B省一截，中文写作流畅度不错，我拿它生成过几篇公众号草稿，语感比Qwen稍微自然一点。代码和逻辑推理就差明显一档了，问个稍微绕点的问题就开始编。它在我的排序里排第四，定位是“文字工作者的轻量助手”。
8GB档我综合推荐就一句话：主用Qwen2.5-7B，副用Llama3.1-8B，需要中文知识密度高的场景挂一个GLM-4-9B。这三个覆盖了九成日常需求。代码场景我单独说，DeepSeek-Coder-6.7B的Q4版本加载4.5GB，补全准确率在同体量里数一数二，我写Python的时候会切过去用，比通用模型顺手。它的短板是对话能力弱，你问它“这段代码什么意思”它能答，你让它“帮我写个周报”就露怯了。
有个细节得提醒，8GB卡上别开太多后台程序。我有次开着浏览器十几个标签页、微信、还有个视频播放器，加载Qwen2.5-7B直接OOM。关掉浏览器再跑，稳稳的。显存是共享的，系统桌面、浏览器硬件加速都吃显存，你看着模型占5.6GB，实际总占用可能已经7.5GB了。我现在的习惯是跑模型前把不用的应用全关了，这个动作能省出500MB到1GB的救命空间。
4.3 10GB至12GB进阶档模型排行与性能边界
12GB卡给我的最大感受是“喘气空间”终于够了。Qwen2.5-14B的Q4_K_M加载8.9GB，4K上下文峰值10.1GB，12GB卡上跑得稳稳当当，还能留点余量给系统。这个模型的中文能力比7B上了一个台阶，长文档理解、复杂指令跟随、多轮对话的一致性都明显更好。我拿它做长合同摘要，一次能塞8K上下文不切分，摘要的完整性比用7B分段拼起来强太多。
排第二的是Qwen2.5-7B的FP16版本，14.2GB权重在12GB卡上放不下，我试的是Q8_0量化，7.9GB加载，峰值9.2GB。Q8的精度损失极小，实际生成质量跟FP16几乎肉眼看不出差别，速度比Q4快一截。这个组合我推荐给对质量敏感、对上下文要求不极端的场景，比如代码补全，Q8的7B比Q4的14B在补全任务上更利索。
第三个要说的是CodeQwen1.5-7B的Q8版本，8.2GB加载，代码补全场景下是我用过最舒服的组合。补全的准确率和速度平衡得很好，12GB卡上开4K上下文，响应基本是秒回。它的通用对话能力一般，但写代码这件事上，专模确实比通模顺手。
10GB档比较尴尬，比8GB多2GB，能干的活提升有限。Qwen2.5-7B的Q6_K加载6.3GB，峰值7.4GB，10GB卡上留了2.6GB余量，可以开8K上下文不慌。这个组合适合经常处理中等长度文档的人，Q6的质量比Q4好半档，8K上下文能应付大部分文章和报告。我拿它做过一批新闻摘要的批量处理，吞吐稳定，质量够用。
12GB档的边界我摸得比较清楚。14B的Q4是质量和显存的甜蜜点，再往上16B以上的Q4就要11GB往上了，12GB卡上加载完只剩几百兆，随便开个长上下文就爆。往下7B的Q8是质量优先的选择。这中间有个空档，就是10B到13B这个区间的模型，Q4加载7GB到8GB，12GB卡上很宽裕，但市面上的选择不多，我试过几个效果都一般。这个档位目前我的建议就是二选一：要能力上14B Q4，要精度上7B Q8。
4.4 按场景选型：办公问答、代码补全、长文档摘要、本地知识库与轻量多模态
办公问答这个场景我拆成两类。一类是即问即答，比如“帮我润色这段话”“把这个表格转成文字描述”，8GB卡上的Qwen2.5-7B Q4就够，响应快、质量稳，没必要上更大的模型。另一类是带知识库的问答，比如查公司制度、查产品参数，这个场景模型大小不是关键，检索质量才是。我拿Qwen2.5-3B配了个简单的RAG，回答准确率跟7B裸跑差不多，因为答案都在检索到的文档里，模型只负责组织语言。这个发现让我省了不少显存，办公问答场景3B到7B足够了。
代码补全我单独拎出来说，因为它的需求和对话完全不一样。补全要的是低延迟、高准确、对上下文代码结构的理解，不需要模型懂太多世界知识。我的组合是12GB卡上跑CodeQwen1.5-7B的Q8，8GB卡上跑DeepSeek-Coder-6.7B的Q4，4GB卡上就别想代码补全了，延迟高到没法用。补全场景的上下文设置也有讲究，我一般开到2K到4K，把当前文件和附近几个函数塞进去，再大对补全质量提升有限，反而拖慢速度。
长文档摘要是我用得最多的场景，也是最能体现显存档位差距的场景。8GB卡上我的做法是分段摘要再合并，用Qwen2.5-7B Q4，每段4K上下文，一篇五十页的PDF大概切八段，跑完合并再让模型做一次全局摘要，总共五分钟左右。12GB卡上直接上Qwen2.5-14B Q4，8K上下文一次塞进去，三分钟出结果，细节保留明显更好。4GB卡上只能用小模型粗筛，Qwen2.5-1.5B把每段的主题句抽出来，再人工看一遍，适合对精度要求不高的快速浏览。
本地知识库这个场景我踩坑最多。一开始我以为模型越大检索问答越准，后来发现不是这回事。知识库问答的瓶颈在检索环节，向量库的召回质量决定上限，模型只负责把召回的内容组织成通顺的回答。我现在的配置是：8GB卡上Qwen2.5-7B Q4做生成，检索用bge-small这类小向量模型，整套跑下来显存占用6GB出头，响应两秒内。12GB卡上我会把生成模型换成Qwen2.5-14B Q4，回答的完整度和语气自然度好一些，但提升幅度没有价格差那么大。知识库场景我的结论是8GB档性价比最高。
轻量多模态是这两年的新玩法，我试过几个方案。LLaVA-1.5-7B的Q4版本在8GB卡上加载5.8GB，跑图片描述和简单视觉问答可以，但速度慢，一张图要等十几秒。Qwen2-VL-2B在4GB卡上能跑，加载2.9GB，识别简单的图表和文档截图够用，精度别指望太高。多模态的显存开销比纯文本模型大，因为视觉编码器额外吃显存，8GB卡上跑7B级别的多模态模型很勉强，我的建议是玩多模态至少准备12GB卡，或者接受2B级别模型的能力上限。现阶段低显存玩多模态，尝鲜可以，当生产力工具还差点意思。
场景选型说到底是个匹配问题，不是越大越好。我见过有人8GB卡硬上14B的Q3量化，跑是能跑，速度慢到每分钟出二三十个字，问答质量还不如7B的Q4。显存和模型大小要匹配，场景和模型能力也要匹配。办公问答3B到7B够用，代码补全专模优先，长文档摘要显存越大越省事，知识库重检索轻生成，多模态现阶段别对低显存抱太高期待。这几条是我折腾两年下来的体感总结，你照着选能少走不少弯路。
排行榜看多了会发现一个问题，同一个模型在不同人手里跑出来的显存占用能差出一大截。我见过有人说Qwen2.5-7B在8GB卡上稳稳的，也有人说一加载就爆。两边都没撒谎，差别在部署姿势。这一章聊聊我这两年攒下来的优化手段，顺带把排行榜里那些容易踩的坑说清楚。
5.1 量化策略与显存优化：权重压缩、KV Cache量化与分层卸载
量化是低显存部署的第一道闸门，这道闸门怎么开直接决定了你能跑多大的模型。我最早只会用Q4_K_M，觉得这是万能钥匙，后来发现不同任务对量化的敏感度完全不一样。Q4_K_M在通用对话上跟FP16的差距很难察觉，但做代码补全的时候，Q4版本的补全准确率比Q8低了大概一成半。我现在的习惯是：对话类任务Q4够用，代码和数学类任务往上走一档到Q5或Q6，除非显存实在卡得死。
权重量化只是显存账本里的一页，KV Cache的量化经常被忽略。我拿Qwen2.5-7B Q4在8K上下文下测过，默认FP16的KV Cache吃掉将近1.8GB，换成Q8量化的KV Cache压到不到1GB，Q4的KV Cache能压到600MB出头。KV Cache量化对生成质量的影响比权重量化更微妙，短对话几乎无感，长文档摘要的时候能感觉到细节丢失，特别是数字和专有名词容易出错。我的做法是短对话开KV Q8，长文档任务老老实实FP16。
分层卸载是个保命技能，不是日常手段。llama.cpp的--n-gpu-layers参数我调过无数次，把一部分层扔到CPU上跑，显存立刻松一口气，代价是速度断崖式下跌。我试过在8GB卡上跑Qwen2.5-14B的Q4，卸载8层到CPU，显存占用从10GB压到7.2GB，能跑了，但生成速度从每秒25个token掉到每秒6个。这个组合我只在“必须用14B能力且只有8GB卡”的极端场景下用，平时不碰。分层卸载的本质是用时间换空间，你得想清楚这个交换值不值。
5.2 上下文与批处理优化：截断策略、滑动窗口与并发控制
上下文长度是显存的隐形杀手，这句话我逢人就说。Qwen2.5-7B Q4在4K上下文下占5.6GB，到8K就6.9GB，16K直接8.2GB往上，8GB卡当场去世。很多人测模型只看加载后的静态占用，忽略了推理时KV Cache随上下文线性增长这回事。我的习惯是部署前先算一笔账：模型权重占多少、每1K上下文吃多少KV Cache、系统预留多少，三个数加起来超过显存容量的八成就要警惕。
截断策略得按场景设计，不能一刀切。做客服问答的时候，我把历史对话截到最近6轮，再往前的内容用一句摘要代替，显存稳住了，多轮对话的连贯性也没怎么丢。做长文档处理的时候，滑动窗口比硬截断好用得多，我一般设4K窗口、2K重叠，让模型带着前一段的尾巴读下一段，摘要的衔接处不会断裂。这个参数组合是我试了七八组之后定下来的，重叠太少会漏信息，重叠太多浪费算力。
批处理在低显存场景下是个双刃剑。vLLM的连续批处理确实能把吞吐拉上去，但显存占用也跟着涨。我在8GB卡上跑Qwen2.5-7B，批大小设1的时候显存峰值5.6GB，设4直接冲到7.8GB，再大就OOM。低显存部署的批处理，我的经验是批大小设1到2，靠请求队列排着来，别贪吞吐。真要高并发，换大卡或者多卡，别在小显存上硬撑。我见过有人为了压榨吞吐把批大小开到8，结果每个请求都变慢，整体体验反而更差。
5.3 低显存模型排行常见误区与避坑指南
排行榜最容易误导人的地方是“能跑”和“好用”被混为一谈。我早期看榜选模型，看到某个7B模型标着“4GB可运行”，兴冲冲下载下来，加载确实能加载，一对话就发现每秒出三个token，回复质量还稀碎。后来我学乖了，看排行先看测试条件里的上下文长度和量化格式，标着4GB可运行的7B模型，八成是Q2量化加2K上下文，这种组合的实用性基本为零。
第二个坑是拿别人的显存数字直接套自己的机器。同一个模型，我在RTX 3060 Ti上跑出来峰值5.6GB，朋友在RTX 4060上跑出来6.1GB，差了500MB。框架版本、CUDA版本、驱动版本、后台程序，每一个变量都在悄悄吃显存。排行榜上的数字只能当参考区间，不能当精确指标。我现在的做法是自己跑一遍，用nvidia-smi盯着峰值看十分钟，心里才有底。
还有个误区是盲目追新。新模型发布的时候榜单更新很快，新模型排到前面，旧模型往下掉。我踩过这个坑，追着一个刚发布的小模型折腾了一周，部署各种报错、框架支持不全、量化版本还没出，等生态跟上的时候热度已经过了。低显存部署这个领域，模型发布后等两到四周，等GGUF和AWQ版本齐了、等框架适配稳了再上手，能省掉大量试错时间。榜单是风向标，不是发令枪。
5.4 小参数模型、蒸馏模型与端侧部署趋势对排行的影响
这两年最明显的变化是小参数模型的质量在快速逼近大模型。Qwen2.5-3B的中文能力已经接近两年前7B的水平，Phi-3-mini在英文推理上能跟一些13B模型掰手腕。这个趋势直接改写了低显存排行版的格局，以前8GB卡上7B是甜点，现在3B到4B的模型在很多场景下够用了，显存余量更大，能开更长的上下文，整体体验反而更好。我最近做办公问答，已经从7B切到3B配RAG，响应更快、显存更省、准确率没掉。
蒸馏模型是另一个变量。我试过几个用大模型蒸馏出来的小模型，在特定任务上的表现确实超出参数量的预期，比如某些代码蒸馏模型在补全任务上能压过同尺寸的通用模型。蒸馏模型的短板是泛化能力，它在蒸馏数据覆盖的场景里很强，出了这个范围就露馅。排行榜如果把蒸馏模型和通用模型混在一起排，参考价值会打折扣，得看清楚测试集是什么。我现在看榜会专门留意模型是不是蒸馏版，蒸馏版只在对应场景里采纳。
端侧部署的趋势对排行榜的影响更深远。手机、平板、迷你主机这些设备开始能跑3B以下的模型，量化到Q4甚至Q3，显存占用压到2GB以内。这个方向上的排行跟PC端完全是两套逻辑，端侧更看重功耗、内存带宽和首字延迟，而不是纯粹的生成质量。我拿一台16GB内存的迷你主机试过跑Qwen2.5-1.5B Q4，全程CPU推理，速度每秒12个token，做简单的文本处理和问答够用，功耗不到15瓦。这种场景下的排行，参数量的权重在下降，能效比的权重在上升。
趋势归趋势，选型还是得回到自己的实际需求。小模型质量上来了不代表大模型没价值，长文档理解和复杂推理还是得靠14B往上的模型。蒸馏模型在专精场景好用不代表通用场景也能凑合。端侧部署方便不代表能替代桌面端。排行榜是个工具，帮你在候选池里缩小范围，最终拍板还得靠自己在目标硬件上跑一遍。我折腾这么久最大的体会就是：榜单看三遍，不如自己实测一遍。
