企业官网建设流程全解析

前阵子有个朋友来问我，说公司想做内部知识库问答，数据又不想往云端送，问我“我们自己电脑上到底能不能跑大模型”。我说能跑，而且比你想象的简单。现在开源模型生态已经很成熟了，真正把门槛打到地板上的，就是 Ollama 这个工具。装上它之后，本地化部署大模型基本就三步：把模型拉下来、跑起来、用 API 或者网页界面调它。

这篇文章我会从零开始，把本地部署大模型的完整链路讲清楚：硬件要什么配置、Ollama 在三个平台怎么装、模型怎么选、怎么解决下载慢的问题、怎么用 Modelfile 做定制、怎么把它供成 API，最后再把常见坑和性能调优思路一次性讲透。不管你是第一次碰本地模型，还是已经在用但想玩得更深，这篇应该都能帮上忙。

1. 为什么要把大模型装进自己的电脑

1.1 本地部署解决的真实痛点

先说一个很直白的感受。用云端大模型 API，体验确实顺滑，但在我手里始终有几个绕不过去的问题。

第一个是数据隐私。把公司文档、客户信息、个人笔记丢给在线服务，心里总不踏实。虽然很多平台承诺“数据不会用于训练”，但作为使用者，你很难验证这句话。本地部署意味着模型权重、推理过程、历史会话全部留在你的机器里，数据不出内网，从机制上就断了外泄这条路。对很多企业场景来说，这是刚需，不是什么“洁癖”。

第二个是离线可用。我去年过年回老家，高铁上、乡下没信号的角落，正好想处理点文本，云端 API 全废，本地模型却照常工作。只要你机器还有电，推理就不依赖外网。这种“随取随用”的感觉，用习惯之后真的回不去。

第三个是成本结构。云端 API 是按 token 计费的，你用得越多越贵。大模型这玩意一旦用进工作流，token 消耗涨得很快，每个月结算单看着就肉疼。本地部署是前期一次性投入，之后单次推理的边际成本几乎为零。如果你的使用量稳定且频繁，自己跑模型迟早比按量付费划算。

第四个是可控性。API 服务的版本迭代、负载变化都会影响结果稳定性；本地模型从量化精度、上下文长度、采样参数到 system prompt 全部能自己控，甚至还能做微调。你真正“拥有”这个模型，而不是“租用”它。

用一个生活化的类比：云端 API 就像叫外卖，方便是方便，但你不能改配方，也不能在没网的时候点单。本地部署就像自己开灶做饭，前期洗菜备菜累一点，但之后你完全掌控厨房。

1.2 为什么工具箱里选了 Ollama

本地跑大模型的技术路径其实不少，常见的有 llama.cpp、vLLM、LM Studio，还有 Ollama。我为什么推荐新手从 Ollama 入手？因为它在“开箱即用”这件事上做到了极致。

llama.cpp 是个底层推理引擎，性能好、玩法多，但它更像“零件”，你需要自己编译、自己写脚本、自己搞模型转换。vLLM 是生产级推理服务，PagedAttention 那套机制在高并发场景下确实厉害，但部署复杂度高，对个人电脑来说是大炮打蚊子。LM Studio 的图形界面也不错，但它在服务化、自定义和跨平台脚本化方面，没有 Ollama 这么顺。

Ollama 做的事情很聪明：把模型管理、推理引擎、API 服务全部打包成一个简单的 CLI 工具。安装完之后，你只需要一条ollama run qwen2.5:7b，它就会自动下载模型并启动一个交互式对话界面。底层是 llama.cpp 那套高性能推理，但对外暴露的是极简接口。它自带一个 OpenAPI 兼容的 REST API 服务，端口默认 11434，这意味着任何会发 HTTP 请求的语言都能直接调它，前端、后端、脚本、手机 App 都可以。

我把几个常见方案做过对比，大概是这样：

