8GB显存跑35B大模型这话放出去谁听了都先皱眉。我自己动手之前也不信直到有一次手里的主力显卡被临时征用只剩一台装着8GB老卡的机器才硬着头皮开始找办法。折腾到半夜模型确实跑起来了能正常对话、能写代码片段只是速度谈不上流畅——但一个35B参数的模型单张8GB显存的消费级显卡就能逐字推理这件事本身就值得把整条链路拆开聊聊。这篇实录不是标题党也不是劝你“8GB也能和4090体验一样”。我会把账算清楚把量化、CPU卸载、混合推理这些听起来很唬人的概念讲成人话再给出可以直接抄走的部署步骤、参数设置和实测数据。适合手里只有8GB卡但想本地玩中大规模开源模型的玩家也适合被“显存不够就玩不了大模型”劝退过、想搞明白边界到底在哪的人。1. 先算清楚这笔账35B 为什么天然“放不进”8GB 显存1.1 模型体积的数学基础要理解这件事先得回到最朴素的存储逻辑。一个模型的“显存占用量”大致等于参数数量乘以每个参数占用的字节数。35B参数意味着350亿个参数如果精度是FP16每个参数占2字节那么光权重就是350亿×2字节约70GB。这还没算推理过程中的中间激活值、KV Cache和各种临时张量。所以问题根本不是“8GB怎么优化一下就能塞下”而是“70GB的东西怎么变成能塞进有限空间的东西”。这就是量化出现的根本原因——把每个参数的精度降下来换取体积的大幅缩小。我用实际跑过的量化格式给你列个表你就明白了精度格式35B模型大致体积单独放进8GB显存FP16原始约70GB完全不可能INT8约35GB完全不可能INT4Q4_K_M约20GB装不下全部但可以分给内存INT3Q3_K_S约16GB同样装不下仍需外部内存INT2Q2_K约13GB装不下而且质量损失严重从这张表能看出一个残酷的前提哪怕量到Q4级别35B模型依然有20GB左右单靠8GB显存物理上就是塞不进去的。那些号称“8GB跑35B”的方案本质都不是“装进显存”而是“装进系统和显卡的混合空间”。1.2 显存、内存与带宽真正的瓶颈其实不在容量很多人以为显存不够就完了其实真正卡住本地大模型体验的是容量和带宽的联合绞杀。显卡推理和CPU推理的核心区别在于GPU有巨大带宽——一块普通消费级显卡的显存带宽动辄300GB/s以上高端旗舰能到上千GB/s而CPU从DDR4/DDR5内存读数据通常只有40-90GB/s。差距是数量级的。这里有个关键概念叫“权重复用”。Transformer模型每预测一个token理论上都要把全部权重读一遍。如果模型20GB、5%的层在GPU、95%的层在CPU内存那么每个token生成之前系统都得通过PCIe或内存控制器把绝大部分权重搬运一遍。带宽决定了你的每秒token数上限容量决定了你能不能真正把模型加载起来。所以我当时给自己定了个目标先跑通再谈速度。8GB显存跑35B本质上是在“容量不足”和“带宽有限”之间找一个能用方案——用系统内存补足容量用最少的GPU层数保住基本推理速度接受一个“能用但绝不丝滑”的结果。2. 破解思路量化、CPU卸载与混合推理是怎么协作的2.1 量化不是玄学Q4_K_M 为什么是甜点如果你接触过Ollama或llama.cpp一定见过Q4_K_M、Q5_K_M这类文件名。它们的核心原理是把大部分参数用4bit存储但对一小部分关键张量比如attention层里容易受误差影响的权重保留更高的精度。K代表K-quant算法M代表混合中等精度。刚开始玩的时候我也迷信过“精度越低越垃圾”的说法。实测下来Q4_K_M在多数任务上相对FP16的质量损失是轻微且可感知但不致命的——尤其在代码生成、结构化输出、翻译这类任务上差距很小反而是长文本逻辑推理时偶尔会出现“思路走偏”的情况这更多是模型本身能力的限制倒不全怪量化。我踩过一个特别典型的坑为了省空间直接下Q2_K版本结果模型对话时频繁输出混乱内容像是喝多了在胡言乱语。后来换回Q4_K_M才正常。所以我的建议是35B模型的底线就是Q4_K_M能上Q5或Q6更好但你的系统内存和显存需要与之匹配。省空间可以调整部署方式而不是一味压缩量化精度。2.2 GPUCPU 混合推理显存不够内存来凑“混合推理”这个词听起来很高端落地到实际操作就是一句话把模型的一部分层放在显卡上其余层放在系统内存里推理时逐层计算需要哪一层的输出就从对应的存储位置读取。以原版llama.cpp为例控制这个行为的核心参数是--n-gpu-layers缩写为-ngl。Ollama里对应的是num_gpu参数。设成-ngl 0就是纯CPU推理设成-ngl 99是尽可能把层都扔给GPU。我当时的策略很简单先设一个较大的-ngl等Ollama提示显存不够再往回减直到能稳定加载为止。这里有一个很重要的经验不要试图把显存塞满。8GB显存还要同时容纳KV Cache、CUDA上下文和各种临时计算缓冲留出至少1-2GB余量才不会中途OOM或触发显存碎片化问题。我的实际配置是num_gpu设为20左右取决于具体模型的总层数这样大约三分之一的层在GPU剩下的交给系统内存继续算。或许你会问CPU部分的计算不会慢到无法忍受吗会但也没那么可怕。现代CPU跑4bit量化后的矩阵运算单靠AVX512或AMX指令集也能榨出一些性能。实测感受是GPU和CPU之间的切换是无缝的你不会感知到“哪一层在哪”只有生成速度会告诉你答案。2.3 工具链选型为什么我用 Ollama 而不是直接撸 llama.cpp这个选择其实没有绝对的对错关键在于你的目的是“研究原理”还是“快速跑起来”。我最初直接用llama.cpp编译确实获得了最大的参数控制权——-ngl、--threads、--ctx-size都非常直观。但随之而来的问题是模型管理、多模型切换、内存回收这些琐事全得自己处理debug成本偏高。换到Ollama之后体验改善是明显的。它的底层本质还是llama.cpp那一套但把模型管理和服务封装成了极简接口一条ollama run命令就直接进对话界面还自带OpenAI兼容API。对只想专注体验模型、不想跟CMake和编译器搏斗的人来说Ollama是更务实的起点。当然如果你喜欢完全掌控全局或者需要一些Ollama没暴露的底层参数直接上手llama.cpp依然是好选择。我把两套方案的适用人群做个简单对比方案优势劣势适合人群Ollama安装简单、模型管理方便、自带API底层参数暴露有限快速体验、应用开发llama.cpp参数控制灵活、适配性强编译和命令行有门槛研究原理、极限调优3. 完整部署实录从选型到跑通 35B 的全过程3.1 环境准备与模型选型别忽略机器自己的短板我的“实验机”配置属于典型的消费级老平台8GB显存显卡、64GB DDR4内存、普通NVMe固态。写这段前先提醒你一个残酷事实系统内存如果只有16GB跑35B Q4基本没戏——模型权重20GB都超过了内存容量加上操作系统和其他常驻进程16GB必然直接爆掉。所以底线是系统内存至少要有32GB最好直接上64GB。安装Ollama这一步没什么好说的下载对应系统的安装包装完就能用。Linux下也可以直接跑安装脚本Windows下就是普通安装流程。唯一要注意的是如果你装的Ollama版本比较新默认的并发请求数、并行加载模型数这些全局参数可能会在后台悄悄吃显存。曾有一次我同时加载了两个模型显存瞬间爆掉这才注意到OLLAMA_MAX_LOADED_MODELS这类环境变量。至于模型选型我家里网络环境好的时候直接用ollama pull拉取模型网络条件差的机器建议用镜像源或者换一台能联网的电脑下载GGUF文件再拷过来。35B级别的开源模型在Hugging Face和各类模型仓库都有不同量化版本的GGUF格式重点是选一个带Q4_K_M后缀的文件或者用Ollama官方库里明确标注的35B Q4版本。别图省事直接拉默认版本默认很可能是更大的精度8GB显存连启动都会失败。3.2 让模型真正跑起来的配置不是装完就完事装好Ollama、确认模型下载完成之后如果你直接敲ollama run大概率会看到GPU利用率很低、速度惨不忍睹甚至直接报显存不足。原因很简单Ollama默认会尝试把所有层都加载到GPU8GB显存撑不住于是回退到某种“低效的CPU-only”模式——没错它会跑但跑得让你怀疑人生。正确的做法是给模型专门写一个Modelfile把关键参数固定进去。下面是个可以直接抄的示例假设模型tag为my-35b-q4FROM qwen-35b:q4_K_MA PARAMETER num_gpu 20 PARAMETER num_ctx 4096 PARAMETER temperature 0.7 PARAMETER top_p 0.9这里最核心的就是num_gpu 20。它定义了有多少层放GPU。如果你的显卡只有8GB显存这个数字需要根据模型总层数调整。我的做法是先用一个较大的值测试比如30如果报错就逐步减到22、20、18直到能稳定加载为止。还有一个关键点是num_ctx 4096——上下文长度直接决定KV Cache的大小。8GB显存下4096上下文比默认的8192或更高要稳得多。想追求更激进把上下文压到2048生成速度还能再快一点。写好后执行ollama create my-35b-q4 -f Modelfile ollama run my-35b-q4首次加载会比较慢因为需要把20GB的权重从磁盘读入内存和显存。加载完成后你会看到GPU利用率上升、显存占用在6GB左右、系统内存占用在14GB左右——这个分布基本就是8GB跑35B的合理状态。3.3 交互阶段让模型在低显存下保持行为正常跑通之后接踵而来的第二个问题是生成速度太慢的时候模型容易像卡带一样答非所问。这其实不完全是模型的错而是低速度下人机交互的体验错位。我总结出三个非常实用的小技巧能让实际使用感受提升一个台阶。第一提问时把问题拆得更细。速度慢的时候一次性抛给模型一个复杂的多段任务你盯着屏幕等三分钟结果它写到一半开始胡编体验极其崩溃。改成小步提问每步只给一个明确子任务虽然总时间差不多但每一段输出都在可控范围内。第二提前把系统提示词准备好。这里说的system prompt不只是“你是一个助手”这种空话而是把输出格式、语气、任务边界都写清楚。我在本地模型上测试了很多次明确的系统提示词对低带宽推理下的输出稳定性帮助很大能省掉不少无效的输出浪费。第三善用流式输出和停止令牌。如果是通过API调用一定要开启stream模式否则服务端会等到全部生成完毕才返回那体验是灾难级的。同时遇到代码生成类任务故意在结尾加上“”之类的停止标记能防止模型继续胡编一类内容。4. 实测结果生成速度、输出质量和现实应用的边界4.1 速度实测每秒多少 token 才够用我相信你最关心的就是这一节。我的实测环境是上面那台配置模型为35B Q4_K_Mnum_gpu 20num_ctx 4096。实际生成速度大约在每秒2到5个token之间浮动具体取决于问题的复杂度和当前上下文长度。短句回答时能摸到4-5 token/s长文本生成时会降到2-3 token/s。这个数字到底意味着什么人类正常阅读速度大约是每秒5-7个字中文模型每个token对应的汉字视分词方式而定大约2-3个token才是一个汉字。换算下来模型每秒说出的汉字数大概只有1-2个阅读基本要一句一句地等。我的真实感受是这个速度适合“问答、小段代码生成、结构化输出”不适合“读整本书、写几千字长文、做长对话陪伴”。做个直观对比如果同样是35B Q4模型放在一块24GB显存的显卡上全GPU推理速度能达到20-40 token/s体验完全不是一个等级。8GB方案的意义不在“追上旗舰卡”而在于“让没有旗舰卡的人也能摸到35B模型的能力边界”。4.2 输出质量35B 和 7B 的差距到底值不值这可能是整篇文章里最值得认真看的一节。起初我担心“8GB跑35B速度那么慢不如跑一个7B-8B小模型至少快得多”但实际对比后35B在复杂推理、长程规划、代码逻辑等方面确实稳压7B一头。同样是让模型写一个带状态管理的异步任务调度器7B模型给出的代码经常有明显逻辑漏洞而35B模型能给出结构完整、异常处理到位的版本。为了控制变量我还专门用同一批问题跑过35B Q4和7B Q8结果是复杂问题上35B即使4bit也强于7B的高精度版本。这背后的原因很简单——模型的参数量决定了表征能力和知识容量量化只是引入噪声而参数量是实打实的信息量。你可以理解为一个读了很多书但有点近视的人比一个只读了几页书但视力满分的认字更靠谱。所以我的结论是如果你对本地模型的需求集中在“解决复杂一点的问题”8GB跑35B的思路完全值得付出速度代价。如果只是日常闲聊、翻译几个句子小模型加高速度的体验反而更好。这个选择本质上是在能力的上限和交互的流畅度之间找平衡。4.3 什么场景真正适合 8GB 跑 35B结合几个月的使用体验我认为真正适合这种跑法的场景有三大类。第一类是敏感数据本地处理比如公司内部文档摘要、隐私性较高的代码审查数据不出本机的好处是很多团队根本无法拒绝的。第二类是复杂但不强调实时的任务例如批量给大量短文本打标签、整理会议纪要点、生成结构化JSON数据这类任务看重质量而非响应速度预先排队慢慢跑完全没问题。第三类是深度学习验证你想确认某个35B模型是否满足需求又暂时没有云端预算或大显存卡先用这种方式做技术预研。反过来如果你要做实时聊天机器人、追求连续对话的沉浸感或者需要处理很长文档8GB方案会让你非常难受。这时候老老实实租API或升级硬件性价比反而更高。本地部署不是信仰它是成本、隐私和体验的动态平衡不同场景有不同的最优解。5. 绕坑心得我在低显存下踩过的那些坑5.1 显存碎片化与 OOM不是显存不够而是分配不均匀低显存场景下最让人崩溃的报错就是CUDA out of memory。但“OOM”的原因不总是模型太大很多时候是显存碎片化。加载模型、KV Cache、CUDA上下文后显存被切割成多个不连续的小块后续申请大块内存就可能失败哪怕你肉眼看着显存“还剩3GB”。我的解决思路很简单粗暴留出余量。把num_ctx压到4096把num_gpu降到能稳定跑的值然后重启Ollama服务让显存重新分配。这里特别提醒Ollama在加载多个模型或反复切换模型后显存释放往往不彻底与其费劲排查不如直接重启服务。实测重启后同样配置的OOM概率大幅下降。还有一次坑来自于其他桌面程序抢显存。Windows下浏览器硬件加速、视频播放器、甚至某些输入法特效都会占用几百MB显存。低显存机器上这些“看不见的占用”可能就是压垮配置的最后一根稻草。我在跑模型前会临时关掉浏览器硬件加速效果非常明显。5.2 速度优化的优先顺序先调什么最有效很多人一跑起来发现慢第一反应就是疯狂调整量化等级和层数忙了半天速度没提升多少。我的经验是优化顺序必须按影响大小排序浪费时间的顺序会让你失去耐心。首先检查是否真的有一部分层在GPU上。用ollama ps查看如果显示GPU内存为0说明你的模型根本没有利用显卡这是最大的性能黑洞。其次调整上下文长度num_ctx从8192降到4096能实打实减少KV Cache和计算量。接着才是微调num_gpu的层数找到一个“刚好不OOM”的最大值。最后再看CPU线程数设置体验上大概调整到物理核心数而不是逻辑线程数反而更稳定。坦白说我见过很多人直接把所有层都丢CPU然后抱怨慢但实际上他们显卡利用率一直为零。低显存跑大模型的底线是“能利用一点GPU就利用一点”纯CPU和混合推理的差别可能比你量化等级提升两档还大。5.3 什么时候该放弃本地转用 API 或升级硬件这个话题可能有点劝退但认真讲反而能帮人省时间。如果你发现自己花了整整一周调参、仍然无法接受每秒2-3个token的速度那最理性的选择就是租用云端GPU实例或使用商业API。这不是丢人是切切实实的成本收益判断。本地部署的初衷是隐私和控制权如果这两个诉求并不强烈API往往是更优解。但我主观上依然觉得8GB跑35B这件事有独特的学习价值。它会逼着你理解量化、显存管理、模型架构、Transformer推理链路这些东西是无价的。一旦明白了再去操作任何AI部署工具都会觉得透明、有底气。最后分享一个我一直在用的小技巧把Ollama服务设置成开机自启然后用任务计划或脚本在低负载时段自动跑那些不紧急的批量推理任务。晚上睡前提交一批任务第二天醒来直接收获结果。这个“夜间打工”的玩法完美避开了速度慢的痛点让8GB老卡在低功耗下默默干活反而成了我本地部署里最常用的一块阵地。
