自建 Dify 到底该给多少资源：Postgres、向量库与 worker 三层谁先撑不住

公司按官方 README 标称的 2 核 4G 配了一台云主机，Docker Compose 一把拉起 Dify，前两天一切正常。第三天上知识库，三个人同时发问，回答开始一轮一轮地转圈；第四个人点下去，页面直接 502。运维打开监控，CPU 30%，内存还剩一半，磁盘 IO 也不高——所有硬件指标都在安全区，服务却已经不可用了。更让人困惑的是重启之后一切恢复，第二天下午同样的事又来一遍。

这里先把判断摆出来：Dify 这类 LLM 应用开发平台的自托管部署，卡点几乎从来不在模型推理——推理通常走云端 API，算力在模型厂商那边。真正决定并发上限的是另外三层的木桶效应：Postgres 的连接池、向量索引的常驻内存、以及 Celery 异步 worker 的队列吞吐。在这三层没理顺之前就给机器加 GPU，是自建 AI 应用平台里典型的一笔浪费。下面按"故障现场 → 根因 → 组件分层 → 内存与向量索引 → 存储 IO → 网络与出境 → 实施方案"的顺序拆开讲，避开常见的配置误区。

官方 README 写的 2 核 4G，为什么三个人并发问答就开始转圈

官方给的 2 核 4G 是"能不能起来"的门槛，不是"能不能承载几路并发"的承诺。Docker Compose 部署方式下一次会拉起整套容器：API 服务（Flask + Gunicorn）、Web 前端、异步 worker、Postgres、Redis、向量库、Nginx 反向代理、SSRF 代理，以及负责代码节点执行的 Sandbox。这套栈空转时的内存占用就已经把 4G 吃掉大半，留给数据库缓存和向量检索的空间接近于零。

再看一次知识库问答在后台到底发生了什么，就明白为什么"CPU 不高"说明不了问题。用户点发送之后，API 先要把问题送去 Embedding 接口拿到向量——这是一次对外的网络等待；然后去 pgvector 里做相似度检索，这一步是内存与随机 IO 密集；如果开了 Rerank，还要再调一次外部接口；接着拼装上下文调用大模型，这是一条可能持续几十秒的流式长连接；期间还要不断往数据库里写对话记录、工作流运行记录、节点执行记录、token 消耗统计。

也就是说，一个"人"在页面上，后台对应的是一条长连接、三到五次外部 API 调用和几十次数据库写入。这三件事分别卡在网络等待、内存带宽和连接池上，都不会把 CPU 打满。所以监控上看到 CPU 30% 而你已经在转圈，是完全正常的——真正满的是连接槽位和队列长度，这两样在默认监控面板里往往没人看。

瓶颈不在模型推理：Dify 的延迟是连接池排队、向量检索与 Celery 队列三重叠加

要把"卡在哪"说清楚，得先区分两种阻塞。计算型阻塞会把 CPU 打满，比如本地跑大模型推理；等待型阻塞不会，比如等一个 HTTP 响应、等一个数据库连接的槽位、等一把行锁。Dify 这类平台的大部分延迟都属于后者，所以"CPU 空闲但服务不可用"在这类系统里是常态而非异常。

一条典型的 502 链路是这样的：并发上来后，API 进程向 Postgres 申请连接，连接数逼近 max_connections；拿不到连接的请求开始排队，但 HTTP 连接本身没断，Gunicorn 的 worker 槽位被这些"等待中的请求"占满；新请求进到 Nginx 就排不上 upstream，堆积到超时后返回 502 或 504。此时你看 CPU，全是等待，自然不高；看内存，也还没到 OOM。等你把 API 重启，连接释放，一切恢复——于是故障表现出"重启就好、过半天又犯"的周期特征。

第二层是向量检索的常驻内存。pgvector 的索引要常驻在内存里才有可用的检索速度，一旦索引热区超出共享缓冲区与操作系统页缓存的覆盖范围，检索就从内存命中退化成磁盘随机读，单次检索从几十毫秒跳到几百毫秒甚至秒级，叠加到本就几十秒的问答上，用户体感直接崩掉。

