随着大模型在编程场景的广泛应用，个人用户也面临着token计费上涨和隐私泄露等挑战，本地部署模型成为趋势。本文从工程化视角出发，分析了个人电脑部署大模型的可行性，重点讨论了模型选择（如Qwen3.5/3.6、Gemma4）、硬件方案（显卡与显存配置）、量化方案（Q4_K_M、IQ、IQ_KT、EXL3）及推理框架（llama.cpp、ExLlamaV3）的选择，并探讨了显存扩充和kv-cache量化等进阶方案，为个人用户在资源受限的环境下部署大模型提供了实用指南。

---

第一部分:背景大模型/agent的成熟

自从以claude code为代表的编程agent成熟起来以后,coding场景就成为大模型的重度使用场景。而由于特殊的情况，又衍生了被称为御三家的细粮，和这边的，阿里千问，智谱GLM，月之暗面MinMax(DeepSeek V4刚发布，小米的感觉在coding场景的重度用户不多)等粗粮。细粮的意思是细节更完善，使用更丝滑，意图理解更深入完整，输出质量更高。这其中模型的水平占据一部分影响，接下来就是agent和其插件等构成的工程能力，以及和模型的配合密切程度了。

从软件工程角度讲，如今的编程agent+大模型,已经将软件开发带入了面向AI的软件工程的时代，也就是已经超越了vibecoding层次了，而相对应的，模型提供商，也迎来了他们的春天时代。随着token使用量的迅速上升,有一个很重要的变化就是这边的coding plan逐步被取消，转而以token计费方式为主,这固然其中有部分因素是由于以openClaw为代表的龙虾类agent对于token使用的毫无节制,也在于在coding agent场景下,基本也是使用的大模型的深度思考模式,以及在agent中也是以plan方式为主,就是先完成详细的代码草稿,审阅并定稿，再交给agent 执行,这其中token的消耗也是远远高于日常的简单提问对话的。

那边的御三家固然好，但是要么购买转发调用的，要么拼套餐，当然了，如果你们公司给直接开通无限量，那最好了。但是费用上涨，尤其是coding plan类的收紧，或者取消，毫无疑问会给个人使用者带来不小的影响。这种情况之下，能否使用本地部署模型来进行coding?

另一个促使本地部署模型的动因就是隐私问题.在使用厂商/api服务商的服务时,本地的信息会大量的被喂给模型。不管是代码还是个人的其他工作产物。目前这个方面是属于灰色地带的。

还有一个场景就是对于使用openClaw类的个人工作处理类agent时,其带来的高消耗量，以及可能涉及到敏感信息安全，也会考虑需要本地部署。

在这个部分的最后，需要说明下，本文不会涉及任何使用ollama的内容,本文是面向工程化视角，面向在实际的任务背景下本地场景部署大模型的，并在在这边网络访问等条件约束下，直接使用推理框架部署，更为直接。

第二部分:本地部署的模型选择

本文中的本地部署，特指个人在日常办公电脑尤其是笔记本电脑的部署，其中的内容也适用于台式机。所以，针对于购买专门的AI算力服务器不在本文讨论之列，其参考主流推理引擎的部署指导即可。

个人部署时，面临的第一个问题就是硬件资源受限,所以，模型的选择就比较关键。好在世界总有带回给你光芒的人,在大模型的能力越来越成熟，参数量越来越高的背景下，仍然有厂商没有忘记个人用户，发布同代了小参数量的模型。从目前能够获取的开源模型来看,qwen3.5,qwen3.6,和gemma4,是可供选择的.下面是几个模型的基本信息：

维度	Qwen3.5	Qwen3.6	Gemma 4
发布方	阿里巴巴·通义实验室	阿里巴巴·通义实验室	Google DeepMind
发布时间	2025Q4	2026 Q1	2026 H1 (预测)
模型类型	稠密 + MoE 混合	稠密 +MoE 增强架构	MoE 轻量架构
参数规格	0.5B / 3B / 7B 9B/ 27B/35B-A3B /122B-A10B/397B-A17B	27B / 35B-A3B / 满血版未开源	E2B ( 5.1B-A2)/ E4B(8B-A4.5) / 26B-A4B / 31B
专家总数	256-256	256-512	256
激活专家数	10 个路由专家 + 1 个共享专家	10 个路由专家 + 1 个共享专家	8
上下文长度	27B及以上256K	256K	256K
支持语言	100+ (中英优化)	100+ (中英增强)	40+ (英文优先)
开源协议	Apache 2.0	Apache 2.0	Gemma Terms v2 (商用需注册)

