企业官网建设流程全解析

2026年再回头看本地部署，已经不是什么“极客玩具”了。开源模型的能力曲线一直在往上走，而推理工具经过这两年的迭代，也成熟到了一个很务实的阶段：普通人用 8GB 显卡也能跑 7B 模型，企业用 24GB 到 48GB 显存就能私有化部署一个可用性相当不错的服务。这篇文章我尽量把“怎么选工具”和“怎么跑起来”两件事讲透，结合我自己的实测和踩坑经历，覆盖 Ollama、llama.cpp、vLLM 这几条主流路线，并把显存计算、量化选择、微调框架选型、Dify 接入这些实操细节一起说清楚。

如果你正准备开始本地部署大模型，或者已经在跑但总觉得卡、慢、不稳定，这篇就是给你写的。

1. 先想明白：你为什么要本地部署大模型

很多人上来就问“哪个工具最好”，但实话实说，工具的好坏完全取决于你的场景。我见过有人在 4090 上装了 Ollama，跑得好好的，后来上了生产环境才发现并发扛不住；也见过团队一开始就用 vLLM，结果为了处理一个需求把部署复杂度拉满，最后自己维护得很痛苦。所以选型第一步，是先把需求想清楚。

1.1 三种典型场景，对应三种完全不同的部署方式

第一种是数据敏感场景。企业内部文档、客户资料、代码仓库这些内容不适合传到云端的商业模型。这时候本地部署的核心价值不是“性能”，而是数据不出内网。对这种场景，我一般推荐 Ollama 或 llama.cpp，因为它们简单、可控，模型跑在物理机上，没有多余的中间链路；如果请求量大再考虑上 vLLM。

第二种是高频推理的成本控制场景。团队要调 API 做大量业务调用，公有云按 token 计费，一个月下来账单可能比发工资还扎眼。本地部署的意义是把边际成本压到近乎为零——显卡是固定的，电费可以忽略不计。这种场景需要关注吞吐量和并发能力，我会偏向 vLLM 或 SGLang 这种生产级推理引擎。

第三种是个人学习或离线工作场景。比如你在高铁上、在客户现场、在完全没有外网的环境里需要一个大模型随手用。这时候 Ollama 的小体积、低延迟优势就体现出来了，它甚至不用 GPU，纯 CPU 也能用，只是慢一点。

这三种场景没有优劣之分，但如果你拿处理“个人玩具”的心态去跑生产服务，或者拿生产级部署的复杂度去做个人测试，都会很难受。

1.2 本地部署能跑多大模型，先记住两条原则

原则一：模型参数量决定权重的下限。一个 7B 参数的模型，FP16 精度下光权重就是大概 14GB，INT4 量化后大概 3.5GB。但你还要算上 KV Cache、CUDA context、并发请求的中间数据，实际占用永远比“纯权重”高不少。

原则二：不要只看总显存，还要看单卡还是多卡。24GB 的显卡想跑 32B 模型，INT4 量化后权重约 16GB，看起来余量很大，但如果上下文长度开到 8192 甚至 32768，KV Cache 可能吃掉 4GB 甚至更多。再叠加多个并发请求，爆显存是分分钟的事。

我建议你先把目标模型的量化等级和上下文长度定下来，再回头选工具，否则很容易出现“模型拉下来了，卡上跑不动”的尴尬。

2. 2026 主流工具全家桶：从 Ollama 到 vLLM

现在市面上能用的推理工具不少，但真正值得花时间研究的就那几个。我按“从简单到复杂、从个人到生产”的顺序给你拆开讲。

2.1 Ollama：入门首选，但别指望它扛高并发

Ollama 应该是过去两年普及度最高的本地推理工具，没有之一。它把模型下载、量化管理、推理服务打包成了一个非常友好的体验。你要做的事无非三条命令：ollama pull、ollama run、ollama list。

Ollama 底层用的是 llama.cpp，所以它对 GGUF 格式支持很好，量化模型直接拉下来就能跑。它还会自动做显存加载、上下文窗口管理，对新手极其友好。我自己给朋友推荐入门都是一句话：先装 Ollama，跑通再说。

但它的短板也很明显：吞吐量和并发调度并不算强。单请求、短对话，它的延迟表现不错；一旦要同时服务很多用户，或者需要流式输出大量 token，它的排队和控制能力就会露怯。所以我的建议是：个人使用、内部小范围测试、边缘设备部署，用 Ollama 很好；生产环境高并发，还是看 vLLM。

2.2 llama.cpp / GGUF：硬件不够时的救命稻草

llama.cpp 是纯 C/C++ 实现，设计目标就是低资源跑大模型。它最拿手的是 CPU 推理、旧显卡、显存不足时把一部分层 offload 到内存。你现在看到的各种 GGUF 量化格式，基本就是围绕它发展出来的生态。