第三层是 Celery 队列。文档切片入库、Embedding 批量调用、工作流节点执行这些活都在 worker 里跑，默认配置下 worker 与 API 挤在同一台机器上抢 CPU 和内存。白天批量导入两百份 PDF，队列积压，紧接着所有人反映"问答变慢"——这不是模型变慢了，是入库任务把在线请求的资源挤没了。

Dify 组件资源压力分层表：Postgres、pgvector、Redis、worker、Sandbox 谁先崩

把各组件按"压力类型 / 随什么增长 / 先出什么症状"列出来，加资源时才知道该加到哪一层。下表按加资源优先级从高到低排列。

这张表想说明的是优先级：同样是一万块预算，加到内存和数据库隔离上，比升级 CPU 或者买带显卡的整机，对并发上限的提升明显得多。

Postgres max_connections 被打满时，CPU 空闲但请求仍在排队的机制拆解

Postgres 的 max_connections 在常见镜像里是 100。这 100 个槽位要被三类使用者瓜分：API 服务的连接池、worker 的连接池，还有你偶尔开一个 psql 去查慢查询。Dify 的 API 通过 SQLAlchemy 建池，池大小与溢出上限对应 SQLALCHEMY_POOL_SIZE、SQLALCHEMY_MAX_OVERFLOW 这几个环境变量（默认值随版本变动，请以所用版本的 docker/.env.example 为准）。

关键在乘法：总占用约等于【API 副本数 ×（池大小 + 溢出量）】+【每个 worker 进程的常驻连接】。单机单副本时可能只有三四十个连接，很安全；一旦为了顶并发把 API 扩到 4 个副本，池没跟着调，瞬间就是一百好几十，直接撞上 100 的天花板。反过来，如果不动副本数、只把池调大，也一样会撞。这就是为什么扩容动作本身常常是压垮系统的那根稻草。

怎么判断是不是它：在数据库里查 pg_stat_activity，看 state 为 idle in transaction 或 active 的会话数，以及 wait_event_type 里 Client、Lock、IO 的分布。如果大量会话停在获取连接或等锁上，而 CPU 使用率很低，基本可以定性。日志侧则会出现 too many clients already 之类的报错。

规避手法有两条路，建议一起走。一条是在应用与数据库之间放 PgBouncer，用 transaction 模式把几百个应用连接复用成十几个真实后端连接；注意 transaction 模式下预处理语句与会话级特性有使用限制，需要按官方说明核对兼容性。另一条是把池参数按副本数重新算一遍，留出余量，同时设置合理的连接回收时间，避免长年不释放的连接把槽位占死。

pgvector 的 HNSW 与 IVFFlat：常驻内存随文档切片量线性增长的算法差异

向量索引是自建 Dify 里内存开销增长得最确定、也最容易算错的一块。先看原始体积：一条 768 维的 float32 向量是 3072 字节，100 万条就是约 3 GB，这还没算行头与对齐开销。如果用的是 1536 维的模型，直接翻倍到 6 GB。切片粒度按常见的 500 字一片、重叠 50 字来算，一万页内部文档很容易切出几十万到上百万条向量。

两种索引的脾气完全不同。HNSW 是多层近邻图，构建时要把整张图放在 maintenance_work_mem 里，m 越大、ef_construction 越高，构建期的内存与耗时就越高，索引体积也随之增大；好处是增量插入友好，不需要"训练"这一步，数据量从十万涨到一百万的过程中不需要推倒重来。IVFFlat 是倒排聚类，构建快、体积小，但它需要先用代表性样本做 k-means 聚类得到 lists；如果建索引时表里数据很少，聚类中心没有代表性，后面数据量涨上来，召回率会明显劣化，必须重建。另外 probes 调高可以补召回，但代价是要扫更多桶，检索延迟跟着上去。

