8GB显存跑35B模型，这句话放在三年前说出去，多半会被当成吹牛。那时候本地部署大模型的主流思路是“装得下才跑得动”，显存不够直接出局，更别提8GB这种消费级甜品卡的容量了。可这两年量化技术和推理框架成熟之后，一台普通游戏电脑干这件事已经不再是天方夜谭，我自己就在一张RTX 4060 8GB上跑通了Qwen2.5-32B和GLM-4-32B这类大参数模型，体验虽然谈不上丝滑，但真的能用。

这篇文章不谈云服务器、不聊企业级A100，只围绕“消费级显卡本地大模型实测”这件事，把8GB显存跑35B模型的原理、工具、实测数据、踩坑经历和后续接入Dify的玩法完整梳理一遍。如果你是手里只有一张普通显卡、又想让本地跑起大模型的玩家或开发者，这篇文章能让你少走不少弯路。

1. 为什么8GB显存能跑35B模型：先把账算明白

1.1 35B模型到底需要多少资源

先说一个最容易被忽略的基础点：模型参数和显存之间到底是什么关系。

35B的意思是模型有350亿个参数。按照最常见的FP16半精度存储，每个参数占2字节，350亿参数至少需要70GB空间。如果直接用FP16精度把模型全部加载到显存里，别说是8GB，就算是单张RTX 4090都装不下，必须要上多卡服务器。这就是很多人一听“8GB跑35B”就觉得不靠谱的原因——按原始精度来算，它确实不可能。

但这里有个关键误区：本地推理并不要求模型“完整塞进显存”。显存负责的是模型层在前向传播时的计算缓存，内存则可以兜底存储暂时不参与计算的权重。算法上，大语言模型的推理是逐层进行的，每一层只在一个很小的时刻被使用。因此只要调度得当，完全可以把一部分层放在显存、一部分层放在内存，CPU和GPU协作完成推理。这个思路是本地大模型能在低显存设备上跑起来的核心前提，也是后面所有实操的地基。

1.2 量化是让“跑不起”变成“跑得慢”的关键

量化可以理解成把模型参数的精度“降格”存储。就好比一张照片，用无损格式存要10MB，压缩成质量稍低的JPG只占3MB，肉眼看上去差别不大。模型量化也是类似的逻辑：原本FP16精度的权重占2字节，量化成4bit后只占0.5字节，体积直接变成四分之一。

当前最主流的是GGUF格式的4bit量化，常见方案包括Q4_0、Q4_K_M等。以32B模型为例，原始FP16版本大约64GB，量化到Q4_K_M后大约19GB到20GB。虽然对8GB显存来说还是放不下，但已经比70GB小得多，而且20GB这个规模是可以和系统内存配合加载的。35B模型的理论量化体积也就在20GB出头，属于“内存能装下、显存能沾光”的区间。

量化后的模型在推理质量上会有一点损失，但如今的K-quant量化方案在4bit水平上已经能把损失控制得很小。日常对话、写代码、做知识问答，跟原版模型比没有天壤之别，几十层Transformer堆出来的语义能力基本保留住了。

1.3 显存不够时，内存来凑

再看另一本账。假设模型量化后是20GB，GPU可用显存只有8GB，那么至少有12GB需要放到系统内存里。推理时，GPU负责前几层的计算，CPU负责剩余层，这就叫“异构计算”或者“层卸载”。

具体到实现上，Ollama这类推理框架会有一个“GPU层数”参数。默认情况下它会自动检测显存容量和模型尺寸，把尽量多的层放到GPU上，放不下了就把剩余层放在CPU侧。每处理一个token，数据要走一遍所有层，因此GPU和CPU之间会有反复的数据搬运。这就是低显存跑大模型时速度上不去的核心原因：算力不是瓶颈，跨界传输才是。

这也是为什么你会在任务管理器里看到“共享GPU内存”和“系统内存”同时飙升。其实Windows的WDDM驱动机制会把一部分系统内存模拟成共享显存，让GPU可以间接访问，但性能远不如板载显存。这个机制对“能跑”很有帮助，对“跑得快”则没啥帮助，后面实测数据里会看到它的实际影响。

1.4 现实中真正能跑到什么效果

