企业官网建设流程全解析

这几年我折腾本地部署大模型的次数，比写业务代码还多。每次看到有人问“本地部署大模型有没有未来”，我都想先反问一句：你说的未来，是指人人都从头训练一个模型，还是指每个人都能在自己机器上稳定地跑一个可用的大模型？这两件事完全不是一回事。

我最早也站“直接用云 API”那一队，觉得本地部署纯属自嗨：自己买显卡、配环境、处理报错，算下来比调用人家封装好的接口贵得多。直到后来遇到一个需求：要把企业内部的合同和技术文档做成问答系统，数据不能出内网，不能传到第三方平台，外部 API 这条路直接堵死。那时候我才认真开始研究本地部署，也亲身把 DeepSeek、Qwen 这些开源模型在自己的机器上跑了起来。这篇内容就把我这一年多踩过的坑、验证过的方案、以及对“未来”的判断一起聊清楚。不管你是准备入门的开发者，还是已经在企业内部做私有化 AI 选型，应该都能从中找到可参考的部分。

1. 先别急着站队：本地部署这几年到底经历了什么

1.1 为什么很多人觉得本地部署是伪需求

“本地部署是伪需求”这种判断，在一两年前有它的道理。那时候想跑一个能打的模型，基本意味着你需要一块 80GB 显存的显卡，或者一整台双卡服务器。没有这些硬件，强行本地跑出来的模型要么是 6B、7B 的“玩具”，要么回答质量差到没法在实际场景里使用。云厂商把最好的模型、最大的算力封装成 API，几行代码就能接入，个人开发者确实没有必要和硬件较劲。

但真实世界里还有另一层需求：数据安全、成本控制、离线环境、定制自由。这四样东西，恰恰是云 API 很难完全满足的。尤其是企业场景，合同内容、客户信息、生产数据一旦上传到第三方平台，合规风险和商业风险都很大。所以“本地部署是不是伪需求”这个问题的答案，其实取决于你手里有没有那种必须留在本地的数据。只要这类数据存在，本地部署就永远有用武之地。

1.2 开源模型和量化技术把门槛打下来了

真正让本地部署开始变务实的，是开源模型和量化技术的同时成熟。今天你不需要用几百亿参数的大模型来满足日常问答，7B、14B 的开源模型在很多任务上已经能给出很可靠的结果，尤其是在中文场景，Qwen（通义千问）系列和 DeepSeek 系列模型的表现已经能和几个版本前的“大模型”打平。

与此同时，GGUF、AWQ、GPTQ 这类量化格式大大降低了硬件门槛。我最初不理解什么是“量化”，后来用生活里的例子给自己解释清楚了：模型参数本来用 16 位精度保存，相当于一本书里每个字都写32个比特，但量化就是把这本书记录成更紧凑的笔记，比如只保留关键意思的 4 位精度。代价是信息有一点损失，但换来的是体积缩小到原来的三分之一甚至四分之一。一个 7B 参数量的模型，FP16 格式要占 14GB，Q4_K_M 量化后只需要 4GB 多，普通 8GB 显存的入门卡就能跑起来。这就是本地部署从极客玩具走向普通工程师工具的关键原因。

1.3 本地部署解决的不是“便宜”，而是“主权”

很多人算本地部署成本的时候，常常只对比电费和 API token 费用，然后得出结论：本地跑不如买 API。我承认，从单次推理的综合成本来看，本地部署不是最优解，特别是模型调用量很低的时候。但本地部署的价值更像自建机房而不是租赁云服务器：你需要的是可控的算力、可控的数据链路、可控的模型版本。

你可以随时换模型、改提示词、微调参数、加自己的知识库，不必担心上游 API 突然改版或者涨价。也可以断网运行，不必担心哪天服务不可用导致整个产品瘫痪。换句话说，本地部署买的是选择权和确定性。如果你认为软件系统的稳定和安全比省几十块钱更重要，那这个“未来”就已经有了基本盘。

2. 当前主流部署工具怎么选？从 Ollama 到 vLLM 的定位差异