这里也要说清楚 Ollama 的边界。如果你要部署一个日请求量几十万次的线上服务，那 Ollama 不是最佳选择，vLLM 那类专用引擎才扛得住。但如果你是个人开发者、搞内部工具、做 AI 应用的原型验证，Ollama 是当前性价比最高的起点。后面如果业务量大了，再平滑迁到 vLLM 也不迟，毕竟模型权重是通用的。

2. 部署前的硬件与环境评估

2.1 你的电脑到底能不能跑

很多人的第一反应是：“本地跑大模型是不是要几万块的显卡？”这个想法停留在两年前。现在的开源模型经过量化之后，对硬件的要求已经亲民很多，中端消费级显卡，甚至纯 CPU 都能玩起来。

先理解一个关键概念：模型推理时的显存占用主要来自两部分——模型权重和 KV Cache。模型权重的大小可以粗略估算：模型参数量（B）× 量化位数 ÷ 8。比如一个 7B 模型用 4-bit 量化（Q4_K_M），权重约等于 7 × 4 ÷ 8 = 3.5GB，加上运行时开销，实际占用在 5GB 左右。如果是 14B 模型，大约 8 到 10GB。32B 模型，大概 20GB 左右。KV Cache 则和上下文长度、并发数直接挂钩，上下文开得越大、同时处理的请求越多，它占的显存就越多。

所以“能不能跑”这个问题，最终取决于你的总显存或统一内存大小。我按常见配置整理了一个档位表，方便你对号入座：

如果你没有独显，只要内存够大，Ollama 会退回到 CPU 推理。小参数模型（3B 以下）在比较新的 CPU 上也能有可用的响应速度，但 7B 及以上就有点煎熬了，一个字一个字地往外蹦是常有的事。Apple Silicon 的用户则要注意，Mac 的统一内存架构对这类任务很友好，一个 32GB 内存的 M 系列芯片可以把 14B 甚至 32B 模型跑得非常流畅，因为 CPU 和 GPU 共享同一块大内存。

判断自己硬件能不能跑，还有个笨办法：先装好 Ollama，直接拉一个 7B 模型试跑。如果速度不理想，再往下换 3B。实测永远比理论估算靠谱。

2.2 三平台安装实操：Windows、macOS、Linux

Ollama 官方对三个主流桌面平台都提供了安装包，过程都很傻瓜化。

Windows 是最省事的，去官网下载OllamaSetup.exe，双击安装，一路下一步。装完以后，命令行里输入ollama --version，能输出版本号就说明成功了。这里有一个 Windows 用户经常问的问题：怎么把模型装到 D 盘？默认情况下模型会存在C:\Users\你的用户名\.ollama\models下，如果你 C 盘空间紧张，可以在安装前设置系统环境变量OLLAMA_MODELS，把它指向一个 D 盘的目录，比如D:\ollama_models，再启动服务。改了环境变量之后，一定要重启 Ollama，否则不生效。

macOS 同样简单，有安装包和 Homebrew 两种方式。用 Homebrew 的话，一条命令：brew install ollama。Apple Silicon 用户直接跑就很舒服，Ollama 会自动走 Metal 加速，不需要额外装 CUDA 之类的驱动。

Linux 用户通常用官方脚本安装：

curl -fsSL https://ollama.com/install.sh | sh

这个脚本会自动检测系统架构、安装必要依赖，并把 Ollama 注册成 systemd 服务。安装完成后用systemctl status ollama可以查看服务状态。有一点要提醒：任何curl | sh操作都相当于把系统权限交给脚本，跑之前建议先去官网确认命令，或者下载脚本后先打开看一眼内容再执行。

还有一个常见情况：Windows 用户装了 WSL2，想在里面用 GPU。Ollama 官方其实有 Windows 原生版，原生版已经能直接用显卡了，优先用原生版。如果你确实要在 WSL2 里折腾，记住一个关键点：模型文件要放在 Linux 文件系统内（比如~/ollama_models），不要放在/mnt/c/下面，跨文件系统 IO 会拖慢模型加载速度。

3. 模型下载、选型与自定义

