
简介这份实战教程面向希望快速上手检索增强生成系统的开发者与运维人员围绕DeepSeek模型系统讲解RAG环境从零搭建的完整流程。内容涵盖技术栈概要、Dify服务器、Rerank与Embedding模型服务器、DeepSeek模型服务器三台ECS的分步部署并涉及CUDA驱动、vLLM推理库、Docker容器化、xinference框架以及bge-reranker-large、bge-large-zh-v1.5等中文模型的安装与调用帮助读者理解多机协作下的模型部署与检索增强链路。资源包为1个docx文档约580KB以图文步骤与目录结构呈现便于按章节对照操作。目前已有324人学习适合具备一定Linux与深度学习基础、需要落地RAG系统的技术人员参考可从中获取环境版本选定、依赖安装与模型验证等实操经验。1. 三台机器、三个模型这套 RAG 环境搭建到底在解决什么很多人第一次搭 RAG习惯把 Dify、Embedding、Rerank、大模型全塞进一台机器结果显存被抢爆服务互相拖死。这份教程的价值就在于它把角色拆开了ECS-1 跑 Dify 做应用编排ECS-2 用 xinference 挂 bge-reranker-large 和 bge-large-zh-v1.5 两个检索侧模型ECS-3 用 vLLM 起 DeepSeek-R1-Distill-Qwen-14B 做生成。三台机器各司其职显存不打架扩容也清晰。它适合谁手上有几张 Tesla T4 或 V100、想从零把一套能跑通知识库问答的 RAG 环境立起来的人。整套流程覆盖 CUDA 驱动、Python 虚拟环境、vLLM 推理服务、xinference 自定义模型注册属于典型的深度学习模型部署落地场景。下面按服务器逐台拆把参数和坑一起讲清。2. 技术栈选型为什么是 Dify xinference vLLM 这套组合2.1 三个组件各自扛什么活先理清分工不然后面装到一半会怀疑人生。Dify 是应用开发平台负责知识库管理、流程编排、智能体对话它本身不跑模型只通过 API 调后端推理服务。xinference 是模型推理框架专门用来托管 Embedding 和 Rerank 这类中小模型支持自定义模型注册适合把本地下载的权重挂上去。vLLM 则是为大语言模型推理设计的库靠 PagedAttention 把显存利用率和吞吐拉起来DeepSeek 这种 14B 级别的模型用它部署最省心。选型理由很直接Embedding 和 Rerank 模型小、调用频繁用 xinference 托管启动快、显存占用低生成模型大、对吞吐敏感用 vLLM 才能把并发撑起来。如果反过来把 14B 塞进 xinference或者用 vLLM 去跑 bge 这种小模型都是资源错配。2.2 模型与硬件对应关系教程里三台机器的配置不是随便写的模型精度和显存要对得上。下面这张表把关键对应关系列清楚选机器时照着对。服务器角色模型显卡要求系统镜像ECS-1应用编排Dify不跑模型对显卡无要求CentOS 7.5 64bitECS-2检索侧bge-reranker-large / bge-large-zh-v1.51×Tesla T4 16GiBUbuntu 20.04 Driver 470 CUDA 11.4ECS-3生成侧DeepSeek-R1-Distill-Qwen-14B1×Tesla V100 32GiBCentOS 7.9 CUDA 12.1判断某台机器能不能载某个模型教程给了一个实用方法看模型 config.json 里的torch_dtype字段它标了模型支持的精度再对照显卡显存估算。14B 模型用 half 精度大约要 28GB 显存所以 V100 32GiB 刚好够T4 16GiB 就顶不住这也是为什么生成模型必须单独放一台。2.3 版本锁定别让依赖把你带沟里这套环境对版本极其敏感教程明确锁了 ECS-3 的组合CentOS 7.9 CUDA 12.1 Python 3.10 vLLM 0.43。ECS-2 则是 Ubuntu 20.04 CUDA 11.4 Python 3.8。两台机器 CUDA 版本不同是因为驱动和镜像预装环境不同不要强行统一。提示vLLM 对 torch 版本有硬性要求装 vLLM 前先把 torch 固定到匹配 CUDA 的版本否则会在编译阶段报一堆找不到符号的错。3. ECS-2 实战xinference 托管 Embedding 与 Rerank 模型3.1 安装 xinference 并启动服务ECS-2 的任务是把两个检索侧模型跑起来。先装 xinference它带 all 依赖会把推理后端一起装上。# 安装 xinference 全量依赖 pip install xinference[all] # 配置模型存储目录避免默认路径占满系统盘 export XINFERENCE_HOME/tmp/xinference # 前台启动方便第一次看日志 xinference-local --host 0.0.0.0 --port 9997 # 确认命令可用 xinference --helpXINFERENCE_HOME决定模型缓存和注册信息落盘位置生产环境建议指到大盘。端口 9997 是教程固定值后面 Dify 配置要对应别随意改。第一次用前台启动能直接看到模型加载日志确认没问题后改成后台# 后台启动并把日志重定向到文件 nohup xinference-local --host 0.0.0.0 --port 9997 nohup.out --host 0.0.0.0是为了让 ECS-1 上的 Dify 能跨机访问只绑 127.0.0.1 的话外部调不通。日志重定向到 nohup.out出问题先tail -f nohup.out。3.2 注册并启动 bge-reranker-largeRerank 模型负责对检索结果二次排序是提升命中率的关键。xinference 内置模型列表里不一定有你要的版本所以走自定义注册。先把 HuggingFace 上的模型文件下载到本地再上传服务器然后写 config.json{ model_name: custom-bge-reranker-large, type: normal, language: [en, zh], model_id: BAAI/bge-reranker-large, model_uri: file:///path/to/bge-reranker-large }model_name是注册到 xinference 里的别名后面启动要用它model_uri指向本地权重目录用file://前缀。注册和启动分两步# 注册自定义 rerank 模型并持久化 xinference register --model-type rerank --file model.json --persist # 检查注册结果 xinference registrations --model-type rerank # 启动模型 xinference launch --model-name custom-bge-reranker-large --model-type rerank # 需要下线时注销 xinference unregister --model-type rerank --model-name custom-bge-reranker-large--persist很关键不加的话重启 xinference 注册信息就丢了得重新注册这是血泪经验。registrations用来确认模型确实进了列表launch才会真正加载权重占显存。3.3 注册并启动 bge-large-zh-v1.5Embedding 模型把文本转成向量是知识库构建的基础。它的 config.json 比 rerank 多了维度和长度限制{ model_name: custom-bge-large-zh-v1.5, dimensions: 768, max_tokens: 512, language: [zh], model_id: BAAI/bge-large-zh-v1.5, model_uri: file:///path/to/bge-large-zh-v1.5 }dimensions必须和模型真实输出维度一致bge-large-zh-v1.5 是 768填错会导致向量入库后检索全乱。max_tokens是单条文本最大长度超长会被截断。注册启动流程和 rerank 一样只是类型换成 embedding# 注册 embedding 模型 xinference register --model-type embedding --file model.json --persist # 确认注册 xinference registrations --model-type embedding # 启动 xinference launch --model-name custom-bge-large-zh-v1.5 --model-type embedding两个模型都起来后ECS-2 的显存占用会明显上升T4 16GiB 同时挂这两个是够的但如果还想塞别的模型就要掂量了。4. ECS-3 实战CUDA 环境与 vLLM 部署 DeepSeek4.1 驱动与 CUDA 安装的先后顺序ECS-3 跑 14B 模型环境最重。教程踩过一个典型坑驱动和 CUDA 不能一起装一起装会失败。正确顺序是先单独装 NVIDIA 驱动选 x86_64 历史版本里的 530.30.02这个版本对应 CUDA 12.1。驱动装完再装 CUDA安装时取消勾选驱动选项。# 装完 CUDA 后配置环境变量 vim ~/.bashrc # 在文件末尾加入路径按实际 CUDA 版本替换 export PATH/usr/local/cuda-12.1/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda-12.1/lib64:$LD_LIBRARY_PATH # 刷新环境变量 source ~/.bashrc # 验证 CUDA 版本 nvcc -V # 验证驱动与 CUDA 是否匹配 nvidia-sminvcc -V看的是 CUDA 工具链版本nvidia-smi右上角显示的是驱动支持的最高 CUDA 版本两者一致或驱动版本更高即可。如果nvcc找不到命令八成是 PATH 没生效重开终端或重新 source。4.2 Python 环境与 torch 版本匹配用 conda 建独立环境避免污染系统 Python。torch 必须和 CUDA 12.1 匹配否则 vLLM 装到一半就报错。# 创建 Python 3.10 虚拟环境 conda create -n myenv python3.10 -y # 激活环境 conda activate myenv # 安装匹配 CUDA 12.1 的 torch 三件套 pip install torch2.3.0 torchvision0.18.0 torchaudio2.3.0 --index-url https://download.pytorch.org/whl/cu121--index-url指向 PyTorch 官方 CUDA 12.1 的 wheel 源不指定的话默认装 CPU 版vLLM 会直接报没有 CUDA 支持。torch 版本和 vLLM 0.43 是配套的别自己升。4.3 安装 vLLM 并启动 DeepSeek 服务torch 就位后装 vLLM过程中可能提示某些依赖版本冲突按报错要求逐个指定版本装即可。模型文件提前下载上传到服务器14B 权重体积不小别等启动时现下。# 安装指定版本 vLLM pip install vllm0.43 # 启动 OpenAI 兼容 API 服务 python -m vllm.entrypoints.openai.api_server \ --model /root/work/ds/pretrained \ --dtype half \ --trust-remote-code \ --tensor-parallel-size 1 \ --max-model-len 5120 \ --enforce-eager \ --gpu-memory-utilization 0.95 \ --max-num-batched-tokens 5120 \ --max-num-seqs 5 \ --host 0.0.0.0 \ --served-model-name DeepSeek-R1-14B \ --port 8008 逐个参数说清--model是本地权重路径--dtype half用半精度省显存--trust-remote-code允许加载模型自带的自定义代码DeepSeek 系列必须加--tensor-parallel-size 1表示单卡多卡才调大--max-model-len 5120限制上下文长度直接决定 KV Cache 占用V100 32GiB 上别设太大--enforce-eager关掉 CUDA 图捕获牺牲一点性能换稳定显存紧张时建议开--gpu-memory-utilization 0.95让 vLLM 用 95% 显存--max-num-seqs 5限制并发序列数防止显存被并发打爆--served-model-name是 Dify 调用时填的模型名--port 8008是服务端口。启动后看到模型加载完成、监听 8008 的日志就说明生成侧通了。可以用 curl 测一下 OpenAI 兼容接口是否响应。5. 避坑排查这套环境最容易翻车的五个地方5.1 xinference 注册信息重启后消失现象重启 xinference 后registrations列表空了模型要重新注册。原因注册时没加--persist信息只存在内存里。解决注册命令统一带上--persist并确认XINFERENCE_HOME指向的目录有写权限且不会被清理。5.2 vLLM 启动报 CUDA 版本不匹配现象启动 vLLM 时报找不到 libcudart 或 CUDA 版本不符。原因装的 torch 是 CPU 版或 CUDA 版本和驱动对不上。解决用pip show torch确认版本重装时带--index-url https://download.pytorch.org/whl/cu121并核对nvidia-smi显示的驱动支持版本。5.3 显存不够导致模型加载中断现象14B 模型加载到一半 OOM。原因max-model-len设太大KV Cache 吃光显存或gpu-memory-utilization设太高没留余量。解决把max-model-len降到 5120 甚至更低gpu-memory-utilization从 0.95 往下调加--enforce-eager减少显存峰值。5.4 Embedding 维度填错导致检索失效现象知识库能建但检索结果完全不相关。原因config.json 里dimensions和模型真实维度不一致向量入库后距离计算全错。解决bge-large-zh-v1.5 固定填 768注册后可以调一次 embedding 接口看返回向量长度是否匹配。5.5 Dify 跨机调不通推理服务现象Dify 里配置模型后测试连接失败。原因xinference 或 vLLM 只绑了 127.0.0.1或安全组没放行端口。解决启动时统一用--host 0.0.0.0并在云服务器安全组放行 9997 和 8008 端口用telnet从 ECS-1 测一下连通性。6. 进阶技巧用一条链路验证三台机器是否真的打通环境搭完不代表能用得有一条端到端验证链路。我一般会按「Embedding 出向量 → Rerank 出分数 → 大模型出回答」的顺序逐段测任何一段断了都能立刻定位。先测 ECS-2 的 Embedding 服务确认向量维度# 调用 xinference 的 embedding 接口 curl http://ECS-2_IP:9997/v1/embeddings \ -H Content-Type: application/json \ -d {model: custom-bge-large-zh-v1.5, input: 测试文本}返回的data[0].embedding长度应该是 768不是就说明模型注册或维度配置有问题。再测 Rerank给一组 query 和候选文档看返回的相关性分数是否合理。最后测 ECS-3 的生成服务# 调用 vLLM 的 OpenAI 兼容接口 curl http://ECS-3_IP:8008/v1/chat/completions \ -H Content-Type: application/json \ -d {model: DeepSeek-R1-14B, messages: [{role: user, content: 你好}]}三段都通之后回到 Dify 里把三个服务地址分别填进模型供应商配置建一个知识库上传文档跑一次问答。如果检索召回正常但回答跑偏多半是 Rerank 没生效或 prompt 编排问题如果检索就召不回回头查 Embedding 维度和知识库分段策略。几个调优方向max-model-len和max-num-seqs是一对矛盾参数上下文越长、并发越高显存越紧张V100 32GiB 上建议先保守再逐步加压Rerank 的 top_k 不要设太大一般召回 20 条重排取前 3 到 5 条进生成太多反而稀释相关性Embedding 的max_tokens512 意味着长文档要先切分切分粒度直接影响召回质量。从那以后我每次搭多机推理环境都强制先跑一遍这条三段验证链路确认每段单独可用再联调省得三台机器一起排查。希望帮到你。本文还有配套的精品资源点击获取