2.1 Ollama：个人开发者和初学者的第一站

现在讨论本地部署，几乎绕不开 Ollama。这个工具解决的是“把模型从下载到运行这中间的繁琐过程”问题。以前运行本地模型，要先装 Python 环境、装 PyTorch、下载模型权重、写推理脚本，整个过程足够劝退一半新手。而 Ollama 把这些都封装好了，安装之后只需要两条命令：

ollama pull qwen2.5:7b ollama run qwen2.5:7b

第一条命令负责下载模型，第二条命令直接进入交互式对话界面。就这么简单，背后涉及的模型格式转换、上下文管理、GPU 加速调用全部自动处理。我第一次用 Ollama 跑起 7B 模型的时候，心里只有一个念头：以后终于不用再浪费时间搭环境了。

除了命令行方便，Ollama 还默认暴露了一个本地 HTTP API，监听在 11434 端口。你完全可以把它当成一个私有化的“API 供应商”，在代码里用标准接口去请求模型。对于个人知识库、内网小工具、原型验证来说，这种低成本方式已经非常够用。

2.2 vLLM：高并发和长文本场景更合适

Ollama 很好用，但它更偏向单机或小规模使用。如果要在本地给几十个人同时提供模型服务，或者追求更高的吞吐量，就要考虑 vLLM（Very Large Language Model Library）这套推理框架。

vLLM 的核心优势是 PagedAttention 和 Continuous Batching 机制。我尽量不把这些术语讲得玄乎：传统推理服务在并发高的时候，每个请求都要占用一块完整的显存空间，效率很低；vLLM 则是把显存切分成小块动态分配，并把多个请求的计算任务拼在一起处理，这样同一张显卡能支撑的并发数明显提升。实际用下来的感觉是：同一张 24GB 显卡，用普通方式可能只能同时服务两三个长对话，但用 vLLM 可以支撑更多稳定并发的请求。

所以在选型上，我的建议是：个人尝试、内网轻量使用，先用 Ollama；如果要做一个正式的私有化服务，直接考虑 vLLM，或者选择 Dify、FastChat 这类集成了 vLLM 的框架。

2.3 LM Studio 和 Open WebUI：不想碰命令行的选择

不是所有人都有耐心面对终端。如果你只是想试验一下本地模型，或者家里长辈想体验离线 AI，LM Studio 这种图形化工具会更友好。下载安装后，在界面里搜索模型、点击下载、选一个会话窗口，基本不需要写命令。LM Studio 也提供了本地 HTTP 服务，方便接入其他应用。

Open WebUI 则是另一个方向：它把模型包装成一个类似 ChatGPT 的网页界面，部署在浏览器中。你可以把 Ollama 作为后端，Open WebUI 作为前端，直接在浏览器里跟私有模型对话，还支持多用户登录、对话历史、附件上传等能力。对一个开发团队来说，这套组合方案已经能解决大部分“我们想要一个内部 AI 助手”的需求。

3. 一套可复现的本地部署实操：用 Qwen 模型做业务问答

3.1 硬件怎么配、模型怎么选：看参数不如看显存

本地部署大模型的第一个实际问题不是“选什么框架”，而是“你的显卡显存有多大”。模型大小和显存之间的关系，可以按这个粗略公式估算：所需显存约等于可量化的模型权重大小，加上上下文推理时占用的 KV Cache，再加上一些运行时开销。

举例来说：

• 7B 模型用 Q4 量化后大约需要 4GB 到 5GB 显存，上下文开 8192 tokens 时，保守要再留 2GB 到 3GB，所以一张 8GB 显卡可以流畅运行；
• 14B 模型 Q4 量化后大约 8GB 到 9GB，想开长上下文，16GB 显存是更好的选择；
• 32B 模型 Q4 量化后接近 20GB，市面上消费级显卡里最稳妥的选择是 24GB 显存版本。

我自己的经验是：如果不是奔着测试最大规模模型去，没必要盲目追求 70B。很多企业内部问答、文档处理、代码辅助任务，7B 到 14B 配合好的提示词和知识库已经能做得不错。模型不是越大越好，是“在能跑的基础上，选最符合任务的那个”。