个人本地部署时,因为内存的限制，需要选择小参数量的版本。以qwen3.5为例,下面是不同版本的大小信息:

版本	架构	总参数	激活参数	上下文	原始大小 (FP16)	Q4_K_M 大小
27B	MoE	27B		256K	~54 GB	~19 GB
35B-A3B	MoE	35B	~3B	256K	~70 GB	~23 GB
122B	MoE	122B	~10B	256K	~245 GB	~88 GB
397B	MoE	397B	~17B	256K	~810 GB	~285 GB

可以看出，原始的FP16大小,对于122B和397B来说，普通单机的显卡显存是很难容纳的，即使是Q4_K_M量化的，也只有35B和27B存在单张显卡容纳权重的可能性.

同时，推理时上下文长度和KVCache的大小正相关。计算公式为：

mem_KV = 2 × batch_size × seq_len × (hidden_size / num_heads) × num_kv_heads × num_layers × dtype_bytes(byte)

其中batch_size是推理时批次大小，是可调的，最小为1(仅服务单个用户)，seq_len是输入和输出的总长度，dtype_bytes是进行量化处理时的大小。以qwen27B为例,设本地部署场景下用到最大上下文256K时(极限)，kv-cache大小约48GB(BF16),以32K上下文计算时也有6GB.如果进行Q8量化,则需要3GB.

就模型的性能和大小的考虑而言，对于个人部署的场景，Q4量化后在24GB以下为好，同时，模型的参数量不能太小。也就是在尺寸大小可以具备部署条件的情况下，参数量大，会更好。所以，可以选择的范围就是qwen系列的35B，27B和gemma4的26B，31B。

接下来，需要说明的是qwen的35B是moe架构的，27B是dense架构的；而gemma4恰好相反,26B是moe的，31B是dense的。moe和dense之间的选择，主要考虑显存是否充足。因为moe架构的模型是部分激活的,模型的后缀AxB就是激活XB的专家权重.因为是部分激活，所以，在显存不能完全容纳，需要卸载到CPU/内存时,受到的影响会更小。

由于qwen3.6版的27B/35B已经开源,所以,在qwen系列选择中应当选择3.6版本。而在gemma4和qwen3.6的选择中，由于qwen的旗舰版本是397B的,那么，其35B/27B版本，在训练数据集和技术上会具有同源性，其性能上限会高于纯小模型gemma4，而基准测试也表明了这一点。

第三部分：硬件方案

对于大模型的推理而言，毫无疑问，算力和显存大小是最为关键的，而在个人的笔记本上部署，恰恰，这两个也是最受限的，并且难以同时得到最优解。

先说显卡，或者说是GPU：nvidia,intel/amd。因为，对于intel/amd的新款集成显卡才具备基本的本地部署算力，intel的酷睿ultra系列388H/358H/338H处理器，amd的ai max 395/392/390/385处理器。其中单独计算gpu算力的话，intel的处理器的gpu算力,领先于amd的同档次处理器。

对于nvidia来说，肯定是独立显卡了，基本上rtx30系列的算力，就能满足需要了。

接下来需要面对显存的问题。对于笔记本电脑来说，如果是nvidia显卡,那么显存以8G或者更少居多，高于8G显存的,可以说都是偏高档的机器。但是大模型对于显存的需求可以说远大于游戏，所以，对于独显的笔记本电脑来说，显存问题的解决，要么购买大显存的(16GB)的型号，要么，就选择amd ai max或者intel 3x8H处理器的笔记本。还有一种选择就是针对rtx30系列显卡，到专业门店，更换显存颗粒,将显存从8G升级到16GB

amd ai max或者intel 3x8H处理器可以说是针对于ai潮流而推出的，诚然，他们的图形处理能力也相比已前有了大幅度的提升，但是和nvidia相比，如果为了游戏或者做图而选择这两种类型的笔记本，只能说是仅仅可用，因为相比同代的nvidia独立显卡，还是要弱许多。为什么说是针对ai潮流，就是它们都具备了统一内存技术，也就是显示核心，和cpu核心共用内存控制器mmu单元，高速的访问系统内存，把系统内存作为显存。比如如果系统内存是128GB，则amd处理器可以分配最多96GB内存作为显存.也就是3/4的内存作为显存，而intel的3x8H处理器平台也最多可以分配87%的内存作为显存，当然，操作系统需要保留足够的内存给自己和应用使用。