3.1 拉取模型慢怎么办

装好 Ollama 之后，第一件事通常是拉模型，但很多人卡在这一步：ollama pull之后进度条半天不动，或者下载速度只有几十 KB/s。

先说原理。Ollama 默认从官方模型库拉取权重文件，一个 7B 模型的量化文件就有 4GB 左右，加上大文件跨区传输本来就受国际带宽影响，速度波动就会很明显。遇到这种情况，我一般用三个方法来处理。

第一类是换个网络环境。只表述现象的话，不同运营商、不同时段、不同地区访问官方源的速度差异很大。深夜或者工作日上午重试，往往能跑到正常速度。而且 Ollama 的下载支持断点续传，中断了重新执行ollama pull，它会接着之前的进度继续，不用从头再来。

第二类是走社区镜像源。常见做法是把下载源换成国内可访问的模型镜像站。操作上，先设置环境变量，再重新拉取。

以 Linux 或 macOS 为例：

export OLLAMA_HOST=0.0.0.0 export OLLAMA_MODELS=/your/path/to/models # 部分版本可以通过 OLLAMA_BASE_URL 或镜像配置切换源，具体以当时文档为准

Windows 用户在系统环境变量里加同名变量即可。需要留意的是，镜像源有很多都是社区维护的，稳定性不一，选那种持续更新、声明支持 Ollama Registry 协议的镜像相对靠谱。Hugging Face 本身也提供了大量 GGUF 格式的模型文件，配合 hf-mirror 这类镜像站也能手动下载。

第三类是手动导入。你完全可以从第三方渠道把 GGUF 格式的模型文件下载到本地，然后通过 Modelfile 导入到 Ollama。这样最可控，我放在 3.4 节细讲。

下载慢这个问题，我的经验是组合处理：优先试断点续传，不行再换镜像，最后才考虑手动下载导入。直接换镜像往往立竿见影。

3.2 不同硬件档位适合哪些模型

模型选型是本地部署最影响体验的决策点。选大了跑不动，选小了答非所问，所以要学会看“档位”。我按硬件水平给几个具体模型组合，都是实测过或者社区口碑不错的。

入门档（16GB 内存、无独立显卡）：这个配置跑 7B 会很吃力，建议瞄准 1.5B 到 3B 的小模型。Qwen2.5 的 1.5B 和 3B 版本都很能打，做文本改写、关键词提取、小范围问答完全够用。Llama 3.2 的 1B 和 3B 也是轻量选手，英文任务表现不错。

主流档（8GB 显存）：这是大多数游戏本的配置，能流畅跑 7B 到 9B 的 Q4 量化模型。Qwen2.5:7b 是我最常推荐的国产选择，中文理解强，代码能力也好。DeepSeek-R1 的 7B 或 8B 版本则适合推理类任务，它会在回答前生成一段“思考过程”，逻辑性更好，但输出中也包含思考内容，需要自己提取最终答案。

进阶档（16GB 显存）：可以考虑 14B 级别模型。Qwen2.5:14b 的质量明显超过 7B，特别是在长文本和复杂指令上。DeepSeek-R1:14b 的推理能力也很惊艳，应对数学题或逻辑分析比 7B 稳得多。另外，如果你更看重通用对话，GLM-4 的 9B 版本也不错。

高阶档（24GB 及以上显存）：这个级别可以上 32B 模型，比如 Qwen2.5:32b 或 DeepSeek-R1:32b，体验已经很接近商业大模型了。如果有 48GB 以上的设备（比如多卡工作站或 Mac Studio），甚至可以考虑 70B 级模型，但量化级别可能需要降到 Q3，速度也会受内存带宽影响。

再补一句常识：模型不是越大越好，而是要匹配你的任务。你要是只做标题生成，3B 模型调好参数未必比 14B 差，但响应速度快得多。日常使用我一般常驻两个模型：一个 7B 专门做快速任务，一个 14B 做重活。

3.3 高频命令一网打尽

Ollama 的命令体系不复杂，我把我实际高频用到的整理成清单：