3.2 从零到运行：一个可以直接抄的部署过程

下面这套步骤，我用在 Linux 服务器上居多，Windows 用户建议用 WSL2 环境，逻辑一致。先是安装 Ollama，可以一条命令完成，也可以去官网下载对应安装包。装完以后，我习惯先设置模型存储目录，避免模型全部堆到系统盘：

export OLLAMA_MODELS=/data/ollama/models ollama serve

然后另开一个终端窗口，拉取模型：

ollama pull qwen2.5:7b ollama run qwen2.5:7b

“ollama run”会进入一个交互式终端。这时候你可以直接问一些业务问题，先判断回答质量。如果默认表现不满意，再用 Modelfile 自定义参数。比如让模型在推理时更稳定一些，可以新建一个名为 Modelfile 的文件：

FROM qwen2.5:7b PARAMETER temperature 0.7 PARAMETER top_p 0.9 PARAMETER num_ctx 8192 PARAMETER num_predict 1024

接着用这个文件创建一个新模型：

ollama create qwen-business -f Modelfile ollama run qwen-business

这里的temperature控制随机性，num_ctx控制模型能看到的上下文长度，num_predict控制单次最大回复长度。不要把它们盲目调大，因为上下文越长，KV Cache 占用的显存和内存也越多。

3.3 让模型服务化：API 调用和聊天界面

如果你不是想坐在服务器前聊天，而是希望业务程序调用模型，那就只需要 Ollama 的服务模式。默认端口是 11434，发一个 POST 请求即可：

curl http://localhost:11434/api/generate \ -H "Content-Type: application/json" \ -d '{"model":"qwen-business","prompt":"用一句话解释什么是RAG","stream":false}'

返回的 JSON 里有response字段，就是模型生成的答案。想要更符合开发习惯的 OpenAI 兼容接口，也可以访问/v1/chat/completions，很多现有代码可以无缝切换。

团队多人使用的时候，我会把 Ollama 的监听地址设为0.0.0.0，然后用 Open WebUI 做一个前端界面。Open WebUI 官方支持 Docker 部署，命令大致是：

docker run -d \ --name open-webui \ --add-host=host.docker.internal:host-gateway \ -p 3000:8080 \ -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \ ghcr.io/open-webui/open-webui:main

启动后在浏览器打开http://localhost:3000，注册一个账号，就能在网页里选择本地模型聊天了。

3.4 关于性能，我实测得到的一组参考值

我手头常用的是一张 16GB 显存的显卡，跑 7B Q4 模型时，生成速度大约在每秒 35 到 45 个 token 之间。作为对比，人正常阅读速度大概是每秒 5 到 8 个字，所以这个速度在实际问答场景中完全够用。14B Q4 模型在同样的显卡上会慢一些，大概每秒 20 到 28 个 token，长文档分析时会有一点点等待感，但也可以接受。

如果完全没有 GPU，纯靠 CPU 跑也不是不行，但速度会比较感人。因为 CPU 推理时每生成一个 token 都要把整个模型的权重读一遍，速度受内存带宽限制。7B Q4 模型的权重约 4GB 到 5GB，DDR5 内存带宽如果只有 60GB/s 左右，那理论最快也只有每秒 12 到 20 个 token。老旧的 DDR4 平台会更低。所以我的建议是：如果只是简单体验，CPU 足够；想真正当生产力工具，至少准备一块 8GB 显存以上的显卡。

4. 本地部署的未来不在“聊天”，而在知识库、Agent 和微调

4.1 用 Dify 把私有文档变成模型的知识库

如果你问一个通用模型“我们公司报销制度是什么”，它大概率回答不上来，因为模型没有见过你的内部文档。解决这个问题通常有两条路：RAG（检索增强生成）和微调。先做的事一定是 RAG，而不是微调。