如果你手里是一台没有 NVIDIA 显卡的机器，或者只有一张 4GB 的入门卡，llama.cpp 通常比你硬上 PyTorch + Transformers 要顺畅得多。它自己也带了一个llama-server，能提供 OpenAI 兼容接口，所以不是只能跑命令行。

缺点是配置和编译需要一些动手能力，编译时还要针对自己的 CPU / GPU 做优化，比如是否启用 CUDA、Metal 还是 RoCM。如果不想折腾，直接用 Ollama(它内置了 llama.cpp)就好。

2.3 vLLM / SGLang：生产级推理的正确打开方式

一旦你要把本地模型当线上 API 用，Ollama 就不太够用了。vLLM 的核心优势是 PagedAttention 和 Continuous Batching，简单说就是能让一批请求共享显存、动态插队，把 GPU 的吞吐压榨得更狠。

我在实测定长文本生成时，vLLM 的吞吐量通常能比直接跑 Transformers 翻几倍。它启动后直接提供 OpenAI 兼容的/v1/chat/completions接口，下游应用几乎不用改代码就能接。

SGLang 是后起之秀，它在结构化输出、多轮记忆、RadixAttention 上有一些独到优化，如果你主要做 Agent 或者复杂 workflow，可以重点关注。但整体生态和文档成熟度，vLLM 目前还是更稳。

2.4 LM Studio / GPT4All：不想敲命令行的桌面派

如果你就是想在笔记本上装个 GUI，点鼠标跑模型，LM Studio 和 GPT4All 都很合适。LM Studio 对 GGUF 模型的管理非常直观，可以下载、加载、聊天、开一个本地服务给其他应用用；GPT4All 更轻量，适合随时打开问两句。

这类工具的好处是零门槛，坏处是性能和定制能力都有限。它们更适合体验，不适合做重型服务。

2.5 微调工具框架选型：跑起来之后绕不开的话题

推理只是本地化的第一步。真正要让模型贴合自己的数据，微调迟早绕不开。2026 年最主流的微调框架，我列一下我的实际体感：

我目前个人最常用的组合是：数据整理阶段用 LLaMA-Factory 快速验证，正式训练时用 Unsloth 的 QLoRA 跑小批量实验。如果你的显存只有 8GB 左右，别去碰全参微调，QLoRA 4bit 才是你的朋友。

3. 硬件与量化：一张显卡到底能跑多大的模型

工具选完之后，最现实的约束来了：你的硬件到底能跑什么模型？很多人栽在“模型下载了，结果显存不够”这一步。这里我把计算方法和选择思路给你讲透。

3.1 先算显存账：量化等级与模型参数的换算

先记住一个基础换算公式：

权重显存 ≈ 参数量（十亿） × 每参数字节数

不同精度对应关系如下：

这只是权重。真正跑起来，你还需要算 KV Cache。KV Cache 的大小大致和“序列长度 × 层数 × 注意力头数”有关，实操经验是：7B 模型在 8K 上下文下，KV Cache 大约 1GB 到 2GB；再叠加 CUDA context、激活值、碎片，我建议实际留出 20% 的余量。

举个例子：一张 8GB 显卡跑 7B Q4 模型，权重 3.5GB，KV Cache 和运行时额外占用 2GB 左右，总共 5.5GB 上下，能跑；但如果把上下文开到 32K，再加多个并发，8GB 就非常危险。而一张 24GB 显卡跑 32B Q4，权重 16GB，余量 8GB，日常使用完全没问题，但想上 70B 就基本不可能了。

3.2 CPU 与边缘设备路线：Jetson Orin 这类设备怎么玩

不是所有部署都非得有高端显卡。Jetson Orin 这类边缘设备在工业现场、机器人、嵌入式场景用得越来越多。它的显存和内存是共享的，跑大模型的原则是“选小模型，上重度量化”。

如果你要在 Jetson Orin 上部署 DeepSeek 这类模型的蒸馏小版本，比如 1.5B、3B、7B 的 INT4 版本，体验会好很多。原因是这类设备的内存带宽虽然比笔记本好，但和真正的显卡还是有差距，模型越大，推理越容易变成内存带宽瓶颈。建议优先用 llama.cpp 的 CUDA 版本，并搭配 Q4_K_M 量化，效果比直接用 PyTorch 要好一个量级。

CPU 路线的话，关键看内存带宽。同样一个 7B Q4 模型，在 DDR5 双通道的笔记本上可能只有 2 到 3 tok/s，在服务器 DDR5 八通道上能到 10 tok/s 以上。能用 GPU 还是尽量用 GPU，CPU 只是“有胜于无”的兜底方案。