统一内存技术可以说是为ai而生的，在ddr5时代,内存带宽的提升，使得主存的带宽差距和显卡显存不再那么大，更可以充分利用内存作为显存，在ai场景下，对于需要大量显存来加载权重和存放kv-cache的需要来说，无疑是一场及时雨。但是呢，另一面，统一内存的机型定位，以及内存价格的走高，在让相关的产品价格居高不下。ai max系列，32G内存的价格在9000上下，配备64G内存的华硕系列，价格在一万三左右，而128G内存的幻则来到了23000左右。如果选择32GB的内存配置,则需要进行低比特量化，否则系统内存会很紧张.

而在intel的3x8H平台方面，情况也很不乐观：虽然其gpu算力很好，但是芯片产能感人，供应量少，推出的产品内存最大也只有32GB的版本。即便如此，其中的高配机型，如thin boor pro的358H版本，价格和amd的 ai max相差无几。并且没有更大的内存的机型可以选择。

下面针对显卡的选择和显存情况，及模型部署方案进行整理

显卡类型	显存大小	可用部署方案	备注
nvidia	8G	板载显存扩容到16GB	需要到专门的店铺扩容显存
nvidia	8G	35B量化(低于等于Q4)混合推理	混合推理是将moe专家卸载到内存，计算通过cpu进行
nvidia	16GB	35B量化(低于等于Q4)混合推理/27B量化(低于Q4)完全显存推理
amd ai max/intel 3x8H	32GB	35B量化(Q4)完全显存推理/27B量化(Q4)完全显存推理
amd ai max	64GB	35B量化(大于等于Q4)完全显存推理/27B量化(大于等于Q4)完全显存推理
amd ai max	128GB	35B完全显存推理/27B完全显存推理/122BQ4量化推理

第四部分:模型的量化方案选择

在第三部分中，除了128GB顶配场景，其它场景均涉及量化。当然了，128GB场景仍然可以对大尺寸模型进行量化，在目前，由于量化水平的进步，Q4量化对于精度损失已经很小了，而且新的Q4_K_M量化采用的是动态量化，对于激活部分采用更高比特量化，并且使用校准过程识别权重的重要程度，所以，已经很成熟了。

对于显存更为受限的配置，量化可以说是必须进行的。根据目前的信息综合而言，优选的量化类型包括Q_K_M，IQ\IQ_KT和EXL3三种，至于通常的int8，体积太大，量化收益太低。int4，性能太差，所以本文不做讨论。下面的表格简要给出各种量化技术的简要解析表格：

量化类型	举例	核心处理逻辑	PPL/特点	特点
Q_K_M	Q4_K_M	核心思想：细粒度分块 + 非线性码本 + 多级缩放 技术升级: 1. 分块策略: 256 weights/block (比 Q4_0 的 32 更细) 2. 缩放因子: 每块 4 个缩放因子 (而非 2 个)，适应局部分布 3. 量化码本: 使用 K-means 聚类优化的非线性码本 4. 精度保留: 对极端值使用更高精度编码	比通常的Qx_0具有好的多的ppl/一般作为同等Bit量化的基准,支持成熟
IQ	IQ4_XS/IQ4_XSS/UD_IQ_XSS	在Q_K_M基础上通过数据集产生校准数据,进行权重的重要性感知校正,同体积下ppl更低	好于Q_K_M/速度会降低少许
IQ_KT	IQ4_KT	核心思想：在 IQ 基础上，针对现代加速器硬件优化内存布局与解码流程 技术升级: 1. 内存布局优化: • 权重按张量核心 (Tensor Core) 的 16×16/32×32 块对齐 • 缩放因子与权重数据连续存储 → 减少内存事务 2. 解码流程优化: • 减少条件分支 → 提高分支预测命中率 • 批量查表 (vectorized LUT lookup) → 提升吞吐量 • 预取策略优化 → 隐藏内存延迟 3. 混合精度策略: • 关键层 (如输出层、路由层) 自动使用更高精度编码 • 非关键层使用激进压缩 → 平衡整体精度	PPL和和IQ相当/体积略大/速度提高
EXL3	无约定命名规则	EXL3 是一种基于网格编码量化 (TCQ) 的向量量化方法，通过不相关预处理使权重分布近似高斯，再用维特比最优编码在超高维空间实现接近理论极限的压缩效率。	同体积具有最好的PPL表现,远超Q_K_M

