第17章：并发请求治理——排队、取消与超时控制

1. 项目背景业务场景第16章部署的API网关上线一周后，用户体验开始分化。上午10点（业务高峰期），客服团队5个人同时提问，老李等30秒才收到回复，小张只等了3秒。更诡异的是，小周的请求直接返回504超时，但几分钟后重试又好了。运维排查发现：Ollama同一时间只能高效服务有限并发——GPU资源固定，每多一个并发请求，所有请求的推理速度都下降。客服团队的5个请求同时到达，GPU显存中同时加载了5个上下文，推理速度变成原来的1/5。更糟糕的是，小张的请求还没完成就按了"停止生成"按钮——但Ollama不知道这个取消信号，继续在后台生成token，白白浪费了GPU算力。痛点无界并发：所有人同时发请求，GPU被过载使用，每个人的速度都变慢——雪崩效应。无排队机制：先到先服务，但先到的人可能问了一个需要生成5000字的问题，后面的人等一个简单回答等几十秒。取消信号丢失：前端用户点了"停止"，但Ollama继续生成，浪费GPU且阻塞后续请求。超时难以设定：不同任务耗时差距悬殊——简单问答2秒，长文档摘要60秒——统一超时值不合适。一句话总结：不加并发的Ollama是单人电梯，加入并发治理后才是写字楼电梯群控系统。2. 项目设计