# 7 - 企业级大模型部署
本章面向**企业级私有化部署**：在自有机房或云服务器上部署 **Dify**（应用层）和 **Xinference**（模型托管与推理层），实现数据不出域、成本可控、模型版本可管的完整链路。内容偏实战，涉及租云服务器、装 Docker、部署 Dify、租 GPU 服务器、部署 LLM/Embedding/Rerank 及 Dify 对接自建模型。
**本章课程目标：**
- 理解企业级部署为什么通常要把 **应用层** 和 **模型推理层** 分开。
- 分清 **推理引擎** 和 **模型托管平台** 的职责边界，不再把 vLLM、Ollama、Xinference 混成一个概念。
- 完成 Dify 在服务器侧的私有化部署。
- 完成 Xinference 在 GPU 服务器上的部署，并分别托管 LLM、Embedding、Rerank 模型。
- 理解 Dify 对接 Xinference 后，为什么这条链路更适合企业做统一模型治理。
**学习建议：** 企业部署最容易被环境细节淹没，先把层次分清：Dify 属于应用层，Xinference 属于推理层，GPU 服务器只是承载它们的基础设施。第 1 节先看选型逻辑，第 2 节只负责把 Dify 跑起来，第 3 节再接模型服务。遇到 Docker、网络、数据库或升级问题，直接回看 [第 8 章](8-Docker快速入门与Dify部署排障.md)，不要在这一章里硬猜。
**官方文档与资源**：详见 [工具导航与参考资料索引 - 部署与基础设施](工具导航与参考资料索引.md#部署与基础设施)。
---
## 1、企业级大模型部署概述
### 1.1 为什么企业部署和个人部署不是一回事
个人学习时，我们更关注：能不能跑起来，有没有界面，能不能先验证一个应用。
但企业部署关注的事情会更多：数据安全与合规，高频调用下的成本，模型与平台的可替换性，统一鉴权、监控、审计，版本升级与运维治理。
所以企业部署的目标，从来都不只是“把 Dify 装上去”，而是把它变成一套可持续维护的基础设施。
| | 第三方 API | 企业级部署 |
| ------------ | ------------------------------ | ------------------------------------------- |
| **安全合规** | 敏感数据泄漏 | 数据掌握在企业手中 |
| **成本预算** | 高频调用成本不可控 | 成本可预测（服务器购买/租赁和运维
成本） |
| **能力可控** | 黑箱与版本漂移 | 推理性能、模型版本可定制 |
| **可靠性** | 延迟、吞吐不可控 | 内网低延迟、弹性扩缩容自由调整
吞吐量 |
| **运维治理** | 模型服务不透明，不利于定位故障 | 模型服务可观测，支持故障定位和治理 |
> 注：这里的“版本漂移”是指第三方服务升级后，接口行为、模型效果或系统输出发生不可控变化。
### 1.2 技术架构
最容易出错的地方，是把 Dify、模型服务、推理引擎都混成“模型平台”。更好的理解方式是分层看：
- `应用层`
- 典型代表：Dify
- 负责 Agent、Workflow、RAG、知识库、提示词、前端交互和平台管理
- `模型托管层`
- 典型代表：Xinference
- 负责统一托管 LLM、Embedding、Rerank，并对外暴露服务
- `推理引擎层`
- 典型代表：vLLM、SGLang、TEI、Ollama、llama.cpp
- 负责真正加载模型并在 CPU / GPU 上执行推理
- `接入方式`
- 上层通常通过 OpenAI-compatible API 或平台插件完成对接
调用路径（从上到下）：
**这种分层架构的优势在于**：
- `技术解耦`
- 模型可独立升级、替换
- 应用开发不依赖具体模型实现
- `有利于运维治理`
- 统一入口（标准 OpenAI-compatible API 调用）可以做统一鉴权、限流、审计等
- 推理层可以被独立运维，单独监测 QPS（Queries Per Second）、TTFT（Time To First Token）、TPS（Tokens Per Second）、GPU 利用率等指标
### 1.3 框架选型
#### 1.3.1 推理引擎
**① 本地开发 / 个人验证（最快跑起来）**
这一类工具更适合“快速验证”，但通常**不擅长企业里的多租户 / 高并发 / 多卡集群部署**。
- **Ollama**：由 Ollama Inc.公司开发，是部署大模型`最简单`的方式，但`推理效率低`，`不适合高并发场景`。
- **llama.cpp**：由 Georgi Gerganov 个人开发的开源项目，纯 C/C++实现的 LLaMA 模型推理库。尤其适合 CPU/边缘设备/低成本部署。
> 结论：它们更适合个人学习或小规模验证，不是本章企业架构的主线。
**② 企业高并发推理引擎**
这类引擎门槛更高，但可以更充分地发挥 GPU 性能。
- **vLLM**：来自加州大学伯克利分校的 Sky Computing 实验室，采用了 PagedAttention、Prefill 与 Decode 分离等多种优化策略，`追求极致推理性能`，支持英伟达 GPU、AMD GPU 和华为昇腾等`多种硬件平台`，支持`多卡并行`推理。主要`支持LLM部署`。
- **SGLang**：也是在 Sky Computing 实验室诞生，同样采用了类似的优化策略，不同的是，SGLang 面向`应用编排/结构化生成`，对同一个应用多次调用请求的场景做了优化，底层通过合并、复用、调度优化等策略`减少模型实际进行的推理次数`，进一步提升推理性能。
- **HuggingFace TEI（Text Embedding Inference）**：Huggingface 官方推出的工具包，专为高效`部署嵌入模型`设计。
> 结论：企业部署更关心的是吞吐、延迟和资源利用率，因此 vLLM、SGLang、TEI 这类工具更有现实意义。
#### 1.3.2 模型托管平台
这类平台解决的不是“模型怎么跑得更快”，而是“怎么把多类模型像服务一样统一管理起来”。
- **Xinference（Xorbits Inference）**：杭州未来速度科技有限公司的大模型管理和推理服务平台，致力于打造一体化解决方案。支持`LLM`、`Embedding`、`Rerank`等多种模型托管。
> **辨析：Xinference 是推理引擎吗？**
> **不是**。Xinference 与 Ollama、vLLM、SGLang 不属于同一层级：
>
> - **推理引擎**（vLLM、SGLang、Ollama、llama.cpp、TEI 等）：直接负责在 GPU/CPU 上执行模型计算，是“真正跑模型”的底层软件。
> - **模型托管平台**（Xinference）：负责模型的下载、管理、生命周期和对外 API，**底层可选用**某一种或多种推理引擎。例如部署 LLM 时，Xinference 通常选用 **vLLM** 作为引擎；部署 Embedding 时则使用自带的嵌入推理实现。
> 最直观的类比是：推理引擎 = 干活的“发动机”，模型托管平台 = 管多台发动机并统一对外提供服务的“调度中心”。
> **推理引擎和 LLM、嵌入模型、重排序模型是什么关系？**
>
> - **模型**（LLM、Embedding、Reranker 等）是“权重 + 网络结构”，本身不能自己跑，必须被某个程序加载并在 GPU/CPU 上执行，这个程序就是**推理引擎**。
> - **推理引擎**负责：加载模型文件 → 在硬件上做前向计算 → 把结果返回。不同引擎针对不同模型类型做了优化（例如 LLM 要逐 token 生成、需要 KV 缓存，嵌入/重排序通常只需一次前向）。
> - **对应关系**：同一类模型可以由不同引擎来跑（如 LLM 可用 vLLM 或 SGLang）；一个引擎往往只擅长某一类模型（vLLM 主打 LLM，TEI 主打 Embedding）。因此部署时既要选“用什么模型”，也要选“用哪个引擎来跑这个模型”。
#### 1.3.3 选型
**大语言模型（Large Language Model, LLM）：**可以用 vLLM、SGLang、或者 Xinference+vLLM 引擎部署。
**嵌入模型（Embedding Model）：**可以用 Huggingface TEI 和 Xinference 部署。
**重排序模型（Reranker / Re-ranking Model）：**目前调研的产品，除了 Ollama 和 llama.cpp，只有 Xinference 支持这类模型的部署。
**最终选型：**
本章选定 Xinference 平台作为模型托管与推理服务框架，统一部署大语言模型、嵌入模型和重排序模型。原因如下：
① 接口统一：可以向外提供统一的 API 接口，像大模型厂商那样一个链接管理多个模型。
② 针对 LLM：结合 vLLM 引擎部署 LLM，可以获得`极高的推理性能`。
③ 针对嵌入模型和重排序模型：嵌入模型和重排序模型只需要一次前向，和逐 token 生成的大语言模型相比，`资源开销要小得多`，因此对性能要求不高。Xinference 也支持这两种模型部署，这样我们可以用一个平台管理所有模型，`运维成本低`。
#### 1.3.4 整体调用关系
整体图示如下：
**问题：为什么这个项目里 Dify 装在 Docker 中，而 Xinference 直接装在 GPU 服务器上？**
首先说，Xinference 是可以部署到 Docker 中的。但是 Xinference 中模型推理需要消耗大量 GPU，而 Docker 容器默认无法直接使用宿主机 GPU，需额外配置（如 NVIDIA Container Toolkit）才能使用 GPU。所以：
方案 1：Xinference 不安装在 Docker 中
方案 2：Xinference 安装在 Docker 中，但是需要额外安装其他的软件，支持 GPU 的调用。
这里采用方案 1：只将 Dify 安装到 Docker 中，Xinference 直接运行在 GPU 服务器上。
> **可这样记：** 整条链路可以记成「**Dify（应用）-> Xinference（托管）-> 推理引擎（执行）-> 模型（能力来源）**」。Dify 不负责算模型，它只负责上层应用编排；真正算模型的是 GPU 服务器上的模型服务。
---
## 2、Dify 平台私有化部署
### 2.1 Dify 平台的角色（复习）
在这一章里，Dify 不是“模型本身”，而是上层应用平台。
它主要负责：
- 基于 Agent 架构构建智能体应用
- 基于 RAG 构建私有知识库应用
- 基于 Workflow 构建智能工作流应用
也就是说，Dify 更像企业内部的“AI 应用操作系统”，而不是“算模型的地方”。
> 说明：访问 Dify 官网需要魔法（或梯子、科学上网）
### 2.2 租赁 Dify 服务器：腾讯云
企业用户可以选择租用云服务器，或者在本地的服务器中部署 Dify。因为 Dify 所需的资源很小，一个轻量级的服务器足以支持运行。
我们需要租赁一个云服务器去运行 Dify 服务：腾讯云。
官网：https://cloud.tencent.com/
#### 2.2.1 基础配置
https://buy.cloud.tencent.com/cvm
如果是企业中使用或者个人资金充裕且业务稳定的话，可以选择长租使用。期望优惠的话，可以选择竞价实例。竞价实例，在性能和稳定性上，与按量计费模式没有差别。
> 竞价实例，只要有人租长期的服务器就有可能把你的服务器踢掉，实例被竞价释放也是有解决办法的，后续会去讲。
地域选择：没有要求，自己根据需要选即可。
实例配置：根据自己需求选择，无具体要求。这里我选择 4 核 8GB。
镜像：选择 CentOS、Ubuntu 都可以，这里使用了 Ubuntu。选择后点击下一步。
#### 2.2.2 设置网络和主机
拉满带宽上限，新建安全组，把常用的端口都开启：
命名实例，设置密码，进行下一步：
开通：
#### 2.2.3 登录(使用 Xshell 或 finalshell 或 windTerm)
创建好了，通过这个公网 IP，端口使用 22，账号 ubuntu，密码使用你设置的密码。使用你的远程连接工具 XShell 或 FinalShell 连接即可。
XShell 界面如下：
### 2.3 部署 Docker
部署 Dify 平台，需要基于 Docker 环境，而腾讯云新购的云服务器默认未预装 Docker。接着，需要在腾讯云租用的服务器中部署 Docker。
**什么是 Docker？**
Docker 是一种容器化技术，相较于传统的通过虚拟机技术实现的虚拟化方案来说，Docker 是⼀种更加轻量级的虚拟化解决方案。
**它可以将应用程序及其依赖项打包成一个独立的容器，并在不同的环境中运行。**通过 Docker 容器， 开发者可以轻松地构建、部署和运行应用程序，而无需担心环境配置和依赖问题。
**使用 Docker 的好处：**
- `一次构建，到处运行`：你在自己电脑上开发测试好的程序，打成 Docker 镜像后，可以保证在生产服务器上跑起来的效果一模一样。再也不会出现“在我电脑上是好的啊！”这种问题。
- `环境隔离`：你可以同时运行一个项目的 Python 2 版本和 Python 3 版本，它们互不影响。
- `快速部署与扩展`：因为容器非常轻量，你可以瞬间启动成百上千个一样的容器来应对高流量（比如双十一抢购）。
- `简化配置`：环境配置都写在了“材料包”（镜像）里，新人接手项目时，不需要花几天时间配环境，直接一条命令就能让程序跑起来。
**场景：**
假设你开发了一个网站。
- **传统方式：** 你需要给运维人员一份长长的《环境配置手册》：“请先安装 CentOS 7，然后安装 Python 3.8.2，再安装 Nginx 1.18.0，配置如下……”。步骤繁琐，极易出错。
- **Docker 方式：** 你直接把整个网站和环境打包成一个 Docker 镜像。运维人员只需要执行一句简单的命令：`docker run [你的镜像名]`，一个完整、可运行的网站环境就在一秒内启动了。
按照下面的指令一步一步进行操作
```bash
# 更新软件包
sudo apt update
sudo apt upgrade
# 安装 Docker 官方仓库依赖
sudo apt install ca-certificates curl
# 添加 Docker 官方 GPG key
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
# 添加 Docker 官方 apt 软件源
sudo tee /etc/apt/sources.list.d/docker.sources < 看到 running 状态说明 docker 已经正常启动
**注意：安装过程中如果报错如下：**
可以按如下操作步骤执行：
| 步骤 | 关键检查点/操作 | 预期结果/说明 |
| :----------------------------- | :------------------------------------------------------------------------------------------------------------------------ | :----------------------------------------------------------------------------- |
| 1. 验证 Docker 安装状态 | 运行 sudo systemctl status docker | 确认 Docker 服务当前的状态和错误日志。 |
| 2. 检查并取消服务屏蔽 | 执行 sudo systemctl unmask docker.service | 解决服务被意外“屏蔽”导致无法启动的问题。 |
| 3. 检查依赖服务状态 | 运行 systemctl list-dependencies docker.service.
如果 containerd 服务异常，尝试启动它：sudo systemctl start containerd | 查看 Docker 依赖的服务（如 containerd）是否正常。
如果启动失败，进入第 4 步 |
| 4. 修复 containerd（关键步骤） | 执行：① sudo apt-get update
② sudo apt-get install --reinstall containerd.io | 重新安装 Docker 的核心运行时依赖。 |
如果以上步骤均无效，可以考虑彻底清理 Docker 及其相关组件后重新安装。这是解决文件损坏或版本冲突的可靠方法。
彻底卸载 Docker：
```bash
sudo apt-get purge docker-ce docker-ce-cli containerd.io
sudo rm -rf /var/lib/docker
sudo rm -rf /var/lib/containerd
```
### 2.4 部署 Dify
安装 Dify 之前, 请确保你的机器已满足最低安装要求：
- CPU >= 2 Core
- RAM >= 4 GiB
#### 2.4.1 下载
> 注意：本章使用 **0.15.5** 作为课程测试 / 历史示例版本，用于复现截图和课程流程。新部署时应优先参考 Dify 官方最新自托管文档；如果使用更新版本，需以当前 release notes 和本地兼容性验证为准。
在`/opt`下创建一个 dify 目录，用于存储 dify 源码：
```cmd
cd /opt
sudo mkdir dify #用于存储dify源码包
```
##### 方式 1：离线下载包(推荐)
**离线下载源码包**（科学上网）
下载地址：https://github.com/langgenius/dify/releases/tag/0.15.5
> 注意：网络不好的同学，可在网盘资料中查看使用。
利用远程连接工具（比如：XFTP）将 dify 源码包传递到服务器 /opt/dify 文件夹中，并解压即可：
上传可能失败（因为默认 ubuntu 用户权限不足），解决办法如下
```bash
# 方式1：赋予指定用户指定目录的完全权限（使用777）
# 在Ubuntu终端xshell执行：sudo chmod -R 777 /目标目录的完整路径
sudo chmod -R 777 /opt/dify
# 方式2：先将文件上传到您的用户主目录（如 /home/ubuntu），这个目录通常有写入权限
# 然后使用XShell或终端，通过命令移动文件：sudo mv /home/ubuntu/文件名 /目标/path/
```
进行解压：
```cmd
#进入dify目录,在opt目录下执行：
cd ./dify
#解压
sudo tar -zxvf dify-0.15.5.tar.gz
cd /opt/dify/dify-0.15.5
pwd # 输出 /opt/dify/dify-0.15.5
```
##### 方式 2：Gitee 下载
如果使用 GitHub 下载过慢，还可以使用码云（Gitee）或镜像网站替代 GitHub 直接下载，利用国内服务器加速。
操作步骤：
1）注册码云账号（[https://gitee.com ](https://gitee.com/)）。
2）在码云新建仓库，选择「导入 GitHub 仓库」，粘贴 `https://github.com/langgenius/dify.git ` 的链接 。
3）导入完成后，使用码云生成的仓库地址克隆：
```bash
sudo git clone https://gitee.com/你的用户名/dify.git
```
这里大家也可以直接使用我的链接：
```bash
sudo git clone https://gitee.com/shkstart/dify.git
```
#### 2.4.2 使用 docker 启动 Dify
1. 进入 Dify 源代码的 Docker 目录：
```cmd
cd /opt/dify/dify-0.15.5/docker
```
2. 复制环境配置文件
```bash
sudo cp .env.example .env
```
3. 启动 Docker 容器
根据你系统上的 Docker Compose 版本，选择合适的命令来启动容器。你可以通过 ` docker compose version` 命令检查版本，详细说明请参考 [Docker 官方文档](https://docs.docker.com/compose/#compose-v2-and-the-new-docker-compose-command)：
- 如果版本是 Docker Compose V2，使用以下命令（课程对应版本）：
```bash
sudo docker compose up -d
```
- 如果版本是 Docker Compose V1，使用以下命令：
```bash
sudo docker-compose up -d
```
说明：Docker 会自动帮你：拉取需要的镜像 → 创建容器 → 按顺序启动所有服务 → 后台运行。
4. 运行命令后，你应该会看到类似以下的输出，显示所有容器的状态和端口映射：
注意：第一次拉取镜像，时间可能会很长，实测约将近十分钟。
```cmd
[+] Running 11/11
✔ Network docker_ssrf_proxy_network Created
✔ Network docker_default Created
✔ Container docker-redis-1 Started
✔ Container docker-ssrf_proxy-1 Started
✔ Container docker-sandbox-1 Started
✔ Container docker-web-1 Started
✔ Container docker-weaviate-1 Started
✔ Container docker-db-1 Started
✔ Container docker-api-1 Started
✔ Container docker-worker-1 Started
✔ Container docker-nginx-1 Started
```
5. 最后检查是否所有容器都正常运行：
```cmd
sudo docker compose ps
```
在这个输出中，你应该可以看到包括 3 个业务服务 `api / worker / web`，以及 6 个基础组件 `weaviate / db / redis / nginx / ssrf_proxy / sandbox` 。
6. 停止 Dify 运行
```cmd
#一键关停所有相关容器，干净不残留
docker compose down
```
7. 同步环境变量配置（重要！）
- 如果 `.env.example` 文件有更新，请务必同步修改你本地的 `.env` 文件。
- 检查 `.env` 文件中的所有配置项，确保它们与你的实际运行环境相匹配。你可能需要将 `.env.example` 中的新变量添加到 `.env` 文件中，并更新已更改的任何值。
#### 2.4.3 常见问题解决
**问题 1：安装 Dify 常见问题和解决方案**
```cmd
sudo docker compose up -d
```
执行失败，大概率会由于网络问题或镜像缺失问题发生报错。
进行镜像源或代理配置。
> **说明：** 镜像源和代理属于 Docker 通用网络问题，第三方镜像源的可用性、安全性和同步完整性都可能变化。生产环境优先使用 Docker 官方源、企业内网镜像仓库，或云厂商明确提供并可信的镜像加速服务。通用处理思路见 [第 8 章 - 网络慢或镜像拉取失败](8-Docker快速入门与Dify部署排障.md#_44-网络慢或镜像拉取失败)。
```bash
sudo vi /etc/docker/daemon.json
```
按你当前可用的镜像源填写 `registry-mirrors`，示例格式如下：
```bash
{
"registry-mirrors": [
"https://your-trusted-mirror.example.com"
]
}
```
**在 vi 中保存并退出**：按 `Esc` 确保进入命令模式，输入 `:wq` 回车（保存并退出）；若放弃修改则输入 `:q!` 回车。
保存后，在终端重新启动 Docker：
```bash
# 重新加载配置并重启 Docker（修改了 /etc 下配置，通常需要 sudo）
sudo systemctl daemon-reload
sudo systemctl restart docker
```
重新执行：
```bash
sudo docker compose up -d
```
开始正常下载了：
**问题 2：可能出现报错，报错如下**
于是根据报错信息检查
```bash
sudo vi /etc/apparmor.d/tunables/home.d/ubuntu
```
删除掉报错信息中第七行的多余字符即可
重新运行，成功
#### 2.4.4 访问
你可以前往管理员初始化页面设置管理员账户：
```bash
# 服务器环境
http://your_server_ip/install #your_server_ip即为配置的腾讯云服务器地址
```
如图所示为成功访问，进行注册登录即可
**注意：如果一直无法加载进去，则需要重启 Docker 再次尝试**
#### 2.4.5 设置快照
为避免案例中的竞价实例被释放，可以在控制台中的快照中设置快照策略，即使被释放了也能保存快照，从而快速恢复
再次进入定期快照策略，可发现已设置成功。
### 2.5 配置在线大模型
如果想调用线上的 LLM，则可以用 Dify 选择线上的模型运营商。比如说可以在模型运营商中选择 DeepSeek。
DeepSeek 官网地址：https://www.deepseek.com/ ，在官网获取自己的 API Key 即可配置后使用
在这里可以使用平台提供的在线大模型服务（运营商），但是考虑到可能存在的数据安全问题，所以我们自己部署 Xinference，进而部署私有的大模型。
---
## 3、模型部署
### 3.1 租赁 GPU 服务器：AutoDL
**AutoDL 介绍**
这里我们选用 AutoDL 平台租赁服务器。这是一款面向开发者和企业的云计算平台，主要提供高性价比的`GPU算力资源`，支持 AIGC、深度学习、云游戏、渲染测绘、元宇宙、HPC 等应用。
**平台地址：**https://www.autodl.com/
> AutoDL 服务器的资源比较紧俏，且比较贵
>
> - 一台机器开机一个小时平均花费 2 元
> - `建议`：一般早上开始工作的时候开机，在结束一天工作的时候关机。
#### 3.1.1 配置服务器+镜像
选择服务器：
这里可以选择西北 B 区的单卡 4090 作为我们的服务器，我们需要租赁一台服务器部署 Xinference。
注意：AutoDL 官方文档中默认会将实例的 **6006** 和 **6008** 端口映射为自定义服务入口。
> 注意：
>
> 1、这里推荐“西北地区”，因为会提供公网 IP，其他地区不确定。
>
> 2、GPU 推荐 RTX4090，3090，3080 等，其他显卡可能会出现后续不兼容情况。
选择镜像版本：
界面中的「框架」是 AutoDL 预装好的基础环境，不同框架用途不同，可做大致区分：
| 框架 | 简要说明 |
| ---------------- | ----------------------------------------------------------------------------------------------------------------- |
| **PyTorch** | 主流深度学习框架，用于训练和推理。vLLM、Xinference 等推理栈多基于 PyTorch，**本教程部署 Xinference 建议选此项**。 |
| **TensorFlow** | 另一大深度学习框架，生态多用于训练与部署，与 PyTorch 二选一即可。 |
| **Miniconda** | 轻量版 conda，只提供 Python 与包管理，无预装深度学习框架，适合自己从零配环境。 |
| **tritonserver** | NVIDIA Triton 推理服务，用于高性能模型部署，多与 TensorRT 等配合使用。 |
| **JAX** | 面向数值计算与研究的框架，强调高性能与函数式写法，偏研究/实验场景。 |
| **PaddlePaddle** | 百度开源深度学习平台，国内生态常用。 |
| **TensorRT** | NVIDIA 的推理优化库，侧重在 NVIDIA GPU 上加速推理，常与推理服务一起用。 |
| **Gromacs** | 分子动力学模拟软件，与深度学习无直接关系，属科学计算/生物物理方向。 |
**本教程建议**：选择 **PyTorch** 对应镜像，Python 选 **3.10**，CUDA 选 **11.8**（或与当前显卡驱动兼容的版本）。这样便于在实例中直接使用 conda 安装并运行 Xinference。
#### 3.1.2 XShell 连接登录
复制该服务器的登录指令，通过远程连接工具进行登录
测试连接：
> 默认的用户名：root
连接成功
#### 3.1.3 开启学术资源加速
为下载一些外网的资源（比如 GitHub、HuggingFace 等），需要在**当前终端中**开启`学术资源加速`
> 免不了我们要在这个系统上安装一些软件。这些软件可能来自于如下的红框的位置。默认是下载不了的。那么就需要魔法或科学上网。这里我们称为：学术加速。
https://www.autodl.com/docs/network_turbo/
将图中框选的一行复制到终端输入即可
```bash
source /etc/network_turbo
```
> **加速说明：** `source /etc/network_turbo` 主要用于当前终端访问 GitHub、HuggingFace 等学术资源时的临时加速，官方也不承诺稳定性。用完或发现影响其他网络请求时，可执行 `unset http_proxy && unset https_proxy` 取消当前终端代理。
### 3.2 部署 XInference
#### 3.2.1 准备 conda 环境
##### ① 创建 conda 环境
AutoDL 的系统盘大小为 30GB，数据盘大小为 50GB，conda 的默认工作路径在系统盘下，Xinference 全家桶需要的空间比较大，可能导致系统盘被占满，因此将 conda 环境创建在数据盘下。
```shell
conda create -p /root/autodl-tmp/conda_envs/xinfer_env python=3.10
```
##### ② 初始化 conda 环境
```shell
conda init bash
source ~/.bashrc
```
##### ③ 激活 conda 环境
```shell
conda deactivate
conda activate /root/autodl-tmp/conda_envs/xinfer_env
```
##### ④ 验证 conda 是否创建成功
若 `python` 和 `pip` 的路径均指向该 conda 环境目录，则创建成功。
```shell
which python
which pip
```
#### 3.2.2 部署 XInference
AutoDL 学术加速默认使用阿里云作为 PyPI 源，该镜像环境中可能缺少 XInference 所需的 num2words 等依赖而导致报错，因此将清华源作为备用源。
```shell
pip install "xinference[vllm,embedding,rerank,transformers]==1.16.0" \
--extra-index-url https://pypi.tuna.tsinghua.edu.cn/simple
```
可以把安装服务放在后台
```shell
nohup pip install "xinference[vllm,embedding,rerank,transformers]==1.16.0" --extra-index-url https://pypi.tuna.tsinghua.edu.cn/simple >xinfer_install.log 2>&1 &
```
日志记录在 xinfer_install.log，执行以下命令可以监听日志
```shell
tail -F xinfer_install.log
```
#### 3.2.3 启动 XInference 服务端
```shell
XINFERENCE_MODEL_SRC=modelscope xinference-local --host 0.0.0.0 --port 6006
```
XINFERENCE_MODEL_SRC=modelscope 的作用是将默认的模型仓库从**Huggingface**更换为**魔搭**。
--host：指定监听网卡，0.0.0.0 表示监听所有网卡的请求
--port：指定服务端口，默认 9997
#### 3.2.4 访问 XInference WebUI
##### ① 查看 AutoDL 自定义服务地址
AutoDL 的云 GPU 服务器默认会将 6006 和 6008 映射为服务，Xinference 服务端监听了 6006 端口，访问对应链接即可访问 Xinference 的 WebUI。
##### ② 访问 Xinference 的 WebUI
### 3.3 部署 LLM（大语言模型）
#### 3.3.1 部署
##### ① 云端模型
我们可以让 Xinference 平台帮我们从模型仓库下载并启动模型，前提是该模型被官方收录并支持。
以 Qwen3-0.6B 为例，参考官方文档
> https://inference.readthedocs.io/zh-cn/latest/models/builtin/llm/qwen3.html
Xinference 把模型分成了很多模型族，每个模型族都包含一系列不同规模的模型，通过不同的属性配置区分。Qwen3-0.6B 的模型族为 qwen3，配置如上图所示。
新起一个连接窗口：激活 conda 环境
```
conda activate /root/autodl-tmp/conda_envs/xinfer_env
```
开启学术加速：
```
source /etc/network_turbo
```
启动命令如下：
```shell
xinference launch \
--model-engine vllm \
--model-name qwen3 \
--size-in-billions 0_6 \
--model-format pytorch \
--quantization none \
--model-uid Qwen3-0.6B \
--gpu_memory_utilization 0.6 \
--max_model_len 1024 \
--endpoint http://localhost:6006
```
`--model-engine vllm`：底层推理引擎
`--model-name qwen3`：模型族
`--size-in-billions 0_6`：模型规模，以 10 亿为单位
`--model-format pytorch`：权重文件格式
`--quantization none`：是否量化
`--model-uid Qwen3-0.6B`：模型 uid，用于在 Xinference 中唯一区分模型，可以省略，由系统生成
`--gpu_memory_utilization 0.6`：vLLM 参数，模型占用 GPU 显存的百分比（示例中为 0.6，可按需调整）
`--max_model_len 1024`：vLLM 参数，模型支持的上下文长度
`--endpoint`：Xinference 服务端入口
此时服务端可以看到模型正在下载。
模型部署完成
##### ② 本地模型文件
如果模型权重已被预下载到本地，可以执行以下命令。
```shell
xinference launch \
--model-engine vllm \
--model-name qwen3 \
--size-in-billions 0_6 \
--model-format pytorch \
--quantization none \
--model-path "${your_model_path}" \
--model-uid Qwen3-0.6B \
--gpu_memory_utilization 0.6 \
--max_model_len 1024 \
--endpoint http://localhost:6006
```
`--model-path`：模型权重本地存储路径。
#### 3.3.2 测试
##### ① 查看模型部署情况
```shell
xinference list \
--endpoint http://localhost:6006
```
##### ② WebUI
##### ③ 发送请求
```shell
curl http://localhost:6006/v1/chat/completions -H "Content-Type: application/json" -d '{
"model": "Qwen3-0.6B",
"messages": [
{"role": "system", "content": "你是个乐于助人的助理。"},
{"role": "user", "content": "你好啊"}
]
}'
```
响应如下：
### 3.4 部署 Embedding 模型（嵌入模型）
#### 3.4.1 部署
##### ① 云端模型
```shell
xinference launch \
--model-name bge-small-zh-v1.5 \
--model-type embedding \
--endpoint http://localhost:6006
```
`--model-name`：模型名称
`--model-type`：模型类型
正在下载
部署完成
##### ② 本地文件
```shell
xinference launch \
--model-name bge-small-zh-v1.5 \
--model-type embedding \
--model-path "${your_model_path}" \
--endpoint http://localhost:6006
```
`--model-path`：本地模型路径（模型权重所在目录）
#### 3.4.2 测试
##### ① 查看模型部署情况
```shell
xinference list \
--endpoint http://localhost:6006
```
##### ② WebUI
##### ③ 发送请求
```shell
curl http://localhost:6006/v1/embeddings \
-H "Content-Type: application/json" \
-d '{
"model": "bge-small-zh-v1.5",
"input": "这是一个用于测试的中文句子"
}'
```
响应如下：
### 3.5 部署 Rerank 模型（重排序模型）
#### 3.5.1 部署
```shell
xinference launch \
--model-name bge-reranker-base \
--model-type rerank \
--endpoint http://localhost:6006
```
正在下载
部署完成
#### 3.5.2 测试
##### ① 查看模型部署情况
```shell
xinference list \
--endpoint http://localhost:6006
```
##### ② WebUI
##### ③ 发送请求
```shell
curl http://localhost:6006/v1/rerank \
-H 'Content-Type: application/json' \
-d '
{
"model": "bge-reranker-base",
"query": "Apple",
"documents": [
"鸡蛋",
"苹果",
"good",
"香蕉"
],
"instruction": "基于查询结果重排序",
"top_n": 4
}
'
```
响应如下：
### 3.6 Dify 对接 Xinference
#### 3.6.1 安装 Xinference 插件
搜索 Xinference
安装插件
安装完成后即可看到 Xinference
#### 3.6.2 添加 LLM
在 Xinference 插件下可以看到模型，则配置成功
#### 3.6.3 添加 Embedding 模型
#### 3.6.4 添加 Rerank 模型
---
**章节思考题：**
1. 企业级部署里，Dify、Xinference、GPU 服务器分别处在哪一层？
**参考思路：** GPU 服务器提供算力基础，Xinference 把模型服务化和统一管理，Dify 在应用层使用这些模型构建知识库、工作流和应用。层次分清后，排障时才不会把应用问题、模型服务问题和硬件问题混在一起。
2. 为什么企业不一定满足于直接调用第三方模型 API？
**参考思路：** 可能出于数据安全、成本、内网交付、模型可控、合规、延迟和运维自主性考虑。直接 API 上手快，但企业级场景往往还要考虑长期运行和治理。
3. 在知识库问答链路里，LLM、Embedding、Rerank 为什么最好统一规划？
**参考思路：** 它们分别负责生成、召回和精排，效果会相互影响。如果分散配置，模型版本、鉴权、监控、切换和故障定位都会变复杂。统一管理不是为了整齐，而是为了稳定和可运维。
4. 如果部署完成后 Dify 里看不到 Xinference 模型，你会从哪几层排查？
**参考思路：** 先看 Xinference 服务是否启动、模型是否加载、网络和端口是否通，再看 Dify 插件配置、Base URL、模型类型、鉴权和容器网络。最后再看日志，不要只在页面上反复保存配置。
**本章小结：**
- **企业级部署讲的不是“怎么装几个服务”，而是部署架构为什么要分层**：应用层负责产品形态和工作流编排，推理层负责模型运行和统一托管，对外再通过兼容 API 暴露能力。只有把这几层拆开，后面的 RAG、Agent、工作流应用才能稳定挂上来。
- **推理引擎和模型托管平台要分清**：vLLM、SGLang、Ollama、TEI 这类更偏“把某类模型高效跑起来”；Xinference 这类更偏“把 LLM、Embedding、Rerank 等多类模型统一管理和服务化暴露”。本章选择 Xinference，是因为它更适合做企业里的统一模型入口。
- **Dify + Xinference 这条链的价值，在于把上层应用和下层模型服务解耦**：Dify 负责工作流、知识库、应用交互；Xinference 负责模型托管；中间通过兼容接口对接。这样后续换模型、扩模型、做权限和观测都更方便。
- **真正的企业收益不是只有私有化**：还包括数据安全、成本可控、能力组合自由度、版本治理、监控排障和后续扩展空间。也正因为如此，企业部署往往要同时考虑 CPU 侧应用服务和 GPU 侧模型服务，而不是把它们混在一台机器上“先能跑再说”。
- **排错时也要按分层思路查**：应用层看 Dify 配置和 Docker，模型层看 Xinference、模型下载和端口，接入层看插件、地址、鉴权和 API 兼容性。分层排查，才不会把“平台问题”和“模型服务问题”混成一锅。
- 从掌握结果看，学完本章后，你至少应该：能理解企业级私有化部署为什么不仅是“能跑起来”，还涉及安全、成本、版本、可观测和运维治理；能区分推理引擎和模型托管平台在架构中的不同职责，并理解本章为什么选 Xinference；能大致复述“Dify 应用层 + Xinference 模型托管层 + 兼容 API 接入”的整体链路，并知道它如何衔接后续 RAG / Agent 主线。
**建议下一步：** 先按第 2 节在腾讯云上把 Dify 跑通并能在浏览器使用；再按第 3 节在 AutoDL 上把 Xinference 及 LLM/Embedding/Rerank 部署并测试通过；最后在 Dify 中安装 Xinference 插件并添加自建模型，用一个小型 RAG 或 Agent 应用验证端到端调用。遇到 Docker 基础问题或 Dify 具体报错可查 [第 8 章 Docker 快速入门与 Dify 部署排障](8-Docker快速入门与Dify部署排障.md)。