尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

8GB显存跑35B大模型:显存与CPU内存协作推理的实测调优

8GB显存跑35B大模型:显存与CPU内存协作推理的实测调优 很长一段时间里我都被“消费级显卡能不能跑大模型”这个话题吊着胃口。手边正好有一张8GB显存的老型号消费级显卡网上又到处飘着“8GB跑35B”的说法索性把它当成一次摸底实测。真正跑通之后发现这个标题里的“跑”字跟很多人理解的跑完全不是一回事它靠的不是显存堆得下而是显存和CPU内存分工协作。这篇文章就把我整个实测过程、踩过的坑、调参的方式、以及最后的真实速度全部记录下来给同样只有中低端显卡、又想折腾本地大模型的人做个参考。1. 先算一笔账35B模型在8GB卡上到底是怎么“塞”进去的1.1 35B参数的全精度权重有多大很多人看到“8GB跑35B”的第一反应是不可能。我最初也是这个反应因为用最朴素的方式算35B参数就是350亿个参数值每个参数按FP16半精度浮点存储占2字节那光权重就是70GB。哪怕换成8bit量化1字节一个参数也得35GB。8GB显存连零头都装不下这不是开玩笑。但问题在于“全精度”是一个极端情况。现实中的开源模型通常以量化后的形式分发最常用的是4bit量化。按大约4.5bit一个参数来估算35B模型的权重压到18到20GB。这就产生了一个新的可能整份权重虽然还是超过8GB显存但如果只把模型的一部分放进显存剩下的留在系统内存里理论上就能跑。1.2 “跑起来”的真实原理显存放一层内存放一层大模型的网络结构是一层一层堆起来的有点像一列火车每节车厢就是一层的权重。推理的时候数据要顺序通过每一层才能输出结果。所以不需要像读一张大图那样把整列火车一次性停进显存而是可以让前面若干节车厢停在显存里后面若干节停在系统内存里CPU和GPU各算各的。实际执行的时候GPU负责显存里那部分层的计算CPU负责内存里那部分层的计算。层与层之间的中间结果通过PCIe总线在显存和内存之间来回搬。这就是“8GB能跑35B”的方案基础。Ollama这类工具在加载大模型时会先把模型文件映射进系统内存再根据显存余量把部分层灌到GPU上显存放不下的层就在CPU上跑。这里有个容易误解的地方很多人以为Ollama会把整个模型装进显存所以一看到“8GB跑35B”就觉得是标题党。实际上只要系统内存够大比如32GB甚至64GB加载20GB权重的量化模型是很自然的做法。显卡只是拿了属于它的那8GB。1.3 速度瓶颈PCIe带宽才是真正的天花板这种混合方案的代价很明显计算速度完全取决于CPU和GPU之间的数据搬运效率。GPU内的显存带宽通常在每秒几百GB级别CPU访问DDR4/DDR5内存的带宽也有几十GB每秒。但问题出在PCIe总线上。消费级主板上的PCIe 4.0 x16理论带宽也就32GB/s实际可用带宽大约25GB/s如果你用的是PCIe 3.0那就只有约16GB/s。每算完一层中间结果就要从显存搬出去或者从内存搬回来一次来回折腾几次之后速度会掉得非常厉害。所以“能跑”和“跑得快”是两码事。我在第一次把35B量级模型拉起来的时候生成速度只有每秒两三个token连基础的对话都显得拖沓。这也是后面所有调优的核心目标尽量让更多层留在显存里减少跨PCIe的数据搬运。2. 开始前的选型模型、量化、部署工具怎么挑2.1 “35B”到底对应哪个模型严格意义上名字里正好带35B的开源模型不多最常见的其实是Qwen2.5的32B、Command R的35B这类“三十多B”参数档位。标题里的35B更多是一个泛称。我这次实测选的标尺是Qwen2.5 32B一是因为它下载量高、中文能力有保障二是在Ollama生态里可以直接拉取不用折腾格式转换。在Ollama里qwen2.5:32b默认就是Q4_K_M量化下载大小大概在19到20GB。这个大小是系统内存能扛住的范围。如果内存只有16GB建议直接放弃32B去看14B或者更小的模型如果要硬上32B16GB内存会在一开始就陷入swap地狱几乎不可用。2.2 量化等级怎么选Q4还是Q8决定模型文件大小的关键在量化等级量化等级每参数占用35B模型大致体积效果评价FP162字节约70GB最优但体积巨大Q8_01字节约35GB质量接近原版体积大Q5_K_M约0.7字节约24GB质量和体积较均衡Q4_K_M约0.55字节约20GB推荐质量损失可接受Q3_K_M约0.4字节约14GB体积小但效果下降明显在8GB显存条件下Q4_K_M几乎算是最优解。我实测下来Q4和Q5之间的差距在常规对话里很难察觉但在代码生成、逻辑推理这类任务上Q5会比Q4略稳。如果你内存足够且更在意质量可以拉Q5_K_M如果追求能跑且内存吃紧Q4_K_M就是那个“平衡点”。2.3 部署工具选Ollama还是llama.cpp这次我用的是Ollama主要因为省事。Ollama底层其实就是llama.cpp的封装但它把模型管理、量化下载、环境变量配置都集成好了适合像我这样想快速验证“能不能跑”的人。如果在生产环境或对层控制有极致需求llama.cpp编译版能调得更细但对普通玩家没必要。Windows上的安装很直白官网下载安装包下一步下一步就行。不过我强烈建议在跑大模型之前先把几个环境变量设置好否则默认配置下很容易遇到显存爆掉或者模型加载失败。3. 完整实测操作从安装到第一次看到输出3.1 环境准备和关键环境变量我的测试机配置是CPU为8核16线程内存32GB DDR4显卡8GB显存系统Windows 11硬盘是NVMe SSD。这套配置在二手市场很常见不算高端但用来测“8GB跑35B”刚好。装好Ollama之后先别急着拉模型。我建议在系统环境变量里加三个值setx OLLAMA_MAX_LOADED_MODELS 1 setx OLLAMA_KEEP_ALIVE 24h setx OLLAMA_NUM_GPU 24解释一下含义。OLLAMA_MAX_LOADED_MODELS设为1是避免同时加载多个模型导致显存被瓜分OLLAMA_KEEP_ALIVE让模型在24小时内驻留内存不用反复加载OLLAMA_NUM_GPU最关键它控制把多少层放到GPU上。Qwen2.5 32B一共有64层设成24只代表我打算先让24层进显存剩下的留在CPU。设完之后需要重启Ollama进程让环境变量生效。3.2 拉取模型和第一次加载的现场设置完毕直接在终端里跑ollama run qwen2.5:32b第一次会下载模型接近20GB的文件量具体时间看网速和磁盘速度。我当时等了大概二十分钟。下载完成后终端陷入一段很长的沉默像是加载了很久然后才弹出对话提示。这里有个细节如果硬盘速度不够快或者Windows Defender正在后台扫描GGUF文件加载时间会被拉长到好几分钟属于正常现象别急着按CtrlC。启动后用nvidia-smi看显存占用会看到显存从平时几百MB跳到6GB以上说明Ollama确实把一部分层放进了显卡。但这时候如果直接输入“你好介绍一下自己”大概率会等到一个很煎熬的响应。我遇到的第一个完整输出生成速度只有每秒2.1个token相当于一句话要等几十秒。3.3 交互式调整GPU层数Ollama支持在对话中直接改参数。我在终端里输入/set parameter num_gpu 40 /set parameter num_ctx 4096 /runnum_gpu调大到40意味着让更多层住进显存num_ctx限制上下文长度为4096目的是让KV Cache不要吃掉太多显存。改完之后重新运行再用nvidia-smi看显存占用会接近7GB此时生成速度明显提升。注意/set parameter这个命令在不同Ollama版本里的表现不完全一致有的版本支持有的版本被忽略。更稳妥的做法是直接改OLLAMA_NUM_GPU环境变量然后彻底退出Ollama托盘进程再启动。我的做法是先用环境变量锁定一个基础值再用对话内参数做临时微调。3.4 第一个像样的回答把num_gpu调到40之后再问同样的问题生成速度提升到每秒3.6个token虽然离“流畅”还差很远但至少能接受。Qwen2.5 32B在中文任务上的表现确实比7B模型强一大截回答的完整性和条理性都能感觉到明显升级。这种“虽然慢但回答质量高”的状态就是8GB机器跑35B的真实日常。4. 调整GPU层数后的性能变化附调参配置4.1 不同层数下的实测数据我把GPU层数从0调到40记录了几组数据尽量保持同一问题和同一长度排除文本本身带来的误差GPU层数生成速度tokens/s显存峰值主观感受0纯CPU1.1几乎没有完全不可用101.9约3.4GB能跑但等得心焦202.6约5.3GB勉强可对话303.4约6.8GB日常问答可用403.8约7.6GB接近这台机器的甜点再往上调到接近48层显存会有很高的爆显存风险因为KV Cache会随时占用额外空间。8GB显存在跑40层左右时剩余空间已经非常少一旦上下文长度增长KV Cache扩张起来直接把显存撑爆。4.2 为什么不是所有层都塞进显卡就更好很多人会有一个直觉既然num_gpu越大越快那把能塞的都塞进去不就行了实测下来的经验是这个逻辑只在一定范围内成立。当显存余量低于某个阈值比如只剩几百MB系统为了给KV Cache腾地方可能会主动把某些层搬回CPU甚至干脆内存换出。这时候你看到的不是更快而是更卡甚至直接报OOM。所以调层数的本质是在“能驻留显存的权重”和“KV Cache的生存空间”之间找平衡。上下文越长KV Cache占得越多留给层数的显存就越少。如果只做短对话可以把上下文限制在2048到4096然后放心把层数拉高如果要做长文档总结那就要忍痛降低层数把显存留给KV Cache。4.3 关于“每秒3.8个token”算什么水平3.8 t/s是什么概念参考一下人类阅读速度大约是每秒4到6个中文字符模型生成速度差不多等于一个很慢的人在那儿打字。对于短问答还能忍对于超过500字的长文等待时间就会变成几分钟。这个速度比纯7B模型在GPU上全速跑差远了但考虑到跑的是32B量级模型已经算是“物理极限内能接受”的结果。4.4 实测中最实用的三组配置我把最稳的三组配置列出来方便直接抄作业短对话模式推荐OLLAMA_NUM_GPU40num_ctx 2048速度3.6到4.0 t/s显存稳定在7.2GB左右。中等任务模式OLLAMA_NUM_GPU30num_ctx 4096速度2.8到3.4 t/s显存约6.8GB适合文档总结和代码生成。长上下文模式OLLAMA_NUM_GPU20num_ctx 8192速度2.0到2.5 t/s显存约5.6GB适合长文分析和多轮对话。5. 实测翻车现场加载失败、掉速掉帧的排查链路5.1 现象一模型加载时直接报“内存不足”第一次在16GB内存的备用机器上拉同样的模型时Ollama直接报了内存不足。很多人以为这是显卡问题其实不是。32B Q4模型的权重将近20GB系统内存如果只有16GB连映射文件的空间都不够自然加载失败。这个问题没有软件解法要么换32GB内存要么换14B模型。这里必须强调一个反常识的细节Ollama在Windows上不是把20GB的GGUF文件一次性读进物理内存而是使用内存映射文件。真正吃内存的部分是运行时产生的KV Cache和CPU计算缓冲区。但即便如此物理内存太小同样会触发加载失败或者中途退出。所以想跑35B这一档32GB内存是底线中的底线。5.2 现象二显存明明有余量但速度只有1 t/s有一次我把OLLAMA_NUM_GPU改成很大的数字但速度反而比默认还慢。查了一圈发现原因在Windows任务管理器里显卡占用率冲到99%CPU占用率也维持在高位。这说明模型的一部分层在GPU上另一部分在CPU上两边都在满负荷跑但瓶颈变成了跨PCIe的数据来回搬。这种情况有个特征GPU的利用率和CPU的利用率同时接近满载但机器就是不快。因为每次层切换GPU算完自己的部分就要等CPU的结果送过来然后才能继续算下一部分。你可以把这种状态理解成一台流水线两端都在拼命干活但传送带太窄大量时间都耗在等待和搬运上。解法和前面说的一样要么减少GPU层数让流水线在一个地方跑完要么减少CPU层数尽量让更多计算留在显卡里。但8GB显存决定了你没法让所有层都留在显卡里所以这类机器的瓶颈最后必然落在PCIe传输上。5.3 现象三对话越聊越慢甚至回复中断刚开始玩的时候我跟它聊了十几轮输出了好几百个token然后明显感觉到速度从3.5一路跌到1字头。这不是发散而是上下文变长后KV Cache膨胀导致的。KV Cache就是模型在对话过程中记住前面内容的缓存上下文越长它占的内存量就越大。当显存里没有足够空间KV Cache会被放到系统内存里每取一次都更慢。排查方法很简单在对话界面输入/info或者直接用ollama ps看当前上下文占用。解决思路也很直接调小num_ctx或者每隔几轮点击重启对话给KV Cache瘦身。长对话不是8GB机器该干的事至少在这台机器上不是。5.4 现象四Windows下首次加载异常慢首次加载32B模型时我等了将近五分钟才看到对话提示一度以为卡死了。后来用资源监视器一看磁盘读取一直在跑但CPU占用不高。原因有两层一是GGUF文件有20GB冷启动时要加载到内存映射区域二是Windows Defender会扫描新下载的大文件尤其是第一次运行扫描时间拉得非常长。解决办法是把模型文件所在的目录加到Defender的排除列表里比如Ollama默认的模型目录通常在C:\Users\你的用户名\.ollama\models。添加排除后后续加载速度能快半分钟以上。如果还是不放心可以先观察一下资源占用再决定要不要动Defender设置。5.5 给想要复现的人一句提醒如果你也想照着复现建议先在终端里记住两个命令nvidia-smi看显存ollama ps看模型当前在GPU还是CPU。这两个命令能回答绝大部分“为什么这么慢”的疑问。剩下的基本都是在调层数和上下文长度之间做取舍。6. 跑起来之后的真实定位这台配置适合干什么6.1 值得做的任务离线问答、隐私文档、代码补全把35B模型在这个配置上跑通之后我也冷静下来给它定位了一番。它不适合当作实时聊天助手因为每秒三四个token的速度实在太慢但适合那些不着急的任务。我最常用的是离线隐私问答。有些内容不方便发到云端API塞给本地模型跑至少数据留在本地。比如整理一份内部文档让它总结摘要或者写一段示例代码这类任务不强调秒回几分钟出结果也完全能接受。35B参数量的推理能力比7B强太多写出来的代码质量、逻辑分析深度都明显上了个台阶。6.2 别指望的场景高并发、长文档、实时翻译高并发就不用说了单机单卡同时只有一个人能用。长文档也基本是噩梦超过2000字之后每多一轮对话KV Cache都会把预算吃得干干净净。实时字幕、实时翻译这类需要低延迟的场景这台机器也完全扛不住。如果你想用8GB显卡体验大模型我的实诚建议是先用7B或8B的量化模型把全GPU推理的流畅性感受一遍再回来跑32B你才知道快和慢的差距在哪里。一上来就硬上35B容易误以为本地大模型都是这德行。6.3 后续升级的方向和顺序如果对这套方案有兴趣想进一步提升升级顺序很重要。首先是内存至少要32GB16GB跑35B纯属折磨其次是硬盘尽量用NVMe SSD否则冷加载时间会拖到怀疑人生再往后才考虑换显卡。12GB显存的显卡能把层数拉得更高速度会快不少但它解决不了CPU层依旧存在的根本问题。落到实际我对这套“8GB跑35B”方案的最终评价是能跑但跑得很勉强它像一个证明题证明了消费级硬件和开源生态结合之后确实能把门槛压到很低。但在真正用起来的时候我还是更愿意把35B留给那种不赶时间的任务比如深夜跑一个离线总结或者开会前让它帮我整理一份材料。它能做的不算多但对于一台没有额外预算的老电脑来说已经足够惊艳了。
返回列表