【推理优化】服务于高并发：推理服务架构与调度策略

从模型到服务

在之前的章节里，我们把注意力集中在推理引擎内部——算子融合、显存复用、动态 shape 优化，这些都是让单个模型跑得更快的手段。但当我们把这些优化搬到生产环境、面对真实的业务流量时，会发现一个残酷的事实：模型跑得快，不等于服务扛得住。vLLM 的 continuous batching 能在单卡上把吞吐推到极限，可当 500 个并发请求同时涌入时，引擎的调度策略、显存分配、甚至进程模型都可能成为新的瓶颈。模型推理的优化是"点"上的功夫，而服务架构的搭建是"面"上的工程。两者的差距，恰恰是大量推理项目从 Demo 走向生产时折戟的地方。

要想理清"面"上的问题，得先回答三个基础问题：请求从哪来？经过谁？最终交给谁？一个典型的推理服务架构，可以拆解为四个核心组件，它们各司其职，构成一条完整的请求链路。

组件职责：入口、网关、引擎与存储