企业官网建设流程全解析

大模型本地部署这几年的热度一直没降过，但大家关注的点明显在变。2024年那会儿社交媒体上问得最多的是“我的电脑能不能跑”，到了2026年，问题已经变成“这么多部署工具我该用哪个”“怎么部署完效果还是不行”。我把这两年帮团队和个人朋友落地本地大模型的经历整理了一下，从硬件评估、工具选型到完整实操流程，再到知识库、Agent、微调这些进阶玩法，一次说清楚。内容可能有点长，但每一段都是实测过的经验，照着走基本不会踩大坑。

如果你是第一次接触本地大模型，建议重点看第二章和第三章，这两章解决的是“选什么”和“怎么跑起来”。如果你已经在用Ollama或LM Studio这类工具，可以直接跳到第四章和第五章，那里整理了知识库部署、Agent框架选型、微调工具链和一些调优排查细节。

1. 动手之前：先算清你的硬件家底

1.1 本地部署的核心瓶颈不是算力，是显存

很多人下意识认为跑大模型最吃GPU算力，这个理解在训练阶段是对的，但本地部署推理时真正卡脖子的往往是显存容量。打个比方，算力决定了你“算得快不快”，显存决定了模型“能不能放进去”。模型放不进显存，再强的GPU也白搭。

推理阶段显存占用主要由三部分构成：模型权重、KV Cache（键值缓存）、CUDA上下文和运行时开销。其中权重是大头，可以用一个很简单的公式估算：模型显存占用GB约等于参数量（B）× 量化位数 / 8。以8B模型为例，Q4_K_M量化后权重约4.7GB，加上16K上下文的KV Cache约1.6GB，再算上CUDA额外开销，实际占用普遍在6.5GB到7.5GB之间。也就是说，8GB显存的显卡理论上能跑，但非常极限，稍微把上下文调长一点就OOM。真正舒服的起步配置是16GB显存。

搞清楚了这点，你在选硬件时就有了明确判断标准：不要只盯GPU型号的“算力”数值，先看显存大小够不够放模型。RTX 4090的24GB显存跑14B模型又能开大上下文，3090二手卡性价比也不错，这些都是本地部署圈里常见的选择。

1.2 常见的几类硬件路线与2026年的真实表现

2026年的本地部署硬件路线基本稳定在四类，每类的定位和体验差异很大。

第一类是单卡游戏显卡或涡轮卡路线，代表是RTX 4090/5090、二手3090、Titan RTX这类。这是绝大多数个人开发者的首选，性价比最高，驱动成熟，生态兼容性最好。我实测过Titan RTX的24GB显存跑14B模型，Q4量化下速度和效果都比较理想，显存占用控制在20GB左右，部署老黄历的24GB双卡路线时，Tensor Parallel还能进一步跑大模型。这类卡的共同点是：显存是个硬指标，24GB是甜点，12GB以下建议只跑7B/8B模型。

第二类是Mac统一内存路线。苹果M系列芯片把内存直接当作显存用的设计，跑大模型天然有优势。我帮朋友用MacBook Pro M3 Max的48GB内存跑过Qwen3-14B，虽然速度比不上4090，但胜在能跑、发热低、安静，而且大上下文场景下表现意外不错。Mac路线适合经常移动办公、又不想背砖头显卡坞的人。

第三类是边缘设备路线，典型代表是Jetson Orin系列。这类设备面向的不是桌面场景，而是机器人、边缘网关、工业视觉这类嵌入式环境。Orin NX 16G模块勉强能跑7B/8B量化模型，AGX Orin 64GB则可以跑14B模型，但速度也只能说“可用”。如果你没有边缘部署需求，别跟风买Orin，性价比远不如一张二手大显存显卡。

第四类是多卡并行路线。双卡甚至四卡通过Tensor Parallel、Pipeline Parallel等技术可以突破单卡显存限制。这里要提醒一句：多卡部署的效率和显存线性扩展程度取决于推理引擎的并行策略，不同框架差距很大。

我整理了一张硬件路线速查表：

这里再加一条个人经验：硬件应该等软件选型之后再确定。先想清楚你要用哪个引擎、跑哪个模型，再反过来匹配显存。我见过好几个朋友先高高兴兴买了张12GB显卡，结果想跑的模型标着“建议24GB”，最后只能降级用蒸馏小模型，多少有点尴尬。