我现在的常用组合是 Dify + Ollama。Dify 是一个开源的大模型应用开发平台，通过界面就能创建知识库、编排 Prompt、接入工具。它可以把 PDF、Word、TXT 等文档切分后，通过 Embedding 模型转换成向量存入本地向量数据库。用户提问时，系统会先检索相关片段，再把这些片段和问题一起交给本地大模型生成回答。

部署 Dify 的方式不复杂。做完基础安装后，在“模型供应商”里填上 Ollama 的接口地址，再填写本地已下载的模型名称，比如qwen2.5:7b。同时要确保 Embedding 模型也已经拉取到 Ollama：

ollama pull nomic-embed-text

然后在知识库里配置这个 Embedding 模型，上传文档，就能完成一套完全离线的私有知识库问答。整个过程不把任何文档发送到外部服务，这对数据敏感型场景非常重要。

4.2 先做 RAG 再谈微调，顺序一定不能反

很多人一上来就想微调模型，觉得这样才“懂业务”。但微调成本高、周期长，而且并不能解决“事实性”问题。微调更像是改变模型的技能和语气，如果你想把几万条规章制度塞进模型参数里，不仅需要大量高质量训练数据，还很容易让模型产生幻觉。

RAG 的优势在于：文档更新只需要重新入库，不需要重新训练模型；回答时可以明确引用来源，让用户判断答案是否可信；运维成本也低得多。唯一需要注意的是检索的质量，如果文档切分不合理、向量检索召回率低，再强的生成模型也容易答非所问。

所以我的实际建议是：把 RAG 作为第一选择，等确信模型缺少某种表达能力、并且积累了一批高质量问答对时，再考虑微调。

4.3 LLaMA-Factory 让消费级显卡也能做 LoRA

要说本地部署的“未来”，微调也是绕不开的一环。过去微调大模型需要极高的硬件门槛，但 LoRA（Low-Rank Adaptation，低秩适应）和 QLoRA 技术出现后，消费级显卡也能做小规模微调。常用工具是 LLaMA-Factory，它把数据处理、训练、导出封装成了一套比较完整的工作流。

我用 16GB 显存跑过一个小规模指令微调实验，底模是 7B 模型，使用 4 比特量化加 LoRA，训练数据是几千条特定行业的问答对，显存占用基本控制在 10GB 到 12GB 以内。命令大致如下：

llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B \ --stage sft \ --finetuning_type lora \ --quantization_bit 4 \ --dataset industry_qa \ --output_dir outputs/qwen_industry \ --per_device_train_batch_size 1 \ --gradient_accumulation_steps 8

训练完成后，需要把 LoRA 权重和原模型合并，再导出成 Ollama 能用的 GGUF 格式。这个过程比跑推理复杂不少，得对训练数据质量有严格把关，否则微调出来的模型可能连原本的通用能力都丢掉。但一旦链路跑通，本地部署就不只是“调一个现成模型”，而是真正拥有了一个可进化的私有模型。

5. 本地部署的排查手册：这些问题我基本都踩过

5.1 模型下载、磁盘占用和版本管理

本地部署遇到最多的问题不是推理，而是模型资源的管理。一个 7B 模型只有 4GB 多，但 70B 模型甚至有 40GB，如果不设置OLLAMA_MODELS，默认会把模型存到系统盘。我见过好几台服务器因为/root或 C 盘被模型占满而告警。

解决方式就是像前面说的，提前指定模型目录到独立数据盘。另一个容易忽略的点是：同一个模型的不同量化版本会重复占用磁盘空间。所以我一般只保留一个最常用的量化版本，比如 Q4_K_M，它对大部分任务够用且体积适中。如果你不确定该留哪个，先跑 Q4，再根据效果决定是否换更大的 Q8 或 FP16 版本。

5.2 显存不是唯一指标，但 OOM 最常见

跑本地模型最崩溃的瞬间就是看到CUDA out of memory。新手最容易犯的错误是：只关注模型权重大小，不看上下文和并发。同一张显卡，上下文开 2048 和开 32768，显存占用差距很大。我建议在服务稳定之前，先把上下文长度设置为 4096 或 8192，跑通流程后再逐渐调大。