进入ollama run之后，它是一个交互式终端，可以直接输入问题。比如：

>>> 用一句话解释什么是量子纠缠

它会立刻返回模型的输出。在这个交互界面里，还有一些斜杠命令：

• /bye退出
• /set parameter temperature 0.7临时调整采样温度
• /show info查看当前模型信息
• /?查看全部帮助

这些临时设置只在当前会话生效，下一次打开又会回到默认值。如果你希望某个参数一直生效，就要用到 Modelfile 或者在 API 请求里带上参数，这正好带出下一节的内容。

3.4 用 Modelfile 打造自己的模型

Modelfile 是 Ollama 的模型自定义文件，类似 Dockerfile。它做的事情，是把底座的模型权重和你的“配置层”打包成一个新模型。你可以把常用的 system prompt、采样参数、甚至新的对话模板固化进去。

一个典型场景：你希望每次启动模型后，它都自动以“资深技术专家”的口吻回答，且输出尽可能简洁。你可以写一个 Modelfile：

FROM qwen2.5:7b SYSTEM 你是一名资深技术专家，回答问题要直接、简洁、专业，最多不超过200字。 PARAMETER temperature 0.3 PARAMETER top_p 0.9 PARAMETER num_ctx 8192

然后执行：

ollama create my-expert -f Modelfile

这样你就有了一个新模型my-expert，以后ollama run my-expert启动后，它会自动加载这些预设参数，不需要每次手动改。这个方法在多人协作时很有用——你把 Modelfile 提交到代码仓库，团队成员ollama create一下就能获得完全一致的行为。

另一个场景是手动导入模型。假设你从某个渠道下载了一个 GGUF 文件，比如my-model.Q4_K_M.gguf，那只要在同目录下写一个 Modelfile：

FROM ./my-model.Q4_K_M.gguf

然后执行ollama create my-model -f Modelfile，Ollama 就会把你的 GGUF 文件注册成一个模型。这样就能把 3.1 节的“手动下载导入”闭环起来。

MODEL 目录的存储结构也值得了解一下。在你的OLLAMA_MODELS目录下，会有blobs和manifests两个子目录。blobs存放的是实际的二进制文件（按哈希命名，去重），manifests存放的是模型的注册信息。如果你手动拷贝别人的模型目录，要确保这两类文件都完整，尤其是 blobs，缺一个文件模型就会加载失败。

还有一个实用参数num_ctx值得单说。它控制上下文窗口长度，默认值偏低（通常是 2048 或 4096），处理长文本时会直接截断。如果你的任务是读文档、长聊天，建议把它改成 8192 或 16384。但要注意，num_ctx开得越大，KV Cache 占用越高，推理速度也会下降。具体改多大，取决于你的显存余量和任务需求。

4. 把本地模型变成 API 服务

4.1 端口与服务配置

Ollama 启动后，默认会在11434端口监听请求。你可以直接浏览器访问http://localhost:11434，看到一句 “Ollama is running” 就说明服务正常。

如果想让它监听所有网卡，让局域网里的其他设备也能访问，设置环境变量：

export OLLAMA_HOST=0.0.0.0

重启服务后，同一局域网内的电脑就能通过http://你的IP:11434访问你的模型服务了。同事可以在自己电脑上直接调用你机器上的模型，一个简易的“共享推理服务器”就搭出来了。不过这里有个重要的安全提醒：Ollama 默认不提供鉴权，一旦对外开放，意味着局域网里的任何人都能调你的模型、消耗你的算力。在不可信网络里，建议不要暴露端口，或者用防火墙做白名单限制。

另外一个很影响体验的参数是OLLAMA_KEEP_ALIVE。它表示模型在无人使用时继续驻留内存的时间，默认是 5 分钟。如果你经常反复调用，模型每次都要重新从磁盘加载，首字延迟会明显拉长。可以把存活时间调长，比如：

export OLLAMA_KEEP_ALIVE=30m