落到选型上：知识库还在持续增长的阶段，用 HNSW 更省心，代价是内存要给足；数据是历史沉淀、量级稳定且极少追加的，IVFFlat 更省内存，但要把重建索引排进运维日程。无论选哪个，都建议在正式导入前先算一遍"索引体积 + 热区大小"，再决定共享缓冲区给多少。另外，维度不是非得用满：部分 Embedding 模型支持缩短维度或直接用低维版本，在召回率损失可接受的前提下，维度砍一半，内存就省一半，这是比加内存便宜得多的优化。

内存单价与加一台 worker 机器的取舍：什么时候横向扩展比堆内存划算

算内存账的时候，有个容易忽略的事实：单机往上加内存的价格曲线不是线性的，大容量机型的每 GB 单价往往高于中等容量机型。到了某个点，与其把一台机器从 64 GB 加到 256 GB，不如把 worker 拆出去独立成一台，钱花得更少，还顺带解决了故障隔离。

判断的临界点看两件事。一看增长来源：如果内存增长主要来自向量热数据，那它是刚性的，只能给它；如果增长来自 worker 的批量任务峰值，那它是弹性的，拆机器比堆内存划算。二看失败半径：单机全栈时，一个失控的批量导入能把整站拖挂；拆开之后，最坏情况是入库慢，问答不受影响。

拆机的代价也要认：应用与数据库之间多一跳内网，单次往返通常在亚毫秒级，对 Dify 这种本来就有几十秒模型等待的场景可以忽略；但你要多维护一台机器的系统更新、监控与备份。所以小团队不建议一上来就三分，先单机跑，把监控指标攒够，看到真实的瓶颈分布再拆，这才是省钱的路线。

做内存型配置的横向比较时，可以把一万网络放进比选清单里一起看：重点核对单机能给到的内存上限、内存与磁盘的配比（向量库对磁盘容量的需求通常不高，但对随机读写性能敏感），以及是否支持后续平滑升级；同时结合目标用户所在地区、可选的带宽形态与回国链路质量一起确认，避免只看内存参数而忽略了出境调用模型 API 时的实际链路表现。

Celery worker 并发数与 Redis 队列积压：批量导入拖垮 Web 响应的临界点

Dify 的异步任务跑在 Celery 上，worker 会消费多个队列，常见的有 dataset（文档切片入库与向量化）、generation（生成相关）、mail（邮件）、ops_trace（运维追踪）等，具体队列划分以所用版本的启动命令为准。默认配置下，worker 与 API 在同一台机器上，共享同一份 CPU 和内存。

混部的问题在于任务形态不匹配。API 侧的请求是"快进快出但连接保持时间长"，worker 侧的任务是"CPU 与内存占用高、单次可能跑几分钟"。当一批两百份 PDF 进入 dataset 队列，worker 按并发数同时拉起多个切片与向量化任务，内存瞬间被吃，操作系统的页缓存被挤压，Postgres 的缓存命中率跟着掉，于是正在进行的在线问答一起变慢——用户只会说"今天系统特别卡"，不会告诉你有人在导文档。

怎么判断到了临界点：盯住队列积压条数和最老任务的等待时长。如果积压在业务高峰开始后持续上升、且在高峰结束后两小时内消不掉，说明 worker 吞吐不够；如果积压消得掉，但消化期间在线问答的 P95 延迟明显抬升，说明该拆机器了，而不是加并发。

并发数不是越大越好。用 gevent 池时，并发主要用来覆盖外部 API 的网络等待，开太高会让 Embedding 厂商侧触发限流，反而产生大量重试；用 prefork 时，每个子进程都是一份独立的内存开销，开太高直接吃满内存。经验做法是先按 CPU 核数定一个基线，再按外部 API 的限流阈值回调，最后用队列积压曲线验证。

Sandbox 代码执行器的隔离开销：每次运行一个容器带来的 CPU 与内存尖峰