在动手之前，建议先把期望值调整到正确的位置：8GB显存跑35B模型，能保证的是“可以完整对话、可以写长文本、可以做推理分析”，不能保证的是“秒回”。在普通消费级配置上，这类模型的生成速度通常在4到8 token/s之间，也就是每秒钟蹦出四到八个汉字或单词，肉眼看上去像是对方在手速不快地打字。

如果只是用来做问答、总结文档、辅助编程，这个速度完全是可用的。但如果想拿来做实时翻译或者流式输出聊天体验，那会更适合退一步用7B或14B模型全量放进显存跑，速度能到20到40 token/s。所谓“小模型干小事、大模型干重活”，选择哪个参数量，本质上是在速度和效果之间做取舍。

2. 实测前的准备：一台普通游戏电脑就够了

2.1 我的实测环境

说清楚一点，这次实测用的不是什么特挑硬件，就是一台普通家用游戏电脑，配置放在现在勉强算中端水平：

• GPU：RTX 4060 8GB显存
• CPU：i5-13490F，中端六核十二线程
• 内存：32GB DDR4 3200MHz双通道
• 系统：Windows 11 22H2
• 存储：NVMe固态硬盘，仓库盘备了60GB以上空间

这套配置最接近大多数准备尝试本地大模型的玩家。如果你手头是RTX 3060 12GB或者RTX 4070，体验会更好，但思路完全一致。如果内存只有16GB，跑30B以上模型会比较紧张，建议优先试14B级别。

磁盘空间必须提前看一眼。35B级别模型的4bit量化文件就有20GB左右，加上官方库的暂存文件，一次性至少预留40GB空间。很多人在下载中途发现空间不够，又得清盘重来，非常浪费时间。

2.2 为什么用Ollama而不是别的方案

本地推理框架的选择其实不少，llama.cpp本身也能直接用，还有LM Studio这类带图形界面的工具。但我实际用下来还是推荐Ollama，理由很简单：配置成本最低，且对Windows支持很友好。

Ollama会把模型的量化格式、层数分配、交互方式都封装成极简的操作。安装完系统服务后，只需要在终端执行一条pull或run命令就能把模型拉下来跑，不需要手动去处理GGUF文件里的各种量化标记，也不需要折腾Python环境。

如果你已经用llama.cpp或者Transfromers跑了很久，用Ollama也不亏，因为它在底层同样基于llama.cpp的GGML推理方案，效率上没有明显短板。Ollama最值钱的地方在于抽象了一层模型仓库，想切换模型版本的时候非常方便。

另外，Ollama自带了一个与OpenAI兼容的HTTP接口，即时不装任何额外服务，Dify、FastGPT这类应用也能直接接入。这一点后面再说。

2.3 模型与量化版本怎么选

去Ollama模型库搜索时，你会发现有不少30B到35B区间的宝藏模型，比如官方源里的Qwen2.5-32B-Instruct、GLM-4-32B，还有一些社区调的独立35B微调模型，命名五花八门。

这次实测我主要跑两款：Qwen2.5-32B和GLM-4-32B。标题里说的35B不是死磕某个具体模型，而是泛指这一档参数量级别。如果你是刚开始接触，建议直接从Qwen2.5-32B入手，因为它的中文指令遵循能力很强，量化兼容性也成熟。

Ollama拉取的默认版本选择比较保守，执行ollama pull qwen2.5:32b-instruct拿到的就是官方推荐的4bit量化版。如果你想自己指定更细的GGUF方案，可以用ollama create结合本地GGUF文件来构建，但对于大多数人来说，官方默认版就够了。花更多时间折腾量化参数，不如把折腾时间拿去多验证几个使用场景。

3. 完整实测过程：从下载到对话

3.1 下载模型并观察资源变化

一切准备就绪后，实际操作从终端开始。打开PowerShell，执行：

ollama pull qwen2.5:32b-instruct

第一次拉取需要等一段时间，20GB左右的数据量要看网速，快的话五六分钟，慢的话半小时。下载完成后，直接执行：

ollama run qwen2.5:32b-instruct

启动阶段它会先加载模型权重。因为8GB显存放不下完整的20GB模型，所以加载过程需要一段时间，我的机器上大概花了1分40秒左右。不要怀疑是不是卡死了，只要看到内存占用在涨、CPU有负载，就是在加载。

趁这个时间打开任务管理器，重点盯三块：GPU显存、共享GPU内存、系统内存。加载完成后，我观察到大约是7.1GB专用显存被占用，共享GPU内存占用了9GB左右，系统内存总体占用比空闲时高出15GB以上。整个过程基本印证了“一部分权重在显存、一部分在内存”的判断。

