“8GB 跑 35B”说真的第一眼看到这种标题大多数人脑子里蹦出来的词是“标题党”。玩大模型的都清楚35B 参数光权重文件在 FP16 精度下就要占 70GB 空间你一张 8GB 显存的消费级显卡连零头都塞不下怎么跑但话不能说得太死我手上正好有张吃灰的 8GB 老卡被这个说法勾得心痒痒折腾了两个晚上真把它跑起来了。虽然速度堪比“老奶奶拄拐杖”但整个过程中踩过的坑、理清的原理、调参的心得我觉得比单纯看评测文章有价值得多。这篇就来写一份完整实录把你关心的量化、显存分配、CPU 卸载、日常踩坑一次讲透。别指望它能带你飞但绝对能让你知道 8GB 显存在本地大模型这个局里到底能硬撑到什么程度。1. 先别急着下单8GB 显存跑 35B 的底层逻辑1.1 显存不够量化来凑在聊实操之前得先解决一个认知问题为什么 8GB 显存能加载一个 35B 的模型这里面的关键不是魔法而是量化。大模型在训练和正常推理时通常用 FP16 或 BF16 精度存储权重一个权重参数占 2 字节。35B 参数的 FP16 模型换算下来就是 35×270GB这还没算中间激活值。所以常规思维下想本地跑 35B 至少得 80GB 显存那就是专业卡或双卡交火的领域了。但量化收割的就是这一步空间。把每个权重从 16bit 压缩到 4bit理论上参数体积直接除以 470GB 缩到 17.5GB 左右。如果再用 Q3_K_M 这样的激进量化还能再压一截8GB 显存虽然依然不够装下全部但剩下的可以“借”到内存里。对你没看错显存不够内存来凑。更具体一些现代推理框架llama.cpp、Ollama 底层也是这个支持 GPU CPU 混合推理。模型是一个多层结构你可以指定前 N 层放在显卡上算剩下的层放在系统内存里用 CPU 算。显卡计算极快CPU 算得慢但胜在内存容量大。所以“8GB 跑 35B” 量化后的模型约 15-20GB 8GB 显存装一部分层 12GB 甚至更多内存装剩下的层。这样拼拼凑凑一个 35B 模型还真能被拉起来。1.2 为什么说这是方案里的最优解看到这里你可能不服既然要借内存那干脆纯 CPU 推理不就行了吗CPU 的内存多大都行还不限量。说对了一半纯 CPU 推理确实能跑34B 的模型用 Q4 量化配一个 64GB 内存的电脑速度大约每秒 1-2 个 token如果你能接受泡杯茶回来看它蹦一个字也可以。但实测下来只要有哪怕 8GB 的显存把几十层网络放在 GPU 上推理速度就能提升到每秒 4-8 token提升是肉眼可见的。所以这 8GB 显存不是装饰它才是跑 35B 模型的“加速钥匙”。另一个原因在于成本。专业显卡万把块起步40GB 显存的卡二手也得三四千而一张二手 8GB 显卡几百块随便淘。对于大多数只想在本地体验大模型、不想花钱租云 GPU 的用户来说流出一小部分 CPU 内存利用手头已有的入门卡整个方案零新增成本。即便你是刚入门的新手也完全没必要为了跑一个 35B 模型去折腾昂贵硬件先理解这套思路以后升级显卡时你还会感激这段踩坑经历。2. 环境准备与工具选型2.1 硬件与软件清单我先交代一下我这台机器的配置方便你对号入座CPUi5-104006 核 12 线程性能约等于中端水平内存32GB DDR4 3200MHz注意内存性能对 CPU 推理速度影响很大显卡RTX 2060 8GB显存带宽和算力在消费级显卡里算普通水平系统Windows 11 22H2这套配置很典型没有新显卡没有超频内存也没有专用 AI 主机。如果你用的是 1660 Super 或 3050 8GB体验差距不大。核心重点是内存容量建议至少 16GB最好 32GB因为 35B 的 Q4 模型本身就要占掉 18GB 左右内存加上系统和其他软件32GB 才不至于紧张。软件这边我用的是 Ollama Windows 11 直接安装省去了大量手动配置。Ollama 主打零门槛一键装好命令行直接拉模型。相比之下直接裸用 llama.cpp 虽然也能达到同样效果但你需要自己准备编译好的 exe、模型文件、前后端脚本对新手不太友好。我这篇实践先讲 Ollama后面进阶部分再提底层参数对应关系。2.2 为什么选择 Ollama 而不是裸用 llama.cpp很多人看网上教程觉得 Ollama 就是个傻瓜式封装没技术含量。但对我来说Ollama 的价值在于三点第一自动处理依赖。NVIDIA 驱动、CUDA 库、计算库之类的环境Ollama 会在安装时自动匹配不会出现编译报错、链接失败这类劝退问题。你只需要保证显卡驱动是新的。第二模型仓库一键拉取。官方库里已经帮大家把主流开源模型做成了多种量化版本用一条ollama pull命令就能下载文件名上直接标注了 Q4_K_M、Q5_K_M 等量化等级不用自己拿导出工具从 HuggingFace 转格式。第三提供 OpenAI 兼容 API。这是个大杀器。Ollama 启动后会默认监听 11434 端口对外暴露一个格式和 OpenAI 几乎一致的 API。也就是说本地跑完模型后任何支持接入自定义 API 地址的应用Dify、ChatGPT 的本地替代客户端、某些自动化脚本都能把请求转发给它。这等于把你本地模型变成了一个私有 AI 服务。当然Ollama 也不是全无毛病。它的默认参数有时会为了通用性牺牲性能比如默认只给一半层放到 GPU这就需要你去调它的 Modelfile 或配合环境变量来手动改但这恰好是这篇文章要帮你解决的问题。2.3 模型的量化版本怎么选命令行里拉模型时量化的选择非常关键。拿千问Qwen来说它提供 32B 这个接近 35B 的参数规模你会在 Ollama 库里看到类似qwen2.5:32b-instruct-q4_K_M、qwen2.5:32b-instruct-q3_K_M这样的 tag。怎么选我结合实测给你一个参考Q4_K_M最稳妥的起始点模型体积约 19GB显存和内存压力适中智商保持得不错一秒能出 4-6 个 token。我强烈建议先从这个版本开始跑。Q3_K_M体积压缩到约 15GB刚好能为你多空出一点 CPU 内存速度会略微快一些但生成质量下降能明显感觉到适合那些内存只有 16GB 的机器强行试一把。Q5_K_M体积约 24GB对内存要求更高而且 GPU 吃掉 8GB 后剩余的 16GB 会直接怼在内存里如果内存不够会频繁交换导致卡顿我不推荐新手用。还有一个隐藏参数叫“上下文长度”别小看它你下载模型时不指定Ollama 会默认只给 2048 或 4096 token 的上下文窗口这也意味着对话一长就开始“失忆”。要在模型里同时限制内存占用又想提高生成质量得学会在 Modelfile 里配置num_ctx参数。这个后文会有更细致的说明。3. 完整实操从下载到跑起来3.1 安装部署与镜像拉取我自己是在 Windows 11 上操作的整体流程走一遍也就十几分钟。先是到 Ollama 官网下载 Windows 安装包安装过程没什么可选择交叉路口一路 Next。装完后终端会自动多出ollama命令。接着拉模型。注意在拉取之前建议先看看自己的内存是不是足够。我的机器是 32GB直接上了qwen2.5:32b-instruct-q4_K_M。命令就是ollama pull qwen2.5:32b-instruct-q4_K_M下载过程很漫长毕竟 19GB 的模型文件取决于你的网速。下载完成后无论你用幂等接口测试也好直接ollama run也罢其实都能跑。但直接跑的话Ollama 会按默认参数把一半的层放在 GPU另一半丢 CPU两个硬件都不满也没优化速度未必理想。我第一次就是这样跑起来的只有大概 3 token/s那种感觉真的很磨人。所以接下来要讲讲关键的负载分配调优。3.2 GPU 和 CPU 的负载分配参数Ollama 给 8GB 显卡默认分配的 GPU 层数并不是根据模型的量化体积算出来的最优解。为了尽量保证各种电脑小白不会刚开始就跑不了它会预留不少显存缓冲区。对我们这种想把性能榨干的人来说就得手写 Modelfile 去覆盖这个默认值。操作步骤是这样的先创建一个 Modelfile 文件写入模型基础参数。在文件里指定num_gpu为固定值或百分比。用ollama create把自定义模型加载进 Ollama 的名录里。写一个适合 35B 量化模型的 Modelfile FROM qwen2.5:32b-instruct-q4_K_M PARAMETER num_gpu 18 PARAMETER num_ctx 4096 PARAMETER temperature 0.7其中num_gpu的含义是把模型的前 18 层网络结构加载到 GPU 显存其余的层交给 CPU。那么问题来了18 这个数字是怎么定的可以参考这个思路显存 8GB量化后的模型每层大约占用 0.3-0.4GB 显存18 层大概吃掉 6-7GB剩下的显存要给对话中间产生的 key-value cacheKV 缓存留一点余量。如果num_gpu设太大例如设成 20推理时极容易直接爆显存报错又要重启服务得不偿失。num_ctx是上下文长度我设为 4096这是考虑内存占用后的折中。32B Q4 模型的 KV cache 本身就会随着 context 增大而增大每增加 1024 token 大约占用 500MB 内存。4096 意味着系统内存要给 KV 缓存留约 2GB 余量配合 19GB 模型权重32GB 内存才能比较轻松地扛住。如果内存大且不在乎读得慢可以直接提升到 8192不过速度下降会更明显。调完参数后运行ollama create qwen32b-local -f Modelfile ollama run qwen32b-local记住你输入的是ollama run qwen32b-local而不是原来的官方模型名这样才能让 Ollama 读取到我们自定义的参数配置。如果后面觉得速度不满意可以重复修改 Modelfile 中的num_gpu但每次修改都需要重新ollama create一次想用热更新是不行的。3.3 首次运行实录与性能数据我最后一次调优后的实际运行效果是这样GPU 负载约 88%显存占用 7.2GB接近极限但没爆。CPU 负载6 个物理核全部打满内存占用 23GB模型 KV 系统本身。平均生成速度1.6 token/s 到 6.2 token/s 之间波动简单短句大概 4-5 token/s遇到复杂推理会掉到 1-2 token/s。首次生成前有一个肉眼可见的“长时间思考”其实是 CPU 和 GPU 之间数据来回搬运大概 5-10 秒延迟。我知道你看到这个数据会想哦这还能用吗说实话日常用它写代码、做一些长文档确实急人但如果只是拿来偶尔提问、验证某个提示词的效果甚至做一些本地离线数据清洗这个速度是能忍的。而且我的 CPU 只是 i5-10400如果换成带 AVX-512 的 Intel Core Ultra 或性能更强的 AMD Ryzen 7000 系列CPU 推理部分还能快一半以上。另外一个很重要的点生成速度特别受回答长度影响。让 35B 模型长篇大论地写文章你能看到它以龟速输出 500 字中间如果去泡杯茶回来也就输出到一半。但如果只是让它回答“用 Python 写一个快速排序并解释时间复杂度”回答约 200 字整个过程 1 分钟之内能结束体验是完全可以接受的。4. 踩坑实录那些文档里不会写的坑4.1 速度慢到怀疑人生先调这几个参数如果你按我上面的流程跑完发现速度还是 0.8 token/s那问题大概率不出在显卡负载而是另外两个容易被忽略的地方第一内存通道数。CPU 推理非常依赖内存带宽如果你只有一根 DDR4 内存条速度会被腰斩有两条组双通道则会好一倍。跑 35B 这种大模型内存瓶颈比 CPU 算力更致命。如果条件允许请务必让内存运行在双通道模式下。第二电源管理模式。Windows 11 默认的“平衡”电源计划会限制 CPU 频率尤其在 CPU 和 GPU 同时高负载时系统会自动降压降频。我在试跑时一度速度低到 1 token/s后来发现 CPU 频率只有 3.2GHz怎么都不见上去。切到“高性能”电源计划后频率拉到 4.4GHz速度直接翻倍。所以别在这个细节上因为心疼电费而牺牲验证时间。第三是否被后台程序抢占资源。Windows 的 Defender 实时扫描、Windows Update 后台下载、甚至浏览器开着几页大页面都会抢占 CPU 线程。干扰模型推理。跑之前最好把不用的浏览器标签全关掉给模型让路。4.2 显存占用越跑越高怎么办我在第一个晚上被“CUDA out of memory”折磨得差点放弃。原因其实很好笑我把num_ctx设成了 8192但没意识到 KV cache 会随着对话轮数增加而膨胀。当你连续对话超过 20 轮后之前的 key-value 向量还留在缓存里显存占用自然不断往上升最终冲破 8GB 上限报错。解决方案有两个一是把num_ctx调小。若日常只是简单问答2048 其实足够用模型给它多少上下文它输出的质量并不会有大幅损失。二是给 Ollama 设置显存占用上限。在 Ollama 服务的环境变量里设置set OLLAMA_MAX_LOADED_MODELS1 set OLLAMA_NUM_GPU999OLLAMA_NUM_GPU999看起来像是“全上 GPU”其实是让 Ollama 自动以尽量多的显存来加载模型并允许使用内存做交换。若你真想限制显存使用需要自己创建 Modelfile 中的num_gpu来调节这两种方式可以叠加使用。还有一个技巧每隔一段对话后重启一次 Ollama 服务ollama serve强制清理 KV 缓存这是最土但也最有效的方法。4.3 中文输出乱码与对话格式问题另一个非常直接的坑是模型一旦在 CPU GPU 混合模式下跑偶尔会出现中文变成一堆“锟斤拷”或者回答带很怪异的符号。这个问题归结起来有两个根源第一下载的量化 CG 版本本身不包含中文词表优化。用 Qwen 这种原生中文模型时概率较低但如果拿 Llama 类模型做底子那中文乱码就是家常便饭。解决办法是把模型切回qwen2.5:32b-instruct-q4_K_M或其他中文表现好的模型别跟英文模型较劲。第二模型输入模板不匹配。Ollama 默认会使用模型自带的提示模板但如果你通过 API 接入外部应用比如 Dify应用可能会按照自己的格式拼 prompt导致模型理解不了角色设定回答质量下降。我的经验是在外部应用侧尽量使用“系统提示词”并写清楚模型的角色避免在用户消息里堆叠过多格式说明。另外关闭应用的“自动添加时间戳”功能这类无意义前缀经常把模型带偏。5. 进阶玩法接入 Dify 与去掉限制5.1 通过 OpenAI 兼容接口喂给 Dify只跑一个交互式命令行对有些人来说还不够爽。比如你想做一个私有知识库或者企业内部某个工具的自助问答助手那必然会想把本地模型接入到 Dify 这种编排平台里。操作其实很简单Dify 支持自定义远程模型你只需要在设置中填上模型提供商为“OpenAI API”然后把 API 地址改成http://localhost:11434/v1再填上一个任意的 API KeyOllama 默认不校验随便写个ollama就能过接着填模型名称注意一定要填你通过 Modelfile 自定义出来的模型名比如qwen32b-local。保存后Dify 就可以直接把这个本地模型当成底层大语言模型来用了。接入之后你还会发现另一个好处Dify 里的知识库问答、工作流编排都能复用这一套场景不用再傻兮兮地每次手敲对话。模型速度虽然慢但胜在私有化数据不出本机特别适合企业内部处理敏感文档的场景。5.2 去掉上下文和并发限制“ai 本地大模型 去掉限制”这个关键词其实指的就是两类限制上下文长度限制和并发访问限制。上下文长度限制好办方法我都试过——在 Modelfile 里设置更大的num_ctx即可。但记住一个简单的公式模型体积 KV 缓存不要超过内存总量。如果你要提高上下文长度就必须降低模型量化等级或减小num_gpu让显存宽裕一点从而把 KV 缓存转移到系统内存。我个人感觉 4096 是一个甜点值再往上走产生的回退效应太明显。并发限制的话Ollama 默认支持并发请求但如果你的显卡只有 8GB并发数太高会导致显存溢出或推理排队严重。实测下来 1-2 个并发是极限更多并发只能是排队。如果你确实需要同时服务多个人或者用企业级 API 的请求量跑建议把 Ollama 装在一台内存更大、显卡更好的服务器上或者直接考虑使用云 GPU而不是继续压榨这张小卡。5.3 企业落地时的运维成本预期写到这里有不少朋友问我如果公司想搭一套本地大模型花二三十万买硬件会有多大运维工作量我的真实体会是跟“买回来就能用”之间的距离比你想象中远。首先要解决的就是供电和散热一台 4 卡服务器日常功率上千瓦机柜你得单独配。其次依赖工程CUDA 升级一次可能会让所有模型重新适配。模型更新很快今天你部署的模型过三个月就有新版你要不要更新更新后效果差异如何这些问题没人能替你做决定。还有数据管理本地模型只是推理引擎你需要配套知识库、权限控制、审计日志这些加起来运维工作量绝对不是一个普通 IT 岗兼职能扛住的。简单说如果只是几个人测试用8GB 消费卡能凑合如果真要做生产请预留专门的 AI 运维人力。我的最终体会实践告诉我8GB 显存跑 35B不是不能跑而是要看你能不能接受“慢工出细活”。它把原来遥不可及的大模型门槛一下子拉到了几百块显卡 32GB 内存的平民价位这本身就是件很有意思的事。如果你是想低成本体验、学习、做原型验证这个方案挺值的但如果要拿它代替云端 GPT那建议趁早换方案。走完这一趟最大的收获其实是理解了量化、显存、KV 缓存、CPU/GPU 混合推理这些概念以后再看到各种“7B 手机跑”“13B 老显卡跑”的标题自己心里就有了一把尺。先折腾起来吧很多事真的试了才知道边界在哪里。最后分享一个细节技巧如果你跟我一样一次只想快速跑一小段提示词不想每次等入 OLLAMA 前戏加载模型可以在启动后连续输入几个问题Ollama 会保持模型常驻第二次提问的加载时间会明显缩短。跑完切换模型时记得用ollama stop qwen32b-local显式释放显存不然下一个模型可能因显存残留加载失败。这就是我踩过坑后最想提醒你的两个小操作。