你已经能用 vLLM 把 DeepSeek 起成一个 OpenAI 兼容接口，但一接进 Dify 就发现模型列表空着、对话报超时、流式输出断在半路。这篇不讲该不该自建，只讲这条链路怎么接起来：三层各自负责什么、配置项填哪些、出问题按什么顺序排查，最后告诉你什么场景下这套组合其实不划算。
你已经能用 vLLM 把 DeepSeek 起成一个 OpenAI 兼容接口，但一接进 Dify 就发现模型列表空着、对话报超时、流式输出断在半路。这篇不讲该不该自建，只讲这条链路怎么接起来：三层各自负责什么、配置项填哪些、出问题按什么顺序排查，最后告诉你什么场景下这套组合其实不划算。
整体思路就一句话：让每层只暴露它该暴露的东西。vLLM 只负责把权重变成 HTTP 服务，Dify 只负责编排，DeepSeek 只负责提供权重。任何跨层「顺手帮忙」的配置，最后都会变成排查时的噪音。下面按这个顺序往下走。
先分清三层各自管什么
把这三层当成三个独立的人，谁出问题找谁，别互相甩锅。vLLM 的职责边界很清楚：加载权重、调度并发、管显存，对外只给一个兼容接口。它不知道什么是提示词模板，也不关心你后面接的是知识库还是工作流。选 DeepSeek 哪个参数量、用哪种量化档位，直接决定你这张卡能扛多少并发，这个对应关系不要凭感觉估，到 /models/deploy 按你的卡型算一遍。
- vLLM
- 推理服务层，只干一件事：把权重加载进显存，吐出一个 OpenAI 兼容的 HTTP 接口
- Dify
- 编排层，提示词、知识库、工作流、会话历史、对外 API 都在这里，不关心模型跑在哪台机器
- DeepSeek
- 权重层，选哪个规模、什么量化档位，决定卡够不够、并发能开多少
- 三层解耦的好处：换模型不用动工作流，工作流改版也不用重启推理服务
- 三层解耦的坏处：任何一层配错，报错信息长得都像另一层的锅，所以排查必须分层
- 判断依据：如果 curl 能通但 Dify 不通，问题基本不在 vLLM；如果 curl 都不通，先别碰 Dify
- 常见的错位：把 Dify 的模型名当成随便填的标签，其实它必须和 vLLM 启动时注册的名字逐字一致
接线顺序：从 vLLM 到 Dify 四步走
很多人卡住不是某一步配置难，而是顺序反了——先在 Dify 里配模型，再接知识库，最后才发现 vLLM 根本没跑通，回头每一步都要重查。按下面四步走，每一步都有独立验证动作，通过再进下一步。
- 先把 vLLM 单独跑通用 curl 打一次 completions 接口，同时测一次非流式和一次流式。这一步不通过，后面全是白搭，别往下走。
- 确认监听地址能被 Dify 访问同机部署最常见的坑是绑了 127.0.0.1，Dify 跑在容器里就访问不到。换成容器网络能路由到的地址，再用容器内部 curl 验证一次。
- 在 Dify 里选 OpenAI 兼容供应商base URL 指向你的 vLLM 服务地址，模型名必须和 vLLM 启动参数里注册的名字完全一致，多一个空格都连不上。
- 先用纯对话应用试不要一上来就挂知识库和工作流。纯对话通了再加 RAG，这样出问题你能确定是新加的那一块造成的。
第四步是很多人忽略的：Dify 里一个应用可以挂很多能力，但你第一次接线时只留对话，等于把变量控制到最少。等链路稳定了，再逐个往上加知识库、工作流、外部工具，每加一个验证一次，比一次性全开然后漫无目的查日志高效得多。
参数对齐：三处最容易互相打架的地方
接线通了不等于能用。三层各有一套参数，谁都以为对方会兜底，结果就是超时、截断、流式失效这些问题。下面这三个参数项是冲突高发区，接好线之后务必逐个对齐。
| 参数项 | 冲突表现 | 对齐做法 |
|---|---|---|
| 上下文长度 | 回答被静默截断，或直接报长度超限 | vLLM 启动的最大长度设为上限，Dify 配置填的值和实际提示词长度都要小于它 |
| 并发与超时 | 请求排队后集体超时，看起来像服务挂了 | Dify 超时要留够首 token 时间，vLLM 并发上限按显存和 batch 策略设，别两边都往高设 |
| 流式开关 | 回答一次性蹦出来，像卡住了 | 两边都开才有效果，只开一边等于没开 |
每张卡能扛多少并发，不要照搬别人文章里的数字，模型规模、量化档位、输入长度都会影响。站内 /compute/sizing 有按模型和量化方式的测算口径，按你自己的硬件和实际请求长度套一遍，比抄一个数字靠谱。
- 上下文长度：先定 vLLM 启动值，再倒推 Dify 配置值和提示词预算，顺序反了会反复调
- 并发：先用低并发跑通，再按吞吐需求逐步加，加的过程中盯排队时间和超时率
- 流式：调试阶段建议先关流式确认链路通，通了再开，省得把两类问题混在一起
- 参数改动：一次只改一个，改完做一次同样的请求验证，别一次调三项然后不知道是哪项生效
连不上时的排查顺序
排查的核心原则是从外往内剥，先排除掉不可能出问题的那层，别一上来就翻日志。按下面的顺序走，每一步都有一个明确的「通/不通」结论，把范围一步步缩小。
- 先绕开 Dify用 curl 或任意 HTTP 客户端直接请求 vLLM 的模型列表接口。返回空或报错，说明问题在推理层，不用往上看。
- 再绕开模型在 Dify 里换成任意一个能用的接口配置，看应用本身是否正常。正常说明编排层没问题，问题回到 vLLM 连接配置上。
- 然后查网络容器之间、宿主机与容器之间、端口映射这三层逐层确认，最常见的是最后一层端口没映射出去。
- 最后看日志vLLM 侧看有没有收到请求，Dify 侧看请求体长什么样。两边日志一对，大部分问题能定位到具体哪一层没接上。
排查不是猜哪层坏了，而是用一次请求把三层各验证一遍，谁没产生日志谁就是断点。
什么情况下这套组合不值得搭
这套组合不是默认答案，它解决的是「数据不出内网 + 有稳定并发需求 + 想用编排能力」这三件事同时成立的情况。缺一条，你就是在为不需要的复杂度付费。判断之前先问自己三个问题，有一个答案是不需要，就换个更轻的方案。
| 场景 | 建议 | 原因 |
|---|---|---|
| 一两个人偶尔用 | 用更轻量的本地服务 | 常驻显存的运维成本比按量调接口高，没必要为低频需求占着卡 |
| 模型规模超出单卡 | 先确认是否真需要这个吞吐 | 多卡并行能跑但配置复杂度上一个台阶，别为跑通而跑通 |
| 工作流重度依赖多模型 | 本地链路只当其中一环 | 频繁调外部模型的编排里，单独优化本地这一段收益有限 |
| 合规不要求数据出内网且调用频率低 | 重新评估是否被「本地部署」绑架 | 没有硬性约束时，编排层的灵活性往往比部署位置更重要 |
还有一类容易被忽略的情况：团队里没有能负责推理服务运维的人。vLLM 跑起来不难，难的是长期盯着显存、并发、版本升级这些事。如果这条链路没人接手，它迟早会变成一个没人敢动的黑盒，那时候再迁移的成本比一开始就用托管方案高得多。
下一步接线通了之后，先别急着堆功能，花十分钟按你的卡型和模型规模核对一遍并发与上下文的测算口径，能省掉后面大量「明明通了却总超时」的返工。→常见问题
vLLM 起好了，Dify 里模型列表是空的，先查哪？
先直接用 HTTP 请求打 vLLM 的模型列表接口，看服务本身有没有正常返回。如果这边正常，问题基本在 Dify 的地址填写和网络可达性：容器部署时 base URL 不能用 127.0.0.1，要用容器能解析到的主机名或 IP，端口映射也要确认。两步分开测，比在 Dify 日志里猜快得多。
这套链路和 Ollama 接 Dify 差在哪？
差别在推理层的定位。Ollama 偏单机自用，装完就能跑，管理省事；vLLM 偏服务化，吞吐和并发调度更强，但要自己管显存参数、并发上限和服务常驻。团队多人共用、有明显并发压力时 vLLM 更合适；个人或小团队低频调用，Ollama 的体感反而更好。
DeepSeek 换成别的模型，Dify 那边要改什么？
如果新模型也是通过同一个 vLLM 服务或同样 OpenAI 兼容接口暴露的，Dify 里通常只要改模型名，个别情况改 base URL，工作流和知识库不用动。这正是三层解耦的价值。但如果新模型要换一套推理框架（比如从 vLLM 换成别的），接口路径和参数命名可能不同，那就等于换了一层，配置要重来。
