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是单人电梯,加入并发治理后才是写字楼电梯群控系统。