基于上面的表格,再考虑到部署机器的显存大小，就可以进行部署时进行模型/量化的选择。

第五部分:推理框架选择

个人部署场景下，即使具备了128GB的显存/内存,和大规模高并发推理系统相比，仍然属于资源受限环境，在推理框架的选择上，这里就不去介绍vLLM和sgLang的相关信息了，着重针对不同模型格式，介绍相关的框架。

在推理框架方面,Q_K_M\IQ\IQ_KT的推理框架都属于llama.cpp体系。EXL3则使用专用的ExLlamaV3推理引擎。

下面的表格是相关框架的介绍信息

框架名称	概况	模型格式	特点	仓库
llama.cpp	主线版本	GGUF	更新快，混合推理，成熟，使用最广	https://github.com/ggml-org/llama.cpp
ik_llama.cpp	性能优化版，从主线fork而来	GGUF	跟随主线,针对CUDA做算子的特别优化实现，性能更高	https://github.com/ikawrakow/ik_llama.cpp
ik_llama.cpp(Thireus版)	IQ_KT特别版，从ik_llama.cpp仓库fork	GGUF	在ik_llama.cpp基础上，完善对IQ_KT支持	https://github.com/Thireus/ik_llama.cpp
ExLlamaV3	EXL3专用	EXL3	使用专门的EXL3格式，不能进行混合推理	https://github.com/turboderp-org/exllamav3

在个人部署场景,目前来说，如果硬件资源充足， 机器配置好，显存充分的情况下，可以选择llama.cpp。如果一个模型同时具备dense和moe模型(如qwen3.5-27B/qwen3.5-35B)，在显存充分的情况下优先选择dense模型,从基准评测看，dense模型的分值更高。如果显存不充分,对于nvidia显卡，选择moe模型,将专家卸载到CPU/系统内存中。

对于amd/intel的统一内存场景,除了128GB显存之外的时候，可以自由选择dense或者moe模型.

而对于资源受限，又希望体验高性能的小伙伴，可以尝试下ExLlamaV3，其目前已经支持qwen3.5，但是因为该框架过于小众,模型的量化需要自行进行，并且ExLlamaV3不支持混合推理，也不支持除了cuda之外的其他生态,所以，如果需要使用，需要先确定显卡的显存 。

注意在进行模型部署时，需要仔细的进行参数设定，包括对话模板，rope 等参数，以提升表现。在使用llama.cpp及变体部署时，如果使用moe模型,并且使用nvidia显卡，注意参数设置时先将所有moe专家卸载到cpu/内存,使用-ngl 999加载所有层到gpu，然后根据剩余的显卡显存空间，逐步减小卸载的moe参数值，以便于充分利用显存，提升推理速度。而intel/amd平台因为是统一内存，不涉及此问题。

第五部分:附加的信息-nvidia显存的软件扩充/kv-cache量化以及可能的进化方向

对于个人本地部署而言，特别是移动办公场景，在笔记本电脑上部署大模型，在有了量化，llama.cpp的混合推理的加持之下，显存的矛盾仍然是主要矛盾，因为第一，不可能每个人都去购买一台128GB的amd ai max的笔记本电脑。而intel的3x8H系列的高配机型则很少，产能更是不够。amd的rocm生态并不如cuda成熟，intel的生态同样。所以，除了价格问题之外，cuda生态的成熟性也让基于nvidia显卡进行部署是最常用的，然而nvidia不支持统一内存。