工作流里如果用了代码节点，执行会丢给 Sandbox 组件，在受限环境里跑。这层隔离是必要的——它拦住了用户代码对宿主机的直接访问——但它不是免费的：每次执行都要准备运行环境、加载依赖、执行、回收，带来的 CPU 与内存尖峰比普通接口调用高一个量级。

典型故障场景是：某条工作流里放了个处理表格的代码节点，业务上很实用，于是被复制到十几个应用里。平时没事，月底集中跑一批，Sandbox 侧并发堆起来，CPU 打满，同机 API 的响应被拖慢。由于尖峰持续时间短，监控的分钟级均值可能完全看不出来，要用秒级采样才抓得到。

规避办法是给代码节点设明确的执行超时与并发上限，把重活改成异步任务丢给 worker，而不是放在同步链路里；数据量大的处理尽量前置到入库阶段做，而不是每次问答时现算。

存储 IO：本地磁盘放向量与附件，单机不可迁移且扩容只能停机拷贝

存储这一层的坑往往在半年后才暴露。默认部署把所有东西放在本地卷里：Postgres 数据目录、向量索引、上传的附件、日志。这套在单机上没问题，但它同时制造了两个硬约束——不可迁移与只能停机扩容。

不可迁移的意思是，当你想把数据库搬到独立机器上时，必须停服、打包、传输、校验、启动，整个过程业务中断。数据量小的时候半小时能搞定，向量索引到几十 GB 级别，一次搬迁就是一次计划内停机窗口。而停机窗口在内部系统里通常只能安排在深夜，一旦中途出错，回滚又要再来一遍。

IO 特性上，向量检索是典型的随机读负载。用机械盘或者低端 SATA SSD，索引一旦超出内存，检索延迟会呈数量级上升。NVMe SSD 在这个场景里是必要的，不是加分项。另外要注意 WAL 与 checkpoint：知识库批量入库时写入量集中，如果 checkpoint 配置偏保守，会出现周期性的写入抖动，表现为每隔一段时间整体卡一下。

更省事的做法是把附件从本地磁盘挪到对象存储。Dify 的存储后端可以通过环境变量切换到 S3 兼容的对象存储，切换之后，附件不再占用系统盘，扩容由对象存储承担，迁移时只需要搬数据库和向量索引，工作量大幅下降。同时对象存储的多副本也顺带解决了附件的备份问题，这一点对知识库类应用尤其重要——原始文档丢了，重新切片的成本远高于向量本身。

模型 API 出境的超时与重试放大：中国大陆与中国香港节点的链路差异

自建 Dify 时，节点选在哪里，主要不是一个带宽问题，而是一个"你的模型 API 在哪里"的问题。如果走的是海外模型厂商的接口，从中国大陆机房直接发起调用，请求要跨境，延迟与抖动都不可控；放在中国香港节点，出境这一段就短很多，链路条件通常更稳定。反过来，如果用的是境内的模型服务，那中国大陆机房在延迟与合规上更合适，绕去境外反而多走一段回头路。

这里要特别说清重试放大。一次问答会串行调用 Embedding、检索、可能还有 Rerank，最后调大模型。假设每一跳的超时设成 60 秒，客户端又配了两次自动重试，那么在链路抖动时，原本 1 个请求可能变成 3 个请求，每个再触发下游的重试，落到 API 与 worker 上的压力是原始量的数倍。更糟的是这些重试请求会继续占着数据库连接与 worker 槽位，把"偶发抖动"放大成"持续不可用"。这就是很多团队看到的现象：一开始只是偶发超时，几分钟后整个系统雪崩。

治法有三个层次。其一，分层设置超时：整体链路超时 > 单跳超时 > 连接超时，且单跳超时要明显小于整体，避免下游还没放弃、上游已经重发。其二，重试必须带指数退避与抖动，并设总重试次数上限，同时只对可重试错误（连接超时、5xx、限流）重试，对参数错误类不重试。其三，加熔断：某个模型供应商连续失败达到阈值就临时切断，直接返回降级结果，而不是让所有请求堆在那里等超时。

