企业官网建设流程全解析

8GB显存跑35B模型？第一反应都是：你在开玩笑吧。35B参数意味着模型权重在FP16精度下要占70GB，就算量化到4-bit也要接近20GB，8GB的显存连个零头都装不下。但这事确实能做，只是要用一种“慢工出细活”的姿势——让权重躺在内存里，显存只承载一小部分计算单元。这篇文章记录我在一台搭载RTX 4060 8GB的机器上，完整跑通Qwen2.5-32B和Command R 35B的本地大模型部署实测，包括每个参数怎么调、速度能到什么程度、哪些环节最容易翻车，以及最后的真实体验总结。如果你手头也是一张8GB消费级显卡，想横跨大模型本地部署的门槛又担心显存不够，这篇文章值得你花十分钟看完。

1. 为什么“8GB跑35B”听上去像个伪命题

1.1 先算一笔账：35B模型到底有多大

模型大小这件事，圈外人经常低估。所谓“35B”，指的是模型有350亿个参数。每个参数如果按FP16（半精度浮点数，2字节）存储，那就是350亿乘2字节，约等于70GB。这是什么概念？一张RTX 4090 24GB都装不下，更别提8GB的RTX 4060、3060、3070这些消费级显卡了。

就算压缩到8-bit量化（Q8），也要大约35GB。压到4-bit量化（Q4），才能降到20GB上下。即便是牺牲质量很明显的Q2量化，35B模型也要约13.5GB的文件体积。所以你看到的第一道数学题就是：8GB显存装下20GB的模型，理论上不可能。

这也是绝大多数人一听“8GB跑35B”就直接摇头的原因。他们默认了一个前提：模型必须完全塞进显存才能跑。但本地推理框架早在几年前就给出了另一条思路——CPU也能算，只是慢。

1.2 量化和KV Cache：让模型“瘦身”的两把刀

模型能跑起来，靠的是量化（Quantization）。这个概念可以粗暴理解为：把原本2字节存一个权重，压缩到4比特甚至2比特存一个权重。重量没变，精度变了——就像把一张高清照片从专业RAW格式存成压缩JPG，肉眼看大部分场景没区别，但放大到细节就会有噪点。

现代量化方法（比如llama.cpp生态里的K-quant系列）并不是简单地把所有层一刀切压到4-bit，而是对模型里不同层做差异化处理。注意力层、输出层这种对精度敏感的层保留更高精度，部分中间层用更激进的压缩。这也是为什么Q4_K_M在今天几乎是“质量与体积平衡点”的代名词。

另一个吃掉显存的大头是KV Cache。推理时，模型要记住已经生成的上下文内容，这个缓存会随着对话长度线性增长。同样是跑35B模型，上下文开4096 tokens和开8192 tokens，KV Cache占用的显存/内存完全是两个量级。很多人在小模型上习惯了长上下文，跑到35B上发现同样的参数配置直接OOM，根源就在这里。

1.3 层卸载：让CPU和GPU分工干活

真正让“8GB跑35B”变成现实的，是层卸载（Layer Offloading）机制。这个思路特别直白：把模型的64层Transformer层拆开，能放进显存的前N层给GPU算，剩下放不下的层丢给CPU去算。GPU负责一部分计算，CPU负责另一部分，中间通过系统内存交换数据。

这样做当然有代价。GPU算力和CPU算力差距悬殊，GPU算完一批数据要等CPU慢慢爬，整个生成速度会被CPU拖到很低。但优点是——它能跑。在显存不够的大模型推理场景里，“能跑”比“跑得快”重要得多。我的实测里，Ollama（基于llama.cpp推理引擎）在8GB显存上自动分配约20层给GPU，剩下的层全部走CPU。生成速度确实感人，但在“一次性生成长篇内容”这种场景下完全可以用。

2. 模型怎么塞进去：量化等级与显存腾挪的数学账

2.1 为什么我选了Qwen2.5-32B和Command R 35B当测试样本

先说模型选择。35B这个档位里，目前本地部署社区最常接触的两类模型是：阿里的Qwen2.5系列（32B版本虽然标称32B，发布到Ollama仓库后常按35B量级讨论）和Cohere的Command R系列（官方标称35B）。两个都是开源的、中文能力出色的模型，而且社区里量化版本非常齐全。

我个人测试主力是Qwen2.5-32B-Instruct。原因很简单：它的中文语料和指令遵循能力在开源模型里属于第一梯队，而且Ollama官方库直接提供“qwen2.5:32b”这个标签，拉下来就是Q4_K_M量化版，对小白特别友好。Command R 35B我也顺手测了，特点是对长文档的理解和RAG场景更强，但中文生成的自然度略有不如。

还有一个关键因素——这两个模型在8GB显存的机器上，能跑出“有实际使用价值”的结果。那些动辄70B、上百B的模型，用8GB显存硬跑不是不行，但速度会掉到每秒0.5 token以下，那就真的没法用了。

