从模型到服务在之前的章节里，我们把注意力集中在推理引擎内部——算子融合、显存复用、动态 shape 优化，这些都是让单个模型跑得更快的手段。但当我们把这些优化搬到生产环境、面对真实的业务流量时，会发现一个残酷的事实：模型跑得快，不等于服务扛得住。vLLM 的 continuous batching 能在单卡上把吞吐推到极限，可当 500 个并发请求同时涌入时，引擎的调度策略、显存分配、甚至进程模型都可能成为新的瓶颈。模型推理的优化是"点"上的功夫，而服务架构的搭建是"面"上的工程。两者的差距，恰恰是大量推理项目从 Demo 走向生产时折戟的地方。要想理清"面"上的问题，得先回答三个基础问题：请求从哪来？经过谁？最终交给谁？一个典型的推理服务架构，可以拆解为四个核心组件，它们各司其职，构成一条完整的请求链路。组件职责：入口、网关、引擎与存储组件核心职责关键实现API 网关路由分发、鉴权限流、协议转换、负载均衡Nginx、Kong、Envoy推理引擎模型加载、batc