企业官网建设流程全解析

先说结论：8GB显存跑35B级大模型，不是标题党吹出来的神话，但也绝对不是什么甜头。它是一场把显存、内存、CPU带宽都逼到极限的工程操作。我拿Qwen2.5-32B-Instruct作为“35B级”代表模型，在RTX 4060 Ti 8GB上完整跑了一轮，总共经历了量化选型、参数调优、OOM闪退、速度崩盘、模型乱码这些经典环节，最后稳定在每秒10到20个token的可聊状态。这篇实录会把整条路的账算明白，把关键参数讲透，也把那些视频里绝对不会告诉你的坑一个个晒出来。

如果只是个人自用，想体验“本地跑大模型”的感觉，这篇实录就是一个能直接抄作业的完整过程记录。如果你正在纠结“本地二三十万买硬件部署大模型，到底有没有运维工作量”，那真正适合生产的部署组合是什么、运维成本从哪里来，这篇也会给出答案。

1. 为什么8GB显存能跑35B：先算清楚这笔账

1.1 显存需求的数学账

先说一个最基础的常识：35B参数，如果用最原始的FP16精度保存，光权重文件就是35 × 10亿 × 2字节 ≈ 70GB。就算你有RTX 4090的24GB显存，也一样装不下这种原版模型。8GB显存跑去跑35B，第一反应肯定是“不可能”。

但大模型部署从来不是只能吃FP16。量化技术允许用更少的位数来表示权重，比如8bit、4bit、2bit。按照这个思路往下算：

• FP16（16bit）：70GB
• INT8（8bit）：35GB
• INT4（4bit）：17.5GB
• INT2（2bit）：8.75GB

看到这里你大概就明白了，2bit量化后的权重体积已经压到了8.75GB，跟8GB显存只有一步之遥。顶点出现了。但注意，这只是“权重本身”的体积，真正部署时还要额外付三笔账：

第一笔是CUDA上下文和中间激活值。加载模型进GPU，驱动、运行库、计算图都会占一些显存，通常就有300MB到1GB的空间。第二笔是KV Cache，也就是注意力机制里为每个历史token缓存的Key和Value。上下文越长，这个缓存越肥。假设35B级模型按40层、隐藏维度4096、上下文4096来估算，KV Cache大约要占到2到4GB。第三笔是量化后权重文件本身还带着一堆额外的group scale、zero point之类的辅助参数，2bit并不意味着文件体积精确等于2bit。

所以结论很清晰：单靠2bit量化，35B模型也没有办法干净利落地塞进8GB显存。那为什么还能跑起来？因为还有一个更关键的机制在起作用——GPU-CPU混合推理。

1.2 量化不是万能的，混合推理才是关键

混合推理这个概念，说白了就是“GPU装得下多少层就装多少层，剩下的层放内存里让CPU跑”。llama.cpp里有个参数叫--n-gpu-layers，也可以写作-ngl，它的值决定了模型前多少层被加载到显存里。剩下没加载的部分，会被放到系统内存中，由CPU用矩阵运算一截一截地向前推进。

这个设计像极了以前“内存不够用虚拟内存”的思路。操作系统把一部分不常用的内存页搬到硬盘上，等需要的时候再换回内存。大模型部署里的CPU层，就相当于那种“临时借用外部资源”的兜底方案。区别在于，CPU计算矩阵乘法的速度远不如GPU，而且数据在显存和内存之间来回搬运也要花时间。

实测的时候，我设置了-ngl 22，也就是把35B模型的前22层放到GPU，后18层留在CPU。此时显存占用可以控制在6.5到7.5GB之间，给系统留出余量。模型能跑起来，靠的其实是这种“拆分配置”，而不是某一项单一技术。

这也就是为什么很多人在相同显卡上跑了同样的模型，效果却天差地别。有人用8GB显存跑出12 token/s，有人跑出了不到3 token/s，差距往往就出在-ngl设置、CPU型号、内存类型这些参数上。显卡只是整条链路中的一环，CPU和内存才是真正决定下限的组件。

1.3 8GB显存卡到底适合什么模型？

