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 章，不要在这一章里硬猜。

官方文档与资源：详见 工具导航与参考资料索引 - 部署与基础设施。

---

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 [你的镜像名]，一个完整、可运行的网站环境就在一秒内启动了。

按照下面的指令一步一步进行操作

# 更新软件包
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 <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

# 更新软件源
sudo apt update

# 安装 Docker Engine、Buildx 和 Compose 插件
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

执行sudo apt upgrade的时候会出现这个界面，按回车即可

之后如果在这个界面卡住，按几下回车即可。

安装完毕，启动 docker，并查看状态

sudo systemctl start docker

sudo systemctl status docker

如图所示即为启动成功

看到 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：

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 源码：

cd /opt
sudo mkdir dify #用于存储dify源码包

方式 1：离线下载包(推荐)

离线下载源码包（科学上网）

下载地址：https://github.com/langgenius/dify/releases/tag/0.15.5

注意：网络不好的同学，可在网盘资料中查看使用。

利用远程连接工具（比如：XFTP）将 dify 源码包传递到服务器 /opt/dify 文件夹中，并解压即可：

上传可能失败（因为默认 ubuntu 用户权限不足），解决办法如下

# 方式1：赋予指定用户指定目录的完全权限（使用777）
# 在Ubuntu终端xshell执行：sudo chmod -R 777 /目标目录的完整路径
sudo chmod -R 777 /opt/dify

# 方式2：先将文件上传到您的用户主目录（如 /home/ubuntu），这个目录通常有写入权限
# 然后使用XShell或终端，通过命令移动文件：sudo mv /home/ubuntu/文件名 /目标/path/

进行解压：

#进入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 ）。

2）在码云新建仓库，选择「导入 GitHub 仓库」，粘贴 https://github.com/langgenius/dify.git 的链接 。

3）导入完成后，使用码云生成的仓库地址克隆：

sudo git clone https://gitee.com/你的用户名/dify.git

这里大家也可以直接使用我的链接：

sudo git clone https://gitee.com/shkstart/dify.git

2.4.2 使用 docker 启动 Dify

1. 进入 Dify 源代码的 Docker 目录：

   cd /opt/dify/dify-0.15.5/docker

2. 复制环境配置文件

   sudo cp .env.example .env

3. 启动 Docker 容器

   根据你系统上的 Docker Compose 版本，选择合适的命令来启动容器。你可以通过 docker compose version 命令检查版本，详细说明请参考 Docker 官方文档：

   • 如果版本是 Docker Compose V2，使用以下命令（课程对应版本）：

     sudo docker compose up -d

   • 如果版本是 Docker Compose V1，使用以下命令：

     sudo docker-compose up -d

   说明：Docker 会自动帮你：拉取需要的镜像 → 创建容器 → 按顺序启动所有服务 → 后台运行。

4. 运行命令后，你应该会看到类似以下的输出，显示所有容器的状态和端口映射：

   注意：第一次拉取镜像，时间可能会很长，实测约将近十分钟。

   

[+] 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. 最后检查是否所有容器都正常运行：

   sudo docker compose ps

   在这个输出中，你应该可以看到包括 3 个业务服务 api / worker / web，以及 6 个基础组件 weaviate / db / redis / nginx / ssrf_proxy / sandbox 。

6. 停止 Dify 运行

#一键关停所有相关容器，干净不残留
docker compose down

7. 同步环境变量配置（重要！）

• 如果 .env.example 文件有更新，请务必同步修改你本地的 .env 文件。

• 检查 .env 文件中的所有配置项，确保它们与你的实际运行环境相匹配。你可能需要将 .env.example 中的新变量添加到 .env 文件中，并更新已更改的任何值。

2.4.3 常见问题解决

问题 1：安装 Dify 常见问题和解决方案

sudo docker compose up -d

执行失败，大概率会由于网络问题或镜像缺失问题发生报错。

进行镜像源或代理配置。

说明： 镜像源和代理属于 Docker 通用网络问题，第三方镜像源的可用性、安全性和同步完整性都可能变化。生产环境优先使用 Docker 官方源、企业内网镜像仓库，或云厂商明确提供并可信的镜像加速服务。通用处理思路见 第 8 章 - 网络慢或镜像拉取失败。

sudo vi /etc/docker/daemon.json

按你当前可用的镜像源填写 registry-mirrors，示例格式如下：

{
  "registry-mirrors": [
    "https://your-trusted-mirror.example.com"
  ]
}

在 vi 中保存并退出：按 Esc 确保进入命令模式，输入 :wq 回车（保存并退出）；若放弃修改则输入 :q! 回车。

保存后，在终端重新启动 Docker：

# 重新加载配置并重启 Docker（修改了 /etc 下配置，通常需要 sudo）
sudo systemctl daemon-reload
sudo systemctl restart docker

重新执行：

sudo docker compose up -d

开始正常下载了：

问题 2：可能出现报错，报错如下

于是根据报错信息检查

sudo vi /etc/apparmor.d/tunables/home.d/ubuntu

删除掉报错信息中第七行的多余字符即可

重新运行，成功

2.4.4 访问

你可以前往管理员初始化页面设置管理员账户：

# 服务器环境
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/

将图中框选的一行复制到终端输入即可

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 环境创建在数据盘下。

conda create -p /root/autodl-tmp/conda_envs/xinfer_env python=3.10

② 初始化 conda 环境

conda init bash

source ~/.bashrc

③ 激活 conda 环境

conda deactivate

conda activate /root/autodl-tmp/conda_envs/xinfer_env

④ 验证 conda 是否创建成功

若 python 和 pip 的路径均指向该 conda 环境目录，则创建成功。

which python

which pip

3.2.2 部署 XInference

AutoDL 学术加速默认使用阿里云作为 PyPI 源，该镜像环境中可能缺少 XInference 所需的 num2words 等依赖而导致报错，因此将清华源作为备用源。

pip install "xinference[vllm,embedding,rerank,transformers]==1.16.0" \
--extra-index-url https://pypi.tuna.tsinghua.edu.cn/simple

可以把安装服务放在后台

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，执行以下命令可以监听日志

tail -F xinfer_install.log

3.2.3 启动 XInference 服务端

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

启动命令如下：

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 服务端入口

此时服务端可以看到模型正在下载。

模型部署完成

② 本地模型文件

如果模型权重已被预下载到本地，可以执行以下命令。

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 测试

① 查看模型部署情况

xinference list \
  --endpoint http://localhost:6006

② WebUI

③ 发送请求

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 部署

① 云端模型

xinference launch \
  --model-name bge-small-zh-v1.5 \
  --model-type embedding \
  --endpoint http://localhost:6006

--model-name：模型名称

--model-type：模型类型

正在下载

部署完成

② 本地文件

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 测试

① 查看模型部署情况

xinference list \
  --endpoint http://localhost:6006

② WebUI

③ 发送请求

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 部署

xinference launch \
  --model-name bge-reranker-base \
  --model-type rerank \
  --endpoint http://localhost:6006

正在下载

部署完成

3.5.2 测试

① 查看模型部署情况

xinference list \
  --endpoint http://localhost:6006

② WebUI

③ 发送请求

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 部署排障。