3.3 显存不够的软出路：量化、投机采样和 KV Cache 优化

如果你评估之后发现显存差一点，不是只有“换卡”一条路。2026 年有几个常见手段：

• 换更狠的量化。从 Q8 降到 Q4，再从 Q4_K_M 降到 Q4_K_S，模型体积能再压缩 20% 到 30%，但精度和效果会有轻微下降。
• 启用 FlashAttention。它能显著减少显存占用，同时加速推理。
• 收紧 KV Cache。长度限制短一点，或者开启 KV Cache 量化，能省出不少空间。
• 投机采样（Speculative Decoding）。用一个小的 draft model 做初稿，大模型做校验，实际加速明显。

这些手段优先级要看工具支持情况：Ollama 里能调的部分不多，但 vLLM 和 llama.cpp 都有相关参数。你先跑一次，观察日志里的显存占用，再决定优化方向。

4. 实操流程：从下载模型到对外提供服务全链路

聊完理论，直接上实操。这一节我会把从零到可用 API 的完整链路走一遍，涵盖 Ollama、vLLM 和 Dify 三种典型用法。

4.1 环境准备：先把地基打好

系统层面，如果你是 Linux 服务器，推荐 Ubuntu 22.04 或 24.04。NVIDIA 驱动需要提前装好，CUDA 版本尽量用 12.x。Python 环境我建议用 conda 或 uv 隔离，不要一股脑装到系统 Python 里，否则后面依赖冲突会想砸键盘。

模型下载方面，推荐用 Hugging Face 官方 CLI：

pip install -U huggingface_hub huggingface-cli download Qwen/Qwen2.5-7B-Instruct-GGUF --local-dir ./models/qwen2.5-7b-instruct-gguf

如果网络环境不好，可以换国内镜像，具体地址不同阶段有变化，核心思路是下载带断点续传，不要用浏览器下载几十 GB 的大文件。目录规划也重要，我习惯把所有模型放在一个独立磁盘目录下，比如/data/models，避免和系统盘抢空间。

4.2 用 Ollama 十分钟跑通第一个对话

Ollama 的安装很简单，官方脚本一键完成：

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

装完后拉模型：

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

看到命令行进入对话状态，输入“你好”，能正常回复，就算跑通了。如果你想要自定义系统提示词，可以用 Modelfile：

FROM qwen2.5:7b SYSTEM "你是一个严谨的文档助手，回答尽量简洁，并给出来源依据。"

然后创建模型：

ollama create my-assistant -f Modelfile ollama run my-assistant

Ollama 默认在localhost:11434提供 API，你可以很快验证：

curl http://localhost:11434/api/chat -H "Content-Type: application/json" -d \ '{"model":"qwen2.5:7b","messages":[{"role":"user","content":"介绍一下你自己"}]}'

到这一步，你已经完成了本地部署的最小闭环。但要注意，这个服务默认没有鉴权，生产环境至少要加一层反向代理和 Token 校验。

4.3 生产级部署：vLLM + OpenAI 兼容 API

如果你需要稳定并发、高吞吐，直接用 vLLM 部署。先安装：

pip install vllm

然后启动服务：

vllm serve Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.90

这里--max-model-len 8192限制最大上下文，避免显存被吃满；--gpu-memory-utilization 0.90表示允许模型最多占用九成显存，留一点余量给系统和调度。

启动日志出现“Application startup complete”之后，就能用 OpenAI SDK 直接请求：

curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"Qwen/Qwen2.5-7B-Instruct","messages":[{"role":"user","content":"你好"}],"stream":true}'

模型名要跟启动时参数一致，一般默认是完整的 Hugging Face repo 名称。下游代码把base_url改成http://localhost:8000/v1，API key 随便填一个占位符即可。

4.4 接入 Dify 这类应用编排平台

本地模型跑通后，真正落地往往要接到应用。Dify 是我目前用得最多的开源 LLM 应用平台，它可以把知识库、工作流、Agent 和模型层组合起来。

Dify 本地部署一般用 Docker Compose，模型接入方式选“OpenAI-API-compatible”这一类。要注意 Docker 容器访问宿主机端口时不能直接写localhost，需要写http://host.docker.internal:8000/v1；如果是 Linux 容器，有时候要写网关地址http://172.17.0.1:8000/v1。填上之后，再设置模型名称对应 vLLM 启动时的模型 ID，API key 随便填，保存后就能在应用里选到这个本地模型。

这一步踩坑的人特别多，表面上看起来是“模型连不上”，其实八成是容器的网络命名空间和宿主机不互通导致的。先说结论：Docker 里访问宿主机服务，首选host.docker.internal。

5. 实测对比：同一台机器上不同工具的真实差距