这里顺便给想入手的同学泼一盆冷水。8GB显存跑35B，能做，但不是最优解。测试下来，8GB显存最舒服、最从容的区间是7B到14B模型。7B模型用Q4_K_M量化之后权重体积只有4到5GB，显存里还能腾出2到3GB做KV Cache，速度可以跑到35到50 token/s，体验非常流畅。14B模型用Q4量化大约8到9GB，需要轻微依赖混合推理，但速度也不会太离谱。35B属于极限操作，是用“能跑”换“跑得好”的典型案例。

如果非要在8GB显卡上跑35B，建议先把心理预期调到“能聊天、能写短文、能跑RAG”的水平，不要指望它能在复杂推理、长代码生成上跟云端API掰手腕。

2. 实测环境与方案选型

2.1 硬件与软件配置清单

这次实测我用的是一套非常典型的消费级配置：

• 显卡：NVIDIA RTX 4060 Ti 8GB（CUDA算力对应Ada架构，CMAKE_CUDA_ARCHITECTURES=89）
• CPU：Intel i5-13400F（6个大核+4个小核，16线程）
• 内存：64GB DDR4 3200MHz

为什么特别强调内存？因为混合推理的方案里，CPU要承担相当一部分层数的计算，内存带宽和容量直接决定模型能不能完整加载。35B模型在Q4_K_M量化后体积约19GB，Q2_K体积约12GB。加上操作系统、浏览器、终端这些杂七杂八的占用，机器上总内存最好不少于32GB。我直接用64GB，除了模型本身，还要给系统的文件缓存留空间。

软件栈方面，我用的是Ubuntu 22.04 + CUDA 12.2 + llama.cpp最新源码编译，另外也装了Ollama做对比测试。Windows上同样可以跑，但llama.cpp需要开WSL或者用官方预编译版，步骤繁琐一些，所以最终全程在Linux下完成。

2.2 为什么最终选了GGUF + llama.cpp

市面上本地大模型推理方案不少，vLLM、Transformers、MLC-LLM、llama.cpp各自都有拥趸。但在8GB显存跑35B这个目标下，很多常规方案直接就死了。

Transformers是加载推理最方便的路子，但它默认会把整个模型按权重全部加载到设备内存，加载一个19GB的Q4模型到8GB显卡上，只会得到一行OOM错误。vLLM的能力很强，做并发推理、PagedAttention都很香，但它的设计目标是把整个模型放进GPU显存，还依赖CUDA Graph这些特性，8GB显存连权重都塞不下，根本没有后续。MLC-LLM可以做GPU加速，但部署复杂度高，可调参数也少。

剩下真正符合8GB场景的就是llama.cpp生态。它的好处有几点：第一，GGUF格式本身就是为CPU+GPU混合推理设计的，可以在层粒度上自由切分；第二，llama.cpp对低内存环境做了大量优化，包括KV Cache量化、内存映射--mlock、批处理参数调优；第三，社区迭代极快，每个新版本都有不少性能改进。Ollama其实也内置了llama.cpp作为推理引擎，只是把底层参数包装成了Modelfile里的几个选项，对不想自己编译的人更友好。

3. 8GB显存部署35B的完整流程实录

3.1 准备模型文件与量化档位选择

这次我用的模型是Qwen2.5-32B-Instruct，算下来跟“35B”属于同量级。真正可下载的GGUF文件通常已经量化好，直接在Hugging Face页面上挑需要的档位。常见档位从大到小依次是：Q4_K_M、Q3_K_M、Q2_K、IQ2_M、Q2_K_XS。Q4_K_M的质量最接近原版，但文件体积达到19GB；Q2_K的文件只有12GB左右，但代价是模型能力明显缩水。

如果没有现成的GGUF文件，也可以从原权重自己量化。先在Hugging Face下载FP16的原始模型，然后用llama.cpp自带的llama-quantize工具转换：

cd llama.cpp llama-quantize /models/qwen-32b-fp16.gguf /models/qwen-32b-q4_k_m.gguf Q4_K_M

这条命令会把FP16原始模型压成4bit精度的Q4_K_M档位，整个转换过程持续几分钟到十几分钟，取决于硬盘读写速度。如果只需要测试能不能跑起来，直接从网上下载已经量化好的GGUF文件更省事。

