2. 模型Serving基础架构：客户端-服务端模型、同步与异步推理、长连接与短连接、RESTful与gRPC协议对比
在生产级模型Serving系统中，基础架构的选择直接决定了推理服务的吞吐量、延迟、资源利用率以及可扩展性。本章将深入剖析构成模型Serving骨架的四大核心维度：通信模型、推理模式、连接管理以及协议选型。理解这些基础组件之间的权衡，是设计高并发推理系统的前提。
2.1 客户端-服务端模型：请求驱动的推理闭环
几乎所有模型Serving系统都遵循经典的客户端-服务端（C/S）架构。客户端发起推理请求，服务端加载模型并执行计算，最后将结果返回给客户端。这个看似简单的闭环，在高并发场景下会衍生出多种优化变体。
核心角色定义：
- 客户端（Client）： 业务应用、API网关、微服务或前端界面。负责封装输入数据（如文本、图像、特征向量）并发送请求。
- 服务端（Server）： 模型推理引擎（如Triton Inference Server、TorchServe、TensorFlow Serving）。负责模型加载、请求调度、GPU/CPU资源管理及结果返回。
- 模型仓库（Model Repository）： 存储模型版本文件（如.pth、.onnx、.plan），服务端从仓库加载模型到内存。
2.2 同步推理 vs 异步推理
根据客户端与服务端的交互方式，推理模式分为同步（Synchronous）和异步（Asynchronous）两种。选择哪种模式，取决于业务对延迟和吞吐量的容忍度。
| 对比维度 | 同步推理 | 异步推理 |
|---|---|---|
| 工作流程 | 客户端发送请求后，阻塞等待服务端返回结果。 | 客户端发送请求后立即返回，通过轮询或回调获取结果。 |
| 端到端延迟 | 低（请求-响应直通） | 较高（需额外轮询/回调开销） |
| 吞吐量 | 受限于客户端连接数和服务端并发处理能力。 | 高（服务端可批量处理请求，客户端无需保持长连接等待） |
| 资源利用率 | 客户端线程/协程在等待期间被占用。 | 客户端资源可被释放，服务端可做请求排队与批处理。 |
| 适用场景 | 实时交互（如在线翻译、对话系统） | 离线批量推理、视频处理、大模型文本生成 |
架构建议： 对于高并发实时场景，推荐使用同步 + 长连接组合，配合服务端动态批处理（Dynamic Batching）来平衡延迟和吞吐量。对于非实时的大规模数据处理，异步模式配合消息队列（如Kafka、RabbitMQ）是更优解。
2.3 长连接与短连接：连接管理的艺术
连接管理直接影响握手开销和系统并发上限。在模型Serving中，短连接和长连接的选择需要结合协议和推理模式综合考虑。
- 短连接（Short-lived Connection）： 每次推理请求都经历TCP三次握手 → 数据传输 → 四次挥手。适用于低频、偶发的推理请求。缺点是频繁握手增加延迟和CPU开销。
- 长连接（Persistent Connection / Keep-Alive）： 建立连接后复用，多个请求共享同一个TCP通道。适用于高频、持续的推理流量。HTTP/1.1的Keep-Alive和HTTP/2的多路复用（Multiplexing）均属于长连接范畴。
避坑指南： 在gRPC中，长连接是默认行为（基于HTTP/2）。但长连接并非没有代价——服务端需要维护大量连接状态，当客户端数量达到数万级别时，连接数可能成为瓶颈。此时需要引入连接池（Connection Pool）或负载均衡器来管理连接生命周期。
2.4 RESTful vs gRPC：协议选型对决
RESTful（基于HTTP/1.1）和gRPC（基于HTTP/2）是当前模型Serving最主流的两种通信协议。它们的差异贯穿序列化、传输效率、流式支持和生态兼容性。
2.5 协议选型决策矩阵
在实际部署中，协议选型需要结合团队技术栈、运维能力和业务需求综合判断。以下决策矩阵可作为参考：
| 决策因素 | 推荐协议 | 理由 |
|---|---|---|
| 团队熟悉HTTP/REST，快速原型验证 | RESTful | 开发门槛低，工具链丰富（Postman、curl） |
| 高吞吐、低延迟、微服务间通信 | gRPC | Protobuf序列化快，HTTP/2多路复用减少连接数 |
| 需要服务端流式返回（如大模型Token流） | gRPC | 原生支持Server Streaming，无需额外实现SSE |
| 需要浏览器端直接调用 | RESTful | 浏览器原生支持HTTP/1.1，gRPC-Web仍有兼容性限制 |
| 已有Kubernetes + Istio服务网格 | gRPC | 网格对HTTP/2流量管理更高效，支持gRPC负载均衡 |
2.6 综合架构示例：高并发推理系统的协议与连接选型
以下是一个典型的高并发模型Serving架构选型示例，结合了上述所有概念：
架构选型总结：
- 外部客户端 → API网关：RESTful（短连接），便于安全认证和限流。
- API网关 → 推理服务端：gRPC（长连接），利用HTTP/2多路复用降低延迟。
- 推理服务端内部：同步推理 + 动态批处理，最大化GPU利用率。
- 离线任务：异步推理 + 消息队列，解耦生产者和消费者。
关键指标参考：
- RESTful + JSON：单次推理序列化开销约 0.5ms ~ 2ms（取决于Payload大小）。
- gRPC + Protobuf：单次推理序列化开销约 0.05ms ~ 0.2ms，性能提升 5~10 倍。
- 长连接 vs 短连接：在1000 QPS场景下，长连接可减少约 30% 的CPU握手开销。