企业官网建设流程全解析

折腾大模型本地部署这件事，我前后花了整整两天，把三种主流路线全跑通之后才敢说"保姆级"这三个字。今天这篇就把完整过程分享出来——从硬件怎么算、模型怎么选，到 Ollama、LM Studio、vLLM 三种部署方式的具体操作步骤、关键参数、调用方法，再加上我实际踩过的几个坑。不管你是刚接触大模型的小白，还是准备把本地推理接入产品线的开发者，这套流程可以直接参考，照着一步步走就能跑起来。

1. 为什么要把大模型搬回本地：先想清楚再动手

1.1 本地部署解决的三个核心问题

先说我遇到的一个典型场景。去年帮一家小公司搭内部知识库问答，对方提的第一条硬性要求就是：数据绝对不能出公司内网。他们的合同、技术文档、客户资料都属于敏感信息，上传到任何云端 API 都有泄露风险，如果硬要用在线大模型，就得自建隐私过滤层、设计复杂的脱敏流程，一圈绕下来成本比部署本身还高。而模型跑在本地服务器上，数据从头到尾只在本机流转，合规问题直接消失。这是很多人选择本地部署的第一动力。

第二个场景是成本。商业 API 按 token 计费，单看单价不算贵，但一旦高频调用、批量跑数据，月底账单会非常可观。我身边有做社群运营的朋友，每个月靠 API 做内容二次创作，账单轻松上千。开源模型本地跑，主要成本就是电费和硬件折旧，对固定场景、固定数据量的需求来说，算总账比订阅 API 划算得多。

第三个是可控性。本地部署意味着模型权重、推理参数、上下文逻辑全在自己手里，想调试就调试，想接 LoRA 微调就微调，想配私有知识库就配私有知识库，不用受远端 API 的版本更新和政策变动影响。尤其对开发者而言，这种"什么都能动"的掌控感，才是本地部署真正的吸引力所在，也是它被越来越多人关注的根本原因。

1.2 先算一笔账：你的硬件能跑多大的模型

新手最关心的永远是"我的电脑能不能跑"。决定因素其实不是 CPU，也不是内存大小，而是 GPU 显存。模型参数量级和显存需求之间有一个经验公式：所需显存约等于模型参数量乘以每个参数占用的字节数，再乘以 1.2 左右的运行余量系数。

以 7B（70 亿参数）模型为例：

• 用 FP16（半精度，每个参数 2 字节）推理：70 亿 × 2 字节 ≈ 14GB，加上运行时开销，一张 16GB 显存的显卡才比较稳妥。
• 用 INT4（4 位量化，每个参数 0.5 字节）推理：70 亿 × 0.5 字节 ≈ 3.5GB，加上 KV Cache 和其他开销，实际需要 5GB 到 6GB 显存。

按这个逻辑推算，13B 模型 INT4 量化大约需要 7GB 到 8GB 显存，70B 模型 INT4 量化需要 35GB 到 40GB 显存。所以你的硬件水平直接决定了能跑多大模型：

选模型别盲目追大。以中文文档问答为例，7B 到 14B 的量化模型已经能给出很不错的回答，70B 模型确实更聪明，但硬件要求成倍上升。先确定自己的显存边界，再决定模型规模，这是本地部署的第一步，也是最容易被忽略的一步。

1.3 量化精度怎么选：GGUF 与 fp16 的那些事

"量化"这个词听起来高大上，本质就是压缩。FP16 是每个参数用 16 位浮点表示，模型质量高但体积大；INT4 是把参数压缩到 4 位整数，体积缩小到接近四分之一，质量略有下降，但在大多数日常任务里几乎无感。GGUF 格式就是为量化而生的主流存储格式，Ollama、LM Studio、llama.cpp 生态都基于它运行。

挑选模型时，你会看到 Q4_K_M、Q5_K_M、Q8_0 这样的后缀，它们代表不同的量化档位。Q4_K_M 是质量与体积的均衡点，显存紧张时的首选；Q5_K_M 比 Q4 更接近原始质量，显存足够时更推荐；Q8_0 接近原始 fp16 质量，但体积和显存需求明显上升；fp16 一般只在显存非常充裕时才选。

我的建议是：第一次用，直接选 Q4_K_M，先在配置不太高的机器上跑通，确认效果满意后再考虑要不要换更高精度版本。别一上来就下 fp16，不然很容易在加载阶段就撞上显存天花板，白白浪费时间。

2. 方法一：Ollama，五分钟跑起第一个大模型

2.1 安装与第一次运行