不过这里有个很多人容易忽略的坑：GGUF文件的Schema版本更新很奇怪，旧版llama.cpp可能读不了新版文件。下载模型前先看一眼自己的llama.cpp版本，尽量用最新的。

3.2 llama.cpp编译与关键启动参数

下载好模型后，第一步是自己编译llama.cpp。CUDA后端编译命令如下：

cd llama.cpp mkdir build && cd build cmake .. -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89 cmake --build . --config Release -j 8

编译完成后，启动命令的核心参数长这样：

./llama-cli \ -m /models/qwen-32b-q4_k_m.gguf \ -ngl 22 \ -c 4096 \ -t 12 \ -b 2048 \ --temp 0.7 \ --repeat-penalty 1.1

这里每个参数都值得展开讲讲。-ngl 22表示把模型前22层放到GPU，这个值需要根据显存余量反复试。-c 4096是上下文长度，默认值可能很大，比如32768，这会直接吃光KV Cache的显存预算，所以在8GB卡上必须手动压到4096或更小。-t 12是CPU线程数，i5-13400F有16线程，实际跑下来12线程比16线程更快，因为物理核心毕竟只有10个，线程太多反而增加调度开销。-b 2048是批处理大小，这个值对生成速度影响不小，但盲目调大也可能增加KV Cache的开销。

首次运行时，日志会明确打印当前显存分配状况。我那次启动日志里有一行大概是offloaded 22/40 layers to GPU，同时显示model buffer size约6.8GB，KV cache size约1.2GB，整体显存用量控制在8GB以内返回。这时候就能看到历史性的时刻：8GB显存确实加载起了35B级模型。

3.3 Ollama方案：不编译也能复现

如果不想碰编译，Ollama是更友好的选择。安装Ollama后，直接用一条命令拉取模型：

OLLAMA_GPU_LAYERS=22 OLLAMA_NUM_PARALLEL=1 ollama run qwen2.5:32b

OLLAMA_GPU_LAYERS就是llama.cpp的-ngl，环境变量指定以后，Ollama会按照同样的逻辑做层切分。如果要在Modelfile里固化参数，也可以这样写：

FROM qwen2.5:32b PARAMETER num_gpu 22 PARAMETER num_ctx 4096 PARAMETER num_thread 12 PARAMETER temperature 0.7

然后执行ollama create my-qwen32 -f Modelfile，以后直接ollama run my-qwen32即可。需要注意的是，Ollama默认可能会把全部GPU显存都占满用于KV Cache，要做好内存和显存资源的取舍。

3.4 首次启动实测记录

第一次启动我用的就是Q4_K_M档位的19GB模型。加载过程大约花了25秒，主要是从NVMe硬盘把19GB文件读进内存，再往显存里推22层。当提示符出现的那一刻，显存占用7.2GB，内存占用约20GB，系统还留着充足余量。

输入“你好，请介绍一下你自己”，模型第一token返回大约耗时2.1秒，之后生成速度稳定在10到12 token/s。作为对比，如果纯CPU推理不加载任何层到GPU，同样的模型只有3到4 token/s。混合推理一下把速度提了三到四倍。

这个速度刷网页聊天勉强算流畅，但不适合做实时交互对话，因为首token延迟太高。如果只是让它输出一个几百字的回复，整体等待时间在十几秒到几十秒之间，还处于“能接受”的范畴。

4. 量化级别与推理性能对照

4.1 不同量化档位的实测数据

同一个模型，在不同量化档位下，显存占用、内存占用、生成速度是完全不同的。我把Q4_K_M、Q3_K_M、Q2_K三个档位跑了一遍，数据整理如下（环境均为RTX 4060 Ti 8GB + i5-13400F + 64GB DDR4）：

这里有个反直觉的现象：量化档位越低，文件体积越小，反而可以把更多层塞进GPU，所以生成速度更快。Q2_K比Q4_K_M快了约30%，代价是模型能力断崖式下滑。这就回到一个老问题：你要的是“能跑”，还是“跑得像样”。

4.2 为什么CPU阶段决定了整体速度

