1. 一张8G显卡凭什么敢碰35B模型先给结论8GB显存跑35B级别大模型技术上完全可行但它的定位是“能跑”不是“跑得爽”。我拿手里的RTX 4060 Laptop 8GB实测了几天中途踩遍OOM、CPU满载、上下文断裂这些坑最终在保持基本可用的情况下用Q2量化加上部分层卸载把35B级的模型在本地跑出了稳定出字的效果。这篇实录就把整个过程中最核心的计算逻辑、参数设置、速度表现和避坑记录全部分享出来。我为什么非要跟8GB显存较劲因为这是目前消费级笔记本和台式机的“主流配置”身边太多人买了4060/3060/笔记本4060结果一看到模型下载页面写着“XXB参数”第一反应就是“我这显卡是不是废了”。其实显卡不是废了是思路没换过来。本地部署大模型拼的不只是显存这一个指标内存带宽、量化方案、模型卸载策略、上下文窗口设定这些因素加在一起才是“能不能跑”的最终答案。再说一个容易被忽略的事实市面上真正叫“35B”的开源模型并不多大家日常说的“35B”其实是一个习惯性称呼覆盖了30B到35B这一档比如Qwen2.5-32B、Yi-34B、CodeLlama-34B都属于这个量级。下面的实操都以这一档模型为例。1.1 先算一笔显存账35B模型到底有多大要理解8GB到底为什么“看似不可能”得先把账算明白。模型权重在显存里占多大地方取决于两个参数参数量和权重精度。以35B级别模型为例FP16精度16位浮点每个参数占2个字节总重量约70GB。INT8量化每个参数占1个字节重量约35GB。INT4量化每个参数约0.5字节重量约17.5GB。2bit量化Q2系列每个参数约0.25到0.3字节重量大约9GB到11GB。所以默认下载的FP16版本8GB显存连零头都塞不下。哪怕做到INT417.5GB依然是天文数字。到这基本可以确定一件事纯靠显存硬扛8GB永远没戏。那为什么还有“8GB跑35B”这种说法因为推理计算并不要求整个模型全部躺在显存里。这就要引入两个关键词了量化砍体积、卸载借内存。1.2 量化活命卸载续命快慢全看带宽量化是把模型权重的精度降下来说白了就是“用一些精度换体积”。Q2_K系列能把35B模型压到10GB上下Q3_K系列则要12GB到14GBQ4_K就要15GB到17GB了。光看数据即使Q2_K已经接近10GB8GB显存还是差一点。这时候就要用到第二个手段层卸载。层卸载的原理说起来很简单一个Transformer大模型由几十层重复结构堆叠而成推理的时候一层算完才会算下一层不是所有层同时参与计算。所以可以把一部分层“放”在内存里计算到那一层时再从内存搬运到显存算完又腾出来。这个思路打个比方显存是厨房台面内存是冰箱。台面小放不下全部食材没关系炒哪个菜就从冰箱里拿哪个菜只是拿菜这个过程会耽误时间。基于这个原理有两类本地推理工具值得关注llama.cpp系列包括Ollama、LM Studio支持GGUF格式的量化模型通过ngl/num_gpu参数控制放进GPU的层数放不下的层跑在CPU内存里。AirLLM专门做“权重重于显存”的方案把整个模型按层组织在内存中每次计算时把需要的那几层权重复制到显存算完立刻释放。它的优点是几乎不挑显存大小4GB显卡也能跑70B模型缺点是慢因为没有做层并行权重搬运开销非常明显。如果也想看看这些工具背后是怎么实现的有一个叫nano-vllm的项目值得翻翻它是vLLM的精简教学版把推理框架的关键模块拆得很干净适合想搞懂“卸载、量化、KV Cache到底在做什么”的人。2. 工具选型别一上来就下PyTorch版全集很多第一次接触本地大模型的人最容易犯的错是直接去HuggingFace下载模型的safetensors权重文件然后试图用transformers库在本地跑起来。这个路线对8GB显存来说几乎是灾难。因为原生PyTorch推理不会自动帮你做层卸载默认要把整个模型权重一次性载入GPU内存35B的FP16版本直接把显存爆掉连报错的机会都不给。所以我强烈建议跑本地模型直接走GGUF路线别碰原生权重。GGUF是llama.cpp项目专门设计的格式把量化权重、分词器、模型超参数打包成单个文件配合llama.cpp运行时才能实现“显存装不下的部分自动放内存”这种操作。2.1 主流本地推理框架横向对比我实测过几个方案它们各自的定位差异用表格看最清楚工具底层引擎显存要求上手难度适合场景Ollamallama.cpp可调低单命令跑极低快速体验、日常聊天、API调用llama.cppllama.cpp可调低参数细致中等深度调参、逐参数控制LM Studiollama.cpp可调低界面友好低不想写命令的桌面用户AirLLM自定义卸载逻辑极低4G也能跑中小显存想试超大模型vLLM高性能服务引擎高适合多并发高服务生产环境消费卡慎入Ollama是目前我个人最推荐新手起步的方案。它把“下载模型、量化选择、GPU层数配置、上下文窗口设置”都包成了简单的命令默认情况下会自动检测显存并决定放几层进GPU对8GB用户来说这种“自动兜底”反而避免了一堆手动调参的折磨。llama.cpp则是进阶玩家的选择。它允许你通过-ngl参数精确控制放进GPU的层数是10层还是12层差别都在帧级。如果你愿意折腾还可以自己编译带特定优化指令集的版本再把CUDA加速开关打开实测比预编译版本快一些。顺带说一嘴驱动的坑。如果你在Windows笔记本上装的是NVIDIA驱动系统里可能同时存在核显和独显跑模型前先用nvidia-smi确认程序确实落在独显上。如果是那种NVIDIA计算卡专用的TCC模式和游戏显卡常用的WDDM模式之间本地推理用WDDM就行TCC模式主要面向数据中心场景普通玩家不必纠结。另外如果显卡出现花屏、显存报错之类的硬件问题可以试试NVIDIA的MATS显存检测工具不过这套东西对普通用户偏硬核我后面会详细说。2.2 量化版本怎么选Q2、Q3还是Q4选量化版本是8GB显存能否跑35B的决定性一环。我的实测结论是Q2_K2bit量化左右35B压到10GB上下配合12层左右的卸载8GB显存勉强起步。Q3_K_S3bit量化体积约12GB需要卸载更多层速度进一步下降。Q4_K_M4bit量化体积约15GB8GB显存基本只能全CPU跑速度跌到无法接受。这里存在一个关键矛盾量化的比特数越低模型智力损伤越大。Q2_K在简单的翻译、摘要、结构化输出上还能看但一遇到复杂推理、长文本归纳、代码debug就明显“脑子不够用”。Q3是质量与性能的妥协点可以接受偶尔的胡说八道。Q4质量最好但显存装不下是硬伤。所以别迷信“跑35B就一定要上最好的量化”。本地部署的第一原则是先保证模型放得下、有速度再谈质量。为“能跑”牺牲一点智商在8GB这个级别是不可避免的。如果你日常需要写代码、做数学题我反而建议退一步跑14B或者32B的Q4版本体验比硬跑35B的Q2舒服很多。2.3 模型下载渠道与文件校验GGUF格式的模型文件主要两个地方下载HuggingFace和国内做得很快的ModelScope。HuggingFace上搜索模型名 GGUF就能看到量化版本列表通常一个模型会有Q2_K、Q3_K_S、Q4_K_M、Q5_K_M、Q8_0这些变体文件名里都会标注清楚。下载时注意三点看文件名里的量化等级别下成fp16或者bf16版本体积直接翻好几倍。把GGUF文件放到SSD上第一次加载模型要读取好几个GB的文件机械硬盘加载35B模型的等待时间足够你去泡杯咖啡。下载完成后最好做个sha256校验有些镜像站会传坏文件跑起来会直接报不认识的错误排查起来极其折磨。3. 完整实操8GB跑35B的详细过程下面进入正题。我的测试环境是RTX 4060 Laptop GPU 8GB版i7-13620H处理器32GB内存Windows 11系统。这套配置很有代表性如果你是台式机的RTX 4060或者3060 12G结果只会比这个更好。先说目标我这次跑35B模型不是为了写论文、做推理就是希望实现三件小事离线聊天、写简单脚本、做长文档总结。对这个目标来说速度慢一点没关系关键是能顺利跑起来并且不频繁崩溃。3.1 用Ollama从零开始跑通Ollama安装好之后它默认从自带库拉取模型。我这次跑的是Qwen2.5-32B的Q2量化版命令如下ollama run qwen2.5:32b-q2_K这一步会先检查本地有没有这个模型文件没有就自动下载。下载完之后Ollama会尝试自动把模型塞进显存。问题在于8GB显存塞不下Q2量化后的完整模型如果直接run大概率会得到CUDA out of memory的报错或者模型把所有层放在CPU上跑速度慢到像老式拨号上网。要控制放入显存的层数需要用环境变量OLLAMA_NUM_GPU指定。Windows命令行里这样做set OLLAMA_NUM_GPU12 ollama run qwen2.5:32b-q2_KOLLAMA_NUM_GPU12表示把模型的前12层放进显存其余层留在内存。这个数字不是拍脑袋定的我试过几组值放12到14层时显存占用大概在7GB上下很稳放到18层以上就偶尔会OOM。第一次跑完看清楚显存占用再决定是往上加还是往下减。上下文窗口也直接影响显存占用。默认情况下Ollama会给一个较短的上下文跑大模型时我自己手动限制到2048 token。怎么理解token可以简单理解成字词的切分单位中文一两个字就是一个token2048 token差不多能支持2000字左右的中文对话日常聊天够用了。Ollama跑起来之后观察一个细节如果首字等待时间极长而且生成过程中显存占用始终不掉说明模型层卸载策略不合理。正常状态下生成第一个token的时候显存会有一个明显的峰值波动之后进入稳定期。如果是全CPU跑显存占用几乎为0GPU利用率也接近0但内存占用会涨到20GB以上。3.2 用llama.cpp精确控制层数如果你想要更细致的控制可以直接用llama.cpp。预编译的Windows版本在GitHub的Release页面可以下载把文件放到一个目录然后在命令行里跑llama-cli.exe -m qwen2.5-32b-q2_k.gguf -ngl 12 -c 2048 -p 你好请介绍一下自己这里的-ngl 12和Ollama的OLLAMA_NUM_GPU12是一个意思就是“放12层到GPU”。-c 2048则是上下文长度把它设置成一个保守值可以显著降低显存和内存压力。-p输入的是你要让模型生成的首句话。实测中ngl参数从0调到14生成速度是阶梯式变化的ngl 0全部CPU速度大约0.3到0.5 token每秒每个字要等两三秒基本不可用。ngl 8速度大约0.6到0.9 token每秒开始有可用性。ngl 12速度大约0.9到1.2 token每秒这是我能接受的最低可用档位。ngl 14速度可能到1.5 token每秒左右但如果同时开长上下文显存就会顶不住。什么是token每秒可以简单理解为每秒生成多少个“语言片段”中文大概一个字对应一两个token。1 token/s意味着生成一个20字左右的短句大约要等20到30秒体感上确实很慢但装杯效果拉满毕竟是8GB在跑35B。3.3 不做量化的另一条路AirLLM如果你不想用GGUF或者想跑一个非量化版本的大模型AirLLM提供了另一种思路。它的核心设计是模型权重全部驻留在内存推理时按层动态搬运到GPU显存计算。安装方式很简单pip install airllm调用方式和transformers很像from airllm import AirLLMLlama2 model AirLLMLlama2(/path/to/model) print(model.generate(介绍一下你自己))AirLLM最大的优势是精度不用量化理论上是“满血版”模型。但代价就是慢。它相当于每次算一层都要把权重从内存搬到显存内存带宽再高也比不上显存自身的带宽实测下来速度只有0.3到0.5 token每秒而且内存占用极其夸张。我的建议是如果只是为了验证某个模型效果可以试试AirLLM如果真要日常使用还是GGUF配合层卸载更实际。4. 实测数据与性能对照纸上谈兵没意思直接上实测数据。我记录了三种典型的配置方案涵盖“保速度”“保质量”“保体积”三个方向数字都是同一台机器、同一个模型、同一段提示词下的对比配置方案量化等级GPU层数显存占用内存占用生成速度主观质量方案AQ2_K12层约6.8GB约18GB0.9-1.2 token/s能用偶尔发癫方案BQ3_K_S12层约7.4GB约22GB0.7-1.0 token/s稳定写代码偶尔错方案CQ4_K_M0层全CPU约0.5GB约30GB0.2-0.4 token/s稳但慢到没法用方案A和B之间我更推荐B。虽然Q3的生成速度比Q2慢了一点但模型回答的连续性和逻辑性明显更好。Q2在长回答时会出现前后矛盾、重复废话、甚至突然切换语言的情况这些比慢更影响心情。4.1 为什么内存占用这么高很多人看到内存占用飙到20GB会慌其实这是正常现象。模型权重本身有10GB左右放在内存里另外每生成一个新token都需要把之前的对话历史重新计算一遍KV Cache这部分缓存在CPU侧也要占一定的内存。所以32GB内存是跑35B模型的实际推荐底线小于16GB内存的话即使显存层数放得再少也容易因为系统内存不足而直接卡死。我尝试过把上下文窗口从2048调到4096内存占用立刻又涨了4GB左右显存也涨了1GB多生成速度反而掉得厉害。所以在8GB显存这个场景下长上下文是奢侈品建议日常聊天控制在1024到2048 token之间。这也解释了一个现象8GB机器跑35B适合做“短对话工具”不适合做“文档总结机”。4.2 速度带来的体验问题实测0.9到1.2 token/s是什么体验发问之后要等5到10秒才开始出字出了字之后是一字一字蹦出来的。短问题两三句话还能忍长问题加上对话历史等待时间直接翻倍。这里有个细节本地推理的出字不像网页那样流式平滑它是一段一段吐出来的中间还有明显的卡顿这是因为CPU和GPU之间在来回搬运权重。如果觉得这个速度太痛苦有几个治标不治本的办法降低上下文长度到1024能提速10%到20%。换一个体积更小但同级别的量化版本比如Q2_K_S。关掉其他吃显存的程序给模型留干净环境。如果系统是Windows确认电源模式是“高性能”笔记本插着电源跑。实测下来Windows的“平衡”电源模式会把GPU频率锁到很低的水平生成速度直接对半砍。这个坑特别隐蔽很多人以为是量化问题折腾半天结果只是没插电。5. 常见问题排查实录跑了几天踩过的坑几乎全被踩了一遍。把最有代表性的几个问题整理出来你如果照着做遇到类似情况可以直接对号入座。5.1 一启动就CUDA out of memory这是最常见的报错也是劝退率最高的。核心原因就是放GPU的层数太多了模型权重的总要求超出了8GB显存上限。解决办法先把ngl或OLLAMA_NUM_GPU降到8不行再降。检查是不是同时开着浏览器、直播工具等吃显存的应用关掉再试。换更低的量化版本Q3下不去就Q2。检查模型文件确认没有误下成fp16版本。另外有个容易忽略的问题Ollama默认会把显存预留在模型生命周期内如果你跑完一个模型立刻切另一个可能因为显存碎片化而OOM。重启Ollama进程或者重启系统基本能解决。5.2 GPU占用率几乎为0全是CPU在跑显存没爆但速度慢得无法接受观察任务管理器发现GPU利用率在0%到5%徘徊。这个问题的原因大概率是推理程序没识别到CUDA。排查顺序打开命令行输入nvidia-smi看显卡驱动是否正常、CUDA版本是否够新。检查Ollama是否安装了CUDA版本。有些懒人包只装了CPU版本重装一次带CUDA支持的版本就好。检查是不是核显和独显混淆了。有些笔记本默认把程序丢给Intel UHD Graphics自然跑不动大模型。在设备管理器里禁用核显或者用CUDA_VISIBLE_DEVICES0强制指定独显。5.3 生成到一半突然中断或者报错这个问题通常和上下文窗口有关。当累积的对话内容超过设定窗口长度时llama.cpp系引擎要么截断历史要么直接崩溃。表现是生成了很长的内容后突然报context length exceeded或者生成内容出现无意义的重复循环。办法是按需调整-c参数。想支持长文档总结就把上下文调大代价是显存内存都涨如果只是日常聊天保持2048就够别贪。另外如果发现自己经常手动清空对话历史再继续说明上下文确实不够用了。5.4 NVIDIA驱动和硬件检测那些事这里重点说一下两块内容都是我自己或者周围朋友实测遇到的第一块是驱动模式。Windows下NVIDIA显卡有TCC和WDDM两种驱动模式TCC全称Tesla Compute Cluster主要给数据中心计算卡用跑大模型时够稳够快WDDM则是消费级显卡的标准模式日常和游戏体验更好。消费级笔记本显卡默认就是WDDM不需要折腾。只有那种装了NVIDIA计算卡的主机才需要考虑把TCC改成WDDM来解决显示问题。本地大模型跑在WDDM模式下完全没毛病别被网上那些“必须TCC才专业”的论调带偏。第二块是显卡硬件健康度检测。如果你怀疑显卡本身有问题——比如花屏、显存报错、跑大模型频繁崩驱动——可以试试NVIDIA的MATS工具全称Memory Analysis Tool是官方用于显存颗粒检测的命令行工具。它需要在Linux环境下配合第三方脚本使用不是所有人都有条件折腾。大多数普通用户的“显存问题”其实都是驱动或供电不足重装驱动比跑MATS实在得多。这里给个建议如果rtx 4060笔记本跑大模型中途花屏或黑屏先查电源适配器功率是不是够很多游戏本在满负载下如果供电跟不上显卡就会出各种怪毛病。5.5 双显卡笔记本的调度问题如果你的机器是双显卡笔记本例如同时有Intel UHD Graphics和NVIDIA GeForce RTX 4060 Laptop GPU跑大模型时默认可能落到核显上。解决方法是在NVIDIA控制面板里给Ollama或llama.cpp的exe程序指定“高性能NVIDIA处理器”或者在启动命令前加一行set CUDA_VISIBLE_DEVICES0需要注意的是核显有时会撑起系统桌面显示任务所以不用完全禁用只要让大模型程序强制走独显就行。跑起来之后再观察任务管理器GPU1独显的利用率会明显上涨内存和显存都同步飙升。6. 从“能跑”到“能用”的一点点经验最后的最后说说我对“8GB跑35B”这件事的总体判断和几条实用建议。跑通这件事本身更多是证明了一条可行路径而不是说它就是最佳方案。如果你手头有8GB显存我的建议是如果想体验35B级别模型的能力边界按这篇文章的方案折腾一遍值得。它能让你直观理解量化和卸载的意义。如果是为了实际干活——比如写代码、写文档、做翻译——我劝你退一步用14B或者32B的Q4版本反而体感好得多。如果是为了学习底层原理AirLLM和nano-vllm都值得啃前者教你什么是层卸载后者教你推理框架的关键链路。如果做正式创作或批量推理云GPU实例是更稳妥的选择。本地折腾的意义在于“随时能用、不用付费、私密性好”而不是跟显存对着干。这里分享一个我踩了几次才意识到的小技巧跑大模型之前先手动设好一个后台监控命令比如Windows下的nvidia-smi -l 2每两秒刷新一次显存占用。你会在第几秒看到显存被模型权重吃满第几秒开始有量化的权重被搬运到内存这些瞬间变化比任何教程都直观。真正的显存优化感觉不是靠理论堆出来的而是一帧一帧盯出来的。还有一个我自己常用的经验如果显存差一点塞不下别急着改量化等级先试着把上下文窗口减半。很多时候问题出在KV Cache上权重本身反而占不了那么多。减窗口对质量的影响往往比降量化更小。这次实测的总体结论是8GB显存跑35B模型过程痛苦结果可用但局限性很明显。它适合短视频问答、轻量翻译、离线背资料这类低频、短上下文任务。当你的需求规模超过这个边界时要么换更大的显存要么换小一号的模型——这两个方案都比“硬扛”更优雅。不过话说回来能在8GB的小卡上看到35B模型断断续续吐出人话那一刻还是有点成就感的。至少证明了一件事显存不够从来不是本地大模型的门槛顶多是一道需要绕的弯。 8GB显存如何跑35B大模型？量化加层卸载的完整实测方案
1. 一张8G显卡凭什么敢碰35B模型先给结论8GB显存跑35B级别大模型技术上完全可行但它的定位是“能跑”不是“跑得爽”。我拿手里的RTX 4060 Laptop 8GB实测了几天中途踩遍OOM、CPU满载、上下文断裂这些坑最终在保持基本可用的情况下用Q2量化加上部分层卸载把35B级的模型在本地跑出了稳定出字的效果。这篇实录就把整个过程中最核心的计算逻辑、参数设置、速度表现和避坑记录全部分享出来。我为什么非要跟8GB显存较劲因为这是目前消费级笔记本和台式机的“主流配置”身边太多人买了4060/3060/笔记本4060结果一看到模型下载页面写着“XXB参数”第一反应就是“我这显卡是不是废了”。其实显卡不是废了是思路没换过来。本地部署大模型拼的不只是显存这一个指标内存带宽、量化方案、模型卸载策略、上下文窗口设定这些因素加在一起才是“能不能跑”的最终答案。再说一个容易被忽略的事实市面上真正叫“35B”的开源模型并不多大家日常说的“35B”其实是一个习惯性称呼覆盖了30B到35B这一档比如Qwen2.5-32B、Yi-34B、CodeLlama-34B都属于这个量级。下面的实操都以这一档模型为例。1.1 先算一笔显存账35B模型到底有多大要理解8GB到底为什么“看似不可能”得先把账算明白。模型权重在显存里占多大地方取决于两个参数参数量和权重精度。以35B级别模型为例FP16精度16位浮点每个参数占2个字节总重量约70GB。INT8量化每个参数占1个字节重量约35GB。INT4量化每个参数约0.5字节重量约17.5GB。2bit量化Q2系列每个参数约0.25到0.3字节重量大约9GB到11GB。所以默认下载的FP16版本8GB显存连零头都塞不下。哪怕做到INT417.5GB依然是天文数字。到这基本可以确定一件事纯靠显存硬扛8GB永远没戏。那为什么还有“8GB跑35B”这种说法因为推理计算并不要求整个模型全部躺在显存里。这就要引入两个关键词了量化砍体积、卸载借内存。1.2 量化活命卸载续命快慢全看带宽量化是把模型权重的精度降下来说白了就是“用一些精度换体积”。Q2_K系列能把35B模型压到10GB上下Q3_K系列则要12GB到14GBQ4_K就要15GB到17GB了。光看数据即使Q2_K已经接近10GB8GB显存还是差一点。这时候就要用到第二个手段层卸载。层卸载的原理说起来很简单一个Transformer大模型由几十层重复结构堆叠而成推理的时候一层算完才会算下一层不是所有层同时参与计算。所以可以把一部分层“放”在内存里计算到那一层时再从内存搬运到显存算完又腾出来。这个思路打个比方显存是厨房台面内存是冰箱。台面小放不下全部食材没关系炒哪个菜就从冰箱里拿哪个菜只是拿菜这个过程会耽误时间。基于这个原理有两类本地推理工具值得关注llama.cpp系列包括Ollama、LM Studio支持GGUF格式的量化模型通过ngl/num_gpu参数控制放进GPU的层数放不下的层跑在CPU内存里。AirLLM专门做“权重重于显存”的方案把整个模型按层组织在内存中每次计算时把需要的那几层权重复制到显存算完立刻释放。它的优点是几乎不挑显存大小4GB显卡也能跑70B模型缺点是慢因为没有做层并行权重搬运开销非常明显。如果也想看看这些工具背后是怎么实现的有一个叫nano-vllm的项目值得翻翻它是vLLM的精简教学版把推理框架的关键模块拆得很干净适合想搞懂“卸载、量化、KV Cache到底在做什么”的人。2. 工具选型别一上来就下PyTorch版全集很多第一次接触本地大模型的人最容易犯的错是直接去HuggingFace下载模型的safetensors权重文件然后试图用transformers库在本地跑起来。这个路线对8GB显存来说几乎是灾难。因为原生PyTorch推理不会自动帮你做层卸载默认要把整个模型权重一次性载入GPU内存35B的FP16版本直接把显存爆掉连报错的机会都不给。所以我强烈建议跑本地模型直接走GGUF路线别碰原生权重。GGUF是llama.cpp项目专门设计的格式把量化权重、分词器、模型超参数打包成单个文件配合llama.cpp运行时才能实现“显存装不下的部分自动放内存”这种操作。2.1 主流本地推理框架横向对比我实测过几个方案它们各自的定位差异用表格看最清楚工具底层引擎显存要求上手难度适合场景Ollamallama.cpp可调低单命令跑极低快速体验、日常聊天、API调用llama.cppllama.cpp可调低参数细致中等深度调参、逐参数控制LM Studiollama.cpp可调低界面友好低不想写命令的桌面用户AirLLM自定义卸载逻辑极低4G也能跑中小显存想试超大模型vLLM高性能服务引擎高适合多并发高服务生产环境消费卡慎入Ollama是目前我个人最推荐新手起步的方案。它把“下载模型、量化选择、GPU层数配置、上下文窗口设置”都包成了简单的命令默认情况下会自动检测显存并决定放几层进GPU对8GB用户来说这种“自动兜底”反而避免了一堆手动调参的折磨。llama.cpp则是进阶玩家的选择。它允许你通过-ngl参数精确控制放进GPU的层数是10层还是12层差别都在帧级。如果你愿意折腾还可以自己编译带特定优化指令集的版本再把CUDA加速开关打开实测比预编译版本快一些。顺带说一嘴驱动的坑。如果你在Windows笔记本上装的是NVIDIA驱动系统里可能同时存在核显和独显跑模型前先用nvidia-smi确认程序确实落在独显上。如果是那种NVIDIA计算卡专用的TCC模式和游戏显卡常用的WDDM模式之间本地推理用WDDM就行TCC模式主要面向数据中心场景普通玩家不必纠结。另外如果显卡出现花屏、显存报错之类的硬件问题可以试试NVIDIA的MATS显存检测工具不过这套东西对普通用户偏硬核我后面会详细说。2.2 量化版本怎么选Q2、Q3还是Q4选量化版本是8GB显存能否跑35B的决定性一环。我的实测结论是Q2_K2bit量化左右35B压到10GB上下配合12层左右的卸载8GB显存勉强起步。Q3_K_S3bit量化体积约12GB需要卸载更多层速度进一步下降。Q4_K_M4bit量化体积约15GB8GB显存基本只能全CPU跑速度跌到无法接受。这里存在一个关键矛盾量化的比特数越低模型智力损伤越大。Q2_K在简单的翻译、摘要、结构化输出上还能看但一遇到复杂推理、长文本归纳、代码debug就明显“脑子不够用”。Q3是质量与性能的妥协点可以接受偶尔的胡说八道。Q4质量最好但显存装不下是硬伤。所以别迷信“跑35B就一定要上最好的量化”。本地部署的第一原则是先保证模型放得下、有速度再谈质量。为“能跑”牺牲一点智商在8GB这个级别是不可避免的。如果你日常需要写代码、做数学题我反而建议退一步跑14B或者32B的Q4版本体验比硬跑35B的Q2舒服很多。2.3 模型下载渠道与文件校验GGUF格式的模型文件主要两个地方下载HuggingFace和国内做得很快的ModelScope。HuggingFace上搜索模型名 GGUF就能看到量化版本列表通常一个模型会有Q2_K、Q3_K_S、Q4_K_M、Q5_K_M、Q8_0这些变体文件名里都会标注清楚。下载时注意三点看文件名里的量化等级别下成fp16或者bf16版本体积直接翻好几倍。把GGUF文件放到SSD上第一次加载模型要读取好几个GB的文件机械硬盘加载35B模型的等待时间足够你去泡杯咖啡。下载完成后最好做个sha256校验有些镜像站会传坏文件跑起来会直接报不认识的错误排查起来极其折磨。3. 完整实操8GB跑35B的详细过程下面进入正题。我的测试环境是RTX 4060 Laptop GPU 8GB版i7-13620H处理器32GB内存Windows 11系统。这套配置很有代表性如果你是台式机的RTX 4060或者3060 12G结果只会比这个更好。先说目标我这次跑35B模型不是为了写论文、做推理就是希望实现三件小事离线聊天、写简单脚本、做长文档总结。对这个目标来说速度慢一点没关系关键是能顺利跑起来并且不频繁崩溃。3.1 用Ollama从零开始跑通Ollama安装好之后它默认从自带库拉取模型。我这次跑的是Qwen2.5-32B的Q2量化版命令如下ollama run qwen2.5:32b-q2_K这一步会先检查本地有没有这个模型文件没有就自动下载。下载完之后Ollama会尝试自动把模型塞进显存。问题在于8GB显存塞不下Q2量化后的完整模型如果直接run大概率会得到CUDA out of memory的报错或者模型把所有层放在CPU上跑速度慢到像老式拨号上网。要控制放入显存的层数需要用环境变量OLLAMA_NUM_GPU指定。Windows命令行里这样做set OLLAMA_NUM_GPU12 ollama run qwen2.5:32b-q2_KOLLAMA_NUM_GPU12表示把模型的前12层放进显存其余层留在内存。这个数字不是拍脑袋定的我试过几组值放12到14层时显存占用大概在7GB上下很稳放到18层以上就偶尔会OOM。第一次跑完看清楚显存占用再决定是往上加还是往下减。上下文窗口也直接影响显存占用。默认情况下Ollama会给一个较短的上下文跑大模型时我自己手动限制到2048 token。怎么理解token可以简单理解成字词的切分单位中文一两个字就是一个token2048 token差不多能支持2000字左右的中文对话日常聊天够用了。Ollama跑起来之后观察一个细节如果首字等待时间极长而且生成过程中显存占用始终不掉说明模型层卸载策略不合理。正常状态下生成第一个token的时候显存会有一个明显的峰值波动之后进入稳定期。如果是全CPU跑显存占用几乎为0GPU利用率也接近0但内存占用会涨到20GB以上。3.2 用llama.cpp精确控制层数如果你想要更细致的控制可以直接用llama.cpp。预编译的Windows版本在GitHub的Release页面可以下载把文件放到一个目录然后在命令行里跑llama-cli.exe -m qwen2.5-32b-q2_k.gguf -ngl 12 -c 2048 -p 你好请介绍一下自己这里的-ngl 12和Ollama的OLLAMA_NUM_GPU12是一个意思就是“放12层到GPU”。-c 2048则是上下文长度把它设置成一个保守值可以显著降低显存和内存压力。-p输入的是你要让模型生成的首句话。实测中ngl参数从0调到14生成速度是阶梯式变化的ngl 0全部CPU速度大约0.3到0.5 token每秒每个字要等两三秒基本不可用。ngl 8速度大约0.6到0.9 token每秒开始有可用性。ngl 12速度大约0.9到1.2 token每秒这是我能接受的最低可用档位。ngl 14速度可能到1.5 token每秒左右但如果同时开长上下文显存就会顶不住。什么是token每秒可以简单理解为每秒生成多少个“语言片段”中文大概一个字对应一两个token。1 token/s意味着生成一个20字左右的短句大约要等20到30秒体感上确实很慢但装杯效果拉满毕竟是8GB在跑35B。3.3 不做量化的另一条路AirLLM如果你不想用GGUF或者想跑一个非量化版本的大模型AirLLM提供了另一种思路。它的核心设计是模型权重全部驻留在内存推理时按层动态搬运到GPU显存计算。安装方式很简单pip install airllm调用方式和transformers很像from airllm import AirLLMLlama2 model AirLLMLlama2(/path/to/model) print(model.generate(介绍一下你自己))AirLLM最大的优势是精度不用量化理论上是“满血版”模型。但代价就是慢。它相当于每次算一层都要把权重从内存搬到显存内存带宽再高也比不上显存自身的带宽实测下来速度只有0.3到0.5 token每秒而且内存占用极其夸张。我的建议是如果只是为了验证某个模型效果可以试试AirLLM如果真要日常使用还是GGUF配合层卸载更实际。4. 实测数据与性能对照纸上谈兵没意思直接上实测数据。我记录了三种典型的配置方案涵盖“保速度”“保质量”“保体积”三个方向数字都是同一台机器、同一个模型、同一段提示词下的对比配置方案量化等级GPU层数显存占用内存占用生成速度主观质量方案AQ2_K12层约6.8GB约18GB0.9-1.2 token/s能用偶尔发癫方案BQ3_K_S12层约7.4GB约22GB0.7-1.0 token/s稳定写代码偶尔错方案CQ4_K_M0层全CPU约0.5GB约30GB0.2-0.4 token/s稳但慢到没法用方案A和B之间我更推荐B。虽然Q3的生成速度比Q2慢了一点但模型回答的连续性和逻辑性明显更好。Q2在长回答时会出现前后矛盾、重复废话、甚至突然切换语言的情况这些比慢更影响心情。4.1 为什么内存占用这么高很多人看到内存占用飙到20GB会慌其实这是正常现象。模型权重本身有10GB左右放在内存里另外每生成一个新token都需要把之前的对话历史重新计算一遍KV Cache这部分缓存在CPU侧也要占一定的内存。所以32GB内存是跑35B模型的实际推荐底线小于16GB内存的话即使显存层数放得再少也容易因为系统内存不足而直接卡死。我尝试过把上下文窗口从2048调到4096内存占用立刻又涨了4GB左右显存也涨了1GB多生成速度反而掉得厉害。所以在8GB显存这个场景下长上下文是奢侈品建议日常聊天控制在1024到2048 token之间。这也解释了一个现象8GB机器跑35B适合做“短对话工具”不适合做“文档总结机”。4.2 速度带来的体验问题实测0.9到1.2 token/s是什么体验发问之后要等5到10秒才开始出字出了字之后是一字一字蹦出来的。短问题两三句话还能忍长问题加上对话历史等待时间直接翻倍。这里有个细节本地推理的出字不像网页那样流式平滑它是一段一段吐出来的中间还有明显的卡顿这是因为CPU和GPU之间在来回搬运权重。如果觉得这个速度太痛苦有几个治标不治本的办法降低上下文长度到1024能提速10%到20%。换一个体积更小但同级别的量化版本比如Q2_K_S。关掉其他吃显存的程序给模型留干净环境。如果系统是Windows确认电源模式是“高性能”笔记本插着电源跑。实测下来Windows的“平衡”电源模式会把GPU频率锁到很低的水平生成速度直接对半砍。这个坑特别隐蔽很多人以为是量化问题折腾半天结果只是没插电。5. 常见问题排查实录跑了几天踩过的坑几乎全被踩了一遍。把最有代表性的几个问题整理出来你如果照着做遇到类似情况可以直接对号入座。5.1 一启动就CUDA out of memory这是最常见的报错也是劝退率最高的。核心原因就是放GPU的层数太多了模型权重的总要求超出了8GB显存上限。解决办法先把ngl或OLLAMA_NUM_GPU降到8不行再降。检查是不是同时开着浏览器、直播工具等吃显存的应用关掉再试。换更低的量化版本Q3下不去就Q2。检查模型文件确认没有误下成fp16版本。另外有个容易忽略的问题Ollama默认会把显存预留在模型生命周期内如果你跑完一个模型立刻切另一个可能因为显存碎片化而OOM。重启Ollama进程或者重启系统基本能解决。5.2 GPU占用率几乎为0全是CPU在跑显存没爆但速度慢得无法接受观察任务管理器发现GPU利用率在0%到5%徘徊。这个问题的原因大概率是推理程序没识别到CUDA。排查顺序打开命令行输入nvidia-smi看显卡驱动是否正常、CUDA版本是否够新。检查Ollama是否安装了CUDA版本。有些懒人包只装了CPU版本重装一次带CUDA支持的版本就好。检查是不是核显和独显混淆了。有些笔记本默认把程序丢给Intel UHD Graphics自然跑不动大模型。在设备管理器里禁用核显或者用CUDA_VISIBLE_DEVICES0强制指定独显。5.3 生成到一半突然中断或者报错这个问题通常和上下文窗口有关。当累积的对话内容超过设定窗口长度时llama.cpp系引擎要么截断历史要么直接崩溃。表现是生成了很长的内容后突然报context length exceeded或者生成内容出现无意义的重复循环。办法是按需调整-c参数。想支持长文档总结就把上下文调大代价是显存内存都涨如果只是日常聊天保持2048就够别贪。另外如果发现自己经常手动清空对话历史再继续说明上下文确实不够用了。5.4 NVIDIA驱动和硬件检测那些事这里重点说一下两块内容都是我自己或者周围朋友实测遇到的第一块是驱动模式。Windows下NVIDIA显卡有TCC和WDDM两种驱动模式TCC全称Tesla Compute Cluster主要给数据中心计算卡用跑大模型时够稳够快WDDM则是消费级显卡的标准模式日常和游戏体验更好。消费级笔记本显卡默认就是WDDM不需要折腾。只有那种装了NVIDIA计算卡的主机才需要考虑把TCC改成WDDM来解决显示问题。本地大模型跑在WDDM模式下完全没毛病别被网上那些“必须TCC才专业”的论调带偏。第二块是显卡硬件健康度检测。如果你怀疑显卡本身有问题——比如花屏、显存报错、跑大模型频繁崩驱动——可以试试NVIDIA的MATS工具全称Memory Analysis Tool是官方用于显存颗粒检测的命令行工具。它需要在Linux环境下配合第三方脚本使用不是所有人都有条件折腾。大多数普通用户的“显存问题”其实都是驱动或供电不足重装驱动比跑MATS实在得多。这里给个建议如果rtx 4060笔记本跑大模型中途花屏或黑屏先查电源适配器功率是不是够很多游戏本在满负载下如果供电跟不上显卡就会出各种怪毛病。5.5 双显卡笔记本的调度问题如果你的机器是双显卡笔记本例如同时有Intel UHD Graphics和NVIDIA GeForce RTX 4060 Laptop GPU跑大模型时默认可能落到核显上。解决方法是在NVIDIA控制面板里给Ollama或llama.cpp的exe程序指定“高性能NVIDIA处理器”或者在启动命令前加一行set CUDA_VISIBLE_DEVICES0需要注意的是核显有时会撑起系统桌面显示任务所以不用完全禁用只要让大模型程序强制走独显就行。跑起来之后再观察任务管理器GPU1独显的利用率会明显上涨内存和显存都同步飙升。6. 从“能跑”到“能用”的一点点经验最后的最后说说我对“8GB跑35B”这件事的总体判断和几条实用建议。跑通这件事本身更多是证明了一条可行路径而不是说它就是最佳方案。如果你手头有8GB显存我的建议是如果想体验35B级别模型的能力边界按这篇文章的方案折腾一遍值得。它能让你直观理解量化和卸载的意义。如果是为了实际干活——比如写代码、写文档、做翻译——我劝你退一步用14B或者32B的Q4版本反而体感好得多。如果是为了学习底层原理AirLLM和nano-vllm都值得啃前者教你什么是层卸载后者教你推理框架的关键链路。如果做正式创作或批量推理云GPU实例是更稳妥的选择。本地折腾的意义在于“随时能用、不用付费、私密性好”而不是跟显存对着干。这里分享一个我踩了几次才意识到的小技巧跑大模型之前先手动设好一个后台监控命令比如Windows下的nvidia-smi -l 2每两秒刷新一次显存占用。你会在第几秒看到显存被模型权重吃满第几秒开始有量化的权重被搬运到内存这些瞬间变化比任何教程都直观。真正的显存优化感觉不是靠理论堆出来的而是一帧一帧盯出来的。还有一个我自己常用的经验如果显存差一点塞不下别急着改量化等级先试着把上下文窗口减半。很多时候问题出在KV Cache上权重本身反而占不了那么多。减窗口对质量的影响往往比降量化更小。这次实测的总体结论是8GB显存跑35B模型过程痛苦结果可用但局限性很明显。它适合短视频问答、轻量翻译、离线背资料这类低频、短上下文任务。当你的需求规模超过这个边界时要么换更大的显存要么换小一号的模型——这两个方案都比“硬扛”更优雅。不过话说回来能在8GB的小卡上看到35B模型断断续续吐出人话那一刻还是有点成就感的。至少证明了一件事显存不够从来不是本地大模型的门槛顶多是一道需要绕的弯。