1. 先说我为什么在这两台机器上焊了两天开源模型事情起因是上周有位同事问我“2026 年了开源 AI 模型到底还值不值得折腾”他的原话更直白“我用 API 写提示词都嫌贵家里那台电脑 RTX 3060 放着吃灰能不能让它跑点什么”我没法直接回答“能”或“不能”因为开源模型这两年卷得太快了。两年前提到开源 AI很多人第一反应是“本地跑个 7B 模型聊聊天效果跟 API 差得远”。现在的情况已经完全不一样从通用对话、深度推理到代码生成、智能体调用、视觉理解、知识库问答开源模型几乎在每个方向上都有一批“开放权重”且能落地的选择。而且最关键的一点是生态层已经出现了大量成熟的推理框架和部署工具不再是只有程序员才能玩转的东西。所以我把手头的两台电脑翻了出来做了一个非常朴素的双机实测一台 24GB 显存的工作主力机一台 12GB 显存的“老伙计”。整整一周时间我下载、跑分、对比、调参把目前在本地能顺利运行的几类开源模型都过了一遍。这篇文章没有厂商通稿式的内容更多的是一份亲手焊了机器、盯着显存占用反复折腾之后的选型报告。如果你也想知道“自己的电脑到底能跑什么模型”“2026 年这些开源模型值不值得下”这篇应该能帮你少走不少弯路。2. 全景盘点2026 年值得放进下载列表的开源模型长什么样既然标题叫“全景盘点”那得先建立一个坐标。2026 年开源 AI 模型的生态已经不是“某个公司贡献了两三个模型”的阶段而是形成了多条明显的产品线有专注推理的思维链模型有面向 agent 场景的工具调用模型有把代码生成为核心的编程专用模型有带视觉能力的多模态模型还有一批专门做 embedding 和 rerank 的“基础设施模型”。我一直觉得普通用户没必要去追每一个新发布的大模型但要搞清楚模型家族背后的适用场景。下面这四类是当前本地部署最常碰到的。2.1 通用对话与深度推理模型这一类的代表非常清晰阿里的 Qwen3 系列、DeepSeek 系列、智谱 GLM 系列以及一直在迭代的 Llama 和 Mistral 等海外开源权重模型。先说 Qwen3。这个家族已经演变出了一整套覆盖不同显存档位的产品0.6B、1.7B、4B、8B、14B、32B还有专门为消费级显卡准备的 MoE 架构版本思路很有意思不追求所有参数都激活而是用少量激活参数去提供接近大模型的推理能力。实测下来这类 MoE 模型在响应速度上有非常明显的优势后面我会详细说。DeepSeek 系列最大的贡献是把“深度推理”从闭源模型独占变成了开源生态的标配。早期大家觉得“推理链”只是模型内部的一种计算方式但 DeepSeek 把这种思考过程通过“思维链”文字化之后用户可以直接看到模型在一步步拆解问题。我在测试中用了它的蒸馏版本在 12GB 显存的老机器上依然能获得不错的推理表现。智谱 GLM 系类则更强调“在中文场景下把复杂指令执行准确”尤其是需要调用外部知识库、按照企业格式输出结构化内容的场景。它的输出格式稳定性普遍比同尺寸的海外模型好这点在 RAG 系统里非常重要。2.2 编程与智能体模型2026 年本地开源模型最大的亮点我认为是编程与智能体方向的成熟。过去大家普遍认为“写代码必须用云端大模型”因为代码生成对上下文长度、工具调用稳定性要求极高。但现在开源模型已经能很好地完成函数调用在代码补全和仓库级代码理解上也有相当强的产品。我没有把所有模型都测一遍聚焦了两条主线一条是 Qwen Coder 系列另一条是基于 DeepSeek 做的蒸馏代码模型。此外 Devstral、CodeGeeX4 也值得关注。 实测中发现编程类模型对显存的敏感度比通用模型更高因为代码任务往往伴随更长的上下文比如“读取整个项目的文件列表”“理解多个函数之间的调用关系”。2.3 多模态视觉模型说到本地部署很多人会自动忽略视觉模型觉得“看一眼图片这种东西必须走云端 API”。实际上完全不是。Qwen2.5-VL 系列、MiniCPM-V 等开源视觉模型在 7B 到 11B 这个尺寸范围内已经能完成相当可靠的截图理解、文档 OCR、物体识别和简单图像问答。我在办公场景里实测过把一堆票据截图丢给它让它输出结构化字段效果已经达到可用的程度。视觉模型对显存的要求确实比纯文本模型高因为图片输入需要转换成视觉 token越大的图片占用的上下文越长KV Cache 消耗也会显著增加。 但如果你的核心场景是“本地查看文档”而不是“电影级视频理解”那么 12GB 显存依然能跑得动 7B 级别的视觉模型。2.4 Embedding、Rerank 等基础设施模型这一块最容易被忽略但它才是 2026 年真正把“知识库自动化”推向普通用户的关键。BGE 系列、GTE 系列等开源 embedding 模型体积不大最大的通常只有几百 MB却负责把所有文档转换成向量是 RAG 系统的基石。Rerank 模型则是在向量检索之后做二次精排把最相关的片段顶到最前面。很多人在本地搭知识库的时候把大模型选得很高配却随手用了一个不分中英文的弱 embedding 模型导致最后问答效果很差。这是完全跑偏的做法。我的实测经验是花少量成本跑一个专用 rerank 模型提升可能比把大模型从 7B 升到 14B 更明显。3. 双机实测平台与测试口径用同样的请求才能得出参考结论其实“双机实测”这个事最大的难点不是选模型而是怎么让两个配置差异很大的平台拥有可对比的测试口径。如果一台机器跑的是 8B 模型另一台跑的是 70B 模型比 TPS 没有任何意义因为压根不是同一量级。为了避免这种尴尬我制定了一个相对客观的标准每台机器都去跑它“自己所在档位最适合的模型”然后再用几个能力覆盖度比较广的测试题目去验证输出质量。最终呈现出来的不是“哪台更值”而是“什么样的电脑应该选什么样的模型”。3.1 测试平台的硬件配置先交代两台机器的具体配置项目机器 A“主力工作站”机器 B“老伙计”CPUIntel Core i9-13900KAMD Ryzen 7 5800X内存128GB DDR5 440032GB DDR4 3600显卡RTX 4090 24GBRTX 3060 12GB存储2TB NVMe SSD1TB NVMe SSD系统Ubuntu 24.04 LTSUbuntu 24.04 LTS选择这两台机器是有原因的。24GB 显存几乎是当前消费级用户能舒服运行 7B 到 32B 量化模型的“黄金档位”往上走 48GB 专业卡的成本不接地气。12GB 显存则是近两三年二手市场保有量很高的配置很多人的“旧电脑”就是这个水平。3.2 测试框架与模型格式统一使用 llama.cpp 作为推理后端所有模型都转换成 GGUF 格式量化精度统一先跑 Q4_K_M再根据实际需要调整。为什么不用更省事的 Ollama因为我想测出底层的变化包括 KV Cache 分配、GPU 层数、上下文长度对性能的影响。Ollama 把太多细节封装掉了适合日常使用不适合做这种贴近硬件的实验。每个推理任务都通过 llama.cpp 自带的 HTTP server 接口发送请求保证两边的请求方式完全一致。所有测试题目都设置temperature0关闭随机采样尽可能让输出稳定可复现。同时记录三个核心指标首 token 延迟、平均生成速度 token/s、峰值显存占用。这里还有一个非常重要的细节上下文长度必须单独测试。很多人喜欢直接把上下文拉到 128K这会显著增加 KV Cache 的显存占用导致能跑起来的模型尺寸变小。所以我会在“默认 16K 上下文”和“长上下文压力”两种模式下分别观察。3.3 测试数据与方法完备性我准备了三类测试一类是通用中文推理题检验模型的逻辑和文字组织能力一类是代码任务比如从零编写一个具备登录校验的 Flask 接口还有一类是多模态任务包括图片 OCR 和知识库检索问答。为了让结果不像玄学每个题目至少跑三遍取中间值。另外我要先泼一盆冷水任何本地模型的输出质量都有波动尤其是低温度下也可能出现完全不同的结果风格。所以单项测试的数据只能反映“这台机器在当前配置下跑这个模型”的大致水平而不是“这个模型在所有硬件下宇宙无敌”。这篇报告的真正价值在于给你一个相对真实的量级感知。4. 通用对话与推理实测Qwen3 系列 vs 蒸馏模型的现场过招这一轮测试我用的题目偏“生活化推理”而不是纯粹的智商题因为实际使用中绝大多数人不会让模型解偏微分方程更多是让它做方案、算成本、分析一句话背后的意图。我用的一道经典题是“一个水池有一个进水口和一个出水口。单独开进水口需要 6 小时放满单独开出水管需要 9 小时排空。如果两个口同时打开水池原来有 1/3 的水问多长时间能放满”这个题看似简单但模型经常会在“原有 1/3 水”这件事上翻车是一个很能暴露推理漏洞的题目。4.1 机器 A 上的表现机器 A 上我最看重的组合是 Qwen3-32B Q4_K_M 和 Qwen3-30B-A3B。32B 模型能吃下复杂指令A3B 这种 MoE 则因为激活参数少生成速度飞快。测试结果整理成了一张表模型量化平均生成速度首 token 延迟题目结果Qwen3-32BQ4_K_M约 27 token/s约 0.4s正确列式步骤清晰Qwen3-30B-A3BQ4_K_M约 43 token/s约 0.2s正确偶尔步骤跳跃DeepSeek-R1-0528 蒸馏版 (32B)Q4_K_M约 22 token/s约 3.1s进行了大量自我检验逻辑严密这里最值得留意的不是速度本身而是 DeepSeek 蒸馏版在首 token 延迟上明显偏高。为什么因为蒸馏版本继承了深度推理模型的习惯在真正吐出第一个字之前会先生成很长一段“内部思考内容”即使设定为 0 温度也无法关闭。这导致它在“快速问答”场景下并不占优但在复杂逻辑推理时那段思考确实会提升正确率。4.2 机器 B 上的表现12GB 显存能比较舒服地运行 Qwen3-14B 和 Qwen3-8B以及 DeepSeek-R1-Distill-Qwen-14B 等蒸馏小模型。模型量化平均生成速度峰值显存题目结果Qwen3-14BQ4_K_M约 41 token/s约 9.5GB正确速度快Qwen3-8BQ4_K_M约 55 token/s约 5.8GB正确但解释偏简DeepSeek-R1 蒸馏 14BQ4_K_M约 34 token/s约 9.2GB正确思考过程很长有意思的是机器 B 跑 Qwen3-14B 的速度甚至超过了机器 A 跑 32B 的速度但输出质量明显不在一个层次。这说明速度只是体验的一部分如果问题复杂度上升比如让它做一份涉及多变量约束的排班方案14B 模型开始出现忽略条件、答非所问的情况32B 则能较完整地遵守所有约束。对于大多数想“免费用一个靠谱中文助手”的朋友14B 是目前性价比最高的档位。它不需要 24GB 显存速度也足够流畅已经能覆盖日常写作、翻译、基础分析类需求。8B 则更适合放在后台长期跑、做轻量分类和信息抽取速度和显存都友好但不太适合深度讨论问题。5. 给智能体做压力测试让本地模型自主决定调用哪个工具2026 年最热的玩法已经从“聊天”变成了“智能体”。所谓智能体通俗说就是模型不只是被动回答而是能自己决定“我现在需要调用什么工具、调整什么参数、根据工具返回结果做下一步判断”。我在这轮测试里给模型设计了一个标准的工具调用场景。模型需要根据用户的一句模糊请求自主选择调用三个函数中的一个或多个查询天气、查询文档、执行计算。为了降低花里胡哨的因素我要求模型必须输出一个 JSON 格式的函数调用然后由外部脚本模拟执行并返回结果模型再根据结果生成最终回答。5.1 不同模型在工具调用上的差距模型能否识别需要调用工具单次调用准确率连续调用稳定性Qwen3-32B很稳定接近 95%能持续完成 3 轮以上工具往返Qwen3-14B大部分场景可以约 85%偶尔会在第二轮丢掉调用参数DeepSeek 蒸馏版能识别但喜欢先长篇推理约 80%速度拖慢稳定性不够好这里的差距非常关键。代码层面的函数调用接口本身并不复杂复杂的是模型在经历了第一轮工具返回之后是否还记得最初的目标。 我在机器 A 上试了一个复杂场景先查天气再根据天气情况规划一个户外活动最后把活动安排写入一个 JSON 文件。Qwen3-32B 能一路清楚执行而较小模型经常在第二步开始“自由发挥”直接跳出 JSON 格式去生成散文式回答。5.2 为什么本地智能体比云端智能体更值得建立很多人问既然要跑智能体为什么不直接用云端 API我的核心理由有两个。第一智能体往往需要长时间维持任务状态过程中会反复携带大量中间上下文和数据如果走 API这个成本可能非常吓人。本地模型虽然单次效果不一定比得上云端大模型但胜在没有按 token 计费的压力你可以让它反复尝试、多跑几遍。第二智能体涉及的数据通常不是“你好天气怎么样”这种无伤大雅的内容而是你的工作文档、代码仓库、个人笔记。数据不出本机这一点对很多开发者来说是压倒性的优势。我在实测文档问答智能体时把一批内部技术文档切成向量塞进本地知识库全程没有任何数据被发送到外网这个安全边际是云 API 给不了的。5.3 智能体任务中的显存与上下文消耗智能体场景对显存的消耗比普通问答高得多。普通问答可能只需要 2K 到 4K 上下文但智能体在连续调用工具后上下文长度经常能快速膨胀到 16K 以上。同样的模型在 4K 上下文下可能只占 10GB 显存拉到 32K 上下文后显存占用可能直接多出 2GB 到 3GB因为每多一个 token 都要额外写一份 KV Cache。这也是我在机器 A 上相对更喜欢 Qwen3-30B-A3B 的原因。它的激活参数少计算量低面对倍数膨胀的工具返回结果时有更多余量去处理长上下文而不是像传统 32B 模型那样因为显存吃紧而被迫降级。6. 视觉、RAG 与滑动窗口上下文把多模态和知识库也塞进本地这一节是为了回应那些不只想聊天、还想让模型“看懂文档和图片”的用户。 我给机器 A 安排了 Qwen2.5-VL-7B给机器 B 安排了 MiniCPM-V 系列更小的视觉模型。除此之外我在两台机器上都搭建了完全本地的知识库流水线测试了 RAG 的完整链路。6.1 图片理解实测告别手动 OCR 复制我的测试图片是一张拍糊了的会议白板上面有手写的待办事项、数字和箭头。视觉模型需要输出结构化清单并识别出数字之间的对应关系。结果比较令人满意7B 视觉模型在没有额外 OCR 预处理的情况下能正确识别大部分手写文字并按照“事项 / 负责人 / 截止日期”的格式输出。 MiniCPM-V 在小显存下的识别准确率略低特别是“数字被线条穿过”的场景容易犯错但作为免费方案已经可用。给视觉模型标注一个关键建议不要直接丢大图。本地视觉模型的分辨率处理能力有限图片过大时应该先裁剪或缩放。 比如 A4 纸扫描件直接塞进去可能导致核心文字区域被压缩变形更聪明的做法是保留 150 DPI 左右的分辨率把大图切成四块分别送给模型再合并结果。6.2 RAG 知识库embedding 模型才是隐藏主角知识库问答我采用的标准链路是先加载文档按固定窗口大小和重叠比例切块用 embedding 模型转成向量存到本地数据库收到问题时再调用 embedding 模型把问题转成向量检索 top-K 候选片段最后让大模型基于这些片段生成答案。链路里的两个模型中embedding 模型非常小却极其关键。我对比了 BGE-M3 和一款通用英文 embedding 模型在中文技术文档上的效果差距大到令人绝望用错模型时检索返回的前几个片段经常和问题完全不相关换上 BGE 后问题“消息队列为什么丢失数据”能精准命中讲 ACK 机制、消费者 offset 的那几段。环节使用模型耗时备注文档切块与向量化BGE-M3约 1300 段耗时 2 分半CPU 就能跑不必上 GPU检索向量相似度 top-8毫秒级正常精排BGE-Reranker-v2-M3每查询约 150ms对最终效果影响很大6.3 滑动窗口策略不是所有上下文都值得永久保留说到切块必然要提到“滑动窗口”。知识库文档不是一句话而是一个长章节直接把整个章节塞给模型做问答会瞬间拉爆上下文。但我也不想简单地按固定 500 字切一刀因为可能把一个完整方案切断。比较好的做法是让相邻两个切块保留 100 字左右的重叠区域等于一个滑动窗口。窗口从头滑到尾每个位置生成一个独立片段。这样既不浪费上下文又能保证某些跨越切边界的逻辑关系尽量完整。 实测下来重叠率设置在 20% 左右能兼顾检索效率和语义完整度太高会制造大量重复向量太低又容易把关键信息切碎。我还在机器 A 上对比了“只检索不精排”和“检索加精排”的最终回答效果。加入 rerank 模型后大模型基本不会再去引用不相关内容回答幻觉明显减少。如果你想在本地搭知识库哪怕预算有限我也建议至少留出几百 MB 显存给 embedding 和 rerank收益非常明显。7. “榨干”不是超频量化级别、上下文窗口长短与 KV Cache 的经验账很多人把“榨干电脑”理解成把 GPU 的功耗拉满、风扇转到起飞其实真正的“榨干”是在现有显存容量下发掘出模型性能上限。这需要你去管理三个核心变量模型量化精度、上下文长度、GPU 与 CPU 之间的层分配。7.1 量化精度不是越低越好GGUF 格式提供了从 Q2 到 Q8 的一整套量化档位。Q2 文件最小但推理质量会明显下降尤其对中文和代码符号敏感度高的任务容易出现胡言乱语。Q4_K_M 是当前消费级里公认的“甜点”文件大小适中质量损失相对可控。我在 Qwen3-32B 上分别跑了 Q4_K_M 和 Q8_0质量差异主要体现在复杂生成任务上日常问答很难察觉。但在 12GB 机器上如果 Q4 版本无法完整加载到显存Q6/Q8 文件则更不可能所以档位选择往往是被显存倒逼出来的。我个人的量化选型口诀目标模型文件加 KV Cache 后如果能小于显存的 85%优先选更高精度的量化档如果不满足果断降到 Q4_K_M如果连 Q4 都放不下不要硬用 Q2应换一个更小的模型而不是牺牲质量换一个伪的大模型。7.2 上下文长度是隐藏的内存巨头很多人只盯着模型文件大小却完全忽略上下文长度带来的显存开销。模型文件的权重是固定的但上下文是动态增长的。下面是一次实测数据基于 Qwen3-14B Q4_K_M在 12GB 机器上观察到的峰值显存上下文长度4K16K32K峰值显存约 8.6GB约 9.5GB约 11GB是否流畅流畅流畅勉强边缘32K 上下文距离 12GB 显存上限已经很近。如果你同时还开着一个占用 1GB 显存的上网浏览器就可能触发 OOM。所以当你发现模型加载后一长文本就崩溃先不要怪模型看看上下文是不是被拉得太高了。有人可能会问KV Cache 不是可以量化吗llama.cpp 确实提供了 KV Cache 量化选项比如 Q8_0。开启之后显存占用能再降一截但会带来轻微的精度损失。我在实际部署时长文本场景会开 Q8_0短文本场景保持默认。 这个开关的性价比很高如果你的服务端有“长上下文极客”需求值得测试一下。7.3 GPU 层数分配让 CPU 也分担一部分当模型文件超过显存容量不少人的第一反应是“跑不了”。其实 llama.cpp 允许把一部分层放在显存、一部分层放在 CPU也就是 GPU offload。你在启动命令里设置-ngl比如-ngl 20表示前 20 层放到 GPU其余层留在 CPU。我在机器 B 上尝试过把 Qwen3-32B 的 Q4 文件通过部分 offload 跑起来虽然峰值显存正好卡在 12GB 边界但生成速度掉到只剩个位数 token/s。 这相当于用 5 倍时间换取了“不用买新卡”的结果。在我看来这种方式只适合“偶尔跑一次复杂问题”的场景不适合作为日常主力方案。7.4 实际服务时的并发与内存预热如果你不满足于命令行聊天想把它跑成一个局域网服务还要考虑并发请求和模型常驻内存的开销。llama.cpp 的 server 模式默认会分配可复用的 KV Cache 空间多个用户同时提问时会排队而不是并行占满内存。我在“服务”模式下把--parallel设为 2在 4090 上同时处理两个 16K 上下文请求单请求的速度会略微下降但系统整体吞吐量比串行高不少。这里有一个常见的误区把--parallel设得很大认为像 Web 服务器一样并发越高越好。但并行槽位越多KV Cache 预分配的显存也越多最后可能导致单个请求能用的上下文变小所有请求都被迫排队。应该根据显存余量去调而不是盲目堆数字。在 24GB 机器上我一般给 32B 模型留 2 个并行槽位给 14B 模型留 4 个。7.5 善用日志与监控查看瓶颈最后分享一个“榨干”时最容易被忽略的动作看日志和监控。llama.cpp 启动时会打印模型加载耗时、显存分配情况、CPU 线程数运行中你还可以通过watch -n 1 nvidia-smi观察 GPU 利用率和显存变化。我在调优机器 B 时发现它的 GPU 利用率经常只有 70% 上下瓶颈反而在内存带宽。对 AMD 平台或者 Intel 平台的老机器启动时建议显式设置--threads不要让它自动选。自动选会默认把所有核心都用上但推理任务在核心数超过某个阈值后不仅不加速反而会因为线程调度开销拖慢速度。 我的经验值是物理核心数一半附近开始试逐档往上加找到拐点为止。8. 按显存档位给选型建议24GB、12GB、8GB……都能吃上哪道菜测试做了整整一周最后
1. 先说我为什么在这两台机器上焊了两天开源模型事情起因是上周有位同事问我“2026 年了开源 AI 模型到底还值不值得折腾”他的原话更直白“我用 API 写提示词都嫌贵家里那台电脑 RTX 3060 放着吃灰能不能让它跑点什么”我没法直接回答“能”或“不能”因为开源模型这两年卷得太快了。两年前提到开源 AI很多人第一反应是“本地跑个 7B 模型聊聊天效果跟 API 差得远”。现在的情况已经完全不一样从通用对话、深度推理到代码生成、智能体调用、视觉理解、知识库问答开源模型几乎在每个方向上都有一批“开放权重”且能落地的选择。而且最关键的一点是生态层已经出现了大量成熟的推理框架和部署工具不再是只有程序员才能玩转的东西。所以我把手头的两台电脑翻了出来做了一个非常朴素的双机实测一台 24GB 显存的工作主力机一台 12GB 显存的“老伙计”。整整一周时间我下载、跑分、对比、调参把目前在本地能顺利运行的几类开源模型都过了一遍。这篇文章没有厂商通稿式的内容更多的是一份亲手焊了机器、盯着显存占用反复折腾之后的选型报告。如果你也想知道“自己的电脑到底能跑什么模型”“2026 年这些开源模型值不值得下”这篇应该能帮你少走不少弯路。2. 全景盘点2026 年值得放进下载列表的开源模型长什么样既然标题叫“全景盘点”那得先建立一个坐标。2026 年开源 AI 模型的生态已经不是“某个公司贡献了两三个模型”的阶段而是形成了多条明显的产品线有专注推理的思维链模型有面向 agent 场景的工具调用模型有把代码生成为核心的编程专用模型有带视觉能力的多模态模型还有一批专门做 embedding 和 rerank 的“基础设施模型”。我一直觉得普通用户没必要去追每一个新发布的大模型但要搞清楚模型家族背后的适用场景。下面这四类是当前本地部署最常碰到的。2.1 通用对话与深度推理模型这一类的代表非常清晰阿里的 Qwen3 系列、DeepSeek 系列、智谱 GLM 系列以及一直在迭代的 Llama 和 Mistral 等海外开源权重模型。先说 Qwen3。这个家族已经演变出了一整套覆盖不同显存档位的产品0.6B、1.7B、4B、8B、14B、32B还有专门为消费级显卡准备的 MoE 架构版本思路很有意思不追求所有参数都激活而是用少量激活参数去提供接近大模型的推理能力。实测下来这类 MoE 模型在响应速度上有非常明显的优势后面我会详细说。DeepSeek 系列最大的贡献是把“深度推理”从闭源模型独占变成了开源生态的标配。早期大家觉得“推理链”只是模型内部的一种计算方式但 DeepSeek 把这种思考过程通过“思维链”文字化之后用户可以直接看到模型在一步步拆解问题。我在测试中用了它的蒸馏版本在 12GB 显存的老机器上依然能获得不错的推理表现。智谱 GLM 系类则更强调“在中文场景下把复杂指令执行准确”尤其是需要调用外部知识库、按照企业格式输出结构化内容的场景。它的输出格式稳定性普遍比同尺寸的海外模型好这点在 RAG 系统里非常重要。2.2 编程与智能体模型2026 年本地开源模型最大的亮点我认为是编程与智能体方向的成熟。过去大家普遍认为“写代码必须用云端大模型”因为代码生成对上下文长度、工具调用稳定性要求极高。但现在开源模型已经能很好地完成函数调用在代码补全和仓库级代码理解上也有相当强的产品。我没有把所有模型都测一遍聚焦了两条主线一条是 Qwen Coder 系列另一条是基于 DeepSeek 做的蒸馏代码模型。此外 Devstral、CodeGeeX4 也值得关注。 实测中发现编程类模型对显存的敏感度比通用模型更高因为代码任务往往伴随更长的上下文比如“读取整个项目的文件列表”“理解多个函数之间的调用关系”。2.3 多模态视觉模型说到本地部署很多人会自动忽略视觉模型觉得“看一眼图片这种东西必须走云端 API”。实际上完全不是。Qwen2.5-VL 系列、MiniCPM-V 等开源视觉模型在 7B 到 11B 这个尺寸范围内已经能完成相当可靠的截图理解、文档 OCR、物体识别和简单图像问答。我在办公场景里实测过把一堆票据截图丢给它让它输出结构化字段效果已经达到可用的程度。视觉模型对显存的要求确实比纯文本模型高因为图片输入需要转换成视觉 token越大的图片占用的上下文越长KV Cache 消耗也会显著增加。 但如果你的核心场景是“本地查看文档”而不是“电影级视频理解”那么 12GB 显存依然能跑得动 7B 级别的视觉模型。2.4 Embedding、Rerank 等基础设施模型这一块最容易被忽略但它才是 2026 年真正把“知识库自动化”推向普通用户的关键。BGE 系列、GTE 系列等开源 embedding 模型体积不大最大的通常只有几百 MB却负责把所有文档转换成向量是 RAG 系统的基石。Rerank 模型则是在向量检索之后做二次精排把最相关的片段顶到最前面。很多人在本地搭知识库的时候把大模型选得很高配却随手用了一个不分中英文的弱 embedding 模型导致最后问答效果很差。这是完全跑偏的做法。我的实测经验是花少量成本跑一个专用 rerank 模型提升可能比把大模型从 7B 升到 14B 更明显。3. 双机实测平台与测试口径用同样的请求才能得出参考结论其实“双机实测”这个事最大的难点不是选模型而是怎么让两个配置差异很大的平台拥有可对比的测试口径。如果一台机器跑的是 8B 模型另一台跑的是 70B 模型比 TPS 没有任何意义因为压根不是同一量级。为了避免这种尴尬我制定了一个相对客观的标准每台机器都去跑它“自己所在档位最适合的模型”然后再用几个能力覆盖度比较广的测试题目去验证输出质量。最终呈现出来的不是“哪台更值”而是“什么样的电脑应该选什么样的模型”。3.1 测试平台的硬件配置先交代两台机器的具体配置项目机器 A“主力工作站”机器 B“老伙计”CPUIntel Core i9-13900KAMD Ryzen 7 5800X内存128GB DDR5 440032GB DDR4 3600显卡RTX 4090 24GBRTX 3060 12GB存储2TB NVMe SSD1TB NVMe SSD系统Ubuntu 24.04 LTSUbuntu 24.04 LTS选择这两台机器是有原因的。24GB 显存几乎是当前消费级用户能舒服运行 7B 到 32B 量化模型的“黄金档位”往上走 48GB 专业卡的成本不接地气。12GB 显存则是近两三年二手市场保有量很高的配置很多人的“旧电脑”就是这个水平。3.2 测试框架与模型格式统一使用 llama.cpp 作为推理后端所有模型都转换成 GGUF 格式量化精度统一先跑 Q4_K_M再根据实际需要调整。为什么不用更省事的 Ollama因为我想测出底层的变化包括 KV Cache 分配、GPU 层数、上下文长度对性能的影响。Ollama 把太多细节封装掉了适合日常使用不适合做这种贴近硬件的实验。每个推理任务都通过 llama.cpp 自带的 HTTP server 接口发送请求保证两边的请求方式完全一致。所有测试题目都设置temperature0关闭随机采样尽可能让输出稳定可复现。同时记录三个核心指标首 token 延迟、平均生成速度 token/s、峰值显存占用。这里还有一个非常重要的细节上下文长度必须单独测试。很多人喜欢直接把上下文拉到 128K这会显著增加 KV Cache 的显存占用导致能跑起来的模型尺寸变小。所以我会在“默认 16K 上下文”和“长上下文压力”两种模式下分别观察。3.3 测试数据与方法完备性我准备了三类测试一类是通用中文推理题检验模型的逻辑和文字组织能力一类是代码任务比如从零编写一个具备登录校验的 Flask 接口还有一类是多模态任务包括图片 OCR 和知识库检索问答。为了让结果不像玄学每个题目至少跑三遍取中间值。另外我要先泼一盆冷水任何本地模型的输出质量都有波动尤其是低温度下也可能出现完全不同的结果风格。所以单项测试的数据只能反映“这台机器在当前配置下跑这个模型”的大致水平而不是“这个模型在所有硬件下宇宙无敌”。这篇报告的真正价值在于给你一个相对真实的量级感知。4. 通用对话与推理实测Qwen3 系列 vs 蒸馏模型的现场过招这一轮测试我用的题目偏“生活化推理”而不是纯粹的智商题因为实际使用中绝大多数人不会让模型解偏微分方程更多是让它做方案、算成本、分析一句话背后的意图。我用的一道经典题是“一个水池有一个进水口和一个出水口。单独开进水口需要 6 小时放满单独开出水管需要 9 小时排空。如果两个口同时打开水池原来有 1/3 的水问多长时间能放满”这个题看似简单但模型经常会在“原有 1/3 水”这件事上翻车是一个很能暴露推理漏洞的题目。4.1 机器 A 上的表现机器 A 上我最看重的组合是 Qwen3-32B Q4_K_M 和 Qwen3-30B-A3B。32B 模型能吃下复杂指令A3B 这种 MoE 则因为激活参数少生成速度飞快。测试结果整理成了一张表模型量化平均生成速度首 token 延迟题目结果Qwen3-32BQ4_K_M约 27 token/s约 0.4s正确列式步骤清晰Qwen3-30B-A3BQ4_K_M约 43 token/s约 0.2s正确偶尔步骤跳跃DeepSeek-R1-0528 蒸馏版 (32B)Q4_K_M约 22 token/s约 3.1s进行了大量自我检验逻辑严密这里最值得留意的不是速度本身而是 DeepSeek 蒸馏版在首 token 延迟上明显偏高。为什么因为蒸馏版本继承了深度推理模型的习惯在真正吐出第一个字之前会先生成很长一段“内部思考内容”即使设定为 0 温度也无法关闭。这导致它在“快速问答”场景下并不占优但在复杂逻辑推理时那段思考确实会提升正确率。4.2 机器 B 上的表现12GB 显存能比较舒服地运行 Qwen3-14B 和 Qwen3-8B以及 DeepSeek-R1-Distill-Qwen-14B 等蒸馏小模型。模型量化平均生成速度峰值显存题目结果Qwen3-14BQ4_K_M约 41 token/s约 9.5GB正确速度快Qwen3-8BQ4_K_M约 55 token/s约 5.8GB正确但解释偏简DeepSeek-R1 蒸馏 14BQ4_K_M约 34 token/s约 9.2GB正确思考过程很长有意思的是机器 B 跑 Qwen3-14B 的速度甚至超过了机器 A 跑 32B 的速度但输出质量明显不在一个层次。这说明速度只是体验的一部分如果问题复杂度上升比如让它做一份涉及多变量约束的排班方案14B 模型开始出现忽略条件、答非所问的情况32B 则能较完整地遵守所有约束。对于大多数想“免费用一个靠谱中文助手”的朋友14B 是目前性价比最高的档位。它不需要 24GB 显存速度也足够流畅已经能覆盖日常写作、翻译、基础分析类需求。8B 则更适合放在后台长期跑、做轻量分类和信息抽取速度和显存都友好但不太适合深度讨论问题。5. 给智能体做压力测试让本地模型自主决定调用哪个工具2026 年最热的玩法已经从“聊天”变成了“智能体”。所谓智能体通俗说就是模型不只是被动回答而是能自己决定“我现在需要调用什么工具、调整什么参数、根据工具返回结果做下一步判断”。我在这轮测试里给模型设计了一个标准的工具调用场景。模型需要根据用户的一句模糊请求自主选择调用三个函数中的一个或多个查询天气、查询文档、执行计算。为了降低花里胡哨的因素我要求模型必须输出一个 JSON 格式的函数调用然后由外部脚本模拟执行并返回结果模型再根据结果生成最终回答。5.1 不同模型在工具调用上的差距模型能否识别需要调用工具单次调用准确率连续调用稳定性Qwen3-32B很稳定接近 95%能持续完成 3 轮以上工具往返Qwen3-14B大部分场景可以约 85%偶尔会在第二轮丢掉调用参数DeepSeek 蒸馏版能识别但喜欢先长篇推理约 80%速度拖慢稳定性不够好这里的差距非常关键。代码层面的函数调用接口本身并不复杂复杂的是模型在经历了第一轮工具返回之后是否还记得最初的目标。 我在机器 A 上试了一个复杂场景先查天气再根据天气情况规划一个户外活动最后把活动安排写入一个 JSON 文件。Qwen3-32B 能一路清楚执行而较小模型经常在第二步开始“自由发挥”直接跳出 JSON 格式去生成散文式回答。5.2 为什么本地智能体比云端智能体更值得建立很多人问既然要跑智能体为什么不直接用云端 API我的核心理由有两个。第一智能体往往需要长时间维持任务状态过程中会反复携带大量中间上下文和数据如果走 API这个成本可能非常吓人。本地模型虽然单次效果不一定比得上云端大模型但胜在没有按 token 计费的压力你可以让它反复尝试、多跑几遍。第二智能体涉及的数据通常不是“你好天气怎么样”这种无伤大雅的内容而是你的工作文档、代码仓库、个人笔记。数据不出本机这一点对很多开发者来说是压倒性的优势。我在实测文档问答智能体时把一批内部技术文档切成向量塞进本地知识库全程没有任何数据被发送到外网这个安全边际是云 API 给不了的。5.3 智能体任务中的显存与上下文消耗智能体场景对显存的消耗比普通问答高得多。普通问答可能只需要 2K 到 4K 上下文但智能体在连续调用工具后上下文长度经常能快速膨胀到 16K 以上。同样的模型在 4K 上下文下可能只占 10GB 显存拉到 32K 上下文后显存占用可能直接多出 2GB 到 3GB因为每多一个 token 都要额外写一份 KV Cache。这也是我在机器 A 上相对更喜欢 Qwen3-30B-A3B 的原因。它的激活参数少计算量低面对倍数膨胀的工具返回结果时有更多余量去处理长上下文而不是像传统 32B 模型那样因为显存吃紧而被迫降级。6. 视觉、RAG 与滑动窗口上下文把多模态和知识库也塞进本地这一节是为了回应那些不只想聊天、还想让模型“看懂文档和图片”的用户。 我给机器 A 安排了 Qwen2.5-VL-7B给机器 B 安排了 MiniCPM-V 系列更小的视觉模型。除此之外我在两台机器上都搭建了完全本地的知识库流水线测试了 RAG 的完整链路。6.1 图片理解实测告别手动 OCR 复制我的测试图片是一张拍糊了的会议白板上面有手写的待办事项、数字和箭头。视觉模型需要输出结构化清单并识别出数字之间的对应关系。结果比较令人满意7B 视觉模型在没有额外 OCR 预处理的情况下能正确识别大部分手写文字并按照“事项 / 负责人 / 截止日期”的格式输出。 MiniCPM-V 在小显存下的识别准确率略低特别是“数字被线条穿过”的场景容易犯错但作为免费方案已经可用。给视觉模型标注一个关键建议不要直接丢大图。本地视觉模型的分辨率处理能力有限图片过大时应该先裁剪或缩放。 比如 A4 纸扫描件直接塞进去可能导致核心文字区域被压缩变形更聪明的做法是保留 150 DPI 左右的分辨率把大图切成四块分别送给模型再合并结果。6.2 RAG 知识库embedding 模型才是隐藏主角知识库问答我采用的标准链路是先加载文档按固定窗口大小和重叠比例切块用 embedding 模型转成向量存到本地数据库收到问题时再调用 embedding 模型把问题转成向量检索 top-K 候选片段最后让大模型基于这些片段生成答案。链路里的两个模型中embedding 模型非常小却极其关键。我对比了 BGE-M3 和一款通用英文 embedding 模型在中文技术文档上的效果差距大到令人绝望用错模型时检索返回的前几个片段经常和问题完全不相关换上 BGE 后问题“消息队列为什么丢失数据”能精准命中讲 ACK 机制、消费者 offset 的那几段。环节使用模型耗时备注文档切块与向量化BGE-M3约 1300 段耗时 2 分半CPU 就能跑不必上 GPU检索向量相似度 top-8毫秒级正常精排BGE-Reranker-v2-M3每查询约 150ms对最终效果影响很大6.3 滑动窗口策略不是所有上下文都值得永久保留说到切块必然要提到“滑动窗口”。知识库文档不是一句话而是一个长章节直接把整个章节塞给模型做问答会瞬间拉爆上下文。但我也不想简单地按固定 500 字切一刀因为可能把一个完整方案切断。比较好的做法是让相邻两个切块保留 100 字左右的重叠区域等于一个滑动窗口。窗口从头滑到尾每个位置生成一个独立片段。这样既不浪费上下文又能保证某些跨越切边界的逻辑关系尽量完整。 实测下来重叠率设置在 20% 左右能兼顾检索效率和语义完整度太高会制造大量重复向量太低又容易把关键信息切碎。我还在机器 A 上对比了“只检索不精排”和“检索加精排”的最终回答效果。加入 rerank 模型后大模型基本不会再去引用不相关内容回答幻觉明显减少。如果你想在本地搭知识库哪怕预算有限我也建议至少留出几百 MB 显存给 embedding 和 rerank收益非常明显。7. “榨干”不是超频量化级别、上下文窗口长短与 KV Cache 的经验账很多人把“榨干电脑”理解成把 GPU 的功耗拉满、风扇转到起飞其实真正的“榨干”是在现有显存容量下发掘出模型性能上限。这需要你去管理三个核心变量模型量化精度、上下文长度、GPU 与 CPU 之间的层分配。7.1 量化精度不是越低越好GGUF 格式提供了从 Q2 到 Q8 的一整套量化档位。Q2 文件最小但推理质量会明显下降尤其对中文和代码符号敏感度高的任务容易出现胡言乱语。Q4_K_M 是当前消费级里公认的“甜点”文件大小适中质量损失相对可控。我在 Qwen3-32B 上分别跑了 Q4_K_M 和 Q8_0质量差异主要体现在复杂生成任务上日常问答很难察觉。但在 12GB 机器上如果 Q4 版本无法完整加载到显存Q6/Q8 文件则更不可能所以档位选择往往是被显存倒逼出来的。我个人的量化选型口诀目标模型文件加 KV Cache 后如果能小于显存的 85%优先选更高精度的量化档如果不满足果断降到 Q4_K_M如果连 Q4 都放不下不要硬用 Q2应换一个更小的模型而不是牺牲质量换一个伪的大模型。7.2 上下文长度是隐藏的内存巨头很多人只盯着模型文件大小却完全忽略上下文长度带来的显存开销。模型文件的权重是固定的但上下文是动态增长的。下面是一次实测数据基于 Qwen3-14B Q4_K_M在 12GB 机器上观察到的峰值显存上下文长度4K16K32K峰值显存约 8.6GB约 9.5GB约 11GB是否流畅流畅流畅勉强边缘32K 上下文距离 12GB 显存上限已经很近。如果你同时还开着一个占用 1GB 显存的上网浏览器就可能触发 OOM。所以当你发现模型加载后一长文本就崩溃先不要怪模型看看上下文是不是被拉得太高了。有人可能会问KV Cache 不是可以量化吗llama.cpp 确实提供了 KV Cache 量化选项比如 Q8_0。开启之后显存占用能再降一截但会带来轻微的精度损失。我在实际部署时长文本场景会开 Q8_0短文本场景保持默认。 这个开关的性价比很高如果你的服务端有“长上下文极客”需求值得测试一下。7.3 GPU 层数分配让 CPU 也分担一部分当模型文件超过显存容量不少人的第一反应是“跑不了”。其实 llama.cpp 允许把一部分层放在显存、一部分层放在 CPU也就是 GPU offload。你在启动命令里设置-ngl比如-ngl 20表示前 20 层放到 GPU其余层留在 CPU。我在机器 B 上尝试过把 Qwen3-32B 的 Q4 文件通过部分 offload 跑起来虽然峰值显存正好卡在 12GB 边界但生成速度掉到只剩个位数 token/s。 这相当于用 5 倍时间换取了“不用买新卡”的结果。在我看来这种方式只适合“偶尔跑一次复杂问题”的场景不适合作为日常主力方案。7.4 实际服务时的并发与内存预热如果你不满足于命令行聊天想把它跑成一个局域网服务还要考虑并发请求和模型常驻内存的开销。llama.cpp 的 server 模式默认会分配可复用的 KV Cache 空间多个用户同时提问时会排队而不是并行占满内存。我在“服务”模式下把--parallel设为 2在 4090 上同时处理两个 16K 上下文请求单请求的速度会略微下降但系统整体吞吐量比串行高不少。这里有一个常见的误区把--parallel设得很大认为像 Web 服务器一样并发越高越好。但并行槽位越多KV Cache 预分配的显存也越多最后可能导致单个请求能用的上下文变小所有请求都被迫排队。应该根据显存余量去调而不是盲目堆数字。在 24GB 机器上我一般给 32B 模型留 2 个并行槽位给 14B 模型留 4 个。7.5 善用日志与监控查看瓶颈最后分享一个“榨干”时最容易被忽略的动作看日志和监控。llama.cpp 启动时会打印模型加载耗时、显存分配情况、CPU 线程数运行中你还可以通过watch -n 1 nvidia-smi观察 GPU 利用率和显存变化。我在调优机器 B 时发现它的 GPU 利用率经常只有 70% 上下瓶颈反而在内存带宽。对 AMD 平台或者 Intel 平台的老机器启动时建议显式设置--threads不要让它自动选。自动选会默认把所有核心都用上但推理任务在核心数超过某个阈值后不仅不加速反而会因为线程调度开销拖慢速度。 我的经验值是物理核心数一半附近开始试逐档往上加找到拐点为止。8. 按显存档位给选型建议24GB、12GB、8GB……都能吃上哪道菜测试做了整整一周最后