混合推理的模式下，token是一层一层生成的，GPU层跑完把中间结果传给CPU层，CPU层算完再传回GPU层。整个过程中，最慢的那一部分就是瓶颈。

GPU显存带宽通常在200到400GB/s，而DDR4内存带宽只有20到40GB/s，差了接近十倍。35B模型的剩余18层放在CPU这边，意味着每一轮生成都要让这部分数据在内存里被CPU反复读取。模型参数越大，内存带宽越吃紧，生成速度越上不去。

这也是为什么我在前面反复强调内存的重要性。DDR5比DDR4带宽至少高30%到50%，在北京地区某台DDR5机器上实测，同样配置下生成速度可以提升到14到18 token/s。如果再加一条高频率DDR5内存组成双通道，效果更明显。相反，如果机器还停留在DDR3时代，那8GB显存跑的35B模型大概率会卡到每秒一两个token，完全没有实用价值。

4.3 35B被压缩后，能力还剩多少

量化过程的本质是把模型参数里的冗余信息丢掉。35B参数本身就带着大量冗余，压缩到4bit还能保留大部分语义能力，压缩到2bit就会伤筋动骨。实测时我专门做了几个对照：

让它写一段Python快速排序代码，Q4_K_M能给出结构完整的实现，Q3_K_M勉强能看，Q2_K则开始丢缩进、乱命名变量。让它解一道一元二次方程，Q4_K_M能正确套用求根公式，Q2_K偶尔会把符号算反。让它总结一篇三百字短文，Q4_K_M基本忠实还原要点，Q2_K输出更简短但会漏掉细节。

35B模型在4bit下，仍然能感受到“大参数量的底子”。同样7B模型在4bit下可能就达不到那么细的推理深度，但35B模型哪怕被压缩到4bit，因为参数量本身够大，留给语义表达的知识容量还是比小模型多。这也是为什么有人宁愿跑得慢一点，也要在8GB显存上坚持跑35B，目标就是那一点“大模型味”。

4.4 不同任务场景的实际表现

为了不纸上谈兵，我用三个典型场景做了速测。

代码生成场景里，我让它写一个带注释的FastAPI接口，Q4_K_M档位输出大约用了35秒，给出了完整的路由定义和参数校验逻辑，基本能直接拷进项目里改一改。速度慢是慢，但效果比预期好。这让我很惊喜，说明35B模型的代码能力被4bit量化保留了大半。

长文本总结场景中，我把一篇1500字的技术文章喂进上下文，要求它输出摘要。它能够理解整体结构，但输出过程中在第三段附近出现过一次轻微重复，需要--repeat-penalty拉高到1.15来压制。这与KV Cache长度有关，毕竟8GB显存下的上下文预算只有4096 token，长文本处理本就捉襟见肘。

多轮对话场景里，聊到第八九轮时开始出现上下文遗忘，它会重复回答同一个问题。这是KV Cache被截断造成的，随着长度逼近4096 token，模型被迫忘记更早的内容。想缓解，要么接受现实，要么牺牲速度去扩大上下文，鱼与熊掌不可兼得。

5. 本地部署的运维真相与常见坑

5.1 运维工作量：不是没有，但可以控制在合理范围

热搜里有人问“如果本地花二三十万买硬件部署大模型，会有运维工作量吗”，我的实话是：只要模型跑在自己的机器上，运维工作量就存在，只是大小深浅的问题。

个人场景下，这套8GB跑35B的方案，运维成本主要是三块。一是模型与推理框架的版本升级，llama.cpp几乎每周都在变，性能优化和安全更新都靠手动拉新编译。二是异常处理，比如OOM崩溃、断点续跑、显存泄漏，这些都无法完全避免。三是数据备份和模型文件管理，GGUF动辄十几个GB，换一个量化档位就要重新下载大文件，磁盘空间规划也是真问题。

200人团队的生产环境完全是另一量刑级。单张8GB卡连并发都支撑不了，同一时刻只能处理一个请求。一旦有多人同时访问，必须上多卡、做请求队列、加API网关，光这一套基础设施的软硬件加起来就远超单卡成本了。运维工作量也随之从“个人折腾”变成“专职岗位”。