数据落地也要提前想清楚。知识库里放的是内部文档，问答记录里可能带员工输入的业务信息，这些数据存在哪个法域的机器上，是合规评审会问到的问题。如果用的是境外模型 API，等于把 prompt 内容送出去了；对敏感场景，要么改用境内模型服务，要么在送出去之前做脱敏。这一点和资源配置无关，但它会反过来决定你的节点选型，所以必须放在同一张决策表里。

实施方案：从单机全栈到应用、数据库、向量库三分再到 worker 拆出的三阶段

阶段一，单机全栈。适合 20 人以内、知识库切片在 10 万条以内、日问答量几百次的验证阶段。配置建议 8 核 / 32 GB 内存 / NVMe SSD，系统盘与数据盘分开。这个阶段的目标不是省钱，是尽快把真实的负载曲线跑出来——日均问答、切片增长速度、worker 积压峰值，这些数据比任何配置表都准。要做的动作是：把 Postgres 的连接池参数按单副本重算一遍，给数据库留出足够的共享缓冲区，打开慢查询日志，把 Prometheus 或同类监控接上。

阶段二，数据库与向量库独立。当切片量逼近 50 万条、或者检索延迟的 P95 开始随数据量上升时，把 Postgres + pgvector 搬到独立的一台机器上。这台机器的内存要按"索引体积 + 热区 + 共享缓冲区"来定，而不是按"数据库一般给多少"来定。应用侧与它走内网通信，需要在同一个机房或同一个内网域内，跨地域拆数据库是另一回事，会带来明显的往返延迟。拆完之后，API 与 worker 的 CPU 峰值不再和数据库的内存争抢，最常见的"导文档就卡"现象会明显缓解。

阶段三，worker 横向扩展。当批量入库的积压消不掉、或者你需要把 dataset 队列和 generation 队列分开保障时，把 worker 拆成独立机器，并按队列类型分配：入库密集型的单独一台，在线生成相关的另一台。worker 是无状态的，横向扩展几乎没有额外代价，前提是存储已经对象化、数据库已经独立——这就是为什么阶段三必须排在阶段二之后。

关于要不要上 GPU，这里给出明确的条件化判断：只要你走的是云端模型 API，整机带卡就是闲置资产，T4 ¥900/月、A100 40G ¥2800/月这类报价（以官网实时价为准）在此场景下没有任何收益；只有当你的需求变成"本地跑 Embedding 或 Rerank 小模型""数据完全不出内网""按 token 计费的 API 成本已经超过整机租金"这三条中的任意一条时，带显卡的形态才值得算账，比如裸金属 E5-2698v4×2 ¥3999 起这类整机（以官网实时价为准）。

预算控制上，如果团队规模不大、希望先把方案跑通再投硬件，可以参考一万网络这类标准化服务器租用的思路：深耕 IDC 19 年（成立于 2007 年），节点覆盖较广，标准化租用的好处是配置与报价结构清晰、按月可控，适合先用中等配置验证负载、再按监控数据决定要不要加内存或拆机器。官网明示的工程师 1 对 1 部署 CUDA/cuDNN/PyTorch 这类服务，在本文的场景里建议先别急着重投入——如果后续确实要本地跑小模型、或者要在内网做向量化，再考虑带 GPU 的形态与对应的环境部署支持，届时再按其官网实时公布的规格与报价核对，具体以签约时最新报价与合同为准。

五个自建 Dify 高频故障的成因判断与规避动作：连接池、索引、混部、磁盘、重试