2. 2026 工具选型：推理引擎与部署框架的横向对比

2.1 为什么先选引擎再选模型

本地部署不同于调用云端API，你选定的推理引擎直接决定了模型文件用什么格式、能开多大的并发、支持哪些高级特性。模型GGUF、AWQ、GPTQ这些格式和推理引擎是绑定的，Ollama主要吃GGUF，vLLM对AWQ/GPTQ支持更好，llama.cpp则是GGUF的老家。引擎选错了，模型下下来可能根本加载不了。

另外，引擎决定了你的“扩展天花板”。Ollama生态里模型管理做得极好，热门模型一行命令就能拉下来跑，但它的并发放大能力不如vLLM。如果你只是自己对话、做点智能体实验，Ollama完全够用；如果你想把本地模型对团队开放，或者做一个并发较高的API服务，那必须考虑vLLM这类吞吐更强的方案。

2.2 主流方案优缺点对比

我2024年开始接触本地推理引擎，2025年基本把市面上的主流方案都过了一遍。到2026年，头部工具格局已经很清晰，这里逐个点评：

Ollama：我在本地部署里用得最多的工具，没有之一。它的优势是模型管理机制极其优雅，支持各大模型仓库直接拉取，跨平台，Windows/macOS/Linux全通吃，而且提供OpenAI兼容的API接口，配置一次就能被各种前端和开发框架调用。劣势是高并发场景下性能调度不够强，对AWQ/GPTQ这类模型格式支持比较弱，但它很适合个人开发者。

LM Studio：图形化做得最友好的方案，带模型下载界面、内置聊天窗口、可视化参数调节，新手很容易上手。我经常拿它当“先试试再决定”的评测工具，确认一个模型效果满意后再用Ollama做正式部署。它底层其实复用llama.cpp，性能也不差。

llama.cpp：真正的底层技术方案，纯C/C++实现，优化深入，对CPU推理、小幅显存设备支持完善，还支持各种量化格式。缺点是配置和调用偏向命令行，对普通用户不友好。如果你在资源受限的机器或嵌入式设备上部署，llama.cpp是绕不开的选项。

vLLM：吞吐量怪兽，PagedAttention技术让并发请求下的显存利用率和吞吐表现都比Ollama高不少，支持高度可配置的推理参数、量化、LoRA加载，适合服务化部署。劣势是环境配置相对复杂，对显存底限要求高，小显存场景体现不出优势。

SGLang：vLLM之后出现的优秀后辈，在一些大上下文、复杂推理场景下表现比vLLM更激进，但生态还在追赶，适合有一定工程能力的人尝鲜。

Xinference：国产开源推理框架，模型管理和推理后端兼容做得不错，内置多种引擎切换能力，还集成了嵌入模型和重排序模型管理，对知识库项目很友好。社区活跃度在逐步上升。

整理成表格更直观：

如果你实在不知道怎么选，个人开发场景直接上Ollama，团队服务场景直接上vLLM，这两个选型在2026年依然是容错率最高的方案。别一上来就追求最复杂的方案，部署只是起点，后续你有的是时间慢慢折腾。

2.3 2026年模型选型的几个建议

工具定完之后就是模型。2026年开源生态里值得本地部署的主流模型包括DeepSeek系列、Qwen千问系列、Llama系列、GLM系列、Mistral/MiniMax等。我发现很多人选模型有个误区——只看榜单分数，不结合自己的显存和场景。

自己的硬件能跑什么量化等级，根本决定你能选哪些模型。让我给出一个比较稳妥的选型思路：显存8GB到12GB，重点看7B/8B模型的Q4量化版本，比如Qwen3-8B、DeepSeek-R1蒸馏版；显存16GB到24GB，可以上14B模型，Q4或Q8量化都行，比如Qwen3-14B、GLM-4-9B；显存超过24GB且支持多卡，就可以考虑32B甚至70B的量化模型。

另外还要考虑任务类型。日常对话和文档总结类，Qwen系列的中文表现一直很稳；代码生成和逻辑推理类，DeepSeek系列的优势明显；如果是英文内容为主，Llama系列可以保留一个位置。我把这个观察写在这里——本地部署的模型不追求最强，追求“在你能跑的范围内”最适合你的任务。