所以我的建议非常明确：个人自用或者小团队内测，这套8GB方案可以玩得风生水起。真要服务200人，就别省这个钱，要么老老实实上几张专业卡搭推理服务，要么用现成API更划算。

5.2 常见问题速查表

5.3 避坑经验：几个容易踩碎的小细节

第一，别把-ngl当越大越好。我之前在Q4_K_M档位尝试-ngl 35，显存直接爆掉，系统花了几十秒用swap硬扛，速度掉到2 token/s。正确的做法是从-ngl 10开始，每加两层重启一次看占用，直到刚刚好留出约500MB显存余量。

第二，--mlock这个参数值得开。它能把模型加载过程中使用的内存页锁在物理内存里，防止操作系统的内存交换机制把模型页面挪到硬盘上导致卡顿。在llama.cpp里默认不会开，建议加上。实测同样配置下，开启--mlock的生成速度大约能提升8%到10%。

第三，别小看模型文件存放的位置。第一次我把19GB的GGUF放在一块老旧SATA硬盘上，光加载就花了2分钟以上，换到NVMe SSD后直接降到25秒。现代大模型部署对硬盘速度极其敏感，有条件一定放NVMe盘。

第四，Windows用户的WSL环境里，CUDA调用默认可能走的是虚拟显存路径，而不是直接访问宿主机显卡。这种情况下llama.cpp虽然能跑，但性能可能只有原生Linux下的七成。真想省心，直接在Windows上用Ollama或者LM Studio更实在，别跟WSL较劲。

6. 延伸玩法：本地知识库与API封装

6.1 用本地模型搭个人知识库

35B模型跑在本地，最大的意义不只是聊天，而是隐私数据不出机器。配合向量数据库和RAG流程，可以做一个完全私有的知识库助手。

链路大概是：先有一批PDF、TXT、网页文档，用Embedding模型把它们切成小块并向量化，存进向量数据库。用户提问时，系统先把问题向量化，在向量库里检索出相关的文档片段，拼进Prompt里，再交给本地大模型生成回答。这整套流程在Ollama上都有现成工具。比如AnythingLLM或者RAGFlow，都支持把Ollama作为底层模型，配置起来只要在界面上填上Ollama地址和模型名。

但有一点要提醒：35B模型的上下文只有4096 token，用来塞知识片段非常紧张。一个标准RAG的Prompt往往包含“系统提示词+用户问题+检索到的文档片段+历史对话”，随便一拼就可能超过2000 token。留给知识片段的空间越小，应答质量越差，所以做知识库时最好把正文分块控制在500到800字符以内，别贪多。

6.2 用一个API让其他程序调用本地模型

Ollama默认会启动一个本地服务，监听11434端口。这意味着你的本地模型可以像一个私有API一样被其他程序调用：

curl http://localhost:11434/api/chat -d '{ "model": "qwen2.5:32b", "messages": [ {"role": "user", "content": "用三句话解释一下什么是RAG"} ], "stream": false }'

返回结果是标准的JSON格式，OpenAI兼容的接口在/v1/chat/completions路径下也有支持。也就是说，你完全可以写一个小工具，把本地35B模型接进自己的博客后台、微信机器人、自动化脚本里，让它充当一个不用付费、不出内网、不泄漏数据的“AI秘书”。

我自己就搭了一个命令行工具，把Ollama和RAGFlow串起来，早上把当天的新闻摘要喂进去，让模型帮我整理成要点清单。虽然生成速度只有每秒十几个token，但胜在每次调用完全免费、数据全部留在本地，那种“私有化智能体”的安心感，是云端API难以替代的。

说到底，8GB跑35B这件事，本质是“工程挪移”而不是“物理奇迹”。用低比特量化压缩模型体积，用层切分让CPU和GPU分头干活，再用合理的上下文和批处理参数把硬件资源榨干，整套路径是可以复现的。我个人跑完这一轮的最大感受是：如果你只是想证明“消费级硬件也能摸到大模型的门槛”，这件事值得一试；如果你想要真正的应用体验，升级CPU和内存带来的收益远大于折腾显卡本身。先把手头显存和内存的账算明白，再决定要不要走这条路，能少走不少弯路。