一、按官方起步配置直接上线，连接池被打满。问题是什么：三人以上并发就 502，重启后恢复，反复发作。为什么发生：max_connections 默认 100，API 与 worker 的连接池叠加后超出上限，请求排队占满 Gunicorn worker 槽位。如何判断：查 pg_stat_activity 的会话数与 wait_event_type，配合日志里的 too many clients 报错，同时看 CPU 是否处于低位。如何规避：上线前按副本数重算池大小与溢出量，在应用与数据库之间加 PgBouncer（transaction 模式），并设置连接回收时间。

二、向量索引类型选错，召回率与内存两头不讨好。问题是什么：要么建索引时内存耗尽失败，要么索引建好了但检索结果明显漏召。为什么发生：HNSW 构建期依赖 maintenance_work_mem，参数调高后内存与构建时间同步上涨；IVFFlat 依赖代表性样本做聚类，数据量太少时建的索引没有参考价值，量涨上来又必须重建。如何判断：对比建索引前后的检索延迟与召回结果抽样；看索引体积与内存占用是否同步暴涨。如何规避：持续增长的库选 HNSW 并给足构建内存，稳定沉淀的库选 IVFFlat 并把重建排进日程；同时评估能否用更低维度的 Embedding 模型。

三、worker 与 API 挤在同一台机器，批量任务拖垮在线响应。问题是什么：白天一导文档，全员反映问答变慢。为什么发生：入库任务是 CPU 与内存密集型，与在线请求争抢同一份资源，并挤压数据库缓存。如何判断：观察入库期间 CPU、内存与在线问答 P95 延迟是否同步抬升，队列积压是否在高峰后持续。如何规避：按队列类型拆分 worker 到独立机器，给入库任务设并发上限与错峰时段，把大批量导入安排在业务低峰。

四、向量与附件放在本地磁盘，扩容只能停机拷贝。问题是什么：想迁移或扩容时，必须安排停机窗口，数据量大时一次搬迁耗掉整个晚上。为什么发生：本地卷与单机绑定，没有网络层访问能力。如何判断：盘点数据目录体积增长曲线，估算一次全量打包、传输、校验所需时间是否超出可接受的停机窗口。如何规避：尽早把附件切到 S3 兼容的对象存储，数据库与向量索引保持可独立迁移的备份策略，定期做恢复演练而不是只做备份。

五、模型 API 走公网出境时，超时与重试被放大成雪崩。问题是什么：起初只是偶发超时，几分钟后整个平台不可用。为什么发生：上层超时大于下层，客户端自动重试叠加下游重试，请求量成倍放大，占满连接与 worker 槽位。如何判断：统计同一 trace 上的重复请求次数，看失败率上升与请求量上升是否同步发生。如何规避：分层设置超时，重试带指数退避与抖动并限定次数与错误类型，引入熔断与降级；同时按模型 API 所在地选择中国大陆或中国香港节点。

关于 Dify 自托管资源配置的八个高频疑问：从并发上限到备份迁移逐条作答

自托管的 Dify 与云端 SaaS 版，在资源这件事上到底差在哪？

差别在"谁替你承担排队"。SaaS 版由平台方统一调度连接池、向量库与 worker 队列，你看到的是一个已经扛过多租户负载的系统，代价是数据落在对方那里、可调项有限、出境与合规由对方定义。自托管反过来：资源全部归你独占，没有邻居吵闹，但连接池上限、索引参数、worker 并发、备份与恢复这些原本由平台方兜底的事，现在全部落到你头上。所以自托管的资源配置，本质不是"买多大机器"，而是把平台方做过的调优重新做一遍，并且自己承担排队成本。

CPU 使用率一直不高，为什么用户还是觉得卡？

因为 Dify 的等待绝大部分属于等待型阻塞，不消耗 CPU 时间片。一次问答要串行等 Embedding 接口返回、等向量索引扫完、等大模型逐 token 吐字，这些时段进程都在睡眠，CPU 自然低。真正被占满的是另外三类资源：数据库连接槽位、Gunicorn 的 worker 槽位、以及 Celery 队列的排队位置。判断可以分三步：查 pg_stat_activity 看会话是否堆在等连接或等锁；翻 Nginx 日志看 upstream 排队耗时；盯队列长度与最老任务等待时长。这三个指标比 CPU 曲线有用得多，也是扩容决策的直接依据。