3. 实操流程：从零部署一个能聊天的本地大模型

3.1 准备与安装：把Ollama的默认路径改掉再装

如果你决定走Ollama路线，安装这一步有个非常容易被忽略的点：Ollama默认会把模型存到系统盘的用户目录下，一个7B模型就是四五个GB，多下几个模型轻松占用二十多GB。系统盘空间紧张的朋友装完就后悔。

我的做法是安装前先设置环境变量OLLAMA_MODELS，把模型库指向数据盘或独立分区。在Windows上，先在系统环境变量里新建OLLAMA_MODELS，值设为D:\ollama\models，然后再安装Ollama。Linux/macOS则在命令行执行export OLLAMA_MODELS=/data/ollama/models，可以写进shell配置文件让它永久生效。别小看这一步，等你下载第一个模型时就知道它有多重要。

安装完成后验证一下。在终端执行ollama list，如果能列出空列表说明安装成功。Windows用户安装后记得重新打开终端，确保环境变量生效。

3.2 下载模型并跑通第一段对话

Ollama拉取模型只需要一条命令。我以两个典型模型举例：

# 拉取 DeepSeek-R1 7B 量化版（适合8-12G显存） ollama pull deepseek-r1:7b # 拉取 Qwen3 8B（中文效果好，适合日常对话） ollama pull qwen3:8b

如果显存只有8GB，建议加上量化标签。Ollama默认拉取的是常用量化版本，但不同标签对应不同精度，空间和效果差别很大。显存小的优先选含有q4字样或直接写明小量化等级的标签；显存充裕可以直接用默认版本，效果最接近原版。

模型拉完后执行：

ollama run qwen3:8b

等待进入交互界面，第一次运行会做模型加载，可能稍微慢一点。进去后随便问一句“请介绍一下你自己”，能正常回复就说明整套链路通了。

这里我提一个很多人遇到的坑：如果你的CPU不支持AVX/AVX2指令集，Ollama可能直接报illegal instruction错误。排查方法是用CPU-Z等工具查看CPU指令集支持情况，老CPU就别硬跑了，要么换设备，要么用兼容性更好的llama.cpp。

3.3 把本地模型变成OpenAI兼容API

本地模型最常用的价值之一就是提供OpenAI兼容接口。Ollama启动时默认监听11434端口，通过curl就能直接调用：

curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen3:8b", "messages": [{"role": "user", "content": "你好，介绍一下自己"}] }'

返回格式和OpenAI几乎一样，这就意味着市面上所有兼容OpenAI SDK的工具都能无缝接入本地模型。Python里我习惯这样写：

from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama" # 本地不需要真实密钥，占位即可 ) response = client.chat.completions.create( model="qwen3:8b", messages=[{"role": "user", "content": "用三句话说明什么是RAG"}] ) print(response.choices[0].message.content)

把它接到你的自动化脚本、聊天机器人、智能体框架里都行。我把自己平时写的工具脚本都从云端API切到了本地API，离线也能跑，数据不出机，隐私方面也放心很多。

3.4 加一个网页聊天界面

命令行交互对技术人够用，但如果你想把本地模型开放给家人、同事或团队用，网页端就很有必要了。最推荐的两个界面是Open WebUI和Dify的对话模块。

Open WebUI是OpenAI ChatGPT界面的开源替代品，支持模型切换、知识库上传、多人对话、插件扩展。用Docker部署最省事：

docker run -d -p 3000:8080 \ --add-host=host.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main

启动后浏览器访问localhost:3000，注册一个管理员账号，然后在设置里把Ollama的地址填成http://host.docker.internal:11434，就能在网页上直接调用本地模型了。实测下来Open WebUI对Ollama的适配几乎是无痛的。

如果你想要的不只是聊天界面，而是打算构建知识库、Agent工作流，那头部的搜索词“dify本地部署教程”是绕不开的。Dify是一套可视化的LLM应用开发平台，它和Open WebUI定位不一样，后面我会单独开一节聊。

4. 进阶：本地知识库、Agent 与轻量化微调

4.1 文档问答与知识库部署：RAG方案怎么选