Ollama 是目前把本地部署门槛压到最低的工具，没有之一。它的设计哲学有点像 Docker：一条命令拉取模型、一条命令启动服务，把模型下载、格式转换、推理进程管理全部封装好。对第一次接触本地大模型的人来说，这是最友好的入门选择。

我以 macOS 环境为例走一遍完整流程，Windows 和 Linux 的操作几乎相同：

1. 打开 ollama.com ，下载对应操作系统的安装包，双击安装。
2. 打开终端，输入ollama --version，确认安装成功。
3. 执行ollama run deepseek-r1:7b，Ollama 会自动下载模型，下载完成后直接进入交互式对话界面。

我第一次跑通时，从安装到跟模型对话只花了不到十分钟。Ollama 官方模型库里有大量热门模型，比如 qwen2.5、llama3.2、deepseek-r1 等，命名规则通常是"模型名:参数规模"。比如ollama run qwen2.5:14b就是运行 14B 版本的 Qwen。想找更多模型，在模型库页面搜索即可，上面会标注每个模型的参数量、量化精度和建议显存。

2.2 管理模型目录与局域网访问

用 Ollama 过程中最常遇到的两个问题：模型下载速度慢，以及模型文件把磁盘占满了。

先说下载。模型文件动辄几个 GB，如果你的网络环境下载官方源很慢，有两条路可以走：一条是耐心等待，期间确保电脑不要休眠；另一条是去模型托管平台手动下载 GGUF 格式的模型文件，放到本地目录后通过ollama create命令导入。手动导入的方式可以更精确地选择模型文件，同时能保留一份可复用的模型副本，方便以后换机器。

再说磁盘。Ollama 默认把模型放在系统盘的用户目录，跑两三个模型后几十 GB 空间就没了。解决办法是设置环境变量OLLAMA_MODELS，指定一个空间充裕的目录，比如D:\ollama_models，然后重启 Ollama 服务。如果模型已经下载到默认目录，直接把旧目录下的文件复制到新目录再重启即可，不丢失模型。

还有一点容易被忽略：OLLAMA_HOST环境变量控制监听地址，默认是127.0.0.1:11434，只允许本机访问。如果想让同一局域网内的其他机器调用这台机器的模型服务，把它改成0.0.0.0:11434并重启就能生效。但开放局域网访问等于把推理端口暴露在网络上，建议只在可信内网里这么做，别直接暴露到公网。

2.3 用 API 把模型接到自己的应用里

Ollama 最大的实用价值，是它自带一个 OpenAI 风格兼容的本地 API。服务启动后默认监听 11434 端口，可以用 curl 验证：

curl http://127.0.0.1:11434/api/generate -d '{ "model": "deepseek-r1:7b", "prompt": "用一句话解释什么是大模型量化", "stream": false }'

返回的 JSON 里就能看到完整回复。如果想在 Python 项目中使用，只需要几行代码：

import requests r = requests.post( "http://127.0.0.1:11434/api/generate", json={ "model": "deepseek-r1:7b", "prompt": "翻译这段英文：Hello world", "stream": False } ) print(r.json()["response"])

这套接口和 OpenAI 的 Chat Completions 非常接近。很多应用只需要把原来的base_url从云端地址改成http://127.0.0.1:11434/v1，就能从云端切换到本地，对整个现有项目的改动很小。这也是 Ollama 能成为很多本地应用首选方案的原因。

3. 方法二：LM Studio，鼠标点击式部署与模型管理

3.1 为什么还需要一个图形化工具

Ollama 确实好用，但如果完全在终端里操作，对非程序员朋友来说还是有不小的心理门槛。LM Studio 解决的就是这个问题：它把模型搜索、下载、加载、推理参数调节、本地服务启动、聊天测试全部做进了图形界面，全程不需要写代码。

它的使用流程可以概括为四个动作：搜索模型、点击下载、点击 Load、点击 Start Server。真正做到了"鼠标点按全程"。对开发者来说，LM Studio 还有一个很实用的价值：当你需要快速比较不同尺寸、不同量化精度的模型在同一个问题上的表现时，图形界面的直观程度远超命令行。

我自己在 Mac 上的体验尤其好。Ollama 在 Apple Silicon 上也能用，但有时候要手动处理 GPU 相关参数；LM Studio 会自动识别 M 系列芯片并启用 GPU 加速，开箱即用。如果你用的是 MacBook，又不想折腾终端，LM Studio 几乎是零门槛的答案。

3.2 量化版本选择与推理参数调节

