还在用在线网页聊天窗前阵子我把手头一块 8GB 显存的消费级显卡翻出来硬是在本地把 35B 参数的 Qwen2.5 大模型给跑起来了全程不依赖任何云端 API。这篇就是那台“过气甜品卡”的完整实录——装了什么东西、踩了哪些坑、实际每秒吐多少字、能拿来干哪些活全部摊开写清楚。如果你手里也有一块 8GB 左右显存的卡想知道本地大模型部署到底能到什么程度这篇可以直接当操作手册看。先说几个关键结论8GB 显存跑 35B 大模型靠的是“量化 部分模型层卸载到内存”的组合打法全程约 20GB 系统内存推理速度大概在每秒 2 到 5 个 token 之间上下文一拉长还会掉到 1 字出头。听起来不快但写文案、改代码、做知识库问答这类场景完全够用而且数据不出本机。下面我从需求拆解、工具选型、实操参数到问题排查完整过一遍。1. 为什么偏要在 8GB 显存上跑 35B需求分析与思路拆解1.1 8GB 显存的尴尬位置消费级显卡的显存分布很有意思入门卡 8GB甜品卡 8GB 到 12GB高端卡 16GB 出头。像 RTX 4060、3060、部分 4060 Ti 和笔记本 GPU大量卡都卡在 8GB。这个容量在 3D 游戏里绰绰有余但在大模型时代很尴尬——如果只跑 7B、8B 的模型8GB 勉强能全量塞进显存量化后确实流畅想要上 14B 就得靠 CPU 帮忙35B 更是所有资源都拉满才碰得到。为什么非要在 8GB 上跑 35B表面看是显存不够但实际需求是我需要一个能读得懂长文档、能写结构化代码、能理解复杂指令的开源模型同时又不想把文档内容传到第三方 API。7B 模型写打油诗、做摘要勉强及格一旦涉及多步骤推理或长代码逻辑输出质量肉眼可见地掉链子。35B 参数带来的推理能力和指令遵循能力是 7B 模型比不了的这也是我坚持在这个显存瓶颈上硬啃 35B 的直接原因。1.2 指导思想量化压缩 分层卸载35B 模型如果用 FP16 精度保存光权重就要 70GB 左右。别说 8GB 显存就是 128GB 内存的机器也未必舒服。所以本地跑大模型的第一原则是“不要保留原汁原味”而是用量化把权重压到可以接受的体积。常见做法是把每个权重从 16 bit 压到 8 bit、6 bit、4 bit体积直接缩到原来的四分之一甚至五分之一。但即使压到 4 bit35B 模型仍然要占 20GB 左右的存储和内存。8GB 显存怎么装答案是拆开装模型被切成一层层 Transformer Block电 脑把前面的层放进 GPU 显存剩下的层留在系统内存里由 CPU 负责计算。GPU 和 CPU 之间边算边搬显存不够就用内存凑。实际效果取决于“卸载比例”和“内存带宽”这部分后面实测数据会详细展开。1.3 这套方案到底解决了什么问题本地跑 35B 模型从需求角度看其实解决了三类问题隐私敏感场景。公司合同、病例记录、个人笔记这类资料直接发到公网 API 很多人心里没底。模型完全跑在本机输入输出都不出本机至少在数据流向上没有外泄路径。长期使用成本。在线 API 是按 token 计费的重度使用一个月下来账单不小而一张普通显卡加一台 32GB 内存的电脑装好之后除了电费几乎零成本。离线可用的刚需。断网环境下也想用 AI 助手本地部署是唯一答案。当然这些价值不是凭空来的代价就是速度慢、折腾多、硬件资源需求苛刻。所以这篇文章不做立场判断只把“8GB 跑 35B”的完整路径记录给你能不能用、合不合算你看完实测数据自己判断。2. 环境准备与工具选型Ollama 量化模型方案2.1 主机配置参考我这次实测的机器不高端但内存和硬盘都是特意为跑模型准备的配置如下部件参数说明显卡RTX 3060 8GB 桌面版实测代表笔记本 4060 8GB 同理CPUi5-12490F 6 核 12 线程CPU 负责卸载层的推理内存DDR4 3200 32GB双通道35B 至少要 24GB 可用内存32GB 是底线硬盘1TB NVMe SSD模型文件约 21GBSSD 决定加载速度系统Windows 11 WSL2 或直接 Linux推荐 LinuxOllama 支持更好注意几点系统内存千万别低于 24GB我试过 16GB 机器跑 35B Q4_K_M加载到一半直接 OOM。双通道内存非常加分内存带宽直接决定 CPU 卸载部分的推理效率单通道和双通道能差出 30% 以上速度。2.2 为什么选 Ollama 而不是其他推理框架本地跑 35B 模型可选方案不少llama.cpp 原版、GPT4All、LM Studio、Ollama。我最终选了 Ollama原因很实际一条命令装好ollama pull就能拉模型不用自己编译源码。底层用的是 llama.cpp 的量化推理内核GPU 和 CPU 混合调度做得比较成熟。自带 OpenAI 兼容 API后续接知识库、接聊天前端都非常方便。模型标签管理清晰一个命令换一个量化版本。我用命令行操作你也可以用 LM Studio 的图形界面替代原理完全一样。但下面所有命令都以 Ollama 为例。2.3 量化等级与显存占用计算拉模型之前理解量化标签非常重要。Ollama 模型库里的常见标签包括q4_K_M4 bit 量化K 均值混合策略体积大约 21GB质量较好最推荐。q5_K_M5 bit 量化约 25GB质量略好但内存压力大。q8_08 bit 量化约 37GB普通家用机已经很难承载。fp16原始半精度约 70GB8GB 显卡机器直接放弃。35B 模型指的是 Qwen2.5-35B-Instruct实际参数量 35.5B4 bit 量化后的模型文件大概 21.5GB。这里要划个重点8GB 显存跑 35B 能成功全靠 q4_K_M 这种量化把体积压到内存能承受的范围。如果上 q8_0 或 fp16内存和显存的压力都会翻倍速度更惨。模型文件体积可以这样粗算参数量 35.5B量化位数 4 bit则权重体积 35.5B × 4 / 8 ≈ 17.75GB加上一部分 embedding 和额外开销实际约 20 到 21GB。这个估算方法对任何模型都适用选量化版本之前先拿计算器算一下比自己瞎猜准得多。2.4 安装与拉取模型的完整命令先安装 Ollama。Windows 用户直接到官网下载安装包Linux 用户执行curl -fsSL https://ollama.com/install.sh | sh装完验证一下ollama --version然后拉取模型重点来了直接指定 q4_K_M 标签# 官方模型库中的 35B Q4 量化版本 ollama pull qwen2.5:35b-instruct-q4_K_M不加标签拉ollama pull qwen2.5会默认拉最大参数版本有可能把几十 GB 的东西全下下来。我只推荐拉q4_K_M标签因为这是显存和内存双重瓶颈下的最佳平衡点。下载时注意模型默认存到用户目录下的.ollama/models对 C 盘空间小的用户不太友好可以设置环境变量set OLLAMA_MODELSE:\ollama\modelsWindows 下在系统环境变量里配置即可。修改后重启 Ollama 进程才会生效这是一个非常容易忽略的坑。2.5 运行时关键参数层数卸载与上下文长度模型拉到本地后Ollama 默认会把能塞进显存的层数全塞进去但 8GB 显存面对 35B 一定塞不完手动控制才靠谱。最稳妥的方式是通过 Modelfile 固定参数FROM qwen2.5:35b-instruct-q4_K_M PARAMETER num_gpu 28 PARAMETER num_ctx 2048保存为Modelfile然后创建自定义模型ollama create qwen35b-lite -f ./Modelfile这里num_gpu 28的含义是让前 28 层 Transformer Block 放在 GPU 上计算其余层由 CPU 处理。Qwen 35B 总层数大约 64 层28 层对应约 4 到 5GB 显存占用留一部分显存给上下文缓存和计算缓冲。num_ctx 2048表示上下文窗口长度为 2048 个 token这个设定必须克制上下文越大显存和内存占用越高直接压垮本就紧张的资源。不同显卡、不同显存容量的最优值不同。我自己实测下来8GB 显存配 32GB 内存num_gpu设在 24 到 32 之间都是工作区间。设少了太慢设多了加载时直接报 allocate tensor failed。建议从num_gpu 28开始调跑通了再一格格往上加。3. 实操过程从安装到首次对话的完整实录3.1 首次启动加载耗时与资源占用创建好qwen35b-lite这个自定义模型后直接开跑ollama run qwen35b-lite第一次加载 21GB 模型文件很慢SSD 上大约要 30 到 60 秒。期间打开任务管理器可以看到显存占用一下冲到 4GB 多内存占用从 5GB 飙到 25GB 左右。这个过程主要慢在“内存临时分配 CUDA 上下文初始化”上不是模型推理本身。启动完成后会进入对话交互界面输入/show可以看到当前模型的参数设置。我用/show parameters确认num_gpu生效。如果没有生效且显存直接爆满可以踢开模型重进或检查 Modelfile 里的参数是否被拼写错误。3.2 典型任务测试写作、代码、多轮对话加载成功后我做了三组代表性测试记录原始输出效果第一组是中文写作。让模型写一段 300 字的“夏日绿豆汤制作说明”输出逻辑完整步骤清晰没有明显语病。速度大约每秒 3 个 token整段 300 字花了快两分钟。这个速度边看边等是可以接受的。第二组是代码生成。让它写一个 Python 快速排序模型不只是给了代码还附带解释了时间复杂度。代码语法正确可运行质量超过 14B 模型的输出。第三组是多轮对话。连续追问了三个问题让它回顾之前提到的内容。在num_ctx 2048的限制下前几轮没问题长对话超过上下文窗口后开始遗忘早前内容。说明跑 35B 时上下文长度比模型质量更早成为瓶颈。3.3 把模型变成服务API 调用与前端接入命令行模式适合测试但真正日常使用要接前端或 API。Ollama 启动后可以直接用 Python 请求本机接口ollama serve另一个终端运行curl http://localhost:11434/api/chat -d { model: qwen35b-lite, messages: [{role: user, content: 你好}] }也可以直接调用 OpenAI 兼容接口import openai client openai.OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama ) resp client.chat.completions.create( modelqwen35b-lite, messages[{role: user, content: 写一段欢迎词}] ) print(resp.choices[0].message.content)这样做的意义在于后续接 Open WebUI、AnythingLLM、Dify 等前端时不需要改代码只要把 LLM 后端地址指向本机 11434 端口即可。这也是一整套本地大模型部署的核心枢纽。3.4 速度调优环境变量与并发控制同一个模型在不同参数下速度差一倍是常事。Ollama 读取几个关键环境变量直接影响性能OLLAMA_CONTEXT_LENGTH全局默认上下文长度默认 2048开大会拖慢推理。OLLAMA_NUM_PARALLEL同时处理的请求数默认 1 或 4多开会严重拖慢单次响应。OLLAMA_MAX_LOADED_MODELS最多同时加载的模型数默认 38GB 显存只建议设为 1。我的推荐配置放在 Windows 系统环境变量里OLLAMA_CONTEXT_LENGTH2048 OLLAMA_NUM_PARALLEL1 OLLAMA_MAX_LOADED_MODELS1Linux 用户可以用 export 临时生效重启 Ollama 服务后测试。实测下来OLLAMA_NUM_PARALLEL1时单用户响应最快如果拿来做团队服务倒是可以让模型排队处理但每人的等待时间会拉长。4. 实测数据与效果对比到底值不值4.1 不同配置下的显存、内存与速度记录我把 35B 模型在三种不同配置下各跑了一组同一测试任务写 300 字短文结果很直接配置方案GPU 层数系统内存占用显存占用平均生成速度稳定度全 CPU 推理GPU 不参与024GB0.5GB1.2 t/s稳定但很慢GPU 26 层 CPU 剩余层2623GB4.5GB2.8 t/s较稳定GPU 32 层 CPU 剩余层3218GB6.2GB3.5 t/s偶尔卡顿GPU 40 层8GB 显卡上限尝试4012GB7.8GB加载阶段直接 OOM不可用这张表是这篇文章最核心的数据。共性是单看生成速度8GB 显存跑 35B 无论如何达不到“飞快”但通过调整 GPU 层数可以从 1.2 t/s 提升到 3.5 t/s接近三倍差距。40 层的尝试失败的原因也很经典模型权重加上计算缓冲空间超出显存物理容量加载阶段就爆了。Ollama 在加载阶段会为每个 Transformer 层预留权重和激活值的缓冲显存满后没有任何换入换出的余地。4.2 和 7B 模型做对比牺牲速度换质量值不值跑 35B 之前同一台电脑跑 7B Q4 量化是桌面顺滑级别速度能到 30 到 50 t/s。为什么还要用 1 到 3 t/s 的龟速跑 35B我用一个实际任务做了对比写一段带条件分支的 Python 脚本输入 200 行左右的半成品代码要求修复变量作用域问题并添加注释。7B 模型输出结果存在两个明显硬伤第一没有识别出闭包导致变量污染第二注释建议比较啰嗦且跑偏。35B 模型一次输出基本正确每个问题都切中要害。这种差距在“写代码”“处理长逻辑”“按复杂指令执行”时非常明显在“简单问答”时反而不大。所以结论很清楚如果你只是做闲聊、写短句8GB 显存完全没必要上 35B但如果你需要本地处理结构化任务、复杂代码、长文档这种“速度换质量”的取舍是值的。4.3 长上下文压测上下文一长速度直接掉一半35B 模型在本地跑最容易被低估的坑是上下文长度。num_ctx 2048只意味着模型能“记住”约 2000 个 token 的历史对话但实际计算量跟序列长度高度相关。当对话历史逐渐累积模型每生成一个新 token都需要把前面所有 token 的注意力矩阵重算一遍。实测下来上下文长度 512 时生成速度约 3.8 t/s上下文长度 2048 时降到 2.6 t/s强行拉到 4096降到 1.8 t/s 且系统内存飙到 30GB随时可能触碰 32GB 天花板。所以我最后把num_ctx 2048定为默认值这是质量和资源占用之间的妥协点。内存计算也有规律Qwen 35B 的每 token KV cache 占用约 0.5MB 到 1MB2048 上下文大概吃 2GB 内存4096 就能吃掉 4GB 以上。显存不够时这些内存占用还得和 CPU 卸载层共享进一步拖慢速度。所以一定要记住本地跑 35B上下文长度是要精打细算的珍稀资源。4.4 本地部署与在线 API 的成本账跑之前我算了笔账35B 模型本机 run 一天假设重度使用电费按 500W 功耗跑 8 小时一天约 2 到 3 元电费。在线 API 讲的是 token 计费以常见的中档模型价格写 3000 字文档约消耗 2 万 token连续算一个月笔电账单可能上百元。长期看本地部署的经济优势明显尤其适合有固定任务量、需求稳定的场景。但这笔账有一个前提硬件已经存在。如果没有显卡和 32GB 内存的先期投入只为了跑 35B 专门配电脑那要把硬件成本摊进每月的折旧里再比较。另外本地部署省的是 token 费没省维护时间折腾新模型、调参、解决 OOM 都是隐性成本。5. 把模型接进知识库让本地模型真正干活5.1 为什么只聊天不够纯命令行聊天更多是炫技真正让本地大模型产生生产力的是把它接进“本地知识库”也就是 RAG检索增强生成架构。思路不复杂用户提问后系统先在本地嵌入模型检索最相关的文档片段然后把片段拼进提示词交给大模型生成回答。这套架构下大模型不需要记住全部知识只要在回答时“看得到”相关资料就行。这个方案对显存紧张的 8GB 环境尤其有价值。35B 模型本身记不住太多新知识但通过外部向量检索可以把最新文档、私有资料、行业术语塞进问答链路相当于给 35B 装了个可无限扩展的外置记忆。5.2 选择配合的知识库工具目前最常用的本地知识库工具是 AnythingLLM 和 Open WebUIDify 则更适合团队化工作流。我这次用 AnythingLLM因为它配置最简单对 Ollama 后端支持成熟下载安装 AnythingLLM 桌面版。LLM 后端选择 Ollama模型选qwen35b-lite。Embedding 模型也选 Ollama 提供的nomic-embed-text或者bge-m3体积很小几百 MB拉取很快ollama pull bge-m3Embedding 模型用来把文本片段变成向量是整个检索环节的基石。选 embedding 模型时注意两点维度太高的模型会吃掉更多内存性能优先选 1024 维以内的中文场景建议用 bge-m3 这类中英双语模型检索质量远好于通用英文模型。5.3 数据准备与向量化流程AnythingLLM 里新建一个 Workspace把需要问答的 PDF、Markdown、TXT 文档拖进去系统会自动完成切片、向量化、存储三步。我这里实际喂了一个 10 万字的内部运维手册普通配置下耗时约 3 分钟。向量化完成之后问答响应流程变成请求进来先由 embedding 模型检索最相关段落再把段落塞给 35B 模型生成回答。这里有个经验——检索出来的相关片段不要太多我实测 3 到 5 个片段效果最佳。片段太多会把上下文迅速填满35B 模型在 2048 上下文下很快失去焦点片段太少又找不到足够的依据。所以知识库切片长度建议控制在 500 到 1000 字之间过长会让单次检索结果太粗。5.4 知识库问答的实测调整配置完知识库后我试问了几轮“公司服务器 SSH 登录出现 permission denied 是什么原因”模型能准确引用手册中的排查步骤回答质量比裸用 35B 高一个档次。说明 35B 模型的推理能力加上外部知识库检索已经接近在线大模型的基础体验。但速度依然受限于模型推理速度。RAG 机制对模型生成本身没有加速效果反而因为要额外等待检索步骤整体延迟比裸模型还高一点点。实际体验是提问后约 10 到 20 秒才开始生成不是 bug是资源紧张下的正常节奏。如果嫌慢可以换 14B 模型配知识库速度能到 10 t/s 左右质量对大多数文档问答也够用。我的建议是知识库问答这种“准确性比文采重要”的任务优先保速度14B 往往比 35B 更实用。6. 常见问题与排查技巧实录6.1 显存不足类问题8GB 显存跑 35B 最常见的报错是error: failed to load model: allocate tensor failed如果你看到这行直接原因就是显存或内存不够。排查顺序检查系统内存是否充足35B Q4 至少预留 24GB 可用内存总内存低于 32GB 的基本没戏。降低num_gpu层数从 40 往 24 调每次 4 层。降低num_ctx2048 降到 1024释放 KV cache 占用。换更小量化模型比如 8B 或 14B。还有一类隐性显存占用来自 Ollama 的预加载机制。如果之前加载过其他模型显存可能还被它占着。可以强制清空ollama stop qwen35b-lite或者直接重启 Ollama 服务干净利落。这个“上一个模型还占着显存”的问题我用 8GB 显存时遇到过好几次重启服务屡试不爽。6.2 生成速度慢或者直接卡住如果模型能加载但输出像乌龟爬优先检查卸载层数。按前面表格num_gpu从 0 调到 32速度能提升近三倍。若已经调到 32 但还是卡顿则要检查系统内存是否还在被其他程序占用。浏览器开几十个标签页、后台编译任务都会抢内存跑 35B 前最好把无关大程序全关掉。另外 CPU 推理速度受内存通道数影响极大。双通道 DDR4 3200 的内存带宽约 50GB/s单通道只有一半不到。如果你用的是第 12 代酷睿配两根不同容量的内存条可能工作在单通道模式下这会让 CPU 卸载部分慢到无语。用 CPU-Z 或任务管理器确认一下内存通道数这个坑不起眼但影响巨大。生成中途卡住不吐字还有一个常见原因模型输出期间 CPU 和 GPU 频繁等待同步。解决方案是降低num_ctx或者干脆减少 GPU 层数让调度更稳定。我在num_gpu 32和num_ctx 2048下偶发卡顿下调到num_ctx 1024后卡顿明显缓解。6.3 模型输出质量差或带莫名限制本地开源模型其实是可控性最高的一类模型角色、输出风格、约束条件全都写在你自己的 System Prompt 里。如果你对输出不满意优先调整这一段提示词给模型明确身份和边界而不是去搜什么“破解提示词限制”的操作。真正的质量瓶颈通常出现在两个地方量化精度不够。q4_K_M 在复杂推理任务上确实比 fp16 差一截如果任务特别讲究推理准确性可以换 q5_K_M 或 q8_0但代价是内存和速度。上下文不足。模型没有看到关键信息时会出现“一本正经胡说八道”解决方法是把需要的资料通过知识库检索显式放进上下文。6.4 多人使用与并发场景的现实回应很多人问“搭建一个 200 人用的本地大模型要多少钱”。这里直接给结论8GB 显卡机器带不动 200 人。35B 模型在单线程下以 2 到 4 t/s 的速度生成一个用户问一个问题就要等几十秒200 人并发会直接让本机资源耗尽。如果真要服务一个 200 人团队至少需要一台多卡服务器双卡甚至四卡 24GB 以上显存配合 vLLM 这类推理框架做并发调度。那是另一套硬件的预算量级跟本篇文章里的单卡玩法完全不是一个赛道。最后再分享一点我的实际体会跑完这轮 8GB 显存 35B 的折腾我的最大心得不是“越大的模型越好”而是“显存不够时模型要用到刀刃上”。在本地部署大模型这件事上量化等级、GPU 层数、上下文长度三者互相牵制任何一个拉满都会让另外两个崩溃。最终稳定可用的状态往往是三者都不饱和的中间值。如果你也准备动手我建议的顺序是先装 Ollama拉一个 14B 模型跑通流程再回来挑战 35B 的 q4_K_M。这样你能更直观地理解“快”和“好”在本地模型中到底要怎么取舍。8GB 显存跑 35B说到底不是追赶什么大模型军备竞赛而是把手头有限的硬件用到极致让个人电脑真正具备离线智能问答和知识管理的能力。下一次再有人说消费级显卡不能碰大模型你可以把这篇文章甩过去。 8GB显存跑35B大模型：量化与混合卸载实操指南
还在用在线网页聊天窗前阵子我把手头一块 8GB 显存的消费级显卡翻出来硬是在本地把 35B 参数的 Qwen2.5 大模型给跑起来了全程不依赖任何云端 API。这篇就是那台“过气甜品卡”的完整实录——装了什么东西、踩了哪些坑、实际每秒吐多少字、能拿来干哪些活全部摊开写清楚。如果你手里也有一块 8GB 左右显存的卡想知道本地大模型部署到底能到什么程度这篇可以直接当操作手册看。先说几个关键结论8GB 显存跑 35B 大模型靠的是“量化 部分模型层卸载到内存”的组合打法全程约 20GB 系统内存推理速度大概在每秒 2 到 5 个 token 之间上下文一拉长还会掉到 1 字出头。听起来不快但写文案、改代码、做知识库问答这类场景完全够用而且数据不出本机。下面我从需求拆解、工具选型、实操参数到问题排查完整过一遍。1. 为什么偏要在 8GB 显存上跑 35B需求分析与思路拆解1.1 8GB 显存的尴尬位置消费级显卡的显存分布很有意思入门卡 8GB甜品卡 8GB 到 12GB高端卡 16GB 出头。像 RTX 4060、3060、部分 4060 Ti 和笔记本 GPU大量卡都卡在 8GB。这个容量在 3D 游戏里绰绰有余但在大模型时代很尴尬——如果只跑 7B、8B 的模型8GB 勉强能全量塞进显存量化后确实流畅想要上 14B 就得靠 CPU 帮忙35B 更是所有资源都拉满才碰得到。为什么非要在 8GB 上跑 35B表面看是显存不够但实际需求是我需要一个能读得懂长文档、能写结构化代码、能理解复杂指令的开源模型同时又不想把文档内容传到第三方 API。7B 模型写打油诗、做摘要勉强及格一旦涉及多步骤推理或长代码逻辑输出质量肉眼可见地掉链子。35B 参数带来的推理能力和指令遵循能力是 7B 模型比不了的这也是我坚持在这个显存瓶颈上硬啃 35B 的直接原因。1.2 指导思想量化压缩 分层卸载35B 模型如果用 FP16 精度保存光权重就要 70GB 左右。别说 8GB 显存就是 128GB 内存的机器也未必舒服。所以本地跑大模型的第一原则是“不要保留原汁原味”而是用量化把权重压到可以接受的体积。常见做法是把每个权重从 16 bit 压到 8 bit、6 bit、4 bit体积直接缩到原来的四分之一甚至五分之一。但即使压到 4 bit35B 模型仍然要占 20GB 左右的存储和内存。8GB 显存怎么装答案是拆开装模型被切成一层层 Transformer Block电 脑把前面的层放进 GPU 显存剩下的层留在系统内存里由 CPU 负责计算。GPU 和 CPU 之间边算边搬显存不够就用内存凑。实际效果取决于“卸载比例”和“内存带宽”这部分后面实测数据会详细展开。1.3 这套方案到底解决了什么问题本地跑 35B 模型从需求角度看其实解决了三类问题隐私敏感场景。公司合同、病例记录、个人笔记这类资料直接发到公网 API 很多人心里没底。模型完全跑在本机输入输出都不出本机至少在数据流向上没有外泄路径。长期使用成本。在线 API 是按 token 计费的重度使用一个月下来账单不小而一张普通显卡加一台 32GB 内存的电脑装好之后除了电费几乎零成本。离线可用的刚需。断网环境下也想用 AI 助手本地部署是唯一答案。当然这些价值不是凭空来的代价就是速度慢、折腾多、硬件资源需求苛刻。所以这篇文章不做立场判断只把“8GB 跑 35B”的完整路径记录给你能不能用、合不合算你看完实测数据自己判断。2. 环境准备与工具选型Ollama 量化模型方案2.1 主机配置参考我这次实测的机器不高端但内存和硬盘都是特意为跑模型准备的配置如下部件参数说明显卡RTX 3060 8GB 桌面版实测代表笔记本 4060 8GB 同理CPUi5-12490F 6 核 12 线程CPU 负责卸载层的推理内存DDR4 3200 32GB双通道35B 至少要 24GB 可用内存32GB 是底线硬盘1TB NVMe SSD模型文件约 21GBSSD 决定加载速度系统Windows 11 WSL2 或直接 Linux推荐 LinuxOllama 支持更好注意几点系统内存千万别低于 24GB我试过 16GB 机器跑 35B Q4_K_M加载到一半直接 OOM。双通道内存非常加分内存带宽直接决定 CPU 卸载部分的推理效率单通道和双通道能差出 30% 以上速度。2.2 为什么选 Ollama 而不是其他推理框架本地跑 35B 模型可选方案不少llama.cpp 原版、GPT4All、LM Studio、Ollama。我最终选了 Ollama原因很实际一条命令装好ollama pull就能拉模型不用自己编译源码。底层用的是 llama.cpp 的量化推理内核GPU 和 CPU 混合调度做得比较成熟。自带 OpenAI 兼容 API后续接知识库、接聊天前端都非常方便。模型标签管理清晰一个命令换一个量化版本。我用命令行操作你也可以用 LM Studio 的图形界面替代原理完全一样。但下面所有命令都以 Ollama 为例。2.3 量化等级与显存占用计算拉模型之前理解量化标签非常重要。Ollama 模型库里的常见标签包括q4_K_M4 bit 量化K 均值混合策略体积大约 21GB质量较好最推荐。q5_K_M5 bit 量化约 25GB质量略好但内存压力大。q8_08 bit 量化约 37GB普通家用机已经很难承载。fp16原始半精度约 70GB8GB 显卡机器直接放弃。35B 模型指的是 Qwen2.5-35B-Instruct实际参数量 35.5B4 bit 量化后的模型文件大概 21.5GB。这里要划个重点8GB 显存跑 35B 能成功全靠 q4_K_M 这种量化把体积压到内存能承受的范围。如果上 q8_0 或 fp16内存和显存的压力都会翻倍速度更惨。模型文件体积可以这样粗算参数量 35.5B量化位数 4 bit则权重体积 35.5B × 4 / 8 ≈ 17.75GB加上一部分 embedding 和额外开销实际约 20 到 21GB。这个估算方法对任何模型都适用选量化版本之前先拿计算器算一下比自己瞎猜准得多。2.4 安装与拉取模型的完整命令先安装 Ollama。Windows 用户直接到官网下载安装包Linux 用户执行curl -fsSL https://ollama.com/install.sh | sh装完验证一下ollama --version然后拉取模型重点来了直接指定 q4_K_M 标签# 官方模型库中的 35B Q4 量化版本 ollama pull qwen2.5:35b-instruct-q4_K_M不加标签拉ollama pull qwen2.5会默认拉最大参数版本有可能把几十 GB 的东西全下下来。我只推荐拉q4_K_M标签因为这是显存和内存双重瓶颈下的最佳平衡点。下载时注意模型默认存到用户目录下的.ollama/models对 C 盘空间小的用户不太友好可以设置环境变量set OLLAMA_MODELSE:\ollama\modelsWindows 下在系统环境变量里配置即可。修改后重启 Ollama 进程才会生效这是一个非常容易忽略的坑。2.5 运行时关键参数层数卸载与上下文长度模型拉到本地后Ollama 默认会把能塞进显存的层数全塞进去但 8GB 显存面对 35B 一定塞不完手动控制才靠谱。最稳妥的方式是通过 Modelfile 固定参数FROM qwen2.5:35b-instruct-q4_K_M PARAMETER num_gpu 28 PARAMETER num_ctx 2048保存为Modelfile然后创建自定义模型ollama create qwen35b-lite -f ./Modelfile这里num_gpu 28的含义是让前 28 层 Transformer Block 放在 GPU 上计算其余层由 CPU 处理。Qwen 35B 总层数大约 64 层28 层对应约 4 到 5GB 显存占用留一部分显存给上下文缓存和计算缓冲。num_ctx 2048表示上下文窗口长度为 2048 个 token这个设定必须克制上下文越大显存和内存占用越高直接压垮本就紧张的资源。不同显卡、不同显存容量的最优值不同。我自己实测下来8GB 显存配 32GB 内存num_gpu设在 24 到 32 之间都是工作区间。设少了太慢设多了加载时直接报 allocate tensor failed。建议从num_gpu 28开始调跑通了再一格格往上加。3. 实操过程从安装到首次对话的完整实录3.1 首次启动加载耗时与资源占用创建好qwen35b-lite这个自定义模型后直接开跑ollama run qwen35b-lite第一次加载 21GB 模型文件很慢SSD 上大约要 30 到 60 秒。期间打开任务管理器可以看到显存占用一下冲到 4GB 多内存占用从 5GB 飙到 25GB 左右。这个过程主要慢在“内存临时分配 CUDA 上下文初始化”上不是模型推理本身。启动完成后会进入对话交互界面输入/show可以看到当前模型的参数设置。我用/show parameters确认num_gpu生效。如果没有生效且显存直接爆满可以踢开模型重进或检查 Modelfile 里的参数是否被拼写错误。3.2 典型任务测试写作、代码、多轮对话加载成功后我做了三组代表性测试记录原始输出效果第一组是中文写作。让模型写一段 300 字的“夏日绿豆汤制作说明”输出逻辑完整步骤清晰没有明显语病。速度大约每秒 3 个 token整段 300 字花了快两分钟。这个速度边看边等是可以接受的。第二组是代码生成。让它写一个 Python 快速排序模型不只是给了代码还附带解释了时间复杂度。代码语法正确可运行质量超过 14B 模型的输出。第三组是多轮对话。连续追问了三个问题让它回顾之前提到的内容。在num_ctx 2048的限制下前几轮没问题长对话超过上下文窗口后开始遗忘早前内容。说明跑 35B 时上下文长度比模型质量更早成为瓶颈。3.3 把模型变成服务API 调用与前端接入命令行模式适合测试但真正日常使用要接前端或 API。Ollama 启动后可以直接用 Python 请求本机接口ollama serve另一个终端运行curl http://localhost:11434/api/chat -d { model: qwen35b-lite, messages: [{role: user, content: 你好}] }也可以直接调用 OpenAI 兼容接口import openai client openai.OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama ) resp client.chat.completions.create( modelqwen35b-lite, messages[{role: user, content: 写一段欢迎词}] ) print(resp.choices[0].message.content)这样做的意义在于后续接 Open WebUI、AnythingLLM、Dify 等前端时不需要改代码只要把 LLM 后端地址指向本机 11434 端口即可。这也是一整套本地大模型部署的核心枢纽。3.4 速度调优环境变量与并发控制同一个模型在不同参数下速度差一倍是常事。Ollama 读取几个关键环境变量直接影响性能OLLAMA_CONTEXT_LENGTH全局默认上下文长度默认 2048开大会拖慢推理。OLLAMA_NUM_PARALLEL同时处理的请求数默认 1 或 4多开会严重拖慢单次响应。OLLAMA_MAX_LOADED_MODELS最多同时加载的模型数默认 38GB 显存只建议设为 1。我的推荐配置放在 Windows 系统环境变量里OLLAMA_CONTEXT_LENGTH2048 OLLAMA_NUM_PARALLEL1 OLLAMA_MAX_LOADED_MODELS1Linux 用户可以用 export 临时生效重启 Ollama 服务后测试。实测下来OLLAMA_NUM_PARALLEL1时单用户响应最快如果拿来做团队服务倒是可以让模型排队处理但每人的等待时间会拉长。4. 实测数据与效果对比到底值不值4.1 不同配置下的显存、内存与速度记录我把 35B 模型在三种不同配置下各跑了一组同一测试任务写 300 字短文结果很直接配置方案GPU 层数系统内存占用显存占用平均生成速度稳定度全 CPU 推理GPU 不参与024GB0.5GB1.2 t/s稳定但很慢GPU 26 层 CPU 剩余层2623GB4.5GB2.8 t/s较稳定GPU 32 层 CPU 剩余层3218GB6.2GB3.5 t/s偶尔卡顿GPU 40 层8GB 显卡上限尝试4012GB7.8GB加载阶段直接 OOM不可用这张表是这篇文章最核心的数据。共性是单看生成速度8GB 显存跑 35B 无论如何达不到“飞快”但通过调整 GPU 层数可以从 1.2 t/s 提升到 3.5 t/s接近三倍差距。40 层的尝试失败的原因也很经典模型权重加上计算缓冲空间超出显存物理容量加载阶段就爆了。Ollama 在加载阶段会为每个 Transformer 层预留权重和激活值的缓冲显存满后没有任何换入换出的余地。4.2 和 7B 模型做对比牺牲速度换质量值不值跑 35B 之前同一台电脑跑 7B Q4 量化是桌面顺滑级别速度能到 30 到 50 t/s。为什么还要用 1 到 3 t/s 的龟速跑 35B我用一个实际任务做了对比写一段带条件分支的 Python 脚本输入 200 行左右的半成品代码要求修复变量作用域问题并添加注释。7B 模型输出结果存在两个明显硬伤第一没有识别出闭包导致变量污染第二注释建议比较啰嗦且跑偏。35B 模型一次输出基本正确每个问题都切中要害。这种差距在“写代码”“处理长逻辑”“按复杂指令执行”时非常明显在“简单问答”时反而不大。所以结论很清楚如果你只是做闲聊、写短句8GB 显存完全没必要上 35B但如果你需要本地处理结构化任务、复杂代码、长文档这种“速度换质量”的取舍是值的。4.3 长上下文压测上下文一长速度直接掉一半35B 模型在本地跑最容易被低估的坑是上下文长度。num_ctx 2048只意味着模型能“记住”约 2000 个 token 的历史对话但实际计算量跟序列长度高度相关。当对话历史逐渐累积模型每生成一个新 token都需要把前面所有 token 的注意力矩阵重算一遍。实测下来上下文长度 512 时生成速度约 3.8 t/s上下文长度 2048 时降到 2.6 t/s强行拉到 4096降到 1.8 t/s 且系统内存飙到 30GB随时可能触碰 32GB 天花板。所以我最后把num_ctx 2048定为默认值这是质量和资源占用之间的妥协点。内存计算也有规律Qwen 35B 的每 token KV cache 占用约 0.5MB 到 1MB2048 上下文大概吃 2GB 内存4096 就能吃掉 4GB 以上。显存不够时这些内存占用还得和 CPU 卸载层共享进一步拖慢速度。所以一定要记住本地跑 35B上下文长度是要精打细算的珍稀资源。4.4 本地部署与在线 API 的成本账跑之前我算了笔账35B 模型本机 run 一天假设重度使用电费按 500W 功耗跑 8 小时一天约 2 到 3 元电费。在线 API 讲的是 token 计费以常见的中档模型价格写 3000 字文档约消耗 2 万 token连续算一个月笔电账单可能上百元。长期看本地部署的经济优势明显尤其适合有固定任务量、需求稳定的场景。但这笔账有一个前提硬件已经存在。如果没有显卡和 32GB 内存的先期投入只为了跑 35B 专门配电脑那要把硬件成本摊进每月的折旧里再比较。另外本地部署省的是 token 费没省维护时间折腾新模型、调参、解决 OOM 都是隐性成本。5. 把模型接进知识库让本地模型真正干活5.1 为什么只聊天不够纯命令行聊天更多是炫技真正让本地大模型产生生产力的是把它接进“本地知识库”也就是 RAG检索增强生成架构。思路不复杂用户提问后系统先在本地嵌入模型检索最相关的文档片段然后把片段拼进提示词交给大模型生成回答。这套架构下大模型不需要记住全部知识只要在回答时“看得到”相关资料就行。这个方案对显存紧张的 8GB 环境尤其有价值。35B 模型本身记不住太多新知识但通过外部向量检索可以把最新文档、私有资料、行业术语塞进问答链路相当于给 35B 装了个可无限扩展的外置记忆。5.2 选择配合的知识库工具目前最常用的本地知识库工具是 AnythingLLM 和 Open WebUIDify 则更适合团队化工作流。我这次用 AnythingLLM因为它配置最简单对 Ollama 后端支持成熟下载安装 AnythingLLM 桌面版。LLM 后端选择 Ollama模型选qwen35b-lite。Embedding 模型也选 Ollama 提供的nomic-embed-text或者bge-m3体积很小几百 MB拉取很快ollama pull bge-m3Embedding 模型用来把文本片段变成向量是整个检索环节的基石。选 embedding 模型时注意两点维度太高的模型会吃掉更多内存性能优先选 1024 维以内的中文场景建议用 bge-m3 这类中英双语模型检索质量远好于通用英文模型。5.3 数据准备与向量化流程AnythingLLM 里新建一个 Workspace把需要问答的 PDF、Markdown、TXT 文档拖进去系统会自动完成切片、向量化、存储三步。我这里实际喂了一个 10 万字的内部运维手册普通配置下耗时约 3 分钟。向量化完成之后问答响应流程变成请求进来先由 embedding 模型检索最相关段落再把段落塞给 35B 模型生成回答。这里有个经验——检索出来的相关片段不要太多我实测 3 到 5 个片段效果最佳。片段太多会把上下文迅速填满35B 模型在 2048 上下文下很快失去焦点片段太少又找不到足够的依据。所以知识库切片长度建议控制在 500 到 1000 字之间过长会让单次检索结果太粗。5.4 知识库问答的实测调整配置完知识库后我试问了几轮“公司服务器 SSH 登录出现 permission denied 是什么原因”模型能准确引用手册中的排查步骤回答质量比裸用 35B 高一个档次。说明 35B 模型的推理能力加上外部知识库检索已经接近在线大模型的基础体验。但速度依然受限于模型推理速度。RAG 机制对模型生成本身没有加速效果反而因为要额外等待检索步骤整体延迟比裸模型还高一点点。实际体验是提问后约 10 到 20 秒才开始生成不是 bug是资源紧张下的正常节奏。如果嫌慢可以换 14B 模型配知识库速度能到 10 t/s 左右质量对大多数文档问答也够用。我的建议是知识库问答这种“准确性比文采重要”的任务优先保速度14B 往往比 35B 更实用。6. 常见问题与排查技巧实录6.1 显存不足类问题8GB 显存跑 35B 最常见的报错是error: failed to load model: allocate tensor failed如果你看到这行直接原因就是显存或内存不够。排查顺序检查系统内存是否充足35B Q4 至少预留 24GB 可用内存总内存低于 32GB 的基本没戏。降低num_gpu层数从 40 往 24 调每次 4 层。降低num_ctx2048 降到 1024释放 KV cache 占用。换更小量化模型比如 8B 或 14B。还有一类隐性显存占用来自 Ollama 的预加载机制。如果之前加载过其他模型显存可能还被它占着。可以强制清空ollama stop qwen35b-lite或者直接重启 Ollama 服务干净利落。这个“上一个模型还占着显存”的问题我用 8GB 显存时遇到过好几次重启服务屡试不爽。6.2 生成速度慢或者直接卡住如果模型能加载但输出像乌龟爬优先检查卸载层数。按前面表格num_gpu从 0 调到 32速度能提升近三倍。若已经调到 32 但还是卡顿则要检查系统内存是否还在被其他程序占用。浏览器开几十个标签页、后台编译任务都会抢内存跑 35B 前最好把无关大程序全关掉。另外 CPU 推理速度受内存通道数影响极大。双通道 DDR4 3200 的内存带宽约 50GB/s单通道只有一半不到。如果你用的是第 12 代酷睿配两根不同容量的内存条可能工作在单通道模式下这会让 CPU 卸载部分慢到无语。用 CPU-Z 或任务管理器确认一下内存通道数这个坑不起眼但影响巨大。生成中途卡住不吐字还有一个常见原因模型输出期间 CPU 和 GPU 频繁等待同步。解决方案是降低num_ctx或者干脆减少 GPU 层数让调度更稳定。我在num_gpu 32和num_ctx 2048下偶发卡顿下调到num_ctx 1024后卡顿明显缓解。6.3 模型输出质量差或带莫名限制本地开源模型其实是可控性最高的一类模型角色、输出风格、约束条件全都写在你自己的 System Prompt 里。如果你对输出不满意优先调整这一段提示词给模型明确身份和边界而不是去搜什么“破解提示词限制”的操作。真正的质量瓶颈通常出现在两个地方量化精度不够。q4_K_M 在复杂推理任务上确实比 fp16 差一截如果任务特别讲究推理准确性可以换 q5_K_M 或 q8_0但代价是内存和速度。上下文不足。模型没有看到关键信息时会出现“一本正经胡说八道”解决方法是把需要的资料通过知识库检索显式放进上下文。6.4 多人使用与并发场景的现实回应很多人问“搭建一个 200 人用的本地大模型要多少钱”。这里直接给结论8GB 显卡机器带不动 200 人。35B 模型在单线程下以 2 到 4 t/s 的速度生成一个用户问一个问题就要等几十秒200 人并发会直接让本机资源耗尽。如果真要服务一个 200 人团队至少需要一台多卡服务器双卡甚至四卡 24GB 以上显存配合 vLLM 这类推理框架做并发调度。那是另一套硬件的预算量级跟本篇文章里的单卡玩法完全不是一个赛道。最后再分享一点我的实际体会跑完这轮 8GB 显存 35B 的折腾我的最大心得不是“越大的模型越好”而是“显存不够时模型要用到刀刃上”。在本地部署大模型这件事上量化等级、GPU 层数、上下文长度三者互相牵制任何一个拉满都会让另外两个崩溃。最终稳定可用的状态往往是三者都不饱和的中间值。如果你也准备动手我建议的顺序是先装 Ollama拉一个 14B 模型跑通流程再回来挑战 35B 的 q4_K_M。这样你能更直观地理解“快”和“好”在本地模型中到底要怎么取舍。8GB 显存跑 35B说到底不是追赶什么大模型军备竞赛而是把手头有限的硬件用到极致让个人电脑真正具备离线智能问答和知识管理的能力。下一次再有人说消费级显卡不能碰大模型你可以把这篇文章甩过去。