本地部署大模型后，大多数人下一步就是做知识库问答。对接私有文档、PDF、网页内容，本质是RAG（检索增强生成）。流程大致是：文档切块 → 向量化 → 向量数据库存储 → 查询时做相似度检索 → 把检索结果拼进Prompt交给大模型。

2026年做本地知识库的主流方案有三类。一类是轻量级方案，直接用AnythingLLM，它把文档管理、向量库、模型接入都在桌面端搞定，适合个人本地知识库，انسخ新手15分钟能跑起来。一类是中量级方案，用Dify或FastGPT搭知识库应用，它们自带知识库管理、API编排、日志系统，适合小团队内部使用。还有一类是重量级方案，类似RAGFlow这类专注深度文档解析的系统，对复杂PDF、表格、扫描件的解析能力更强，但部署和维护成本明显更高。

Dify本地部署值得多看两眼，因为它在个人免费场景下表现不错而且生态热。部署方式主要是Docker Compose：

git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d

等容器起来后在浏览器配置模型供应商，把API地址指向本地Ollama或vLLM服务，然后就能在知识库页面创建数据集，上传文档，接入聊天助手。

嵌入模型选择上，做中文知识库我推荐bge-m3或bge-m3-large，它对中文分句和语义匹配都比默认的英文嵌入模型好不少。选择嵌入模型时注意维度、最大token限制和与向量库的兼容性，我见过不少案例是嵌入模型设置不对导致检索质量很差，效果“答非所问”，问题常常出在这，而不是模型本身。

4.2 2026主流Agent框架选型：为什么可视化平台越来越重要

本地部署的最终目的往往不只是聊天，而是让模型执行任务。2026年的Agent框架选型已经进入一个相对成熟的阶段，大致可以分三派。

一派是可视化Agent平台，代表是Dify、FastGPT、MaxKB。这些平台把Agent的规划、工具调用、知识库、流程编排都做成可视化界面，业务人员也能快速配置出智能客服、自动化助手。Dify的Agent节点支持自定义工具OpenAPI接入，FastGPT的流程编排也相当灵活。对大多数企业场景来说，这类平台是首选，因为维护成本和上手门槛都低。

另一派是代码编程框架，代表是LangChain、LlamaIndex和2025年后声量很大的各类新Agent SDK。它们适合开发者深度定制工作流，灵活性很高，但需要自己处理大量链路细节，比如回调、重试、状态管理。如果你本来就是工程师，我建议用代码框架实现复杂链路，但不要什么都往LangChain里塞，轻量的调用组合反而更好维护。

还有一派是开箱即用的私有化Agent应用，比如n8n配合AI节点、以及一些面向企业交付的完整Agent服务。n8n在自动化工作流方面很强，AI Agent节点能对话式调度已有的自动化流程，部署到本地也没有问题。

选型逻辑很清楚：业务人员多、开发资源少的团队，优先可视化平台；开发者个人项目或深度定制需求，优先代码框架；自动化流程与AI需要深度耦合的场景，n8n这类工作流引擎更合适。

4.3 从部署走向微调：LoRA/QLoRA与工具链选型

聊到微调，先泼一盆冷水：不是所有效果问题都该靠微调解决。很多时候你对模型效果不满意，可能是提示词工程没做好、检索内容质量太差、或者是模型本身选得不合适。这些情况先优化Prompt、优化RAG链路，再考虑微调。

真正需要微调的场景有三个：模型输出格式需要严格遵循固定模板；需要稳定的特定领域风格（例如客服话术、行业术语）；需要让模型学会私有知识且通过RAG无法解决的高频场景。2026年最主流的微调路线是参数高效微调（PEFT），LoRA和QLoRA几乎是事实标准。

微调工具链方面，推荐LLaMA-Factory和Unsloth。LLaMA-Factory是国产开源项目里面把LoRA训练封装得最舒服的工具，支持命令行和网页界面，模型种类覆盖广，文档也完整。Unsloth的优化更狠，显存占用更低，训练速度也更快，但支持的模型种类相对少一些。Axolotl是老牌选手，定制能力强，但对新手不友好。

下面是一个典型的QLoRA微调显存估算表，基于8B模型：

用LLaMA-Factory在本地跑QLoRA微调，大概流程是准备JSON格式数据集（包含instruction、input、output字段）→ 选择基座模型 → 配置LoRA参数（秩一般取16或32）→ 启动训练 → 导出LoRA权重 → 用vLLM或Ollama加载推理。整个流程不难，但数据质量才是关键，低质量数据微调出来的模型很可能连基座能力都丢掉。

