看到模型显存总体分析这个主题我第一反应就是这几年帮网友配本地模型环境时被问烂了的问题我这个显卡到底能跑多大的模型为什么别人的显卡能跑 13B 我只能跑 7B6GB 显存是不是不配玩本地大模型这些问题本质上都指向同一个核心——显存。显存直接决定了你能不能在本地跑模型、能跑多大的模型、能跑多长的对话、能开多大的 batch。搞清楚显存的消耗逻辑比单纯抄别人的配置清单管用得多。这篇我打算把模型推理时显存到底花在哪儿、怎么估算、怎么在有限显存下做取舍一次性讲透尤其照顾一下 6GB 显存这个卡在门槛上的群体。1. 一张显卡到底能装下多大的模型先搞清楚显存都花在哪了很多人以为模型显存 模型文件大小这其实是最大的误解。模型文件在硬盘上是 3.5GB不代表你只需要 3.5GB 显存就能跑真实运行时的内存占用往往比文件大小高出 30%~50%原因在于显存里装的不只是模型参数本身。1.1 权重参数最直观的那块大头模型里的权重weights是显存消耗的第一大来源。每个参数需要多少字节取决于你加载时的精度FP32单精度每个参数占 4 字节FP16/BF16半精度每个参数占 2 字节INT88-bit 量化每个参数占 1 字节INT4/NF44-bit 量化每个参数占 0.5 字节所以一个 70 亿参数7B的模型不同精度下权重占用的显存可以这样粗算精度每参数字节数7B 模型权重占用13B 模型权重占用FP32428GB52GBFP16/BF16214GB26GBINT817GB13GBINT40.53.5GB6.5GB这就是为什么量化quantization是低显存玩家的救命稻草。同样一个模型FP16 加载需要 14GBINT4 加载只要 3.5GB显存需求直接砍到四分之一。代价当然是精度损失但现代量化方法比如 GGUF 的 Q4_K_M、QLoRA 的 NF4在大多数场景下损失已经控制得很小属于用 5% 的智商税换 75% 的显存折扣。1.2 KV Cache对话越长越吃显存权重是固定成本KV Cache 则是动态成本很多人栽在这上面。KV Cache 是推理过程中用来缓存历史对话的 key-value 向量避免每次生成新 token 都要重新计算全量 attention。它的占用公式是KV Cache 大小 2 × 层数 × 注意力头维度 × 序列长度 × batch size × 每参数字节数前面那个 2 是 K 和 V 各一份。具体数字我不想让新手头皮发麻直接给结论一个 7B 模型在 2048 上下文长度下FP16 精度的 KV Cache 大约占 0.5GB~1GB上下文拉到 8192这个数字直接翻四倍变成 2GB~4GB。你可能会惊讶——光历史对话的缓存就能吃掉好几个 GB。这还没完。如果你的推理框架支持 GQAGrouped Query Attention分组查询注意力KV Cache 会比 MHAMulti-Head Attention多头注意力小很多。这也是为什么新出的模型Llama 3、Qwen 2.5 这些普遍用 GQA人家不只是为了推理速度更是在帮你省显存。选模型的时候同等参数规模下优先选带 GQA 的长对话场景差异非常明显。1.3 激活值、CUDA 上下文和碎片隐形开销不容小觑权重和 KV Cache 之外还有三部分隐形开销很多人算来算去发现对不上就是漏了它们激活值activations前向传播过程中每层的中间结果batch size 越大、序列越长激活值越夸张。推理时如果 batch 1激活值通常占 200MB~1GB但你以为没人会开大 batch 就错了服务多用户时 batch 开上去了激活值能吃掉几个 GB。CUDA contextCUDA 上下文只要你调用 CUDA显卡驱动就会划走一块固定显存作为运行时上下文一般 300MB~800MB这个躲不掉NVIDIA 驱动越大吃的不一定越多但基础开销就在那儿。显存碎片多次加载/卸载模型之后显存里会出现碎片大块连续内存申请不到。实际表现就是显存明明显示还有 2GB但加载一个只需要 1.5GB 的模型却 OOMOut of Memory显存溢出。这个在长时间不重启、反复切换模型的机器上特别常见。算总账的时候我习惯用一个粗暴的系数实际显存需求 ≈ 权重占用 × 1.3 或 2~3GB 固定开销。前者适合参数密集的估算后者适合小模型。两种方法交叉验证比单看文件大小靠谱得多。2. 显存估算公式不用进推理框架也能算出个大概理解了显存的构成就能自己估算任何模型在你机器上的可行性。这一步不用装任何工具拿计算器就能搞定。2.1 核心公式与计算流程我的估算流程分四步查模型的参数量单位是 Bbillion确定加载精度FP16 还是 INT4 还是其他量化档位估算需要的上下文长度对话轮数 × 每轮 token 数用公式汇总总显存 ≈ 参数 × 每参数字节数 KV Cache 固定开销举一个实际例子。假设你想用 Ollama 跑 Qwen2.5 7B 的 Q4_K_M 量化版预期上下文 4096权重7B × 0.5字节 ≈ 3.5GB KV CacheGQA7B 规模4096 上下文FP16约 1.5GB~2GB CUDA context 激活值 碎片余量约 1GB 合计3.5 2 1 约 6.5GB看到没有一个文件大小可能只有 4.4GB 的 Q4 量化模型实际在 4096 上下文下要吃掉 6.5GB 左右显存。如果你只给它 6GB要么降低上下文到 2048要么让一部分层跑到 CPU 上这就是后面要说的 offload 问题。2.2 精度选型影响的可不是一星半点有人觉得量化只是显存和精度的简单交换其实没这么简单。不同量化档位之间显存省下来的比例和精度损失的比例不是线性的。以 GGUF 格式为例常见的几个档位量化档位每参数字节数相对 FP16 的显存占比质量表现FP162100%无损基准Q8_01.0625~53%几乎无损Q6_K0.75~38%损失极微Q5_K_M0.625~31%日常可用Q4_K_M0.5~25%性价比之选Q3_K_M0.375~19%明显受损应急用Q2_K0.25~13%不推荐我实测下来的感受是Q4_K_M 是低显存场景的甜点位再往上 Q5 确实好一点但在大多数问答、写作、代码补全场景里差距不大Q3 及以下就别碰了生成的文本经常逻辑断裂你省下来的显存会在反复重试生成这件事上还回去。2.3 一个 6GB 显存卡的实际计算示例就拿很多网友手里都有的 6GB 显卡比如 RTX 2060、RTX 3050、GTX 1660 Super来算笔账。6GB 显存里先刨掉 CUDA context 和系统占用的 0.5GB~0.8GB实际能给模型的只有 5.2GB~5.5GB。用这个数去套不同规模的模型模型规模Q4 量化权重剩余给 KV Cache 的空间能支撑的上下文3B~4B约 2GB约 2.5GB~3GB8192 甚至更长7B~8B约 3.5GB~4GB约 1.5GB~2GB2048~409613B~14B约 6.5GB~7GB不够得靠 CPU 卸载结论很清晰6GB 显存跑 7B 级别模型的 Q4 量化版是刚好能进门槛但余地不大的状态跑 3B~4B 模型可以从容应对长上下文跑 13B 以上的模型必须依赖 CPU 帮忙速度会明显下降。这个边界不是靠感觉的用上面的公式自己算一遍心里就踏实。3. 6GB 显存实际能跑什么Ollama 场景下的真实边界很多人的第一反应是装 Ollama因为它确实把本地模型的门槛降到了一条命令。但 Ollama 也不是魔法显存的物理边界它绕不过去只是帮你自动做了很多权衡。3.1 Ollama 在显存管理上的工作方式Ollama 底层用的是 llama.cpp它的显存策略核心就一句话有多少显存用多少显存放不下的部分自动丢给 CPU。具体来说它会把模型切成一层一层的优先把尽可能多的层放进 GPU剩余层放到 CPU通过 PCIe 总线做数据传输。这个机制有个关键参数对应到 Ollama 环境变量是OLLAMA_NUM_GPU也可以用--num-gpu参数。在 Ollama 里这个值默认是 -1意思是让运行时自动检测。你的 6GB 显存如果加载 13B 模型的 Q4 量化版它不会直接 OOM 崩掉而是自动把一部分层扔到内存里用速度换容量。这里有个容易被忽视的点Ollama 判断放得下的标准不仅仅是权重还包括 KV Cache。所以你手动设了很高的上下文长度Ollama 就得从 GPU 层数里挪出更多空间给 KV Cache导致更多层落到 CPU速度更慢。这个连锁反应很多人没意识到只怪模型好慢其实是你把上下文调太高了。3.2 7B/8B 模型量化后跑得动吗直接给结论跑得动但要在上下文长度上做让步。以 6GB 显存为例实测跑 Qwen2.5 7B Instruct 的 Q4_K_M 量化版上下文 2048可以全部塞进显存GPU 推理速度大约 30~50 token/s取决于显卡型号上下文 4096勉强全显存运行但显存余量很少如果开浏览器或录制软件容易 OOM上下文 8192大概率会有部分层落到 CPU速度掉到 10~20 token/s所以如果你主要是短对话、单轮问答7B 模型全显存跑没问题。需要处理长文档、超长对话就得考虑换 3B~4B 模型或者接受 CPU offload 带来的速度下降。3.3 13B/14B 模型是不是完全没戏也不是完全没戏但你要接受一个现实6GB 显存跑 13B 模型体验不在流畅区间而在于能不能用。还以 6GB 显存为例跑 Qwen2.5 14B 的 Q4_K_M权重就得 6.5GB显存根本装不下Ollama 会把大约 60%~70% 的层放到 CPUGPU 只负责一小部分实际速度大概 3~8 token/s取决于你的 CPU 性能和内存带宽3 token/s 什么概念一句话 30 个 token你要等 10 秒。这个速度做验证性测试可以真拿去办公写东西耐心会被消耗殆尽。我的建议是6GB 显存就别硬上 13B 了除非你的机器有 DDR5 高频内存 16 核以上的 CPU否则体验大概率让你想砸键盘。这不是打击人而是帮你把期望值放在正确位置。6GB 显存最舒服的区间就是 7B~8B 的 Q4 量化版和 3B~4B 的更高精度版前者管智商、后者管速度各取所需。4. 实测推荐6GB 显存上的模型选型与对比这一节不该叫测评因为我没打算堆跑分数据更想分享的是我帮不同需求量身定做的几个选择逻辑。同样是 6GB 显存代码需求和聊天需求的选择完全不同。4.1 综合能力与中文场景的首选如果你只装一个模型我的答案是Qwen2.5 7B Instruct 的 Q4_K_M 量化版。理由很直接中文能力强这是通义系模型的传统优势7B 规模在 6GB 显存上刚好处于全显存运行和轻度 offload的交界支持 GQA长对话时的 KV Cache 消耗比老模型低一截Ollama 仓库里直接ollama run qwen2.5:7b就能拉下来默认就是量化版实际体验下来这个模型做文案改写、知识问答、日常对话是完全够用的。和更大的模型比差距主要体现在复杂推理和长文本结构化输出上但考虑到你手里的显存厚度它已经是综合性价比的天花板了。4.2 代码场景和英文场景的替换选项写代码是另一个高频需求但代码场景的逻辑严谨性要求更高7B 模型有时候会露怯。我试过几个方案DeepSeek-Coder-V2-Lite 16BQ3/Q4 量化能力确实更强但 16B 的体量在 6GB 显存上几乎必须重度 offload速度惨不忍睹仅适合不着急的代码审查CodeLlama 7B / Llama 3.1 8B 的 Q4 量化英文代码场景比 Qwen 更顺补全和简单重构够用但上下文一大也扛不住Qwen2.5-Coder 7B 的 Q4 量化中文注释友好代码生成质量在 7B 级别里属于第一梯队6GB 显存的代码党我最推荐这个如果你接受全英文输入输出Llama 3.1 8B的 Q4_K_M 也是很好的选择它的指令跟随能力和推理稳定性在同规模里排前面就是中文语感和词汇丰富度略逊于 Qwen。4.3 低显存环境下的参数微调技巧模型选好之后别急着开跑。还有几个 Ollama 层面的参数值得花两分钟调一下。默认上下文别贪。Ollama 的默认上下文是 2048如果你不处理长文档这个值没必要改。改了之后 KV Cache 涨GPU 层数降速度掉得不偿失。真要长文本按需设成 4096 就够再长建议换模型而不是硬加上下文。num_ctx和num_gpu配合着调。在 Modelfile 里可以这样写FROM qwen2.5:7b PARAMETER num_ctx 4096 PARAMETER num_gpu 30num_gpu设为总层数减几层故意留几层给 CPU这样 KV Cache 的显存压力更小不容易在长对话后期突然 OOM。30 这个数字不是固定的先看模型总共多少层减去 2~4 层就是合理值。开了num_gpu还是 OOM那就降低num_ctx每次砍一半直到稳定为止。这是个笨办法但胜在有效。5. 压榨显存的几条实战经验从踩坑里总结的最后分享几条我这几年实际跑模型攒下的经验。这些东西你去读官方文档不一定能读到因为文档不会告诉你哪些坑它自己都没想到。5.1 别迷信模型越大越聪明6GB 显存的用户最容易犯的错是硬上大模型然后靠 offload 硬撑结果速度和智能两头都不讨好。我见过太多人用 6GB 跑 70B 模型生成速度 0.5 token/s等半天出来一段质量还不如 7B 模型 40 token/s 流畅输出的内容。速度本身就是智能的一部分——你等得起你的耐心等不起任务的连续性也等不起。我个人的经验法则是显存能全量装下的最大模型优先于 offload 才能装下的更大模型。7B 全显存跑 14B 半 offload 跑因为延迟对交互体验的影响远大于那一点模型能力差距。5.2 显存不够时先看内存带宽如果你确实需要跑超出显存的模型决定体验的上限因素不是 CPU 核心数而是内存带宽。llama.cpp 在做 CPU offload 时每生成一个 token 都要在内存和显存之间搬运数据内存带宽越低速度越惨。同样是 6GB 显存跑 14B 模型DDR4 2666MHz 双通道速度约 3~4 token/sDDR5 6000MHz 双通道速度约 6~8 token/s所以低显存用户的升级路线未必是换显卡加内存频率和维度有时候立竿见影。这也是为什么那些跑本地模型的 DIY 玩家总是追求主板上的四条内存插槽全插满——带宽翻倍CPU 推理速度直接翻倍。5.3 跑之前先量化显存余量跑之后看两个数字最后一个习惯启动模型前先用nvidia-smi看显存余量别靠猜。启动后重点盯两个指标nvidia-smi里的 GPU 内存占用确认模型是否全部进了显存Ollama 的生成速度token/s如果个位数说明 offload 严重该调参或换模型了这两个数字一摆你就能判断当前配置是显存红利没吃满还是容量已经到极限下一步该加显存还是换模型一目了然。根据我的经验在 6GB 显存这个档位上最舒服的配置就是Qwen2.5 7B 或 Llama 3.1 8B 的 Q4_K_M 量化版上下文控制在 4096 以内留几层给 CPU 兜底。这套组合覆盖日常问答、文案生成、代码辅助绰绰有余而且几乎不会碰到 OOM 的崩溃体验。别老盯着排行榜上那些 70B、上百 B 的怪兽先把手中这块显卡的每一 MB 显存用到刀刃上比什么都实在。 大模型显存占用全解析：估算公式、量化技巧与6GB显卡实战指南
看到模型显存总体分析这个主题我第一反应就是这几年帮网友配本地模型环境时被问烂了的问题我这个显卡到底能跑多大的模型为什么别人的显卡能跑 13B 我只能跑 7B6GB 显存是不是不配玩本地大模型这些问题本质上都指向同一个核心——显存。显存直接决定了你能不能在本地跑模型、能跑多大的模型、能跑多长的对话、能开多大的 batch。搞清楚显存的消耗逻辑比单纯抄别人的配置清单管用得多。这篇我打算把模型推理时显存到底花在哪儿、怎么估算、怎么在有限显存下做取舍一次性讲透尤其照顾一下 6GB 显存这个卡在门槛上的群体。1. 一张显卡到底能装下多大的模型先搞清楚显存都花在哪了很多人以为模型显存 模型文件大小这其实是最大的误解。模型文件在硬盘上是 3.5GB不代表你只需要 3.5GB 显存就能跑真实运行时的内存占用往往比文件大小高出 30%~50%原因在于显存里装的不只是模型参数本身。1.1 权重参数最直观的那块大头模型里的权重weights是显存消耗的第一大来源。每个参数需要多少字节取决于你加载时的精度FP32单精度每个参数占 4 字节FP16/BF16半精度每个参数占 2 字节INT88-bit 量化每个参数占 1 字节INT4/NF44-bit 量化每个参数占 0.5 字节所以一个 70 亿参数7B的模型不同精度下权重占用的显存可以这样粗算精度每参数字节数7B 模型权重占用13B 模型权重占用FP32428GB52GBFP16/BF16214GB26GBINT817GB13GBINT40.53.5GB6.5GB这就是为什么量化quantization是低显存玩家的救命稻草。同样一个模型FP16 加载需要 14GBINT4 加载只要 3.5GB显存需求直接砍到四分之一。代价当然是精度损失但现代量化方法比如 GGUF 的 Q4_K_M、QLoRA 的 NF4在大多数场景下损失已经控制得很小属于用 5% 的智商税换 75% 的显存折扣。1.2 KV Cache对话越长越吃显存权重是固定成本KV Cache 则是动态成本很多人栽在这上面。KV Cache 是推理过程中用来缓存历史对话的 key-value 向量避免每次生成新 token 都要重新计算全量 attention。它的占用公式是KV Cache 大小 2 × 层数 × 注意力头维度 × 序列长度 × batch size × 每参数字节数前面那个 2 是 K 和 V 各一份。具体数字我不想让新手头皮发麻直接给结论一个 7B 模型在 2048 上下文长度下FP16 精度的 KV Cache 大约占 0.5GB~1GB上下文拉到 8192这个数字直接翻四倍变成 2GB~4GB。你可能会惊讶——光历史对话的缓存就能吃掉好几个 GB。这还没完。如果你的推理框架支持 GQAGrouped Query Attention分组查询注意力KV Cache 会比 MHAMulti-Head Attention多头注意力小很多。这也是为什么新出的模型Llama 3、Qwen 2.5 这些普遍用 GQA人家不只是为了推理速度更是在帮你省显存。选模型的时候同等参数规模下优先选带 GQA 的长对话场景差异非常明显。1.3 激活值、CUDA 上下文和碎片隐形开销不容小觑权重和 KV Cache 之外还有三部分隐形开销很多人算来算去发现对不上就是漏了它们激活值activations前向传播过程中每层的中间结果batch size 越大、序列越长激活值越夸张。推理时如果 batch 1激活值通常占 200MB~1GB但你以为没人会开大 batch 就错了服务多用户时 batch 开上去了激活值能吃掉几个 GB。CUDA contextCUDA 上下文只要你调用 CUDA显卡驱动就会划走一块固定显存作为运行时上下文一般 300MB~800MB这个躲不掉NVIDIA 驱动越大吃的不一定越多但基础开销就在那儿。显存碎片多次加载/卸载模型之后显存里会出现碎片大块连续内存申请不到。实际表现就是显存明明显示还有 2GB但加载一个只需要 1.5GB 的模型却 OOMOut of Memory显存溢出。这个在长时间不重启、反复切换模型的机器上特别常见。算总账的时候我习惯用一个粗暴的系数实际显存需求 ≈ 权重占用 × 1.3 或 2~3GB 固定开销。前者适合参数密集的估算后者适合小模型。两种方法交叉验证比单看文件大小靠谱得多。2. 显存估算公式不用进推理框架也能算出个大概理解了显存的构成就能自己估算任何模型在你机器上的可行性。这一步不用装任何工具拿计算器就能搞定。2.1 核心公式与计算流程我的估算流程分四步查模型的参数量单位是 Bbillion确定加载精度FP16 还是 INT4 还是其他量化档位估算需要的上下文长度对话轮数 × 每轮 token 数用公式汇总总显存 ≈ 参数 × 每参数字节数 KV Cache 固定开销举一个实际例子。假设你想用 Ollama 跑 Qwen2.5 7B 的 Q4_K_M 量化版预期上下文 4096权重7B × 0.5字节 ≈ 3.5GB KV CacheGQA7B 规模4096 上下文FP16约 1.5GB~2GB CUDA context 激活值 碎片余量约 1GB 合计3.5 2 1 约 6.5GB看到没有一个文件大小可能只有 4.4GB 的 Q4 量化模型实际在 4096 上下文下要吃掉 6.5GB 左右显存。如果你只给它 6GB要么降低上下文到 2048要么让一部分层跑到 CPU 上这就是后面要说的 offload 问题。2.2 精度选型影响的可不是一星半点有人觉得量化只是显存和精度的简单交换其实没这么简单。不同量化档位之间显存省下来的比例和精度损失的比例不是线性的。以 GGUF 格式为例常见的几个档位量化档位每参数字节数相对 FP16 的显存占比质量表现FP162100%无损基准Q8_01.0625~53%几乎无损Q6_K0.75~38%损失极微Q5_K_M0.625~31%日常可用Q4_K_M0.5~25%性价比之选Q3_K_M0.375~19%明显受损应急用Q2_K0.25~13%不推荐我实测下来的感受是Q4_K_M 是低显存场景的甜点位再往上 Q5 确实好一点但在大多数问答、写作、代码补全场景里差距不大Q3 及以下就别碰了生成的文本经常逻辑断裂你省下来的显存会在反复重试生成这件事上还回去。2.3 一个 6GB 显存卡的实际计算示例就拿很多网友手里都有的 6GB 显卡比如 RTX 2060、RTX 3050、GTX 1660 Super来算笔账。6GB 显存里先刨掉 CUDA context 和系统占用的 0.5GB~0.8GB实际能给模型的只有 5.2GB~5.5GB。用这个数去套不同规模的模型模型规模Q4 量化权重剩余给 KV Cache 的空间能支撑的上下文3B~4B约 2GB约 2.5GB~3GB8192 甚至更长7B~8B约 3.5GB~4GB约 1.5GB~2GB2048~409613B~14B约 6.5GB~7GB不够得靠 CPU 卸载结论很清晰6GB 显存跑 7B 级别模型的 Q4 量化版是刚好能进门槛但余地不大的状态跑 3B~4B 模型可以从容应对长上下文跑 13B 以上的模型必须依赖 CPU 帮忙速度会明显下降。这个边界不是靠感觉的用上面的公式自己算一遍心里就踏实。3. 6GB 显存实际能跑什么Ollama 场景下的真实边界很多人的第一反应是装 Ollama因为它确实把本地模型的门槛降到了一条命令。但 Ollama 也不是魔法显存的物理边界它绕不过去只是帮你自动做了很多权衡。3.1 Ollama 在显存管理上的工作方式Ollama 底层用的是 llama.cpp它的显存策略核心就一句话有多少显存用多少显存放不下的部分自动丢给 CPU。具体来说它会把模型切成一层一层的优先把尽可能多的层放进 GPU剩余层放到 CPU通过 PCIe 总线做数据传输。这个机制有个关键参数对应到 Ollama 环境变量是OLLAMA_NUM_GPU也可以用--num-gpu参数。在 Ollama 里这个值默认是 -1意思是让运行时自动检测。你的 6GB 显存如果加载 13B 模型的 Q4 量化版它不会直接 OOM 崩掉而是自动把一部分层扔到内存里用速度换容量。这里有个容易被忽视的点Ollama 判断放得下的标准不仅仅是权重还包括 KV Cache。所以你手动设了很高的上下文长度Ollama 就得从 GPU 层数里挪出更多空间给 KV Cache导致更多层落到 CPU速度更慢。这个连锁反应很多人没意识到只怪模型好慢其实是你把上下文调太高了。3.2 7B/8B 模型量化后跑得动吗直接给结论跑得动但要在上下文长度上做让步。以 6GB 显存为例实测跑 Qwen2.5 7B Instruct 的 Q4_K_M 量化版上下文 2048可以全部塞进显存GPU 推理速度大约 30~50 token/s取决于显卡型号上下文 4096勉强全显存运行但显存余量很少如果开浏览器或录制软件容易 OOM上下文 8192大概率会有部分层落到 CPU速度掉到 10~20 token/s所以如果你主要是短对话、单轮问答7B 模型全显存跑没问题。需要处理长文档、超长对话就得考虑换 3B~4B 模型或者接受 CPU offload 带来的速度下降。3.3 13B/14B 模型是不是完全没戏也不是完全没戏但你要接受一个现实6GB 显存跑 13B 模型体验不在流畅区间而在于能不能用。还以 6GB 显存为例跑 Qwen2.5 14B 的 Q4_K_M权重就得 6.5GB显存根本装不下Ollama 会把大约 60%~70% 的层放到 CPUGPU 只负责一小部分实际速度大概 3~8 token/s取决于你的 CPU 性能和内存带宽3 token/s 什么概念一句话 30 个 token你要等 10 秒。这个速度做验证性测试可以真拿去办公写东西耐心会被消耗殆尽。我的建议是6GB 显存就别硬上 13B 了除非你的机器有 DDR5 高频内存 16 核以上的 CPU否则体验大概率让你想砸键盘。这不是打击人而是帮你把期望值放在正确位置。6GB 显存最舒服的区间就是 7B~8B 的 Q4 量化版和 3B~4B 的更高精度版前者管智商、后者管速度各取所需。4. 实测推荐6GB 显存上的模型选型与对比这一节不该叫测评因为我没打算堆跑分数据更想分享的是我帮不同需求量身定做的几个选择逻辑。同样是 6GB 显存代码需求和聊天需求的选择完全不同。4.1 综合能力与中文场景的首选如果你只装一个模型我的答案是Qwen2.5 7B Instruct 的 Q4_K_M 量化版。理由很直接中文能力强这是通义系模型的传统优势7B 规模在 6GB 显存上刚好处于全显存运行和轻度 offload的交界支持 GQA长对话时的 KV Cache 消耗比老模型低一截Ollama 仓库里直接ollama run qwen2.5:7b就能拉下来默认就是量化版实际体验下来这个模型做文案改写、知识问答、日常对话是完全够用的。和更大的模型比差距主要体现在复杂推理和长文本结构化输出上但考虑到你手里的显存厚度它已经是综合性价比的天花板了。4.2 代码场景和英文场景的替换选项写代码是另一个高频需求但代码场景的逻辑严谨性要求更高7B 模型有时候会露怯。我试过几个方案DeepSeek-Coder-V2-Lite 16BQ3/Q4 量化能力确实更强但 16B 的体量在 6GB 显存上几乎必须重度 offload速度惨不忍睹仅适合不着急的代码审查CodeLlama 7B / Llama 3.1 8B 的 Q4 量化英文代码场景比 Qwen 更顺补全和简单重构够用但上下文一大也扛不住Qwen2.5-Coder 7B 的 Q4 量化中文注释友好代码生成质量在 7B 级别里属于第一梯队6GB 显存的代码党我最推荐这个如果你接受全英文输入输出Llama 3.1 8B的 Q4_K_M 也是很好的选择它的指令跟随能力和推理稳定性在同规模里排前面就是中文语感和词汇丰富度略逊于 Qwen。4.3 低显存环境下的参数微调技巧模型选好之后别急着开跑。还有几个 Ollama 层面的参数值得花两分钟调一下。默认上下文别贪。Ollama 的默认上下文是 2048如果你不处理长文档这个值没必要改。改了之后 KV Cache 涨GPU 层数降速度掉得不偿失。真要长文本按需设成 4096 就够再长建议换模型而不是硬加上下文。num_ctx和num_gpu配合着调。在 Modelfile 里可以这样写FROM qwen2.5:7b PARAMETER num_ctx 4096 PARAMETER num_gpu 30num_gpu设为总层数减几层故意留几层给 CPU这样 KV Cache 的显存压力更小不容易在长对话后期突然 OOM。30 这个数字不是固定的先看模型总共多少层减去 2~4 层就是合理值。开了num_gpu还是 OOM那就降低num_ctx每次砍一半直到稳定为止。这是个笨办法但胜在有效。5. 压榨显存的几条实战经验从踩坑里总结的最后分享几条我这几年实际跑模型攒下的经验。这些东西你去读官方文档不一定能读到因为文档不会告诉你哪些坑它自己都没想到。5.1 别迷信模型越大越聪明6GB 显存的用户最容易犯的错是硬上大模型然后靠 offload 硬撑结果速度和智能两头都不讨好。我见过太多人用 6GB 跑 70B 模型生成速度 0.5 token/s等半天出来一段质量还不如 7B 模型 40 token/s 流畅输出的内容。速度本身就是智能的一部分——你等得起你的耐心等不起任务的连续性也等不起。我个人的经验法则是显存能全量装下的最大模型优先于 offload 才能装下的更大模型。7B 全显存跑 14B 半 offload 跑因为延迟对交互体验的影响远大于那一点模型能力差距。5.2 显存不够时先看内存带宽如果你确实需要跑超出显存的模型决定体验的上限因素不是 CPU 核心数而是内存带宽。llama.cpp 在做 CPU offload 时每生成一个 token 都要在内存和显存之间搬运数据内存带宽越低速度越惨。同样是 6GB 显存跑 14B 模型DDR4 2666MHz 双通道速度约 3~4 token/sDDR5 6000MHz 双通道速度约 6~8 token/s所以低显存用户的升级路线未必是换显卡加内存频率和维度有时候立竿见影。这也是为什么那些跑本地模型的 DIY 玩家总是追求主板上的四条内存插槽全插满——带宽翻倍CPU 推理速度直接翻倍。5.3 跑之前先量化显存余量跑之后看两个数字最后一个习惯启动模型前先用nvidia-smi看显存余量别靠猜。启动后重点盯两个指标nvidia-smi里的 GPU 内存占用确认模型是否全部进了显存Ollama 的生成速度token/s如果个位数说明 offload 严重该调参或换模型了这两个数字一摆你就能判断当前配置是显存红利没吃满还是容量已经到极限下一步该加显存还是换模型一目了然。根据我的经验在 6GB 显存这个档位上最舒服的配置就是Qwen2.5 7B 或 Llama 3.1 8B 的 Q4_K_M 量化版上下文控制在 4096 以内留几层给 CPU 兜底。这套组合覆盖日常问答、文案生成、代码辅助绰绰有余而且几乎不会碰到 OOM 的崩溃体验。别老盯着排行榜上那些 70B、上百 B 的怪兽先把手中这块显卡的每一 MB 显存用到刀刃上比什么都实在。