打开 LM Studio 的搜索栏，输入模型名，界面会列出所有可下载的文件。同一个模型有多个文件，区别主要在量化精度。下载之前建议参考下面这张表：

我在没有理解这些后缀之前，给一张老显卡直接下了 fp16 的 7B 模型，结果每次加载到一半就报显存不足。换成 Q4_K_M 之后立刻流畅起来。所以第二个坑就是：先看清量化后缀再下载。

加载模型后，界面里有几个关键参数需要关注。GPU Offload 决定多少层交给显卡计算，拉到最大可以让推理速度最快，但前提是显存够用；Context Length 是上下文长度，做长文档问答时记得调大，否则模型会"忘记"前面的内容，但调太大也会增加显存占用；Temperature 是采样温度，越高回复越有创造性，越低越保守，文档问答场景建议设置在 0.2 到 0.7 之间。

3.3 启动本地 OpenAI 兼容服务

LM Studio 的聊天窗口可以作为快速测试工具，但真正把它当服务用，是在 Developer 面板。点击 Start Server 后，LM Studio 会在本机启动一个 OpenAI 兼容的 API 服务，默认端口是 1234。

启动后，任何支持自定义 OpenAI API 地址的工具都能接入。我试过用它连接 Dify、LobeChat 和 Cherry Studio 这类开源项目，配置方式都一样：在设置里把 Base URL 填成http://127.0.0.1:1234/v1，API Key 填任意字符串即可连通。对想快速搭建个人知识库或聊天应用的人来说，LM Studio 的角色就是"模型中转服务器"，让上层应用完全感知不到底层模型的变化。

一个实用的提醒：LM Studio 支持同时加载多个模型，可以方便地切换测试，但不要同时启动多个推理服务，否则显存很快会吃满，反而导致所有模型都变慢。一次只跑一个模型，是保持体验稳定的前提。

4. 方法三：vLLM，追求吞吐与生产环境的硬核方案

4.1 vLLM 适合谁，它解决了什么问题

Ollama 和 LM Studio 解决的是"用起来"的问题，但如果你是面向几十个甚至上百个并发请求提供推理服务，或者要在多卡环境下跑大模型，它们就有点吃力了。这时候就该上 vLLM。

vLLM 是当前开源社区最流行的高性能推理引擎之一。它的核心优势来自 PagedAttention 技术，我尽量用大白话解释：普通的 KV Cache 管理方式会预留整块显存给每个请求，容易造成浪费；PagedAttention 按照页面来管理缓存，就像操作系统管理内存一样按需分配和回收，显存利用率大幅提升。同时 vLLM 支持连续批处理，同一个 GPU 上可以同时处理大量请求，吞吐量经常是家用工具的数倍。

它的目标人群很清晰：想把模型跑成一个稳定的、支持高并发的 API 服务的团队；需要多卡并行推理但不想手写并行逻辑的开发者；以及已经在其他工具上跑通，却发现性能撑不住业务量的进阶用户。vLLM 在纯 CPU 环境里基本跑不动，主力场景是 NVIDIA GPU 或较新的 Apple Silicon。

4.2 安装与启动 OpenAI 兼容服务

vLLM 的安装依赖 Python 环境，推荐用 pip 安装：

pip install vllm

安装完成后，启动推理服务只需要一条命令。以下以 DeepSeek-R1 蒸馏版 7B 为例：

vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B --tensor-parallel-size 1

这个命令会自动从模型托管平台下载模型文件并启动服务，默认监听 8000 端口，同时提供 OpenAI 风格的/v1/chat/completions接口。--tensor-parallel-size 1表示用 1 张 GPU 推理；如果机器有多张卡，把这个数字改成对应卡数，vLLM 会自动做模型并行切分，省去你自己写分布式逻辑的麻烦。

服务启动后，可以用 openai SDK 快速验证：

from openai import OpenAI client = OpenAI(base_url="http://127.0.0.1:8000/v1", api_key="EMPTY") r = client.chat.completions.create( model="deepseek-ai/DeepSeek-R1-Distill-Qwen-7B", messages=[{"role": "user", "content": "帮我写一段本地部署的总结"}] ) print(r.choices[0].message.content)

这里api_key填什么都可以，本地服务不需要真正的密钥验证。几个常用启动参数我也列一下：--max-model-len 8192限制最大输入长度，保护显存；--gpu-memory-utilization 0.9控制 GPU 显存上限，防止服务崩溃；--served-model-name my-model自定义 API 中的模型名称，方便服务隔离和路由。