3.2 调整加载层数，找到自己的甜点位

Ollama默认会自动分配GPU层数，但在Windows下不一定是最优解。想手动控制，需要设置环境变量OLLAMA_GPU_LAYERS，然后重启Ollama服务：

setx OLLAMA_GPU_LAYERS "14"

重启Ollama的方式是把后台托盘图标里的Ollama退出，然后重新执行ollama run即可。为什么要强调这个参数？因为它直接决定了显存是否过载。如果你把加载层数设得太高，比如一次往8GB显存里塞太多层，会立刻出现显存分配失败，模型直接报错退出。反之设得太低，GPU利用率不足，速度会明显变慢。

我在RTX 4060 8GB上试了几个数值：18的时候运行较快但偶发OOM，14比较稳，10则明显拖慢生成速度。最终锁定14层，相当于把模型的前四分之一放在GPU上，其余交给CPU处理。不同显卡的甜点位不一样，建议从低往高试，遇到OOM就降两层。

3.3 生成速度、质量和体验

进入对话后，我先问了一个简单问题：“写一段关于本地大模型部署的300字介绍。”观察到的输出速度稳定在6 token/s上下，生成完300字大概用了45秒，中间没有中断。

这个速度意味着什么呢？如果你用惯了ChatGPT那种瀑布式输出，会觉得它慢。但实际体验下来，6 token/s已经足够支撑你边看边思考，不太会影响创作类任务的流畅度。模型输出的内容质量超出预期，条理清楚，中文表达自然，没有出现明显的语序崩坏。

接着我用代码补全和数学逻辑题做了测试。代码方面，让它写一个Python函数实现目录遍历，输出结构完整、注释清晰；逻辑题方面，一个带有隐含条件的题目也能答到点子上。能被量化保持到这个水平，说明4bit方案对32B级别模型的语义能力保留得确实不错。

顺带提一句：温度参数不建议在低显存跑大模型时调太高。本地推理本来就要等，如果模型因为高温而大幅发散，一个简单问题来回改半天，体验会很差。默认温度0.7是个不错的选择。

3.4 上下文长度的影响

这是很多人玩两天后才会遇到的门槛：模型加载正常、对话也正常，但聊到一定轮数之后，它突然像失忆了一样，前面说过的东西全忘光了。原因很简单，上下文窗口默认只有4096个token，也就是大约两千到三千个汉字，超过这个量，最老的内容就会被丢弃。

如果想让上下文长一点，可以用参数调整：

/set parameter num_ctx 8192

把上下文翻倍之后，内存和显存占用会同时上涨。实测从4096扩到8192后，共享GPU内存多了大概2GB，系统内存也涨了一截。对8GB显存来说，2GB的共享内存增量还好，但如果你同时把加载层数调得很高，就有OOM风险。我的建议是：优先保住层数，上下文保持在4096到6144之间，够日常用就行。

更长上下文的代价会成倍增长，因为KV Cache的大小跟上下文长度正相关。8GB显存跑32B，本身留给KV Cache的空间就很小，硬开16384上下文只会让推理慢到不可接受。这不是模型能力不行，是硬件边界，接受它就好。

4. 实操避坑：常见报错与排查方法

4.1 显存不足或OOM

这是所有低显存玩家最容易遇到的第一个坑。表现是执行ollama run后加载到一半报类似“failed to allocate memory”的错误，或者Ollama服务后台崩掉。原因基本都是GPU层数设置过高，或者电脑上还有其他程序占显存。

排查思路很简单：关掉浏览器硬件加速、关闭Stream Dock等第三方渲染工具，再把OLLAMA_GPU_LAYERS往下调。一次调2层，直到能稳定启动为止。如果显存占用明明很低还是报OOM，检查一下Windows有没有启用“硬件加速GPU计划”，这个设置在某些驱动版本下会导致显存预留异常。

4.2 回答慢到怀疑人生

如果生成速度掉到2 token/s以下，通常不是模型量化的问题，而是内存带宽和CPU算力成了瓶颈。可以先看任务管理器：CPU占用是否接近满载？答案是“是”的话，说明大部分层在CPU侧计算，这时把层数调高反而可能会因为更多显存参与而提速。