5. 常见问题排查与调优速查

5.1 经典问题清单

本地部署的坑实在不少，这里整理一份高频问题的排查速查表。这些都是我的排障经验，基本上覆盖了实际部署中90%的故障点。

这个表格里每一条我都实际遇到或是帮别人排查过。OOM是最常见的，但很多人误以为是模型问题，其实只是上下文太长。下载慢则经常让人误认为工具坏了，其实是网络因素，用国内模型平台下载后再导入反而更快。

5.2 性能调优的细节与参数经验

调优不是玄学。Ollama有几个环境变量是官方文档之外实测很有效的。OLLAMA_NUM_PARALLEL控制模型并行处理的请求数，默认值可能过高，单卡用户建议调到1或2，否则同时来几个请求时每个请求都慢得像卡住。OLLAMA_MAX_LOADED_MODELS默认可以加载多个模型，显存紧张时改成1避免模型反复加载换入换出。还有一个是OLLAMA_KV_CACHE，控制KV Cache大小，想省显存就调小一点。

vLLM的调优逻辑和Ollama不同。vLLM有一个非常有用的参数--gpu-memory-utilization，默认0.9，代表把90%的显存交给模型调度。线上服务建议设0.85到0.95之间，留出一点余量给请求抖动；并发请求量大时合理设置max-num-seqs，避免请求过多导致显存溢出。

推理参数也一样重要。Temperature控制随机性，日常对话设0.7左右；做代码生成或结构化输出时降到0.2以下，减少胡说八道。top_p保持默认0.8到0.9。上下文长度不要无脑拉满，越长的上下文越吃显存，而且很多基座模型长上下文质量并不稳定。

模型侧我也总结了一点感受：通用本地部署，Qwen系列的综合体验一直很稳；代码任务DeepSeek系列表现更好；偏英文和指令跟随场景，Llama系列依然能打。2026年开源模型迭代很快，每个季度都有更优秀的模型出来，建议养成熟练切换评估模型的习惯，而不是迷信某一个模型永远最好。

5.3 双卡与边缘设备的特殊心得

双卡部署是很多人问到的，尤其是“Titan RTX能不能双卡跑大模型”这类问题。我实测过24GB双卡Titan RTX用Tensor Parallel跑32B模型的量化版，效果可以用，但配置起来比单卡费时不少。Ollama虽然能在多GPU间自动拆分布局模型，但它的拆分逻辑相对简单，性能谈不上最优。如果对性能有要求，建议用vLLM的tensor-parallel-size参数。

vLLM双卡启动示例：

vllm serve Qwen/Qwen3-32B-AWQ \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9 \ --max-model-len 32768

边缘设备方面，Jetson Orin是我在机器人项目里经常接触的平台。Orin AGX 64GB跑14B Q4模型基本可用，但散热和功耗控制要心里有数；Orin NX 16G跑8B模型需要谨慎优化上下文长度。更小的设备建议直接考虑4B模型，比如Qwen3-4B这类，体验稳定很多。

最后分享一个我在Mac上的部署小经验：Ollama在Apple Silicon下默认开启Metal加速，跑模型其实比很多人想象中快。要是觉得慢，检查一下系统是不是把内存用得太多导致Mac疯狂换页，关掉一些大应用后再试，体感提升明显。

我个人这两年反复体会到一个道理：本地部署模型从来不是“装一个工具跑通就结束”的事情，它是一个持续迭代的系统工程——硬件、引擎、模型、应用层四层互相制约。新手最容易犯的错误是跳过前面两层直接追求应用效果，出了问题又不知道该修哪一层。所以如果你现在正在配置自己的第一套本地大模型环境，我的建议很朴素：先从最简单的Ollama跑通一个小模型，加一个网页界面，然后慢慢往里面加知识库、加Agent、再考虑微调。每一步都留出迭代空间，比一开始就追求“全网最强部署方案”要实在得多。

本地部署的路子走通了之后，你会发现自己手里多了一个完全可控、离线可用、数据隐私有保障的AI底座。这个底座能做的事，远比“在网页上聊天”要大得多。