如果确定是 OOM，优先做这几件事：换更小参数的模型、选择更低的量化位数、减小num_ctx、减少并发请求数量。也可以用监控命令确认真实占用：

nvidia-smi

有时候 Ollama 会默认把模型保持在显存中以加快响应速度，如果同一模型并发数过高，会频繁切换、加载，反而更慢。这时候可以关闭自动保持或者限制并发数，让自己对资源使用有更清晰的把控。

5.3 响应慢、输出乱，问题往往不在模型本身

同一个模型在不同人手里，表现可能天差地别。响应慢时，先查底层：是否模型没预热，第一次请求要花几十秒加载；是否网络端口受限；是否并发请求太多互相争抢显存。

输出乱时，先查提示词和采样参数。温度太高，回答会发散；上下文太长，模型可能被无关信息干扰；系统提示词没写清楚角色和输出格式，答案自然五花八门。我习惯把 Prompt 当成“模型的上游代码”来调，把任务边界、格式样例、否定项都写清楚，一次排查一个变量，而不是连续改好几个参数。

5.4 安全和供应链：先解决“模型从哪来”

本地部署不是把模型下载下来就万事大吉。任何模型权重都有可能被恶意投毒，也就是在训练阶段注入特定的触发词或后门行为。你从公开渠道下载模型后，至少要做两件事：第一，尽量从官方源或可信源下载；第二，对模型文件做好哈希校验，和发布方给的校验值对照一下。

另外，把 Ollama 这类服务直接暴露到公网是件非常危险的事，因为它默认没有复杂的鉴权机制。我的做法是：只在内网监听，如需对外提供能力，前置一层 API 网关或者反向代理，加上密钥校验和访问控制。别让“本地部署”变成“裸奔部署”。

6. 给“本地部署大模型有没有未来”的一个答案

6.1 未来会更偏向云、端、本地协同，而不是二选一

如果让我判断，本地部署大模型不会取代云 API，但云 API 也不可能独吞所有需求。更可能出现的情况是分层协同：在手机、电脑、NAS 上跑一个小模型，处理隐私数据、快捷指令和离线任务；在本地服务器上部署一个中等规模模型，服务企业内部的知识库和 Agent；再在云上调用最强模型，处理那些对数据安全要求不高、又非常考验模型上限的复杂任务。

这种协同模式其实跟开车的逻辑很像：短途通行骑电动车，长途出行开汽车，两者各有各的适用场景，不会因为汽车方便就没人骑车，也不会因为骑车轻巧就不造汽车。

6.2 本地部署能守住的位置：私有数据、离线、可解释

未来最有确定性的本地部署场景，我认为有三个：私有数据、离线环境、可解释需求。私有数据和离线环境不用多说，只要还有政务、金融、医疗、制造这些行业存在，数据出域就永远是红线，这些行业里的 AI 应用必然要落在本地私有化基础设施上。

“可解释”这个词看起来软件味儿很重，但实际含义很朴素：别人问你这个 AI 为什么这么回答，你能不能说清楚数据来自哪里、模型版本是什么、中间经过了哪些检索和排序？使用本地部署，你可以完整控制这条链路，而不是对外部接口内部的隐性更新一无所知。

6.3 最后的个人建议

如果你现在问我“本地部署大模型有没有未来”，我的观点很简单：大概率有，但它的未来不是“人人都自己从零训一个模型”，而是“越来越多的人能在本地运行、调试、微调一个自己说了算的模型”。这一年多操作下来，我最深的体会是：本地部署的价值不取决于显存多大，而取决于你能否把模型真正放到业务场景里解决问题。

给想入坑的朋友一个不绕弯的劝告：别一开始就追求跑 70B 大模型，也别把“全功能一键部署”想得太完美。先准备一块 16GB 显存的显卡，把 7B 或 14B 模型跑起来，再用 Dify 接一个你自己的文档，最后再加一个 Agent 工具，这套链路打通之后，你自然就明白本地部署适合做什么、不适合做什么了。那时候再回头看“有没有未来”的问题，你会给出属于自己的答案。