知识库文档量到多少，就该把向量库从主库拆出来？

不要用文档页数判断，页数与切片数之间没有稳定换算关系，要用切片总量乘以维度算体积。一个可操作的门槛是：索引体积加热区超过单机可用内存的 30%–40%，或者检索 P95 延迟相比上线初期上升超过 50%，就该拆。粗算一下：若用 768 维向量，切片到 50 万条时原始向量约 1.5 GB，叠加 HNSW 图结构与行开销之后，需要常驻的热区往往在数 GB 量级，此时 32 GB 内存的单机已经开始紧张，把数据库与向量库独立出来更稳妥，也顺便让备份窗口变得可控。

自建 Dify 到底要不要配 GPU？

只要模型推理走的是云端 API，就不需要。GPU 只在你本地跑模型时才有意义，比如自建 Embedding 服务、本地部署 Rerank 模型、或者合规上要求数据完全不出内网。判断标准是算账：把每月 API 调用费用与整机租金对比，同时把数据出境的合规成本、以及自建带来的运维人力算进去。T4 ¥900/月、A100 40G ¥2800/月属于官网明示的参考报价（以官网实时价为准），在纯 API 调用场景下这笔支出没有收益；若确实要本地跑小模型，再看裸金属 E5-2698v4×2 ¥3999 起这类整机形态。

Celery worker 的并发数应该开几个？

取决于池类型和外部限流两个变量。用 gevent 池时，并发主要用来覆盖网络等待，可以从 CPU 核数的 2–4 倍起步，但必须受上游模型 API 限流阈值的硬约束，否则会触发 429，再叠加自动重试就是一次重试风暴。用 prefork 时，每个子进程一份独立内存，并发通常不超过核数，否则光是常驻内存就吃掉大半。正确做法不是一次定死：先设基线，再观察队列积压曲线的斜率——高峰后积压能在一小时内消掉说明够用，持续抬升再往上加，并同步确认没有踩到厂商限流。

数据备份和迁移具体要怎么做才不至于半夜救火？

分三类对象、三种节奏。业务库最关键，用逻辑备份工具做定时全量，配合 WAL 归档保证能恢复到任意时间点，备份文件要落到与数据库不同的物理位置；向量索引理论上可以从原始文档重建，备份优先级低于业务库，但重建耗时必须在演练里实测，不能只按理论吞吐估算；附件一旦切到对象存储，就交给它自身的多副本机制。真正关键的动作是恢复演练：每季度至少完整跑一次"从备份恢复到服务可用"的流程并记录耗时，这个数字才是停机窗口的真实依据。

从中国大陆访问海外模型 API 总是超时，有什么可落地的治法？

先分清是连接超时还是响应超时，两者的治法不同。连接超时多与出境链路质量有关，可以通过把应用部署在出境条件更合适的节点上缓解，中国香港节点在这类场景里通常更常见，具体链路表现仍需按运营商、线路与具体机房实测确认，不宜照搬公开数据。响应超时则多与上下文长度、厂商侧排队有关，要靠缩短 prompt、减少每次召回的切片条数、开启流式输出来治。无论哪一种，都要配好分层超时、带指数退避与抖动的重试上限，以及熔断降级，否则一次瞬时抖动就会被重试放大成雪崩。

一台机器到底能撑多少个并发应用？

要先把"应用数"和"并发会话数"分开。Dify 里的应用本质是配置对象，一二百个挂在平台上几乎不占资源；真正吃资源的是同时在线的会话数、每个会话的流式连接保持时长，以及后台 worker 的积压深度。粗估口径是：先给系统与容器栈留 4 GB，给 Postgres 共享缓冲区留整机四分之一，再按每个 API 进程常驻 0.3–0.6 GB、每个 worker 常驻 0.3–0.8 GB 预留，剩下的才是承载并发的空间。按这个口径，8 核 32 GB 的单机大致对应十几到三十路同时在线的问答，再往上就该走阶段二拆分。