但也要注意，很多CPU的AVX2或者AVX512指令集对llama.cpp的推理效率影响很大。新一点的CPU自带AVX512，速度比老平台有明显优势。如果你的CPU本身性能较弱，8GB跑32B可能只能拿到3到4 token/s，这是硬件天花板的限制，不是配置问题。

另一个常被忽视的因素是内存通道数。双通道内存比单通道快接近一倍，因为每次读写权重的数据量极大，内存带宽几乎直接决定吞吐。建议至少组成双通道，性能提升立竿见影。

4.3 对话一长就失忆

本质就是上下文窗口被截断。如果你想保留更长的历史，就必须接受更大的KV Cache代价。开8192上下文实测还可以用，开16384就明显吃力了。

有一种妥协方案是使用“分段式对话”：每次提问前把关键背景用一两句话重新描述，不让模型必须从旧上下文里回忆。对于8GB显存的场景，这个习惯比你无脑调大上下文窗口更实用。

4.4 不同参数量的速度对比

为了给自己一个坐标，我顺手测了同环境下7B和14B模型的速度。结果如下表，方便你根据实际需求选择：

从表里能看出一个趋势：14B模型基本是8GB显存全能跑的极限甜点，速度和效果非常均衡；32B则是追求效果的上限，代价是速度折半。35B模型的情形与32B基本一致，所以把标题里的“8GB跑35B”理解成“能启动、能对话、不能秒回”的标杆就行。

5. 这个能力还能怎么用：接入Dify与场景扩展

5.1 本地大模型接入Dify

本地模型跑起来之后，最大的乐趣是把能力交给应用层去调用。这里分享一下Ollama接入Dify的方式，这也是最近问得很多的一个方向。

Ollama启动后，默认监听的端口是11434，并提供了一个OpenAI兼容的HTTP接口。在Dify的自定义模型里，选择“OpenAI API compatible”，填写：

API Endpoint: http://localhost:11434/v1 API Key: ollama Model ID: qwen2.5:32b-instruct

这里API Key是占位符，随便填一个非空字符串就可以。配置完成后，Dify就能把该模型当作标准OpenAI接口模型来调用。你可以把它放到工作流里做知识库回复生成，不需要购买任何云服务。

需要提醒的是，消费级显卡上的本地模型并发能力极其有限。Dify如果有多个工作流同时请求，Ollama会排队处理，单个请求的等待时间会被拉得很长。如果你的场景是个人助手、研究型使用，完全没问题；但如果是多人团队同时使用，建议只把它接到低并发的内部工具里。

5.2 怎么理解“去掉限制”

网上经常看到“AI本地大模型去掉限制”的说法，其实不玄乎。大多数情况下指的是两件事：一是把Ollama对CPU加载层数等运行参数的限制放开，二是把上下文长度、响应超时等默认参数调宽。

比如在Shell里设置环境变量：

setx OLLAMA_NUM_PARALLEL "1" setx OLLAMA_MAX_LOADED_MODELS "1" setx OLLAMA_CONTEXT_LENGTH "6144"

这几个参数能约束Ollama在8GB显存机器上的行为，避免它因为错误估计资源而做出不合理的调度。“去掉限制”并不是要把性能提升到和人几万块服务器一样，而是把默认策略改成更适合自己硬件的方式。

5.3 消费级部署与企业部署的差异

有人会问，如果公司花二三十万买了一堆硬件部署本地大模型，运维工作量会不会很大？实际上会，而且不低。企业级部署要考虑鉴权、多用户并发、模型热更新、GPU监控、日志采集和故障恢复，这些在消费级单机场景里都是可以跳过的。正因如此，个人玩本地模型反而更轻快，一台PC就能成为一个私有的模型服务。

但我必须说一句实在话：消费级跑大模型的核心价值不是省钱，也不完全是为了速度，而是数据可控和自由折腾。模型跑完一次微调、调完几个参数后，整套管道就变成你自己的东西。这种从“使用者”变成“操作者”的过程，才是这件事最让人上瘾的地方。

回头总结下我这段实测的过程：从最开始被报错折磨，到后来摸清OLLAMA_GPU_LAYERS和上下文窗口的关系，再到Dify里成功发起第一轮本地模型对话，整个过程花了一个晚上。踩坑越多，对“显存不够也能跑大模型”这件事的理解就越到位。如果你也正要拿手头这张消费级显卡去挑战大参数模型，希望这份实录能让你少试几次错，更快看到想要的输出。