为了解决nvidia不支持统一内存，无法直接借助系统内存扩充显存的问题，一位开发者开发出来了greenboost(https://gitlab.com/IsolatedOctopi/greenboost),来让nvidia显卡可以把系统内存当作显存使用(不是nvidia的unify memory)，其基本原理是使用dma-buf或者hostMemReg将系统内存注册给显卡，显卡直接通过pcie总线读写系统内存。原来这种特性是用于gpu和其他子系统高效交换数据的(绕过显存-内存拷贝)，但是结合操作系统的巨页等特性，的确能够让显卡看到更多的内存。

前面提到的llama.cpp在进行混合推理时，卸载到cpu/内存中的专家在参与推理时，算子运算是在cpu上进行的，而cpu进行矩阵类运算，即使有话后，也不能和gpu相比。

这个技术目前llama.cpp还没有进行适配，因为系统内存注册成的显存，带宽受限于pcie带宽，在pcie3.0,4.0还是要比显存低很多。所以，需要llama.cpp能够主动将moe专家，kv-cache放置在这种内存显存中，以降低对速度的影响，而ExLlamaV3有对应的kv-cache压缩组件，能够充分利用该特性。详情请参考greenboost文档。但是使用ExLlamaV3需要自己进行量化处理，需要做好相关准备。

个人曾经修改过llama.cpp的代码,使用dense模型，将权重拆分成两部分，比卸载一部分到cpu/内存要快，但是对于moe型，需要单独适配，没有进一步尝试。

最后说下kv-cache量化，对于实际的生产性部署，长上下文是不得不面对的，所以，此时，需要考虑对kv-cache使用量化。llama.cpp自带支持对kv-cache做q4,q8量化。

而目前最新的turboQaunt量化，从原理上可以和低比特量化结合，目前有开发者在fork分支上增加了turboQaunt的支持，合入llama.cpp主线的事宜在热烈讨论中。

所以，如果llama.cpp如果能够对greenboost适配，或者自身直接支持将内存注册为显存使用,以及增加对于turboQaunt的支持，无疑会非常好。

2026年AI行业最大的机会，毫无疑问就在应用层！

字节跳动已有7个团队全速布局Agent

大模型岗位暴增69%，年薪破百万！

腾讯、京东、百度开放招聘技术岗，80%与AI相关……

如今，超过60%的企业都在推进AI产品落地，而真正能交付项目的 大模型应用开发工程师 **，**却极度稀缺！

落地AI应用绝对不是写几个prompt，调几个API就能搞定的，企业真正需要的，是能搞定这三项核心能力的人：

✅RAG：融入外部信息，修正模型输出，给模型装靠谱大脑

✅Agent智能体：让AI自主干活，通过工具调用（Tools）环境交互，多步推理完成复杂任务。比如做智能客服等等……

✅微调：针对特定任务优化，让模型适配业务

目前，脉脉上有超过1000家企业发布大模型相关岗位，人工智能岗平均月薪7.8w！实习生日薪高达4000！远超其他行业收入水平！

技术的稀缺性，才是你「值钱」的关键！

具备AI能力的程序员，比传统开发高出不止一截！有的人早就转行AI方向，拿到百万年薪！👇🏻👇🏻

AI浪潮，正在重构程序员的核心竞争力！现在入场，仍是最佳时机！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

⭐️从大模型微调到AI Agent智能体搭建

剖析AI技术的应用场景，用实战经验落地AI技术。从GPT到最火的开源模型，让你从容面对AI技术革新！

大模型微调

• 掌握主流大模型（如DeepSeek、Qwen等）的微调技术，针对特定场景优化模型性能。

• 学习如何利用领域数据（如制造、医药、金融等）进行模型定制，提升任务准确性和效率。

RAG应用开发

• 深入理解检索增强生成（Retrieval-Augmented Generation, RAG）技术，构建高效的知识检索与生成系统。
• 应用于垂类场景（如法律文档分析、医疗诊断辅助、金融报告生成等），实现精准信息提取与内容生成。

AI Agent智能体搭建

• 学习如何设计和开发AI Agent，实现多任务协同、自主决策和复杂问题解决。
• 构建垂类场景下的智能助手（如制造业中的设备故障诊断Agent、金融领域的投资分析Agent等）。

如果你也有以下诉求：

快速链接产品/业务团队，参与前沿项目

构建技术壁垒，从竞争者中脱颖而出

避开35岁裁员危险期，顺利拿下高薪岗

迭代技术水平，延长未来20年的新职业发展！

……

那这节课你一定要来听！

因为，留给普通程序员的时间真的不多了！

立即扫码，即可免费预约

「AI技术原理 + 实战应用 + 职业发展」

「大模型应用开发实战公开课」

👇👇

👍🏻还有靠谱的内推机会+直聘权益！！

完课后赠送：大模型应用案例集、AI商业落地白皮书