或者设为-1表示永久驻留。代价是显存一直被占着，机器不能同时干其他重活。我日常设置为 30 分钟，兼顾响应速度和资源释放。

4.2 REST API 调用

Ollama 的 API 是标准的 RESTful 风格，用 curl 就能测试。最基础的生成接口是/api/generate：

curl http://localhost:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "用一句话解释什么是数据库索引", "stream": false }'

返回结果是一个 JSON，里面有response、total_duration、eval_count等字段。total_duration是总耗时纳秒数，eval_count是生成的 token 数，两者一除就是推理速度，这是评估性能最直接的手段。

如果你要模拟多轮对话，用/api/chat接口，带上 messages 数组：

curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [ {"role": "system", "content": "你是一个数据库专家。"}, {"role": "user", "content": "介绍一下索引失效的场景"} ], "stream": false }'

注意这里的路径是/v1/chat/completions，它兼容 OpenAI 的接口格式。这意味着你之前写过的、面向 OpenAI API 的代码，只要把base_url改成http://localhost:11434/v1，就能无缝切换到本地模型。

关于流式返回（"stream": true），它会把输出切成一个个数据块实时推送，前端能做成打字机效果，体感上比硬等完整回答顺滑得多。我的建议是：交互场景用流式，脚本场景用非流式，可以省去解析多次响应的麻烦。

如果你用的是 DeepSeek-R1 这类推理模型，响应体里除了常规的content之外，还会多一个reasoning字段，保存模型在正式回答前的思考过程。做产品展示时可以把它折叠起来，只展示最终答案。不少人第一次用的时候没注意到，把思考过程和答案一起渲染给用户，体验就很奇怪。

4.3 用 Python 快速调用

Python 是调用 Ollama 最顺的语言，因为它有官方 SDK。安装很简单：

pip install ollama

然后写一个最简脚本：

import ollama response = ollama.chat( model="qwen2.5:7b", messages=[ {"role": "user", "content": "讲个冷笑话"} ], ) print(response["message"]["content"])

如果要流式接收，改成：

import ollama stream = ollama.chat( model="qwen2.5:7b", messages=[{"role": "user", "content": "讲个冷笑话"}], stream=True, ) for chunk in stream: print(chunk["message"]["content"], end="", flush=True)

如果你已经是 OpenAI SDK 的忠实用户，那更简单：

from openai import OpenAI client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama") response = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": "写一首关于秋天的短诗"}], ) print(response.choices[0].message.content)

api_key随便填个字符串就行，Ollama 不做鉴权校验，但 OpenAI SDK 又强制要求传这个参数，所以用一个占位符。

4.4 搭一个带网页界面的聊天室：Open WebUI

命令行和 API 适合开发者，但如果你想把模型分享给团队做内部工具，或者自己就想有个好用的聊天界面，Open WebUI 几乎是首选。它自带漂亮的聊天页面，支持多模型切换、文件上传、知识库挂载、用户管理，比裸 API 方便太多了。

通过 Docker 启动：

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

启动之后，浏览器访问http://localhost:3000，注册一个账号，然后就能在界面上选择你已经拉好的模型进行对话。第一次用的时候，注册的第一个账号是管理员账号，注意保管好。

这里的关键参数是OLLAMA_BASE_URL。因为 Docker 容器是一个独立网络空间，不能直接用localhost访问宿主机服务，在我的 Linux 和 macOS 环境下用host.docker.internal可以指向宿主机。如果你用 Windows 跑 Docker Desktop，这个内置域名同样适用。如果你的 Open WebUI 和 Ollama 在同一台机器上、且 Ollama 监听在 0.0.0.0，也可以直接填宿主机的局域网 IP。

5. 高频问题与性能调优

5.1 新手最容易踩的坑

我把自己这些年遇到的问题整理成一张速查表，每一条都是真实场景：

其中最常见的两个问题再展开一下。