2.2 Q4_K_M和Q2_K：选哪个量化等级

这是我在部署过程中最纠结的一个选择。量化等级直接决定了模型文件大小、速度、质量三者之间的关系。我做了个实测对比表，数据基于我的机器（RTX 4060 8GB + i7-12700K + 32GB DDR4双通道）：

看到这个结果你可能会问：那为什么不直接用Q2_K？速度更快，GPU能多塞好几层。答案是质量。Q2_K在长文生成和复杂推理场景下，会出现明显的语句重复、逻辑断裂、中英文混杂等问题。我拿一段需要分点论述的产品分析题测试，Q2_K版本给出的答案结构明显松散，甚至出现前后矛盾。Q4_K_M虽然慢，但生成质量稳定得多。

我的最终建议是：如果机器能凑够32GB以上系统内存，优先选Q4_K_M；只有内存实在不够、跑不起来的时候，才降级到Q2_K。别为了那每秒1个token的速度提升牺牲模型质量，得不偿失。

2.3 用Modelfile把GPU层数写死

Ollama默认会根据自己的逻辑决定加载多少层到GPU，但这个自动决策不一定最优。更可控的做法是写一个Modelfile，用num_gpu参数把GPU层数写死。

我最终的Modelfile长这样：

FROM qwen2.5:32b PARAMETER num_gpu 20 PARAMETER num_ctx 4096

这里num_gpu设为20，是因为在8GB显存上，加载20层Q4_K_M量化后的模型权重后，显存剩余空间刚好够一个4096上下文的KV Cache。如果强行调到25层，会有一部分数据溢出到共享显存（Shared Memory），不仅不会变快，反而因为显存和内存之间的频繁交换导致速度倒挂。这是我实测踩过的坑：num_gpu调到26时，生成速度反而从3.0 token/s掉到了1.8 token/s。别贪，适可而止。

3. 部署实操：Ollama的CPU+GPU混合推理调优全记录

3.1 环境清单与安装注意事项

先把硬件环境说清楚。我用的是一台2023年组装的台式机：CPU是i7-12700K（8个性能核+4个能效核，16核20线程），内存32GB DDR4双通道3200MHz，显卡是RTX 4060 8GB，系统是Ubuntu 22.04 LTS，驱动版本550.54.15，CUDA 12.4。这套配置在今天算是中端偏下的水平，但消费级硬件的典型代表。

部署工具用的是Ollama。安装本身没什么难度，Linux一行命令：

curl -fsSL https://ollama.com/install.sh | sh

Windows和macOS也有对应安装包，但实测下来，Windows版本的Ollama在CPU+GPU混合推理时的调度略逊于Linux版，同样的模型和参数，Linux下能多出0.5~1个token/s的速度。如果你有Windows和Linux双系统，强烈建议在Linux下跑大模型。

装好后拉模型：

ollama pull qwen2.5:32b

这一步会下载约20GB的模型文件。如果你之前的Ollama版本在别处用过，记得先注意默认模型存储目录。Linux下默认在/usr/share/ollama/.ollama/models，如果你的系统盘空间不够，需要先改存储路径再拉模型。当初我没注意，直接把系统盘塞满了，后来清理起来特别麻烦。

3.2 首次启动：内存不足的教训

我第一次跑这个模型是带着一脸自信的。结果ollama run qwen2.5:32b刚输入指令，终端就报了个错：Out of memory。当时机器上挂着浏览器几十个标签页、还有一套IDE，32GB内存一下子被吃了大半，模型加载到一半系统就扛不住了。

这个教训很重要：去系统内存不够充足的情况下，跑35B模型几乎必挂。为什么？你把这个模型看成一个住在仓库（系统内存）里的巨人，GPU只是他偶尔过来用的工作台。仓库本身就得够大，才能放得下这个巨人。Qwen2.5-32B的Q4_K_M模型，加载时需要约20GB空闲系统内存，再加上KV Cache和系统本身的开销，32GB内存的机器理论上刚够，但如果你同时开着浏览器之类的应用，就悬了。

解决办法很简单：先把大程序关掉，给模型腾出至少26GB空闲内存。如果想跑得更舒服，64GB内存是更好的选择——别笑，很多跑大模型的人最终都会升内存和加强CPU散热，因为模型一跑就是几十分钟，CPU全程满载。

3.3 速度实测：从2 token/s到稳定3 token/s的调优过程

首次成功启动后，我做的第一件事是测速。输入一个简单的“你好”，模型思考了大约20秒才吐出第一个字，然后以每秒2字左右的速度往外蹦字。说句实话，第一次看到这个速度，我心里是凉了半截的——这能用？

