2. 端到端推理链路全景：从请求到达、特征工程、模型打分到结果返回的完整流程拆解

在低延迟AML推理系统中，端到端链路并非简单的“请求进、结果出”，而是一条由多个紧密耦合的阶段组成的流水线。任何一个阶段的延迟抖动都会直接放大为整体响应时间的劣化。本章将完整拆解这条链路，从请求到达网关开始，依次经过协议解析、特征工程、模型打分、后处理，直至结果返回客户端，并重点分析每个环节的延迟构成与优化切入点。

2.1 推理链路全景阶段划分

一条典型的在线推理链路可划分为以下六个核心阶段。每个阶段都有独立的延迟预算和优化策略。

2.2 阶段一：请求接入与协议解析

请求到达推理服务的第一站是网关或负载均衡器。此阶段的核心延迟来自网络传输和协议反序列化。

• 网络传输延迟： 包括客户端到服务端的 RTT（往返时间）。对于跨可用区或跨地域部署，RTT 可能占据 5-20ms。优化手段包括就近接入、Anycast 路由、以及使用长连接复用。
• 协议解析延迟： JSON 解析在大量请求下会成为 CPU 瓶颈。gRPC/Protobuf 的二进制格式解析速度通常比 JSON 快 3-5 倍，且序列化体积更小，是低延迟场景的首选。
• 鉴权与路由： 基于 Token 或 JWT 的鉴权应使用缓存，避免每次请求都查询数据库。路由规则应预编译为哈希表或前缀树，实现 O(1) 或 O(logN) 匹配。

2.3 阶段二：特征工程（预处理）

特征工程是 CPU 密集型阶段，也是延迟优化的重灾区。其流程通常包含以下步骤：

1. 特征获取： 从在线特征存储（如 Redis、Memcached）或离线预计算表中拉取原始特征。网络 IO 和缓存命中率是关键。
2. 特征变换： 包括缺失值填充、归一化、离散化、交叉特征组合等。此步骤应使用预编译的表达式或 C++ 原生算子，避免 Python 动态解释执行。
3. 特征拼接： 将多个特征源的数据按模型输入格式组装成张量。内存拷贝次数应最小化，尽量使用零拷贝或共享内存技术。

2.4 阶段三：模型打分（推理）

模型打分是整条链路中最核心、最耗时的阶段。其延迟主要由模型结构、Batch 策略和硬件决定。

• 单请求推理： 对于延迟敏感场景（如实时风控、搜索），通常采用单请求推理，即一个请求一个 Batch。此时延迟主要取决于模型的计算图深度和算子效率。
• 动态 Batch： 对于吞吐优先场景（如离线批量），可将多个请求合并为一个 Batch 推理，以提升 GPU 利用率。但 Batch 会引入排队延迟，需在吞吐和延迟之间做 trade-off。
• 模型优化： 包括量化（INT8/FP16）、剪枝、算子融合、以及使用 TensorRT 或 ONNX Runtime 等推理引擎进行图优化。

2.5 阶段四：后处理与结果组装

模型输出的原始张量通常需要经过后处理才能返回给客户端。常见操作包括：

• Softmax/Sigmoid： 将 logits 转换为概率分布。此操作在 GPU 上执行更快，但若模型输出维度较小，CPU 上执行也可接受。
• 阈值过滤与排序： 例如只返回概率大于 0.5 的前 K 个结果。使用堆排序或快速选择算法，避免全排序。
• 结果格式化： 将内部数据结构序列化为客户端期望的格式（如 JSON、Protobuf、Thrift）。序列化库的选择（如 RapidJSON vs. nlohmann/json）对延迟有显著影响。

2.6 阶段五：结果返回

结果返回阶段的延迟主要来自响应序列化和网络传输。优化策略包括：

• 压缩： 对响应体进行 gzip 或 snappy 压缩，减少传输字节数。但需权衡压缩和解压的 CPU 开销。
• 连接复用： 使用 HTTP/2 多路复用或 gRPC 长连接，避免每次请求都建立 TCP 连接。
• 异步返回： 对于非关键结果，可采用异步回调或消息队列返回，将同步等待时间从链路中剥离。

2.7 贯穿阶段：监控与日志

监控与日志虽然不直接贡献业务价值，但却是低延迟架构的“眼睛”。不当的监控实现反而会引入额外延迟。

• 分布式追踪： 使用 OpenTelemetry 或 Jaeger 进行全链路追踪，记录每个阶段的开始和结束时间戳。采样率应动态调整，例如在低负载时全采样，高负载时降采样。
• 指标采集： 使用 Prometheus 客户端库，以异步方式上报延迟直方图、QPS、错误率等指标。避免在请求路径上同步写磁盘或网络。
• 日志记录： 采用异步日志库（如 spdlog、log4cpp），将日志写入内存缓冲区后批量刷盘。对于高 QPS 场景，建议只记录异常请求和采样请求的详细日志。

2.8 链路延迟的数学建模

为了量化优化效果，我们可以将端到端延迟建模为各阶段延迟之和，并考虑并行与排队效应：

L_total = L_net + L_proto + L_feat + L_infer + L_post + L_serial + L_queue

其中：
- L_net: 网络传输延迟（RTT）
- L_proto: 协议解析与序列化延迟
- L_feat: 特征工程延迟
- L_infer: 模型推理延迟
- L_post: 后处理延迟
- L_serial: 响应序列化延迟
- L_queue: 排队延迟（由请求并发度和服务处理能力决定）

在低延迟系统中，排队延迟 L_queue 往往是被忽视的变量。当请求到达率接近服务处理能力的上限时，L_queue 会呈指数级增长。因此，保持一定的资源冗余（over-provisioning）是保障 P99 延迟稳定的关键手段。