4.3 vLLM 与 Ollama/LM Studio 的本质差异

经常有人问："已经有 Ollama 了，为什么还要学 vLLM？"我的回答是：两者定位不同，不是替代关系。

Ollama 的设计目标是把部署复杂度降到最低，对单个用户、单个并发请求非常友好；vLLM 的设计目标则是最大化吞吐量，在多并发场景下的表现远非 Ollama 能比。做个不太精确的类比：Ollama 像家用轿车，好开好停；vLLM 像货运卡车，载重和效率远超家用车，但需要你具备一定的驾驶技能和适合的运行条件。

从资源占用上看，vLLM 启动时需要把模型预加载进显存，运行时的显存管理也更激进，不适合在低配机器上硬扛。我的实际做法是：本地开发调试用 Ollama 或 LM Studio，快速验证效果；正式部署到服务器、对外提供 API 服务时再用 vLLM。两条路各自有各自的阵地，没必要互相替代。

5. 部署完之后的事：微调扩展与踩坑记录

5.1 从部署到微调：LoRA 与动手学大模型

部署完成只是第一步。如果你希望模型更懂自己的业务术语，比如公司的产品名、行业黑话，就需要做一次轻量微调。中小团队最主流的方案是 LoRA，它的思路是不修改模型的全部权重，而是训练一个很小的低秩适配器，训练成本低、显存占用少，训练完只得到一个几百 MB 的适配文件，用起来非常灵活。

LoRA 的本地接入链路大概是：用 Hugging Face Transformers 和 PEFT 库加载基础模型，用业务数据训练 LoRA 适配器，再把适配器合并进原始模型或单独保存。GGUF 格式的模型可以封装成 Modelfile 后导入 Ollama；vLLM 则自带 LoRA 动态加载功能，支持在 API 请求中指定不同适配器。

这套流程对硬件的要求比想象中低。我做过一次 7B 模型的 LoRA 微调，用的是一张 24GB 显存的显卡，训练数据几千条，整个流程能非常平稳地跑完。想系统学习微调链路，推荐看上海交大团队公开的"动手学大模型"开源项目，里面覆盖了完整的数据处理、训练代码和实验结果，作为入门资料非常扎实。

5.2 踩过的三个坑：OOM、量化格式混用和上下文截断

先说显存溢出。新手最常见的错误是直接把高精度模型塞进小显存显卡，比如给 8GB 显卡下 fp16 的 13B 模型，加载时就会报 OOM。解决方向有三个：换低量化精度模型、限制上下文长度、同时少加载几个模型。我跑 13B 模型时，把 Context Length 从 8192 降到 4096，显存压力立刻降了一大截。

第二个坑是量化格式混用。GGUF 和 safetensors 是两套完全不同的格式，前者用于 llama.cpp 系推理工具，后者用于 Transformers 训练和加载。很多人下载模型时不注意，导致 Ollama 加载不了 safetensors，或者训练脚本加载不了 GGUF。我的习惯是在本地准备两个目录，一个放 GGUF 推理文件，一个放 safetensors 训练文件，各用各的，绝不混。

第三个坑是长文本截断。部署时如果不主动调大上下文长度，很多模型默认只处理 2048 或 4096 个 token。当你的文档长度超过限制时，模型会直接忽略后面的内容，表现为"回答不完整"或"漏掉了后面的关键信息"。排查方法很直接：看请求日志里的 token 用量，如果每次都顶着上下文上限，就该调大max_model_len，或者对输入文本做分块处理。

5.3 三种方法怎么选：一张表说清楚

最后把三条路线放在一起做个总结，方便你按自己的情况做判断：

如果是第一次接触，从 Ollama 开始，先跑通一个 7B 模型感受整体流程；如果习惯图形界面，或者主力机是 Mac，直接用 LM Studio；一旦你要把模型服务化、给多个业务系统提供推理能力，再切换到 vLLM。三条路线完全可以在项目不同阶段交替使用，本地开发用 Ollama 或 LM Studio，生产环境用 vLLM，切换成本其实很低。

最后再分享一个我自己的习惯：每次部署新模型，我会记一张"硬件-模型-量化-上下文长度"的四元组清单，比如RTX 4090 - deepseek-r1:7b - Q4_K_M - 8192。下次换机器或换模型时，直接对照这张表就能预判能不能跑、大概什么速度。踩过几次坑之后你会发现，本地部署最大的成本往往不是下载模型，而是排查运行环境里的各种玄学问题。养成记录变量的习惯，比任何教程都更能帮你节省时间。