理论讲再多，不如一组实测数据来得直观。我在一台 RTX 4090 24G 上做过一轮非严格 benchmark，模型是 Qwen2.5-14B-Instruct 的 INT4 版本，上下文 8192。数据仅供你感受工具之间的差异趋势，具体数字会因驱动、模型量化、输入长度不同而波动。

单个请求时，Ollama 和 llama.cpp 的生成速度甚至比 vLLM 还高，因为 vLLM 在低负载下会有一些调度开销。但并发一上来，vLLM 的优势立刻显现：它能把多个请求塞进同一个 batch，共享 KV Cache 和计算资源，所以 8 并发时仍然能稳定在 20 tok/s 以上，而 Ollama 在 8 并发时已经明显排队。

这个对比说明一个核心问题：单看“谁跑得快”没有意义，要看“谁在什么负载下跑得快”。一个人自己聊天，Ollama 很爽；一个应用有几十个人同时用，vLLM 才是真正能扛事的那个。

5.1 不同规模模型的推荐组合

根据我的实际经验，给你一套可抄作业的组合：

这套组合不是绝对标准，但能帮你快速划定选型范围。预算有限的个人用户，直接把目标投到“7B 模型 + Ollama”这组上，效果和性价比最均衡。

6. 避坑清单：我从踩坑里总结的六条经验

最后这部分，我不想写“你应当注意以下几点”这种空话，直接把踩过的坑和对应的处理办法列出来，每一条都是真金白银换来的。

6.1 显存账少算 KV Cache，爆显存后怀疑人生

我第一次部署 13B 模型时，算了一下权重差不多 7GB，放进 8GB 显卡绰绰有余。结果一跑长对话，直接 OOM。原因就是没算 KV Cache。尤其是上下文长度一拉开，KV Cache 的增长非常快。现在我的习惯是启动前先用ollama list查看已占显存，并把num_ctx或者max_model_len限制在一个合理值，比如 8K。宁可损失一些长文本能力，也要保稳定。

6.2 混淆 GGUF 和 SafeTensor，导致下载两次

Ollama 用 GGUF，vLLM 用 SafeTensor(AWQ/GPTQ 是量化版)。如果先下载了一堆 GGUF，想换 vLLM 跑才发现用不了，又要重新下载几十 GB，很痛苦。建议一开始就定好路线：个人日常用 GGUF，生产服务用 SafeTensor 或 AWQ。如果追求通用，有些工具比如 llama.cpp 也能加载部分 SafeTensor，但转换过程并不平滑。

6.3 生产服务忘记加鉴权，被外面打到资源耗尽

本地部署的 API 默认监听所有网络接口时，没有任何鉴权。如果你直接把它暴露在公网，基本等于送菜。至少要做两件事：内网部署，不对外暴露端口；必须外网访问时，前面加 Nginx 并开启基本鉴权或 Token 校验。这个坑我见过不止一次，希望大家引以为鉴。

6.4 Python 环境互相污染，CUDA 版本暗坑不断

要跑 vLLM、ComfyUI、MinerU、CosyVoice 这些周边工具时，对 CUDA 和 PyTorch 版本要求各不相同。我一开始喜欢把所有东西装进一个 conda 环境，结果 vLLM 要求 PyTorch 2.5，ComfyUI 又跟着不同插件走，最后冲突到怀疑人生。现在我会针对每个项目建独立虚拟环境，并固定核心依赖版本。这个习惯能省下大量排查时间。

6.5 在 Docker 里访问宿主机端口，local 是永远连不上的

Dify 容器要连 vLLM 服务，最典型的错误就是写http://localhost:8000。容器内的 localhost 是容器自己，不是宿主机。改成http://host.docker.internal:8000或网关 IP 之后基本都能通。封装成配置项时，我会把“宿主机地址”通过环境变量注入，避免不同环境的差异让人懵。

6.6 微调不是玄学，数据准备比框架重要

如果你已经进入微调阶段，你会发现框架不是瓶颈，数据才是。同样用 LLaMA-Factory，有人做出来的模型效果不错，有人一塌糊涂，区别主要在于数据清洗和 prompt 格式。建议先做一个“小数据实验”：拿 1000 条高质量样本，把 LoRA rank 调到 16，跑通流程后观察 loss，没问题再放大到全量数据。不要一上来就全量微调，浪费显卡不说，出了问题还很难排查。

我个人实际用下来，2026 年本地部署大模型的门槛已经低到“一台普通游戏笔记本就能玩 7B 模型”的程度。真正难的不是跑起来，而是根据需求选对工具、算好显存、处理好周边依赖。把上面这几条路走一遍，你就不会再被“选什么工具”“怎么部署”“为什么跑不起来”这种问题卡住。最后提醒一句：生产环境别贪新，稳定优先，先把一条链路完全跑通再扩容。