第一个是context length exceeded。这通常不是你写错了，而是默认num_ctx太小。很多模型的默认上下文只有 2048 或 4096，稍微长一点的 prompt 就会触顶。最简单的办法是在运行前用/set parameter num_ctx 8192临时改，或者直接写进 Modelfile。要记住，这本质上是用显存换上下文，改得太大会加重显存压力。

第二个是中文输出质量不好。很多人以为是模型不行，其实是采样参数没调对。默认 temperature 偏高会让中文输出天马行空，甚至出现生造词。中文任务我习惯把 temperature 压到 0.5 左右，top_p保持 0.9，稳定性和连贯性会立刻上一个台阶。

5.2 性能调优三板斧

本地模型用久了，你会发现流畅度可以继续压榨。我总结为三板斧：量化、上下文、并发。

量化级别的选择对性能影响最直接。同一个 7B 模型，Q8_0 占的显存比 Q4_K_M 翻一倍，参数量是大了，但智能程度提升有限。反过来，Q4_K_M 和 Q5_K_M 是综合口碑最好的两个档位，兼顾体积、速度和质量。如果你的显存还有余量，优先试 Q5_K_M；如果紧张，Q4_K_M 一样能用。Q3 甚至 Q2 的量化我一般不建议日常使用，输出质量掉得比较明显，除非硬件实在跑不动。

上下文长度是显存消耗的隐性大户。KV Cache 的开销和num_ctx近似线性，你从 4096 开到 8192，多占用的显存可能接近一个 1B 小模型。我的建议是：默认任务保持 4096，阅读长文档再临时开到 8192 或 16384，不要一启动就把num_ctx拉满，否则几个长期驻留的模型一起占显存，很容易 OOM。

并发和常驻参数决定多用户场景的吞吐量。OLLAMA_NUM_PARALLEL控制同一个模型同时处理几个请求，默认为 1 或者根据显存自动调。如果多人共用一台机器，适当调高能减少排队，但每个请求都会平摊显存。OLLAMA_KEEP_ALIVE我已经提过，控制模型驻留时间，调长能减少反复加载的等待。

硬件层面还有一个容易忽视的点：模型文件所在地的磁盘速度。Ollama 在每次冷启动（模型不在内存）时都要从磁盘读几十 GB 的模型文件，如果放在机械硬盘上，加载时间可能长达一两分钟，放在 SSD 上十几秒就搞定。有条件的话，把OLLAMA_MODELS目录放到 NVMe SSD 上，算是我做过最便宜的提升。

5.3 我实际跑下来的几点体会

玩本地模型这两年，最大的感受是：别贪大。刚入门的时候我也觉得模型参数越大越厉害，结果就是下载了几十 GB 的大模型，电脑卡成幻灯片，最后还得删掉换回 7B。后来想明白了，本地部署的核心诉求是“在给定的硬件约束内拿到最优结果”，不是跑分竞赛。14B 的 Qwen 在绝大多数任务里给我的体验，已经足够支撑日常工作流了。

第二个体会是，定制化的价值经常被低估。很多人直接把模型原始地拿来用，觉得效果一般。但其实一个针对你业务场景的 system prompt，加上一组调试好的采样参数，往往能让模型表现上一个台阶。这也是为什么我前面反复强调 Modelfile——它不改变模型权重，却能改变模型的使用效果。

第三点是关于稳定性。本地部署不是配置好了就一劳永逸，系统更新、驱动升级、环境变量变动，都可能让服务出一堆奇怪的毛病。我自己的习惯是：所有配置项做成文档或脚本存到仓库里，出问题的时候能快速重建环境。Ollama 的配置其实很薄，真正要管好的是模型目录、环境变量和依赖服务（比如 Docker 里的 Open WebUI）。把这些管好，本地模型服务就能安安静静地一直跑下去。

这篇文章里列举的命令、参数和技巧，都是我实际运行过、踩过坑之后总结出来的。你可能不会用到所有功能，但掌握这些，至少能应对日常开发和个人使用的绝大部分场景。现在就可以打开终端，拉一个 7B 模型，开始自己的本地化部署旅程了。