给华为云服务器上的本地小模型加了一层Nginx排队

最近在自己的华为云服务器上跑了一个轻量开源模型，专门给几个日常采集和监控脚本提供文本提取、分类的接口。因为机器配置有限，没有配独显，纯靠CPU在硬跑。

平时一个请求一个请求来的时候，速度还能接受，两三秒就能返回。但上周翻了车：两个定时抓取脚本刚好在同一个整点触发，同时往接口塞了五六个处理任务。结果CPU瞬间占满100%，不仅这两个脚本全部因为超时报错，连挂在同一台机器上的个人博客都跟着卡死了半天。

这台机器本来就是图省钱买的，不可能为了偶尔的并发去升配；也不想为了几个简单的个人脚本去额外搭一套Celery或者RabbitMQ消息队列，维护起来太累赘。最后琢磨了一下，决定直接用服务器前端现成的Nginx来充当简易的任务队列和流量阀门。折腾完记录一下配置上的细节。

第一个调整是用limit_conn限制最大并发。
小模型在CPU上推理是纯粹的计算密集型任务，多核算力全被吃满时，强行并行处理只会让线程频繁争抢上下文，原本3秒能跑完的任务拖到十几秒，两个任务互相掐架双双超时。
既然机器顶不住并行，那就老老实实串行。在Nginx里通过limit_conn_zone把针对该接口的并发连接数硬性限制为1。也就是说，同一时刻只允许一个请求真正进入后端的推理进程，哪怕后面来了一堆任务，也必须在门口守着。

第二个调整是合理设置limit_req的排队缓冲。
直接限制并发很容易导致多出来的请求被Nginx直接甩回503错误，这不是我想要的，我的目标是让脚本别报错、老老实实排队等。
所以核心在于配置limit_req的burst参数。我把处理速率设为很低的每秒0.5次，但给了burst=10的缓冲队列。注意这里千万不能加nodelay参数。不加nodelay，Nginx就会按照设定的速率把后面进来的请求压在缓冲区里慢慢往下放，充当了一个天然的轻量级FIFO队列。脚本发完请求后在连接中等待，直到前面一个任务算完，排到自己再执行。

第三个调整是修改超时时间。
平时我们的反向代理配置，proxy_read_timeout一般默认是60秒。但在这种排队场景下，如果队列里排了三四个长文本任务，轮到最后一个任务时很可能已经过去了一两分钟。
如果不改超时设置，客户端还在苦苦等，Nginx自己先断开连接报了504 Gateway Time-out。所以我把该路径下的proxy_read_timeout和proxy_send_timeout直接放大到了300秒，给长文本排队留足容错窗口。同时在调用端的Python脚本里，把requests的超时参数同步调大，并在捕获到异常时加上基础的指数退避重试。

第四个坑是在FastAPI代码层加一把信号量锁兜底。
只防Nginx有时候并不稳当，万一自己以后从内网其他端口直接调服务，绕过了Nginx，依然有可能把后端打死。
于是我在FastAPI处理推理的核心逻辑外，加了一个全局的asyncio.Semaphore(1)。哪怕并发请求真穿透到了应用层，也只能拿到锁才能进推理函数，拿不到锁就在异步事件循环里排队。这样两头都做了卡口，彻底杜绝了进程被突发流量冲垮的可能。

改完这套配置后，我写了个脚本模拟连续发10个请求过去。
服务器CPU负载虽然依然打到了较高水位，但整个执行过程非常平稳，10个任务像排队打饭一样依次执行完毕，没有一个请求中途掉线或者报错退出，同一台机器上的其他网页访问也基本没受影响。

对于个人开发者来说，算力资源紧缺是常态。遇到高负载或者突发请求，不一定非要去升级硬件或者引入重型架构，善用Nginx自带的限流与缓冲特性，往往几行配置就能把一个容易崩溃的服务改造成皮实耐操的系统。