Dify高并发优化需动态设置Gunicorn workers为CPU核心数×2+1，选用Uvicorn异步worker，延长timeout至120秒、keepalive≤5秒，并调优模型超时、工作流并发、Redis缓存TTL及CPU亲和性。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让Dify在高并发请求下保持低延迟、不超时、不堆积任务，同时避免CPU和内存被单个组件吃满导致服务雪崩。
调整Gunicorn工作进程与线程配置
这一步直接决定API层能扛住多少并发连接。默认的1个worker在生产环境完全不够用，必须按CPU核心数动态设置。
第一步：进入Dify后端服务目录，打开gunicorn.conf.py文件。
第二步：将workers参数改为CPU逻辑核心数 × 2 + 1。例如8核机器就设为17；若部署在K8s中且Pod限制为4核，则设为9。
第三步：确认worker_class为uvicorn.workers.UvicornWorker，这是支持异步IO的关键——用同步worker会在线程阻塞时彻底卡死整个进程。
第四步：把timeout从30秒提升到120秒，否则大模型推理中途容易被Gunicorn误杀；但keepalive必须控制在5秒以内，防止长连接占满连接池。
优化模型推理超时与重试策略
模型推理超时不是越短越好，也不是越长越稳，得匹配实际模型加载+前向计算的真实耗时。
方法一：修改config.yaml中的model.inference_timeout字段，设为模型P95响应时间的1.5倍。比如实测BGE-reranker-base平均耗时2.4秒，那就填4s。
方法二：对request_timeout单独设为10s，它只管HTTP层握手和头信息传输，不该和模型计算混为一谈。
方法三：启用max_retries: 1并配合指数退避。第二次重试前等待1.6秒，比固定等3秒更抗突发抖动——【不要设max_retries为0，否则网络瞬断就会直接返回502】。
控制工作流节点并发执行粒度
工作流里多个“调用LLM”节点并行跑，看似快了，实则可能触发GPU显存OOM或Redis锁争抢。
① 在Dify控制台打开目标工作流 → 点击任一LLM节点 → 展开「高级设置」→ 找到「最大并发数」。
② 将其从默认的unlimited改为具体数字：CPU部署填2，GPU部署填1（除非你确认显存≥24GB且模型≤7B）。
③ 同时勾选「启用执行队列」，这会让超出并发上限的任务自动进Redis队列排队，而不是直接拒绝——避免前端报错，也防止下游服务被打穿。
这一步做完，你就能看到Worker日志里不再频繁出现"task rejected: queue full"，而是稳定输出"dequeued and started"。
精简Redis缓存键生命周期
默认Dify把所有缓存设成永不过期，时间一长Redis内存暴涨，触发淘汰策略后反而增加穿透率。
找到redis.conf或K8s中的ConfigMap，定位cache_ttl_seconds参数。
将LLM输出缓存设为1800（30分钟），检索结果缓存设为600（10分钟），而用户会话缓存保留86400（24小时）即可。
改完立刻执行kubectl rollout restart deployment/dify-worker，否则新配置不会生效——【跳过这步会导致旧Worker继续用永久缓存，新旧策略混用可能引发数据不一致】。
启用CPU亲和性绑定降低上下文切换开销
当Worker Pod分配到多核节点却未绑定核心时，Linux调度器会频繁迁移线程，造成L1/L2缓存失效，实测可使推理延迟波动扩大3倍以上。
在Dify Worker启动命令前插入环境变量：GOMAXPROCS=4 AFFINITY_ENABLED=true。
确保宿主机已安装libnuma库，否则affinity功能静默失效——检查命令：numactl --hardware有输出即正常。
启动后运行ps -o pid,psr,comm -p $(pgrep -f "dify-worker")，确认PSR列数字稳定不变，说明线程已锁定在指定核心上。