把 Dify 的预算先压在内存和队列上：一份可执行的资源分配顺序

如果只读一段，读这段。自建 Dify 的资源分配顺序应该是：先内存，再队列，最后才是 CPU 与 GPU。

具体的分配顺序可以照下面执行。先给数据库与向量索引算内存：按切片总量 × 维度 × 4 字节算出原始向量体积，加上索引结构与行开销，再乘以热区系数，得到需要常驻的内存；在此基础上给 Postgres 的共享缓冲区留出整机的四分之一左右，其余留给操作系统页缓存。再定连接池：按 API 副本数 ×（池大小 + 溢出量）+ worker 常驻连接估算，确保明显小于 max_connections，或者直接上 PgBouncer 做 transaction 级复用。然后拆队列：入库队列与在线生成队列分开，worker 独立部署，设并发上限与错峰策略。最后才考虑算力：只要走云端 API，就不要配卡；确需本地跑模型时再按整机形态重新算账。

几个可以直接拿去用的条件化判断：切片量在 10 万条以内、并发会话两位数以内，单机 8 核 32 GB 起足够，重点是把连接池和共享缓冲区调对；切片到 50 万条量级或检索 P95 明显上升，就把数据库与向量库拆出来独立给内存；批量入库积压消不掉，就把 worker 拆出并按队列类型分离；API 调用月费接近或超过整机租金，才算 GPU 的账。按这个顺序走，同样的预算能换到的并发上限通常比"照着官方起步配置买、卡了就加显卡"高出一大截。

本文参数与配置判断的来源：Dify 官方文档、pgvector 文档与一万网络节点说明

Dify 官方文档《Deploy with Docker Compose / 自部署（Docker Compose）》：镜像与组件清单、启动前置条件（CPU 不少于 2 核、内存不少于 4 GiB）、以及 SQLALCHEMY_POOL_SIZE、SQLALCHEMY_MAX_OVERFLOW、SERVER_WORKER_AMOUNT、CELERY_WORKER_AMOUNT、VECTOR_STORE 等环境变量的说明。该文档随版本持续更新，具体默认值请以 docs.dify.ai 当前版本的说明为准。

Dify 官方 GitHub 仓库 langgenius/dify：docker/docker-compose.yaml 与 docker/.env.example，可核对各服务的镜像版本、worker 启动时消费的队列名称、以及各资源相关变量的默认值。请以仓库 main 分支的最新提交内容为准。

pgvector 官方文档（github.com/pgvector/pgvector）：HNSW 与 IVFFlat 两类索引的构建方式、m、ef_construction、ef_search、lists、probes 等参数的含义，以及索引构建期的内存要求与查询阶段的参数调优。版本迭代较快，以仓库 README 当前内容为准。

PostgreSQL 官方文档《Resource Consumption》与连接池相关章节：max_connections、shared_buffers、work_mem、maintenance_work_mem、checkpoint 相关参数的含义与调优建议，以及 pg_stat_activity 的字段解释。

Redis 官方文档《Memory Optimization》与 Celery 官方文档《Concurrency》：前者用于判断 broker 在队列积压时的内存占用与 maxmemory 策略，后者用于理解 gevent 池与 prefork 在并发模型上的差异。

一万网络官网 https://www.idc10000.net/ ：服务器租用、节点覆盖与带宽形态的产品说明页，本文涉及的机型规格、内存与磁盘配置、以及 T4 ¥900/月、A100 40G ¥2800/月、裸金属 E5-2698v4×2 ¥3999 起、一万云 ¥25 起等参考报价均以此处实时公布的信息为准；机型与带宽的实际可用性、链路质量需结合所在地区与目标用户分布确认，具体以签约时最新报价与合同为准。