企业官网建设流程全解析

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 测试平台的硬件配置

先交代两台机器的具体配置：

选择这两台机器是有原因的。24GB 显存几乎是当前消费级用户能舒服运行 7B 到 32B 量化模型的“黄金档位”，往上走 48GB 专业卡的成本不接地气。12GB 显存则是近两三年二手市场保有量很高的配置，很多人的“旧电脑”就是这个水平。

3.2 测试框架与模型格式

统一使用 llama.cpp 作为推理后端，所有模型都转换成 GGUF 格式，量化精度统一先跑 Q4_K_M，再根据实际需要调整。为什么不用更省事的 Ollama？因为我想测出底层的变化，包括 KV Cache 分配、GPU 层数、上下文长度对性能的影响。Ollama 把太多细节封装掉了，适合日常使用，不适合做这种贴近硬件的实验。

每个推理任务都通过 llama.cpp 自带的 HTTP server 接口发送请求，保证两边的请求方式完全一致。所有测试题目都设置temperature=0，关闭随机采样，尽可能让输出稳定可复现。同时记录三个核心指标：首 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 则因为激活参数少，生成速度飞快。

测试结果整理成了一张表：

这里最值得留意的不是速度本身，而是 DeepSeek 蒸馏版在首 token 延迟上明显偏高。为什么？因为蒸馏版本继承了深度推理模型的习惯，在真正吐出第一个字之前会先生成很长一段“内部思考内容”，即使设定为 0 温度也无法关闭。这导致它在“快速问答”场景下并不占优，但在复杂逻辑推理时，那段思考确实会提升正确率。

4.2 机器 B 上的表现

12GB 显存能比较舒服地运行 Qwen3-14B 和 Qwen3-8B，以及 DeepSeek-R1-Distill-Qwen-14B 等蒸馏小模型。

有意思的是，机器 B 跑 Qwen3-14B 的速度甚至超过了机器 A 跑 32B 的速度，但输出质量明显不在一个层次。这说明速度只是体验的一部分，如果问题复杂度上升，比如让它做一份涉及多变量约束的排班方案，14B 模型开始出现忽略条件、答非所问的情况，32B 则能较完整地遵守所有约束。

对于大多数想“免费用一个靠谱中文助手”的朋友，14B 是目前性价比最高的档位。它不需要 24GB 显存，速度也足够流畅，已经能覆盖日常写作、翻译、基础分析类需求。8B 则更适合放在后台长期跑、做轻量分类和信息抽取，速度和显存都友好，但不太适合深度讨论问题。

5. 给智能体做压力测试：让本地模型自主决定调用哪个工具

2026 年最热的玩法已经从“聊天”变成了“智能体”。所谓智能体，通俗说就是模型不只是被动回答，而是能自己决定“我现在需要调用什么工具、调整什么参数、根据工具返回结果做下一步判断”。

我在这轮测试里给模型设计了一个标准的工具调用场景。模型需要根据用户的一句模糊请求，自主选择调用三个函数中的一个或多个：查询天气、查询文档、执行计算。为了降低花里胡哨的因素，我要求模型必须输出一个 JSON 格式的函数调用，然后由外部脚本模拟执行并返回结果，模型再根据结果生成最终回答。

5.1 不同模型在工具调用上的差距

这里的差距非常关键。代码层面的函数调用接口本身并不复杂，复杂的是模型在经历了第一轮工具返回之后，是否还记得最初的目标。 我在机器 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 的那几段。

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 机器上观察到的峰值显存：

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……都能吃上哪道菜

测试做了整整一周，最后