但冷静下来后发现，这个“慢”要分两头看。首字延迟高，问题出在“Prompt处理”（prefill）阶段。CPU要把你输入的全部文本逐字过一遍35B模型，这本来就是最重计算的阶段，CPU跑这个阶段尤其吃力。后续逐字生成（decode）阶段反而快一些，因为每次只处理一个token。实测下来，一段500字的中文输入，prefill阶段需要40到60秒，后面生成阶段稳定在2.5~3.0 token/s。

我做了几轮调优，总结下来三个有效的操作：

第一，把OLLAMA_MAX_LOADED_MODELS环境变量设为1，保证所有内存优先给当前模型。第二，在Modelfile里把num_ctx从默认的2048调大或者调小要视情况而定——日常问答2048够用，但如果你要让它生成长篇内容，4096到8192的上下文能避免写到一半忘记前面内容。需要注意：num_ctx每翻一倍，KV Cache的内存占用也会显著增加。第三，如果机器有多个CPU核心，Ollama默认使用全部核心，这个不用额外调。

最终的稳定配置是：num_gpu 20、num_ctx 4096、内存空闲26GB以上。在这个配置下，模型的prefill时间缩短到35秒左右，生成速度稳定在2.8~3.2 token/s。虽然还是慢，但至少属于“能等的范围”。

4. 跑起来之后：速度、质量与上下文窗口的三维实测

4.1 和8B模型的速度对比：直观感受差距

光说35B跑得慢没有参照感。我在同一台机器上顺手跑了一个8B模型（qwen2.5:7b，Q4_K_M），对比结果非常直观：

8B模型的速度是35B的十几倍，首字延迟更是天壤之别。如果你追求的是实时对话体验，8B完胜。但问题在于——对话体验只是大模型应用的一个维度。当你让8B模型写一篇三千字的技术方案时，它往往写到中段就开始重复观点、逻辑混乱，甚至出现明显的事实错误。35B虽然慢，但它的输出质量足以支撑一篇结构完整的文章，这就是巨大的差异。

有一次我让两个模型分别写一份“本地部署大模型预算方案”，包含硬件选型、带宽规划、GPU配置建议，要求分五个部分。8B模型写出来的内容框架基本对，但细节上出现“推荐使用16GB显存即可支持70B模型”这种明显错误。35B模型不仅给出了合理的显存估算，还补充了内存带宽对推理速度的影响，逻辑链完整。质量差距，在这一刻体现得淋漓尽致。

4.2 生成质量的差异：慢一点，但脑子更清楚

我做了几组针对性的测试，覆盖长文生成、代码编写、逻辑推理三类场景。长文生成方面，35B模型能稳定输出两千字以上的结构化内容，章节之间有自然的逻辑递进；8B模型五百字之后就开始露馅，经常车轱辘话来回说。

代码编写方面，让两个模型写一个Python脚本来读取CSV并进行数据清洗。8B模型给出的代码结构简单粗暴，边缘情况处理粗糙；35B模型则主动考虑了文件编码问题、空值处理策略和异常捕获，代码可直接跑通。

逻辑推理方面差距最明显。我出了一道经典的三段论推理变种题，8B模型绕了几圈给出了错误结论，35B模型虽然花了更长的时间，但推理链条完整，最终答案正确。在测试过程中我还注意到，35B模型在被指出错误后，认错并修正的能力明显更强，而8B模型容易陷入“固执己见”的循环。

这也印证了我的一个判断：模型参数的规模，本质上是智力的上限。小模型靠技巧弥补，但在真正的复杂任务上，硬差距无法靠提示词工程抹平。

4.3 上下文窗口是一个隐藏杀手

很多人部署本地大模型时只盯着显存，忽略了KV Cache对上下文的消耗。我在测试长对话时发现，把num_ctx从4096调到8192后，模型可用的显存和内存占用明显增加，系统内存从26GB上升到30GB左右。如果同时开多个会话，内存直接飙到32GB以上，系统开始疯狂swap，速度跌到1 token/s以下。

有个简单的经验公式：KV Cache占用的空间主要取决于层数、上下文长度和量化精度。35B模型的层数多，KV Cache膨胀得比7B模型快得多。你在7B模型上开8192上下文没问题，但35B模型上同样配置就可能让整机变得极其卡顿。在做长文档处理时，建议一次不要塞太多文本进去，分段落喂，或者把上下文控制在4096以内，速度稳定性和内存支出都能接受。

5. 这一路踩过的三个坑：模型文件、内存瓶颈和性能过热

5.1 模型文件下载中断与校验问题

如果你网络条件一般，拉取20GB模型文件很可能会遇到中断。Ollama的pull命令本身支持断点续传，但之前版本在中途失败后，会出现一个非常隐蔽的问题：模型文件已经下载了一部分，但ollama pull重试时没有接着下载，反而从头开始，导致你花两倍时间。

