本地部署 LLM 的几种实用方案

如果模型文件想放到别的盘，或者服务要对外监听，直接在 service 里加环境变量就行：

[Service]
Environment="OLLAMA_HOST=0.0.0.0:7861"
Environment="OLLAMA_MODELS=/www/algorithm/LLM_model/models"

改完重载：

systemctl daemon-reload
systemctl restart ollama

常用命令

ollama pull llama3.1
ollama pull qwen2
ollama run llama3.1
ollama list
ollama ps
nvidia-smi

API 测试也很直接：

curl http://10.80.2.195:7861/api/chat -d '{
  "model": "llama3.1",
  "messages": [{"role": "user", "content": "why is the sky blue?"}]
}'

一些常见配置

OLLAMA_HOST=0.0.0.0:7861 用来开放监听；OLLAMA_NUM_PARALLEL 控制并发；多卡环境下可以用 CUDA_VISIBLE_DEVICES=0,1 限定 GPU；OLLAMA_KEEP_ALIVE=-1 则表示模型尽量常驻内存。

这些参数没有什么玄学，主要是看你是想省显存，还是想省等待时间。两者通常不能同时拉满。

卸载

如果只是临时试一试，清理也简单：

sudo systemctl stop ollama
sudo rm /etc/systemd/system/ollama.service
sudo rm $(which ollama)
sudo rm -r /usr/share/ollama
sudo userdel ollama

OpenLLM：更偏服务化的管理方式

OpenLLM 走的是另一条路。它不是把'本地跑起来'这件事简化到极致，而是更在意模型服务、调用方式和生产环境里的管理感。

安装和初始化很短：

pip install openllm
openllm hello

它支持的模型范围比较广，常见的像 Llama-3.1、Llama-3、Llama-2、Mistral、Mixtral、Gemma-2、Gemma、Qwen-2、Phi-3 都在列表里。

客户端调用方式也比较直接：

import openllm
client = openllm.client.HTTPClient('http://localhost:3000')
response = client.query('Explain to me the difference between "further" and "farther"')
print(response)

或者走命令行：

export OPENLLM_ENDPOINT=http://localhost:3000
openllm query 'Explain to me the difference between "further" and "farther"'

如果你本来就在 Python 生态里，这套会顺手很多；如果只是想尽快把模型服务跑起来，Ollama 往往更省事。

LocalAI：兼容 OpenAI 接口这点很实用

LocalAI 的优势不在'最轻'，而在'接得上现有生态'。它提供 RESTful API，并且兼容 OpenAI 的接口风格，所以很多原本写给 OpenAI 的客户端、编排层，改一改 base URL 就能接上。

环境准备

先拉仓库，再进入示例目录：

git clone https://github.com/go-skynet/LocalAI
cd LocalAI/examples/langchain-chroma

下载示例模型：

wget https://huggingface.co/skeskinen/ggml/resolve/main/all-MiniLM-L6-v2/ggml-model-q4_0.bin -O models/bert
wget https://gpt4all.io/models/ggml-gpt4all-j.bin -O models/ggml-gpt4all-j

然后把环境文件准备好：

mv .env.example .env

这里 THREADS 别随便拉太高，超过 CPU 核心数通常只会更吵，不一定更快。

启动

docker-compose up -d --build
docker logs -f langchain-chroma-api-1

默认监听在 http://127.0.0.1:8080。

模型映射

LocalAI 可以把本地模型映射成 OpenAI 风格的名字，这对迁移老项目很有帮助：

• ggml-gpt4all-j -> gpt-3.5-turbo
• all-MiniLM-L6-v2 -> text-embedding-ada-002

这一步看起来像'伪装'，但对上层应用来说，它确实少改很多代码。

Dify：把模型服务串成应用

如果 Ollama、OpenLLM、LocalAI 解决的是'模型怎么跑'，Dify 解决的就是'怎么把这些模型用起来'。它更像应用编排层，而不是推理引擎。

配置模型供应商

在 Dify 后台里添加对应供应商时，常见信息就是这些：

• 模型名称，比如 llama3.1 或 gpt-3.5-turbo
• 基础 URL，比如 http://<IP>:11434
• 模型类型，对话或文本嵌入
• 上下文长度，按模型规格填，默认常见是 4096
• Vision 能力，如果模型支持多模态再勾选

Docker 网络

Dify 和模型服务如果都跑在容器里，最容易踩的坑就是 localhost。容器里的 localhost 只指它自己，不是宿主机。

碰到 Connection refused，先看端口有没有暴露、防火墙有没有拦，再看网络地址是不是写错。host.docker.internal 或自定义 Docker Network 都是常用解法，选哪个取决于你现在的部署方式，而不是看谁'更优雅'。

多模型管理

Dify 允许挂多个模型实例，这点对做不同能力的分流很方便。新模型加完后刷新页面，让配置重新加载。资源面板也能帮你看出哪些调用更耗钱、哪些请求更吃显存。

怎么选

这几套东西其实不是互斥关系，更像是不同层级的工具。

如果只是本地试模型，Ollama 最省心。要做服务化管理，可以看 OpenLLM。要兼容现有 OpenAI 接口或存量应用，LocalAI 更顺手。Dify 则适合把这些能力再往上包一层，做成真正的应用。

生产环境里更实际的几件事

安全加固别省，至少要限制 API 访问来源；资源隔离要做，不然一个模型抢光显存，别的服务就会跟着抖；监控告警最好早点接上，显存、CPU、延迟这几个指标够你先发现大部分问题；模型权重和配置也要备份，真出事时这比重装快得多。

排障时先看这些

• 连接超时：检查防火墙和端口是否开放，比如 11434、8080
• 显存不足：换量化模型，比如 Q4_K_M，或者把并发降下来
• 模型不识别：确认模型文件名和配置里的名字一致
• Docker 网络不通：用 docker network inspect 看容器间 DNS 和连通性

结尾

本地部署大模型真正难的地方，不是把服务拉起来，而是选对组合、把网络和资源关系理顺。Ollama 偏快，OpenLLM 偏服务化，LocalAI 偏兼容，Dify 偏编排。很多场景里，最省时间的做法不是只押一个方案，而是按层拼起来用。