AWS Auto Scaling组负载均衡后服务器返回504错误原因排查

算力阿峰

2026-6-18

上游服务器返回504错误的可能原因分析

负载均衡器超时配置不匹配：AWS负载均衡器（如ALB、NLB）自带超时阈值，若该值小于你设置的gunicorn超时（3000秒），会先于后端服务判定请求超时，直接返回504。比如ALB默认超时仅60秒，远低于你的后端超时设置，请求还在处理时就会被负载均衡器终止。
Auto Scaling组资源或扩容策略不足：Sentence Transformer模型推理对CPU/GPU资源消耗较高，若Auto Scaling组的实例规格无法承载推理负载，或扩容规则（如CPU阈值、请求队列长度）设置过松，会导致请求堆积、处理延迟，最终触发超时。即使模型加载到根路径解决了挂起问题，资源瓶颈仍会引发504。
gunicorn worker配置不合理：仅设置超时和最大请求数不够，worker数量需匹配实例资源：GPU实例过多worker会导致资源争抢，推理变慢；CPU实例worker数未对应核心数则会造成请求排队。另外，max_requests_jitter=50虽能避免worker同时重启，但如果worker在处理长请求时触发max_requests重启，也可能导致请求超时。
单请求推理耗时超出阈值：即使模型加载正常，处理长文本或复杂语义检查时，单请求的推理时间可能超过负载均衡器或客户端的超时限制，触发504错误。
网络与健康检查问题：VPC内网络延迟过高、安全组/网络ACL限制流量传输，会导致请求传输超时；负载均衡器对EC2实例的健康检查配置不合理（如检查路径错误、阈值过严），会将正常实例标记为不健康，流量无法转发，也会表现为504。
gunicorn与uvicorn版本兼容问题：若使用的uvicorn.workers.UvicornWorker与gunicorn版本不兼容，可能存在长连接处理、请求调度等隐性bug，导致请求处理超时。