解决办法是每次pull失败后，先检查模型的存储目录，把未完成的临时文件删掉，然后重新执行pull。虽然不能做到真正断点续传，但至少避免了几次重复下载。我还发现，Ollama对下载完成后的模型会做一致性校验，如果之前下载损坏，启动时会直接报错告诉你文件不完整。遇到这个报错，别瞎折腾，直接删了重新拉。

5.2 内存带宽决定了速度天花板

这是我整个测试过程中最核心的一个认知刷新。以前我以为CPU跑大模型慢是因为CPU算力弱，后来发现，真正的瓶颈是内存带宽。

CPU推理大模型的计算过程可以简化理解为：每生成一个token，都要把模型的所有权重从内存读一遍，进行一次大规模矩阵乘法。如果你的模型是20GB，内存带宽是25GB/s（DDR4双通道），那么理论最大速度就是20GB除以25GB/s，约等于1.25 token/s。实测中我的机器能跑到3 token/s，是因为GPU分担了部分层的计算，只有约一半的权重需要CPU从内存读取。

这也解释了为什么那些跑大模型的老玩家总在强调“双通道内存”“DDR5”“高频内存”。内存带宽从25GB/s提升到45GB/s，CPU推理速度几乎能翻倍。如果你手头有预算升级，换高频内存带来的收益比换CPU更明显。

5.3 长时间推理的散热和功耗问题

35B模型一跑就是几十分钟，CPU全程吃满，这时候散热问题会直接反馈在速度上。我的i7-12700K用的是240水冷，正常桌面用温度五十度出头，跑模型十分钟后直接冲到八十五度以上。CPU过热降频后，生成速度从3.0 token/s降到2.3 token/s，体验很明显。

我自己试了两个方案：一是在BIOS里把PL1功耗墙从默认的125W拉高到180W，让CPU能更长时间维持高频；二是给机箱加了一把后置风扇，改善整体风道。效果立竿见影，温度从八十五降到了七十五左右，速度也稳定了一些。冬季测试天气冷可能不明显，但夏天高温环境，这一步几乎必须做。

如果你用的是笔记本跑大模型，这个问题会更严重。笔记本的散热余量本来就小，CPU长时间满载时，温度墙会把频率压得死死的。实测一部2023年的游戏本（i9-13900HX + RTX 4060 Laptop），跑同样的35B模型，速度只有桌面平台的三分之二。笔记本用户想跑大模型，建议先考虑外接散热底座，或者直接放弃这个念头转战云API。

6. 我的结论：8GB跑35B到底图什么

6.1 这方案适合谁，不适合谁

经过将近一周的实测和调优，我的结论是：8GB显存跑35B模型，适合那些对输出质量有硬性要求、但对反馈速度不敏感的人。典型场景包括：离线生成文档初稿、在无网环境做知识库问答、处理敏感数据不能上云、批量生成结构化内容。这些场景的共同特点是——输出内容的质量比响应速度重要得多，你完全可以让它跑着，去倒杯水再回来看结果。

不适合的场景也很明确：实时聊天、高频交互、需要快速确认答案的工具型应用。35B模型在我机器上的首字延迟接近半分钟，这种等待在日常对话中根本无法忍受。如果你需要的是聊天机器人这种体验，老老实实用7B或14B模型，全GPU推理的流畅度完全不一样。

另外提一句成本。用8GB显卡跑35B模型，电费不是大头，时间成本才是。生成1000个token大约需要5到6分钟，如果你一天要处理上万字的文本，这套方案会让你怀疑人生。这时候租一台带24GB或48GB显存的云服务器，按小时计费跑批任务，性价比反而更高。

6.2 我个人的最终建议

折腾完这一轮，我对“消费级显卡跑大模型”这件事有了更清醒的认识。8GB显存跑35B模型，不是不行，但它是一种很有姿态的用法——你接受了速度上的妥协，换来了“在自己机器上跑出大模型顶级质量”的体验。如果你是玩家心态，享受折腾过程，那这套方案值得一试。它让你深刻理解量化、显存管理、CPU推理这些概念，远比直接调用API来得有意思。如果你只是为了干活，预算又不缺，那我还是建议换个思路——二手3090 24GB已经是性价比之王，一步到位，不用受这份罪。

最后给已经决定开跑的你一点实操经验：先去检查内存够不够，再去想显存怎么分。别一上来就抄别人的Modelfile参数，每台机器的CPU、内存带宽、散热条件都不一样，跑一轮速度测试再定num_gpu值，找到你自己的平衡点。

这个内容后续还可以怎么扩展？我觉得挺值得尝试的是再往下挖一挖——给这套8GB配置接上Open WebUI或者本地知识库，做成一个完全离线的私有问答系统。数据不用出机器，速度慢一点但完全可控，用起来又是另一种踏实感。